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

글│조 승 우, 아주대학교 정보컴퓨터공학과


급변하는 자동차시장과 AUTOSAR

최근 들어 국내에서 AUTOSAR 표준을 도입하고 ISO 26262를 준수하려는 움직임이 활발해졌다. 국내의 대표 OEM들과 Tier들은 모든 부문에서 AUTOSAR 표준 도입을 검토, 선행 개발 또는 상용화 중이다.

주요 해외 OEM들은 이미 2020년 이전에 AUTOSAR 표준을 모든 차량에 적용하겠다는 계획을 발표한 바 있다. 국가적 대응도 만만치 않다. 이웃 일본의 JASPAR, 중국의 CASA만 보더라도 큰돈을 들여 AUTOSAR 개발에 투자하고 있는 것을 알 수 있다.

AUTOSAR를 말하지 않고 자동차 개발을 논할 수 없는 시대가 곧 올 것이다. 비단 국내 OEM, Tier들만 AUTOSAR 적용에 노력할 것이 아니라 미래의 관련 예비 종사자들까지 모두 지속적인 노력과 대응을 해야 할 것이다.

직접 경험해 본 AUTOSAR 

AUTOSAR에 맞춘 Application 개발을 진행하면서 AUTOSAR 개발 방법론이 ECU 개발에 몇 가지 장점을 제공할 수 있다는 것을 명확히 확인할 수 있었다. Application Software layer(ASW)와 Basic Software layer(BSW)를 분리해 개발하는 AUTOSAR 특성상 Application 개발자는 하드웨어의 제약사항에 크게 얽매일 필요가 없다. 하드웨어를 다룰 때 필요한 구체적인 사항들은 Virtual Function BUS(VFB)를 통해 정해지기 때문에 Application 레이어에서 다루는 알고리즘이나 입출력들은 BSW에 의존성을 가지지 않는다(그림 1).

즉, 자신이 만든 AUTOSAR용 Application을 VFB 설정을 기반으로 다양한 하드웨어를 가지는 BSW 위에서 사용할 수 있다는 것이다. 물론, 이는 곧 소프트웨어 재사용 능력의 상승으로 이어지게 된다.

AUTOSAR를 적용하면 테스트 분야에서도 큰 비용 절감을 이뤄낼 수 있다. 소프트웨어 재사용 능력 향상의 중추역할을 하는 VFB는 Run-Time Environment(RTE), Service(BSW), Operating System(OS), Hardware Interface(MCAL)로 구성돼 있다(그림 1). 이 중 BSW는 하드웨어적인 서비스를 담당하는 SW 부분이고, MCAL은 BSW나 OS가 물리적 포트와 디바이스에 접근할 수 있게끔 도와주는 역할을 한다. BSW, MCAL을 잘 활용하면 실제 차량 디바이스를 이용하지 않고 가상 ECU 위에서 테스트할 수 있기 때문에 비용절감이라는 이점을 획득할 수 있다.
 
진행한 프로젝트에 대해

교내 교육과정의 일환으로 처음 AUTOSAR을 접하게 됐을 때, 가장 강조된 요구사항은 바로 안전성이었다. 물론 소프트웨어를 전공한 학부생으로서 자동차 지식에 한계가 있음을 먼저 언급하고자 한다.

운전자 안전 측면에서, 경사로 밀림방지 기능을 만들어보기로 했다. 경사로에서 차량이 정차하고 다시 출발할 때, 운전자는 반드시 브레이크에서 발을 떼고 엑셀 페달을 밟아야 한다. 이 순간, 차량이 경사에 의해 뒤로 밀릴 수 있기 때문에 사고 발생 가능성이 존재한다. 안전성을 위해 차량 자체적으로 짧은 순간 정차시켜주는 기능이 필요하다. 자동 변속기 차량이라도 상황은 마찬가지다. 일정 이상 경사에서는 항상 밀림 현상이 일어난다. 밀림 현상을 해결하기 위해 차량용 Application이 필요하다고 생각했고 AUTOSAR용으로 제작함으로써 Application 자체 안전성도 보장하려 했다.

