전화(電化)/ 전자화

최근 자동차는 점차 전자화 되고 있습니다. 또, 차량 소프트웨어의 숫자와 복잡성 역시 매우 빠르게 증가하고 있는데, 일부 고급 차종의 경우 1000개 이상의 소프트웨어 기능을 갖추고 있습니다. 많은 버스 시스템에서 70개 이상의 ECU가 이용되고 있으며, CAN 네트워크에서 작업을 수행하는 ECU를 CAN 노드라고 부릅니다.

복잡성 증가

ECU 네트워킹 초기에는 CAN 인터페이스의 적절한 구현을 위해 단순한 하드웨어 독립 인터페이스를 제공하는 형태의 CAN 드라이버와 CAN 컨트롤러, CAN 트랜시버를 필요로 했습니다. 그러나 오늘날에는 운영 체제, 네트워크 관리 기능 또는 진단 기능이 필수적으로 있어야 합니다. 고도화된 소프트웨어의 복잡성은 ECU 인프라를 표준화할 필요성을 제기합니다.

소프트웨어 일치

동일한 소프트웨어를 이용한다면 개발이나 유지 관리에 있어 적은 노력이 필요할 것이며, 서로 다른 차량 플랫폼뿐 아니라 OEM 및 공급 업체 간 소프트웨어 컴포넌트를 상호 교환하여 이용하거나 재사용할 수 있을 것입니다.  

AUTOSAR

AUTOSAR(자동차 개방형 시스템 구조)는 ECU 소프트웨어의 참조 아키텍처를 제안합니다. 이 참조 아키텍처의 핵심이 바로 AUTOSAR 런타임 환경(Runtime Environment, RTE)이며, 이를 통해 어플리케이션의 소프트웨어 컴포넌트에서 네트워크를 완전히 분리합니다. 런타임 환경은 베이직 소프트웨어의 형태로 소프트웨어 컴포넌트에 단일한 서비스를 제공합니다. AUTOSAR는 전체적으로 세 가지 레벨(마이크로컨트롤러 추상화 계층, ECU 추상화 계층, 서비스 계층)로 구성됩니다.

CAN 노드 구조

그림 “CAN 노드”에서는 최근 CAN 노드의 구조를 확인할 수 있습니다. “통신 서비스(Communication Services)”는 특히 많은 관심이 집중되는 부분입니다. AUTOSAR COM(communication)은 표준 통신 서비스, 진단 서비스(진단 COM 관리자)와 네트워크 관리 서비스(일반 NM/CAN NM)를 제공합니다. 프로토콜 데이터 유닛(protocol data unit, PDU) 라우터는 개별 통신 계층 간 내부 노트 통신을 처리하며 AUTOSAR COM, 진단 COM 관리자와 CAN TP(전송 프로토콜) 간 통신을 조정합니다.