이타스 툴 체인 이용한 AUTOSAR 기반 FuelCut 제어 가상 ECU 구현 및 시뮬레이션 프로그램(2)
2015년 09월호 지면기사  / 글│이 윤 성 _ meetbaba2@gmail.com, 아주대학교 소프트웨어융합학과

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

FuelCut 제어 가상 ECU 구현 및 시뮬레이션 프로젝트는 ASCET을 통한 AUTOSAR 기반 ECU 소프트웨어의 Implementation 및 모델링을 한 후 ISOLAR-A를 통해 Authoring하는 과정을 거쳐 Bottom-Up 방식으로 ECU 소프트웨어의 개발 가능성을 검증하고 적용 시 고려사항들을 점검하는 것이었다.




ISOLAR-EVE를 이용한 가상 ECU 구현과 RTPC를 이용한 가상 ECU 구동

앞서 ISOLAR-A를 이용해 뽑아낸 ECU Authoring이 적용된 arxml 파일들과 RTE-generated code, 그리고 ASCET을 통해서 만든 Software Component(이하 SWC) modeling이 적용된 Implementation code를 가지고 ISOLAR-EVE에서 가상 ECU를 구현할 수 있다. 가상 ECU의 구현과 구동을 위해서는 Hardware에 대한 정보가 필요한데, 이는 가상머신 위에서 운용되는 이타스 RTPC를 가상 하드웨어로 활용할 수 있다.

ECU 정보 Import:
ISOLAR-EVE에서 VECU Project를 생성하면 src 폴더부터 var 폴더까지 11개의 폴더가 카테고리별로 생성된다. 이 중, EVE_Data 폴더의 하위항목에 arxml 파일들을 import하기 위한 폴더를 생성하고 그 안에 ISOLAR-A에서 생성된 arxml 파일들을 import 해준다. 단, ECUConfigurationParameters.
arxml 파일은 제외한다.



Hardware Mapping:
다음으로 가상 ECU가 적용될 환경인 하드웨어와 맵핑을 해줘야 한다. 이를 위해 가상머신에 RTPC 이미지를 삽입하고 RTPC를 구동시킨다. 그 다음 ISOLAR-EVE의 우측하단에 위치한 EVE Explorer에서 Scan for Target 아이콘을 클릭해 맵핑할 하드웨어를 검색하면 rtpc(‘rtpc의 ip주소’)가 EVE Targets 리스트에 추가된 것을 확인할 수 있다.

다음으로 EVE Explorer 내 VECU Project 탭을 열어서 하드웨어 맵핑을 원하는 프로젝트를 클릭한 뒤, EVE Explorer내 Target Mapping Editor 아이콘을 클릭하면 ISOLAR-EVE 중앙 탭에 Target Mapping Editor가 뜬다. 여기서 프로젝트 명이 기록된 열의 Target 탭을 클릭하면 맵핑할 하드웨어를 선택할 수 있는데, 이 때 리스트 중 rtpc를 클릭하고 엔터를 누른다. 마지막으로 같은 탭의 우측 상단 Automatic Hardware Mapping 아이콘을 클릭해 UDP Port까지 할당되면 하드웨어 맵핑이 완료된 것이다.




RTE Generation:
가상 ECU의 구동을 위해서는 ISOLAR-A에서 생성된 RTE generated 코드가 아닌 Hardware Mapping이 완료된 EVE 프로젝트에서 생성된 RTE generated 코드가 필요하다. ISOLAR-A 프로젝트에서 생성된 arxml을 Import한 EVE 프로젝트이기 때문에 ASCET에서의 모델링과 ISOLAR-A에서의 Authoring 정보는 변하지 않으니 안심해도 좋다.

