Ampere의 클라우드 네이티브 플랫폼을 활용하면 소프트웨어 정의 자동차를 지원하는 클라우드 기반 워크로드에 필요한 규모를 제공하는 동시에 ‘패리티’와 관련된 문제를 해결할 수 있다. 이 두 가지 이점을 통해 소프트웨어 정의 자동차의 개발 속도, 품질 및 효율성은 레거시 x86 플랫폼에서 가능했던 것보다 훨씬 뛰어나게 된다. 

글 | 조 스피드(Joe Speed), Head of Edge, Ampere

  In English  : Achieving “Native Parity” with Ampere® for Better, Faster Software-Defined Vehicle Development (autoelectronics.co.kr)






자동차 산업이 전기화, 자율주행 및 소프트웨어 정의 자동차로 이동함에 따라 자동차에 사용되는 컴퓨터 아키텍처는 전환에 맞춰 변화하고 있습니다. 이런 변화의 일환으로 자동차는 멀티코어 Arm64 컴퓨터로 이동하고 있습니다. 하지만 오늘날 이런 차량을 지원하는 대부분 소프트웨어가 여전히 레거시 x86 아키텍처에서 개발되고 있습니다.

그러니까, 소프트웨어 개발이 차량을 실행하는 동일한 컴퓨터 아키텍처에서 되고 있지 않기 때문에 여러 가지 문제가 있는 것입니다. 아키텍처 간 마이그레이션은 시간과 비용이 들며 부정확할 가능성이 더 커집니다.

따라서 미래의 자동차가 실현에 가까워짐에 따라 업계의 소프트웨어 개발 전략과 테스트 환경도 Arm64 컴퓨터에서 이뤄지도록 전환해야 합니다. 이를 통해 자동차와 ‘네이티브 패리티(native parity)’를 달성해, 소프트웨어 개발을 더 빠르고 쉽게 하고 오류 발생 가능성을 줄일 수 있습니다. 

하지만 네이티브 패리티만으로는 충분하지 않습니다. 고성능 클라우드 워크로드는 소프트웨어 정의 자동차의 근간입니다. 따라서 네이티브 패리티가 필수적인 첫 번째 단계인 반면, 이를 실현하는 하드웨어는 고성능과 용량에 필요한 확장성을 제공하는 ‘클라우드 네이티브(cloud native)’여야 합니다.


네이티브 패리티에 대한 
Ampere Cloud Native의 이점 

Ampere는 최대 128개 코어가 있고, 많은 클라우드 프로바이더와 서버 OEM에서 사용하는 Cloud Native 프로세서를 통해 이런 문제들을 모두 해결합니다. Arm ISA를 활용하는 이 Ampere® Altra® 제품군의 프로세서는 차량에 사용되는 ECU(Electronic Control Units)로 알려진 멀티코어 Arm 임베디드 시스템과 환경 패리티(environmental parity)를 제공하지만, 훨씬 더 큰 규모(서버당 최대 1,024개 코어) 및 와트당 성능 기준으로 x86 프로세서보다 더 나은 에너지 효율성을 제공합니다. 차량의 ECU와 함께 Ampere 프로세서를 사용해 완벽한 엔드 투 엔드 환경을 구축하면 네이티브 패리티와 클라우드 네이티브 아키텍처를 모두 제공할 수 있습니다.







네이티브 패리티가 테스트 품질과 속도를 어떻게 향상시킬 수 있는지를 정량화하기 위해 Ampere의 엔지니어는 Cortex A-72 Arm64 프로세서를 사용해 에뮬레이트된 차량 ECU에서 예제 테스트 워크로드의 성능을 벤치마킹했습니다. 심지어 Ampere Altra Max의 QEMU 에뮬레이터 내에서 실행하는 것만으로도 x86에서 실행할 때보다 속도가 2.6배 향상됐습니다.

게다가, 에뮬레이션을 사용하는 대신 QEMU KVM 반가상화 및 docker OCI 컨테이너가 있는 가상머신에서 동일한 CI(continuous integration) 테스트 워크로드를 실행하면, x86에서 arm64 QEMU 에뮬레이터를 실행하는 것과 비교해 Ampere Altra Max에서 시간당 100배 더 많은 CI 테스트를 수행하고, 에너지 소비가 감소해 차량 소프트웨어 테스트의 탄소 발자국을 줄이기 위한 노력을 지원할 수 있습니다. 








