ASCET는 자동차용 ECU의 애플리케이션 소프트웨어의 모델 기반 개발 환경에서 널리 사용되고 있는 툴이다. 제어/진단 Function의 모델링, 디자인으로부터, 시뮬레이션, Rapid Prototyping, 양산용 코드의 자동 생성에 이르는 개발 환경을 폭넓게 커버하고 있다. 파워트레인과 새시, 보디 일렉트로닉스의 다양한 프로젝트에 적용되고 있으며, ASCET에서 자동 생성된 코드는 연간 1000만 이상의 양산 ECU에 설치되고 있다. ASCET는 AUTOSAR 소프트웨어 컴포넌트를 모델 기반으로 구축할 수 있다.

이전에 바디 일렉트로닉스를 작동시키는 Function들은 텍스트 형식의 언어로 서술(description)되었다. 이것은 하드웨어에 종속되는 구현(implementation)이라는 단점을 갖고 있어 OEM의 기대를 충족시키지 못할 뿐 아니라, 컴포넌트를 공유하여 사용하고자 하는 정책과도 상반되는 일이었다. 또한 에러가 발생한 상황을 다르게 처리해야 함을 알고 있는 엔드 유저들로부터 불만의 대상이 되었다. 이러한 상황을 방지하기 위해서는 소위 유저가 구상한 Function의 많은 부분들을 각각의 제어 엘러먼트(버튼이나 서보 모터, 릴레이 등)로부터 완전히 분리시킨다. 그리고 ASCET 등의 소프트웨어 개발 툴을 이용하여 하드웨어에 종속되지 않는 Function 모델로서 모델링한다. 그 결과 차량 시스템 구조와 독립적이며 추상화된 수준으로 Function 특성이 서술(description)될 수 있다.
이 방법의 분명한 이점은 검증된 Function 모델을 다른 차량의 프로젝트에도 쉽게 재사용할 수 있다는 것이다. 이것은 개발 및 유지보수 비용을 절감하고 사용자의 오퍼레이팅 컨셉트에 일관성을 제공함으로써 제품 품질에도 긍정적인 영향을 미칠 수 있다. BMW에서는 이미 몇 개의 Function 모델을 아무런 변경 없이 성공적으로 신규 차량 프로젝트에서 재사용한 3건의 실적이 있다.

소프트웨어 메이커 BMW

바디 일렉트로닉스용 Function의 모델링을 통해서, BMW는 ECU 서플라이어를 위한 소프트웨어 메이커 및 벤더로서의 역할을 하게 되었다. 그 결과 양자 간에 Operating 소프트웨어 개발에 있어 새로운 인터페이스가 만들어지게 되었다. 일반적으로 자동차 메이커에 있어서 바디 일렉트로닉스용 ECU의 Operating Function은 소프트웨어 전체의 5∼10％에 불과하지만, 관련된 Function을 유저가 직접 인식하는 것은 대단히 중요하다.
요사이 BMW에서는 직접 구상한 소프트웨어 모듈 형태로 ECU용 Operating Function을 공급하는 것이 정착되어 가고 있다. 여기서 BMW가 제공하는 소프트웨어 모듈이 ECU 서플라이어의 전체 소프트웨어 프로젝트에 잘 통합되기 위해서는 인터페이스를 정확하게 서술(description)하는 것이 중요하다. 이를 위해서 정적(static) 및 동적(dynamic) 서술(description)을 모두 이용한 몇 가지 독자적인 방법들이 시도되어 왔다. 그 최신 기법으로 메이커 간의 경계를 초월하는 최초의 대응으로서 도입되는 것이 AUTOSAR(Automotive Open System Architecture) 규약이다. BMW는 AUTOSAR의 창립 멤버이자 코어 파트너 사이며, ETAS는 프리미엄 멤버로 활동하고 있다.

AUTOSAR:
인터페이스의 윤활유

