지난 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 소프트웨어의 개발 가능성을 검증하고 적용 시 고려사항을 점검하는 것이었다.

작년 봄 우연한 기회로 AUTOSAR를 접하고, 주위 동기들이 너도나도 앱을 개발하고 있을 때 홀로 자동차 공부를 시작했다. “소프트웨어 전공생이 왜 기계과 학생들이 하는 것을 붙잡고 있느냐”, “이거 공부해서 어디다 쓸 것이냐”고 핀잔을 듣기도 했지만 묵묵히 1년간 이 길을 걸어왔다. 그 결과 이렇게나마 작은 결과물을 냈고 기쁘게도 교내에서 상을 받기도 했다.

이 후 힘들게 배운 것을 놓고 싶지 않아 소학회에 자동차 융합 스터디 그룹을 만들었다. 근사한 스터디 그룹을 조직하기 위해 될성부른 떡잎으로 보이는 후배들을 섭외하러 다녔다. 이 때 모두에게서 “이걸 왜 해야 되죠”란 같은 질문을 받았다. 이 질문에 답하면서 글을 연다.

AUTOSAR의 필요성

소프트웨어를 전공하는 학생으로서 AUTOSAR에 대한 학습과 프로젝트 경험이 필요한 이유는 크게 두 가지다. 첫째는 자동차 도메인에서 소프트웨어 엔지니어로서의 필수 역량이기 때문이고, 둘째는 학습도구로서의 탁월함 때문이다.

국내 회사에서는 아직 AUTOSAR가 적용돼 양산된 차량이 없는 것 같다. 하지만 AUTOSAR가 일으키는 파도를 피할 수 없을 것이라는 것이 현재의 지론이다. 왜냐하면 자동차 품질에 소프트웨어가 미치는 영향이 점점 커지고 있고, 앞으로 자율주행, 커넥티드 카로 발전하는 방향성에서 소프트웨어가 핵심 요소가 될 것이라는 것은 누구도 부정할 수 없기 때문이다. ‘자율주행’하면 누구나 자동차 제조사가 아닌 구글을 떠올리기 때문에 더욱 그렇다고 볼 수 있다.

AUTOSAR는 그 소프트웨어 개발에 있어서 하드웨어와 독립적인 개발을 용이하게 한다는 것을 가장 큰 장점으로 꼽는다. 임베디드 소프트웨어 범주에 속하는 차량 소프트웨어 개발에서 하드웨어 의존성을 피할수 있다는 것은 큰 축복이다. 즉 차량 내 소프트웨어 비중 증가와 개발상 이점 때문에 AUTOSAR는 앞으로 자동차 업계에서 필수불가결한 요소가 될 것이다. 따라서 자동차 도메인의 소프트웨어 엔지니어를 꿈꾸고 있는 학생이라면 AUTOSAR는 피할 수 없는 요소가 된다.

사실, 학생들에게는 두 번째 이유가 더 설득력이 높다. 왜냐하면 학생 입장에서는 앞으로 어느 회사에 가게 될지, 어느 학교에 진학할지가 불확실하기 때문에 선뜻 자동차 도메인을 진로로 선택하는 것이 두렵기 때문이다. 하지만 자동차 도메인의 특수성은 차치하더라도 AUTOSAR는 공부할만하다. 그 이유는 AUTOSAR 표준문서의 정교함에 있다. 자동차 소프트웨어는 사람의 안전, 생명과 직결되기 때문에 고도의 정밀함을 요구한다. 하나의 오류가 불러올 수 있는 파장이 버전 업데이트 릴리스 시 한 줄의 글로 실수가 만회되는 상용 애플리케이션 소프트웨어와는 비교할 수 없다. 따라서 소프트웨어의 안정성에 대한 많은 노하우가 차량 소프트웨어 개발 업계에 누적돼 있고 그것들이 모이고 엄선돼 만들어진 것이 AUTOSAR다.

