Infobank 연구소 Smart Car Group AUTOSAR팀의 채승엽, 박대영, 이우승, 이헌철 등이 AUTOSAR 최신 기술에 대한 아티클을 6회에 걸쳐 연재한다. 인포뱅크는 AUTOSAR 추세와 요구사항에 맞게 AUTOSAR Ethernet Solution, AUTOSAR 플랫폼 교육, SWC 개발 Tool과 같은 AUTOSAR 전반에 걸친 업무를 수행하고 있다. 제5회는 ‘AUTOSAR CAN’이다.

1. AUTOSAR의 실무 이해
2. AUTOSAR OS
3. AUTOSAR RTE
4. AUTOSAR MCAL
5. AUTOSAR CAN
6. AUTOSAR FlexRay

이번 회에서는 차량용 네트워크에서 사용되고 있는 CAN(Controller Area Network) 통신에 대해 알아보겠다. CAN 통신은 엔진 제어, 전동 파워 스티어링 등 차량의 많은 ECU에서 사용 중인 ISO 표준 시리얼 통신 규격(ISO 11898 등)이다. CAN 통신은 차량에 ECU 증가와 더불어 ECU 간 통신을 위해 전기 배선(Wire Harness)이 증가하게 돼 차량 중량 및 비용 문제가 발생하게 되면서 이를 감소시키기 위해 ECU 간 접속을 네트워크화하기 위해 개발됐다.
이러한 CAN 통신은 노이즈에 강한 차동 통신, 오류 검출 / 통지 / 복구 기능, 고장의 봉입 등으로 고신뢰성을 가지고 있으며, 노드(Node) 추가에 용이하다. 통신 속도 또한 실시간 제어가 가능한 1 Mbps 고속 통신을 제공한다. 하지만 속도의 경우 그림 1과 같이 버스 길이에 따라 전송속도가 달라진다. 그러므로 배선 길이에 대한 고려가 필요하며 일반적으로 CAN의 경우 40 M 이내일 경우 안정적인 속도를 보장한다.
CAN 노드의 경우, 자신의 고유 Message ID를 갖고 있으며 각 노드는 버스가 Idle 상태 일 때 데이터 전송이 가능하다(Multi Master). 만약 복수의 노드에서 동시에 버스에 데이터를 전송할 때 충돌이 발생할 수 있는데, 이 경우 Message ID를 통해 우선순위가 결정되며, 수신하는 노드에서는 Message ID를 확인해 수신 노드에 해당이 되면 저장(해당하지 않을 경우에는 무시함)하고 Ack 신호를 발생시킨다. CAN은 ID bit 길이에 따라 복수의 버전이 존재하며, 그림 2와 같이 표준 포맷의 경우 11 bit, 확장 포맷의 경우 29 bit로 이뤄져 있다. 이외 CAN에 대해 Frame / Error 처리 등에 대해서는 본 연재에서는 생략하고 AUTOSAR CAN에 대해 알아보도록 하겠다.


AUTOSAR에서의 CAN 통신

AUTOSAR를 적용해 CAN 설계에 대해 첫 연재에서 설명한 AUTOSAR Methodology를 기준으로 설명할 수 있다.
AUTOSAR Methodology는 그림 3과 같이 시스템 설계 단계, ECU 설정 단계, BSW Generator 단계로 구성돼 있으며 CAN을 구성하는 데 있어 1단계인 시스템 설계 단계에서는 여러 개의 ECU가 어떻게 통신을 할 것인지를 설계한다. 2단계인 ECU 설정 단계에서는 1개의 ECU에 대한 BSW를 선택하고 상세 설계를 한다. 마지막인 3단계에서는 1개의 ECU에 대해 각각 BSW가 2단계의 ECU 설정 값들을 기반으로 소스 코드가 생성된다. 하지만 소프트웨어 컴포넌트(SWC) 소스 코드와 BSW 중에 Service SWC에 대한 integration Code 영역 부분은 개발자가 소스 코드를 작성해줘야 한다. AUTOSAR Methodology에 대해 자세한 사항은 첫 연재 자료인 “1. AUTOSAR의 실무 이해”를 참고하길 바란다.