해당 Application은 실제 차량의 엑셀 페달, 브레이크 페달, 기울기 센서, 휠 센서 수치를 통해 동작여부를 판단하고 결과를 유압장치와 계기판에 전달하도록 설계됐다. 그러나 실제 차량 장치를 쓸 수 없었기에 모든 장치들을 VRTA Driver와 이타스에서 제공하는 가상 DIO Driver로 대체하고 진행했다. 

Software Component Modeling

Software Component Modeling은 Application 내의 큰 구조를 작성하는 단계다. Component나 Interface 같은 필수적인 구성요소를 설정하는 것으로 개발을 시작하게 된다. Software Component Modeling을 위해 ISOLAR-A라는 이타스 툴을 사용했다. Eclipse 기반 이타스 툴, ISOLAR-A는 사용자가 AUTOSAR 표준에 맞춰 하위 Child를 쉽게 생성할 수 있도록 돕고 내부 연결을 간단하게 설정할 수 있게 해준다. 또한, ISOLAR-A RTE Code는 MISRA-C를 기반으로 제작돼 높은 안전성을 가지고 있다.

Tool에서 Project를 만들고 Appli cation의 한 기능을 담당할 Component들을 생성하는 것으로 개발 작업을 시작한다. 이어서, Component의 외부 연결을 담당할 Port를 만들고 Component의 내부 행동 규칙을 정의할 Internal behavior를 생성한다.

Internal behavior에서는 Com ponent를 호출하는 OperationInvoked Event, DataReceivedEvent, TimingEvent 같은 Event들을 설정할 수 있고 실제 내부 알고리즘을 담당할 Runnable Entity들을 생성할 수 있다. 그리고 설정한 Event가 발생했을 때 실행할 Runnable Entity를 지정함으로써 한 개 Event가 하나의 Runnable Entity를 가리키도록 한다. 이를 통해, 특정 Event가 발생할 때, 그에 맞는 내부 알고리즘을 실행시키도록 설계할 수 있다.

Runnable Entity에서는 다른 Compo nent의 함수를 호출하는 Server call points나 DataReadAccess, DataWrite Access처럼 RTE Interface 내 데이터를 다루는 Variable Access를 설정할 수 있다. 또한, Component 내부적으로 쓰이는 변수에 대한 Variable Access인 WrittenLocal Variables, ReadLocalVariables도 설정 가능하다. 이러한 설정 사항들은 추후 알고리즘을 구체화할 때 사용되므로 목적에 따라 주의해 사용한다.



Interface의 경우, Port를 통해 Compo nent 사이가 어떻게 연결됐는지 정의하는 역할을 한다. ECU 내 설계된 사항에 따라 Interface는 사용되는 종류가 달라질 수 있다. Sender가 데이터를 보내고 Receiver가 받는 단순한 연결에는 Sender-Receiver Interface를 설정한다. 데이터가 아닌 다른 Component가 가지고 있는 함수를 사용해야 하는 것이라면 Client-Server Interface를 사용한다.

Component와 Interface를 모두 생성했다면 Top Level Composition을 생성해 모델링을 이어나간다. Top Level Composition은 ECU 내 Software Component 배치 및 연결 정보를 나타내는 것으로 ISOLAR-A Prototype Editor를 사용하면 도식으로 정보를 쉽게 확인할 수 있다(그림 2).

Top Level Composition이 완성된 후 System에 Top Level Composition을 등록한다. ECU에 들어갈 프로그램이 어떤 Component를 쓰고, 어떤 Interface를 쓰는지 Tool을 통해 등록하는 과정이다. 등록을 마치면 ISOLAR-A System 사용할 OS Task 우선순위를 설정해 어떤 Runnable Entity가 우선적으로 처리될 것인지 정한다(그림 3). OS Task를 설정하는 작업이 끝났다면 RTE Code를 생성해 모델링 결과를 확인한다. 

Safe Runnable Entity Algorithm

지금까지 결함 없는 Software 구조를 ISOLAR-A를 이용해 제작했다. 이제 ISOLAR-A에서 제작한 Runnable Entity에 구체적인 알고리즘을 입력할 차례다. 

