AUTOSAR CAN 통신 Stack 개요

Network Dependent Blocks for Com Stack - CAN

CAN 통신 스택은 AUTOSAR에서 CAN 버스를 활용한 차량 통신 시스템 모듈 그룹이다. 이는 애플리케이션에서 프로토콜 및 메시지 속성을 숨기는 것과 함께 CAN 네트워크에 대한 균일한 Interface를 제공한다. Low Level은 통신 스택에서 처리되며, CAN 통신 스택은 표준 CAN 및 CAN FD(하드웨어에서 지원하는 경우)을 지원한다.

위의 불록도는 AUTOSAR 의 CAN 통신과 관련된 세부 레이어를 간략하게 보여주고 있다. 다만 해당 블록도가 전부는 아니다. 이 블록도에서는 통신 서비스, 통신 하드웨어 추상화, 통신 드라이버만 고려하고 있다. 

1. CAN NM: CAN Network Manager, CAN 종속 모듈이긴 하지만, HW에 대해서는 독립적인 모듈이다. 주요 목적은 CAN 네트워크의 서로 다른 모드(Bus Sleep mode 및 Normal mode) 사이를 조정하는 것이다. 이 외에도 모든 현재 노드를 감지하거나 모든 노드가 절전 모드인지 확인하는 서비스 구현과 같은 기능을 제공한다. CAN NM은 Nm(Network Manager)와 CanIf(Can Interface) 간의 계층을 제공한다. CAN NM은 Network mode, Bus Sleep Ready mode 및 Bus Sleep mode의 3가지 모드로 구성된다. 

 

2. CAN SM: CAN Sate Manager, CanSM은 네트워크의 모드를 변경하는데 사용한다. ECU에는 여러 통신 네트워크/ 버스가 있을 수 있으며 각 네트워크에는 연결된 고유의 네트워크 핸들이 있다. ComM 모듈은 이러한 네트워크 핸들에서 요청하여 네트워크의 통신 모드를 추적한다. ComM은 구성을 통해 어떤 핸들이 CAN, FlexRay 또는 기타 네트워크 유형에 할당되어있는지 알고 있다. CAN의 경우에는 ComM은 CanSM을 사용하여 CAN 네트워트 모드를 요청한다. CanSM 모듈은 AUTOSAR에서 CAN 네트워크 흐름 추상화를 제어하는 역할을 한다. ComM 모듈에서 보낸 요청에 따라 CAN 네크워크의 모드를 변경한다. CanSM은 CanIf의 API를 사용한다. 모듈에서 CAN Controller 또는 CAN Transceiver의 모든 모드 변경은 CanIf에 의해 CanSM에 통보된다. CanSM 모듈이 구성된 각 CAN 네트워크에 대해 구현해야 하는 CAN 네트워크 State Machine의 알람 및 상태에 따라 CanSM이 ComM에 알린다. 

 

3. CAN TP: 전송 또는 수신해야 하는 PDU(메시지)가 지원되는 CAN 메시지의 최대 크기를 초과하는 경우가 많다. 이러한 CAN의 문제점과 한계를 해결하기 위해 AUTOSAR는 CanTp 블록을 구현한다. 단일 CAN 프레임에 맞지 않는 메시지는 각각 단일 CAN 프레임에서 전송될 수 있도록 여러 부분으로 분할됩니다. 이 블록은 CAN의 최대 허용 크기보다 큰 I-PDU의 분할을 수행하는 서비스를 제공합니다. 이 블록은 또한 수신된 PDU를 재조립하는 서비스를 제공하며, 이 PDU는 Signal을 압축 해제하여 Application 계층으로 전송된다. CanTp에는 분할 오류를 감지하는 서비스도 있다. CAN의 표준인 ISO 15765, PduR은 PDU의 크기를 고려하여 이 모듈의 사용 여부를 결정하는데, PDU가 단일  CAN 프레임에 맞으면 CanTP 모듈 대신 다음 모듈로 직접 전달하거나 PDU가 단일 CAN 프레임에 맞지 않으면 그런 다음 해당 PDU는 CanTp를 통과한 다음 하위 계층으로 이동하다. PDU를 수신할 때도 동일한 메커니즘을 따른다. 

 

4. CAN IF: 상위 통신 계층에 대한 CAN 드라이버 서비스에 대한 인터페이스를 나타낸다. ECU 하드웨어 레이아웃에 따라 CAN Controller 및 CAN Transeiver와 같은 다양한 하드웨어 장치를 관리할 수 있는 고유한 인터페이스를 제공한다. 따라서 여러 개의 내/ 외부의 CAN Controller/ CAN Transeiver를 CanSM을 통해 균일하게 제어할 수 있다. CanSM에서 CAN Controller의 상태 전환을 제어하고 상위 계층에 그 변경 사항을 알린다. CAN 인터페이스 모듈은 ECU의 CAN 통신 디바이스 드라이버에 속하는 모든 HW 독립적인 작업으로 구성된다. 이러한 작업은 CAN 인터페이스 모듈에서 한 번만 구현되므로 기본 CAN 디바이스 드라이버는 해당 특정 CAN HW 디바이스의 Access 및 Control에만 집중할 수 있다. CanIf는 PDU 라우터 및 상위 계층 통신 모듈의 주요 제어 및 데이터 흐름, 요구사항을 충족한다. 전송 요청 처리, 전송 확인/ 수신 표시/ 오류 알림, CAN Controller의 시작/정지 및 네트워크에서 깨어나거나 다시 진입하는 것과 같은 다양한 요구사항이 이에 해당한다. 

 

5. CAN Transceiver Driver : MCU에 On-chip Transceiver가 없는 경우에 일반적으로 ECU On-board된 외부 Transceiver를 사용한다. 이 블록은 이와 같은 외부 On-board CAN Transceiver IC를 위한 드라이버를 제공한다. SPI로 통신하는 IC를 지원한다. 

 

6. Driver for external CAN ASIC: 이름에서 알 수 있듯이 CAN application별 ASIC용 드라이버를 제공한다. 표준 CAN Transceiver IC가 application에 적합하지 않은 경우에는 이 블럭이 유용할 수 있다. 

 

 

상위 계층에서 하위 계층까지의 간단한 CAN signal의 여정

위 그림은 CAN Signal이 전송 준비가 된 Message가 되기까지 과정을 매우 단순화한 도표이다. Signal은 Application layer에서 생성되어 RTE를 통해 COM으로 전송되며, 여기서 Signal oriented Interface로 넘어간다. 이 아래 계층은 Signal level로 구분할 수 없으며 PDU 형태만 이해하게 된다. 따라서 COM은 Signal을 PDU로 packing해서 PduR로 전송한다. 그런 다음 PduR은 이를 CanTP로 전송하는데, 이 경우 PDU가 CAN 프레임의 최대 허용 크기보다 크다고 가정하면 여러 개의 PDU로 분할하게 된다. 또한 각 계층마다 PDU의 이름이 변경되는데 이는 다른 포스팅에서 언급하겠다. 이렇게 Can Driver까지 내려가게 되면 이제 HW에서 해당 Message를 네트워크로 전송하게 된다.