LIN통신 LIN2.0 Protocol Spec.(1) ~ 2.2 Frame Slots

 

 

 

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

87c196mc@daum.net 017-279-9381

 

1. 신호 관리(Signal Management)

 

신호는 프레임의 데이터 필드에 실어서 전송된다. 몇몇 신호는 서로 겹치지만 않는다면 하나의 프레임에 묶을 수 있다.

 

각 신호는 정확히 하나의 생산자(producer), 즉 항상 클러스터 내의 같은 노드에 의하여 작성되어야한다. 신호를 수신(subscribe)하는 노드는 0개, 1개 또는 여러 개가 될 수 있다.

 

1.1 신호 종류

 

신호는 수치(scalar value) 이거나 바이트 배열이다.

 

수치는 1~16 비트 길이이다. 1-비트 수치 신호는 논리 신호이다. 2~6 비트의 수치 신호는 부호 없는 정수로 취급된다. 이 밖의 어떠한 해석, 즉 오프셋이나 스케일링은 범위 밖이다.

(역주 : 오프셋과 스케일링은 문서로 규정한다. LIN description file definition의 2.6.1절 참조)

 

바이트 배열은 1~8 바이트의 배열이다. 바이트 배열의 해석은 LIN 규정의 범위 밖이다. 특히 이는 바이트 배열에서 1-바이트가 넘는 요소의 엔디언(endian)에도 적용된다.

 

1.2 신호 일관성(SIGNAL CONSISTENCY)

 

수치 신호를 읽거나 쓸 때에는 분리 조작하지 않는다(atomic operation). 즉, 응용계층에서 부분적으로 갱신된 신호를 수신할 수 없도록 해야한다. 그러나 바이트 배열에서의 각 바이트들 간 또는 신호들 간의 일관성 제한은 없다.

 

1.3 신호 꾸리기(SIGNAL PACKING)

 

신호는 LSB를 먼저, MSB를 나중에 전송한다.  프레임 내의 수치 신호 꾸리기에 적용되는 단 하나의 추가적인 규칙은 수치 신호가 최대 1개의 바이트 경계만을 넘을 수 있다는 것이다(역주:참조그림1 참조). 바이트 배열에서의 각 바이트는 낮은 번호의 데이터 바이트에서 시작하여 단일 프레임 바이트에 사상되어야 한다(역주:참조그림2 참조).

 

 

참조그림1 (a) 수치 신호의 배치가 잘못된 경우 

 

참조그림1 (b) 수치 신호가 올바르게 배치된 경우

 

 

참조그림2 (a) 바이트 배열의 배치가 잘못된 경우

 

 

 

 

참조그림2 (b) 바이트 배열이 올바로 배치된 경우

 

 

2. 프레임 전송(FRAME TRANSFER)

 

LIN 버스를 통하여 전송되는 원소는 프레임이다.

 

한 프레임을 전송하는데 걸리는 시간은 각 바이트를 전송하는 시간에 응답 시간과 바이트 사이의 시간을 더한 것이다. 바이트 사이의 시간은 이전 바이트의 STOP 비트가 종료되는 시간에서부터 다음 바이트의 START 비트가 시작되는 시간이다. 양쪽 모두 음수가 되지 않아야 한다.(역주:바이트 신호가 겹치지 않아야 한다.)

 

프레임 사이의 시간은 한 프레임이 끝난 시점에서부터 다음 프레임이 시작되는 시점 사이의 시간이다. 프레임 사이의 시간도 역시 음수가 되지 않아야 한다.

 

 

2.1 프레임 구조

 

그림 2.1은 프레임의 구조를 보여준다. 프레임은 그림과 같이 하나의 break 신호와 뒤 이은 4~11개의 바이트 필드로 구성된다.

 

 

 

 

 

 그림2.1 : LIN 프레임의 구조

 

