현재 차량용 소프트웨어 규모는 최신 고급차의 경우 코드 행수로 환산해 7,000만 줄에 이른다. 2015년에는 1억 줄 규모에 육박할 것으로 전망된다. 지금까지 차량용 소프트웨어 개발은 일반적으로 회사마다 독자적으로 이루어져왔다. 그러나 차량용 소프트웨어 규모가 급속히 커짐에 따라 각사가 공통으로 이용할 수 있는 기반 소프트웨어의 개발이 절실히 요구되고 있다. 전세계 자동차 업계가 AUTOSAR에 주목하는 이유도 여기에 있다.
지난 2월 14일 일본 자동차 소프트웨어 표준화 단체인 JasPar는 차량 제어 소프트웨어에 대한 3년 간(2007. 3~2010. 3)의 개발 성과를 발표하는 자리를 마련했다. AUTOSAR 3.0 기반의 CAN, FlexRay 통신을 적용한 실제 차량의 공개 시범 주행도 실시했다. AUTOSAR를 적용한 차량 양산이 점차 현실로 다가오고 있다는 느낌이다. 일본에서는 2011년을 목표로 AUTOSAR를 적용한 차량 양산을 준비 중이다.
CAN 통신이란?

CAN(Controller Area Network) 통신은 자동차의 전장 시스템 간 혹은 파워트레인, 새시의 통신에 사용되는 제어용 통신 규격으로 OSI(Open System Interconnection) 7계층을 따른다. 또한 CAN 통신의 오류 제한(Error Confinement)과 오류 탐색(Error Detection) 기능은 노이즈 결정적인(noise-critical) 환경에서 신뢰성을 한층 높여준다.
CAN 시스템은 2-wire로 구성되며 최대 1 Mbit/sec의 데이터 통신을 제공하고 실시간 제어를 촉진한다. CAN 통신의 ID는 디바이스들이 하나의 단일 네트워크 상의 버스에 연결될 수 있는 개수를 지정해 놓은 것으로, 표준형(Standard)과 확장형(Extended)이 있다.
표준형(CAN 2.0A)은 11 bit의 ID을 사용하며, 확장형(CAN 2.0B)은 29 bit의 ID을 제공한다. 한 번에 보낼 수 있는 최대 데이터 전송량은 8 byte이며 연결할 수 있는 최대 노드(일반적으로 ECU) 수는 30개 정도(ISO11898 기준)이다.
그림 2와 같이 전송 케이블인 버스가 배치되며, 버스 길이에 따라 전송 속도도 달라진다. 그러므로 배선 길이에 대한 고려가 필요하다. 일반적으로 CAN은 40 m 이내로 배선을 하면 안정적인 전송 속도를 보장한다.

AUTOSAR에서 CAN 통신 구현

AUTOSAR를 적용하여 CAN 통신을 구현하려면, 먼저 AUTOSAR의 전체적인 흐름에 대한 이해가 필요하다. 다시 말해 AUTOSAR 방법론(Methodology)의 역할과 CAN 통신 설계 방법을 알아야 한다. 그림 4에 제시한 AUTOSAR 방법론을 보면, ①번부터 ③번까지 단계를 거쳐 1개의 ECU에 대한 소스 코드가 생성된다. CAN 통신 구현에서 ①번 단계는 여러 개의 ECU에서 어떻게 통신할 것인지 설계를 한다.
그림 5를 보면 4개의 ECU(=Node)가 있고, 그림 6을 보면 4개의 ECU가 송신(=Sender)과 수신(=Receiver)을 어떻게 할 것인지 설계한다. ②번 단계에서는 1개의 ECU를 선택하여, 그림 7과 같이 어떤 BSW 모듈을 사용할 건인지 선택하고 상세 설계를 한다. 참고로 그림 6의 빨간색 부분 CAN Node A의 정보가 ECU Extract of System configuration이 되었을 때 남는 정보이다. 그러므로 전체 ECU 설계 정보가 없다면, ECU인 CAN Node A가 Can ID=0x12 데이터를 송신할 경우 수신하는 ECU가 CAN Node B인지 알 수가 없다. ③번 단계에서는 1개의 ECU에 대한 자동 생성된 전체 소스 코드를 가지고 그림 8과 같이 애플리케이션 개발자가 소프트웨어 컴포넌트의 소스 코드(=<SW-C>.c)를 개발한다.

독일 Vector회사의 온라인 CAN강좌 (무료), 영어
http://www.vector-elearning.com/vl_einfuehrungcan _portal_en,,378422.html

AUTOSAR에서의 Can 데이터 전송 처리 과정

그림 8의 swc1.c에서 Rte_Write API를 사용하게 되면, 그림 7에서 RTE, Com, PduR를 걸쳐 CanIf까지 전송할 데이터를 보낸다. 그런 다음 Can Driver가 현재 CAN Bus로 데이터를 전송하게 된다. 그림 6을 보면, CAN Node A에서 송신한 데이터 Can ID=0x12는 CAN Node B만 전송받게 되지만 실제로는 그림 10과 같이 CAN Bus에 연결되어 있는 모든 ECU의 Can Driver가 데이터를 전송받게 된다. 그런 다음 각 ECU의 CanIf에서 수신해야 할 CAN ID인지 확인한다(=Acceptance checking). 그림 11과 같이 수신해야 할 데이터의 CAN ID 값을 확인한 다음, 아닐 경우 버리고 맞을 경우 그림 7과 같이 CanIf에서 PduR_CanIfRxIndication API를 호출에 SW-C까지 전달한다. SW-C는 Rte_Read를 통해 보내진 데이터 값을 확인한다.
그림 12에서는 CAN Node B(=ECU)의 CanIf 수신 환경설정에서 CAN ID 값으로 수신해야 할 데이터인지 확인하는 것이다. 그러므로 AUTOSAR를 이용한 네트워크 통신은 짜여진 각본에 따라 데이터를 주고받게 되는 것이고, ECU 개발자는 각본만 잘 만들면 상세한 프로그래밍을 할 필요 없이 소프트웨어 컴포넌트만 작성해 주면 개발이 끝난다.
AUTOSAR를 차량에 적용하면, 개발인력이 많이 필요 없고 또한 ECU 설계에 대한 모든 정보가 AUTOSAR XML에 기술되어 있어 협력업체가 만든 설계 내용까지 알 수 있게 된다. JasPar의 경우를 보면, 일본 자동차 회사들이 AUTOSAR를 도입하는 가장 큰 이유는 ECU 설계의 재사용성임을 할 수 있다. 즉, 한번 개발했던 ECU 설계 데이터를 AUTOSAR XML로 가지고 있다가 간단히 편집해 다른 ECU에서도 쉽게 적용할 수 있다. 특히, 협력업체에 ECU 부품을 납품할 경우 ECU 설계를 AUTOSAR XML로 받아서 안정성 검증까지 할 수 있다.
필자는 AUTOSAR를 자동차뿐만 아니라 CAN 통신을 이용하는 선박, 의료 장비, 로봇 등에도 그대로 적용할 수 있다고 생각한다.