LIN 버스 프로토콜의 개요

Local Interconnect Network (LIN) 버스와 Controller Area Network (CAN) 버스는 자동차 및 산업 시스템에서 일반적으로 사용되는 통신 프로토콜입니다. LIN과 CAN은 비슷한 목적을 수행하지만, 아키텍처와 기능에 눈에 띄는 차이점이 있습니다. 

LIN은 자동차 네트워크에서 저가, 로우엔드 멀티플렉스 통신을 위한 표준을 만들기 위해 개발되었습니다. CAN은 고대역폭, 고급 에러 핸들링 네트워크의 필요를 해결하지만, 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에서는 메시지 처리 스펙 및 서비스가 추가되었지만, 바이트 레벨에서는 LIN 1.3과 호환됩니다. 

¹이 기능은 API에서 기본적으로 지원되지 않습니다. 그러나 이 기능을 구현할 수 있습니다. 

^{표 1: LIN 버전 1.3, 2.0 및 2.1의 비교}

LIN 버스는 하나의 마스터 디바이스와 하나 이상의 슬레이브 디바이스가 있는 폴 버스입니다. 마스터 디바이스에는 마스터 태스크와 슬레이브 태스크가 모두 포함되어 있습니다. 각 슬레이브 디바이스는 오직 하나의 슬레이브 태스크만 포함합니다. LIN 버스를 통한 통신은 마스터 디바이스의 마스터 태스크에 의해 전적으로 컨트롤됩니다. LIN 버스의 기본 전송 단위는 헤더와 응답으로 나누어진 프레임입니다. 헤더는 항상 마스터 노드에 의해 전송되며 브레이크, 동기화(Sync), 식별자(ID)라는 세 가지 필드로 구성됩니다. 슬레이브 태스크가 전송하고 마스터 노드 또는 슬레이브 노드에 있을 수 있는 응답은 데이터 페이로드와 체크섬으로 구성됩니다. 

일반적으로 마스터 태스크는 브레이크 동기화 ID 시퀀스로 구성된 헤더를 전송하여 루프의 각 슬레이브 태스크를 폴링합니다. LIN을 시작하기 전에, 각 슬레이브 태스크는 버스에 데이터를 공개하거나 받는 각 헤더 ID에 따라 데이터를 구독하도록 설정됩니다. 헤더를 받으면, 각 슬레이브 태스크는 ID 패리티를 확인한 다음 ID를 확인하여 공개할 필요가 있는지 아니면 구독할 필요가 있는지 결정합니다. 슬레이브 태스크가 응답을 공개해야 하는 경우, 버스에 1 ~ 8개의 데이터 바이트를 전송한 후 체크섬 바이트를 전송합니다. 슬레이브 태스크가 구독해야 하는 경우, 버스에서 데이터 페이로드와 체크섬 바이트를 읽고 적절한 내부 조치를 취합니다. 

표준 슬레이브 대 마스터 통신의 경우, 마스터는 네트워크에 식별자를 전송하며, 하나의 슬레이브만 데이터 페이로드로 응답합니다.

마스터 대 슬레이브 통신은 마스터 노드의 별도의 슬레이브 태스크로 이루어집니다. 이 태스크는 버스에 공개된 모든 데이터를 자체적으로 받고 독립적인 슬레이브 노드처럼 응답합니다. 데이터 바이트를 전송하려면, 마스터는 먼저 전송하려는 데이터 값으로 내부 슬레이브 태스크의 응답을 업데이트해야 합니다. 그 후 마스터는 적절한 프레임 헤더를 공개하고, 내부 슬레이브 태스크는 데이터 페이로드를 버스에 전달합니다.

^{그림 2: LIN 메시지 프레임}

1. 휴식

모든 LIN 프레임은 브레이크로 시작하며, 브레이크는 13개의 도미넌트 비트 (공칭)로 구성되고, 그 뒤에는 1비트 (공칭) 리세시브의 브레이크 구분자가 따라옵니다. 이렇게 하면 버스의 모든 노드에 프레임 시작 알림이 됩니다.

2. 동기화

동기화 필드는 헤더에서 마스터 태스크가 전달하는 두번째 필드입니다. 동기화는 x55 문자로 정의됩니다. 동기화 필드를 사용하면 자동 보 전송속도 감지를 수행하는 슬레이브 디바이스가 보 전송속도의 주기를 측정하고 내부 보 전송속도를 조정하여 버스와 동기화할 수 있습니다.

3. ID