각 바이트 필드(Note 2 : break 바이트 제외. 2.1.1절 참조)는 직렬 바이트로 전송된다. 데이터의 LSB가 먼저, MSB가 뒤에 보내진다. START 비트는 0(dominant, 도미넌트)으로, STOP 비트는 1(recessive, 리세시브)로 보내진다.

 

 

 

 

그림2.2 : 바이트 필드의 구조

 

2.1.1 브레이크 (Break)

 

브레이크 신호는 새로운 프레임의 시작 신호로 사용된다. 이것은 그림2.2와 같지 않은 유일한 필드이다. 브레이크는 항상 (마스터 모드에서)마스터 태스크에 의하여 발생하며, 그림 2.3과 같이 시작 비트를 포함하여 적어도 13비트 이상의 도미넌트 값을 유지한 후 브레이크 종료를 출력한다. 브레이크 종료는 적어도 1-비트 시간 이상 되어야 한다.

 

슬레이브 노드는 브레이크 검출 한계로 11-비트 시간을 이용한다.(Note 3 : 슬레이브 노드는 클럭의 오차가 FTOL_SYNCH보다 작아야한다. LIN 물리계층의 테이블1.2에서는 (일반적으로 크리스탈이나 세라믹 공진기 이용) 브레이크 검출 기준으로 9.5-비트 시간을 이용한다.)

 

 

 

 

그림 2.3 : 브레이크 필드

 

2.1.2 싱크 바이트 (Synch byte)

 

싱크는 그림 2.4와 같이 0x55 값을 갖는 바이트 필드이다.

 

 

 

 

그림 2.4 싱크 바이트 필드

 

슬레이브 테스크는 바이트 필드를 대기할 때에도 항상 브레이크/싱크 시퀀스를 검출할 수 있어야한다(바이트 필드는 서로 분리되어 있다고 가정한다. Note 4 : 바이트 필드는 서로 분리되어 있는 것이 바람직하지만 반드시 분리되어야하는 것은 아니다. 브레이크가 데이터 바이트와 일부 겹치더라도 브레이크/싱크 시퀀스를 검출할 수 있어야한다.). 이러한 상황이 발생하면, 브레이크/싱크 시퀀스가 검출되면 진행중인 전송을 중단(Note 5 : 프레임을 처리하던 노드는 Response_error와 오류를 설정(set)해야한다. 5절 참조)하고 새로운 프레임의 전송을 개시해야한다.

 

 

2.1.3 보호 ID (Protected identifier)

 

보호 ID는 두 부분 - ID 필드와 ID 패러티로 구성된다 ; 0~5-비트는 ID이고, 6~7-비트는 패러티이다.

 

아이디

6-비트가 아이디에 할당되어있으며, 값은 0~63까지 이용할 수 있다. 아이디는 4 카테고리로 분류된다.

• 값 0~59(0x3b)는 신호 전달 프레임에 사용된다.
• 60(0x3c)와 61(0x3d)는 진단 데이터에 사용된다.
• 62(0x3e)는 사용자 정의 확장을 위하여 예약되어있다.
• 63(0x3f)는 향후 프로토콜 개선을 위하여 예약되어있다.

패러티

패러티는 식(1)과 식(2)에서와 같이 아이디 비트에 대하여 개산된다.

 

P0 = ID0 ^ ID1 ^ ID2 ^ ID4                                                                                          (1)

P1 = ~(ID1 ^ ID3 ^ ID4 ^ ID5)                                                                                     (2)

 

할당

비트(ID0~ID5와 P0~P1)의 할당은 그림2.5와 같다.

 

 

 

 

그림 2.5 : 보호 아이디 바이트 필드에 대한 아이디와 패러티 비트의 할당

 

2.1.4 데이터

 

한 프레임은 1~8 바이트의 데이터를 전송한다. 특정한 아이디를 갖는 프레임에 포함된 바이트의 숫자는 생산자(publisher)와 모든 소비자(subscriber)가 일치해야한다. 데이터 바이트는 그림2.2와 같이 바이트 필드로 전송된다.

 