Runnable Entity 알고리즘을 구현하는 것은 ECU의 안전성과 신뢰성에 직결될 수 있는 사항이기 때문에 매우 중요하게 다뤄져야 한다. 운전자 안전을 위해 코드 상 작은 에러도 허용될 수 없다. 모델링 베이스 Embedded 프로그램을 제작하는 ASCET Tool은 알고리즘 코드를 AUTOSAR 표준에 맞게 자동으로 생성한다.

이러한 작업 방식은 전통적인 Hand code를 사용했을 때 생길 수 있는 에러들을 원초적으로 제거시킨다. 사용자는 알고리즘을 모델로 표현하기만 해도 방어 코드가 들어간 안전한 알고리즘 코드를 얻을 수 있다. 모델링 과정도 복잡하지 않다. 직관적인 표현이 가능하며 처음 다루는 사람도 금방 익힐 수 있기 때문에 사용성도 높다. 필자도 짧은 기간 습득해 간단한 로직을 만들 수 있었다.

ISOLAR-A에서 Authority된 결과물을 손쉽게 import할 수 있다는 점도 ASCET의 큰 장점 중 하나다. ASCET importer는 ARXML 파일들로부터 component와 Interface의 정보를 추출하고 데이터 베이스의 하위 구조에 자동으로 등록시킨다.

ASCET에서는 component scope과 Project scope으로 나누어 알고리즘을 제작한다(그림 4). Component scope에서는 각 component들이 가지는 실제적인 알고리즘을 구현한다. Software Compo nent Editor 내 Outline 항목을 살펴보면 Component와 연관된 Interface나 내부 변수들이 ISOLAR-A에서 작업했던 것과 동일하게 ASCET에서도 설정돼 있다는 것을 알 수 있다(그림 5).

중앙에 위치한 모델링 작업 환경 창에 사용할 Interface, 내부 변수를 드래그해 모델링할 수 있으며 If, MUX, OR, AND 같은 연산들도 드래그해 모델링 작업 환경 창에 모델링할 수 있다. 모두 모델링으로 나타냈다면 연산들과 인터페이스들을 연결하는 작업을 진행한다. ASCET은 연결을 위해 Sequence라는 개념을 사용한다. Sequence를 통해 어떤 Runnable Entity에서 몇 번째로 수행될 것인지 구체적인 알고리즘 순서를 정한다.
 
인터페이스들과 연산 기호들을 모두 연결했다면 원하는 알고리즘을 Project 개발 환경을 통해 RTE Code로 바꿀 준비가 된 것이다(그림 6).

Project scope에서는 실질적으로 code를 생성할 때, 어떤 OS를 쓰고 어떤 컴파일러로 Code를 생성할 것인지 정한다. ASCET에서는 한 번에 하나의 Component가 가진 알고리즘을 RTE Code로 변환할 수 있다. RTE code 생성이 성공적으로 끝나면 C file과 Header file을 통해 알고리즘이 C code 속에 들어간 것을 확인할 수 있다(그림 7). 



 
RTPC를 통한 가상 ECU 제작

ISOLAR-A에서 ECU 내 Software 구조를 만들고 ASCET을 통해 안전한 알고리즘을 구현했다면 이제 Application을 Build할 준비가 된 것이다. 이타스에서 제공하는 ISOLAR-EVE와 Real Time PC (RTPC)만 있다면 지금까지 만든 AUTO SAR용 Application을 가상 ECU 장치에 Build 및 테스트할 수 있다.

ISOLAR-EVE는 ISOLAR-A와 마찬가지로 Eclipse 기반 이타스 툴이다. ISOLAR-A가 결함 없는 Software 구조를 만드는 기능을 제공했다면 ISOLAR-EVE는 안전한 알고리즘이 추가된 ECU Software에 BSW, MCAL 설정을 추가해 가상 ECU 장치에 AUTOSAR용 Application을 Build할 수 있는 기능을 제공한다.