또 AUTOSAR는 아키텍처 뿐만 아니라 방법론도 표준화했는데, 이는 단순하게 결과물 위주로 개발해왔던 과제식 마인드에서 벗어나 프로젝트를 바라볼 때 프로세스, 생산성 그리고 품질을 고려하는 소프트웨어 공학 관점으로의 전환을 유도한다. 물론 교과과정 중에 시스템 공학, 소프트웨어 공학과 같은 과목이 있지만, 학생들에게는 “랍스타는 맛있는 음식이다”처럼 단지 누군가가 정립해 놓은 이론 정도로 개념화 돼 있다. 학부생이 개발에서 소프트웨어 공학을 고려해야 할 정도의 프로젝트를 접하기란 사실 힘들기 때문이다.

AUTOSAR Methodology를 따랐을때 절차 간에 교환되는 파일은 xml 형식으로 강제된다. AUTOSAR 기반 개발을 위해서는 이 xml 파일을 읽고 해석해 적용할 수 있어야 한다. 이는 전통적인 웹, DB 분야 뿐 아니라 다양한 도메인에 소프트웨어를 접목할 때 데이터 교환 형식으로 xml이 많이 응용된다는 점을 볼 때, AUTOSAR를 앞으로 사용하지 않더라도 이 능력은 계속해서 유효할 것이다. 이외에도 Real-Time OS를 접해본다는 점 등 전통적인 컴퓨터 전공 과목들에서 접하기 힘든 요소가 많아 배울 거리는 무궁무진하다.

하루가 다르게 급변하는 IT 분야에서 가장 필요한 능력은 많은 지식이 아니라 학습능력이라고 생각한다. 많은 지식이 공유되고 상호작용을 하면서 급속도로 발전하는 이 시대의 변화에 적응하고 대처할 수 있는 근본적인 능력을 키우는 것은 대학생으로서 가장 주의를 기울여야 할 부분이 아닐까. 이런 맥락에서 AUTOSAR에 대한 학습은 이를 개발해 앞으로 IT 분야의 전문가로 성장하기 위한 토양을 다지는 데에 매우 적합하다. 후배들에게 AUTOSAR는 “랍스타를 실제로 먹어볼 수 있는 기회”라고 자신 있게 얘기 할 수 있다.

아주대학교 융합프로젝트

미래 자동차 융합분야에서 AUTOSAR는 필수 불가결한 요소가 될 것이고, 자동차 소프트웨어 엔지니어의 핵심 역량 중 큰 부분을 차지할 것이라는 전망을 갖고 아주대 소프트웨어융합학과의 이정태 교수 지도하에 처음 AUTOSAR를 접했다. 2014년 봄부터 약 3개월 간 자동차 도메인에 대한 스터디를 진행한 후, 그 해 11월부터 두 달에 걸쳐 아주대학교 IT집중교육 과정에서 본격적으로 AUTOSAR 프로젝트를 시작했다. 이 집중교육은 해당 기간 동안 매일 3시간의 이론수업, 4시간의 실습, 그리고 그 이후 과제와 팀 프로젝트가 부여되는 하드트레이닝 과정이다. 2달 간 AUTOSAR 프로젝트를 위한 기초과정을 짧고 굵게 배웠다.

자동차 전장장치 입문 교육, AUTOSAR XML을 읽어내기 위한 XML 교육, 소프트웨어 모델링과 분석 설계에 관한 내용까지 하나하나를 보면 한 학기 동안 해도 될 만한 주제들이어서 이것을 다 소화할 수 있을까란 의문이 들었지만 집중교육 특유의 강도 높은 분위기 때문에 짧은 기간에 효과적으로 배워나갈 수 있었다.

