일렉트로비트(Elektrobit, EB)는 최초로 AUTOSAR 4.0 솔루션을 개발해 차량에 적용한 기술력을 바탕으로 새로운 AUTOSAR 표준에 발빠르게 대응하고 있다. EB가 갖고 있는 그 동안의 개발 노하우를 기반으로 한 EB tresos는 완성도 높은 AUTOSAR 프로젝트 개발에 있어 실질적 방안을 제시할 것이다.

AUTOSAR는 유럽 자동차 회사와 주요 서플라이어가 주축이 돼어 개발한 개방형 차량 소프트웨어 표준이다. 기존의 차량 소프트웨어 개발 방법은 특정 하드웨어와 소프트웨어가 종속적인 관계를 가지게 되어, ECU에 기능을 추가하거나 하드웨어 규격이 변경되면 ECU를 처음부터 다시 개발해야 하므로 개발 시간과 비용이 많이 소요되는 문제가 있었다. AUTOSAR는 이러한 문제를 해결하기 위해 ECU의 소프트웨어를 그림 1처럼 SoftWare Component(SWC) 파트와 Basic SoftWare(BSW) 파트로 구분하고 각각의 컴포넌트를 모듈화 하는 방법을 채택했다. 또한 SWC와 BSW 사이에 RTE(Run-Time Environment)라는 인터페이스 계층을 두었는데, RTE는 Virtual Functional Bus(VFB)라는 개념을 실제로 구현한 계층으로, 이를 통해 SWC와 BSW 간의 통신이 이뤄진다. RTE는 Client/Server와 Sender/Receiver 통신 모델을 지원한다. Client/Server 모델은 미리 정의된 서비스를 Client SWC가 Server SWC에 요청하고, 그에 따른 결과를 수신하는 통신 방식을 의미한다. Sender/Receiver 모델은 Sender SWC가 데이터를 배포하며 Receiver SWC는 배포된 데이터를 수신하게 된다. AUTOSAR에서는 RTE가 모든 SWC 사이의 통신을 책임지게 되며 SWC들은 동일 ECU에 있을 수도 있고 다른 ECU에 존재할 수도 있다. 이러한 RTE를 통한 통신 시스템은 SWC나 BSW가 교체되거나 새로운 모듈이 추가되더라도 약간의 매핑(mapping) 과정과 설정(configuration) 과정을 통해 새로운 ECU 소프트웨어를 쉽게 개발할 수 있도록 해준다.



AUTOSAR 표준은 기존 모듈의 재사용과 새로운 기능 추가를 위해 계속해서 업데이트되고 있으며 현재 버전 4.0.3이 배포됐다. 내년에 4.1.1 버전을 통해 이더넷(Ethernet)을 포함한 추가적인 장치들을 지원할 예정이다.

AUTOSAR 시장 동향
2011년까지 약 2,500만 개의 ECU가 AUTOSAR를 적용해 개발됐으며 2016년까지 3,000만 개의 ECU가 AUTOSAR를 기반으로 개발될 전망이다. 또 거의 모든 OEM이 2013년 이후에는 AUTOSAR 3.2 또는 4.0 버전의 규격을 사용하겠다고 밝혔다(그림 2). BMW를 선두로 Volvo나 GM 등은 AUTOSAR 4.0.3을 기반으로 차량 개발을 진행하고 있다. 또한 더 많은 업체들이 AUTOSAR 4.0 기반의 개발을 이미 시작했거나 앞으로 지원할 예정이다.

AUTOSAR 개발 방법론
AUTOSAR 개발 방법론(methodology)은 AUTOSAR 시스템을 개발하기 위해 시스템 설계 단계부터 ECU 개발 단계까지 모든 과정의 개발 방법을 의미한다. 하지만 이 과정에 포함되는 차량 제어 알고리즘은 포함하지 않는다.



그림 3은 OEM과 서플라이어 간의 개발 방법에 대해 나타내고 있다. 기존에 OEM은 문서를 통해 시스템 요구사항을 서플라이어에 전달했다. 반면, AUTOSAR에서는 System Configuration Description 파일로 제공한다. System Configuration Description은 OEM의 요구사항이 담겨 있는 애플리케이션 SWC 기술 정보와 BSW 기술 정보 등을 포함하며, XML 기반의 AUTOSAR 표준 포맷인 ARXML로 작성된다. ARXML 안에는 애플리케이션 SWC의 알고리즘 정보는 포함되지 않기 때문에, 애플리케이션의 상세한 알고리즘 정보는 기존의 소스 코드나 오브젝트 파일 형태로 서플라이어에 전달한다. 서플라이어는 OEM으로부터 전달받은 System Configuration Description 파일을 바탕으로 BSW 내의 모듈에 대해 설정 및 매핑 작업을 한 후, 컴파일 및 링크 과정을 통해 최종 플랫폼에 맞는 바이너리 파일을 생성한다.

