AUTOSAR Adaptive 플랫폼서 IDE 및 가상 ECU 배포

AUTOSAR Adaptive 플랫폼서 통합 개발 환경(IDE)과 가상 제어기 배포

이 글은 2023년 1월 AUTOSAR 협회 20주년을 기념해 회원사로부터 접수 선정된 특별 기고문이다. 팝콘사의 'Distributing IDE and Virtual ECU with a New Approach to Effective Development of the AUTOSAR Adaptive Platform'은 Future Automotive Development 분야에 선정되면서 최종 선정된 33개 파트너사 기고 중 하나가 됐다. 채 대표가 팝콘사의 통합 개발 환경 PACON IDE 및 가상 제어기의 탄생 배경을 말한다. AUTOSAR를 적용한 Vehicle OS와 소프트웨어 정의 자동차(SDV)는 기존 개발 방식으로는 Adaptive Application을 효율적으로 개발할 수가 없다. 


글 | 채승엽 대표, PopcornSAR

채 대표는 AUTOSAR 분야에서 15년 동안 개발 활동을 하고 있다. 2014년 12월 AUTOSAR Adaptive Platform 전문기업인 팝콘사(PopcornSAR)를 창업해 Adaptive Platform 도구 및 stack 국산화에 성공했다. 일본 JASPAR에서 2008년부터 2010년까지 Classic Platform 표준화 활동을 했으며, AUTOSAR 협회 Adaptive Platform 표준화 멤버로서 2017년 7월부터 현재까지 활동을 이어가고 있다.  









AUTOSAR를 적용한 Vehicle OS와 소프트웨어 정의 자동차(SDV)는 기존 개발 방식으로는 Adaptive Application을 효율적으로 개발할 수가 없다. 그 이유는 다음과 같다.

1. 자동차 사이버 시큐리티(ISO 21434): POSIX 기반 OS 및 다양한 오픈소스에서 새로운 보안 취약성[CERT C/C++과 CWE(Common Weakness Enumeration)]가 포함된 API가 발견되며, 해당 API의 사용이 금지된다. 모든 개발자가 사용이 금지된 API를 기억할 수 없으며, 기존 개발된 소스 코드에는 사용이 금지된 API가 포함될 수 있다. 다양한 오픈소스에 보안 취약성이 발견되면 해결된 라이브러리가 다시 배포돼야 한다. 모든 개발자는 배포된 라이브러리를 사용해 다시 개발해야 한다. 또 OTA에 의해 SW가 다시 배포돼야 한다.

2. C/C++ 외 다양한 개발 언어(파이썬3, RUST 등)가 포함돼 개발: 자동차에 AI를 적용하려면 AI 모델을 검증해야 하며, AI 모델 검증에는 파이썬3를 사용하게 된다. 자율주행에서 알고리즘을 개발하려면 ROS2를 통한 알고리즘 검증이 필요하다. 최근에는 Functional Safety 관점에서 RUST 언어와 C++ 언어가 같이 통합된 개발도 필요하다.

3. 다양한 ECU의 기능 검증을 위한 가상 제어기: 스마트폰의 경우, 새로운 폰이 출시되기 전 스마트폰용 Application 개발자가 가상 시뮬레이터를 통해 사전 개발 검증할 수 있는 것처럼 자동차 Application 개발자도 새로운 ECU가 출시 되기 전 Application을 개발할 수 있는 환경을 제공해야 한다. 특히 3rd Partner에서 Application만 개발하는 경우는 실제 ECU가 필요하지 않다. 차량 반도체 부족으로 모든 개발자에 개발 보드를 제공하기 어렵다. 여러 개의 가상 ECU를 연동해 개발할 필요가 있다. QNX, VxWorks, Linux 등 1개 ECU에 서로 다른 2개 이상의 OS가 들어가 동작하는 형태가 많아졌다.

