AUTOSAR Adaptive - 차량용 컴퓨팅 센터

새로운 AUTOSAR Adaptive 소프트웨어 표준으로 차량에서 더 강력하고 유연한 E/E 아키텍처를 구현할 수 있다. 이제 Ethernet 기반 ECU를 AUTOSAR Adaptive 아키텍처의 중앙 애플리케이션 서버로 사용할 수 있다. Adaptive ECU 사용의 큰 장점은 차량 전체 라이프 사이클에서 애플리케이션을 업데이트할 수 있으며 추후 새로운 소프트웨어 기능을 추가할 수 있다는 것이다.


미래 세대의 자동차에서는 고도로 발전한 주행 기능이 네트워킹 아키텍처 및 각 ECU 간 상호작용에 엄청난 영향을 줄 것이다. 운전자보조시스템이 지속해서 고도의 자율주행 수준까지 성장하려면 레이더, 라이다 및 다양한 카메라로 구성된 첨단 센서가 필요하다. 이 센서들은 차량에 응집적 환경 모델을 제공한다. 응집적 환경 모델을 제공한다는 것은 차량 네트워크가 대량의 데이터를 단시간에 전송하고 처리해야 한다는 의미이다. 데이터 전송만 해도 저 지연으로 높은 데이터 전송률을 달성할 수 있는 네트워킹 아키텍처가 필요하다. 또한, 센서 데이터의 융합은 특수한 하드웨어를 활용하여 복합적인 알고리즘을 처리할 수 있는 고성능의 차내 컴퓨팅 시스템이 필요하다. 센서와 액추에이터를 비롯한 전체 프로세스 체인을 지연이 거의 없을 정도로 안전하게 차량에 통합해야 한다.

차량 아키텍처에 미치는 영향

IT 백엔드를 통해 사용할 수 있는 디지털 서비스는 차량 아키텍처에 큰 영향을 미친다. 고 대역폭 모바일 라디오 인터페이스 및 저지연 V2X(vehicle-to-x)는 날씨, 교통 흐름 및 공사 구간과 같은 환경조건 관련 정보를 제공한다. ECU는 경로 정보와 함께 이러한 데이터와 차량 센서에서 얻은 주변 환경에 대한 데이터를 종합한다. 차량의 컴퓨팅 시스템은 필요한 그래픽 집약적 작업을 실행하며 그 결과는 사용자가 구성 가능한 고해상도 디스플레이 또는 헤드업 디스플레이에 표시된다.
안전하고 복잡한 데이터 전송이 필요한 것은 외부의 이러한 무선 인터페이스뿐만이 아니다. 상대적으로 단순한 전기차조차도 전기료 과금을 위해 전기 충전소와 안전하게 연결할 수 있어야 한다. 이 안전한 충전 수단은 또한 차량 내 컴퓨팅 능력을 강화는 데도 필요하다.

이 모든 새로운 기능들은 차량 내에서 전자 시스템 및 소프트웨어가 차지하는 부가가치율을 2025년까지 무려 65%로 증가시킬 것이다. 이 중 소프트웨어 비중이 가장 많이 증가할 것이고 2025년이 되면 약 25%가 될 것이다.^[1] 복잡성이 증가함에 따라 ECU 개발 작업을 더 엄격하게 분할하는 경향이 두드러진다. 대체로 1차 공급업체가 ECU 하드웨어 개발을 수행하지만, 일반적으로 자동차 OEM이 훨씬 더 다양한 소프트웨어 소스를 보유하고 있다.
이처럼 다양한 소프트웨어 소스가 있는 것은 매우 중요한 경쟁요인이다. OEM은 내부에서 알고리즘을 개발하거나 특화된 (Third Party) 솔루션 공급업체로부터 소프트웨어 구성요소를 구입한다.

---

높은 수준의 요구사항을 충족하기 위한 새로운 시스템

자동차 OEM이나 최종 사용자는 차량 기능을 확장하는 등의 목적을 위해 소프트웨어 기능을 추가해야 하거나 ECU가 생산에 적용된 이후 등을 비롯해 추후에 소프트웨어 기능을 변경할 수 있어야 한다. 그러나 솔루션 공급업체로부터 소프트웨어를 소싱할 수 있는 가능성 때문에 새로운 시장 상황이 만들어진다. 이를 위해 필요한 동적 소프트웨어 통합 환경은 어떠한 경우에도 향후에 등장할 자동차 플랫폼의 필수적 속성이 된다. 미래에는 컴퓨팅 집약적 알고리즘 및 기능을 실행하기 위해 차량에 훨씬 더 강력한 ECU가 필요할 것이다. 이러한 ECU에는 64비트 멀티코어 프로세서와 MMU(Memory Management Unit)가 탑재될 것이다.

