LIN통신 LIN2.0 Protocol Spec.(3)

틀린 곳이 있으면 댓글을 달거나 연락 주시기 바랍니다.

87c196mc@daum.net 017-279-9381

3. 스케쥴(Schedules)

 

LIN 통신의 중요한 특징은 스케쥴 테이블을 이용한다는 것이다. 스케쥴 테이블을 이용함으로써 버스가 과부하 상태로 되는 것을 막을 수 있다. 이것은 또한 주기적인 신호를 보장하는 중요한 요소이다.

 

LIN 클러스터 내부의 모든 전송은 마스터 태스크로부터 개시된다는 사실은 확실한 동작을 가능케 한다. 마스터는 동작중의 모든 프레임이 충분한 전송 시간을 갖도록 할 책임이 있다.

 

3.1 슬롯 할당(SLOT ALLOCATION)

 

이 절에서는 스케쥴 테이블이 준수해야할 모든 요구조건을 규명한다. 요구조건의 대부분의 근본적인 이유는 충돌이 없는 표준의 제공 또는 LIN 통신의 간단하고 효율적인 구현을 제공하기 위한 것이다.

 

간헐적 프레임(sporadic frame) 또는 이벤트 트리거 프레임과 관련된 무조건 프레임(unconditional frame)은 간헐적 프레임 또는 이벤트 트리거 프레임과 같은 스케쥴 테이블에 할당되지 않을 수 있다.

 

프레임 슬롯은 마스터 태스크에 의해 발생한 지터(jitter)와 식(8)에 정의된 TFrame_Maximum을 허용하도록 충분히 긴 주기를 가져야 한다. 식의 바로 뒤에 지적한 바와 같이 신호 생산자가 수용할 수 있다면 TFrame_Maximum은 줄어들 수 있다.

 

 

4. 태스크 동작 모델

 

4.1 마스터 태스크 스테이트 머신

 

마스터는 스케줄 테이블에 따라 어느 프레임이 보낼지, 프레임 사이의 시간을 얼마로 유지할지를 결정하고, 올바른 헤더를 발생시켜야한다.

마스터 태스크의 스테이트 머신은 그림4.1과 같다.

 

 

 

그림 4.1: 마스터 태스크의 전체 스테이트 머신

 

스테이트 머신의 아이디 필드의 아이디를 선택하는 방법을 규정하지 않는다.

 

Note : 마스터 태스크의 오류를 모니터링하는 것은 필요하지 않다. 리세시브(1)을 전송하는 동안 도미넌트(0)가 검출되는 것 같은 오류는 슬레이브가 헤더를 무시할 것이다.

 

4.2 슬레이브 태스크 스테이트 머신

 

슬레이브가 생산자일 경우에는 응답 프레임을 전송하고, 수신자일 경우에는 응답 프레임을 수신하는 것이 슬레이브의 태스크이다. 슬레이브 태스크는 다음 두 스테이트 머신으로 모델링된다.

• Break와 Synch 검출
• 프레임 처리

4.2.1 Break와 Synch 검출

 

슬레이브 태스크는 프레임의 PID의 시작에서 동기되어야한다. 즉, PID 필드를 올바르게 수신해야한다. 슬레이브는 LIN 물리계층 규정의 1절에 규정한 바와 같이 나머지 프레임 전체 기간에 bit-rate가 오차범위를 유지하여 동기를 유지해야한다.

 

4.2.2

 

프레임 처리는 휴면과 활성 2개의 상태로 구성된다. 활성 상태는 5개의 세부 상태로 구성된다. BreakAndSynch 신호 직후에 활성 상태는 ID 수신 세부 상태로 진입해야한다. 이것은 새로운 break/synch가 발생된 것을 검출하면 처리중이던 프레임에서 벗어나야 함을 의미한다. 프레임 처리 스테이트 머신은 그림4.2에 그려져 있다.

 

 

그림 4.2: 프레임 진행 스테이트 머신

 

오류(Error)와 성공(Success)는 6절에 설명하는 상태 관리에 이용된다.

 

전송한 데이터와 귀환 값이 불일치할 경우, 불일치가 포함된 바이트를 전송한 직후 불일치를 감지해야한다. (역주: 불일치가 포함된 바이트 이후에 새로운 바이트가 전송되지 않아야한다.)

 

[Test] 1. 마스터 헤더+데이터 전동 도중 데이터 전송 중간에서 중단하고 새로운 헤더+데이터 송신한다. -> 데이터를 수신하는 슬레이브가 뒤에 보낸 데이터에 맞게 동작하는 지 확인.