ISOLAR-EVE의 BSW, MCAL 추가 기능은 개발 방법론 측면에서 개발자에게 강력한 장점을 부여한다. BSW 설정에 따라서 하나의 단일 ECU는 많은 확장 가능성을 획득할 수 있기 때문이다. 예를 들어, CAN BSW 설정을 완료한다면 단일 ECU는 다른 ECU와의 통신을 할 수 있으며, DIO MCAL 설정을 마쳤다면 ECU와 연결된 다른 하드웨어와의 입출력 처리도 가능하다. 그리고 BSW, MCAL 설정을 하기 위해 사용자는 어려운 접근 방법을 취할 필요가 없다. ISOLAR-A에서 손쉽게 Software 구조를 구축했던 것과 동일하게 ISOLAR-EVE도 간단한 조작만으로 virtual ECU용 BSW, MCAL 설정을 할 수 있다.



이번 AUTOSAR용 Application에서는 다양한 BSW들 중 DIO, Port를 응용해보았다. DIO 설정은 EcucModuleConfi gurationValues의 Definition을 설정하는 것으로 시작한다. ISOLAR-EVE에 정의돼 있는 DIO definition을 선택하면 DioConfig와 DioGeneral이라는 Container를 다룰 수 있게 된다. DioConfig는 DIO Module이 가지는 하위 Container들을 모두 포함하는 Container이며 DioGeneral은 ErrorDetect의 여부나 VersionInfoApi 같은 Api 사용여부를 확인하는 일반적인 Configuration 파라미터에 관한 사항들을 포함하는 Con tainer이다.



이어서, DioConfig는 DioPort Container를 하위 Container로 가진다. DioPort Container에서는 MCU Port에 Dio Port임을 나타내는 ID를 지정한다. 그리고 DioChannel과 DioChannelGroup을 하위 Container로 두어 알맞게 설정한다. DioChannel은 하나의 입출력 channel로 내부 설정인 DioChannelId를 통해 실제 Micro controller가 DioChannel을 인지하게 할 수 있다. 설정을 완료하면 DioChannelId를 통해 Micro controller가 Digital 값을 불러오거나 내보낼 준비가 된 것이다. DioChannelGroup의 경우 논리적으로 Channel들을 그룹화하는데 사용된다. 그룹화가 된 상태에서 MASK를 통해 DioChannelGroup이 받아들일 비트의 위치를 정의할 수 있으며 offset을 두어 어디서부터 DioChannelGroup이 시작하는지 설정할 수 있다(그림 8).



Port 설정도 DIO와 동일하게 EcucModuleConfigurationValues의 Definition을 설정하는 것으로 시작한다. 설정 후 Port는 PortConfigSet과 PortGeneral이라는 Container를 하위 Container로 가지게 되는데 PortConfigSet은 Module에서 사용할 하위 Port Container들을 모두 포함하는 Container이며, PortGeneral은 ErrorDetect의 여부, SetPinDirectionApi, SetPinMode Api 같은 Api의 사용여부를 확인하는  Configuration 파라미터 정보들을 가진 Container다.



이어서, PortConfigSet은 PortContainer를 하위 Container로 가진다. PortContainer에서는 사용할 PortPin의 개수를 설정하고 PortPin Container들을 생성, 설정할 수 있다. PortPin Container는 구체적으로 총 7가지의 세부 설정을 완료해야 한다. PortPin Direction은 입출력의 방향을 정하고 PortPin DirectionChangeable로 Runtime 도중 입출력의 방향이 변할 수 있는지 명확하게 설정한다.



이어서 PortPinId를 설정한 후 PortPinInitialMode로 Port_init 함수를 통해 초기에 설정될 Port Pin의 MCAL driver를 정한다. 그리고 해당 PIN이 low나 high digital 신호 중 어떤 것을 다루는지 PortPinLevel Value로 설정한다. PortPinMode를 통해 Runtime 내 동작할 MCAL Driver를 정한다. Runtime 도중에 Port pin이 쓰는 MCAL Driver가 변경될 수 있는지 PortPinMode Changeable 항목을 통해 입력하는 것으로 Port 설정을 마친다(그림 9).

