AUTOSAR는 OSEK을 기초로 제작됐기 때문에 OSEK의 디버깅 방법을 이해한다면 AUTOSAR의 적용은 어렵지 않다. TRACE32는 임베디드 시장 표준 도구로 사용되는 디버깅 툴이다. 다양한 마이크로 프로세서와 컴파일러를 지원하며, 어떤 플랫폼을 사용하더라도 동일한 GUI에서 디버깅할 수 있는 환경을 제공한다.

글│성 명 준 과장 <myungjun@mdstec.com>
MDS테크놀로지, DT사업부

복잡한 소프트웨어를 잘 관리하고, 소프트웨어의 재활용성을 높이기 위해 제안된 것이 바로 AUTOSAR다. AUTOSAR는 전장 소프트웨어의 아키텍처와 개발 방법론을 표준화하는 것을 목표로 제안된 공개 표준으로 자동차 전장의 많은 분야에 적용될 것이다.
OSEK은 차량용 전자 제어장치에 사용하는 소프트웨어의 공개 아키텍처다. 독일의 대표 자동차 개발사들이 중심돼 시작된 프로젝트로 ‘Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahrzeug (영어로는 Open Systems and their Interfaces for the Electronics in Motor Vehicles)’를 의미한다. 최근에는 OSEK을 기초로 작성된 AUTOSAR가 사용되고 있으며, OSEK은 더 이상 업데이트가 이뤄지지 않고 있다. 최신 트렌드가 AUTOSAR이지만 OSEK을 기초로 제작됐기 때문에 OSEK의 디버깅 방법을 이해한다면 AUTOSAR의 적용은 어렵지 않다.
OSEK은 OSEK OS, OSEK COM, OSEK NM, OSEK OIL, OSEK RTI로 구성돼 있다. 이중 OSEK RTI는 ORTI라고도 하며, OSEK Runtime Interface의 약어로 타깃에서 동작하는 OS의 현재 상태를 쉽게 파악할 수 있도록 정보를 제공한다. 내용은 TEXT로 되어 있으며, 디버깅에 사용하는 도구가 ORTI를 이해할 수 있도록 되어있다면 어떤 툴이든 사용이 가능하다. ORTI는 일반적으로 OSEK Generator에서 OIL을 이용해, 소스 코드를 생성하는 과정에 함께 생성된다. 툴에 따라서는 Generator 옵션으로 설정이 가능하고, 몇몇 OSEK의 경우 OIL에 ORTI가 생성되도록 설정하면 된다.