‘1. 자동차 사이버 시큐리티’와 ‘2. C/C++ 외에 다양한 개발 언어(파이썬3, RUST 등)가 포함되어 개발’을 하기 위해서는 새로운 통합 개발 환경(IDE)이 필요하고, IDE는 이력 관리가 지원되며, 다양한 개발 언어 지원, 실시간 API 자동 완성 기능 및 사용 금지된 API를 자동으로 표시하는 기능이 필요하다.
기존의 Visual Studio Code에 remote container로 통합 개발 환경(IDE)을 Docker image로 제공할 수 있으며, Jenkins CI/CD 연동을 통해 해당 개발 ECU에 맞게 자동 배포할 수 있다.


 

‘3. 다양한 ECU의 기능 검증을 위한 가상 제어기’는 QNX와 VxWorks는 QEMU 방식으로 구동이 가능하며, Linux는 Docker Container로 구동이 가능하다.
특히 가상 제어기는 실제 ECU와 동일한 CPU 아키텍처를 제공해 기능 검증을 가상 제어기에서 완료하면 컴파일 필요 없이 가상 제어기에서 Adaptive Application을 실제 ECU에 복사해 성능 검증을 할 수 있다.
또한, 가상 제어기도  Jenkins CI/CD 연동을 통해 해당 개발 ECU에 맞게 자동 배포할 수 있다.


 


SDV에서 Adaptive Application을 개발할 때 OEM의 입장(use case1)과 티어 1 혹은 3rd Party Application Supplier(use case2)로 나눌 수 있다.

Use case 1: 1개 OEM에 납품하는 여러 티어 1에 대한 통합 개발 IDE 및 가상 제어기
1개의 자동차 회사가 SDV에 대한 E/E 아키텍처를 정의하고 모든 차종의 variant에 따라 OEM이 티어 1에게 통합 개발 IDE 및 가상 제어기를 배포해야 한다. 해당 통합 개발 IDE 및 가상 제어기는 각 티어 1의 개발 팀에서 사용한다.




그림 1 | OEM에 납품하는 여러 티어 1



Use case 2: 1개 티어 1 혹은 3rd party Application supplier가 동일 서비스 ECU에 대해 여러 OEM을 대응하기 위한 통한 개발 IDE 및 가상 제어기
동일한 개발자, 동일한 Application을 여러 OEM에게 제공하기 위해서는 1명의 개발자가 여러 OEM용 통합 개발 IDE 및 가상 제어기를 선택해 개발할 수 있도록 제공돼야 한다.




그림 2 | 1개 티어 1 혹은 3rd party Application Supplier가 여러 OEM 대응



통합 개발 IDE(PACON IDE)와 가상 제어기는 자동으로 생성 및 배포돼야 한다. 그러기 위해서는 DevOps로 구축된 Jenkins와 dockerhub 등이 필요하다.
통합 개발 IDE(PACON IDE)와 가상 제어기를 자동 배포해 Adaptive Application 개발자는 visual studio Code를 사용해 원하는 개발 환경을 선택할 수 있게 제공할 수 있다. 사용자 PC에서 로컬로 사용하거나, 개발 서버에 원격 접속해 통합 개발 IDE 및 가상 제어기를 선택해 사용할 수 있다. 이런 방식은 laC(Infrastructure as Code)가 적용된 방식으로 통합 개발 IDE 및 가상 제어기를 활용한다.




그림 3 | 통합 개발 IDE 및 가상 제어기를 배포하기 위한 DevOps




그림 4 | IaC(Infrastructure as Code) 방식 적용한 통합 개발 IDE(PACON IDE) 및 Virtual ECU




팝콘사의 Adaptive Platform 표준화 활동  

2017년 7월부터 팝콘사의 9명의 개발자가 4개 Adaptive Platform Working Group인 WG-IVC(ara::com), WG-AP-EMO(ara::exec), WG-UCM(ara::ucm), WG-AP-ST(System Test) 부문서 활동을 해왔으며, 현재는 전체적인 AUTOSAR Adaptive Platform의 아키텍처에 대한 이해가 완료돼 자체 제품 개발 및 판매 성공 후 WG-AP-ST에서만 활동하고 있다. 