AUTOSAR 개발 툴 체인 및 방법
위에서 설명한 AUTOSAR 표준 개발 방법론을 바탕으로 실질적인 개발을 하기 위해서는 크게 SWC 개발 툴과 BSW 개발 툴이 필요하다. SWC 개발 툴은 세부적으로 애플리케이션을 기술하는 툴과 그 안에 들어가는 알고리즘을 개발하는 툴로 세분화된다.
OEM은 ECU 내 자신들의 요구사항에 따라 필요한 애플리케이션 SWC를 개발한다. 이 SWC는 데이터 타입, 포트 정보, 인터페이스와 같이 애플리케이션 기능을 수행하기 위한 모든 정보를 포함하며, 이러한 것을 SWC description이라고 한다. OEM의 요구사항과 SWC ARXML 파일, 그리고 알고리즘 관련 소스 코드나 오브젝트 코드를 전달받은 서플라이어는 System Description 과정을 거치게 된다. System Description에는 특정 ECU에 관련된 태스크 스케줄링, 사용되는 BSW 모듈들, BSW configuration 정보, 그리고 태스크에 의해 동작하는 Runnable들의 내용 등이 포함된다.
위의 모든 정보들이 작성되면 최종적으로 RTE를 중심으로 SWC들과 BSW 간의 매핑 과정을 수행한다. 매핑 과정을 통해 RTE는 동일한 ECU 내의 서로 다른 SWC 간에 데이터를 주고받을 수 있도록 하거나 서로 다른 ECU에 존재하는 SWC 간에 통신이 이루어지게 한다. 특정 SWC가 데이터를 전송하려고 포트에 접근하면, RTE는 특정 SWC의 포트와 매핑된 BSW 모듈의 포트에 정보를 수신할 준비를 시킨다. 또한 RTE는 BSW의 하위 계층으로부터 수신된 데이터를 적절한 SWC로 전송하기 위해 위의 반대 과정을 수행한다. 이러한 과정을 통해 동일한 ECU 내의 통신 및 서로 다른 ECU 간의 통신이 이루어지게 된다.
지금까지 AUTOSAR의 기본적인 동작 원리에 대해 설명했다. 이를 바탕으로 SWC 개발 툴과 EB tresos를 사용해서 실제로 개발하는 과정을 살펴본다.

SWC 툴과 EB tresos를 이용한 AUTOSAR 개발
EB tresos는 ECU 소프트웨어 중 SWC 개발 부분을 제외한 RTE를 포함하여 하위 BSW 모듈들에 대한 configuration 및 generation을 제공한다. 따라서 SWC 개발을 위해 dSPACE의 SystemDesk와 IBM의 Rhapsody를 이용해 SWC ARXML 파일을 생성했으며 EB tresos에 입력(import)하여 BSW configuration과 매핑을 수행하는 환경을 구축했다.



기본적으로 AUTOSAR SWC는 RTE를 거치지 않고 직접 하드웨어나 BSW 모듈에 접근할 수 없기 때문에, SWC들은 자체적으로 스레드나 프로세스를 처리할 수 없다. 그래서 SWC의 기능을 수행하기 위해 Runnable들을 구성하며, 이를 통해 SWC의 스케줄링을 처리하게 된다. 쉽게 말하면, Runnable은 AUTOSAR SWC의 수행 단위이며 C나 C++로 작성된 기능 함수라고 할 수 있다. 하나의 SWC 안에는 여러 개의 Runnable이 존재할 수 있으며 타이머 이벤트, 서버 호출 이벤트, 데이터 동작 이벤트 등을 통해 Runnable이 수행된다. 또 이러한 Runnable 간 전역 변수인 Inter-runnable variable이 존재한다.



여기서 소개하는 ECU 소프트웨어는 2개의 CAN 장치(CAN ID: 0x100, 0x110)가 주기적으로 데이터를 주고받는 시스템으로, SWC는 크게 3개의 Application Software Component (SWC_ModifyEchoSWC, SWC_CyclicCounter SWC, SWC_IoHwAbsSWC)로 구성되며 대표적으로 Cyclic()과 ModifyEcho()라는 2개의 runnable을 사용한다. Cyclic()은 Rte_Time_ Task에 의해 1초 간격으로 실행되며 Inter-runnable Variable인 CurrentCounterValue 값을 1씩 증가시키고 Com 포트로 데이터를 전송한다. ModifyEcho()는 신규 데이터 입력 이벤트가 발생한 경우 Rte_EvenTask에 의해 호출되며 SWC_CyclicCounter에 새로운 카운터 값을 전달한다. 또한 ModifyEcho()는 CAN-ID(0x100)로부터 Cyclic()의 Current CounterValue 값을 수신한다. 그 후 CAN-ID(0x110)로 데이터를 전송하는 기능을 수행한다.



