오늘날 자동차는 편리함을 추구하는 소비자의 요구와 사회적으로 강화된 안전규제를 만족하기 위해 전기/전자 시스템의 장착이 급격히 증가하고 있다. 이런 경향은 친환경, 높은 안전을 지향하는 미래형 자동차와 관련한 연구개발과 맞물려 더욱 가속화될 것으로 예상된다. 이와 같은 차량의 전자화 경향으로 차량 임베디드 소프트웨어의 중요성은 날로 높아지고 있다. 2010년까지 자동차 내에서 기술혁신의 90% 정도가 임베디드 시스템에 의해 달성될 것이며, 그 중 80% 정도가 소프트웨어에 의해 실현될 것이다[1]. 그리고 차량 임베디드 시스템 가격이 자동차 가격의 35~40% 수준으로 증가할 것으로 예상된다[2].
하지만 차량 내에 임베디드 시스템의 증가가 반드시 좋은 결과만을 가져오는 것은 아니다. 임베디드 시스템이 복잡해짐에 따라 그로 인한 결함발생 가능성도 동시에 증가하기 때문이다. 독일자동차협회의 조사에 따르면, 2003년 차량 고장의 36%는 전자장치에 기인한 것이었으며 그 비율은 점차 증가할 것으로 예상된다[3]. 특히 소프트웨어 복잡도가 증가함에 따라 소프트웨어 오류가 차량 고장의 상당한 원인을 차지하고 있는 추세이고, 그에 따른 품질보증 비용이 급격히 증가하고 있다.
한편 반도체를 비롯한 자동차 부품의 성능이 빠르게 향상되고 가격이 하락하면서, 이를 이용하는 자동차 부품업체들은 기존보다 저렴하고 우수한 품질의 임베디드 시스템을 개발하고 있다. 또 자동차 완성업체들은 다양한 소비자의 요구와 경쟁에서 살아남기 위해 성능이 우수한 신차 개발에 더욱 가속을 붙이고 있다. 그러나 복잡한 자동차 임베디드 시스템의 소프트웨어를 신속하고 신뢰성 있게 개발하기 위해서는 기존 방식에서 탈피하여 정형화되고 체계화된 새로운 소프트웨어 개발방법이 필요하다.
이러한 과제를 해결하기 위한 한 가지 방법으로 유럽을 중심으로 한 자동차 업계에서는 차량 임베디드 시스템 개발의 표준화, 개발방법론 등의 기법을 도입하고 있다. AUTOSAR는 그 대표적인 사례로 하드웨어와 소프트웨어의 분리를 통하여 소프트웨어의 재사용성, 확장성 등을 향상시켜 복잡한 소프트웨어를 빠르고 신뢰성 있게 개발할 수 있도록 지원하는 표준 규격이다.
AUTOSAR는 2003년 7월 자동차의 전기/전자 아키텍처에 대한 공개 표준을 제정하는 것을 목표로 유럽, 일본, 미국 등의 자동차 제조업체들과 부품제조업체들이 참여하여 설립했다. AUTOSAR 협력체는 4단계의 회원 구조로 이루어져 있다. 2008년 3월 현재 9개의 Core Partner, 52개의 Premium Member, 67개의 Associate Member, 4개의 Development Member로 구성돼 있다. 국내에서는 현대/기아 자동차, S&T대우, 만도, 대구경북과학기술연구원, 한국전자통신연구원이 Premium Member와 Associate Member로 활동하고 있다[4]. 2006년말 규격 2.1, 2007년말 규격 3.0이 완성돼 배포됐다. 현재 2단계(2007년~2009년) 활동이 진행중이며 규격 보완, 호환성 테스트, 응용시스템의 표준화 등의 업무를 수행중이다. 이르면 올해 AUTOSAR 규격이 접목된 자동차가 시장에 출시될 예정이며, 늦어도 2010년까지 모든 Core partner들이 AUTOSAR 기술이 적용된 자동차를 출시할 계획으로 알려져 있다.

AUTOSAR 기술 개관

AUTOSAR는 컴포넌트(Component) 개념을 적용하여 응용 소프트웨어(Application Software)와 베이식 소프트웨어(Basic Software)를 설계하는 소프트웨어 플랫폼으로 차량 임베디드 시스템의 재사용성을 높이고 기존의 하드웨어 종속적인 소프트웨어 구조에서 하드웨어 독립적인 구조로 바꾸는 것을 목표로 하고 있다[5-7].

