LIN통신 LIN2.0 Diag. & Config. Spec.(2)...진단

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

87c196mc@daum.net 017-279-9381

 

 

3. 진단 (DIAGNOSTICS)

 

진단 정보를 수집하는 세 방법을 다음과 같이 규정한다. 이 방법들은 같은 클러스터 내에서 동시에 존재하거나 심지어 같은 노드 내에 존재할 수 있다. 여기에 열거된 방법의 구현은 모두 선택 사항이다.

 

3.1 신호 기반 진단 (SIGNAL BASED DIAGNOSTICS)

진단 정보 수집의 가장 간단한 형식은 일반적인 보통의 무조건 프레임을 이용하는 것이다. 이 해법의 특징은 다음과 같다:

● 슬레이브 노드에 부담이 적다.

● 개념상 표준화(정상적인 신호/프레임을 사용하므로)

● 데이터 내용이 프레임 구조 내에 고정되어 있으므로 융통성이 없다.

 

3.2 사용자 정의 진단 (USER DEFINED DIAGNOSTICS)

 

진단 프레임의 자유 영역을 사용할 수 있다. 진단 프레임의 자유 영역은 반드시 첫 데이터 바이트가 128(0x80)에서 255(0xff)까지의 범위를 가져야한다. 2.3.2절을 참조하라. 자여 영역 진단에 기반한 해법의 특징은 다음과 같다:

● 비표준화와 비이식성

● 요구에 적절하게 설계되므로 부담이 적당하다.

 

사용자 정의 진단은 표준화되지 않으며, 신호 기반 진단이 선호되는 해법이다.

 

3.3 진단 전달 계층 (DIAGNOSTICS TRANSPORT LAYER)

 

LIN 진단 전달 계층의 사용은 ISO 진단이 (CAN-기반) 상위계층 버스에서 수행되고 시스템 구축자가 하위 LIN 버스 클러스터에서 같은 진단 기능을 사용하길 원하는 시스템을 겨냥한 것이다. 메시지는 사실 ISO 메시지와 같으며 3.3.1절에 정의된 바와 같이 메시지를 전송하는 PDU는 매우 유사하다. 전형적인 시스템 구성은 그림3.1과 같다.

 

LIN 진단 전달 계층의 목적은 다음과 같다:

● 마스터의 부담이 적다.

● 전(또는 부분적) ISO 진단을 LIN 슬레이브에 직접 제공한다.

● (저가의 LIN이 아닌)강력한 노드를 포함하는 클러스터의 구축을 겨냥

 

그림 3.1: 전달 계층을 이용한 LIN 클러스터의 전형적인 시스템 구축

 

3.3.1 PDU 구조

 

이 절의 내용은 2.3절에 제공된 내용을 포함하는 관계이다.

 

LIN 진단 프레임에 전달되는 단위를 PDU(Packet Data Unit)라 한다. 한 PDU는 환전한 메시지이거나 한 메시지의 일부분일 수 있다. 후자의 경우, 다수의 연속된 PDU들이 완전한 메시지를 구성한다.

 

클라이언트(ISO:tester, LIN:master)가 전송하는 메시지를 요청이라 하고, 서버(ISO:master, LIN:slave)가 전송하는 메시지를 응답이라 한다.

 

(ISO에 정의된)흐름제어는 LIN 클러스터에서 사용되지 않는다. 상위 버스 시험 장비가 흐룸제어 PDU를 필요로 하는 경우, 이것(흐름제어)은 마스터 노드에서 발생되어야한다.

 

개요

ISO 진단 프레임과 LIN 진단 프레임간의 변환을 간단히 하기 위해 그림 3.2와 같이 PDU 형태를 지원하는 매우 유사한 구조가 정의된다.

 

 

그림3.2: LIN 진단 전달 계층이 지원하는 PDU. 왼쪽 바이트(NAD)가 먼저 전송되고 오른쪽 바이트(D4, D5, D6)가 나중에 전송된다.

 

요청은 항상 마스터 요청 프레임으로 전송되고, 응답은 항상 슬레이브 응답 프레임으로 전송된다. PDU의 각 바이트가 의미하는 것은 다음과 같다.

 

NAD

NAD는 2.3.2절에 정의되어 있다.

 

PCI

