벡터가 제시하는 차량 ECU의 미래
Adaptive MICROSAR와 PikeOS
2019년 11월호 지면기사  / 글│ 윤범진, 한상민 기자_han@autoelectronics.co.kr


Adaptive MICROSAR와 PikeOS:
벡터가 제시하는 차량 ECU의 미래


Vetor Joachim Kalmbach 벡터 요아킴 캄바흐 매니저,  벡터코리아 조재윤 임베디드 사업부장
 
Adaptive AUTOSAR 플랫폼은 고도화되는 첨단 운전자 지원 시스템(ADAS)과 자율주행, 커넥티드 카 기능을 위한 고성능 하드웨어와 안전성 지원, 차량 통신 네트워크 및 보안 요구에 대응하기 위해 등장했다. 벡터코리아 조재윤 임베디드 사업부장과 함께 벡터의 Adaptive AUTOSAR 팀에서 PikeOS, IPC 업무 및 시스고(SYSGO) 대응을 담당하고 있는 요아킴 캄바흐 매니저를 만나 Adaptive MICROSAR에 대한 이야기를 나눴다.
 
글│ 윤범진, 한상민 기자_han@autoelectronics.co.kr



 
Q. Adaptive AUTOSAR의 도입과 자동차 E/E 개발 프로세스 변화에 대해 들려주시지요.
A. 자동차에 고성능 ECU가 들어오면서 Adaptive AUTOSAR가 도입되기 시작했습니다. 이와 함께 현재 진행 중인 OEM의 E/E 아키텍처의 변화를 보면, IVI, 인스트루먼트 클러스터, ADAS, 커넥티비티 등의 도메인에 고성능 중앙제어기가 2개에서 4개까지 도입되고 있습니다.

이것들은 도메인 컨트롤러 개념으로 볼 수 있습니다. 그 아래 인테그레이션 노드에 해당하는 제어기들이 있고, 그 아래에 실제 액추에이터나 센서를 관장하는 기존 제어기들이 놓이는 형식입니다. 윗단에서 특이할만한 점은, OEM에 따라 방향성이 다르다는 것입니다. 예를 들어, 어떤 OEM은 섀시, 바디, 엔진 도메인별로 컨트롤러를 두는 반면, 어떤 OEM들은 ‘드라이버 사이드 프론트’, ‘패신저 사이드 백’과 같이 차 내 위치에 따라 기능을 관장하는 컨트롤러를 두고 있습니다.

한편, 기존 차량 통신이 CAN, LIN, FlexRay 등 시그널 기반이었다면, 현재는 고성능 ECU가 들어오면서 통신 백본으로 이더넷(Ethernet)이 사용되면서 서비스 지향 아키텍처(Service Oriented Architecture, SOA)가 도입되고 있습니다. 따라서 중앙제어기와 인테그레이션 노드 간에 SOA 통신이 이뤄지고, 인테그레이션 노드와 최하위단 사이에는 기존의 시그널 기반 통신이 이뤄지고 있습니다.



출처| HANS ALMNGER, VOLVO CARS, AUTOMOTIVE NETWORKS AND EE ARCHITECTURES, MUNICH2017


Q. Adaptive MICROSAR 플랫폼과 PikeOS의 특징을 보면 당장은 주행안전과 관련된 도메인이 타깃처럼 생각됩니다.
A. Adaptive MICROSAR가 보는 도메인은 ADAS 쪽입니다. 강력한 커넥티드 카 트렌드에 의해 IT 기술융합이 활발하게 일어나면서 AGL(Automotive Grade Linux) 등 리눅스 OS가 각종 드라이버와 호환성을 강점으로 인포테인먼트, 디지털 콕핏과 같은 애플리케이션을 보다 쉽게 구현할 수 있기 때문에 적용이 늘었지만, AGL 리눅스 OS가 보장할 수 있는 세이프티 레벨은 ASIL B까지로 알려져 있고, 이 또한 검증되어야 합니다. ADAS나 자율주행과 같은 다이내믹한 차량의 실시간 환경을 제어할 수 없는 태생적 한계가 있기 때문입니다.

그러나 벡터의 PikeOS와 Adaptive MICROSAR의 경우는 ASIL D까지 보장할 수 있도록 개발되고 있습니다. RTE(Runtime Environment)와 POSIX와 유사한 성격을 갖는 PikeOS는 고성능 프로세서를 탑재할 수 있으면서 프리-컨피규레이션을 통해 실시간성을 보장할 수 있도록 설계되었습니다. 리소스 파티션과 타이밍 파티션을 통해 각각의 애플리케이션들이 할당량을 갖고 임베디드 환경에서 실행시간, 메모리 컨텍스트 스위칭 환경 등을 제어할 수 있습니다. 또한 리눅스에서 사용할 수 있는 드라이버들도 게스트 OS로 올릴 수 있습니다.