프로젝트 우클릭 → Generate Tools → Generator Tools Configurations… → RTA RTE Generation. ECU Instance 탭에서 ECU Instance 를 선택하고, Main 탭의 Additional RTA-RTE Generator Command Line Arguments 칸에 ‘-tsl=128 --os-output-param=all’를 입력한 뒤 Run 클릭하면 RTE Generation이 완료된다. 콘솔 창을 통해 경고 혹은 오류 목록과 생성된 코드를 확인할 수 있다.
이 때 생성된 *.c, *.h 파일들은 src 폴더의 RTE 폴더 안에 위치한다.


RTA OS Generation:
RTE Generation을 끝내면 가상 ECU를 구동시키기 위한 OS 정보를 생성해야 한다. 앞선 RTE Generation 과정과 같은 방법으로 Generator Tools Configurations 창을 띄운 후, 이번에는 RTA OS Generation을 선택한다. ARXML Files 탭에서 Auto Select 버튼을 클릭하면 RTA-OS 폴더 내에서 자동으로 필요한 arxml 파일들이 선택되고, RTE Generation을 통해 생성된 src 폴더 안의 osNeeds.arxml 파일만 수동으로 체크, Run 버튼을 누르면 콘솔 창에서 RTA OS Generation 과정을 확인할 수 있다. 이 때, Error가 발견되지 않으면 정상적으로 생성된 것이다.

본 프로젝트에서는 앞선 과정에서 BSW에 대한 설정이 생략됐기 때문에 3개만 선택했지만, BSW 설정과정에서 생성된 arxml 파일들에 따라서 본 과정에서 선택해야 하는 arxml들이 추가될 수도 있다.


SWC Code Implementation 적용:
본 프로젝트에서는 Bottom-Up 방식으로 SWC 모델링과 Implementation을 먼저 한 후 RTE Generation을 했기 때문에 RTE Generated Code Implementation 적용은 수작업으로 해야 한다. 하지만 단순 복사, 붙여 넣기 작업이므로 어렵지 않으니 쉽게 따라 할 수 있다.


RTE Generate 헤더파일 (RTE_*.h) 수정:
ASCET에서 Generate한 코드 중‘SWC이름’.h 파일을 열어 #include 문이 끝나는 지점부터 #endif 구문이 나오기 전 까지의 모든 부분을 드래그해 복사(Ctrl+c)한다.

그 다음, ISOLAR-EVE 프로젝트의 RTE 폴더 안에 생성돼 있는 ‘RTE_SWC이름’.h 파일을 더블 클릭해 열고, #include문이 끝나고 처음 #if ~#endif 문이 끝나는 지점 뒤에 복사한 텍스트를 붙여 넣고 (Ctrl+v) 저장(Ctrl+s)한다. 같은 방식으로 가상 ECU에 적용할 모든 SWC의 헤더파일에 적용한다.




RTE Generate C소스파일 (RTE_*.c) 수정:
원리는 앞선 헤더파일의 수정과 같다.
차이점이 있다면 로컬 변수를 위한 선언부와, RTE와 연결돼 생성된 함수 내부 코드부분, 이렇게 두 단계를 거쳐야 한다는 점이다.
먼저 ASCET에서 Generate한 코드 중 ‘SWC이름.c’파일을 열어 *END: ASCET-SE AddOn Options 주석 밑 BEGINE:DEFINITION OF SUBSTRUCT VARIABLE 주석 부분부터 #define 선언이 끝나는 부분까지 복사한다.

이후 ISOLAR-EVE의 프로젝트의 RTE 폴더 안에 생성돼 있는 ‘RTE_SWC이름’.c 파일을 더블 클릭해 열고, #include 문이 모두 끝난 지점에 붙여 넣고 저장한다.

다음으로 ASCET에서 Generate한‘SWC이름.c’파일 내의 FUNC_(void, ‘SWC이름’) ‘SWC이름’_Impl_’Runnable Entity이름’ (‘Parameter 타입’){ } 형식 함수의 중괄호 내부 부분을 복사해, ISOLAR-EVE 내의 같은 SWC를 구현한 RTE_’SWC이름’.c 의 같은 함수의 비어 있는 중괄호의 내부에 붙여 넣는다. 이 때, 각 C소스 파일 내에 함수의 개수는 설계한 Runnable Entity의 개수와 같다는 것을 기억하고 빠짐없이 채운 뒤, 저장하도록 한다.
같은 방식으로 가상 ECU에 적용할 모든 SWC의 C소스 파일에 적용한다.


