AUTOSAR ECU의 올바른 구성
AUTOSAR ECU 소프트웨어 개발을 지원하는 툴
2009년 12월호 지면기사  / 

AUTOSAR 컨소시엄에서는 ECU의 BSW(Basic Software)를 표준화한 것 외에도 다양한 XML 기반의 구성 포맷을 표준화했다. 이같은 표준화 작업은 ECU 소프트웨어의 품질과 재사용 가능성을 높이는 데 그 목적이 있다. 적절한 툴의 사용은 이러한 소프트웨어의 매우 복잡한 구성을 손쉽게 처리하는데 도움이 된다.

글│파스칼 모리저 (Pascale Morizur) * 마티아스 베르니케 (Matthias Wernicke) **
    임베디드 소프트웨어 컴포넌트, 프로덕트 매니저 DaVinici AUTOSAR 툴 라인, 프로덕트 매니저
    Vector Informatik GmbH Vector Informatik GmbH

AUTOSAR BSW는 다양한 구성 옵션을 제공하며, 특수 코드 생성기를 통해 특정 ECU의 요구사항에 맞게 수정될 수 있다. 여기서 구성 포맷은 매우 중요한 역할을 하게 되는데, 특수 AUTOSAR 툴을 사용하면 이러한 포맷에 맞는 구성 파일을 생성 및 검증할 수 있다. 이것은 나중에 ECU에 소프트웨어를 통합할 때 오류가 발생하는 것을 방지한다.
AUTOSAR 레퍼런스 아키텍처

AUTOSAR 레퍼런스 아키텍처는 AUTOSAR Layered Software Architecture[1] 문서에 설명돼 있다. 이 문서에서는 그림 1과 같이 ECU 소프트웨어를 세 가지 부분으로 나누고 있다.
쪾 기능 소프트웨어는 소프트웨어 컴포넌트들(SWC)로 구성돼 있다. SWC는 ECU와 별개로 VFB(Virtual Function Bus)에 기반해 생성되며, 인터페이스를 통해 서로 통신할 수 있다.
쪾 RTE(Runtime Environment)는 SWC를 위한 런타임 환경 역할을 하며, 실제 ECU의 VFB에 대한 기술적인 구현을 포함한다.
쪾 BSW(Basic Software) 모듈은 ECU의 기본적인 기능을 처리하며, ECU 상태 관리 또는 진단 서비스 같은 더 고급의 표준 서비스를 포함한다.

AUTOSAR 릴리즈 3.0에서는 약 50개의 구성 가능한 BSW 모듈을 정의하고 있는데, 이들 중 일부는 매우 복잡하다. 대부분의 모듈에는 이미 이전 소프트웨어 아키텍처에 있는 기능이 포함돼 있지만, 이번 릴리즈에서는 각 기능 간의 구분이 좀 더 명확해졌다. 예를 들어 통신 네트워크(CAN, LIN 또는 FlexRay), 입력 및 출력(I/O) 또는 ECU 메모리를 액세스하는 기능들이 각각 구분됐다. 운영 체제 및 다른 시스템 서비스도 마찬가지로 표준화됐다. 개별 소프트웨어의 기능들을 일관성 있게 구분함으로써 서로 다른 ECU에서 사용하는 데에 요구되는 하드웨어의 개념과 확장성을 보장받을 수 있게 된다.
RTE는 기능 소프트웨어 모듈과 BSW 모듈 간의 계층으로, SWC가 BSW 모듈의 데이터와 서비스를 액세스하는 데 필요한 모든 인터페이스를 제공한다. 또한 RTE는 운영 체제의 도움과 함께 SWC의 실행 및 다른 SWC와의 통신을 처리한다.
BSW 모듈과 RTE 모두 여러 소프트웨어 공급업체(TIER2)의 소프트웨어 제품으로 사용 가능하며, 그 중에는 모든 BSW 모듈과 RTE를 포괄하면서 AUTOSAR 릴리즈 3.0을 따른 Vector의 MICROSAR 제품도 있다. BSW 모듈과 RTE는 표준 소프트웨어 제품이지만 프로젝트별 제약 조건(OEM, 차량 모델, ECU 종류)에 맞게 수정돼야 한다. 이러한 수정 작업은 적절한 PC 기반의 툴을 이용한 구성중에 행해진다. RTE는 Vector의 DaVinci Developer 툴을 통해 구성될 수 있고 BSW 모듈은 DaVinci Configurator Pro 툴을 통해 구성 가능하다.


