AUTOSAR  OS란?

그림 1과 같이 AUTOSAR OS는 SC1~SC4까지 기능별로 나누어진다. 간단히 살펴보면, AUTOSAR OS는 OSEK/VDX 2.23 버전을 필수로 하고 있고 SC3~SC4의 Service Protection과 Memory Protection은 HIS Protected OS에서 가져온 기능들이다. 그리고 Time-Triggered Operating System의 기능을 개선하여 만든 Schedule Table이 있다. AUTOSAR OS 명세서에는 OSEK/VDX나 HIS OS에서 가져온 기능들에 대해서 설명이 생략돼 있으므로 OSEK/VDX나 HIS Protected OS의 명세서를 보지 않고는 이해하기 어렵다.
AUTOSAR OS의 가장 큰 특징은 2가지로 말할 수 있다. 첫 번째는 OSEK/ VDX에서는 1 ms 단위를 보장하는 Software Timer가 필수이고, 1 μs 단위를 보장하는 Hardware Timer는 기본적으로 제공하지 않았다. 그러나 AUTOSAR OS에서는 1 μs Hardware Timer가 필수로 돼 있다. 두 번째는 차량용 통신 프로토콜인 FlexRay를 완벽하게 처리하기 위한 Schedule Table이 필수로 새롭게 추가되었다. Schedule Table을 설명하기 앞서 AUTOSAR OS의 기본적인 개념을 설명하기로 한다.

OSEK/VDX 2.23 명세서 (2005/02/17)
http://portal.osek-vdx.org/files/pdf/specs/os223.pdf
Time-Triggered Operating System 1.0 (2001/06/24)
http://portal.osek-vdx.org/files/pdf/specs/ttos10.pdf
HIS Protected OS 1.0 명세서 (2003/07/24)
http://portal.automotive-his.de/images/pdf/StandardSoftware/his_ protectedosek10.pdf
AUTOSAR OS의 명세서: (AUTOSAR 3.1 2008/08/04)
http://www.autosar.org/download/specs_aktuell/AUTOSAR_SWS_OS.pdf

TASK의 개념

TASK는 C 언어에서 볼 수 있는 실행 함수로써 여러 개의 함수가 동시에 실행될 경우 어느 함수가 먼저 실행될 것인지 우선순위를 부여한 것이다(그림 2). 우선 순위는 보통 0~15까지 있으며, 숫자가 높을수록 우선 순위가 높다. TASK 형태는 Basic Task와 Extend Task로 분류된다(그림 3, 4).
기본적으로 AUTOSAR에서 구현할 때는 Basic Task를 많이 사용하며, Timeout과 같은 TASK 실행에 대한 시간적 제약 조건이 발생했을 경우에는 Extend Task를 많이 사용한다. 일반적으로 Extend Task가 Basic Task보다 더 느리다. 그 이유는 EVENT 처리를 하기 위한 함수를 사용하기 때문이다. AUTOSAR를 구현할 때 각각 BSW(Basic Software) 모듈별로 시간을 측정하는데, AUTOSAR OS의 복잡도에 따라서 1개의 TASK가 동작하기 위한 최소 시간이 달라진다. 예를 들어 AUTOSAR OS에서 Extend Task 기능과 Alarm 기능을 제거하면 Basic Task가 동작하는 최소 시간이 훨씬 짧아진다. 아니면, 사용하는 CPU의 클록 속도를 높이면 실행 속도가 빨라진다. NEC의 V850 CPU는 보통 1개의 TASK 기동 시간이 16~30 μs 사이가 된다.
이처럼 AUTOSAR OS를 만들면, 지원하는 CPU에 대해서 각 OS API의 실행 시간을 제공하고 여기에 맞춰 1개의 ECU에서 동작하는 AUTOSAR BSW의 시간 측정이 이루어진다(그림 2). 그리고 반도체 회사에서 제공하는 AUTOSAR OS의 버전이 바뀔 때마다 OS API의 실행 시간을 문서로 제공해야 한다.
AUTOSAR OS을 구현할 때 가장 힘든 부분은 TASK 실행 시간 단축과 Schedule Table의 완벽한 지원이다. 둘 다 ISR(=Interrupt)에 의해 영향을 많이 받기 때문에, Interrupt 처리를 어떻게 효율적으로 처리하느냐에 따라서 성능이 크게 달라진다. 참고로 AUTOSAR OS는 Interrupt 부분도 소스 코드가 자동으로 생성되므로 해당 CPU에 대한 하드웨어 지식이 많이 필요하다.

Schedule Table의 개념

Schedule Table은 Time-Triggered Operating System 1.0에서의 Time-Triggered Task 기능을 새롭게 개선하여 만든 것으로, FlexRay의 효율적인 데이터 처리를 위해 만들어진 것이라고 할 수 있다(그림 5).
AUTOSAR OS의 Alarm의 경우는 1개의 Alarm으로 1개의 TASK만 실행시킬 수 있으며 1개의 AUTOSAR OS에 여러 개의 Alarm이 있을 경우에 여러 개의 TASK가 겹쳐서 실행되는 일이 발생한다. 예를 들어 주기 10 ms Alarm에 의해서 동작하는 Task1과 주기 20 ms Alarm에 의해서 동작하는 Task2가 있을 경우 최대공약수인 20 ms에서 Task1과 Task2가 겹쳐서 실행되는 경우가 발생한다. 그렇게 되면 차량용 네트워크를 이용해서 TASK에서 데이터를 송수신할 경우 TASK 실행의 지연이 발생하므로 송수신에 대한 정해진 시간을 초과해서 데이터를 보내는 경우가 발생한다. 자동차 주행에 크게 영향을 미치는 부품의 경우 위험하다고 할 수 있다. 예를 들어 X-by-wire에서 FlexRay 통신으로 제어하는 5개의 ECU가 있다고 가정하자. FlexRay 특징으로 1 cycle에 주기 5 ms로 동시에 5개 ECU에 데이터를 보낼 경우, 정해진 시간을 초과하게 되면 원하는 시간에 차량 제어가 불가능해진다(그림 6). Schedule Table은 Alarm의 단점을 개선하여 여러 개의 TASK가 겹쳐서 실행되지 않도록 설계됐으며, AUTOSAR OS 명세서를 보면 주로 FlexRay를 위해 사용한다고 적혀 있다. 그러나 Schedule Table에 등록된 TASK가 정해진 구간 시간 내에 종료하지 못하면 그 다음 실행되는 TASK의 지연이 발생한다. Schedule Table에 등록된 TASK가 정해진 구간 시간 내에 종료가 되는지 확인이 필요하다.
표 1을 보면, Schedule Table을 사용하여 FlexRay Interface을 동작하도록 돼 있다. 필자가 실제로 구현해서 테스트를 해보았는데, AUTOSAR OS 명세서대로는 동작하지 않았다. 따라서 노하우가 필요하다. 현재 SyncScheduleTable이 제대로 구현된 AUTOSAR OS는 JASPAR에서는 본적이 없다. 그만큼 AUTOSAR OS의 전체 기능을 구현하기 어렵다는 반증이다. 필자는 Interrupt를 이용해서 Schedule Table을 동작하는 방식으로 해결을 했다.
참고로, 그림 8은 현재 AUTOSAR와 FlexRay를 이용한 자동차의 출시 계획을 보여주고 있다.

AEM_Automotive Electronics Magazine