가상 센서, 액추에이터 디바이스 생성:
ISOLAR-EVE에서는 가상 ECU의 손쉬운 구동을 위해서 간단한 코드로 구현할 수 있는 가상 센서와 액추에이터를 지원한다. 이 센서와 액추에이터는 .cpp 파일로 제작한다. 이 글에서는 대표 예제로 센서 하나와 액추에이터 하나만 다루도록 하겠다.
가상 센서와 액추에이터 코드를 생성하기 전에 추가할 코드파일이 위치할 폴더를 src 폴더 내에 생성하자. 본 프로젝트에서는 ‘SWC’로 지정했다.

이 과정은 예제 코드와 함께 이해하는 것이 빠를 것 같다. 먼저 ‘디바이스이름’.h와 vrtaSampleDevice.h 헤더파일 둘을 include시킨다. class는 vrtaActuator를 상속받는다.
생성자 내에는 vrtaActuator의 생성자 형식에 맞춰서 표시되기 원하는 디바이스의 이름을 다음 코드와 같이 정해준다. 추후 여기서 정해준 디바이스 이름으로 액추에이터 디바이스가 생성된다.

함수는 원하는 기능과 이름으로 구현하면 되는데, 본 예제에서 액추에이터는 출력을 결정하므로 상속받은 vrta Sample Device에 정의돼 있는 SetValue 함수를 이용했다. 이를 위해 writeAlarmDevice 함수의 파라미터로 받은 value 값을 SetValue 함수의 파라미터로 전달했다. 동일한 방식으로 vrtaSampleDevice에서 제공하는 함수들을 이용해 다른 기능도 구현할 수 있다.

헤더파일은 생성한 C코드의 형식에 맞게 .c파일과 같은 이름의 .h파일로 생성하면 된다. 기본적인 부분이므로 지면상 코드는 생략한다.
가상 센서 역시 가상 액추에이터와 동일한 방식으로 구현되는데, 다른 부분이 있다면 상속받는 클래스가 vrtaSensor라는 점이다. 본 예제에서 센서는 입력을 받는 역할을 하므로 vrtaSampleDevices의 GetValue 함수를 이용해 함수를 정의했다.




가상 센서, 액추에이터 디바이스 적용:
앞서 생성한 가상 센서와 액추에이터 디바이스의 함수를 이제 RTE Generate된 *.c 파일에 적용할 수 있다. 센서와 액추에이터 동작이 필요한 컴포넌트의 .c 파일 상단에 #include로 해당 디바이스의 헤더파일을 추가하고 함수 구현 부분에 원하는 함수를 호출해서 사용하면 된다.



가상 ECU 구동 및 확인:
앞선 모든 과정을 저장하고 이제 가상 ECU를 구동해볼 차례이다. EVE Explorer → EVE Control → Build를 통해 가상 ECU가 생성된다. 빌드가 성공하면 Start 버튼을 누를 수 있다. 이 버튼을 클릭하면 가상 ECU가 RTPC 위에서 구동된다. 물론 이 때 RTPC는 켜져 있어야 한다.
성공적으로 가상 ECU가 구동되고 있다면 RTPC의 command line에 ‘top’ 명령어를 입력하면 프로세스 리스트 상에 가상 RTE Generation 시 선택했던 ECU Instance이름의 .vrt 프로그램이 돌아가고 있는 것을 확인할 수 있다.



Vrta Monitor를 통한 가상 ECU 동작 확인:
이타스에서는 윈도우에서 이 가상 ECU의 동작을 확인할 수 있는 Vrta Monitor란 프로그램을 지원한다. 이 파일은 ISOLAR-EVE를 설치하면 설치된 디렉토리\Tools\bin 폴더에 존재한다.