AUTOSAR 방식

AUTOSAR용 ECU 소프트웨어의 개발 방식은 AUTOSAR 컨소시엄에 의해 정의되었다(AUTOSAR Methodology [2]). 이 방식은 개발 프로세스를 다음과 같은 세 가지 작업으로 분류하고 있으며, XML파일을 이용해 개발 파트너들 간의 데이터 교환을 표준화하고 있다.
쪾 작업: “컴포넌트 구현”
TIER1 또는 OEM은 SWC를 정의하고, 각 SWC에 대해 “SWC Description”이라 불리는 XML 파일을 생성, 해당 인터페이스 및 리소스 요구 사항을 명시한다. 이후 TIER1 또는 OEM은 SWC 구현을 위해 관련 C 파일들을 생성한다.
 
쪾 작업: “시스템 구성”
먼저, OEM은 ECU와는 별개로 SWC에 기반해 전체 차량의 기능 범위를 정의한다. 그리고나서 통신 네트워크를 디자인하고 사용 가능한 ECU에 SWC를 배포한다. 그 결과는 “System Description”에 저장된다.

각 ECU에 대한 “System Description”은 OEM에 의해 다시 “ECU Extract of System Description”으로 축소된 후, 해당 ECU 공급업체(TIER1)에 전달된다. 이 파일은 BSW 모듈을 구성함에 있어 지금까지도 사용되고 있는 DBC, FIBEX 또는 LDF 파일을 대체한다.

쪾 작업: “ECU 디자인 및 구성”
“ECU Extract of System Description”부터 시작한 TIER1은 자신만의 SWC를 통합한다. 그 결과 한 개의 ECU에 대해 OEM과 TIER1 양쪽의 모든 SWC 설명이 포함된 완전한, 그리고 최신 상태의 “ECU Extract of System Description”이 생성된다.
ECU 구성을 위한 또 다른 사전 요구 사항으로는 BSW 모듈의 데이터 구조와 구성 가능한 모든 파라미터에 대한 설명이 포함된 “BSW Module Description” 파일이 있어야 한다는 것이다. 이러한 파일은 구현에 따라 달라지며 생성기(generator) 및 정적 코드(static code)와 함께 BSW 모듈의 일부이다.

그런 다음, TIER1은 현재의 “ECU Extract of System Description” 및 “BSW Module Description” 파일을 기반으로 초기 “ECU Configuration Description”(그림 3의 작업 2)을 생성한다. 다음으로 ECU 구성 프로세스를 시작하고 이를 “ECU Configuration Description”에 문서화한다. 이를 위해 TIER1은 적절한 툴을 사용해 BSW 모듈 및 RTE의 파라미터를 구성하고 검증한다(그림 3의 작업 3과 4). “ECU Configuration Description”은 RTE 및 BSW 모듈을 관련 생성기를 통해 ECU별로 생성하기 위한 기초 역할을 한다.
 
그림 2는 Vector의 DaVinci Developer와 DaVinci Configurator Pro 툴을 이용해 "ECU 디자인 및 구성" 작업을 구현하는 방법에 대한 예이다.



<저작권자 © AEM. 무단전재 및 재배포, AI학습 이용 금지>


  • 100자평 쓰기
  • 로그인


  • 세미나/교육/전시

TOP