지난 2014년 이타스코리아는 아주대학교와 자동차 소프트웨어 인력양성을 위한 산학협력 업무협약(MOU)을 체결하고 아주대학교 소프트웨어융합학과에 개설된 소프트웨어 융합 프로젝트 교과목에 자동차 전장장치 소프트웨어 개발을 위한 AUTOSAR 툴체인(ISOLAR-A, ISOLAR-EVE, RTPC-EVE)과 모델링 개발 툴 ASCET을 공급했다. 2011년 아주대학교가 유치한 미래창조과학부 정보통신산업진흥원 주관대학 소프트웨어 인력양성 사업인 ‘서울 어코드 활성화 사업’ 활성화와 양측의 연구 및 교육 분야 협력을 위해 2월 이타스코리아는 아주대학교 소프트웨어 융합학과 및 정보 컴퓨터 공학과 학생들을 중심으로 AUTOSAR 현장실습 프로젝트를 진행했다. 이에 대한 연구결과를 소개함으로써 자동차 전장 관련 개발자, SW개발자의 실무에 활용될 수 있기를 기대한다.

이타스는 AUTOSAR 플랫폼 기반 소프트웨어 개발 툴체인 전체를 제공한다. 이를 이용하면 애플리케이션, Basic Software 설계와 더불어 가상 ECU를 통해 시뮬레이션할 수 있다. 이 글에서는 간단한 툴 사용방법과 Application S/W, NvM Service S/W Component Design 방법에 대해 기술한다.

AUTOSAR, 작년 가을 우연히 접하게 된 단어다.
교내 프로그램인 집중교육을 통해 알게 된 AUTOSAR는 기계공학의 전유물이라고 생각했던 자동차 분야에 대해 다시 한 번 생각하게 된 좋은 계기가 됐다.

자동차 시장의 변화와 AUTOSAR
최근 자동차시장의 변화는 이전의 바람과는 조금 다른 듯하다. 과거의 자동차는 기계와 전자제품으로 이뤄진 기술의 성능과 발전이었다면, 요즘의 흐름은 융합기술의 결정체인 스마트카인 것이다. 이처럼 자동차에 접목되는 분야가 증가하고 그 중에서도 소프트웨어의 기술이 중요해지면서 AUTOSAR의 중요성은 점차 커져만 가고 있다.

AUTOSAR는 Automotive Open System Architecture의 약자로 자동차 소프트웨어의 표준화를 위해 자동차 개발사들에 의해 개발된 플랫폼이다. 나날이 증가하는 기술과 성능에 맞춰, 자동차의 안전성과 효율성의 필요 또한 증가됐고, AUTOSAR는 이러한 수요에 의해 생겨났다.

AUTOSAR의 필요성은 그림 1로 설명이 가능하다. 과거의 개발방법론은 소프트웨어가 하드웨어에 의존하는 구조였다. 이는 하드웨어를 개발하는 개발사나 그 위의 소프트웨어를 제공하는 개발사에 있어서 매우 비효율적인 체계였다. 그래서 ASW와 BSW를 분리해 개발하는 방법론이 생겨났고 더 효율적으로 사용됐다. 그후 좀 더 체계적인 표준을 위해 AUTOSAR가 생겨났으며 하드웨어와 소프트웨어 인터페이스를 표준화하는 기준을 제시했다.

AUTOSAR 기반의 Application Software와 Basic Software는 서로 독립적으로 개발이 가능하다. Application Software 개발자의 경우, 기능별, 모듈별로 Application Software Component를 개발할 수 있고, 재사용이 가능하다. 하드웨어에 종속적이지 않게 개발이 가능한 것이다. 마찬가지로 Basic software 개발자 또한 Application Software와는 독립적으로 Basic Software를 개발할 수 있다. AUTOSAR를 기반으로 개발된 Application Software와 Basic Software는 AUTOSAR의 RunTime Environment에 의해 통신이 가능하게 되고 ECU의 구조를 구성할 수 있게 되는 것이다.

AUTOSAR 집중교육 프로젝트