이러한 프로세서는 가상화 및 외부 메모리에 대한 고속 인터페이싱을 위한 추가적인 하드웨어 지원을 제공한다. 하드웨어 가속기 역할을 하면서 낮은 전력 손실로 필요한 처리 속도를 달성하는 시스템온칩(SoC)이 그래픽, 이미지 및 알고리즘 프로세싱을 수행한다. 또한, ECU에서는 무단 액세스를 방지하기 위해 하드웨어 보안 모듈(Hardware Security Module, HSM) 및 신뢰 플랫폼 모듈(Trusted Platform Module, TPM)과 같은 구성요소가, 안전 관련 기능을 구현하기 위해서는 추가 마이크로컨트롤러 또는 SoC가 사용된다.

차량 내부 네트워크와 차량 외부에 대한 인터페이싱은 계속해서 중요한 역할을 한다. IEEE 100BASE-T1(100Mbit/s) 또는 1000BASE-T1(1Gbit/s)로 구현되는 Ethernet이 백본 역할을 하여 네트워킹 구조를 지속적으로 변경하고 데이터 전송률을 배가시킨다. WiFi, Bluetooth, 5G 및 V2X와 같은 외부 통신 인터페이스로도 데이터 전송률을 높일 수 있다. 또한, 기가비트 대역의 전송 속도를 제공하는 저 전압 차동 신호 전송(LVDS) 또는 자동 픽셀 링크(APIX)를 통해 센서 및 액추에이터에 대한 인터페이스를 보는 것도 흔한 일이 될 것이다. 이전의 구형 버스 시스템은 계속해서 사용되겠지만 더 이상 전체 차량 통합에서 중심적 역할을 하지는 않을 것이다.

데이터 전송률이 높은 이 하드웨어를 효율적으로 사용하려면 유연한 소프트웨어 아키텍처가 필요하다. 일반적으로 POSIX 기반 운영체제는 복잡한 프로세서와 그 주변장치를 사용하기 위한 전제 조건이다. 그러한 운영체제에는 Linux가 포함되며, 안전 관련 시스템에는 PikeOS가 포함된다. 소프트웨어 기능을 효율적으로 개발하기 위해 다양한 종류의 라이브러리와 개발 프레임워크를 사용할 수 있다. 그래픽 및 인공지능 애플리케이션용 라이브러리는 특히나 주목할 만하다.

AUTOSAR Adaptive: 새로운 표준

이러한 새로운 요구사항을 충족하기 위해서 AUTOSAR 컨소시엄에서는 기존의 Classic Platform 이외에 또 다른 표준인 AUTOSAR Adaptive Platform을 정의했다. Classic Platform은 비용 최적화된 마이크로컨트롤러를 지원한다. 그럼에도, 비교적 덜 강력한 이 프로세서조차 Ethernet, 보안 및 기능적 안전성 영역에서 까다로운 애플리케이션 구현에 사용될 수 있다. 구형 플랫폼은 주로 센서와 액추에이터에 직접 액세스하고 엄격한 실시간 요구사항을 충족해야 하는 ECU를 구현하는 데 사용된다.

한편, Adaptive Platform은 고도 자율주행과 같은 탁월한 성능을 요구하는 애플리케이션 지원을 위해 고안됐다. Adaptive Platform은 업데이트 및 향상된 기능을 비롯한 특징들이 돋보이는 유연한 통합 환경을 제공한다. 분명히 Adaptive Platform은 엄격한 시간 요건도 충족해야 한다. 자주 발생하는 이벤트를 처리하는 데는 AUTOSAR Classic이 여전히 더 적합하다. 오늘날의 관점에서는 가장 엄격한 안전 요구사항을 충족시키려면 Classic ECU와 AUTOSAR Adaptive ECU가 결합되어야만 가능하다. 이는 AUTOSAR Adaptive 표준이 구성요소 및 운영체제 사용에 더 자유롭고 유연하기 때문이다. 여기서 주목할 것은‘POSIX-OS’이다. 현재 Adaptive Platform이 미래의 모든 사용 사례에서 기능적으로 안전한, 유일무이한 시스템으로 독점 사용될 것인지를 판단하기 위한 종합적인 연구가 행해지고 있다.

AUTOSAR Classic과 상호작용하는 Adaptive 표준은 이제 다양한 ECU를 지원하며 시스템 설계자들에게 고성능 차량 플랫폼 개발에 필요한 구성요소를 제공한다. 이전에는 그러한 ECU들이 사유적 접근방식으로 구현됐다. 그러나 AUTOSAR Adaptive를 구성하는 요소는 무엇일까? 두 플랫폼은 기술적으로 어떠한 차이가 있을까?(그림 1)
Adaptive Platform에서 애플리케이션은 ‘AUTOSAR Runtime for Adaptive Applications’, 즉 ARA를 사용한다. 이러한 런타임 환경은 사용자에게 여러 애플리케이션을 시스템에 효율적으로 통합하기 위한 표준화된 인터페이스를 제공한다. ARA는 ECU 내부 통신 및 네트워크 간의 통신을 위한 메커니즘을 제공할 뿐만 아니라 진단 및 네트워크 관리와 같은 기본적 서비스에 접근할 수 있도록 한다. 또한 애플리케이션 프로그래머는 ‘Minimum Real-Time System Profile: PSE51’로 알려진 하위 집합 운영체제 기능에 직접 액세스할 수 있다.