PikeOS의 장점을 좀 더 설명하면, 메모리 파티셔닝을 통해 각각의 파티션 위에 QM 애플리케이션, ASIL 애플리케이션을 모을 수 있습니다. QM이 ASIL 레벨 쪽에 접근하려면 반드시 Adaptive AUTOSAR 플랫폼의 IPC(Inter Process Communication)를 통해 접근해야 합니다.





PikeOS는 세이프티가 크게 강조되는 우주항공 분야에서 채택되는 OS입니다만, 벡터가 시스고와 조인트벤처를 설립해 PikeOS를 자동차 세이프티 요구사항을 충족할 수 있도록 재설계했습니다.





Q. Adaptive AUTOSAR 플랫폼의 두드러지는 강점을 요약해 주세요.
A. ▶그동안은 32비트까지 마이크로컨트롤러가 제어기에 탑재돼 자동차의 임베디드 환경을 구축했지만, Adaptive AUTOSAR가 도입되면서 고성능 마이크로프로세서를 사용할 수 있게 됐습니다. ▶이 마이크로프로세서를 제어할 수 있는 OS를 사용할 수 있다는 점도 강점이라고 할 수 있습니다. AGL, QNX 등의 OS는 물론 PikeOS 등 POSIX OS를 Adaptive AUTOSAR와 함께 사용할 수 있습니다. 자세하게, POSIX OS 중에서도 리얼타임 시스템을 위한 서브셋인 PSE51(POSIX System Environment Profile)을 사용할 수 있습니다. ▶또한 스마트폰처럼 애플리케이션을 자동차에 다운로드할 수 있는 유저 환경이 구현될 수 있습니다.


Q. 안전성 이야기가 나와서 그런데, 전통적으로 자동차는 마이크로컨트롤러에 익숙합니다. 이런 점에서 마이크로프로세서의 사용과 관련된 신뢰성 이슈, 제한적인 선택지를 어떻게 보십니까?
A. 양산에 쓰이고 있는 마이크로프로세서들을 보면, 퀄컴, 인텔과 같은 스마트폰에 쓰였던 애플리케이션 프로세서 벤더들의 칩셋이 쓰이고 있습니다. 삼성의 엑시노스 오토(Exynos Auto)도 아우디에 들어가고 있습니다. 실제로 마이크로프로세서의 선택지가 많지 않은 것은 사실이지만, 마이크로컨트롤러 또한 벤더로만 따진다면 마찬가지라고 할 수 있습니다.
마이크로프로세서는 다이내믹 메모리를 쓰다 보니 메모리의 실행시간이나 메모리 사이즈의 규정이 힘든 등 신뢰성 이슈가 있습니다. 때문에 이를 보완하기 위해 마이크로컨트롤러가 함께 사용되면서 세이프티 기능들을 담당합니다. 제가 알기로도, 마이크로프로세서 단독으로 ASIL C, D 레벨을 인증 받은 사례는 없습니다. 하지만 앞으로 이런 신뢰성 이슈는 지속적으로 개선될 것입니다.

 
Q. Adaptive AUTOSAR 플랫폼의 강점 중 하나로 OTA를 말씀하셨습니다. 연결성과 보안성은 어떻습니까?
A. Adaptive AUTOSAR 플랫폼의 목표 중 하나는 무선 업데이트를 통해 소프트웨어 수정을 유연하게 하는 것입니다. 이를 위해 플랫폼에는 업데이트 컨피규레이션 매니저라는 기능 클러스터가 있어 업데이트 모듈, 애플리케이션들을 인증한 후 업데이트 요청을 처리하게 합니다. 이것이 보안 기능을 담당하는 것입니다. 또 플랫폼은 보안을 위한 API를 지원하고 API는 하드웨어 보안 모듈(HSM)과 같은 별도의 요소를 통해 보안성을 지원합니다.