이러한 기술의 흐름에 맞춰 AUTOSAR기반 ECU Software 설계와 시뮬레이션을 통한 검증을 목표로 하는 집중교육 프로젝트가 아주대에서 진행되었으며, 프로젝트를 통해 AUTOSAR를 처음 접하게 됐다. 소프트웨어융합학과 이정태 교수의 지도로 2개월에 걸쳐 AUTOSAR ECU Software 개발과 시뮬레이션을 통한 검증 프로젝트를 진행했다.

한 달 간은 기본적으로 소프트웨어 전공자에게 부족할 수밖에 없는 자동차의 도메인 지식을 배웠으며, AUTOSAR를 이해하기 위해 스펙 문서를 읽는 방법과 이타스의 Tool인 ISOLAR-A, ISOLAR-EVE, ASCET의 사용법을 익혔다.

나머지 한 달은 프로젝트의 구조를 설계하고, 이타스의 ISOLAR-A, ASCET Tool을 이용해 비교적 간단한 수준의 ACC(Adaptive Cruise Control)를 디자인했으며, ISOLAR-EVE를 통해 Java 프로그램과의 시뮬레이션을 구현했다.

이타스의 툴 중 하나인 ISOLAR-A는 기본적으로 컴포넌트 단위별 모델링을 할 수 있다. 집중교육 프로젝트에서 ISOLAR-A를 통해 컴포넌트들을 모델링한 뒤, Composition Component로 구성했다. 컴포넌트 단위로 모델링하면 기능이 다른 ECU마다 필요한 컴포넌트를 프로토타입으로 구성해 줄 수 있기에 재사용성이 뛰어나다. 그림 2는 단위 별 컴포넌트들이 모여 하나의 기능을 수행하는 ECU의 Composition Component다.

학교에서 진행한 ACC 프로젝트의 경우, 앞차와의 거리를 센서를 통해 받아온 뒤, 단위 시간당 변화율을 통해 속도를 구하고, 속도 값을 통해 가속도를 측정, 알고리즘을 통해 가속 혹은 제동 액추에이터를 조절하는 것이 목적이었다. 사용자의 입력 값인 안전거리와 최대 주행속도 또한 ECU 내부의 알고리즘에 있어 중요한 변수 역할을 하게 되는데, 이런 입력 값의 변화에 따른 적응을 ISOLAR-EVE와 Java OpenGL을 통해 실시간으로 시뮬레이션할 수 있었다.

ISOLAR-A를 통한 애플리케이션 SW컴포넌트 모델링

집중교육 프로젝트에서 주로 사용한 툴 중 하나인 ISOLAR-A는 이타스의 툴로 소프트웨어 구조를 설계하는데 있어 직관적이며 효율적으로 사용할 수 있다. 기본적으로 Application Sw Component를 설계하는 방법은 그림 3과 같다.

프로젝트를 생성했다면, Software => Create Component => Application Sw Component Type 순서로 Application Sw Component를 생성할 수 있다. 물론 Application Sw Component 외에도, Sensor Actuator Sw Component나 Service Proxy Sw Component, 혹은 RTE 아래에 위치한 Ecu Abstraction Sw Component나 Service Sw Component 등도 설정할 수 있다. 그리고 이렇게 설정한 컴포넌트에는 필요에 따라 Internal Behavior와 Port가 구성돼야 한다.

생성된 Application Sw Component에서 New Child => Port를 통해 Port를 생성할 수 있다. 여기서 Provide Port는 API를 제공하거나, Data를 Send하는 컴포넌트에 구성될 수 있으며, Require Port의 경우에는 API를 사용하거나, Data를 Receive하는 컴포넌트에 구성될 수 있다(그림 4).
두 개의 컴포넌트에 각각 Provide Port, Require Port를 설정했다면, 두 Port를 연결할 인터페이스가 필요하다.

Software => Interface를 통해 필요한 인터페이스를 생성할 수 있다. Sender Receiver Interface의 경우 컴포넌트 간 데이터 전달을 목적으로 하며, Client Server Interface는 Operation Call을 위한 용도로 사용된다. 그림 5처럼 인터페이스를 생성하고, Argument 등을 구성했다면, 각 컴포넌트의 Port 설정을 통해 연결을 할 수 있다.
ISOLAR-A의 Auto Connect 기능을 사용하면 Port 간 자동연결이 가능하다.

