글│마티아스 베르니케(Matthias Wernicke),     matthias.wernicke@vector-informatik.de   
DaVinci Tool Suite 관리 책임자    Vector Informatik GmbH

자동차 산업은 새로운 시대로 접어들고 있다. 자동차의 각종 기능이 발전하면서 자동차 전자 분야의 개발이 보다 포괄적인 특성을 띠면서 복잡해지고 있다. 또한 갖가지 변수와 장비의 다양성, 진단 기능 및 가용성과 같은 비기능적인 요건에 대한 고객의 요구가 제기됨에 따라 보다 집약적인 ECU 개발 프로세스의 필요성이 대두되고 있다. 특히 고급 차량의 경우 소프트웨어 기능은 1,000가지가 넘고 서로 다른 종류의 차량용 전자 네트워크를 동시에 사용하고 있으며 70개 이상의 ECU를 가지고 있다. 이 분야에서 사용되는 하드웨어 플랫폼의 다양성 때문에 하드웨어 및 시스템 구성에 대한 ECU 소프트웨어의 종속성은 점점 더 문제가 되고 있다. 이러한 제약 사항 중 하나가 변경될 경우 재프로그래밍을 수행하거나 소프트웨어를 수정해야 한다.
ECU 소프트웨어 개발의 복잡성을 보다 편리하게 관리하기 위해서 AUTOSAR는 재사용 가능한 애플리케이션 개발의 토대가 되는 소프트웨어 아키텍처를 정의하고 있으며 실무 테스트를 거치고 있다. 자동차 OEM, 서플라이어, 글로벌 소프트웨어, 반도체 및 전자산업 분야 업체들이 만든 이러한 시스템 아키텍처의 개방형 표준을 이용하면 사용자들은 굳이 많은 비용과 노력을 들여서 독자적인 솔루션을 개발하지 않아도 된다.
AUTOSAR 아키텍처는 다양한 계층 및 모듈로 세분화된다. AUTOSAR는 인터페이스의 동시 정의(simultaneous definition)를 통해 소프트웨어 컴포넌트나 하드웨어 플랫폼을 쉽게 바꿀 수 있는 표준을 생성한다. AUTOSAR는 기본 소프트웨어 모듈에 대한 사양을 제공할 뿐만 아니라 애플리케이션 및 분산 시스템 개발을 위한 방법론도 제공한다. 이러한 방법론은 소프트웨어 애플리케이션 및 분산 시스템에 대한 모델 기반의 설명(model-based description)에서 시작하여 자동으로 생성되고 재현할 수 있는 테스트로 마무리된다. 이러한 형식화된 접근법은 범용 툴체인(tool chain)의 사용을 단순화한다.
AUTOSAR 2.1은 시작된 지 만 3년 만인 2007년 초에 발표되었다. 이 배포판은 안정적인 수준에 도달했으며 실무 활용을 위해 유효성 검증 프로젝트에서 수차례 테스트를 거쳤다. 많은 분야에서 “AUTOSAR 평가”가 성공적으로 완료되었으며 이제 ECU의 양산 제품에서 구현될 준비가 되었다.

AUTOSAR 아키텍처