앞서 언급한 EB tresos는 RTE 생성에서부터 BSW의 각 모듈 설정, 그리고 SWC와 BSW 간의 매핑을 도와주는 소프트웨어다. 그림 7에서 보이는 바와 같이, EB tresos 상에서 필요한 BSW 모듈들과 SWC 개발 툴에서 생성한 ARXML 파일 및 커뮤니케이션 매트릭스 파일(DBC, FIBEX 등)을 입력하여 BSW configuration 환경을 구축한다.
BSW configuration에서 가장 중요한 RTE 매핑은 크게 3가지가 있다.

1) 이벤트 매핑
Runnable들은 RTE 이벤트에 의해 실행되며 각 Runnable들은 OS 태스크에 매핑이 된다. 이벤트 매핑 또는 Runnable 매핑은 SWC에 의해 정의된 Runnable들을 AUTOSAR OS에서 선언한 태스크들과 연결시켜주는 작업을 말한다. 본 시스템에서 생성한 ModifyEcho()는 데이터 수신 이벤트가 발생하면 동작하도록 Rte_Event_Task와 매핑을 시킨다. 그리고 Cyclic()은 Rte_Time_Task와 매핑 시켜서 매 1초 간격으로 동작하도록 설정된다.

2) 데이터 매핑
데이터 매핑은 이벤트 매핑과는 별도로 통신 버스의 시그널 또는 시그널 그룹들과 SWC에서 구현한 포트들을 매핑 시키는 과정이다. SWC_ModifyEcho 컴포넌트에서 새로운 데이터를 수신하기 위해 생성한 R_NewCounterIn 포트와 SGCounterIn_256R 시그널을 매핑하고, 데이터 출력을 위해 SWC_CyclicCounter 컴포넌트의 P_CounterOut 포트에 SGCounter_272T를 매핑 한다.


 

3) 서비스 포트 매핑
서비스 포트 매핑은 BSW에서 제공하는 서비스 포트들을 적절한 애플리케이션 컴포넌트와 포트에 매핑하는 과정을 말한다. 설정 창의 Application components and port mappings 테이블은 SWC ARXML에서 생성한 애플리케이션 컴포넌트 및 포트 정보들이 목록으로 보이며, 서비스 설정 테이블에는 BSW에서 제공하는 서비스 모듈의 포트 정보(Det, BswM, ComM)가 나열되어 있다. 우선, BSW 서비스 모듈 설정이 끝나면 서비스 포트 매핑 부분에서 알맞은 Application component와 포트에 매핑을 시켜준다. 이벤트 매핑, 데이터 매핑, 그리고 서비스 포트 매핑 단계를 마치면 여러 BSW configuration 중 중요한 RTE configuration 과정이 완료된다.
모든 매핑 과정이 끝나면 입력한 SWC와 BSW가 동작할 수 있도록 OS에 이벤트와 스케줄 테이블을 구성해준다. EB tresos에서는 Update Service Components and BswM Descriptions 설정 버튼을 통해 자동으로 환경을 설정해준다. 이 과정이 끝나면 모든 BSW 관련 configuration 과정이 마무리되고 최종적으로 generate를 통해 BSW description 파일 및 소스 코드를 생성한다. 이 후 타깃 플랫폼에 맞는 컴파일러를 통해 bin 또는 hex 파일을 생성해 최종 ECU에 포팅하는 과정을 마치면 모든 AUTOSAR 개발이 끝나게 된다.
AUTOSAR 시스템은 개발이 완료된 모듈을 재사용할 수 있는 장점을 바탕으로 전체적인 연구개발 기간을 단축할 수 있고 비용을 절감할 수 있는 장점을 갖추고 있다. 또한 OEM과 서플라이어가 보유하고 있는 고유의 기술력을 바탕으로 더 안정된 시스템을 구축할 수 있다. 이러한 장점을 바탕으로 AUTOSAR는 선택사항이 아닌 의무사항으로 바뀌고 있다. Elektrobit은 최초로 AUTOSAR 4.0 솔루션을 개발하여 차량에 적용한 기술력을 바탕으로 새로운 AUTOSAR 표준에 발 빠르게 대응하고 있다. Elektrobit의 개발 노하우를 기반으로 한 EB tresos는 완성도 높은 AUTOSAR 프로젝트 개발에 있어 실질적 방안을 제시할 것이다.

AEM_Automotive Electronics Magazine