[AUTOSAR] CAN(Controller Area Network) 통신 이란?

세상에는 다양한 통신 프로토콜들이 존재하는데  CAN 통신에 대해 알아보자.

 

CAN도 수 많은 통신 프로토콜 중 하나이다. 통신이라는 것은 서로 다른 두 주체가 데이터를 주고 받는 것을 의미한다.
자동차 안에는 굉장히 많은 제어기가 들어가 있다. 여기서 제어기는 일종의 컴퓨터라고 생각하면 된다.

 

핸들(조향장치)를 컨트롤 하는 제어기, 브레이크를 컨트롤 하는 제어기, 에어백을 컨트롤 하는 제어기, 스마트키 모듈을 컨트롤하는 제어기 등등.. 아주 많은 수의 제어기가 자동차 안에 들어가있다.
그리고 이러한 제어기들은 서로 정보를 주고 받을 필요가 있는데, 이 때 사용하는 통신 프로토콜이 바로 CAN 통신이다.

 

예전 자동차 제조사들은 차량 내 ECU(전자제어장치) 간의 Point to Point 방식을 사용한 통신 방식을 사용했다.

(Point to Point방식의 대표적인 예는 RS-232C가 있다.) 

 

Point to Point(좌)에서 CAN통신(우)

 

시간이 지나 ECU의 숫자는 점점 늘어나면서 배선의 길이가 길어지고, 이에 따른 비용과 무게가 증가했다. 차량에서는 제작 비용도 민감하지만 무게에 대해서도 상당히 민감하다. 이 문제를 해결하고자 자동차 업계에서는 CAN통신을 도입(벤츠가 가장 먼저 상용차에 적용)하였으며 현재 산업 통신에서는 모든 차량에 CAN통신을 사용한다고 봐도 과언이 아니다. 

 

CAN 통신의 가장 큰 특징은 토폴로지가 버스형 토폴로지 라는 것인데, 용어가 낯설겠지만 별 것 아니다.

위 그림처럼 가운데 공통으로 사용하는 통신선을 두고,
통신에 참여하려는 제어기들은 모두 여기에다가 선을 연결해서 통신에 참여하면 된다.

이때 저 공통의 선을 버스(bus)라고 부르기 때문에 버스형 토폴로지이다.
버스형 토폴로지에는 새로운 제어기들이 통신에 참여 할 때, 그냥 공통선에만 바로 연결하면 되는 가장 큰 장점이 있다.
또한, 기존에 통신에 참여하던 제어기를 떼고싶다면, 마찬가지로 공통선에서 연결된 선만 잘라내면 된다.

 

그런데 통신에 참여하는 모든 제어기가 공통의 버스선에 연결돼있기 때문에 단점도 있다.
통신에 참여하는 제어기 중에 한 개가 갑자기 비정상적으로 동작하면서 통신선 전체를 고장나게 해버리면
다른 제어기들도 모두 통신이 불가능하다. 모두 공통의 선을 사용하기 때문이다. 이러한 상황을 방지하려고 CAN 프로토콜에서는 BusOff 라는 개념을 도입했는데 이것은 나중에 알아보자.

CAN 통신에서는 버스 라는 하나의 공통선이 있고, 모든 제어기는 이 버스와 연결되어있다. 또한 모든 메세지가 브로드캐스트 방식으로 송신된다. 송신을 하면 버스에 연결된 모든 제어기에게 메세지가 전달 되기 때문에, 이 메세지를 받아서 쓸지 말지는 받는 쪽에서 결정한다.

 

 

 

AUTOSAR CAN 통신 이벤트 경로

AUTOSAR CAN은 크게 3개의 기능으로 분류된다.

1. CAN Communiction (메시지 송수신)

2. CAN Status (통신 상태)

3. CAN Network Management (네트워크 관리)

 

1. CAN Communiction (메시지 송수신)

AUTOSAR CAN Communication Stack은 다음과 같이 크게 5개의 모듈로 구성된다.

• COM

- COM 모듈을 기점으로 상위 Layer는 signal을 사용하고, 하위로는 PDU를 사용한다.

  (Signal은 전달할 메시지, PDU는 계층 간 메시지 전송을 위한 프로토콜 추상화)

- PDU Data Signal 단위로 읽고 쓸 수 있는 인터페이스를 제공한다

- 주기적으로 PDU와 송신한다.
- Signal에 따른 Timeout, Data Received, Data Send 등의 이벤트를 ASW에 통지한다.

- 어플리케이션에서 전달된 signal 은 COM의 I-PDU 버퍼에 저장되고, PduR_ComTransmit 함수에 의해서 I-PDU 형태로 PduR로 전달된다. 반대로 PDU를 수신 받을 때는 PduR에서 Com_RxIndication 함수를 통해서 수신된 PDU가 있음을 알리고, COM에서는 I-PDU 속 signal을 분석해서 해당 signal과 연결된 callback 함수를 호출하여 수신된 signal이 RTE를 통해서 어플리케이션으로 전달된다.

 

• PduR