Adaptive 애플리케이션은 POSIX 기반의 운영체제에서 하나 이상의 프로세스로 구현된다. 런타임 시 애플리케이션 프로세스는 연관된 가상 주소 공간에 로드되고 같은 데서 실행된다. 애플리케이션 제어(실행관리) 모듈이 이러한 프로세스들의 시작을 조정하여 처리한다.
Adaptive 환경은 ECU를 E/E 아키텍처에 통합하는 데 필요한 진단 및 네트워크 관리와 같은 기본적 서비스를 계속해서 제공한다. 기본적 기능을 제공하는 다른 서비스로는 지속적 데이터 저장(지속성), 플랫폼의 기능적 모니터링(플랫폼 상태 관리), 암호 연산 액세스(암호화) 및 측정값의 기록(기록 및 추적)이 있다. 

또한 업데이트 및 구성 관리(UCM)는 Adaptive Platform의 중심 기능이다. Classic Platform은 일반적으로 업데이트 중에 전체 ECU 코드를 교체할 수 있지만, Adaptive Platform은 이제 개별 애플리케이션을 제거하거나 업데이트하거나 추가하는 옵션을 제공한다. 실행 프로그램과 매니페스트 파일로 구성된 패키지가 각 Adaptive 애플리케이션을 정의한다. 이에 따라 ECU 기능을 유연하게 처리할 수 있다. 매니페스트 파일은 서비스 지향 통신을 위한 포트 및 IP 주소와 같은 애플리케이션의 인터페이스를 모델링한다. 또한 애플리케이션을 실행하기 위한 호출 파라미터 등의 전제 조건을 설정한다.

AUTOSAR Classic과 달리 AUTOSAR Adaptive에서는 C++ 프로그래밍 언어를 사용한다. 애플리케이션 프로그래머는 객체지향 프로그래밍 언어, 동적 메모리 관리 및 기존 표준 라이브러리의 조합으로 까다롭고 재사용 가능한 소프트웨어를 효율적으로 구현할 수 있다. Adaptive Platform의 또 다른 특성은 시스템 설계의 유연성을 높여주는, 전적으로 서비스 지향 아키텍처 패러다임으로 전환한다는 것이다. 애플리케이션은 Adaptive 플랫폼을 통해 기능을 하나의 서비스로 제공하고, 제공되는 서비스를 사용할 수 있다(그림 2).
Adaptive Platform이 실행되는 ECU는 Ethernet 네트워크를 통해 상호 연결된다. 클라이언트는 서버가 미리 제공한 서비스를 요청한다. 이 정보는 네트워크 프로토콜 SOME/IP(Scalable Service Oriented Middleware over IP)를 통해 Ethernet으로 전송된다. 서버는 적합한 데이터로 요청에 응답한다. 또한 SOME/IP가 이 데이터의 직렬화를 정의한다. 이와 비교하여 Classic Platform은 신호 지향적 통신에 주로 초점을 맞춘다. 그런데도 AUTOSAR Classic을 여러 ECU 간의 통신에 서비스 기반 방식으로 사용할 수 있다. Adaptive Platform과 마찬가지로 Classic Platform에도 Ethernet 연결과 SOME/IP가 사용된다.

실제로 AUTOSAR Adaptive Platform과 AUTOSAR Classic Platform의 주요 특성은 상호 보완적이다. 따라서 두 표준 모두에 기반한 ECU가 미래 세대의 자동차에서 사용되어 동질적 아키텍처를 생성할 것이라고 가정할 수 있다. 익숙한 Classic 구현 솔루션 이외에도 Vector의 Adaptive MICROSAR와 같은 Adaptive Platform 솔루션이 이미 판매되고 있다.

도메인 컨트롤러와 게이트웨이

일부 최신 차량에는 차량 기능을 그 논리적 할당에 따라 인포테인먼트, 바디 컨트롤러 및 드라이브트레인과 같은 도메인으로 그룹화하는 도메인 중심적 E/E 아키텍처가 적용되어 있다. 각 도메인은 자체 도메인 컨트롤러를 갖추고 있다. 이러한 도메인 컨트롤러는 Ethernet을 통해 상호 연결되며, 센서와 액추에이터를 사용할 수 있도록 하는 다른 ECU들이 각각의 도메인 컨트롤러에 지정되어 이 컨트롤러로 조정된다. CAN 또는 LIN과 같은 차량 버스는 특정 도메인 컨트롤러에 연결된다.