PCI(Protocol Control Information, 프로토콜 제어 정보)는 전달 계층 흐름 제어 정보를 포함한다. PCI 바이트에 대해 표3.1과 같이 세 가지 해석이 있다.

 

표3.1: PCI 바이트 구조 

 

PCI 종류에서 SF(Single Frame)는 전송되는 메시지가 단일 PDU임을 가르킨다. 즉, 이것은 최대 5개의 데이터 바이트를 포함한다. 길이는 사용된 데이터 바이트에 1을 더한 값으로 설정된다.(SID와 RSID에 대하여)

 

PCI 종류에서 FF(First Frame)는 복수의 PDU 메시지 중에서 시작을 가르킨다; 이후의 프레임들은 CF 종류이다. 메시지의 총 데이터 바이트 수에 (SID 또는 RSID에 관하여)1을 더하여 Length를 전송해야한다: Length의 상위 4비트는 PCI 바이트에 위치한다(하위 8비트는 LEN에 전송한다, 다음을 보라).

 

복수-PDU 메시지는 CF(Continuation Frames) 종류가 계속된다. 메시지의 첫 CF 프레임은 번호가 1로 매겨지고, 두 번째는 2, 등이다. CF PDU가 15개 이상일 경우, 프레임 번호는 0으로 되돌아가서 다시 증가한다.

 

LEN

LEN 바이트는 FF 프레임에서만 사용된다; 이것은 메시지 Length의 하위 8비트를 포함한다. 따라서 메시지의 최대 길이는 4095(0x0fff) 바이트이다.

 

SID

서비스 아이디(SID)는 주소지정된 슬레이브 노드가 수행해야할 요청을 규정한다. 0에서 0xaf, 그리고 0xb8에서 0xfe까지가 진단에 사용되며, 0xb0에서 0xb7까지가 노드 구성에 사용된다. 이 SID 번호체계는 ISO 15765-3와 일치하며 “자동차 제조사가 정의한”영역 내에 노드 구성을 위치시킨다.

 

RSID

RSID(Response Service Identifier)는 응답의 내용을 규정한다.

 

D1~D6

데이터 바이트(단일 PDU에서는 6바이트까지)의 해석은 SID와 RSID에 따른다. 다중-PDU 메시지에서 메시지의 모든 PDU 안에 있는 모든 바이트들은 해석되기 전에 하나의 완전한 메시지로 연결되어야 한다.

 

만일 한 PDU가 불완전하게 채워진다면 사용되지 않는 바이트는 1로, 즉 그 값은 255(0xff)가 되어야한다.

 

3.3.2 정의된 요청 (Defined requests)

 

LIN 전달계층은 ISO 진단 표준과 같은 진단 메시지를 이용한다. 이로부터 SID와 RSID 역시 ISO 표준을 따라야한다. 노드는 ISO 표준에 정의된 서비스의 일부를 구현할 수 있다.(역주: 모두 구현하지 않아도 된다.)

 

3.3.3 ISO 타이밍 제한 (ISO timing constraints)

 

ISO에 사용된 타이밍은 몇몇 속성, 즉 P2와 ST, T1에 기반한다. 속성은 정의된 범위 내에 있어야한다. LIN이 CAN보다 느리기 때문에 값들은 그에 맞게 조정되어야한다.

 

이러한 속성에 사용되는 값들은 LIN 표준이 아니다. 그것은 진단 프레임간의 적절한 주기를 갖는 스케줄 테이블의 선택에 의하여 조절된다. 이런 방법으로 값들은 클러스터 개발자의 완전한 통제에 놓이게 되고 적절한 균형(trade-off)에 따라 설정된다.

 

3.3.4 순서도(Sequence diagrams)

 

두 통신 상황이 있다; 테스터는 슬레이브 노드에게 진단 요청을 전송하려하고, 슬레이브는 진단 응답을 테스터에게 전송하려한다. 아래 그림3.3과 그림3.4는 이러한 두 상황의 메시지 흐름을 보여준다.

 

다수의 슬레이브가 동시에 응답(이것은 버스 충돌을 유발한다)하는 요청을 피하도록 통신을 조절하는 것이 중요하다.

 

그림3.3: CAN으로부터 LIN으로의 신호변환

그림 3.4: LIN 메세지를 CAN으로 신호변환