AUTOSAR 협회에서는 APD(Adaptive Platform Demonstrator)의 소스 코드를 배포하고 있는데, 표준화 활동 기여자 중 공로를 인정받은 개발자를 영구 등록시킨 AUTHORS 파일(AUTOSAR_SRC_AdaptivePlatformDemonstrator\ara-api\AUTHORS)에 팝콘사의 5명이 전 세계 등재자 204명(22년 11월까지 기준)에 포함돼 있다. 우리나라에서 유일하다.
 



그림 5 | 현재까지 총 6번의 표준화 버전 제품 릴리즈



팝콘사가 개발한 Adaptive Platform 제품  

2018년 3월 R17-10 표준을 지원하는 Adaptive Platform 도구 및 stack을 일본 덴소 본사에 판매한 이후 2020년 4월부터 일본 덴소 그룹사인 AUTOSAR 솔루션 회사인 AUBASS(https://www.aubass.co.jp/)에 팝콘사의 ARXML 설계 도구인 AutoSAR.io 제품을 AUBIST Designer란 이름으로 white level로 독점 공급하고 있다.

그리고 AUTOSAR 협회는 2019년부터 전 세계 AUTOSAR Adaptive Platform 표준화 활동을 지원을 위해 WG 활동 멤버에게 AutoSAR.io를 공식 AUTOSAR협회 표준화 툴로 제공하고 있다. 2022년부터는 국내 대기업 및 차량 SW 기업에게 Adaptive Platform(R20-11) 도구 및 stack을 납품했다. 2023년부터 국내 대학교 석박사 및 학사 전공수업으로 AUTOSAR Adaptive Platform이 채택돼 연세대, 국민대, 충북대 등에 팝콘사 제품을 유상으로 제공하고 있으며, 전공 수업을 진행할 해당 대학의 석박사 강사도 육성했다.

팝콘사는 리눅스 뿐 아니라, QNX 7.1(POSIX OS)에 Adaptive Platform R20-11 적용을 완료해 ADAS ECU를 선행 개발 프로젝트에 참여하고 있다.



통합 개발 환경 PACON IDE 및 가상 제어기의 탄생 배경  

팝콘사는 자체 제품인 Adaptive Platform stack을 릴리스하면서 Adaptive Platform 표준이 매년 나올 때마다 기존의 표준 API가 삭제, 추가, 변경되고, 특히 그림 6과 같이 특정 Functional Cluster 자체가 새롭게 표준이 제정되는 상황이 발생해 자사의 Adaptive Platform stack에서 신규 개발 시 어려움이 발생했다. 이런 표준 변경 환경에 대응해 자사 제품을 효율적으로 개발하기 위해 통합 개발 IDE인 PACON IDE를 만들게 됐고, 팝콘사 고객에게도 Adaptive Application 개발 시 표준 버전 업데이트 시 기존 개발 Adaptive Application이 표준 API의 삭제, 추가, 변경으로 컴파일이 안 되는 문제를 쉽게 해결하도록 PACON IDE를 판매하게 됐다.

Adaptive Platform 표준은 하위 버전 호환성이 없으며, 그림 7과 같이 OS와 Device Driver 표준화를 하지 않으며, in-Vehicle Application을 개발하기 위한 C++ library 표준이다.
또, 반도체 수급 부족으로 개발 보드를 현업에서 쉽게 구할 수 없는 문제, 코로나 이슈로 재택근무와 온라인 수업이 많아진 상태에서 보드 없이 Adaptive Application을 쉽게 개발할 수 있는 환경을 제공하기 위해 가상 제어기를 만들게 됐다.






그림 6 | Adaptive Platform 표준화 히스토리




그림 7 | Adaptive Platform(왼쪽)Classic Platform(오른쪽)의 표준화 차이

---

AEM_Automotive Electronics Magazine