위와 같은 DIO, Port ARXML설정을 통해 시뮬레이션을 위한 자동차 브레이크 장치를 단순화하는데 성공했다. 브레이크 페달을 밟은 모션을 Digital 값 High으로 대체했고 브레이크에서 발을 뗀 모션을 Digital 값 Low으로 대체했다.


ISOLAR-EVE의 또 다른 기능인 가상 ECU 장치에 AUTOSAR용 Application을 Build하는 기능 역시 사용자에게 매우 중요하다. 테스트 비용절감이라는 이익을 얻을 수 있기 때문이다. ISOLAR-EVE Build 기능은 Debian 계열 Linux 시스템인 RTPC OS에 기초해 동작한다. 사용자는 Virtual machine을 통해 RTPC OS를 설치하고 Network Adapter 설정만 간단히 완료해주면 ISOLAR -EVE Build 기능을 사용할 수 있다. 사용자가 Build를 위해 특별히 RTPC 내에서 customize할 사항들은 크게 존재하지 않는다.

AUTOSAR용 ApplicationBuild 과정은 다음과 같다. ISOLAR-A에서 작성한 ARXML 파일들을 Import하고 ASCET에서 작성한 RTE Code들도 Import해 프로젝트에 추가한다. 그리고 위에서 설명한 BSW, MCAL 설정을 완료한다. 다음으로 RTPC OS를 구동시키고 ISOLAR EVE의 Generator Tool들을 통해 RTA-RTE, RTA-OS, MCAL Generation 과정을 모두 완료한다(그림 10).



이후 AUTOSAR용 Application이 어떤 Hardware에 Build되는지 Target Mapping을 해준다. Target Mapping에서는 Hardware를 구동하기 위한 RTPC 내 헤더파일 설정, Digital 값 처리를 위한 Pin 번호지정 같은 중요한 정보가 포함되기 때문에 사용하려는 Hardware Vendor의 매뉴얼을 받아 진행하는 것이 바람직하다(그림 11).

Target Mapping이 끝난 후 Project Build 버튼을 누르기만 하면 자동으로 RTPC 내에 AUTOSAR용 Application을 Build시킬 수 있다. Build된 AUTOSAR용 Application은 ISOLAR-EVE의 EVE Controller를 통해 간단히 동작시킬 수 있다. 

RTPC의 하드웨어 접근 기능

ISOLAR-EVE에서 BSW, MCAL 설정까지 모두 완료했다면 가상 ECU 내 알고리즘 구동을 위해 RTPC에서는 Target Mapping대로 실제 장치가 연결돼 있어야 한다. 이번 개발에서는 Digital 값을 발생시키기 위해 RTPC용 DIO Board인 ES5340과 함께 이타스 breakout Box를 사용했다(그림 12). ES5340 board는 ECU를 테스트하는데 필요한 모든 신호를 시뮬레이션 할 수 있는 board로 Digital 신호를 Breakout Box를 통해 읽어올 수 있다.
 
Breakout Box에서는 Target Mapping에서 지정한 Pin 번호에 맞춰 Digital 값을 입출력 할 수 있는데 이번 개발에서는 Pin 33(GND), Pin 26(INPUT)을 이용하기로 했다. 33번 Pin에 desktop PC의 그라운드 선을 꽂고 26번 Pin에 desktop PC로부터 나온 15 V 전압선을 연결해 쇼트시키면 Breakout Box에서 Digital 값이 발생한다. ES5340 board는 Breakout Box로부터 Digital 값을 받아 SWC에게 전달하고 SWC는 내부 알고리즘에 의해 Digital 값을 브레이크를 밟거나 뗀 것으로 처리한다.

VRTA Driver와 JAVA 시뮬레이션

ISOLAR-EVE를 통해 RTPC에 AUTOSAR용 Application을 Build하고 동작시키는 것까지 성공했다면 AUTOSAR용 Application에게 사용자의 PC상에서 Input을 입력하고 Output을 확인할 수 있어야 한다. 이를 위해 VRTA Driver가 사용된다. ISOLAR-EVE VRTA Driver를 통해 사용자가 AUTOSAR용 Application에 특정 수치를 입력하고 내부 수치가 어떻게 되는지 확인할 수 있는 기능을 제공한다.