AUTOSAR 개발방법론
AUTOSAR의 개발방법론(Methodology)을 이야기 할 때, 컴포넌트의 개념은 필수적인 요소이다. 사전적인 의미로 컴퓨터 소프트웨어 분야에서 “컴포넌트”라는 용어는 재사용 가능한 범용성을 가진 소프트웨어를 가리킨다. 흔히 소프트웨어에서 재사용을 이야기할 때 모듈의 개념을 주로 사용한다. 모듈은 API(Application Programming Interface) 형태의 함수들로 구성된 일련의 프로그램의 묶음이며, 모듈을 개발한 프로그래밍 언어와 개발환경에 큰 영향을 받는다. 이에 비해 컴포넌트는 모듈에 비해서 좀 더 큰 단위의 묶음이고 재사용을 용이하게 하기 위해 여러 개의 아토믹 컴포넌트(Atomic Component)를 묶어서 하나의 컴포지트 컴포넌트(Composite Component) 단위로 처리할 수 있다. 또한 컴포넌트는 미리 정의된 포트를 가지며, 이 포트를 통해서 다른 컴포넌트와 상호 연동하거나 데이터를 교환할 수 있다.
컴포넌트의 개념을 차량 임베디드 소프트웨어 개발에 이용하면, 그림 1과 같이 미리 정의되고 검증된 컴포넌트 저장소(Component Repository)에서 응용시스템[예를 들면, BCM(Body Control Module), ACC (Adaptive Cruise Control) 등]을 개발하는 데 필요한 컴포넌트들을 재사용하여 새로운 응용시스템을 조기에 개발할 수 있다. 이러한 컴포넌트에 기반한 개발방법은 개발기간을 단축시켜 다양한 차량 모델을 적기에 출시할 수 있고 검증된 컴포넌트를 이용함으로써 응용시스템의 신뢰성 향상에도 도움이 된다.
AUTOSAR 개발방법론은 기본적으로 컴포넌트 기반 소프트웨어 개발(Component Based Software Development, CBD) 방법론을 따르며 소프트웨어 개발 단계마다 각 행위(Activity)를 지원해주는 도구를 사용한다.
AUTOSAR는 VFB(Virtual Function Bus)라는 가상 버스 위에 Application Layer의 응용 소프트웨어 컴포넌트를 배치하고 포트 단위로 연결해준다. 그리고 각각의 컴포넌트들을 도구를 통해 적합한 ECU에 할당하여 전체 응용시스템을 구성한다. 따라서 응용 소프트웨어 컴포넌트 개발자가 개별 ECU 자원 및 네트워크 토폴로지 구성에 독립적으로 컴포넌트를 개발할 수 있도록 함으로써 재사용성을 극대화하고 있다.
그림 2에서 개별 ECU의 RTE(Runtime Environment)는 VFB라는 추상적인 개념을 실제 소스코드 형태로 구현해주는 역할을 담당하고 있으며 베이직 소프트웨어 컴포넌트의 통신 기능을 이용하여 응용 소프트웨어 컴포넌트의 ECU 할당 위치에 상관없이 동일한 인터페이스를 제공해주는 역할을 담당하고 있다.
그림 2는 AUTOSAR　개발방법론을 이용해서 응용시스템을 개발하는 대략적인 과정을 보여주고 있다. 각 단계별의 입력 또는 출력은 XML 파일, 소스코드(.c, .h), 실행 파일(.exe) 등으로 구성되어 있고 각 단계별로 응용시스템의 개발을 진행한다.
그림 3에서 보는 바와 같이, 첫 번째 단계인 Configure System 단계는 응용시스템을 구성하는 전체 소프트웨어 컴포넌트(SW-C)의 정의와 컴포넌트 간 포트 인터페이스의 연결 상태를 정의한다. 또한 응용시스템을 구성하는 ECU 정보와 ECU들이 차량 네트워크(CAN LIN, FlexRay 등)에 연결된 상태를 나타내는 네트워크 토폴로지 및 이들이 주고받을 통신 메시지 매트릭스를 정의한다. 그리고 소프트웨어 컴포넌트들을 적절한 ECU에 할당시키고, 그 결과를 System Configuration Description 파일에 저장한다. 이 단계에서 시스템 설정 도구(System Configuration Tool)가 사용된다. 다음 단계인 Extract ECU-Specific Information 단계는 전 단계의 결과물에서 개별 ECU에 할당된 정보만을 추출하여 ECU Extract of System Configuration 파일을 생성한다. 이로써 전체적인 시스템 설계 과정는 끝나고, 다음 단계부터는 각 ECU에 대해 ECU 설계 과정을 반복해서 수행한다.
Configure ECU 단계는 해당 ECU의 하드웨어 리소스(메모리, 통신 디바이스 등)를 기반으로 베이직 소프트웨어(OS, Communication 등)와 RTE를 설정하는 단계이다. 이 단계에서는 ECU 설정 도구(ECU Configuration Tool)을 이용하여 베이직 소프트웨어 각 모듈의 세부 정보를 설정하거나 이미 개발된 소프트웨어 컴포넌트들을 플랫폼에 통합하기 위해서 각종 설정작업을 수행한다.
마지막으로 Generate ECU 단계는 ECU Configuration Description 정보를 바탕으로 코드생성도구(Code Generation Tool)를 이용하여 RTE 코드와 베이직 소프트웨어 코드를 생성하고 이를 컴파일, 링킹하여 ECU에서 동작하는 실행 가능한 실행 파일(.exe)을 만든다.