AUTOSAR에서 CAN Network 통신 절차에 대해 살펴보겠다. 그림 4에서 보는 것과 같이 CAN으로 데이터를 보낼 경우 SW-C에서 RTE, COM, PduR, CanIf를 거쳐 데이터를 전송하고, 이후 Can Driver에서 CAN Bus로 데이터를 전송하게 되고, 이렇게 전송된 데이터는 CAN Bus에 연결돼 있는 모든 ECU의 Can Driver에서 데이터를 수신하게 되며, 위에서 언급한 것과 같이 CAN ID(Message ID)를 확인해 수신해야 될 데이터이면 CanIf에서 PduR API(PduR_CanIfRxIndication)와 Com을 통해 SW-C로 전달하게 된다. 이러한 CAN 통신을 처리하기 위해서는 Schedule Function을 처리해줘야 되는데, AUTOSAR 3.X(AUTOSAR_SWS_BSW_Scheduler.pdf)에서는 SchM.c에서 처리했으나 AUTOSAR 4.X(AUTOSAR_SWS_RTE.pdf)에서는 Rte.c에서 처리하도록 변경이 됐다. 이 부분은 AUTOSAR 3.X에서 AUTOSAR 4.X의 차이점으로 작업 시 4.X에서 부족한 자료는 3.X의 “AUTOSAR_SWS_BSW_Scheduler.pdf” 파일을 참고해야 한다.


그림 4에서 RTE와 Can Hardware 간 송수신을 할 때 시스템 설계 단계에서는 3가지의 통신 단위로 구성이 돼 있는데, Signal / SignalGroup, PDU, Frame이다. Signal / SignalGroup은 SW-C에서 RTE와 Com에서 송수신하는 단위이다. Signal은 Primitive type의 데이터 변수를 전송 시 사용되며 Sender Receiver Interface 통신이다.


SignalGroup은 Complex type으로 구조체, 배열, 특정 함수를 호출할 때 사용된다. PDU는 Signal과 SignalGroup으로 구성되고, CanIf와 Can Driver 간에 송수신에 사용되며 CAN ID는 PDU 단위로 번호가 정해진다. 마지막 PDU를 묶어 Frame을 형성하게 된다. 그림 5에서 보는 것과 같이 Signal 쭻 PDU 쭻 Frame에 대한 연관 관계를 확인할 수 있다. Signal, PDU, Frame에 대한 연관 관계는 시스템 설계 단계에서 System Template에서 설정을 해주게 되며 System Template에서 설정한 정보는 ECUC Parameter 참조를 한다.


AUTOSAR CAN Stack에 대해 알아보면 4가지로 구분이 된다(그림 6).
1. Can: Can Driver(MCU 내부 Can)
2. CanTrcv: Can Transceiver Driver(외부 Chip)
3. CanSM:  ECU 내부 Can 통신 상태 제어
4. CanNM: ECU 간 Can 통신 상태 제어
CanTrcv는 Can의 디지털 신호를 통신 파형으로 변경해 Can 버스 통신을 지원하고, CanSM은 개발한 ECU가 Can 통신을 보낼 때 내부적으로 장애가 발생하지 않는지를 확인하는 역할을 한다.


CanNM은 ECU 간 통신을 하는데 개발한 ECU에 대해 고장이 나지 않았는지를 확인한다. 이런 CanSM과 CanNM에 대해 SW-C에서 제어를 할 때 ComM을 사용한다. SW-C가 데이터를 전송할 경우 ECU 내부 및 ECU 간 데이터를 보낼 수 있는지를 확인해야 하는데, 이 부분을 SW-C에서 개발해야 한다. CanSM, CanNM은 상태 값을 받아오기는 하지만 SW-C에서 자동으로 전달해 주진 않는다. 이와 같은 이유로 CanSM, CanNM 상위에 있는 Service SW-C인 ComM에 RTE와 port를 통해 SW-C에서 네트워크에 대한 상태를 알 수 있다.


이러한 ComM에서 지원되는 Communication Mode는 그림 7과 같이 COMM_FULL_COMMUNI CATION(송수신 가능), COMM_SILENT_ COMMUNI CATION(송신 불가 수신 가능), COMM_NO_ COMMUNICATION(송수신 불가)로 구성돼 있으며 ComM_GetCurrentCom Mode를 통해서는 CanSM / CanNM에 대한 현재 Communication Mode 값을 가져올 수 있고 ComM_GetRequestedComMode를 사용해 Communication Mode 값 변경 요청을 할 수 있다.
만약 ECU 간 통신 중에 특정 ECU에 대해서 통신이 불가한 상태가 되면, ComM_Get Current ComMode의 현재 상태를 가져와 불가 상태를 확인하고 ComM_GetRequested ComMode를 사용해 해당 ECU와 통신을 하지 않도록 설정해 불필요한 데이터 통신을 하지 않도록 할 수 있다.
 

AUTOSAR에서 CAN 시스템 설계

앞에서 AUTOSAR CAN에 대해 대략적으로 살펴보았다. 이제 시스템 설계 단계에서 CAN 통신을 하기 위해 Arxml을 설계하는 방법에 대해 살펴봤다.
그림 8은 Sender / Receiver interface를 사용해 ECU 간 통신으로 사용하기 위해 System Signal을 설정하고, 네트워크에 보내기 위해서 ISignal로 적용하고, ISignalIPdu은 ISignal로 구성하고, Frame는 ISignalIPdu으로 구성된다. 네트워크 설계를 하기 전 도식화된 컴포넌트에 대해 Artop을 통해 설계한 결과를 그림 9에서 확인할 수 있다. 설계된 내용을 간략하게 살펴보면, Application SWC인 Swc1에 InternalBehavior를 추가하고 함수(Runnable)인 F1을 생성했다. 이후 통신에 사용할 PPort를 추가해 Swc1에 대해 도식된 화면과 같이 구성을 완료한 것이다.