ID 필드는 헤더에서 마스터 태스크가 전달하는 마지막 필드입니다. 이 필드는 네트워크의 각 메시지에 대한 식별을 제공하며, 최종적으로 네트워크의 어떤 노드가 각 전송을 받거나 응답하는지 결정합니다. 모든 슬레이브 태스크는 연속적으로 ID 필드를 듣고, 패리티를 확인하고, 이 특정 식별자의 발신자인지 아니면 구독자인지를 결정합니다. LIN 버스는 총 64개의 ID를 제공합니다. ID 0 ~ 59는 신호 전달(데이터) 프레임에 사용되며, 60과 61은 진단 데이터를 전달하는데 사용되며, 62는 사용자 정의 확장용으로 예약되며, 63은 향후 프로토콜 개선을 위해 예약됩니다. ID는 버스를 통해 하나의 보호된 ID 바이트로 전송되며, 하위 6비트는 원시 ID를 포함하고 상위 2비트는 패리티를 포함합니다.

^{표 2: 패리티 계산 방법}

4. 데이터 바이트

데이터 바이트 필드는 응답의 슬레이브 태스크에 의해 전송됩니다. 이 필드는 1 ~ 8 바이트의 페이로드 데이터 바이트를 포함합니다. 

5. 체크섬

체크섬 필드는 응답의 슬레이브 태스크에 의해 전송됩니다. LIN 버스는 두 개의 체크섬 알고리즘 중 하나를 사용하여 8비트 체크섬 필드의 값을 계산하는 방법을 정의합니다. 클래식 체크섬은 데이터 바이트만을 합하여 계산되고, 강화된 체크섬은 데이터 바이트와 보호된 ID를 합하여 계산됩니다.

LIN 2.0 스펙은 체크섬 계산 과정을 모든 값의 합계와 합계가 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 버스가 폴 버스이기 때문에, 각 프레임의 처리에 다음과 같이 공칭 시간 슬롯이 할당됩니다:

THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
각 프레임의 처리에 다음과 같이 최대 시간 슬롯이 할당됩니다:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

LIN 버스는 단일 마스터 디바이스(노드)와 하나 이상의 슬레이브 디바이스(노드)를 LIN 클러스터에 연결합니다. 각 노드의 동작은 각 노드의 기능 파일에 의해 설명됩니다. 노드 기능 파일은 전체 클러스터의 동작을 설명하는 LIN 설명 파일(LDF)을 생성하는 시스템 정의 도구의 입력입니다. LDF는 시스템 생성기로 분석되어 원하는 노드에서 자동으로 지정된 동작을 생성합니다. 이 때 마스터 노드 마스터 태스크는 버스에서 헤더를 전송하기 시작하고, 클러스터의 모든 슬레이브 태스크(마스터 노드의 자체 슬레이브 태스크 포함)는 LDF에 지정된 대로 응답합니다.

일반적으로, LDF는 LIN 클러스터의 스케줄링 동작을 설정하고 생성하는데 사용됩니다. 예를 들어, 보 전송 속도, 마스터 태스크의 헤더 전송의 순서 및 시간 지연, 각 슬레이브 태스크의 응답 동작을 정의합니다. NI LIN 하드웨어와 NI-CAN Frame API for LIN은 기본적으로 LDF에 대한 전체 지원을 제공하지 않으므로 스케줄링 동작을 하드웨어에 다운로드할 수 없습니다. 그러나 버스 접근(헤더 쓰기 및 응답 공개 또는 구독)의 하위 레벨 지원은 사용자가 어플리케이션 레벨에서 이러한 스케줄링 동작을 생성할 수 있도록 제공됩니다. NI LIN 응답 프레임 입력 타입에 대한 설명에서 설명한 것처럼, NI LIN 하드웨어는 슬레이브 태스크 응답을 저장하는 응답 큐를 제공합니다. 응답 큐는 LIN에 지정된 최대 ID 개수의 각각에 대해 하나씩 64개의 응답을 포함합니다. 이렇게 하면 LIN 인터페이스 슬레이브 태스크가 LIN 스펙에 의해 정의된 응답 시간 내에 헤더에 응답할 수 있습니다.

NI-CAN Frame API for LIN은 LIN 버스와의 완벽한 하위 레벨 상호작용을 위한 강력한 방법을 제공합니다. 이를 통해 최종 사용자는 LIN 네트워크의 분석 및 프로토타이핑과 관련된 복잡한 어플리케이션을 개발할 수 있는 기본 기능을 제공합니다. NI-CAN Frame API for LIN은 LIN 진단 또는 구성, LDF 또는 스케줄 테이블을 기본적으로 지원하지 않습니다. 그러나, NI-CAN Frame API for LIN을 사용하는 어플리케이션에서 이러한 작업을 구현할 수 있습니다.