기본 모듈과 기능들로부터 애플리케이션 소프트웨어를 분리한다는 AUTOSAR의 목표를 실현하기 위해 자동차 전자 분야가 추상화되고 여러 계층으로 세분화돼 있다(그림 1).
제 1계층은 마이크로컨트롤러 추상 계층(Microcontroller Abstraction Layer)이다. 이 계층은 실제 마이크로컨트롤러의 기능 및 주변장치를 매핑하며 메모리, I/O 드라이버 및 해당 통신 연결을 위한 인터페이스를 정의하여 마이크로컨트롤러를 제어한다. 또한 마이크로컨트롤러가 제공하지 않는 기능을 소프트웨어로 에뮬레이션 할 수도 있다.
제 2계층은 ECU 추상 계층(ECU Abstraction Layer)이다. 이 계층은 ECU 특정 하드웨어 레이아웃을 설정하고 ECU 외부 장치에 대한 드라이버를 제공한다.
제 3계층인 서비스 계층(Services Layer)에서는 네트워크 서비스, 메모리 관리, 버스 통신 서비스 및 운영체제와 같은 다양한 기본 서비스를 제공하며 이 계층은 하드웨어와는 거의 무관하게 동작한다. 제 4계층은 RTE (Run Time Environment)이다. 이 계층에서 사용자가 작성하는 애플리케이션과 기본 소프트웨어(BSW)의 실질적인 분리가 이루어진다. 또한 RTE는 애플리케이션 소프트웨어를 통합시키고 애플리케이션과 BSW 간 데이터 교환을 조절한다. 시간이 흐른 후에 하드웨어에 대한 정보가 없는 상태라 하더라도 기존에 작성된 애플리케이션 소프트웨어를 재사용할 수 있고 또한 다른 ECU라 하더라도 AUTOSAR 표준에 따르는 것이라면 소프트웨어를 재사용할 수 있는데, 이것은 이 계층에서 하드웨어를 제어하는 인터페이스를 이미 정의하여 그것을 이용하기 때문이다.
소위 말하는 가상 기능 버스(Virtual Functional Bus, VFB)는 계층 구성의 기본을 형성한다. 자동차 전자 제품의 모든 컴포넌트는 이 버스를 통해 통신한다. 소프트웨어 컴포넌트는 이를 위해 인터페이스에 필요한 신호들을 묶어서 마치 커넥터처럼 하나의 포트(port)로 정의하여 사용한다. VFB를 이용하기 때문에 여러 개의 소프트웨어 컴포넌트를 동일 ECU 내에서 사용하거나 또는 서로 다른 ECU에서 외부 버스를 통해 사용하더라도 동일한 인터페이스를 사용하게 된다. 따라서 VFB는 최종 시스템 레이아웃이 형성되고 각 ECU의 기능이 정의되는 거의 마지막 단계까지 수정 작업을 거치게 된다.
소프트웨어 컴포넌트 자체는 VFB 수정본이 나중에 제공되더라도 특별한 지식이 요구되지 않으므로 독립적으로 개발할 수 있다. 즉, 컴포넌트는 센서 값의 변경 또는 주기적인 동작 등과 같이 특정 이벤트가 발생할 때에 처리할 미리 정해진 프로시저(procedure)를 정의하는 것이므로 특정 소프트웨어 컴포넌트의 인터페이스를 정의하는 VFB 수정에 따라서 큰 영향을 받지 않는다. 결과적으로 애플리케이션 컴포넌트는 특정 ECU와는 별도로 개발될 수 있다.
ECU에서 애플리케이션 컴포넌트에 대한 “상대 개념”이 바로 RTE이다. 이것은 I/O, 메모리 및 기타 기본 서비스를 액세스 할 수 있도록 해준다. 또한 RTE는 ECU의 특정 사양에 적합하도록 생성되는데, 이것은 자원을 효율적으로 활용하면서 다른 다양한 사양에 맞게 다시 개발할 수 있음을 의미한다.

방법론

AUTOSAR 표준은 ECU의 소프트웨어 아키텍처를 정의하는 것 외에, AUTOSAR 시스템의 개발에 도움을 주기 위한 방법론을 정의한다. 구조화된 생성 프로세스를 준수하는 것은 오류 없는 소프트웨어를 생성하는 중요한 사전 조건으로 인식된다. 요구사항 목록에서 누락된 부분은 초기에 검색되고 소프트웨어 컴포넌트의 재사용 및 이식이 단순화되고, 전반적인 시스템의 안정성이 향상된다. 그럼에도 불구하고 이 방법론은 나름대로 자유로운 작업을 보장한다. 가령 사용자들은 하향식 접근법을 사용할 지 또는 상향식 개발을 사용할 지를 결정할 수 있다.
AUTOSAR 이니셔티브는 소프트웨어 개발 프로세스를 향상시키기 위해 툴을 제공한다. 요구사항을 구조적으로 수행하고 관리하기 위해 검증된 툴을 사용함으로써 체계적인 구성, 복잡한 종속성을 자동으로 고려한다.
첫 번째 단계에서는 소프트웨어(SW 컴포넌트), ECU(ECU 자원) 및 시스템 제약의 세 가지 주요 구성요소에 대한 형식화된 설명이 포함된다. 적절한 편집기를 사용하여 완전한 시스템 구성에 대한 설명을 생성한다(그림 2). 이 시스템 구성은 사용자가 구성 툴의 도움을 받아 개별 기본 소프트웨어 모듈을 위해 생성하는 ECU 구성의 기반이 된다. 이 프로세스의 마지막 단계에서는 여러 생성기가 RTE 및 기본 소프트웨어를 이용하는 ECU의 특별한 동작 방법을 제공한다.
개발 프로세스에서 생산된 모든 디자인 및 구성 데이터는 동일한 형식으로 설명된다. AUTOSAR는 이를 위해 XML 기반 형식을 정의했다. AUTOSAR는 한편으로는 개발 프로세스의 보편성을 보장하고, 다른 한편으로는 필요한 보조 툴들을 손쉽게 통합하도록 한다.