Vrta Monitor->Add Host->RTPC의 ip주소입력으로 장치가 추가?Connect. 연결에 성공하면 장치를 구성하는 요소들의 리스트가 뜬다. 여기서 우리가 앞서 생성한 가상 센서와 액추에이터도 확인할 수 있다. 가상 센서의 Input Value에 동작을 확인하기 위한 값을 입력하고 액추에이터 및 ECU의 각 요소에서 설계된 대로 동작하는지 수치로 확인할 수 있다.


JAVA 프로그램과 가상 ECU 연동

현재 EVE에서 돌아가고 있는 가상 ECU를 JAVA 프로그램과 연동해 ECU 동작을 컨트롤 할 수 있다. 이는 ECU 동작을 자동으로 테스트 하는데 유용하다. 이클립스의 자바 프로젝트에 vrta를 지원하는 jar 파일들과 vrta와의 연결을 지원하는 java 소스파일만 있으면 쉽게 할 수 있다.

첫 번째로 연동할 자 바 프로젝트에 vrta 지원을 위한 .jar 파일을 import한다. Import할 파일은 ‘com.etas.vrta.monitor_X.X.X…’, ‘com.etas.vrta.monitor.documentation_X.X.X…’, ‘com.etas.vrta.monitor.platform_X.X.X…’, ‘com.etas.vrta.monitor.ui_X.X.X…’, ‘VRTAcomms’라는 이름의 .jar 파일 5개이다. (X.X.X는 버전 번호, 이하 …은 생성된 날짜) import한 후에는 import한 .jar 파일들을 build path의 libraries에 추가한다.

다음으로는 JAVA 프로그램에 연동할 java 파일을 프로젝트에 import시킨다. ISOLAR-EVE에서 제공하는 샘플코드(Config.java)를 이용해 객체 인스턴스를 생성해 사용한다.

Config.getVECUPath(‘vecu이름’)함수의 리턴 값을 com.etas.vrta.comms.VECUConnection 패키지를 import시킨 뒤 생성한  VECUConnection 타입의 객체에 할당해, VECUConnection에서 제공하는 API를 통해 JAVA 프로그램과 상호작용할 수 있다. 다음은 action().send() 와 event().state() API를 통해서 구현한 간단한 예제 코드이다.

본 프로젝트에서는 이렇게 생성한 Connector 객체와 함수를 가지고 가상 ECU를 컨트롤 했다.

지금까지 ASCET에서 ISOLAR-A를 거치는 Bottom-Up 방식으로 ECU Instance에 대한 정보를 생성한 뒤, ISOLAR-EVE를 이용한 가상 ECU 구현과 자바 시뮬레이션 프로그램과의 연동하는 과정을 살펴봤다.

가상 ECU를 구현했다고는 하지만 이것은 Bottom-Up 방식으로도 이타스 툴 체인을 이용해 손쉽게 AUTOSAR 기반 개발이 가능하다는 것을 보여주는 정도이지, 실제 현업에 그대로 적용하기에는 많이 부족한 것이 사실이다. 아직 학부생인 필자가 직접 수행하며 느낀 불편함은 다음과 같다.



BSW의 부재:
ISOLAR-EVE를 이용해 가상 ECU를 구현하는 것까지가 목표여서 가능한 프로젝트였다. 앞선 설명에서 본 것처럼 Application Software Layer의 SWC 구현은 알고리즘만 정해진다면 포트 Interface를 고려하는 점 말고는 크게 어려움이 없다. 때문에 조금만 배운다면 누구나 단기간에 개발능력을 보유할 수 있다.

툴이 MDE(Model Based Engineering)를 지원해 C코드를 몰라도 프로그램을 만들 수 있으니 진입장벽은 더욱 낮아진다. 하지만 실제 AUTOSAR기반 E C U 개발에서 애를 먹이는 부분은 BSW일 것이다. 왜냐하면 이를 위해서는 Real-Time OS에 대한 이해, 이와 관련해 Timing Analysis를 동반한 설계, 통신과 MCAL 설정까지 필요한 데, 각 분야별 전문지식과 경험을 바탕으로 AUTOSAR에 적용해야 하기 때문이다.