‘Connectivity Unit’이라고 부르는 다른 컨트롤러는 오프보드 진단, Bluetooth 및 모바일 라디오를 통해 외부와 연결된다.
AUTOSAR Adaptive를 사용한다고 해서 근본적 차량 아키텍처가 갑자기 변경되는 것은 아니다(그림 3). 가장 두드러지는 변경 사항은 차량에서 Ethernet을 보편적으로 사용한다는 것과 스위치를 관련 용도로 사용하는 것이다. 각 스위치는 ECU 간의 충돌방지 점대점 연결을 생성한다. 이러한 스위치는 와이어링 하네스를 최적화하기 위해서 통합되며 별도의 ECU로 구현되지 않는다.
또한, 서로 다른 여러 고성능 인터페이스를 통해서 레이더/라이다 센서, 카메라, 디스플레이 및 기타 ECU에 연결하는 다양한 고성능 컴퓨터가 있을 것이다. 무엇보다도, 센서 및 액추에이터 수준에서 액세스하도록 하는 ECU와 높은 빈도로 발생하며 시간 결정적인 데이터를 전송하는 구형 버스 시스템 간의 게이트웨이가 포함된다. 한편, AUTOSAR Adaptive 소프트웨어를 탑재한 고성능 컴퓨터는 차량 네트워크에서 통신 작업 및 컴퓨팅 집약적 작업을 처리한다.

그러한 시나리오에서는 Adaptive ECU와 Classic ECU가 서로 어떻게 통신할 것인가 하는 문제가 나타난다. 가장 단순한 경우, Ethernet을 통해 상호 연결된 ECU들은 SOME/IP를 통해 서비스 지향 통신을 사용한다(그림 4). 이 예에서 AUTOSAR Classic ECU1은 다른 ECU들이 연결된 여러 버스 시스템에 연결되어 있다. ECU1은 이 구성에서 게이트웨이로 작동하고 버스 측의 메시지 신호를 하나의 서비스로 ‘패킹’하여 AUTOSAR Adaptive Platform이 메시지 신호를 즉시 수신할 수 있도록 한다.
통신 레이아웃은 Classic Platform이나 Adaptive Platform 모두에서 AUTOSAR ECU 설계의 고정적 구성요소이다. 두 플랫폼의 구성 형식이 다르기 때문에 서비스 구성을 변환 형식으로 매핑해야 한다. 전적으로 신호에 의해 작동되는 AUTOSAR Classic ECU와 통신하는 경우 상황은 약간 더 다면적이다(그림 5).
이 시나리오에서 ECU1은 신호 게이트웨이로 지정되어 있고 Ethernet을 통해 직접 UDP 프레임으로 메시지 신호를 변환한다. AUTOSAR Adaptive ECU가 이제 UDP 프레임의 신호를 신호-서비스 간 매핑을 통해 ECU2 내에서 사용 가능한 서비스로 변환한다. 통신 매트릭스를 통한 신호 설명 이외에도 이 방식으로 구현하려면 AUTOSAR Classic 구성의 한 구성요소로 서비스에 대한 매핑 규칙이 필요하다. 이러한 매핑 규칙은 이미 AUTOSAR Adaptive 규격의 일부로 표준화되어 있다. 서비스-신호 간 매핑은 이러한 규칙에 기반하여 코딩되고 ECU에서 독립적 서비스로 실행된다.

소프트웨어 복잡성 마스터링

차량의 자동화 및 확장 통신으로 패러다임을 전환하려면 대량의 데이터를 처리 및 전송하고 이로 인한 소프트웨어 복잡성을 숙달해야 한다. 현재의 시스템은 이러한 엄격한 요구사항을 거의 충족하지 않는다. 이러한 이유로 강력한 중앙 컴퓨터를 갖추고 Ethernet 기반 및 서비스 지향 통신을 지원하는 AUTOSAR Adaptive Platform이 미래의 차량 아키텍처를 위한 최적의 토대를 제공할 수 있는 것이다. 여기에서는 AUTOSAR Adaptive ECU와 AUTOSAR Classic ECU를 함께 사용할 수 있다. 유연한 게이트웨이 시나리오로 이 두 가지를 손쉽게 상호 연결할 수 있는 것이다.
 

---

마코 티셔 (Mirko Tischer) 박사
1997년부터 벡터에서 제품 개발 및 제품 관리를 담당해왔고 2018년부터 AUTOSAR 베이직 소프트웨어 Adaptive MICROSAR의 Product Manager로 근무하고 있다.






 

---

AEM_Automotive Electronics Magazine