Composition SW-C를 생성해 Swc1에 대한 연결 관계를 설정한다.
위와 같이 설계된 CSW-C 파일을 가지고 시스템 설계를 진행해야 하는데, 우선 System Element를 추가한 후 그림 10과 같이 Root Sw Composition을 추가해 Composition SW-C와 Ecu Instance를 연결한다. 두 번째로 System Mapping을 추가해 Ecu와 SW-C를 Mapping하며 사용할 Ecu Instance와 H/W Element를 지정하게 된다. 만약 Ecu 내 통신을 하는 경우이면, SwcTo EcuMapping 까지만 설정해 주면 되지만 현재 우리는 ECU 간 통신을 하기 위한 설계를 진행 중이니 System Signal을 추가해 줘야 한다. ECU 간 통신을 하기 위해서 System Mapping의 Data Mappings에서 Signal Mapping을 추가해 줘야 되는데, 이 때 Swc1에 맞는 interface 항목으로 Mapping을 해주면 된다. Sender Receiver interface를 사용하므로 “Sender Receiver To Signal Mapping”을 추가(그림 10에 4번 항목)한다. 이제 추가된 S/R To Signal Mapping에 System Signal을 지정해 주면 된다. SenderReceiver ToSignalMapping의 Properties에 System Signal을 설정해 주는 부분이 있다. (그림 10 붉은 네모 박스) 이 부분을 설정해 주면 Mapping이 된 것이다. 이제 그림 8에 System Signal까지 설계가 됐다.


이제 Signal, PDU, Frame을 작성해 해 Mapping시켜줘야 하고, 설계 순서는 Signal → PDU → Frame 순으로 이뤄져야 한다. 각 항목에 대해 구성하게 되면 그림 11과 같이 설계가 이뤄지게 되는데 Element에서 ISignal을 추가해 위에서 작성했던 System Signal과 Mapping을 시켜줘야 한다.
그림 12에 1번은 그림 11 1번의 Properties 내용으로 위에서 설계한 System Signal에 ISignal에서 설정을 해주고 있다. 이렇게 ISignal를 설계한 후 2번과 같이 ISignalPdu를 추가해 1번에서 지정한 ISignal을 지정해 준다. 하나의 Pdu 안에는 여러 개의 Signal이 들어갈 수 있으며(그림 5 참조), 만약 여러 개의 ISignal을 추가해 줘야 되는 경우에는 그림 11에서 보는 것과 같이 ISignalToPdu Mapping을 Signal만큼 생성해 Mapping을 해줘야 한다. 하지만 현재 예제에서는 1개의 Signal로만 구성돼 있으므로 하나만 생성을 했다. 추가적으로 그림 12의 2번 항목에 보면 Start Position이 보일 것이다. 이 항목은 Pdu 안에서 Signal의 시작 위치를 지정하는 것으로, 만약 Signal이 두 개 있을 경우 Signal 1은 0부터 시작하고, Signal 2는 8부터 시작 하는 것으로 구성할 수 있다. 여기에서는 한 개의 Signal이므로 0이라 지정했다. 이제 Can Frame을 추가해 Pdu와 Mapping을 시켜줘야 한다(사용하는 통신에 따라 Lin Frame, FlexRay Frame을 추가하면 된다). Can Frame도 그림 12의 3번과 같이 2번에서 생성된 Pdu를 Pdu To Frame Mapping을 통해 설정하고 Start Position을 지정해 주어야 한다.


이제 차량 네트워크 통신을 하려면 Cluster와 EcuInstance에서 Connector를 추가해줘야 한다. Cluster는 Can의 속도, Type 등을 설정해 줄 수 있으며 모든 ECU는 Cluster를 경유해서 데이터를 주고받고, EcuInstance의 CanCommunicationConnector의 ISignal Port, IPduPort, FramePort 정보와 ISignal, ISignalPdu, CanFrame이 상호 간에 연결돼 있어야 한다. CanCommunication Connector는 통신의 송수신 방향을 결정할 수 있고 Connector 한 개당 Can Driver 1개라고 생각할 수 있다. Can Cluster에 신호를 보내기 위해 ISignal Triggerings, Pdu Triggerings, CanFrame Triggerings에 설계해야 하며, CanCluster에 Triggering를 추가하려면 CanClusterCon ditional을 추가해 줘야 되는데 ConCluster Conditional에서 속도를 지정한 후 Channel을 통해 상기 3가지의 Triggerings을 추가한다. ISignal Triggerings은 위에서 설계한 ISignal1을 연결하고, Pdu Triggerings은 ISignalIPud1, CanFrameTriggerings은 CanFrame을 연결한다. 자세한 것은 그림 13의 연관관계에서 볼 수 있다.


