LIN통신 LIN2.0 Protocol Spec.(2) ~ 2.3 Frame Types

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

87c196mc@daum.net 017-279-9381

 

2.3 프레임 종류

 

프레임 종류는 적절한 프레임 전송을 위한 필요조건에 해당한다. 일부 프레임 종류는 특별한 목적에만 사용되는데, 다음 절에 정의될 것이다. 노드나 클러스터가 이 절에서 정의된 모든 프레임 종류를 지원해야하는 것은 아니라는 점에 주목하라.

 

한 프레임 내에서 정의되지 않거나 사용되지 않는 모든 비트들은 리세시브(1)이어야한다.

 

2.3.1 무조건 프레임 (Unconditional frame)

 

무조건 프레임은 항상 신호를 전송하며, 아이디는 0~59(0x3b)이다.

 

무조건 프레임의 헤더는 항상 (마스터 테스크에 의하여) 무조건 프레임이 진행되어야할 프레임 슬롯에서 전송된다. 무조건 프레임의 생산자(publisher, 슬레이브 테스크)는 반드시 헤더에 대한 응답을 제공해야한다. (역주 : LIN에서는 신호를 생성하는 노드를 publisher, 신호를 수신하여 이용하는 노드를 subscriber라는 용어를 사용한다. 직역하면 출판자/구독자이지만, 이는 CAN 등에서 사용하는 생산자(producer)/소비자(consumer) 개념과 같으므로 어감상 친숙한 생산자/소비자 또는 발신자/수신자 또는 경우에 따라 용어를 혼용하여 사용하였다.) 무조건 프레임의 모든 소비자(subscriber)는 프레임을 수신하여 (오류가 없을 경우) 응용계층이 이용할 수 있도록 조작해야한다.

 

그림 2.7 3개의 무조건 프레임을 전송하는 시퀀스를 보여준다.

 

 

 

그림 2.7 : 3개의 무조건 프레임 전송. 전송은 항상 마스터에 의하여 시작된다. 무조건 프레임은 하나의 생산자와 하나 또는 복수의 소비자가 있다.

 

2.3.2 이벤트 트리거 프레임 (Event triggered frame)

 

이벤트 트리거 프레임의 목적은 이벤트가 가끔 발생하는 여러개의 슬레이브 노드들을 감시하는 데에 너무 많은 버스 대역을 할당하지 않고서도 LIN 클러스터의 응답성을 증대시키기 위한 것이다.

이벤트 트리거 프레임은 하나 또는 그 이상의 무조건 프레임에 데이터를 실어서 전송하며, 아이디 영역은 0~59(0x3b)이다. 전송되는 무조건 프레임의 첫 데이터 바이트는 PID이다. 이것 때문에 신호가 최대 7-바이트로 제한된다.

이벤트 트리거 프레임과 관련된 무조건 프레임이 두 개 이상일 경우(이것은 일반적이다), 프레임들은 길이가 같아야하며, 동일한 쳌섬을 적용해야하며(LIN1.3과 LIN2.0을 혼용 금지), 프레임들은 다른 슬레이브 테스크에서 생산(publish)되어야 한다.

이벤트 트리거 프레임의 헤더는 이벤트 트리거 프레임에 할당된 프레임 슬롯이 수행될 순서가 되면 정상적으로 전송된다(조건은 아래에 설명). 관련 무조건 프레임의 생산자는 프레임에 의하여 전송되는 신호가 갱신되었을 경우에만 헤더에 대한 응답을 제공해야한다.

헤더에 응답하는 슬레이브 테스크가 없을 경우, 프레임 슬롯의 나머지는 조용히 지나가고 헤더는 무시된다.

만일 한 프레임 슬롯 내에 둘 이상의 슬레이브 테스크가 헤더에 대하여 응답하면, 충돌이 발생한다. 마스터는 다음 이벤트 트리거 프레임을 요청하기 전에 (역주:현재의 이벤트 트리거 프레임에)관련된 모든 무조건 프레임을 요청함으로써 충돌을 해소해야한다.

충돌을 일으킨 슬레이브 노드들 중 하나가 충돌 없이 전송을 중단하면 마스터는 이것을 검출할 수 없다. 따라서 슬레이브는 반드시 성공할 때 까지 응답을 재전송해야한다. 그렇지 않으면 응답은 손실된다.

이벤트 트리거 프레임의 모든 수신자는 관련된 무조건 프레임을 수신한 것과 같이 프레임을 수신하고 (쳌섬이 유효할 경우)데이터를 이용해야한다.

