LIN (Local Interconnect Network) 버스는 자동차 네트워크에서 저가형, 로우엔드 멀티플렉스 통신을 구축하기 위해 개발되었습니다. CAN은 고대역폭의 고급 에러 핸들링 네트워크 요구사항을 해결하지만, 파워윈도우 기능(power window)과 좌석 조절기 같은 높은 성능이 필요하지 않는 기능을 CAN으로 구현하기에는 지나치게 높은 비용을 필요로하게 됩니다. LIN은 CAN의 대역폭과 다양한 기능이 필요하지 않은 어플리케이션에 효율적인 통신을 제공합니다.
대부분의 현대식 저가 8-비트 마이크로컨트롤러에 임베드된 표준 시리얼 유니버셜 비동기 송/수신기 (UART)를 사용하면 비교적 저렴하게 LIN 통신을 구현할 수 있습니다.
현대의 자동차 네트워크는 LIN (차체 전자장치에서의 저가형 어플리케이션), CAN (주요 파워트레인 및 차체 통신) 및 FlexRay 버스 (능동 현가장치와 같은 고급 시스템에서 고속 동기화된 데이터 통신)의 통합된 형태를 사용합니다.
LIN 버스는 LIN 마스터와 하나 이상의 LIN 슬레이브로 구성된 마스터/슬레이브 방식을 사용합니다.
그림 1. LIN 메시지 프레임
메시지 헤더는 프레임의 시작을 파악할 때 사용되는 브레이크와 클럭 동기화를 위해 슬레이브 노드에서 사용되는 동기 필드로 구성됩니다. 식별자 (ID)는 6-비트 메시지 ID와 2-비트 패리티 필드로 구성됩니다.
ID는 특정 메시지 주소를 표시하지만 목적지를 표시하지는 않습니다. ID를 받고 해석할 때 하나의 슬레이브는 메시지 응답을 시작합니다. 이는 데이터의 1~8 바이트와 8-비트 체크섬으로 구성됩니다.
마스터는 스케쥴에 고정된 메시지 프레임의 시퀀싱을 컨트롤합니다. 필요에 따라 스케쥴을 변경할 수 있습니다.
LIN 표준에는 여러가지 버전이 있습니다. 1.3 버전은 바이트-계층 통신을 완성하였습니다.
2.0 및 2.1 버전은 더 많은 메시징 사양과 서비스를 추가하였으나, LIN1.3과 바이트 레벨에서 호환되지 않습니다.
| 기능 | NI USB LIN의 지원 |
| LIN 1.3 | 지원 |
| LIN 2.0 | 지원 |
| 향상된 체크섬 | 지원 |
| 상용 슬레이브 노드 개념 | 지원 |
| NCF 포맷 | 지원 |
| 진단 및 슬레이브 노드 구성 | 지원 |
| 바이트 배열 | 지원 |
| LIN 2.1 | 지원 |
| 새로운 슬레이브 노드 구성 서비스 | 지원 |
| 슬레이브 진단 클래스 I-III | 지원 |
| Functional addressing | 지원 |
| 해상도 테이블 | 지원 |
표 1. LIN 1.3, 2.0 및 2.1 버전 비교
LIN 버스는 단일 마스터 디바이스와 하나 또는 그 이상의 슬레이브 디바이스로 폴링된 버스입니다. 마스터 디바이스에는 마스터 태스크와 슬레이브 태스크가 있습니다. 각 슬레이브 디바이스는 슬레이브 태스크만 보유합니다.
LIN 버스의 통신은 마스터 디바이스의 마스터 태스크가 전적으로 컨트롤합니다. LIN 버스에서 전송의 기본 단위는 프레임이며, 이는 헤더와 응답으로 나뉘어집니다.
헤더는 마스터 노드가 항상 전송하며, 세 개의 필드 즉, 브레이크, 동기 (sync) 및 식별자 (ID)로 구성됩니다. 슬레이브 태스크가 전송하며 마스터 노드 또는 슬레이브 노드에 존재하는 응답은 데이터 페이로드와 체크섬으로 구성됩니다.
일반적으로 마스터 태스크는 헤더 (브레이크-동기-ID 시퀀스로 구성)를 전송함으로써 루프에서 각 슬레이브 태스크를 폴링합니다. LIN을 시작하기 이전에 각 슬레이브 태스크는 데이터를 버스에 출판하거나 각 수신된 헤더 ID에 대한 응답으로 데이터를 구독하도록 구성됩니다.
헤더를 수신하면 각 슬레이브 태스크는 ID 패리티를 확인한 후 ID를 체크하여 출판 또는 수신이 필요한지를 결정합니다. 슬레이브 태스크가 응답을 출판해야 한다면 태스크는 1~8 데이터 바이트를 버스에 전송한 후 체크섬 바이트가 따라옵니다. 슬레이브 태스크가 구독해야 하는 경우 버스로부터 데이터 페이로드와 체크섬 바이트를 읽고 적절한 내부 동작을 취합니다.
표준 슬레이브-마스터 통신에서 마스터는 식별자를 네트워크로 브로드캐스트하고 단 하나의 슬레이브가 데이터 페이로드에 응답합니다.
마스터-슬레이브 통신은 마스터 노드에서 개별 슬레이브 태스크에 의해 완성됩니다.
본 태스크는 버스에 출판된 모든 데이터를 자가 수신하며, 마치 독립 슬레이브 노드인 것처럼 응답합니다. 데이터 바이트를 수신하기 위해 마스터는 반드시 내부 슬레이브 태스크 응답을 전송하고자하는 데이터 값으로 업데이트해야 합니다.
그 후 마스터는 적합한 프레임 헤더를 출판하고 내부 슬레이브 태스크는 데이터 페이로드를 버스에 전송합니다.
Figure 2. LIN Message Frame
1. 브레이크
모든 LIN 프레임은 브레이크로 시작됩니다. 이는 13개의 우성 비트 (nominal)로 구성되며, 하나의 열성 비트 (nominal) 인 break delimiter가 이를 따릅니다. 이것은 프레임의 시작을 버스의 모든 노드에 알리는 역할을 합니다.
2. 동기 필드
동기 필드는 헤더에서 마스터 태스크가 전송하는 두 번째 필드입니다. 동기는 문자 x55로 정의됩니다. 동기 필드가 있으면 자동 보드 속도 감지를 수행하는 슬레이브 디바이스가 보드 속도의 주기를 측정할 수 있으며 버스와 동기화하기 위해 내부 보드 속도를 조정합니다.
3. ID 필드
ID 필드는 헤더에서 마스터 태스크가 전송하는 마지막 필드입니다. 본 필드는 네트워크에서 각 메시지에 대한 식별을 제공하며 궁극적으로 네트워크에서 어떤 노드가 수신하고 전송에 응답하는지 결정합니다. 모든 슬레이브 태스크는 연속적으로 ID 필드를 확인하며 패리티를 검증하고 특정 식별자에 대한 출판자인지 구독자인지를 파악합니다. LIN 버스는 총 64개의 ID를 제공합니다. ID 0 ~ 59는 신호 운반 (데이터) 프레임에 사용되며, 60, 61은 진단 데이터를 운반하는 데 사용되며, 62는 사용자 정의된 확장을 위해 확보되었으며, 63은 향후 프로토콜 향상을 위해 확보되었습니다. ID는 버스를 통해 하나의 보호된 ID 바이트로 전송됩니다. 아래의 6비트는 원시 ID를 포함하고 위의 두 개 비트는 패리티를 포함합니다.
| 보호된 ID(7:6) | 보호된 ID(5:0) |
|
| P(1) | P(0) | ID(5:0) |
| ID(1) ^ ID(3) ^ ID(4) ^ ID(5) | ID(0) ^ ID(1) ^ ID(2) ^ ID(4) | 0–63 |
표 2. 패리티 계산 방식
4. 데이터 바이트
데이터 바이트 필드는 응답에서 슬레이브 태스크가 전송합니다. 본 필드에는 페이로드 데이터 바이트 중 1에서 8 바이트를 포함합니다.
5. 체크섬
데이터 바이트 필드는 응답에서 슬레이브 태스크가 전송합니다. LIN 버스는 8-비트 체크섬 필드에서 값을 계산하기 위해 2개 체크섬 알고리즘 중 하나의 사용을 정의합니다. 기존 체크섬은 데이터 바이트를 합하여 계산되는 반면, 향상된 체크섬은 데이터 바이트와 보호된 ID를 합하여 계산됩니다.
LIN 2.0 사양 정의에 따르면 체크섬 계산은 모든 값을 더하고 그 값이 256보다 크거나 256일 경우에 255를 뺀 값으로 계산됩니다. (modulo-255 또는 modulo-256과 다름) LIN 2.0 사양에 따르면 LIN 1.3 슬레이브 노드와 사용하기 위한 일반 체크섬이 있고 LIN 2.0 슬레이브 노드와 사용하기 위한 향상된 체크섬이 있습니다.
또한 ID 60~63이 항상 일반 체크섬을 사용해야 한다는 것을 설명합니다. NI LIN 인터페이스는 체크섬 유형을 일반 체크섬 또는 향상된 체크섬 중 설정할 수 있는 속성을 제공합니다. 기본 설정은 일반 체크섬입니다.
LIN 2.0 사양에 따르면, ID 60~63은 체크섬 속성의 설정에 상관없이 항상 일반 체크섬을 사용합니다.
그림 3은 마스터 태스크 헤더와 슬레이브 태스크 응답이 LIN 풀 프레임을 구축하기 위해 통합된 모습입니다.
그림 3. LIN 프레임 구축
LIN 버스 타이밍
LIN 버스는 폴링된 버스이므로 각 프레임의 처리는 다음과 같이 명목 시간 슬롯으로 할당됩니다.
THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
Processing of each frame is allocated a maximum time slot as follows:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum
LIN의 토폴로지와 작동방식
LIN 버스는 단일 마스터 디바이스 (노드)와 하나 또는 그 이상의 슬레이브 디바이스 (노드)를 LIN 클러스터에서 연결합니다. 각 노드의 동작은 고유의 노드 기능 파일에 의해 설명됩니다. 노드 기능 파일은 시스템 정의 툴에 대한 입력으로써, 전체 클러스터의 동작을 설명하는 LIN description file (LDF)을 생성합니다.
LDF는 원하는 노드에서 특정 동작을 자동 생성하기 위해 시스템 생성기가 분석합니다. 본 지점에서, 마스터 태스크는 버스에서 헤더를 전송하고 클러스터의 모든 슬레이브 태스크는 (마스터 노드의 고유 슬레이브 태스크 포함) LDF에 설명된 것처럼 응답합니다.
일반적으로 LDF는 LIN 클러스터의 스케쥴링 동작을 구성하고 생성하는 데 사용됩니다.
예를 들어, 보드(baud) 속도, 헤더의 마스터 태스크 전송을 위한 순서와 시간 지연 그리고 각 슬레이브 태스크의 동작을 정의합니다. NI LIN 하드웨어와 LIN용 NI-CAN Frame API는 LDF에 전적인 지원을 제공하지 않습니다.
다시 말해, 스케쥴링 동작을 하드웨어에 다운로드할 수 없다는 뜻입니다. 그러나, 버스에 액세스하는 로우 레벨의 지원 (헤더 작성과 응답에 대한 출판 또는 구독)이 제공되어 사용자가 어플리케이션 레벨에서 이같은 스케쥴링 동작을 생성할 수도 있습니다.
NI LIN 응답 엔트리 프레임 유형에 대한 설명에서 언급한바와 같이, NI LIN 하드웨어는 슬레이브 태스크 응답을 저장하기 위한 응답 큐를 갖추고 있습니다. 응답 큐는 64개의 응답을 보유하며, LIN에 정의된 최대 64개 ID 중 각각에 해당됩니다.
이를 통해 LIN 인터페이스 슬레이브 태스크는 LIN 사양이 정의한 응답 시간 내에서 헤더에 응답할 수 있습니다.
LIN용 NI-CAN Frame API는 LIN 버스와 완벽한 로우 레벨 연동을 위한 수단을 제공합니다. 이를 통해 최종 사용자들은 LIN 네트워크의 분석 및 프로토타입과 같은 복합적인 어플리케이션을 개발하기 위해 기본 기능을 사용할 수 있습니다.
LIN용 NI-CAN Frame API는 LIN 진단 또는 구성, LDF 또는 스케쥴 테이블을 원시 지원하지 않습니다. 그러나, LIN용 NI-CAN Frame API를 사용하는 어플리케이션에서 본 태스크를 실행할 수도 있습니다.
LIN 에러 감지 및 제한
LIN 2.0 사양은 에러 감지가 슬레이브 태스크에 의해 처리되어야 하며 마스터 태스크에 의한 에러 모니터링은 필요하지 않음을 명시하고 있습니다. LIN 2.0 사양은 하나의 LIN 프레임 내에서 여러 개의 에러 처리 또는 에러 카운터의 사용을 요구하지 않습니다.
프레임에서 첫 번째 에러가 발생하면, 슬레이브 태스크는 다음 브레이크-싱크 시퀀스 (마스터가 전송하는 다음 헤더)가 감지될 때까지 프레임의 처리를 중지합니다. 로그 버스 에러 속성이 "true"로 설정되면, 버스 에러 프레임은 읽기 큐에 로깅됩니다. 로그 버스 에러 속성이 "false"로 설정되면 ncWriteNet 또는 ncWriteNetMult가 에러를 반환합니다.
LIN은 또한 네트워크에 에러 리포트를 제공합니다. LIN 2.0 사양은 Response_Error 상태 비트를 정의하며, 즉 전송된 프레임 중 하나에서 슬레이브는 마스터에 리포팅해야 합니다.
이같은 비트는 슬레이브 노드에 의해 송수신된 프레임이 응답 필드에 에러를 포함할 때마다 설정됩니다. 비트는 슬레이브의 출판된 응답으로 전송된 후에 제거됩니다. LIN용 NI-CAN Frame API는 Response_Error 상태 비트를 원시 지원하지 않지만 어플리케이션 레벨에서 본 기능을 편리하게 실행할 수 있는 수단을 사용자에게 제공합니다.
과정은 읽기 큐에서 버스 에러 프레임의 로깅을 활성화하기 위해 1과 동일한 로그 버스 에러 속성을 설정합니다. 그 다음 어플리케이션은 응답에서 에러를 알리는 에러 코드가 있는 버스 에러 프레임의 읽기를 모니터링합니다.
본 조건에서 어플리케이션은 로컬 변수에서 Response_Error 상태 비트를 설정합니다. 그리고 어플리케이션은 NI LIN 응답 엔트리 프레임 유형을 사용하여 슬레이브 응답 큐를 Response_Error 상태 비트를 포함한 데이터로 업데이트하며 그 후 로컬 변수에서 비트를 제거합니다.
LIN 슬립(sleep) 및 웨이크업(wakeup)
LIN은 디바이스가 슬립 상태를 입력하여 잠재적으로 에너지를 보존할 수 있도록 하는 매커니즘을 갖추고 있습니다. LIN 2.0 사양에서, 모든 슬레이브는 첫 번째 데이터 바이트가 0과 동일한 진단 마스터 요청 프레임 (ID=60)을 보내는 마스터에 의해 슬립 모드로 강제 전환됩니다. 이같은 특수 프레임은 go-to-sleep 명령입니다.
또한 슬레이브는 LIN이 4초 이상 비활성인 경우 자동 슬립 모드에 들어갑니다. LIN용 NI-CAN Frame API는 사용자가 어플리케이션 레벨에서 원하는 대로 LIN 인터페이스를 슬립으로 설정하여 우수한 유연성을 제공합니다. 슬립 요청 메시지를 포함한 풀 프레임 또는 버스의 4초 비활동을 알리는 버스 비활성 프레임을 수신하면 사용자는 LIN Sleep 속성을 TRUE에 맞춰 LIN 인터페이스를 슬립으로 설정하도록 선택할 수 있습니다.
또한 LIN은 버스에서 디바이스를 활성화하기 위한 매커니즘도 제공합니다. Wakeup은 버스의 모든 노드 (슬레이브 뿐만 아니라 마스터) 에 의해 시작될 수 있는 태스크입니다. LIN 2.0 사양에 따르면 웨이크업 요청은 250 µs에 대한 버스 우성을 5 ms로 강제 전환하여 진행됩니다.
각 슬레이브는 활성화 요청을 감지해야 하며 100 ms내에 헤더를 처리할 준비를 해야 합니다. 또한 마스터는 활성화 요청을 감지해야 하고, 슬레이브 노드가 준비되었을 때 헤더 전송을 시작합니다. (활성화 요청을 수신한 후 100 ~ 150 ms 이내) 마스터가 첫 번째 활성화 요청을 수신한 후 150 ms 내에 헤더를 발송하지 않으면, 그 후 활성화를 요청한 슬레이브는 두 번째 활성화 요청을 시도할 것입니다. (그리고 또 다른 150 ms를 대기합니다.)
마스터가 여전히 응답하지 않으면, 슬레이브는 활성화 요청을 발송하고 3번째로 150 ms를 기다립니다. 여전히 응답이 없다면, 슬레이브는 4번째 활성화 요청을 보내기 전에 반드시 1.5초를 기다려야 합니다. LIN용 NI-CAN Frame API는 LIN 인터페이스가 마스터 또는 슬레이브로 작동하는지에 상관없이 LIN 2.0 사양에 따라 활성화가 수행되도록 허용합니다.
고급 프레임 유형
LIN 2.0 사양은 LIN 프레임을 6가지 유형으로 분류합니다.
- 무조건적
- 이벤트 트리거
- 산발적
- 진단
- 사용자 정의됨
- 확보됨
이같이 프레임 유형에 차이가 있는 것은 전송되는 타이밍이나 데이터 바이트의 내용 때문이라는 것을 이해해야 합니다.
프레임 분류와 무관하게, 풀 LIN 프레임은 항상 마스터 태스크가 전송한 헤더 및 슬레이브 태스크에 의해 전송된 응답으로 구성됩니다. LIN용 NI-CAN Frame API는 각 LIN 정의된 프레임 유형을 처리하기 위한 요구사항을 해결합니다.
무조건 프레임 유형은 가장 보편적으로 사용됩니다. 무조건 프레임은 신호 (데이터)를 전달하며, 식별자는 0~59 범위에 있습니다.
이벤트 트리거링된 프레임 유형은 하나의 프레임 슬롯 시간 내에서 여러 슬레이브로부터의 무조건적 프레임 응답을 요청함으로써 버스 대역폭을 보존하고자 합니다.
이벤트 트리거링된 프레임 유형은 하나의 프레임 슬롯 시간 내에서 여러 슬레이브로부터의 무조건적 프레임 응답을 요청함으로써 버스 대역폭을 보존하고자 합니다.
이벤트 트리거링된 프레임은 0~59 범위의 ID를 가질 수 있습니다. 이벤트 트리거링된 헤더 ID에 대해 잠재적으로 응답하게 될 각 슬레이브에는 마스터가 무조건적 프레임을 위해 쿼리를 한다면 응답하게 될 보호된 ID를 통해 로딩된 첫 번째 데이터 바이트를 가집니다. 이벤트 트리거링된 프레임은 다음과 같이 작동합니다.
마스터는 헤더에서 이벤트 트리거링된 ID를 작성합니다. 슬레이브는 데이터가 업데이트되었다면 이벤트 트리거링된 ID에만 응답할 수도 있습니다.
단 하나의 슬레이브가 응답을 출판한다면 그 후 마스터는 이를 수신하고 첫 번째 데이터 바이트를 확인하여 어떤 슬레이브에서 수신되었는지 (보호된 ID를 통해) 알게됩니다. 여러 개의 슬레이브가 응답을 출판하면 충돌이 발생하며, 마스터 디바이스 슬레이브 태스크는 이를 버스 에러로 리포팅합니다. 마스터 디바이스는 그 후 무조건 프레임을 사용하여 각 슬레이브로부터 응답을 쿼리합니다.
산발적 프레임은 LIN에 대해 동적인 동작을 제공합니다. 본 프레임은 항상 0~59의 신호 (데이터)를 운반합니다. 산발적 프레임의 헤더는 마스터 태스크가 프레임 내의 데이터 값 (신호)이 업데이트 되었음을 알 때에만 프레임 슬롯으로 보내집니다. 이같은 조건을 통해 마스터 디바이스 슬레이브 태스크는 산발적 프레임 응답의 정상 출판자가 됩니다.
진단 프레임의 길이는 항상 8 데이터 바이트이며, 항상 진단 또는 구성 데이터를 운반합니다.
ID는 마스터 요청 프레임의 경우 60, 슬레이브 응답 프레임의 경우 61입니다. ID 62를 가진 사용자 정의된 프레임은 정보의 모든 유형을 운반할 수 있습니다. 확보된 프레임은 ID 63을 가지며 LIN 2.0 클러스터에서 사용되어서는 안됩니다.
권장 PC LIN 인터페이스
그림 4. NI USB-8476 LIN 인터페이스
NI USB-8476 LIN 인터페이스를 사용하여 LIN 디바이스와 통신할 수 있습니다.
'데이터계측분석 > 데이터통신 기술자료' 카테고리의 다른 글
| 데이터통신을 위한 적합한 네트워킹 프로토콜 선정방법 (0) | 2023.02.28 |
|---|---|
| LabVIEW에서 OPC 사용하기 (0) | 2023.02.22 |
| NI X-NET을 이용한 CAN통신 이해하기 (0) | 2023.02.10 |
| 랩뷰를 이용한 모드버스 통신 (0) | 2023.02.09 |
| 랩뷰를 이용한 제어 및 모니터링 어플리케이션의 네트워크 통신 (0) | 2023.02.09 |