AUTOSAR는 많은 OEM의 자동차 ECU 개발에 보편화되었지만, 새롭고 더 복잡한 자율주행차 기술이 시장에 출시됨에 따라 AUTOSAR는 어떤 역할을 하게 될까?
자율주행 차량 - 레벨 3
자율주행 시스템의 성능이 향상됨에 따라 운전자의 지원이 덜 필요한 자동차 시대에 접어들었지만, 가까운 미래에는 여전히 운전자가 백업용으로 필요할 것이다(예: SAE 레벨 3, 그림 1). 레벨 3 시스템인 조건부 주행 자동화는 특정 조건과 특정 위치에서만 작동하므로 대부분의 시간 동안 운전자가 차량을 제어해야 하며, 모든 조건이 충족될 때만 차량이 주행 작업을 제어할 수 있다. 따라서 여정 내내 차량과 운전자 간, 또는 그 반대로 차량과 운전자 간 제어권 이전이 이루어져야 한다.
그림 1. SAE 자동화 수준
SAE 레벨 3은 차량 제조업체에게 큰 진전이 될 것이다(입증해야 하는 견고성 수준은 민간 항공 표준과 유사합니다). 인간은 적응력이 뛰어나며 일반적으로 잘못된 제어 및 지시를 해결할 수 있다. 그러나 레벨 3 차량이 완전히 제어되면 더 이상 차량의 한계에 적응해야 하는 것은 운전자가 아니다. 차량은 운전자의 한계, 즉 모든 운전자의 한계에 적응해야 한다. 차량이 운전자에게 제어권을 넘겨야 한다고 판단하면 이를 신속하고 강력하며 명확하게 전달할 수 있어야 한다.
그렇다면 레벨 3 차량은 어떻게 차량과 운전자 간에 주행 작업의 제어권을 안전하게 이전할 수 있을까?
제어권 이전에는 여러 가지 측면이 있습니다(그림 2):운전자에서 차량으로:
차량은 필요한 조건이 충족되고 필요한 경우 차량이 자율 주행할 수 있음을 운전자에게 알려야 한다.
운전자는 차량이 제어권을 갖기를 원한다는 의사를 차량에 알려야 한다.
차량이 제어권을 확보하고 운전자에게 제어권을 확보했음을 안정적으로 알려야 한다.
차량은 제어권을 되찾은 후에도 운전자를 지속적으로 모니터링하여 필요한 경우 운전자가 다시 제어할 수 있는지 확인해야 한다.
차량에서 운전자로:
다음과 같은 경우 차량은 제어권 이전 절차를 시작해야 한다:
차량이 제어를 유지할 수 없음(긴급 이송)
드라이버가 드라이버 모니터링 시스템에 응답하지 않는다.
시스템에 필요한 조건이 더 이상 충족되지 않는다.
요청이 있는 경우 운전자가 차량을 제어해야 한다.
표준 제어권 이전 - 구현에 따라 30~60초 동안 통제된 절차에 따라 제어권 이전이 이루어진다.
긴급 제어권 이양 - 긴급 상황으로 인해 운전자가 제어권을 이양해야 하는 경우, 대부분의 시스템에서 최소 5~10초가 소요됩니다.
운전자가 운전자 모니터링 시스템을 제어하거나 응답하지 않으면 차량은 안전 상태로 돌아가며, 대부분의 경우 차량이 차선에 정차하고 긴급 호출을 시작한다.
그림 2 제어권 이전. 출처: sbdautomotive.com(운전자 및 객실 모니터링 - 보고서 810)
이러한 제어권 이전은 휴먼 머신 인터페이스(HMI)를 사용하여 차량과 운전자 간에 관리해야 한다. 차량 내 HMI 시스템에는 터치스크린, 디스플레이, 스위치, 버튼, 오디오, 음성 및 햅틱이 포함된다. 특히 전통적으로 자동차 안전 무결성 수준(ASIL) 요구 사항을 지원하지 않는 오디오 및 인포테인먼트 시스템을 통합할 때는 필요한 기능 안전 요구 사항을 충족하도록 시스템 설계를 신중하게 고려해야 한다. 대부분의 경우 사용 가능한 다양한 디스플레이를 사용하는 시각적 HMI, 차임 또는 음성 명령 형식의 오디오 피드백, 시트 또는 스티어링 휠 액추에이터를 통한 촉각 피드백, 운전자 입력용 스티어링 휠 버튼 및 스위치의 조합이 있을 것이다(그림 3). 여러 HMI 시스템을 사용하면 중복성을 보장하고 기능 안전 요구 사항을 더 높은 ASIL-D 등급에서 더 낮은 ASIL-B/A 등급으로 세분화할 수 있으므로 설계 변경이 개별 시스템에 미치는 영향을 줄이고, 운전자가 디스플레이에서 주의가 산만하거나 청각 장애가 있어 오디오 피드백을 듣지 못할 가능성이 있는 경우에도 운전에 몰입할 가능성을 높일 수 있다.
그림 3. 제어 HMI 전송. 출처: sbdautomotive.com(운전자 및 캐빈 모니터링 - 보고서 810)
예상할 수 있듯이 레벨 3 시스템의 전체 시스템 설계에는 모션 제어, 차체 및 AV/ADAS 도메인의 여러 센서 및 스마트 센서, ECU 및 액추에이터가 통합되지만 제어 요구 사항의 이전으로 인해 이제 오디오 및 인포테인먼트 도메인에도 영향을 미치게 된다. 이로 인해 ASIL-D 기능 안전 요구사항을 충족하는 레벨 3 자율 주행 시스템을 제공하기 위해 여러 도메인 및 ECU에 걸쳐 여러 티어 1 공급업체의 매우 복잡한 전체 시스템 설계가 필요하다. AUTOSAR를 사용하면 공통 소프트웨어 아키텍처 프레임워크를 제공함으로써 개발의 어려움을 일부 완화할 수 있다.
또 다른 중요한 추세는 전자 하드웨어와 소프트웨어의 성능이 향상됨에 따라 여러 도메인에 걸친 기술이 더 적은 수의 더 복잡한 다기능 ECU로 통합되고 있다는 점입니다. EE 아키텍처는 기능 중심의 ECU에서 보다 복잡한 기능 도메인 컨트롤러로, 그리고 향후에는 중앙 집중식 및 구역별 아키텍처로 이동하고 있습니다(그림 4). 이를 통해 궁극적으로 완전히 확장 가능한 서비스 지향 아키텍처를 구현하여 많은 사람들이 소위 말하는 소프트웨어 정의 자동차즉, 대부분의 기능이 하드웨어에 구애받지 않는 소프트웨어 플랫폼에 구축된 차량을 의미합니다. 이 개념을 통해 제조업체는 다양한 하드웨어 구성과 독립적으로 소프트웨어를 개발하는 동시에 생산 과정에서 업데이트 가능한 차량 플랫폼의 이점을 누릴 수 있으며, 이를 위해 대부분의 제조업체는 아웃소싱 파트너나 티어 1이 아닌 내부 소프트웨어 개발 팀을 확장하여 차량의 소프트웨어 제품 로드맵을 관리하고 있습니다.
대부분의 경우 티어 1은 여전히 하드웨어 및 소프트웨어 구성 요소를 제공하지만 시스템의 소유권은 OEM에 있다. 이러한 복잡한 시스템을 여러 공급업체의 컴포넌트와 통합해야 한다. OEM은 AUTOSAR 프레임워크를 사용하여 휴대용 소프트웨어 컴포넌트와 이들 간의 통신 인터페이스를 정의할 수 있다. 이는 어려운 시스템 통합 및 디버깅 작업에 도움이 될 수 있으며, EE 아키텍처가 발전함에 따라 많은 소프트웨어 컴포넌트를 재사용할 수 있다는 것을 의미한다.
그림 4. 차량 내 전기 아키텍처의 예상 발전 방향. 출처: sbdautomotive.com(EE 아키텍처 플랫폼 - 보고서 630)
자동차 오픈 시스템 아키텍처(AUTOSAR)는 자동차 ECU를 위한 개방형 표준 소프트웨어 아키텍처를 만들기 위해 2003년에 설립된 자동차 OEM, 티어 1 및 기술 개발자의 개발 파트너십이다. 이 아키텍처는 소프트웨어 구성 요소를 캡슐화하여 하드웨어 독립성을 제공하기 위해 표준 소프트웨어 모듈과 서비스 인터페이스를 정의한다(그림 5). 플랫폼의 첫 번째 릴리스는 2006년 5월에 출시되었으며, 2008년에 AUTOSAR 기술의 첫 번째 구현이 시장에 출시되었다.
그림 5 AUTOSAR 클래식 플랫폼. 출처: https://www.autosar.org/standards/classic-platform/
초기 플랫폼은 단일 기능을 제공하는 마이크로컨트롤러 기반 ECU를 대상으로 했으며, 출시 이후 대부분의 자동차 OEM이 AUTOSAR 조직과 파트너 관계를 맺으면서 상당한 시장 점유율을 확보했다. 자동차 시스템의 복잡성이 증가함에 따라 마이크로컨트롤러 기반의 단순한 단일 기능 ECU에서 마이크로프로세서 기반의 보다 복잡한 다중 기능 ECU로 이동하고 있다. 이에 따라 커넥티비티, 시간 동기화, 사이버 보안, V2X, SOTA 등과 같은 고급 기능을 지원하는 더욱 발전된 소프트웨어 아키텍처가 필요해졌으며, 이에 대응하여 AUTOSAR는 멀티코어 SoC에서 실행되도록 설계된 POSIX 기반 운영 체제를 제공하는 Adaptive 플랫폼(그림 6)을 개발했다. 기존 플랫폼은 클래식으로 이름이 바뀌었고, 공유된 낮은 수준의 요구사항과 사양은 파운데이션 표준에 포함되었다.
그림 6. AUTOSAR 적응형 플랫폼
적응형 플랫폼은 2017년 3월에 처음 출시되었으며, 현재 두 플랫폼은 공존하며 서로를 보완하고 있다. 적응형 플랫폼은 클래식 플랫폼을 대체하는 것이 아니라 서로 다른 속성을 가지고 있으며 서로 다른 구현에 적합한다. 또한 전체 프레임워크에는 시스템 검증을 위한 승인 테스트와 정의된 도메인 간의 표준 어플리케이션 인터페이스가 포함되어 있어 소프트웨어 재사용 및 교환성이 향상된다(그림 7). 동일한 시스템 내의 ECU는 어느 플랫폼에서든 실행할 수 있으며, AUTOSAR 통신 기능이 제공하는 ECU 상호운용성을 계속 활용할 수 있다.
그림 7. AUTOSAR 표준. 출처: https://www.autosar.org/
AUTOSAR와 자율주행차AUTOSAR 클래식 플랫폼은 현재 시판 중인 많은 레벨 1 및 레벨 2 ADAS 시스템에서 사용되어 왔으며, 주로 ACC, AEB 및 LKA와 같은 단일 기능 ECU에 사용되었습니다. 이제 고성능 컴퓨팅 플랫폼에서 구현되는 소프트웨어 프로세싱을 통해 보다 진보된 ADAS 기능에 AUTOSAR Adaptive가 사용되기 시작했습니다.많은 OEM은 특히 CAN/Flexray/LIN/Ethernet을 통한 차량 통신 네트워크 관리를 위해 ECU에 AUTOSAR 사용을 의무화하고 있습니다. 이는 종종 OEM이 네트워크를 소유하고 관리해야 하는 필요성에 의해 주도됩니다. ECU 구성 및 메시지 카탈로그는 제어된 방식으로 수많은 티어 1에 공개될 수 있으며, 이를 위해 AUTOSAR ECU 구성 파일(ARXML)을 사용하는 것이 널리 퍼져 있습니다. 일부 ECU는 기능에 완전히 적합하지 않은 경우 이 요구 사항에서 제외될 수 있지만, 자율 주행 차량 시스템을 포함한 더 복잡한 차량 시스템으로 이동함에 따라 많은 OEM에서 AUTOSAR가 중요한 역할을 하게 될 것이 분명합니다. 레벨 3 자율주행 기능을 구현하는 시스템에는 여러 도메인에 걸쳐 여러 ECU가 포함되며, ECU 상호 운용성, 엔드 투 엔드(E2E) 기능 안전 메시징 프로토콜, 소프트웨어 이식성 및 기능 안전 기능을 통해 AUTOSAR 프레임워크 내에서 개발하는 것이 확실한 선택이 될 것입니다. 또한 전통적으로 기능 안전이 보장되지 않는 HMI 시스템의 전환을 용이하게 하여 이미 지원되는 AUTOSAR 기능을 확장함으로써 기능 안전 요구 사항을 충족하도록 제어 측면을 이전할 수 있으며, 이 모든 것은 시스템 내에서 일부 소프트웨어 계층만 제공한다는 점을 감안하면 AUTOSAR를 통해 가능합니다.
차량 네트워킹을 어느 정도 독점하고 있기는 하지만, 적응형 플랫폼은 복잡한 자율 기능을 구현하는 데 있어 주요 선택이 아닐 수 있으며 OpenCL, 로봇 운영 체제(ROS), Mobileye 등 독점 및 오픈 소스 소프트웨어 시스템이 많이 있습니다. 다행히도 개발자와 AUTOSAR는 통신 및 안전에 중요한 폴백을 위해 AUTOSAR 스택을 사용하고 다른 상위 시스템과의 연결을 위해 SOME/IP 및 DDS와 같은 미들웨어를 사용하여 두 가지 장점을 모두 갖춘 시스템을 구축할 수 있으며, 현재로서는 AUTOSAR가 AV/ADAS 및 차량 내 다른 많은 시스템을 위한 백본을 제공한다고 해도 과언이 아닙니다.
그러나 이는 다른 많은 소프트웨어 시스템을 포함하는 끊임없이 진화하는 에코시스템의 일부이며, 중앙 집중식 및 구역 기반 아키텍처에서 더 높은 수준의 자율성이 개발됨에 따라 AUTOSAR의 정확한 역할은 아직 결정되지 않았습니다.
저자 소개: Martin Howle은 SBD Automotive 에서 EE 아키텍처, 도메인 대표입니다.