PduR을 설명하기에 앞서 먼저 PDU에 대해 설명하겠다. 통신 메세지는 네트워크 계층 간 정보 전달의 편의를 위해서 PDU(Protocol Data Unit)로 바뀌는데 SDU(Service Data Unit)와 PCI(Protocol Control Information)로 구성된다. SDU는 다른 계층 또는 모듈로 전달되는 데이터이고, PCI는 발신지/수신지/순서 번호와 같은 정보들로 계층 간 혹은 모듈 간 PDU 전달을 위해 덧붙이는 정보를 말한다.예를 들어 COM에서 전달받은 PDU는 PduR에서는 SDU가 되고, 라우팅 정보가 포함된 PCI가 더해져서 새로운 PDU를 구성하게 된다. PDU는 AUTOSAR의 CAN 스택 내에서만 사용되는 것이기 때문에 CAN Driver를 통해서 실제 전송시에는 PDU형태로 전송되지 않고, 필요한 메시지만 PDU에서 추출하여 네트워크로 전송하게 된다.

 

이렇게 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를 연결하여 호출해 주는 기능이다. 
- PduR의 Gateway 기능을 통해서 서로 다른 Bus간 혹은 서로 다른 Controller간 PDU 송/수신도 가능합니다.

   * 진단과 관계 있는 Pdu는 Dcm, Dem 모듈로 전달한다
   * 진단과 관계 없는 Pdu는 Com 으로 올려보낸다. 
-  경우에 따라 메시지를 상위 레이어로 전달하지 않고 다른 모듈로 직접 전달할 수 있다.

 

• CanIf

- CAN Driver로 부터 수신한 PDU를 상위 Layer로 전달한다.
- 상위 Layer가 PDU CAN Driver에 전달한다.
- BusOff 발생을 Can으로부터 받아 CanSM에 전달한다.
- CAN 컨트롤러와 트랜시버를 제어하는 인터페이스를 제공한다.
   * 진단 메시지는 Canlf 에서 CanTP로 전달되어 적절한 처리 후에 PduR로 돌려진다.
   * CAN TP를 사용하지 않는 경우에는 Canlf에서 PduR로 바로 올려 보내진다.

 

• CAN 

- CAN 컨트롤러(하드웨어)를 활성화 또는 비활성화한다.
   * SFR(Special Function Register)를 제어한다.
- CAN Interrupt Handler를 제공한다 (Tx, Rx, BusOff 등)
   * Interrupt 대신에 Task를 이용한 Polling 방식도 사용 가능하다.

 

• CanTrcv 

- CAN 트랜시버(하드웨어)의 상태를 제어한다 (Normal / Sleep / Stanby)
- WakeUp 패턴에 의한 WakeUp 기능을 제공한다.

 

 

2. CAN Status (통신 상태)

AUTOSAR CAN Status Stack은 BusOff Recovery 기능과 Network Status 제어 기능을 포함하며,

다음과 같이 크게 3개의 모듈로 구성된다.

• BswM

- Rule에 따른 Action을 제어한다 (Rule based Configuration)
   ex) Bus-off 상태로부터 회복(recovery) 되면, 100 ms 후 다시 전송을 재개한다.
- BswM은 CanSM 뿐만 아니라 LinSM 등 다른 모듈에도 관여한다.

 

• ComM

- CAN, LIN, FlexRay 등 통신 제어를 요청하는 인터페이스를 제공한다.

- 통신 제어기능 실행시에 하위의 BusSM 모듈에게 명령을 전송한다.

   * BusSM 모듈의 예로는 CanSM, LinSM, FlexraySM 등이 있다.
- NM 모듈에게 Network Request / Release 명령을 전송한다.

 

• CanSM

- BusOff 발생시에 BusOff Recovery Process를 실행한다.
- CAN 통신기능을 제어하여 활성화 또는 비활성화를 시킨다.
- CAN 통신기능 상태를 ComM에게 통지한다.

 

 

3. CAN Network Management (네트워크 관리)

AUTOSAR CAN Network Management는 Network 구성과 Sleep 제어기능을 포함하며,

다음과 같이 크게 2개의 모듈로 구성된다.

• NM

- ComM으로부터 Network Request 또는 Release 명령을 받아 실행한다.
- Network 요청상태에 따라 하위 OsekNm 모듈을 제어한다.
- 전체 Network Cluster가 동기화되어 SLEEP에 진입하도록 제어한다.
- Network 상태를 ComM에게 통지한다 (FULLCOMM, NOCOMM, SILENTCOMM, ...)
   * SilentCom: 데이터 수신만 가능한 통신상태

 

• CanNM (OsekNm)

- NM PDU를 송수신하여 Network 상태를 감시한다.
- NM 인터페이스 모듈에게 Network 상태를 통지한다.
- 네트워크로 메시지를 수신하는 경우. Network 상에 있는 다른 제어기의 ComM이 보낸 Sleep Indication을 처리한다
- 네트워크로 메시지를 전송하는 경우, Network 상에 있는 모든 제어기들이 동시에 BUS SLEEP 상태로 진입하도록 제어한다.
   * 정상적인 통신이라면, 버스에 불려있는 모든 제어기가 동일한 상태를 가지고 있어야 한다.
   * 어떤 제어기는 Sleep 상태를 가지면서, 다른 어떤 제어기는 Wake-up 상태를 가질 수 없다.

 

 

출처 : https://www.mdstech.co.kr/reference/4687

출처 : https://m.blog.naver.com/PostList.naver?blogId=techref&tab=1

출처 : https://newbie-developer.tistory.com/