OS에서 API 실행 시간 이슈

AUTOSAR 기반 차량 애플리케이션을 잘 설계했더라도 실제로 AUTOSAR OS 동작에서 Task나 Interrupt의 기본적인 실행 지연이 있으므로, 실행 시간을 고려하지 않으면 제대로 동작하지 않을 가능성이 높다. 또한 OS의 컴파일 옵션에 따라서도 같은 소스 코드일지라도 실행 시간이 달라진다. 그래서 JASPAR에서는 실행 속도 중심의 최적화와 RAM/ROM 사용량 위주의 최적화로 구분하여 구현을 하고 있다. 실행 속도 중심으로 가면, RAM 사용량이 많아지므로 어느 쪽을 선택할 것인지는 자동차 회사가 선택할 몫이다.
그림 1을 보면, 주기 1 msec로 동작하는 Task1이 있을 경우에 Task가 기동하기 위해 필요한 시간이 NEC 32비트 마이크로컨트롤러 V850인 경우 AUTOSAR OS에서 16~30 μsec가 소모된다. 그러므로 그림 2와 같이 Task가 여러 개 있을 경우는 애플리케이션을 안전하게 실행하기 위한 여유 시간의 고려가 필요하다. 참고로 Task1을 종료하기 위한 시간도 걸린다.
AUTOSAR OS는 Interrupt에 우선순위를 설정해 제어하는 명세 규약은 없지만, 일본에서는 많이 사용하는 독자 기능이다. 그러나 JASPAR의 연구 결과 AUTOSAR OS에서 Interrupt의 우선순위를 설정하는 기능을 제공하면, Interrupt 실행 시간이 5~10 μsec 지연되는 것을 실제 테스트를 통해 알게 되었다. 그래서 지연 시간을 최소하기 위해 Interrupt 우선순위를 설정하는 기능을 삭제하고 Interrupt의 베타 제어를 통한 애플리케이션 개발자가 직접 설정하여 처리하는 방향으로 가고 있다.
이처럼 AUTOSAR OS에서는 OS 자체 API의 실행 시간에 대한 정확한 측정을 요구한다. OEM(=자동차 제조회사)이 원하는 기능의 제품을 서플라이어(=부품업체, SW업체)가 안정성 있게 만들기 위해 설계와 테스트, 시간 측정이 필요하지만 AUTOSAR 3.1로는 기능이 부족하다. 쉽게 말해 AUTOSAR 3.1에서는 자동차 전장 부품의 설계에서, 이러한 시간 제약적 공간에서 이런 기능을 구현하고 싶다고 보충 설명할 수 있는 부분이 없다.

AUTOSAR 4.0에서 TIMMO

그림 2와 같이 Task를 여러 개 실행할 경우, 시간을 측정해 Task나 Interrupt를 실행함에 있어서 원하는 동작을 하기 위한 시간적인 제약이 없는 지 확인하고, 정해진 시간 내에 원하는 동작이 이루어질 수 없는 경우에는 설계 변경을 위해 설계자와 개발자의 협의가 필요하다. 그림 3, 4와 같이 ECU 간 통신이 있을 경우 설계가 더욱 더 복잡해진다.
현재 JASPAR에서는 설계자와 개발자의 협의(=OEM과 서플라이어)에 대한 의사 전달에 어려움이 많다. AUTOSAR에서는 OEM이 전반적인 설계를 하고, 서플라이어가 OEM이 원하는 전장 부품을 만든다. 이와 비슷하게 유럽에서도 같은 상황이 벌어지고 있다. 그 대안으로 AUTOSAR에서 나온 기능이 Timing Model(TIMMO)이며, 현재 AUTOSAR 3.1에서 부족한 디자인 설계 기능을 보완함으로써 설계자와 개발자의 협의(=OEM과 Supplier)가 잘 되도록 도와준다. TIMMO는 각 실행하는 Task, Interrupt, ECU 간 통신의 실행 시간을 상세하게 디자인 설계하도록 해주며 자동차의 핵심 기술인 ABS, steer-by-wire, 엔진 제어, 트랜스미션, 정속 주행(cruise), 보안(security) 등에 대한 디자인 설계 방법에 대해서도 기술하고 있다.
자세한 사항은 TIMMO 웹사이트를 참조하기 바란다.

AUTOSAR 산하 TIMMO(=TIMing Model)
웹사이트: https://www.timmo.org
기본 설명:
https://www.timmo.org/pdf/TIMMO_Brochure_ V10b.pdf
AUTOSAR 4.0에 Specification of Timing Extensions로 추가됨.
과연 AUTOSAR OS는 반드시 필요한가?

AUTOSAR OS는 자동차 고성능 부품을 안전하게 동작시키기 위해서는 필요하나, 자동차 바디 계열이나 간단한 CAN 통신을 사용하는 부품인 경우에는 필요치 않다. 그래서 JASPAR의 경우는 AUTOSAR OS를 사용하지 않는 경우에 대해서도 JASPAR 독자 명세를 만들었다. 간단히 설명하며, 그림 7과 같이 된다.
AUTOSAR OS가 없는 경우에는 1개의 Task가 1개의 함수로 되며, Interrupt Timer가 1 μsec를 제공해 독자 기능의 BSW Scheduler에서 각 함수를 정해진 시간별로 Polling 방식(=순차적으로 함수 실행)으로 함수를 실행시킨다. 그리고 기존의 AUTOSAR RTE에서 OS 없는 환경에서 동작할 수 있도록 JASPAR에서 독자 기능의 RTE도 구현했다. 필자가 직접 개발해 본 결과, 실행 시간 지연은 거의 없는 것이 장점이다.
OS 없는 상황에서의 JASPAR RTE를 간단히 설명하면, OS configuration에서 설정한 xml 정보를 읽어서, RTE Generator가 직접 BSW Scheduler의 소스 코드를 생성한다. OS의 XML 정보가 필요한 이유는 함수(=TASK)의 주기적인 실행 시간과 우선순위, Interrupt를 자동 등록하기 위해서다. 즉, AUTOSAR OS는 필요 없어도 OS.xml 정보는 필요한 것이다. 참고로, JASPAR에서는 AUTOSAR에 없는 여러 가지 독자 명세를 만들고 있기 때문에 일본 진출을 희망하는 부품회사나 SW업체의 경우에는 JASPAR 독자 명세에 대한 이해가 필요하다. 실제로 유럽 관련 AUTOSAR 업체들은 JASPAR에서 활동하고 있는 업체들과 협력해 일본 JASPAR 명세에 맞춰 일본 수출을 준비하고 있다. 따라서 한국 자동차 관련 업체들도 일본 수출을 위해서는 준비가 필요하다.