그 후엔 실제로 RTE 위에서 동작할 Runnable Entity와 이 Runnable Entity의 동작을 위한 Event들을 설정해야 한다.
Runnable Entity는 Internal Behavior내부에서 RTE를 통해 동작하는 일의 단위로, Internal Behavior => New Child => Runnable Entity 순서로 생성할 수 있다(그림 6). 이러한 Runnable Entity들이 동작하기 위한 방법으로 Event가 있으며, Event 설정 방법은 그림 7과 같다.

일반적으로 사용하는 Event 몇 가지를 설명하자면, Timing Event의 경우 개발자가 설정한 시간을 주기로 Runnable Entity를 동작하게 하는 Event다. 보통 주기적으로 실행되는 함수의 경우에 사용될 수 있다(그림 7).

Operation Invoked나 Data Received Event의 경우 특정 상황일 때 Runnable Entity를 실행시키는 Event다. Operation Invoked Event는 Operation이 Call 됐을 때, Data Received Event는 R Port를 통해 데이터를 받았을 때 Runnable Entity를 실행시키는 Event다.

위의 방법을 토대로 프로젝트를 설계하면, ISOLAR-A에서는 .arxml 형식의 파일로 저장된다. 특히, 컴포넌트, 인터페이스 단위로 저장이 가능하기에 이러한 저장 형식의 파일은 개발 툴이 다른 기업 간 , 혹은 이타스의 다른 Tool(ISOLAR-EVE, ASCET등)로 Import해 사용하기에도 쉽고, 단위 모듈 별로 재사용이 가능하다는 점이 큰 장점이라 할 수 있다(그림 8).

현장 실습과 이타스코리아
집중교육을 통해 AUTOSAR에 대해 공부를 하게 됐고, 교육이 끝나갈 즈음 추천으로 이타스코리아에서 현장실습을 할수 있는 기회를 얻게 됐다. 집중교육에서 Application Software를 중심으로 프로젝트를 진행했다면, 현장실습에서는 기존의 프로젝트에 Basic Software를 추가해 설계하는 방향으로 실습을 진행했다.

NvRAM Manager Basic Software

현장 실습을 통해 다루게 된 Basic Software는 NvRAM Manager다. NvRAM Manager는 Non-Volatile RAM Manager의 약자로서 Memory Service를 담당하는 Basic Software다. Application Sw Component로부터 hardware Memory(EEPROM/Data Flash Memory)에 데이터를 Read/Write하는 등의 명령을 받아서 수행하는 Service Sw Component다.

이 Basic Software의 적용을 통해 이타스의 툴을 이용해 Memory Stack을 구현해 봤다.
이타스가 제공하는 툴체인을 이용한다면, Application Software 뿐만 아니라 Basic Software도 개발할 수 있다. 먼저, ISOLAR-A를 통해 자동생성된 Sample NvMService SW Component는 그림 9와 같다.

먼저 이타스의 RTA-BSW Generator를 통해 Configuration된 NvM을 Generation하면 ~Cfg.c, ~Cfg.h 파일 외에도 arxml 파일이 생성된다. 생성된 NvM Service Sw Component를 사용하기 위해 기존의 프로젝트에 NvM.arxml 파일을 Import한다(그림9). 그림 9와 같이 사용할 수 있는 NvM의 API들과 인터페이스들을 볼 수 있다. 이 API를 Application Sw Component에서 사용하기 위해서는 몇 가지 작업을 거쳐야 한다.

먼저 NvM의 API를 사용하기 위해 Application Sw Component는 Require Port를 설정해야 한다. Operation을 Call하는 컴포넌트의 경우 Require Port를, Operation을 제공하는(NvM) 컴포넌트에서는 Provide Port가 있어야 한다. 그림 9의 NvM의 경우, 샘플로 설정된 Provide Port가 존재하며, 그중 NvM_LightAlgoData Port의 경우 NvM Service Interface로 연결돼 있다. 이렇게 설정을 하면 NvM_LightAlgoData Port는 NvM Service 내부의 Operation들을 Require Port로 연결된 컴포넌트에 제공할 수 있다.