이제 CanCluster에 포트 정보를 입력해야 되는데, 이 부분은 EcuInstance에 있는 CanCommunicationConnector에서 생성을 한 후 설정해 줘야 한다. CanCommuni cationConnector 항목에 있는 Ecu Comm Port Instance에 보면 ISiganl Port, IPduPort, FramePort가 존재하는데, 각 항목에 대해 추가한 후 Communication Direction에서 해당 Port에 대해 송수신 값에 맞게 IN(수신)/OUT(송신)을 설정한다. 이렇게 설정한 Connector의 각 Port들은 그림 13에 있는 Triggering과 Mapping을 한다. 즉, ISignalTriggering1의 ISignal Ports 값에 EcuInstance의 CanCommunicationCon nector에 추가된 ISignalPort가 Mapping이 되는 것이다. Pdu Port와 Frame Port 역시 ISignal과 동일하게 각 Port를 지정해야 한다. 그림 14의 각 Triggering에 대한 Property 설정 값을 보여주고 있다. 각 Property를 살펴보면 Port 값의 경로에서 보는 것과 같이 EcuInstance와 연결돼 있는 것을 볼 수 있다. 이제 마지막으로 EcuInstance CanCom municationController를 추가해 주면 된다. CanCommunicationConnector는 통신에 대한 송수신 방향을 결정한다면 CanCommu nicationController는 차량 네트워크의 Controller 특징(Time Segment)을 결정한다고 볼 수 있다.
위와 같은 절차로 설계가 되면 한 개의 ECU에 대한 Arxml 파일이 생성(ECU Extract of System Description Arxml) 되고 1단계가 완료된다. 이후 2단계에서는 1단계에서 생성한 Arxml 파일을 가지고 Import해 BSW을 선정해서 Configuration하게 된다. 선택하는 BSW에 따라 Configuration이 다르기 때문에, 본 연제에서는 2단계 Configuration은 제외했다. 이렇게 2단계에서 생성되는 파일을 ECU Configuration Description Arxml이라 한다. 3단계에서는 앞에서 작업한 Arxml 파일을 가지고 코드를 생성하고 Service SW-C와 SW-C에 대해 코딩 작업을 진행하면 된다.
시스템 설계 예제를 진행해 보았듯이 한 개 Signal에 대해서만 언급을 했다. 하지만 ECU에서 CAN 통신을 사용하는 Signal이 한 개만 존재하는 것이 아니다. 앞에서 보았듯이 각 Signal, PDU, Frame과 ECU Instance, Cluster, interface 등 각 항목에 대해 서로 연관 관계를 가지고 있어 CAN 통신을 많이 하는 ECU의 경우 서로 Mapping을 하는데 있어 주의가 필요하다.
정리해보면, 시스템 설계 단계는 Software Component Template과 System Template으로 구분이 되며, 그림 15에서 1번에 해당되는 Software Component Template은 Runnable, Port, CSw-C가 구성된다. System Template(네트워크 설계)은 그림 15에서 2, 3, 4에 해당되는 사항으로 2번에서는 ISignal, ISignalIPdu, CanFrame(Can 통신)에 대해서 설계를 하고, 3번에서는 Can Cluster, FlexRay Cluster, Ethernet Cluster 등 어떤 통신을 사용할 것인지 설정해야 한다. 2번과 3번 항목이 설정되면 4번 항목인 EcuInstance에서 Can Communication Connector의 Port 설정(IN/OUT)을 해 Mapping 해 설계하면 된다.

마치며
이번 호에는 AUTOSAR에서 CAN 통신을 하기 위해 System Template에서 설계하는 방법에 대해 알아봤다. 한 개의 Signal에 대해 설계를 해 단순하게 보이지만 신호가 많으면 설계와 Mapping에 혼돈이 있으므로 작업하는데 주의해야 한다. 만약 기존의 CAN DB를 Import 할 경우에는 System Template에 대한 정보는 추가되지만, 이럴 경우에는 Software Component Template에 대한 설계가 필요하니 시스템 설계에 대한 연관 관계를 잘 알아두길 바란다.
다음에는 AUTOSAR FlexRay에 대해 다룰 것이다. FlexRay는 기존 CAN 통신 프로토콜의 Event Driven 방식의 처리에서 Timing Trigger 방식의 처리로 마이크로세컨드 시간 단위로 여러 ECU와 동기화 해 실시간을 보장한다. 이것을 X-By-Wire라고 한다.  AE 

AEM_Automotive Electronics Magazine