AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조[출처] AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조

AUTOSAR CAN 통신 스택 : AUTOS.. : 네이버블로그 (naver.com)

AUTOSAR CAN 통신 스택 : AUTOSAR 개발을 위해 반드시 알아야하는 계층형 구조

 

AUTOSAR CAN 통신 스택: BSW 개발을 위해 반드시 알아야하는 계층형 구조

하드웨어에 독립적(#hardware-independent)인 #소프트웨어플랫폼 구축을 위해서 많은 플랫폼들이 #계층형구조 를 도입하여 하위에는 하드웨어 종속적인 모듈들을 배치하고 상위로 갈수록 하드웨어에 독립적인 구조가 될 수 있도록 계층과 모듈들을 구성합니다. #AUTOSAR 도 계층형 구조로 되어있어서 하드웨어에 독립적인 어플리케이션 작성이 가능하지만, 더 정확한 구현과 효과적인 디버깅을 위해서 내부의 계층을 잘 이해할 필요가 있습니다. 특히, #어플리케이션소프트웨어(#ASW)가 아니라 #베이직소프트웨어(#BSW)를 개발하는 입장이라면 계층 간 메시지 전달에 대해서 이해하는 것은 꼭 필요한 일이라고 할 수 있습니다. 

​

이 글에서는 AUTOSAR #CAN통신스택을 살펴보고 메시지 전달 과정과 #CAN통신과 관계된 모듈들을 알아보도록 하겠습니다.

 

통신DB import

통신 모듈들을 설정하기 위해서는 ARXML형태로 구성된 통신 데이터가 필요하기 때문에 모듈 설정에 앞서 ECU에서 사용할 통신 데이터를 import 하게 됩니다. 대부분의 AUTOSAR 솔루션들이 통신 DB를 간편하게 import해서 AUTOSAR 데이터 포맷으로 변환해주는 기능을 갖고 있습니다. 예를 들면 현대오트론에서 개발한 모빌진(mobilgene)도 ARXML파일뿐 아니라, CAN/LIN/Flexray/Ethernet등의 데이터베이스 혹은 엑셀 형식으로 저장된 파일을 drag-drop방식으로 끌어와서 간편하게 AUTOSAR ARXML 형태로 만들어 주는 기능을 제공할 뿐만 아니라, import한 데이터를 모듈들의 의존성을 고려해서 자동으로 설정해주는 기능까지 제공하고 있습니다. 다음 그림은 AUTOSAR 협회 사이트에 공개된 현대오트론 모빌진(mobilgene)의 CAN 관련 설명이니 참고하시기 바랍니다.

​

[그림 1] 현대오트론 mobilgene의 Import Network Design 방법(출처: 현대오트론)

​

[그림 2] 현대오트론 mobilgene의 CAN 통신 예시(출처: 현대오트론)

 

 

CAN 통신스택(Communication Stack)

다음 그림은 통신서비스 제공을 위해 AUTOSAR에서 정의하는 모듈들을 서로 다른 색으로 표현된 계층에(MCU 추상화 계층-빨간색, ECU 추상화 계층-초록색, 서비스 계층-파란색) 나누어 표현한 것으로 계층의 특성에 맞춰 통신 관련 모듈들이 분포되어 있는 것을 알 수 있습니다. 그림의 점선 부분은 적용되는 통신 버스에 따라서 LIN, FlexRay, J1939, XCP, CAN, Ethernet 등이 될 수 있습니다.

[그림 3] AUTOSAR에서 정의하는 모듈 계층

CAN 통신 스택은 기능/역할별로 다음의 세 가지 영역으로 나누어 볼 수 있겠습니다. 

​

1. PDU 송/수신 관련 기능

: CAN 메시지를 송수신 하는 과정에서 PDU 전달과 관련된 기능을 수행하는 모듈들을 포함하고 있습니다. 

2. 통신 상태 제어기능

: 통신 상태를 변경하거나, 이상이 발생했을 때 이에 대한 처리를 담당하는 모듈들을 포함합니다. 

3. 네트워크 관리 기능

: 통신 네트워크를 관리하기 위한 모듈들이 포함되어 있습니다. 

 

[그림 4] CAN 통신 스택의 세 가지 기능

이 글에서는 위에서 언급한 세 가지 중 PDU 송/수신에 관여되는 통신 관련 주요 모듈들을 살펴보고, 통신 스택을 구성하는 모듈 간 PDU 흐름을 살펴보도록 하겠습니다.

 

COM 모듈

통신 스택은 일반적인 CAN통신의 송/수신 기능에 관여하는 모듈들(다음 그림 참고: Com, PduR, CanIf, CAN)로 구성됩니다. COM 모듈을 기점으로 상위 layer는 signal을 사용하고, 하위로는 PDU를 사용합니다. Signal은 전달할 메시지, PDU는 계층 간 메시지 전송을 위한 프로토콜 추상화로 생각할 수 있습니다. 어플리케이션에서 전달된 signal 은, COM의 I-PDU 버퍼에 저장되고 PduR_ComTransmit 함수에 의해서 I-PDU 형태로 PduR로 전달됩니다. 반대로 PDU를 수신 받을 때는 PduR에서 Com_RxIndication 함수를 통해서 수신된 PDU가 있음을 알리고, COM에서는 I-PDU 속 signal을 분석해서 해당 signal과 연결된 callback 함수를 호출하여 수신된 signal이 RTE를 통해서 어플리케이션으로 전달됩니다.

​

[그림 5] Signal/PDU 사이 변경을 위해서 COM 모듈에는 각 signal과 PDU가 정의되어 있는데, 간혹 참조 관계가 틀렸거나 존재하지 않는 경우가 있습니다. AUTOSAR BSW 개발 소프트웨어 DB import 시 자동으로 설정해 줘야 하지만, import과정에서 type 설정을 잘못했거나, 혹은 의존관계 모듈의 버전 문제 등 여러 가지 원인으로 정상적인 설정이 안되는 경우가 있습니다. 이런 경우 직접 확인해서 해당 문제를 수정해 줘야 합니다.

 

 

PDU(Protocol Data Unit)

통신 메세지는 네트워크 계층 간 정보 전달의 편의를 위해서 PDU로 바뀌는데 SDU(Service Data Unit)와 PCI(Protocol Control Information)로 구성됩니다. SDU는 다른 계층 또는 모듈로 전달되는 데이터이고, PCI는 발신지/수신지/순서 번호와 같은 정보들로 계층 간 혹은 모듈 간 PDU 전달을 위해 덧붙이는 정보를 말합니다. 예를 들어 COM에서 전달받은 PDU는 PduR에서는 SDU가 되고, 라우팅 정보가 포함된 PCI가 더해져서 새로운 PDU를 구성하게 됩니다. 아래 그림은 다음 계층의 PCI 정보가 덧붙여 지면서 PDU가 계층 간 전달되는 것을 설명하고 있습니다.

 

​	​
[그림 6] 이렇게 하위 계층으로 이동하면서 PDU는 상위계층에서 만들어진 SDU와 PCI를 헤더에 붙여가는 방식으로 PDU가 지나온 전체 경로를 기억하게 됩니다.	[그림 7] 계층별로 주고받는 정보가 다르기 때문에 다음 그림처럼 계층에 따라 PDU에 붙는 prefix도 달라집니다.

PDU는 AUTOSAR의 CAN 스택 내에서만 사용되는 것이기 때문에 CAN Driver를 통해서실제 전송시에는 PDU형태로 전송되지 않고, 필요한 메시지만 PDU에서 추출하여 네트워크로 전송하게 됩니다.

 

PduR 모듈

COM에서 만들어진 PDU는 PduR(PDU Router)로 전달되어 Routing table을 참고해서 해당 PDU를 전달할 목적지를 설정하는 방식으로 PDU를 목적지로 전송하게 됩니다. PduR모듈은 routing table과 engine으로 구성되는데, Routing table은 각 PDU들의 경로 정보를 가지고 있어서, 여기에 기록되지 않은 PDU는 정상적으로 전달되지 않습니다. Engine은 routing table을 사용해서 PDU가 올바른 경로로 전달될 수 있도록 해주는데, 주요하게는 PDU가 위로 전달되는지 혹은 아래로 전달되는지에 따라서 PDU ID와 API를 연결하여 호출해 주는 기능입니다.

[그림 8] PduR 모듈

PduR의 Gateway 기능을 통해서 서로 다른 Bus간 혹은 서로 다른 Controller간 PDU 송/수신도 가능합니다.

 

간혹 DB Import 과정에서 Multicast 설정이나 Gateway 설정에 해당하는 메시지가 정상적으로 세팅되지 못하거나 그 밖에 다양한 원인으로 PduR에 설정되어야 하는 Gateway가 설정되지 않는 경우가 있습니다. 코드생성 자체가 안되는 경우도 있고, 혹은 나중에 테스트 과정에서 해당 기능이 누락되는 경우도 있습니다. 특히, Gateway 설정이 정상적이지 않은 경우가 빈번합니다.

​

[그림 9] PduR을 기준으로 상위는 Bus나 Controller에 의존성이 없지만,

하위부터는 특정 Bus나 Controller에 의존성을 갖게 됩니다.

​

CanIf 모듈

CanIf 모듈에서는 PDU ID를 확인해서 내부의 Channel을 선택합니다. 각 Channel에 연결된 HOH(Hardware Object Handle)에 PDU를 전달하면, CAN controller의 Hardware Object에 해당 PDU를 write 하고, object flag 값을 1로 설정되면 Transceiver에 의해서 Can frame이 전달됩니다.

 

[그림 10] CanIf 모듈

​

지금까지 설명한 Can 통신 스택의 4가지 주요 모듈을 정리하면 다음과 같습니다. 

COM	- PDU data를 signal 단위로 읽고 쓸 수 있는 interface 제공 - 주기적으로 PDU 송신 - Signal에 대한 timeout, data received, data send 등의 이벤트를 ASW에 통지
PduR	- Routing table에 설정된 PDU reference를 참조하여 source 및 destination 모듈 간에 pdu를 전달
CanIF	- Can driver로부터 수신한 PDU를 상위 layer로 전달 - 상위 layer가 송신한 PDU를 can driver로 전달 - Can controller 및 transceiver를 제어하는 interface 제공 - Bus off 발생을 Can으로부터 받아 CanSM에 전달
CAN	- Can controller의 활성화 및 비활성화 제어 - Can interrupt handler를 제공(Tx, Rx, Busoff 등): interrupt 대신 주기 task를 이용한 Polling 방식도 사용 가능

 

마지막으로, 다음 그림은 CAN 메시지 송신 시 모듈 간 호출되는 API 및 Callback 함수를 정리한 것입니다. 함수명은 환경에 따라 다소 다를 수 있지만, 앞에서 살펴본 CAN 통신 스택의 함수 호출 예로 참고하시기 바랍니다. 

[그림 11] CAN 메시지 송신 시 모듈 간 호출되는 API 및 Callback 함수 정리

​

① RTE API를 통해서 전달할 signal이 COM에 도착하면 COM은 signal을 PDU로 변환하고, PduR로 해당 PDU를 전달하면서 전송 요청을 합니다. 

② PduR은 적절한 전송 모듈을(LIN, CAN, XCP등)을 선택해서 해당 모듈로 PDU를 보내서 전송 요청을 합니다. 

③ CanIf는 PDU ID를 확인해서 연결될 channel을 설정하고, 해당 채널을 통해서 Can driver의 HTH(Hardware Transmission Handle)로 전송하려는 메시지를 전달합니다. 

④ Can driver에서는 HTH에 연결된 Can controller의 Hardware Object에 전달할 메시지를 write하도록 합니다.