2. 마스터 헤더 + 슬레이브 응답에서 슬레이브 응답 도중에 마스터에서 새로운 마스터 헤더를 발생시킨다. 슬레이브 8바이트 데이터+checksum 응답일 경우, 마스터는 최초 헤더를 전송한 후, 6 바이트 시간 후에 다시 헤더를 전송한다. 마지막으로 전송한 헤더에 대해 슬레이브가 응답을 올바르게 하는지 마스터에서 확인한다.

 

5. 네트워크 관리

 

LIN 클러스터에서의 네트워크 관리는 휴면(sleep)과 기상(wake up) 뿐이다. 다른 네트워크에서의 시스템 구성 검출이나 림프 홈(limp home, 시스템 고장시 미리 정해진 값을 사용하여 최소 한도의 성능을 유지하는 것)과 같은 관리 기능은 응용 계층에서 처리한다.

 

5.1 기상(wake up)

 

휴면 상태에 있는 LIN 클러스터의 모든 노드는 기상을 요청할 수 있다.(note 8: 마스터는 정상적인 헤더를 발생시켜서 브레이크 신호를 발생시킬 수 있는데, 이는 헤더의 브레이크가 기상 펄스와 같이 작동하기 때문이다.) 기상 요청은 버스를 250us에서 5ms 동안 도미넌트 상태로 만들어서 발생된다. (전원이 연결된)모든 슬레이브는 기상 요청(150us이상의 도미넌트 펄스, note 9: 150us는 250us 펄스 발생에 대하여 타이머가 정확하지 않은 슬레이브 노드가 충분히 검출할 수 있는 마진을 둔 것이다.)을 검출해야하고, 도미넌트 펄스의 상승 모서리로부터 100ms 이내(note 10:마스터가 추가적인 정보가 없다면, 즉 클러스터 내의 단 한 개의 슬레이브가 기상 신호를 보낸 상태라면 이 시간은 100ms가 걸릴 것이다. 슬레이브는 분명히 즉각 통신 준비 상태이다.)에 버스 지령을 수신할 준비를 해야 한다. 마스터도 기상하여, 모든 슬레이브가 준비(상태가)되면, 프레임 헤더의 전송을 시작하여 기상 사유를 알아내야 한다.

기상 요청으로부터 150ms 이내에 마스터가 프레임 헤더를 발생시키지 않을 경우, 요청을 발생한 노드는 새로운 기상 요청을 발생시킬 수 있다. 세 번 (실패한)요청 후에, 노드는 최소 1.5초 기다렸다가 4번 째 기상 요청을 발생시킨다.

 

5.2 휴면 진입 (GOTO SLEEP)

마스터는 첫 데이터 바이트가 0인 진단 요청 프레임(프레임 Id=0x3c, Note 12: 첫 데이터 바이트는 일반적으로 노드 주소 NAD이며, 0은 허용되지 않는다.)을 전송하여 활성 클러스터 내의 모든 슬레이브 노드를 강제로 휴면 모드(휴면은 클러스터만으로 한정하며, 노드의 응용 계층은 여전히 활성 상태일 수 있다.)로 전환시킬 수 있다. 이러한 진단 프레임의 특별한 사용을 휴면진입지령(go-to-sleep-command)이라 한다.

만일 LIN 버스가 4초 이상 비활성(Note 13:비활성은 0과 1 비트 값의 변화가 없는 상태로 정의된다.) 상태이면 모든 노드들은 자동적으로 휴면 모드로 진입해야한다.

 

5.3 전원 관리(power management)

LIN 노드의 전원 관리 동작 모델은 그림 5.1의 상태도와 같다. 이 문서에서 규정된 LIN 프로토콜 동작은 동작 상태(Operational state)에만 적용된다. (역주: 전원 투입 후 100ms 이내에 초기화를 마치고 동작 상태로 진입해야한다.)

 

 

그림 5.1: LIN 노드 전원 관리

 

6. 상태 관리(STATUS MANAGEMENT)

 

상태 관리의 목적은 작동 중 오류를 검출하는 것이다. 오류 검출의 목적은 두 가지이다.

● 고장 부품을 쉽게 대체하는 방법을 제공

● 문제가 방생했을 때 노드가 림프 홈 모드로 진입할 수 있도록 제공

비록 규정으로 표준화 되지는 않았지만 노드는 이 절(chapter)에서 요구하는 상태 관리 기능 외에 추가적으로 보다 상세한 오류 정보를 제공할 수 있다.

 

6.1 개념

중앙집중적인 클러스터 상태 관리는 마스터 노드에서 행해진다. 마스터 노드는 각 노드로부터의 상태 보고를 관찰하고 보고를 거르고/종합하여 하나의 또는 그 이상의 노드가 고장인지 판단한다. 각 노드의 응용 계층은 자신과 LIN 버스와의 상호 작용을 감시할 수 있다. 이것은 가능한 경우 림프 홈 모드로 진입하는데 쓰일 수 있다.

 