사용자가 VRTA Driver를 사용하려면 간단하게 C file을 작성하고 ISOLAR-EVE가 제공하는 내부 VRTA header를 Include하면 된다(그림 13).



VRTA Driver C file과 Header File을 작성하고 AUTOSAR용 Application에 추가시킨 후 Build하면 VRTA Monitor를 통해 ECU 내 수치들을 확인할 수 있다. VRTA Monitor는 ISOLAR-EVE 설치 시 같이 제공되는 프로그램으로 ECU 내 데이터 흐름을 VRTA Driver, MCAL Driver 같은 다양한 Driver로 확인할 수 있게 도와준다(그림 14). VRTA Monitor에서 VRTA Driver를 확인했다면 수치 입력이나 출력을 확인할 준비가 끝난 것이다. Input의 경우, 원하는 수치를 VRTA Driver 내 Value에 입력하고 send시킨다. Output의 경우, VRTA Driver 내 Value를 Read해 수치를 확인할 수 있다.

ISOLAR-EVE는 이러한 VRTA Driver의 특성을 응용한 VRTA Monitor JAR file과 함께 JAVA Sample Code를 제공한다. Eclipse Java Project에 해당 JAR File을 추가하고 Sample Code를 작성해 입력하면 VRTA Monitor에서 값을 입력하고 출력 수치를 확인하는 것처럼 Java program에서도 동일한 기능을 수행할 수 있게 된다(그림 15). 따라서 Use case에 맞춰 AUTOSAR용 Application에게 Input을 주고 Output을 확인해 시각화하는 것도 충분히 가능하다.

점점 더 다양한 ECU가 장착된 자동차가 개발될수록 안전성과 신뢰성은 더욱 엄격하게 평가될 것이다. 안전성과 신뢰성 기준인 ISO 26262를 만족하기 위해 AUTOSAR 표준을 따르려는 경향은 더 이상 미래의 이야기가 아니다.

이번 AUTOSAR용 Application 개발을 진행하며 AUTOSAR를 준수하는 ECU Software를 제작해봤다(그림 16). 더불어, 이번 경험을 통해 AUTOSAR 표준이 보장하는 Software 독립성을 이해할 수 있었다. 또, 작업의 효율성을 위해 AUTOSAR 표준을 적용하는 Tool들이 반드시 필요하다는 것을 깨달았다. Tool을 이용하면 AUTOSAR 표준을 찾아 헤매는 시간을 절약할 수 있으며 안전한 알고리즘을 손쉽게 도식화해 만들어 낼 수 있다. 실제 Hardware가 없어도 VRTA Driver를 통해 가정하거나 대체해 AUTOSAR용 Application을 테스트 할 수 있어 쉽게 AUTOSAR용 Application 개발을 진행할 수 있다.

AUTOSAR용 Application 개발을 경험할 수 있는 기회는 사실 흔치 않다. 그러나 AUTOSAR를 이론만으로 배우고 끝내기에는 아쉬운 점이 너무나 많다. 산업적인 측면에서 보았을 때, AUTOSAR가 가진 미래 활용 가능성은 매우 높은 수준이다. 자동차 ECU Software 개발을 공부하는 학생들에게 AUTOSAR는 반드시 알고 있어야 하는 기본 소양이 될 것이며, AUTOSAR용 Application 개발 경험은 그런 AUTOSAR를 더 깊게 이해할 수 있는 발판이 될 것이다.

단 한 번의 시도로 실제 차량에 들어가는 ECU software를 개발할 수는 없다. 꾸준한 개발 경험을 통해 AUTOSAR에 대한 높은 이해도를 습득한 후에야 실제 차량의 ECU software를 다룰 수 있을 것이다. 천리길도 한 걸음부터 시작한다는 속담이 있다. AUTOSAR를 공부하는 모든 학생들이 ‘한 걸음’의 기회를 가질 수 있기를 바래본다.