1-바이트를 초과하는 데이터는 LSB를 먼저, MSB를 나중에 전송한다(little-endian). 데이터 필드는 그림2.6과 같이 데이터1, 데이터2,...최대 데이터8까지 표시되어 있다.

 

 

 

 

그림 2.6 : 8개의 데이터 바이트를 갖는 프레임의 데이터 바이트 번호 할당

 

2.1.5 첵섬(Checksum)

 

한 프레임의 마지막 필드는 첵섬이다. 첵섬은 모든 데이터 바이트 또는 모든 데이터 바이트와 보호 아이디를 캐리와 함께 함산(Note 6 : 캐리와 함께 합산한 8-비트 합계는 모든 값을 합산한 값이 256이상이면 255를 뺀 것과 같다(이것은 255- 또는 256-나머지 계산과는 다르다))한 후 반전한 것이다. 모든 데이터 바이트만 계산한 첵섬은 일반(classic) 첵섬이라 하며, LIN 1.3 슬레이브와의 통신에 사용된다.

 

모든 데이터 바이트와 보호 아이디 바이트에 대하여 계산한 첵섬은 개량(enhanced) 첵섬이라하며, LIN 2.0 슬레이브와의 통신에 사용된다.

 

첵섬은 그림 2.2에서와 같이 하나의 바이트 필드로 전송된다.

 

일반 또는 개량 첵섬의 사용은 마스터 노드에 의하여 관리되며, 프레임 아이디 마다 결정된다; 일반 첵섬은 LIN 1.3 슬레이브 노드와의 통신에 사용되고, 개량 첵섬은 LIN 2.0 슬레이브 노드와의 통신에 사용된다.(역주 : 네트웍에 LIN 1.3 슬레이브 노드와 LIN 2.0 슬레이브 노드가 혼재될 수 있으며, 이 경우, 각 노드에 대한 첵섬의 사용은 마스터가 통신하려는 개별 노드에 맞게 첵섬을 관리해야한다.)

 

아이디 60(0x3c)에서 63(0x3f)까지는 항상 일반 첵섬을 사용해야한다.

 

 

2.2 프레임 슬롯

 

스케쥴된 각각의 프레임은 버스에 슬롯을 할당한다.(역주 : 슬롯은 한 프레임이 차지하는 시간을 의미한다.) 슬롯 시간은 최악의 경우에라도 프레임을 전송할 수 있도록 시간이 충분히 길어야한다.

 

한 프레임의 전송에 필요한 정상적인 시간은 응답지연시간(response space), 바이트간의 지연시간, 프레임간의 지연시간이 없이 전송해야할 비트의 수와 정확히 일치한다. 따라서

 

THeader_Nomonal = 34 * TBit                                                      (3)

TResponse_Nominal = 10 * (NData + 1) * TBit                            (4)

TFrame_Nominal = THeader_Nominal + TResponse_Nominal              (5)

 

TBit는 LIN 물리계층에서 정의된 바와 같이 한 비트를 전송하는데 필요한 정상적인 시간이다.

 

바이트 간의 최대 지연시간은 정상 전송시간의 40%를 추가한다. 추가시간은 프레임 헤더(마스터 테스크)와 프레임 응답(슬레이브 테스크)으로 분리된다. 이는 다음과 같다.

 

THeader_Maximum = 1.4 * THeader_Nominal                                       (6)

TResponse_Maximum = 1.4 * TResponse_Nominal                               (7)

TFrame_Maximum = THeader_Maximum + TResponse_Maximum               (8)

 

각 프레임 슬롯은 각각의 프레임에 대하여 TFrame_Maximum 이상 되어야한다.

 

노트

모든 수신 노드들은 오버헤드가 없는 프레임, 즉 TFrame_Nominal 길이의 프레임을 수신할 수 있어야한다.

 

THeader_Maximum은 브레이크 신호의 최대 길이에 대한 요구조건을 부여한다.

 

 

(다음 글에 계속)