그림2.8은 이벤트 트리거 프레임 시퀀스의 한 예이다.

그림 2.8 : ID=0x10은 무조건 프레임 0x11과 0x12와 관련된 이벤트 트리거 프레임이다. 그림에 보인 다섯개의 프레임들 사이에는 스케쥴 테이블에 정의된 다른 프레임이 전송될 수 있다.

예

이벤트 트리거 프레임의 전형적인 사례는 4개의 문을 가진 중앙잠금장치의 각 문의 노브를 감시하는 것이다. 네 개의 모든 문을 감시하기 위해 이벤트 트리거 프레임을 사용하면 버스 부하를 최소화하면서 좋은 응답 시간을 보여준다. 드문 경우에 다수의 승객이 각기 노브를 동시에 누르더라도 시스템은 어떠한 누름도 놓치지 않지만 시간은 더 걸린다.

노트

이벤트 트리거 프레임에 개선 쳌섬을 사용할 경우, 전송된 헤더의 보호 아이디를 쳌섬 계산에 사용해야한다.

 

2.3.3 간헐적 프레임 (Sporadic frame)

 

간헐적 프레임의 목적은 스케쥴 테이블의 다른 스케쥴의 결정성(determinism)을 훼손하지 않으면서 결정적(deterministic)이며 실시간적인 스케쥴 테이블에 동적인 특성을 가미하기 위한 것이다.

 

간헐적 프레임은 항상 신호를 수반하며 아이디는 0~59(0x3b)이다.

 

간헐적 프레임의 헤더는 마스터가 프레임에 전송될 신호가 갱신회었다는 것을 인식할 때 관련된 프레임 슬롯에서만 전송되어야한다. 간헐적 프레임의 생산자는 반드시 헤더에 대한 응답을 제공해야한다. 간헐적 프레임의 모든 수신자는 프레임을 수신하고 (쳌섬이 유효하면)데이터를 이용해야한다.

 

다수의 간헐적 프레임이 같은 프레임 슬롯에 할당되어 있다면(이것은 일반적이다.) 그 프레임 슬롯에서는 우선순위가 가장 높은 간헐적 프레임이 전송되어야한다(노트 7: LIN 구성언어 규정 2.4.3절 참조). 프레임 슬롯에 할당된 간헐적 프레임에 갱신된 신호가 없으면 그 프레임 슬롯은 조용히 지나간다.

 

전송되는 신호가 갱신된 것을 마스터가 알아야한다는 조건은 일반적으로 마스터가 간헐적 프레임의 생산자가 된다. 이벤트 트리거 프레임에서 충돌이 발생하면, 마스터는 관련된 무조건 프레임을 인식하게 된다.(역주 : 이벤트 트리거 프레임에서 충돌이 발생하면 관련된 신호가 갱신되었음을 마스터가 인식해야한다.)

 

그림 2.9는 간헐적 프레임의 시퀀스의 한 예이다.

 

 

 

그림 2.9: 일반적으로 간헐적 프레임의 슬롯은 비어있다. 그림의 두번째 슬롯에서, 관련된 프레임(0x22)이 갱신되었다. 그림에서 프레임 슬롯 사이에 스케쥴 테이블에 정의된 다른 프레임이 전송될 수 있다.

 

2.3.4 진단 프레임 (Diagnostic frames)

 

진단 프레임은 진단이나 구성 데이터를 전송하며 데이터는 항상 8-바이트이다. 아이디는 마스터 요청 프레임 아이디 60(0x3c)이거나 슬레이브 응답 프레임 아이디 61(0x3d)이다. 데이터의 해석은 LIN 진단과 구성 규정에 설명되어 있다.

 

진단 프레임의 헤더를 전송하기 전에, 마스터 테스크는 전송해야할지 또는 버스가 비어있는지를 진단 모듈에 조회해야한다. 슬레이브 테스크는 각자 자신의 진단 모듈에 따라 응답을 생산하고 수신해야한다.

 

2.3.5 사용자 정의 프레임 (User-defined frames)

 

사용자 정의 프레임은 전송하는 정보의 제한이 없다. 아이디는 62(0x3e)이다. 사용자 정의 프레임의 헤더는 항상 그 프레임이 할당된 프레임 슬롯에서 전송된다.

 

2.3.6 예약 프레임 (Reserved frames) 

 

예약 프레임은 LIN 2.0 클러스터에서는 사용하지 않는다. 아이디는 63(0x3f)이다.

 

 

(다음 글에 계속)