ORTI는 OSEK이 Implementation 표준이 아니라 Interface 표준이기 때문에 디버깅의 효율을 높이기 위해 필요하다. 일반적인 운영체제는 Implementation 표준을 제공하기 때문에(Implementation 표준을 제공하는 운영체제라고 하더라도 CPU 아키텍처에 종속적인 부분은 다른 코드를 제공한다), 동일한 소스 코드를 갖고 있는 반면, Interface 표준만 제공하는 OSEK은 제조사마다 제공하는 소스 코드가 다르다. 예를 들어 Task의 이름을 MySample이라는 이름으로 정의하면, MySample Task는 Generator에 따라서 tskMySample,  funcMySample, OSEKOS_T _MySample과 같이 다양한 형태로 생성된다. 이로 인해 디버깅 과정에 Task를 찾거나 현재 상태를 확인하는 것이 어렵다. 그림 2처럼 작성한 것과 다른 이름으로 나타나면 디버깅이 쉽지 않게 된다.
TRACE32는 임베디드 시장 표준 도구로 사용되는 디버깅 툴이다. 다양한 마이크로 프로세서와 컴파일러를 지원하며, 어떤 플랫폼을 사용하더라도 동일한 GUI에서 디버깅할 수 있는 환경을 제공한다. 이러한 장점은 자동차 시장처럼 다양한 플랫폼을 사용하는 엔지니어에게 툴을 다시 학습할 필요가 없는, 다시 말해 어떤 플랫폼을 사용하더라도 바로 업무에 활용할 수 있도록 하는 장점을 제공한다. 그리고 TRACE32에서 제공하는 다양한 기능은 소프트웨어의 문제 원인을 쉽게 찾고, Board Bring-up부터 최종 양산에 이르기까지 다양한 개발 단계에서 모두 적용할 수 있다.
추가로, TRACE32에서는 OS Awareness 기능을 제공한다. OS Awareness라는 타깃에서 동작하는 운영체제의 정보를 쉽게 관찰할 수 있는 기능을 제공한다. OSEK OS 또한 TRACE32의 OS Awareness 기능을 쉽게 디버깅을 할 수 있다. OSEK OS의 제조사와 사용하는 마이크로 프로세서가 다르더라도, 동일한 OSEK의 정보를 관찰할 수 있다.
그림 2에서와 같이 Task의 이름이 바뀌더라도, 다양한 상태 정보를 빠르게 관찰할 수 있다. 뿐만 아니라, 운영체제가 가지고 있는 다양한 리소스도 동일한 방식으로 제공한다. 그림 3의 내용처럼, 운영체제가 가지고 있는 모든 리소스를 한 눈에 관찰이 가능하다. 특히 이 내용은 디버깅 심볼 정보에 의존할 경우 Task나 모든 리소스의 정보가 OIL을 작성할 때와 다르게 나타나는데, ORTI를 참고해 출력하면 OIL에 작성할 때와 동일한 형식으로 나타나 현재 운영체제의 상태를 더 빠르게 관찰할 수 있다.
이러한 ORTI는 KOIL(Kernel Object Interface Language)로 작성됐다. KOIL 문법은 C의 구조체를 작성하는 것과 유사하다. KOIL은 Declaration Section과 Information Section으로 구분된다. Declaration Section은 Kernel Object가 가지는 속성(Attribute)이 열거되며, Information Section에서는 해당 정보를 실제 Kernel에서 어떤 Symbol 정보를 참조해야 하는지 알려준다.
그림 4에서 Implementation Section에서 TASK의 두 번째 속성은 TASK의 상태정보이다. 만일 현재 상태를 확인하려면, InitTask는 OSEKOStaskStatus[1]&03 값을 참고하면 된다. Cyclic의 경우 OSEKOStaskStatus [2]&03 값을 참고하면 된다. 만일 OSEKOStas kStatus[1]&03가 0이면 InitTask는 ‘SUSPENDED’ 상태이며, 2이면 ‘RUNNING’ 상태가 된다.

TRACE32의 OS Awareness 기능은 OSEK OS에서 제공하는 정보를 더욱 정밀하게 관찰 할 수 있다. 예를 들면, OSEK에서는 ErrorHook을 이용해, 문제가 발생하면 특정 변수에 문제의 정보를 기록해 둘 수가 있다. 만일 시스템에서 문제가 발생하면 gErrorCode라는 전역 변수에 Error Code를 기록하도록 코드를 작성하고, gErrorCode의 값이 1이면 “System Error”로 정의하고, 2이면 “Application Error”로 정의하면 그림 5와 같이 ORTI를 작성할 수 있다.

만일 시스템에 문제가 발생하면, 시스템을 멈추고 Error Code 내용을 그림 6과 같이 출력할 수 있다.

전장 소프트웨어는 시간이 갈수록 그 복잡도가 높아질 것이다. 이러한 소프트웨어 디버깅은 점차 개발자에게 많은 양의 데이터를 이용해 디버깅하는 환경을 요구하게 된다. 특히, 본문에서 활용한 OSEK보다 AUTOSAR는 더 많은 양의 데이터가 개발자에게 제공된다. 이러한 정보는 체계적으로 관찰하지 않으면, 소프트웨어 개발이 매우 어려워진다. 하지만, TRACE32의 OS Awareness는 소프트웨어의 많은 데이터를 체계적인 정보로 제공한다. 복잡한 소프트웨어를 개발하는 과정에 매우 편리한 디버깅 기능을 제공함으로써 필요한 정보를 보기 위한 소비적인 프로세스를 줄일 수 있다.

AEM_Automotive Electronics Magazine