Complex Device Driver의 미사용:
AUTOSAR는 기존 레거시코드(AUTOSAR가 적용되어 있지 않은 기존에 쓰이던 코드)의 재사용성을 보장하기 위해 Complex Device Driver라는 컴포넌트를 지원한다. 이것을 통해서 기존에 사용하던 코드의 AUTOSAR 적용을 도와 기존 산업에서 AUTOSAR 표준 도입에서 겪는 어려움을 줄이려는 의도로 보인다.

본 프로젝트에서는 Bottom-Up 방식으로의 개발 가능성을 검증한 것이 기존 OSEK Based 시스템이 있는 경우에 유용할 것이라고 제안했지만, 사실 Complex Device Driver를 통해서 기존 시스템을 AUTOSAR로 끌어오는데 노력을 기울이는 것이 AUTOSAR의 의도에 더욱 부합한다. 하지만 Complex Device Driver를 이용해 기존 코드를 재사용한다는 것도 말처럼 그리 간단하지 않다는 것에 문제가 있다. 이것이 어떤 과정과 절차를 거치며, 어느 정도 수준까지 재사용이 가능한지는 앞으로 연구해 볼만한 주제 가운데 하나다.


Model Based Test의 필요성:
기술 개발에 있어서 V모델을 따르는 것은 이제 어느 산업 군을 막론하고 불문율이 됐다. 이에 따라서 기존 소프트웨어 개발에서는 각 단계별 테스팅 도구들이 많이 등장했다. 이것은 최근 임베디드 소프트웨어 개발을 중심으로 늘어난 MDE(Model Based Engineering) 환경에서 모델링으로 구현된 코드의 테스팅 도구의 필요성을 이끌어냈다. 이것은 AUTOSAR 기반 개발에서도 역시 필요하다.

AUTOSAR 방법론은 아키텍처 수준에서 기능들을 정의 및 검증할 수 있게 해 다운스트림 설계 오류를 감소시킨다지만, 어디까지나 설계 오류의 감소를 돕는 것이지 실제로 오류를 테스트하는 도구는 따로 필요하다. 이번 프로젝트에서도 가상 ECU를 만들고 vrta 모니터를 동작하고 나서야 원하는 대로 구현되지 않았음을 알고, 처음부터 끝까지 반복한 적이 한 두 번이 아니다. ASCET에서 SWC 내부 구성을 Block Diagram으로 옮겨서 시뮬레이션 해볼 수 있지만 하나의 SWC에 대해서만 확인할 수 있고 여러 개의 SWC가 맞물려 동작하는 전체 로직은 확인할 수 없다.

이런 한계를 극복하기 위해 가상 ECU를 만들어 보는 것일 수도 있겠지만, ASCET부터 다시 시작해야 하는 수고를 생각하면 테스팅 도구라고 말하기는 민망하다. 단일 기능 프로그램이지만 설계부터 구현까지 직접 시행착오를 거쳐보니 모델링 코드 기반 개발에서 테스팅 도구의 필요성을 체감할 수 있었다.

앞서 인식한 문제의식을 가지고 남은 학부 기간 동안 공부와 연구를 진행하려고 한다. 첫 번째로는 OSEK을 중심으로 RealTime OS를 공부하면서 제한적으로나마 BSW를 적용해보고 싶다. 또한 기존 레거시 코드를 Complex Device Driver를 통해서 재사용하는 것을 연구해 구체적인 해결방안을 찾아보고 싶다. 향후에 나오는 연구 결과 또한 오토모티브일렉트로닉스 독자들과 함께 나누고 싶다는 생각이다.



AEM_Automotive Electronics Magazine


<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>


  • 100자평 쓰기
  • 로그인


  • 세미나/교육/전시

TOP