한 달이 좀 넘는 시간 동안 AUTOSAR 스펙을 읽어 내기 위한 최소한의 준비를 마치고, 마지막 2주간 더듬더듬 SWC templates 문서들에서 필요한 부분들을 찾아 읽어가며 최종 프로젝트를 진행했다. IBM의 Rhapsody, 이타스의 ASCET, ISOLAR-A, ISOLAR-EVE를 이용해 작은 기능을 하는 가상 ECU를 구현하고 자바 GUI 시뮬레이션 프로그램과 연동하는 것까지 성공했다.

현장실습 주제

집중교육 결과물을 뽑아내는데 세운 공로를 인정받아 교수님 추천으로 이타스코리아에서 현장 실습을 하게 됐다. 현장 실습에서는 집중교육 때 수행했던 프로젝트를 Top-Down이 아닌, ASCET부터 ISOLAR-A로 개발해가는 Bottom-Up 방식으로 개발하게 됐다.

프로젝트 목적

이타스 ASCET은 임베디드 소프트웨어 코드를 모델링 방식으로 만들 수 있도록 지원하는 프로그램이다. ASCET은 이러한 기본 용도 이외에 AUTOSAR를 지원해 주로 AUTOSAR의 SW 컴포넌트 내부 코드 Implementation을 하는 데 사용된다. 또한 AUTOSAR SW Component 및 Interface들의 생성 및 설정을 지원해 Implementation과 동시에 Architecture 모델링을 할 수 있어 Bottom-Up 방식의 ECU 소프트웨어의 제작을 지원한다.

Bottom-Up 모델링은 앞서 말한 바와 같이 이미 OSEK 기반 양산 코드가 있는 경우 등 Architecture 설계가 완성되고 검증된 경우에는 개발생산성 상의 이점이 있어 사용된다. 따라서 본 프로젝트에서는 ASCET을 통한 AUTOSAR 기반 ECU 소프트웨어의 Implementation 및 모델링을 한 후 ISOLAR-A를 통해 Authoring하는 과정을 거쳐 Bottom-Up 방식으로 ECU 소프트웨어의 개발 가능성을 검증하고 적용 시 고려사항들을 점검하고자 했다.

ASCET 모델링

및 Implementation ASCET은 이클립스와 같은 형식의 Workspace 방식과 각 Component와 Interface 별로 독립적인 단위를 형성하는 Database 방식 중 하나를 택해 프로젝트 관리가 가능하다. 자신이 편한 방식을 사용하면 된다. 본 프로젝트에서는 Database를 사용하기 때문에 새로운 Database를 생성했다. Database에 구성하고자 하는 Software Component를 생성했다. ASCET에서는 Software Component Type을 구분하지 않고 모두 Software Component로 지정하기 때문에 Application SW Component Type, ECU Abstraction SW Type, Parameter SW Component Type 등의 모든 SW 컴포넌트는 동일하게 Software Component 아이콘을 통해 만들었다.

SW Component를 만들었으면, 이 Component 사이에 상호작용을 매개할 Interface를 생성한다. Interface에 따라서 SW Component 내부의 구성이 달라지기 때문에 이 부분을 먼저 설정해줘야 한다. ASCET에서는 Interface의 성격에 따라 Sender Receiver Interface, NVData Interface, Calibration Interface, Client-Server Interface를 지원한다. 본 프로젝트에서는 Databased communication 대표로 Sender-Receiver Interface와 Operationbased communication 대표로 Client-Server Interface를 사용해 Software Component(이하 SWC라고 한다.)를 구성했다.

먼저 필요한 Sender-Receiver Interface와 Client-Server Interface들을 각각 특정 S W C 의 하위 수준이 아닌 Database 내 SWC들과 같은 수준으로 만든다. 이렇게 하면 각 Interface Component를 다른 Component 내에서 Insert하는 방식으로 SWC에 구현할 수 있다.