마이그레이션(migration)

AUTOSAR ECU의 소프트웨어 아키텍처는 획일적이지 않으며 잘 정의된 인터페이스를 가진 많은 수의 표준 모듈로 구성된다. 따라서 AUTOSAR로 안전하게 전환할 수 있도록 하는 마이그레이션 솔루션을 구현할 수 있다. 이러한 마이그레이션 솔루션은 프로젝트마다 고유하게 작동해야 한다. 실제로 표준 AUTOSAR 모듈 및 독자적인 소프트웨어의 혼합된 구성이 마이그레이션 솔루션을 형성할 수 있다.
마이그레이션 솔루션의 활용은 기존 사용자 소프트웨어와 AUTOSAR 아키텍처를 비교하는 것에서 시작한다. 중복되는 기능과 통합 옵션을 분석한 후에 그대로 남겨둘 모듈과 표준 소프트웨어로 대체할 수 있는 모듈을 결정한다.
가령 애플리케이션과 기본 소프트웨어 간에 분리 계층을 도입하는 것을 고려할 수 있다. 이 경우에 가능한 시나리오는 AUTOSAR 소프트웨어 컴포넌트가 이미 초기 마이그레이션 단계에 있을 때 애플리케이션을 준비하고 RTE를 통해 이러한 컴포넌트를 통합하는 것이다. RTE 바로 아래에는 기존의 기본 소프트웨어와 만나는 특정 적응 계층이 사용된다(그림 3).
기존의 기본 소프트웨어의 일부를 AUTOSAR 기반 소프트웨어로 대체할 경우 두 영역에 통일된 구성 툴을 사용하는 것이 중요하다. Vector는 독자적인 기본 소프트웨어를 구성하는 데에도 사용할 수 있을 만큼 충분히 유연한 툴을 제공한다. 이제 이후 단계에서는 전체 아키텍처를 안전하게 유지하고 다른 모듈로 재프로그래밍하지 않고도 비 AUTOSAR 모듈을 AUTOSAR 모듈로 대체할 수 있게 된다.
전망

최신 AUTOSAR 3.0은 AUTOSAR 표준의 품질 향상을 위해 진행된 작업이었다. 참여 회사들이 계속 늘어나고 있다는 점은 AUTOSAR 개발의 목표와 타당성을 여실히 보여 주는 반증이라고 할 수 있다. 현재는 AUTOSAR 표준의 차기 버전인 4.0을 구체화하려는 아이디어가 도입되고 있다.
AUTOSAR와 관련된 새로운 아이디어는 툴 공급업체에 의해서도 창출되고 있다. Vector의 현재 개발 목표는 AUTOSAR에 기반한 ECU 개발을 가능한 편리하고 효율적인 것으로 만드는 것이다. 한 가지 예는 VFB 레벨에서 AUTOSAR ECU 환경에 맞는 에뮬레이터로 작동하는 PC 기반의 AUTOSAR 애플리케이션 컴포넌트용 테스트 툴이다. 이 툴은 개발 PC에서 AUTOSAR 소프트웨어 컴포넌트의 구현 코드를 쉽게 테스트할 수 있도록 한다. Vector의 CANoe는 테스트 실행, 테스트 과정 또는 결과의 시각화, 테스트 보고서 생성 등에 사용할 수 있다. Vector는 AUTOSAR의 기본 소프트웨어 및 디자인 툴체인, 개발 툴들을 이용하여  ECU 개발 프로세스의 모든 단계를 지원한다(그림 4). 사용 가능한 Vector 솔루션은 평가 프로젝트에서 실제로 테스트를 거쳤으며 AUTOSAR 2.0 또는 2.1 기준으로 생산 가능하다(2008년 2사분기에 시작될 3.0도 적합함).

요약

AUTOSAR는 현실이 되고 있다. 다양한 OEM들은 새롭게 대두되고 있는 자동차 생산 프로그램에서 AUTOSAR를 구현하기 위한 탄탄한 계획을 갖추고 있다. Vector는 이를 위한 포괄적인 제품 라인업과 AUTOSAR와 관련된 기본 소프트웨어 및 툴을 제공하고 있다. 이를 통해 순수한 AUTOSAR 시스템의 개발을 가능케 할 뿐 아니라 AUTOSAR로의 단계별 마이그레이션을 지원할 수 있다.