NvM API를 사용할 Application Sw Component는 Require Port를 설정 후 NvM Service Interface를 연결한다(그림 10). 그리고 NvM API를 사용할 Runnable Entity를 생성한다(그림10의 RE_CurrentDistance_Sensor). 이 Runnable Entity의 동작 여부는 필요에 맞게 Event를 설정해 사용하면 된다. 그 후, 여기서 제일 중요한 RAM MIRROR라는 변수를 생성한다.

이 RAM MIRROR는 RTE 위에서 존재하는 변수라고 생각하면 된다. Application SW Component 입장에서는 Per Instance memory라는 변수로 ISOLAR-A에서 생성이 가능하다. 이 변수는 데이터를 Read/Write할 때 이용된다. 만약 Application Sw Component가 데이터를 하드웨어에 쓰고자 한다면 이 Per Instance memory에 데이터를 저장한다. 그러면 RTE 위에서 Per Instance Memory는 RAM MIRROR로 공유되며 NvM Service Component가 이 데이터를 읽어온 후 Write 작업을 수행하는 것이다(물론 실제 작업은 Flash Driver 혹은 EEPROM driver에서 수행한다).

Application SW Component에 Per Instance Memory를 생성했다면, Service Needs Editor를 통해 Per Instance Memory를 Mapping해줘야 한다(그림 11). 위의 작업을 진행하면 ISOLAR-A에서는 반자동으로 Per Instance Memory를 Basic Software인 NvM이 사용할 수 있도록 구성해준다. 이외에도 Application SW Component가 NvM Service 혹은 다른 Service를 사용하는데 있어서 필요한 설정을 Service Needs Editor를 통해 추가할 수 있다.
이렇게 Application SW Component의 내부를 설정했다면 이제 NvM Service SW Component의 추가적인 설정이 필요하다. 먼저, NvRAM Manager 내부에 Operation Invoked Event를 생성후, Runnable Entity인 WriteBlock을 설정해준다. 이는 RTE Call을 통해 Operation을 호출당하면, 그 후 어떤 동작을 실행해야 할지를 설계하는 단계라고 볼 수 있다.

Operation Invoked Event를 통해 수행될 Runnable Entity를 Mapping 했다면, 이제 그 Event가 어떤 Port , Operation에 의해 수행될지 Mapping을 해야한다. NvM의 Provide Port인 NvM_LightAlgoData 내부의 WriteBlock이라는 Operation을 Target으로 Mapping하기 위해 POerationInAtomicSwcInstanceRef를 생성 후 설정 단계를 거친다(그림 12).

물론 NvRAM Manager 내부의 ReadBlock이나 WriteBlock은 다른 컴포넌트로부터 호출을 통해 사용되지만, 실질적으로 데이터의 Read나 Write를 수행하는 Runnable Entity는 NvM_MainFunction이다. 이 Runnable Entity는 일정 주기마다 반복적으로 동작하기 때문에 Timing Event로 설정해야한다.
Application SW Component가 NvM Service SW Component에게 Data를 Read/Write하는 명령을 전달하고, NvM Service SW Component가 일을 끝냈다면 일이 끝났음을 Application SW Component는 어떻게 인지할까. 그 해답은 Job End Notification이라는 Operation에 있다.

Job End Notification API의 경우 위의 NvMReadBlock, WriteBlock과는 반대의 흐름이라고 생각하면 된다. 일이 끝난 NvM Service SW Component는 Application SW Component에게 일이 끝났음을 알리고 싶다면, 이를 가장 간단하게 사용하는 방법은 RTE Call을 통해 Operation을 호출하는 것이다.
NvM Service SW Component가 일이 끝난 후 Job End Notification 함수를 호출해야 하므로 내부에 Require Port를 생성한다. 반대로 Application SW Component의 경우 Provide Port를 생성한다. 두 Port는 NvM.arxml에 정의된 NvM_NotifyJobFinished Client Server Interface로 연결한다(그림 10, 12).