Interface 내부는 다음과 같이 설정한다. Sender-Receiver Interface는 해당 Interface를 통해 전달할 data 이름과 type을 지정해 Interface 내부에서 생성해 준다. Client-Server Interface의 경우에 먼저 해당 Interface를 통해 실행시킬 operation을 생성해준다. Operation의 하위 항목으로 argument와 return 값을 설정하는데, argument는 원하는 만큼 생성이 가능하며 type과 argument의 방향을 설정해 줘야 한다. 방향은 In, Out, InOut이 있으며 In은 Server로 전달되는 argument이고 Out은 Server에서 Client로, InOut은 두 방향 모두로 전달되는 argument임을 의미한다.

여기에 default Return 값이 하나 있는데, standard type 또는 enum type으로 설정할 수 있다.
SWC 내부에서 Interface의 구현은 두 가지 방식으로 이뤄진다. Provide인지, Require인지를 선택해 줘야 한다. Sender-Receiver Interface의 경우에는 Sender가 Provider, Receiver가 Require이고 Client-Server Interface는 Client가 Require, Server가 Provide이다. 주의할 점은 Client-Server Interface에서 Provide 측에서 오퍼레이션에 의한 Runnable Entity가 자동 생성돼 Client-Server Interface의 Operation Invoked Event에 의해 실행될 프로그램은 이 Runnable Entity를 통해서만 구현해야 한다는 점이다.

이렇게 SWC들 사이의 Interface에 의한 구성을 마치면 Interface를 이용해 주고 받은 값들을 이용해 나머지 Implementation 부분을 구현해주면 된다. 각 SWC 내에서 Runnable Entity를 생성하고 다이어그램 오른쪽에 있는 아이콘들을 click & drop으로 위치시키고 선으로 연결해 구현하고자 하는 로직을 완성할 수 있다. 모델링에는 Sequence Call을 설정해 Runnable Entity 할당 및 코드화 순서를 결정한다.

이렇게 Implementation까지 완성했으면 각 SWC 별로 Code Generation을 해 AUTOSAR가 적용된 C-코드를 뽑아낼 수 있다. 이 코드는 추후에 ISOLAR-A를 통해 Authoring되어 generation된 RTEgeneration 코드에 적용해 최종 ECU 소프트웨어를 완성하는 데 사용한다.

ISOLAR-A를 이용한 Authoring

AUTOSAR 특징 중 하나는 Methodology를 표준화하고 ECU 소프트웨어 개발 단계를 거칠 때마다 XML 스키마를 따르는 .arxml 형식의 파일을 통해 모든 요소가 tool에 독립적으로 표준화된다는 점이다. 이 파일을 통해 ASCET과 ISOLAR-A가 지원하는 AUTOSAR 요소들의 범위가 다르지만 ASCET에서 ISOLAR-A로 손쉽게 프로젝트를 이어서 진행할 수 있고, 그 반대의 경우 또한 호환성을 보장해 원활한 개발을 진행할 수 있다.

ASCET to ISOLAR-A

ASCET에서Code-generation을 통해 추출된 파일 중에 .arxml 형식의 파일들이 있다. ISOLAR-A에서 ECU Configuration Parameters를 포함하고 있는 프로젝트를 생성한 후, 이 arxml 파일들을 프로젝트에 import시킨다. 이때 주의할 점은, ASCET에서는 프로젝트 단위가 아니라 SWC별로 Code-generation을 하기 때문에 공통된 파일은 겹친다는 것이다. 따라서 AUTOSAR_MOD_PlatformBaseTypes_TC1796.arxml, AUTSOAR_MOD_PlatformTypes.arxml,‘SWC이름’_addrmethods.arxml, ‘SWC이름 ’_appltypes.arxml,‘SWC이름’_dataconstrs.arxml, ‘SWC이름’_mappings.arxml 파일들은 하나만 import하고, ‘SWC이름’_interfaces.arxml 파일들은 arxml을 열어서 내부에 interface들이 중복되지 않게 하나만 남기고 지워주는 작업을 해야 한다. 위 과정을 모두 마치면 ASCET에서 모델링한 SWC들의 구성과 필요한 요소들을 ISOLAR-A에서 확인할 수 있다.

