OSEK - 역사

CLASSIC AUTOSAR를 이해하기 위해 먼저 OSEK을 이해하는 것이 좋다. 왜냐하면 CLASSIC AUTOSAR는 OSEK을 확장한 개념이기 때문이다.

 

플랫폼 통합의 효과

현재 휴대폰 운영체제는 크게 안드로이드와 IOS로 나뉜다. 개발자가 애플리케이션을 개발하고 싶을 경우, 안드로이드용 따로 IOS용 따로 두 번 작업해야하는 번거로움이 있다. (크로스 개발이나 변환 도구를 사용한다고 해도 결국 두 애플리케이션은 본질적으로 같지 않다.)

모든 휴대폰 운영체제가 동일하다면 애플리케이션 개발자들이 훨씬 개발에 집중하고 중복된 일을 줄일 수 있을 것이다.

 

자동차에 들어가는 전자 부품도 휴대폰과 다를 바 없다. 동일한 제어기를 동일한 회사에서 개발할 경우 하드웨어에 따라 플랫폼이 달라지고 달라진 플랫폼에 따라 동일한 애플리케이션을 중복해서 개발해야 했다. 서로 다른 회사에서 제조된 제어장치들간 비표준화, 비호환성은 말할 것도 없다. 만약 자동차에 들어가는 모든 제어장치가 동일한 플랫폼을 공유한다면 어떨까? 구현에 대한 독립성 보장에 따른 애플리케이션의 재사용성을 증가할 것이고 비용 절약 및 소프트웨어 질적 향상을 얻을 수 있을 것이다.

 

OSEK/VDX의 시작

차량용 제어장치가 점점 증가하면서 독일 자동차 산업계와 프랑스 자동차 산업계는 위와 같은 문제를 해결하고자 노력했다. OSEK(Offend Systeme und deren Schnittstellen fur die Elektronik im Kraftfahzeug)은 1993년 5월에 차량용 분산 제어 장치의 공개 아키텍처에 대한 산업표준화를 목표로 독일 자동차 산업계 공동 프로젝트로 설립되었다. 비슷한 시기에 프랑스 자동차 산업계도 VDX-approach(Vehicle Distributed eXcutive)라는 유사한 프로젝트를 진행하고 있었다.

이 후 1995년 10월 OSEK/VDX 그룹이 OSEK과 VDX간 조정된 사양을 발표하였고, 1997년 10월에 정식적으로 사양을 공개했다.

 

이를 통해 응용 소프트웨어와 독립적이고 추상적인 인터페이스 사양, 하드웨어와 네트워크에 독립적인 사용자 인터페이스 사양, 아키텍처의 효율적인 설계, 기능에 대한 검증과 선정된 시험 프로젝트의 프로토타입의 구현이 가능한 아키텍처 표준화를 이루고자 하였다.

 

OSEK/VDX에서 소개한 공개 아키텍처는 다음과 같이 3가지 분야로 구성된다.

1. COM : 통신(제어장치 내부 및 외부 데이터 교환)
2. OS : 운영체제(ECU 소프트웨어의 실시간 실행과 다른 OSEK/VDX 모듈에 대한 기반)
3. NM : 네트워크 관리(구성 결정 및 모니터링)

네트워크 관리를 제외한 통신과 운영체제는 두가지로 나뉜 표준안이 있다.

1. 일반적인 요구사항에 대한 정의를 내리는 표준안
2. 시스템 고장에 대한 처리를 고려하여 안정성을 중요하게 여기는 특별한 요구 사항에 대한 정의를 내리는 표준안

 

정리하면 OSEK 자체는 운영체제라기보다 POSIX와 같이 차량용 운영체제가 지원해야 할 표준 사양 및 API 규격의 정의이다. 따라서 OSEK을 지원하는 다양한 운영체제가 존재할 수 있다.