0. AUTOSAR (오토사) 시작하기

 

최근 AUTOSAR 개발은 어느 OEM/Supplier에서나 화두인 것 같다. AUTOSAR(AUTomotive Open System ARchitecture)로 개방형 자동차 표준 소프트웨어 구조라고 한다. 항상 정의까지만 보고 더 이상 보지 않다 보니 두루뭉술하게 아는 느낌이라 공부를 시작 해 보고자 한다. 이번에 AUTOSAR 프로젝트도 시작했다.

 

정의는 매우 짧게 갈 것이다! 웹사이트를 여러 군데 뒤져 보고 오토사 공식 문서를 요약하는 방식으로 포스팅할 예정이다.

 

0. 오토사(AUTOSAR)란?

AUTOSAR(AUTomotive Open System ARchitecture)로 개방형 자동차 표준 소프트웨어 구조이며, BMW, 보쉬, 콘티넨탈, 포드, PSA, 폭스바겐 등의 회사에서 함께 만든 아키텍처이다.

 

1. AUTOSAR 구조 이해하기

구조를 살펴보면 Application / RTE / BSW(RTE와 Microcontroller 사이) / Microcontroller로 구성된다.

쉽게 얘기하면, Microcontroller -> BSW -> RTE -> Application 구조로 정의하고 있다. 당연한 구성이다.

 

각 계층은 다음과 같다.

Application: 각 기능에 대해 소프트웨어 구성 요소 SWCs로 구성된 최상위 계층. 여기서 SWCs는 이후 중요하게 다루어진다. Software를 구성하는 부품을 의미하며 독립적인 기능을 갖는 모듈을 의미한다.

RTE(Real Time Environment): 런타임 환경이라고 하는데, 프로그램이 실행되는동안 필요한 기능을 제공하는 환경이라고 보면 된다. 이 때 '필요한 기능'은 크게 두 가지이다.

1) SWC 간의 통신을 지원한다. SWC간의 통신 시 RTE를 통해 통신해야한다. 이 때 SWC는 Port를 통해 통신한다.

2) BSW와 통신한다. Microcontroller 제어 또는 접근이 필요할 때 RTE를 통해 BSW에 접근한다.

Service Layer: 어플리케이션이 사용할 수 있는 서비스를 제공한다. 메모리 서비스, 통신 서비스, 시스템 서비스 등이 있다.

ECU Abstraction Layer: ECU 관련 추상화 계층이다. ECU 관련된 추상화를 제공한다. I/O Hardware Abstraction layer, On board device abstraction, Memory hardware Abstraction 등이 있다.

 

Abstraction는 추상화인데, 추상화가 말이 어렵지만 실제로는 복잡한 부분들을 가려주고 쉽게 표현해주는 계층이라고 보면 된다. 예를 들어, 유저는 키보드 Hardware를 사용할 때 드라이버 접근에 대한 복잡성이 보이지 않고 단순히 키보드를 사용만 편하게 사용하는데, 이를 추상화라고 할 수 있다.

 

MCAL(Micro Controller Abstraction Layer): 마이크로 컨트롤러 하드웨어 주변장치들과 소통하는 계층이다. 주변장치도 용어가 어렵지만 쉽게 얘기해서 voltage 가져오는 주변 장치(adc) 등이 있고, 필요에 맞게 장치를 사용한다는 얘기이다.

 

2. AUTOSAR의 필요성?

몇 가지 이유가 있지만 표준화에 대한 가장 큰 이유는 지금껏 각 제조사들에 맞춰 중구난방일 수 밖에 없던 개발을 해왔고, 이에 따라 코드 이식성이 매우 낮다. 게다가 임베디드 특성상 하드웨어가 다르면 이에 대응되는 소프트웨어도 달라져야하므로 코드 이식성도 매우 낮다. 이를 표준화/모듈화해서 이식성을 높이려는 것이다. 특히 Application 영역은 하드웨어와 독립적으로 작성할 수 있기 때문에 이식성이 매우 높아진다. 이러한 점은 Application에서 특히 부각되는 것 같고, BSW에서도 서비스와 같은 부분은 동일할 것으로 판단된다. 다만 MCAL 등 HW dependent한 부분은 작업이 여전히 필요할 것으로 보인다.

 

3. AUTOSAR의 종류

	Classic AUTOSAR	Adaptive AUTOSAR
통신	CAN, LIN 사용	이더넷, SOME/IP 사용
특징	칩 내장 기능 사용	고성능 및 계산 집중된 프로세스 사용
제품	엔진, 브레이크 등등	Over-The-Air updates (OTA), 센서 퓨전 등
모듈화 여부	전체 코드 수정 필요	일부 코드만 수정 가능 (모듈화)
리얼타임 조건	Deadline 매우 중요하며 리얼타임 요건 만족해야함	ms의 리얼타임 프로세스 가능
언어	C	C++
OS 여부	OS가 반드시 필요한 것은 아님	POSIX operating system
어플리케이션 통신 및 스케쥴링	RTE를 통해 스케쥴링하고 다른 소프트웨어 부품(SWC)과 통신함	OS를 통해 다른 소프트웨어 부품(SWC)과 통신하고 스케쥴링함

 

아무래도 통신 여부와 언어, OS 여부만 보면 될 것 같다.

통신은 통신량 증가에 따라 CAN에서 이더넷도 많이 추가되고 있다. 이는 실질적으로 Classic AUTOSAR와 Adaptive AUTOSAR가 획일적으로 CAN / 이더넷 나눠서 사용한다기보다는 요구하는 기능에 따라 달라진다. 보통 Adaptive AUTOSAR가 다루는 기능이 데이터 프로세스를 훨씬 많이 필요로 하므로 이더넷은 기본적으로 사용하는 것이고, Classic AUTOSAR에서도 이더넷을 사용하는 경우를 당연히 볼 수 있다.

언어는 C / C++을 각각 쓰는데 Adaptive AUTOSAR 예제들을 보면 클래스와 클래스 상속, namespace 활용도가 높은 것을 알 수 있다. 물론 엔지니어 능력에 따라 C++ 활용도는 훨씬 높아질 수 있다. 사실 엔지니어 능력보다는 회사 시스템에 따라 달라지는 것이 크겠다.

OS 여부가 가장 중요한데, 기존 Classic AUTOSAR의 경우 OS가 없어서 스케쥴링을 담당하는 모듈이 따로 있거나 아니면 매우 소형 OS가 들어가 있었으나 Adaptive AUTOSAR로 가면서 POSIX OS를 사용한다. 흔히 유닉스 계열을 생각 해 볼 수 있고 Linux가 가장 이해하기 쉬울 것이다. 즉, Linux도 공부해야한다.