이렇게 모델링이 됐다면, NvM Service SW Component, Application SW Component에 연결된 인터페이스의 내부를 Implement해줘야 한다. 그 후, Require Port를 가지고 있는 컴포넌트에서는 RTE Call을 통해 API를 사용할 수 있게 되는 방식이다. 물론 이러한 Implement는 ASCET이 나 Hand Coding을 통해 구현할 수 있다.

앞서 기술한 방법으로 컴포넌트 단위의 구조를 설계했다면, 이제 전체적인 구조를 설계해야 한다. 기존의 Application SW Component나 Sensor Actuator SW Component, NvM Service SW Component 등과 함께 Composition Component를 통해 하나의 기능을 하는 ECU로 구성해줘야 한다(그림 13).

구성된 Composition Component는 ISOLAR-A에서 Virtual ECU에 Mapping을 할 수 있다. 먼저 프로젝트의 하위 폴더인 System에 새로운 System Mapping Component를 생성한 뒤, 구성된 Composition Component를 Mapping하는 작업으로 시작한다. 그 후 ECU Instance를 생성하고, Composition Component에 속해 있는 컴포넌트들을 ECU Instance에 Mapping한다. VECU의 구성이 끝나면 ECU Extract를 통해 추출할 수 있다.

추가적으로 해야 할 단계로는, RTE, OS Configuration과 CodeGeneration인데 이타스의 RTA-RTE를 사용하면 ISOLAR-A에서 RTE를 생성할 수 있다. 먼저 OS Configuration을 진행해야 한다. 이 단계에서는, VECU 내부의 Runnable Entity들을 Task에 Mapping하는 것인데, TASK를 생성하고, Priority를 정의함으로써 TASK들의 동작 방식과 우선순위를 설정해 줄 수 있다(그림 14).

위의 그림은 ISOLAR-A에서 설정한 TASK Mapping을 보여준다. Task를 생성후 Event로 설정된 Runnable Entity들을 Mapping해준다. Priority의 숫자가 높을수록 우선순위가 높으며, 이를 통해 Runnable Entity들의 실행 우선순위를 제어할 수 있다.

그림 15의 경우 Basic Software의 Task Mapping의 상황을 보여준다. 기본적으로 그림 14의 경우 Application SW Component들은 Timing Event로 설정돼 있지만, Basic Software의 경우 BswTimingEvent로 명시된다. 물론 이 Basic Software의 Runnable Entity도 Task Mapping을 통해 OS Configuration을 할 수 있다. 그 후, RTE Generation을 통해 설계를 마무리하면 된다.

ISOLAR-A에서는 RTE 생성을 위한 OS Configuration이 가능하고 나머지 세밀한 OS 설정은 이타스의 툴인 RTA-OS를 사용하면 된다. 앞서 설명한 순서로 설계를 마치고, RTE Generation을 하게 되면 osNeeds라는 arxml 파일이 생성된다. 이 파일을 RTA-OS에 Import하게 되면, 기본적으로 ISOLAR-A에서 설정한 것 외에 추가적으로 설정할 수 있는 항목들이 있다(그림 16).

ISOLAR-A에서 Application SW Component와 Service SW Component의 설계 방법에 대해 알아봤다. AUTOSAR의 강점이라 한다면 Application Software와 Basic Software 개발의 독립성이라 할 수 있다. 하지만 각 소프트웨어를 개발하기 위해서는 어느 정도 서로의 메커니즘을 이해해야 한다. 현장 실습을 진행하기 전까지는 Application Software만 개발하고 이해했기에 Basic Software의 이해도가 많이 부족했었다. 하지만 이번 현장 실습을 통해 Basic Software를 구현하면서 전체적인 큰 틀을 이해할 수 있게 됐다. 이처럼 이타스의 툴 체인을 이용한다면, Application Software부터 Basic Software까지 하나의 흐름을 이해하며 설계할 수 있다는 장점이 있다.

다음 호에서는 NvRAM Manager의 명령을 수행하는 Basic Software인 Flash EEPROM Emulation과 Flash memory Driver를 이타스 툴을 이용해 Configuration, Generation 방법과 API 구현, ISOLAR-EVE를 통해 VECU를 시뮬레이션하는 방법에 대해 기술하도록 하겠다.