AUTOSAR는 인터페이스 서술(description) 표준화를 통해서 자동차 메이커와 서플라이어를 지원한다. 그 분명한 이점은 제공되는 소프트웨어 모듈의 통합을 쉽게 해 주며 재사용성을 높인다는 것이다. AUTOSAR 인터페이스 서술(description)의 기술적인 구현에는 RTE(Runtime-Environment)와 연계되는 소프트웨어 컴포넌트 템플릿(Software Component Template)을 사용한다. 기존의 방법과 달리, 구현에 의존하는 인터페이스의 상세(변수 이름이나 전송 방법 등) 내용은 AUTOSAR 규격에 기반하여 서술(description)되고 이후 RTE를 구현함으로써 인터페이스가 실현된다.
이 방법의 이점은 ASCET 모델의 형태로 BMW가 제공하는 Operating Function이 서플라이어의 소프트웨어 프로젝트에 통합될 때 분명해진다.
모델의 수가 늘어남에 따라 모델의 유지관리에 지출되는 비용도 규모가 커지게 된다. 이 때문에 BMW에서는 자사의 모든 Function 모델들을 이른바 Modellothek이라고 하는 모델 라이브러리에 모아 외부의 서비스 프로바이더에게 의탁하고 있다. 프로바이더는 모델 관리와 테스트를 위해 명확한 프로세스를 따르며, 다양한 대상 프로젝트에 통합하기 위해 대비한다. 그리고 ECU 벤더의 요청에 따라 필요한 ASCET 모델 혹은 모델 데이터로부터 대부분의 타깃 컨트롤러에 적용 가능한 C코드를 만들어 통합이 가능하도록 한다. 자동 코드 생성 작업에도 새롭게 개발된 AUTOSAR 호환 인터페이스를 따르는 Function 모델이 사용된다.
수작업은 아직 필요

독자적인 인터페이스를 따르는 기존의 모델들과 비교하여, AUTOSAR Software Component Template에 기반하여 개발된 모델에서는 다른 인터페이스가 필요하다. 새로운 인터페이스를 구현하는 비용은 기존의 방법에 소요되는 비용과 거의 차이가 없기 때문에, ASCET으로 AUTOSAR 규약을 따르는 인터페이스와 Function을 모델링 하는 현재의 방법에는 추가적인 노동력이 필요하지 않지만 시간 또한 절약되지는 않는다. 그리고 현재 BMW에서 사용하고 있는 ASCET V5.0은 AUTOSAR를 만족하는 인터페이스 서술(description)에 대해 아직 완전한 지원을 제공하지 않기 때문에 몇 가지 AUTOSAR 관련 구현을 수작업으로 해야 할 필요가 있다. 이러한 수작업의 비율을 낮추기 위해서 BMW와 ETAS는 공동 노력을 하고 있으며, ASCET을 이용한 AUTOSAR 지원 인터페이스의 모델링에 있어서 현재의 갭을 없애고, 여기서 얻을 수 있는 개선점을 차기 주요 프로그램 릴리스에 반영하여 ASCET 유저에게 제공할 수 있도록 작업을 진척시키고 있다. 이를 통해 보다 많은 자동화된 Function이 실행되고 인터페이스의 서술(description)이 재사용되며 서브컴포넌트와 이와 관련된 인터페이스의 자동생성이 실현될 것이므로, BMW에서는 생산성의 확실한 진보를 기대하고 있다.
기존 모델들을 향후에 AUTOSAR에 적용시킬 경우에도 많은 AUTOSAR 개념들이 비슷한 방법으로 ASCET 인터페이스에 매핑 가능하기 때문에 문제가 생기지 않을 것이다. 요컨대 AUTOSAR 상의 “code-runnable”은 ASCET에서 사용하는 “프로세스(process)” 개념과 동등하다고 할 수 있다. 전체적으로 보면 ASCET에서 AUTOSAR를 지원할 수 있도록 각각의 애플리케이션의 인터페이스를 수정하는 작업이면 충분한 것이다. 몇 가지 기존 모델들을 이용한 실례를 고려하여 볼 때, 현재의 ASCET 버전을 사용한 경우라도 AUTOSAR 규약을 따르는 Function 모델을 만드는 데 걸린 시간은 비교적 짧다고 할 수 있다.

2009년 발표 예정인 AUTOSAR 4.0 버전은 적합성 시험, 안전장치 및 보다 Function적인 인터페이스를 포함하게 될 전망이다.