이 때 authoring 작업에 들어가기 전 arxml 파일을 수동으로 수정해주는 작업이 필요하다. ASCET에서 만든 모든 SW Component Type은 arxml에 application SW Component Type으로 생성돼 있다.

따라서 ECU Abstraction SW Type이나 Parameter SW Component Type 등 다른 종류의 SW component type은 직접 arxml을 열어서 선언부를 수정해 줘야 한다. 수정후 프로젝트를 저장하게 되면 ISOLAR-A에서 해당 타입으로 변경된 것을 아이콘과 함께 확인할 수 있다.

Authoring

앞선과정을 통해 Application Layer의 모든 요소들에 대한 구성이 끝났다. 이 소프트웨어가 E C U에 올라가기 위해서는 BSW(Basic Software) 설정 및 ECU Configuration이 반드시 필요하다. 자세한 내용은 AUTOSAR Templates의 AUTOSAR_TPS_BSWModule DescriptionTemplate.pdf 파일과 AUTOSAR_TPS_ECUConfiguration.pdf 파일을 통해 확인할 수 있다. 본 글에서는 가상 ECU를 위한 최소한의 과정만을 다룬다.

이 과정을 위해서는 먼저 Target 시스템에 들어가게 될 SWC들의 prototype을 통해 Target ECU Instance를 추출해야 한다.
이는 ISOLAR-A의 AR Explorer 탭을 통해 진행이 된다. 시스템 정보를 나타내기 위해 가장 먼저 target ECU에 들어갈 SWC들의 구성도를 나타낸 Composition SW Component Type의 다이어그램이 필요하다.

새로운 다이어그램을 생성하고 prototype editor를 통해 열어, 기존에 만들어져 있던 SWC들을 drag & drop으로 다이어그램 내에 놓으면 해당 SWC의 Prototype이 생성된다. 이 프로토타입들을 Assembly connection 또는 Delegation Connection으로 연결하고, 이렇게 구성된 Composition SW type을 root System Info에 할당한다. 그 후 ECU Instance를 생성한 뒤, ECU Instance와 이 ECU에 할당될 SWC Component들의 prototype들을 mapping한다. 이렇게 mapping까지 마치면 ISOLAR-A의 ECU EXTRACT 생성 기능을 통해 추출된 ECU Instance와 추출된 ECU System 정보가 담긴 요소, ECU Instance에 대한 FlatMap과 FlatView가 자동으로 생성된다. 이렇게 Target 시스템에 대한 ECU Instance 추출 과정은 끝이 난다.

이제 ECU Configuration을 위한 최소한의 준비과정은 끝이 났다. AR Explorer의 ECU 탭에서 ECU Configuration 설정을 하자. 가장 먼저 EcucValueCollection을 생성하고 여기에 추출된 ECU Instance를 할당한다. 그 후 EcucValueCollection을 더블 클릭하면 해당 ECU Instance에 있는 모든 Runnable Entity에 대해서 Task를 할당할 수 있게 된다. 타깃 시스템의 특성에 맞춰 테스크를 생성하고 priority를 설정할 수 있다.

이때 한 Task 내에 여러 개의 Runnable Entity가 할당돼 있다면 해당 Task 내에서도 Runnable Entity들 간에 Priority를 설정할 수 있다. Priority에 따라서 타깃 시스템의 퍼포먼스에 영향을 미칠 수 있으니 프로그램의 로직과 타깃 시스템의 특성에 맞춰 주의해 설정해야 한다.
이렇게 ECU Configuration이 끝나면 RTE-generation을 이용해 RTE 코드를 추출할 수 있다. 이 프로그램은 가상 ECU의 가상 센서와 액추에이터를 통해 가상 ECU 소프트웨어의 구현 가능성을 확인하고 시뮬레이션 프로그램과 연동을 점검하기 위한 BSW를 설정하지는 않았다.
가상 ECU 구현 및 시뮬레이션 프로그램과의 연동은 다음 호에서 다루겠다.