AUTOSAR 플랫폼 소개
컴포넌트 관점에서 개별 ECU의 소프트웨어 플랫폼 구조는 그림 4와 같다.
응용 소프트웨어는 항상 RTE를 통한 AUTOSAR 인터페이스를 통해서만 베이직 소프트웨어 및 다른 응용 소프트웨어 컴포넌트(SW-C)와 통신할 수 있다. AUTOSAR에서 제공하는 통신 인터페이스의 종류는 크게 두 가지로, 컴포넌트 간에 메시지를 주고받는 Sender-Receiver 통신 모델과 함수 호출을 하는 Client-Server 통신 모델이 있다. RTE는 하위의 베이직 소프트웨어의 통신 컴포넌트를 이용해서 다른 ECU 상에 위치해 있는 소프트웨어 컴포넌트 간에 AUTOSAR 인터페이스를 기반으로 통신을 할 수 있도록 기능을 제공한다. 그림 4를 보면 AUTOSAR 플랫폼에서 사용하는 세 종류의 인터페이스가 있으며, 각 인터페이스의 정의는 다음과 같다.

■ AUTOSAR Interface: RTE를 통해서 제공되는 인터페이스로, 소프트웨어 컴포넌트 간에 교환되는 정보(Data, Operation, Event)를 정의한다. 이러한 정보를 정의하는 인터페이스는 응용 소프트웨어 컴포넌트 개발자에 의해서 다양한 이름으로 정의될 수 있다.
■ Standardized AUTOSAR Interface: RTE틀 통해서 제공되는 인터페이스이지만, 그 Syntax와 Sematic이 AUTOSAR에 의해서 사전에 정의된 인터페이스이다. 주로 Service Layer(Memory, System Service, I/O 등)에 의해서 제공된다.
■ Standardized Interface: RTE와 상관없이 베이직 소프트웨어 간에, 또는 RTE와 베이직 소프트웨어 간에 사용하는 C API 기반의 인터페이스로 소프트웨어 플랫폼 자체를 구현하거나 AUTOSAR 인터페이스를 제공하기 위해서 사용된다.

계층적인 관점에서 AUTOSAR 플랫폼의 구조는 그림 5와 같다.
Service Layer는 응용 소프트웨어를 개발하는 데 필요한 다양한 시스템 서비스를 제공한다. Memory, Communication 뿐만 아니라 각종 하드웨어 리소스에 관련된 자원에 대한 접근을 표준화된 인터페이스를 통해서 제공하고 있다.
EAL(ECU Abstraction Layer)은 ECU에 센서, 액추에이터, 각종 I/O 장치들이 연결될 때, 하드웨어 회로의 배치와 관계없이 응용 소프트웨어 및 Service Layer에 동일한 인터페이스를 제공하는 역할을 한다. EAL의 한 예인 Watchdog Interface는 MCU 내/외부 Watchdog의 구분없이, System Service의 Watchdog Manager가 동일한 인터페이스로 Watchdog Device를 사용할 수 있도록 해준다.
MCAL(Microcontroller Abstraction Layer)은 상위의 EAL에 동일한 디바이스 드라이버 API를 제공하므로 마이크로컨트롤러(MCU)가 변경되었을 때, MCAL 부분을 수정함으로써 상위 계층의 수정을 최소화할 수 있다.