6.2 이벤트 트리거 프레임

 

2.3.2절의 이벤트 트리거 프레임은 충돌을 허용하도록 정의되었다. 따라서 버스 오류, 즉 프레임 오류는 상태 비트(전송성공 비트, 응답중 오류 비트)에 영향을 주면 안된다. 물론 이와 관련된 무조건 프레임에서 오류가 발생하면, 이것은 오류로 간주해야한다.

 

 

6.3 네트워크에 대한 보고

 

네트워크에 대한 보고는 마스터 노드에서 수행되며 클러스터를 감시하는데 사용된다. 슬레이브 노드만이 자신의 상태를 네트워크에 보고해야한다.

 

각 슬레이브는 자신의 전송 프레임 중에 하나의 상태 비트 신호 Response_Error를 마스터에게 전송해야한다. 노드에 의하여 전송되거나 수신되는 응답 필드에 오류가 있을 경우, 그 노드는 항상 Response_Error를 1로 설정해야한다. Response_Error는 전송 후 지워야한다.

 

마스터는 이 신호 비트로부터 다음과 같은 결론을 내릴 수 있다.

• Response_Error = False -> 노드가 정상적으로 작동중이다.
• Response_Error = True -> 노드가 간헐적으로 문제가 있다.
• 노드가 응답하지 않는다. -> 노드(또는 버스 또는 마스터)가 심각한 문제가 있다.

 

 

[Test] 마스터 생산자 프레임에 checksum 오류를 만들어서 전송하고, 슬레이브 생산자 프레임에 Response_Error 비트가 1로 설정되었는지를 마스터 수신에서 확인한다.

 

 

마스터는 프레임이 전송되지 않은 사실로부터 정보를 수집하기 때문에 Response_Error 상태 비트가 이벤트 트리거 프레임에 있을 수 없다. 이 제약 외의 모든 프레임은 Response_Error 상태 비트를 전송하는데 사용할 수 있다. 마스터 노드는 응용 계층에서 서로 다른 슬레이브 노드들로부터 보고된 상태를 합성하고, 개별상태 보고를 거르고 합치는 작업을 해야한다.(Note 14:예를 들어 다수의 노드가 응답하지 않을 경우, 마스터는 모든 슬레이브가 아니라 자신이 고장이라고 결론을 내릴 수 있다.)

 

Note

 

Response_error는 응용 계층이나 신호 상호작용 계층(signal interaction layer)에 관계없이 프레임 트랜시버(프로토콜 엔진)의 성능 시험을 수행하는데 충분하다.

 

 

슬레이브 노드는 원한다면 추가적인 상태 정보를 제공할 수 있지만, 단 1개의 response_error 비트는 항상 존재해야한다.

 

6.4 자기 자신에 대한 내부 보고

 

이 절은 소프트웨어 기반 노드에 적용되지만 ASIC 기반 스테이트 머신 구현에도 같은 개념의 사용을 권장한다.

 

노드는 노드 자기 자신 내부에 상태 관리를 위해 error_in_response와 successful_transfer, 2개의 상태 비트를 제공한다. 또한 노드 자신의 응용 계층은 노드가 인지한 마지막 프레임의 PID를 수신한다.

 

Error_in_response는 노드가 수신 또는 송신하는 프레임이 응답 필드에 오류를 포함되어 있을 경우 1로 설정된다. 즉, Response-error를 1로 설정하는 조건과 같다.

Successful_transfer는 노드가 한 프레임을 성공적으로 전송했을 경우, 즉 한 프레임을 수신 또는 송신했을 경우 1로 설정한다.

 

두 상태 비트는 읽은 후에 지운다.

 

두 상태 비트는 표6.1과 같이 해석될 수 있다.

 

표 6.1: 노드 내부 오류 해석

 

	error in response	successful transfer	해석
	0	0	통신 없음
	1	1	산발적인 통신 (전송 일부 성공, 일부 실패)
	0	1	통신 정상
	1	0	통신 오류(전송만 실패)

 

 

각 상태 보고를 종합하고 거르는 것은 노드의 응용계층의 책임이다.

 

Note

노드 자신에 대한 내부 보고는 LIN 응용계층 인터페이스 규격에 표준화 되어 있으며, 신호 상호작용 계층을 포함한 LIN 드라이버 모듈의 무결성 성능 시험을 자동으로 실행하는 응용 프로그램을 자동으로 실행하는 데 쓰일 수 있다.