CI 테스트에서 이런 향상은 개발자의 생산성에 큰 영향을 미칩니다. 테스트 실행 속도가 빨라지면 더 많은 테스트 반복이 가능합니다. 보다 정확한 플랫폼을 사용하면 테스트 품질이 향상됩니다. 네이티브 툴 체인을 활용하면 가장 발전되고 자주 업데이트되는 툴 사용을 보장합니다. 그리고 크로스 컴파일(cross-compilation)과 그 비효율성을 제거하면 탄소발자국이 줄어듭니다.


Apex.AI의 실제 결과

이것이 어떻게 구현될 수 있는지를 보여주는 대표적인 예가 Ampere 고객인 Apex.AI입니다. 그들은 다임러 트럭, AGCO, 콘티넨탈, ZF 등의 투자사와 함께 카 메이커를 위한 안전하고 인증된, 개발자 친화적이며 확장 가능한 소프트웨어를 개발합니다. Apex.AI는 자동차 산업이 소프트웨어 정의 자동차로 이동함에 따라 소프트웨어와 플랫폼의 복잡성이 증가할 것으로 보고 있습니다. 워크스트림 간 이기종 플랫폼을 사용하면 서로 다른 애플리케이션 도메인, 서로 다른 RTOS, 서로 다른 테스트 전략 및 지속적인 요구사항 변경을 관리해야 하기 때문에 훨씬 더 많은 문제가 발생합니다. 이런 복잡성으로 인해 개발 프로세스가 느려지고 검증이 지연되며, 문제를 해결하기에는 너무 늦은 최종 통합 시에 문제를 발견할 위험이 증가합니다. Ampere Cloud Native Processor와 함께 네이티브 패리티로의 이동은 자동차 소프트웨어 품질 및 지연 이슈에 대한 이런 문제들을 해결하는 데 도움이 됩니다.

지난 1년 동안 Apex.AI는 기능안전성을 확보한 ISO 26262 ASIL D 제품을 생산하는 DevOps 환경에서 엔드 투 엔드 네이티브 패리티를 도입했습니다. 그들의 CI/CD 서버는 클라우드의 Arm64 기반 프로세서에서 실행되고, 가상화된 차량 ECU의 CI 테스트는 Ampere® Altra® 서버에서 실행되며, 검증 테스트는 오토모티브 Arm64 ECU 팜에서 실행됩니다. Apex.AI의 개발 프로세스는 Arm 기반 MacBook Pro 노트북과 Ampere Altra Developer Platform 워크스테이션을 사용하는 개발자를 모두 지원합니다. 각각의 작업에 대해 네이티브 패리티가 설정됐습니다.








Ampere Altra를 사용해 네이티브 패리티를 달성하는 이점 중 하나는 소프트웨어 빌드 속도와 에너지 효율성이 향상된다는 것입니다. 앞서 본 것처럼, Ampere의 Cloud Native Processor는 빠른 컴파일 시간을 제공하며 확장 가능한 워크로드용으로 설계됐습니다. 컴파일 외에도 코드 작성에는 링크가 필요하며 LVVM 컴파일러에서 사용하는 링커인 LLD 작성자가 개발한 ‘mold’란 툴 덕분에 이 단계에서도 Ampere의 128코어 Cloud Native Processor를 활용할 수 있습니다. Mold는 GCC 12에 내장돼 있고 다른 개발 툴과 작동하는 고도로 병렬화된 링커입니다. 최종 결과는 Ampere에서 최적화된 빌드 환경입니다.

워크스트림의 다른 부분과 마찬가지로 CI 테스트는 x86 플랫폼에 필요한 에뮬레이션을 제거하기 때문에 Ampere 프로세서에서 더 빠르게 실행됩니다. ECU 및 R&D 차량에 대한 완전 자동화된 빌드-배포 테스트를 통해 Apex.AI는 이제 클라우드에서 수만 개의 소프트웨어 테스트를 실행하고 가상 및 물리적 차량 ECU의 온-프레미스 테스트를 실행하고 있습니다. Ampere Altra에서 수많은 가상 ECU를 실행함으로써 Apex.AI는 많은 유닛 테스트를 병렬로 실행할 수 있고 목표 테스트는 훨씬 더 간단합니다.