LIN 2.0 스펙은 슬레이브 태스크가 에러 감지를 처리해야 하며, 마스터 태스크가 에러를 모니터링할 필요가 없습니다. LIN 2.0 스펙은 하나의 LIN 프레임 내에서 여러 에러를 처리하거나 에러 카운터를 사용할 필요가 없습니다. 프레임에서 첫 번째 에러가 발생하면, 슬레이브 태스크는 다음 브레이크 동기화 시퀀스(마스터가 전송하는 다음 헤더에서)를 감지할 때까지 프레임의 처리를 강제 종료합니다. 로그 버스 에러 속성이 참으로 설정된 경우, 버스 에러 프레임이 읽기 큐에 로그됩니다. 로그 버스 에러 속성이 거짓으로 설정된 경우, ncWriteNet 또는 ncWriteNetMult가 에러를 반환합니다. 

또한 LIN은 네트워크에 에러 리포트를 제공합니다. LIN 2.0 스펙은 응답_에러 상태 비트를 정의하며, 슬레이브는 전송된 프레임 중 하나에서 마스터에 보고해야 합니다. 이 비트는 슬레이브 노드가 받은 또는 전송한 프레임이 응답 필드에 에러를 포함할 때마다 설정됩니다. 비트는 슬레이브의 공개된 응답 중 하나에서 전송된 후 삭제됩니다. NI-CAN Frame API for LIN은 기본적으로 Response_Error 상태 비트를 지원하지 않지만 최종 사용자에게 어플리케이션 레벨에서 이 기능을 쉽게 구현할 수 있는 수단을 제공합니다. 이 과정은 로그 버스 에러 속성을 1과 같게 설정하여 읽기 큐에서 버스 에러 프레임의 로깅을 활성화합니다. 그 후 어플리케이션은 응답에서 에러를 나타내는 에러 코드로 버스 에러 프레임의 읽기를 모니터할 수 있습니다. 이러한 조건에서 어플리케이션은 로컬 변수에서 응답_에러 상태 비트를 설정할 수 있습니다. 그 후 어플리케이션은 NI LIN 응답 프레임 입력 타입을 사용하여 슬레이브 응답 큐를 응답_에러 상태 비트를 포함하는 데이터로 업데이트한 후 로컬 변수의 비트를 지울 수 있습니다.

LIN은 디바이스가 휴면 상태로 들어가서 전력을 절약할 수 있는 메커니즘을 제공합니다. LIN 2.0 스펙에 따르면, 첫번째 데이터 바이트가 0인 진단 마스터 요청 프레임(ID=60)을 보내면 모든 슬레이브가 휴면 모드로 강제 변환될 수 있습니다. 이 특수 프레임을 go-to-sleep 명령이라고 합니다. 또한 LIN이 4초 이상 비활성화되어 있는 경우 슬레이브는 자동으로 휴면 모드로 전환됩니다. NI-CAN Frame API for LIN은 사용자가 원하는 대로 어플리케이션 레벨에서 LIN 인터페이스를 작동시킬 수 있기 때문에 유연성을 높입니다. 휴면 요청 메시지를 포함하는 전체 프레임을 받거나 버스가 4초 동안 비활성화되었음을 나타내는 버스 비활성화 프레임을 받으면, LIN 휴면 속성을 참으로 설정하여 LIN 인터페이스가 휴면 상태가 되도록 선택할 수 있습니다.

또한 LIN은 버스에서 디바이스를 깨우기 위한 메커니즘을 제공합니다. 휴면 해제는 버스의 모든 노드(마스터뿐만 아니라 슬레이브)가 시작할 수 있는 태스크입니다. LIN 2.0 스펙에 따라, 버스가 250 μs ~ 5 ms 동안 정지하도록 하여 휴면 준비 요청을 수행합니다. 각 슬레이브는 휴면 해제 요청을 감지하고 100 ms 이내에 헤더를 처리할 준비가 되어 있어야 합니다. 마스터는 또한 휴면 해제 요청을 감지하고 슬레이브 노드가 준비되면 헤더를 보내기 시작해야 합니다(활성화 요청을 받은 후 100 ms ~ 150 ms 이내). 마스터가 첫 번째 휴면 해제 요청을 받은 후 150 ms 이내에 헤더를 보내지 않는 경우, 휴면 해제 요청하는 슬레이브는 두 번째 휴면 해제 요청을 보내려고 시도할 수 있습니다(다음 150 ms를 기다립니다). 마스터가 여전히 응답하지 않는 경우, 슬레이브는 활성화 요청을 하고 세 번째로 150 ms를 기다릴 수 있습니다. 여전히 응답이 없는 경우, 슬레이브는 반드시 1.5초 동안 기다려서 네 번째 휴면 준비 요청을 시작해야 합니다. NI-CAN Frame API for LIN을 사용하면 LIN 인터페이스가 마스터 또는 슬레이브로 작동하는지 여부에 관계없이 LIN 2.0 사양에 따라 실행할 수 있습니다.