Q. 벡터의 Adaptive AUTOSAR 베이직 소프트웨어 제품인 Adaptive MICROSAR가 출시됐습니다. 경쟁사와 차별점이 있다면 무엇입니까?
A. ▶우리는 이미 내년 초 양산이 예정된 OEM 프로젝트에 따라 2019년도 3분기에 QM 릴리스를 했습니다.
▶벡터의 Adaptive MICROSAR 베이직 소프트웨어 솔루션은 특히 구현 측면에서 소스 코드, 서드파티, 오픈소스, 협회 등의 코드 사용 없이 ASPICE 레벨 3를 만족하면서 100% 벡터의 코드로 구현한 것입니다. 현재 ASIL D 수준을 만족하도록 개선 중으로, Adaptive AUTOSAR는 외부인증기관인 Exida를 통해, PikeOS는 Tu¨v를 통해 ASIL 인증을 받을 예정입니다.
▶SOME/IP를 활용하면 타이밍 이슈가 있는데, 벡터가 개발한 V-IPC를 통해 SOME/IP를 통하지 않고 이종 플랫폼 간 통신을 직접 가능토록 한 점도 큰 강점이라고 생각합니다. 주로 SPI 버스를 사용해 Classic과 Adaptive AUTOSAR 플랫폼 간 통신을 할 수 있는 것입니다.
▶벡터는 또한 SOME/IP 대신 ECU 간 통신을 위한 ROS(Robot Operating System)라는 통신 바인딩도 제공할 수 있습니다.
▶벡터는 이와 관련 저작 툴인 PREEvision 툴체인을 통해 아키텍처 설계부터 와이어링 하네스까지 전체 E/E 개발을 지원하고, CANoe를 통해 전반적인 ECU 네트워크와 개별 ECU 개발, 테스트, 분석을 지원합니다. 컨피규레이션 환경에서는 이클립스 기반의 ID환경이 있습니다.

 
Q. Classic AUTOSAR에 대한 벡터의 MICROSAR와 Adaptive MICROSAR 간 호환성은 어떻습니까?
A. 현재 협회의 움직임을 보면, Classic이 시그널 기반 통신이다 보니 Adaptive의 SOA 통신과 잘 맞지 않아 시그널 툴 서비스 매핑에 대한 표준화 작업이 진행되고 있습니다. 벡터 또한 이에 대해 시그널 툴 서비스 컨버터를 개발, 시그널 툴 서비스 게이트웨이 프로토타입에 적용해 MICROSAR와 Adaptive MICROSAR의 호환성을 높이고 있습니다. 또 ADAS 도메인 쪽 제어기들과 시그널 프로세싱 제어기 간 싱크를 맞춰주는 타임 싱크로나이제이션(time synchronization) 기능의 QM 릴리스가 연말로 잡혀 있습니다.


Q. 장기적으로 Classic AUTOSAR와 Adaptive AUTOSAR가 하나의 플랫폼으로 통합될 가능성이 있을까요?
A. 경제성 측면에서 보면, 제어기를 저렴하게 구성하기 위해서는 Classic AUTOSAR와 Adaptive AUTOSAR가 공존해야 합니다. 예를 들어 Adaptive AUTOSAR 환경에서는 메모리 매니지먼트 유닛(MMU)이 필요하고 이에 따라 SOC 가격이 높습니다. 또한 시그널 기반 통신이 아니다보니까 이더넷을 위한 와이어링 비용도 큰 부분을 차지합니다. Classic AUTOSAR 환경에서는 시그널 기반 통신이고 제어기들도 작기 때문에 두 플랫폼이 공존할 것이라고 봅니다.


Q. Classic AUTOSAR를 하다가 현재 Adaptive AUTOSAR에 집중하고 계신데, 엔지니어로서 어떤 것이 도전과제입니까?
A. OS 환경 자체가 많이 다릅니다. Classic AUTOSAR에서는 RTE를 사용해 OS 제어가 비교적 간단한 이뤄지는 반면, Adaptive AUTOSAR는 RTE 같은 미들웨어가 없고, OS에서 해야 할 것이 많기 때문에 OS를 많이 공부해야만 합니다. 또한 언어 자체가 기존의 C코딩에서 객체 지향의 C++로 바뀌고 모든 API와 애플리케이션이 C++로 돼 있기 때문에 이 또한 도전입니다. 한편, 기능 클러스터에 따라 Adaptive AUTOSAR가 규정한 새로운 API를 익히는 것도 힘듭니다. Adaptive AUTOSAR 관련 직접적인 도전은 아니지만 이 환경에서 사용되는 하드웨어에 대한 적응도 요구됩니다.


Q. PikeOS가 벡터의 Adaptive MICROSAR와 함께 브랜딩되는 것은 아닌가요?
A. 아닙니다. 벡터는 시스고를 인수한 것이 아니라 조인트벤처를 설립한 것입니다. 따라서 PikeOS를 MICROSAR와 통합하지는 않습니다. 그렇지만 고객 입장에서 본다면 BSP, 하이퍼바이저, PikeOS, 미들웨어, AUTOSAR Classic Platform 등 벡터를 통해 한 번에 공급받는 유저 경험의 통합은 가능할 것입니다.



AEM_Automotive Electronics Magazine


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

PDF 원문보기

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)

  • 100자평 쓰기
  • 로그인


  • 세미나/교육/전시

TOP