속도 외에도, Ampere와 네이티브 패리티의 또 다른 이점은 차량 ECU와 매우 유사한 테스트 아키텍처를 사용해 Apex.AI의 CI 테스트 정확도가 향상된 것입니다. QEMU는 하드웨어 플랫폼 에뮬레이션 및 가상화를 위해 널리 사용되는 오픈소스 소프트웨어 툴입니다. 이것은 Apex.AI 및 자동차 산업의 여러 곳에서 물리적인 오토모티브 ECU 팜으로는 불가능한 속도와 규모의 소프트웨어 테스트를 가능하게 하는 데 사용됩니다. 많은 수의 가상 ECU를 생성함으로써, QEMU는 Apex.AI가 개발 프로세스가 끝날 때까지 이런 테스트를 하나의 ‘빅뱅’으로 미루는 대신 조기에 테스트하고 더 자주 테스트할 수 있도록 합니다. x86 프로세서에서 에뮬레이션을 통한 테스트는 아키텍처의 차이로 인해 이슈들을 놓칠 수 있습니다. Apex.AI는 Ampere Altra 프로세서에서 가상 ECU를 사용해 대규모 테스트를 구현함으로써 대부분의 소프트웨어 품질 문제가 프로세스 초기에 발견되고 수정된다는 사실을 발견했습니다.

이런 강력한 이점으로 인해 Apex.AI는 플랫폼 간 실행에서 Ampere 프로세서를 사용해 네이티브 패리티 실행으로 기본 접근 방식을 변경했습니다. 또, 사용 편의성이 향상됐다는 추가적인 이점을 얻었습니다. 예를 들어, 기본적으로 실행하면 sysroot를 사용해 크로스 컴파일하고 no-native 툴 체인에 새로운 요소를 도입해야 하는 복잡성이 제거됩니다. 패키지 추가 시간이 단축되고 종속성이 더 명확해지며 자동화가 더 간단해집니다. 또한, 크로스 플랫폼 디버깅의 필요성도 없어집니다. 이것은 호스트와 대상 모두에서 고유하게 컴파일된 바이너리를 테스트하기가 훨씬 쉽게 하기 때문에 주요 개선 사항입니다. GNU 디버거에 대한 환경 설정도 훨씬 쉽고 CI 파이프라인이 간소화됩니다.

Apex.AI 엔지니어링 매니저인 아눕 페마이아(Anup Pemmaiah)에 따르면, 이 접근 방식은 소프트웨어 정의 자동차 솔루션의 일부로 많은 타깃 차량 플랫폼에서 Apex.AI 소프트웨어의 개발 및 배포를 간소화했습니다. Apex.AI의 Platform Automation Tool(PAT)과 같은 자동차 개발 툴은 원하는 워크플로를 달성하는 데 중요한 역할을 합니다. Apex.AI 기술책임자인 아눕 파텔(Anup Patel)은 “플랫폼 조정을 단순화하고 ‘빅뱅’의 늦은 통합을 방지한라”고 말합니다.


‘네이티브 패리티’로 전환하는 방법

어떻게 하면 네이티브 패리티로의 전환을 시작하고 클라우드 네이티브 아키텍처를 활용할 수 있을까요? 기존 툴 체인의 레거시 x86 소프트웨어 툴에서 전환할 시간을 제공하는 동안 CI/CD 파이프라인의 핵심이 네이티브 패리티를 갖도록 멀티 아키텍처 쿠버네이트(Kubernete)를 활용하는 것부터 시작하세요. 

Apex.OS 및 Apex.Middleware와 같은 네이티브 패리티를 이미 지원하는 오토모티브 소프트웨어 제품을 사용하면 Ampere Altra Developer Platform 워크스테이션을 사용하는 개발자가 네이티브 패리티 엔드 투 엔드로 개발에서 차량 테스트까지 이동할 수 있습니다. Ampere 솔루션은 HPE와 Gigabyte와 같은 많은 서버 벤더로부터 Azure, Google, Oracle, Tencent, Equinix와 같은 클라우드업체에서 제공하고 있습니다.

사진은 개발자 플랫폼 워크스테이션, 빌드 서버, 단일 서버의 전체 DevOps 팜, MLOps(머신 러닝 운영) 및 시뮬레이션 워크로드를 모두 실행할 수 있는 단일 서버와 같은 네이티브 패리티용 Ampere 기반 시스템의 몇 가지 예입니다.







Ampere의 클라우드 네이티브 플랫폼과 함께 지금 시작하면 소프트웨어 정의 자동차를 지원하는 클라우드 기반 워크로드에 필요한 규모를 제공하는 동시에 패리티와 관련된 문제를 해결할 수 있습니다. 이 두 가지 이점을 통해 소프트웨어 정의 자동차의 개발 속도, 품질 및 효율성은 레거시 x86 플랫폼에서 가능했던 것보다 훨씬 뛰어나게 됩니다.

AEM_Automotive Electronics Magazine