LIN 2.0 스펙은 LIN 프레임을 다음의 6가지 타입으로 분류합니다.

1. 조건없음
2. 트리거된 이벤트
3. 분기적
4. 진단
5. 사용자 정의
6. 예약됨

이러한 프레임 타입의 차이점은 전송 방법의 타이밍 또는 데이터 바이트의 내용 때문이라는 점에 주의해야 합니다. 프레임 분류와 상관없이, 전체 LIN 프레임은 항상 마스터 태스크가 전송하는 헤더와 슬레이브 태스크가 전송하는 응답으로 구성됩니다. LIN용 NI-CAN 프레임 API는 각각의 LIN에 지정된 프레임 유형을 처리할 필요를 해결할 수 있습니다. 가장 일반적으로 사용되는 것은 조건없는 프레임 타입입니다. 조건없는 프레임은 신호(데이터)를 전달하며, 해당 식별자는 0에서 59의 범위 내에 있습니다.

이벤트 트리거 프레임 타입은 하나의 프레임 슬롯 시간 내에 여러 슬레이브로부터 조건없는 프레임 응답을 요청하여 버스 대역폭을 절약하려고 시도합니다.

이벤트 트리거된 프레임의 ID 범위는 0에서 59입니다. 이벤트 트리거된 헤더 ID에 잠재적으로 응답할 수 있는 각 슬레이브는 마스터가 무조건 프레임을 쿼리하는 경우에 응답할 수 있는 보호된 ID로 첫 번째 데이터 바이트를 로드합니다. 이벤트 트리거 프레임은 다음과 같이 작동합니다. 마스터는 이벤트 트리거된 ID를 헤더에 씁니다. 슬레이브는 데이터가 업데이트된 경우에만 이벤트 트리거된 ID에 응답할 수 있습니다.

하나의 슬레이브만 응답을 공개하는 경우, 마스터는 응답을 받고 첫번째 데이터 바이트를 보면 어떤 슬레이브로부터 (보호된 ID를 통해) 응답을 받았는지 알 수 있습니다. 여러 슬레이브가 응답을 공개하는 경우, 충돌이 발생하며, 마스터 디바이스 슬레이브 태스크는 이를 버스 에러로 보고합니다. 그 후 마스터 디바이스는 조건없는 프레임을 사용하여 각 슬레이브의 응답을 쿼리합니다. 

분기적인 프레임은 LIN에 동적 동작을 제공하려고 시도합니다. 항상 신호(데이터)를 전달하며, ID 범위는 0에서 59입니다. 마스터 태스크가 프레임 내의 데이터 값(신호)이 업데이트되었음을 알고 있을 때, 분기적인 프레임의 헤더는 프레임 슬롯에만 전송되어야 합니다. 이 요구조건은 마스터 디바이스 슬레이브 태스크를 분기적인 프레임 응답의 일반적인 공개자로 만듭니다.

진단 프레임은 항상 8 바이트의 길이이며 항상 진단 또는 설정 데이터를 포함합니다. 마스터 요청 프레임의 ID는 60이고 슬레이브 응답 프레임의 ID는 61입니다. ID가 62인 사용자 정의 프레임은 모든 타입의 정보를 전달할 수 있습니다. 예약된 프레임의 ID는 63이며, LIN 2.0 클러스터에서는 사용할 수 없습니다.

NI-XNET LIN

NI-XNET 제품 라인은 가속화된 CAN(Controller Area Network), LIN(Local Interconnect Network), FlexRay 인터페이스, 최적화된 드라이버, 사용하기 쉬운 API, 설정 및 디버깅 유틸리티로 구성됩니다. NI-XNET 인터페이스를 사용하면 NI LabVIEW, LabVIEW Real-Time, C/C++에서 CAN, LIN, FlexRay 네트워크의 프로토타이핑, 시뮬레이션, 테스트를 위한 애플리케이션을 더 빠르고 쉽게 개발할 수 있습니다.

NI-XNET PCI/PXI 및 C 시리즈 LIN 인터페이스에는 통합 LDF 지원, 마스터 태스크의 하드웨어 타이밍에 의한 스케줄링, 프레임 및 신호 통신이 포함됩니다. 

^{그림 4: CAN, LIN 및 FlexRay를 위한 NI-XNET 플랫폼}

NI USB LIN

^{그림 5: NI USB-8506 LIN 인터페이스}

또한 USB LIN 인터페이스 디바이스를 사용하여 LIN 디바이스와 통신할 수 있습니다. 이는 LIN 네트워크와 통신하기 위한 저가 모바일 솔루션입니다.