자동차 개발 협업, AWS 기반 상호 연결된 가상 임베디드 개발 환경으로 혁신을 가속하다

이 글은 AWS for Industries 블로그에 게시된 글 (Accelerate Automotive Collaboration using Interconnected Virtual Embedded Development Targets on AWS)를 한국어로 번역 및 편집하였습니다.

최신 차량 개발에는 자동차 OEM(완성차 제조사)과 여러 단계 공급망 네트워크(Tier-1, Tier-2 등) 간의 긴밀한 협력이 필요합니다. 통합 단계에서는 OEM과 공급망 계층은 모든 부품이 서로 잘 맞고 OEM의 요구사항을 충족하는지 검증합니다. 이 단계는 주로 차량 개발 수명 주기의 후반에 수행되며, 하드웨어와 소프트웨어 개발 주기에 대한 의존성, 결함의 늦은 발견, 비용 초과 등의 문제로 어려움을 겪습니다. 이는 결국 OEM 차량의 양산(SOP, Start of Production) 지연으로 이어집니다.

이 블로그에서는 AWS Marketplace를 통해 제공되는, 서로 다른 AWS 파트너사와 고객이 Amazon Machine Image(AMI) 형태로 제공하는 두 가지 가상 컴포넌트를 활용한 아키텍처를 소개합니다. 여기에 포함된 컴포넌트는 Panasonic Automotive vSkipGen™과 ETAS RTA-VRTE StarterKit입니다. 이 아키텍처의 첫 번째 이점은 OEM이 클라우드에서 가상 컴포넌트를 통합할 때 소프트웨어, 통신 및 컴포넌트 인터페이스와 관련된 문제를 차량 소프트웨어 개발 수명 주기 초기에 발견하고 수정할 수 있다는 점입니다. 이를 통해 나중에 발생할 수 있는 고비용의 큰 재작업을 피할 수 있습니다. 둘째, 공급업체는 각자의 지적 재산(IP)을 공개하지 않고도 지속적 통합(Continuous Integration, CI)과 지속적 테스트(Continuous Testing, CT)를 수행할 수 있으며, 이를 통해 소스 코드나 데이터를 노출하지 않고도 검증 및 확인(Verification and Validation) 단계의 자동화를 실현할 수 있습니다. 셋째, AWS의 종량제(pay-as-you-go) 모델은 가상화된 하드웨어에 대한 온디맨드 프로비저닝(on-demand provisioning)을 제공함으로써, 고객이 고가의 하드웨어 타깃(초기 하드웨어 샘플)에 대한 초기 자본 지출을 줄일 수 있도록 지원합니다. 궁극적으로 컴포넌트의 가상화와 이러한 안전한 상호 연결은 협업을 개선하고 차량(소프트웨어) 개발을 가속화하는 데 기여합니다.

일반적인 차량 프로젝트 설정

OEM은 파워트레인, 섀시, 인테리어, 인포테인먼트 및 관련 전기·전자(electrical and electronic, E/E) 부품을 포함한 주요 시스템을 공급하는 여러 1차 공급업체(Tier-1)와 긴밀히 협력합니다. OEM은 설계 과정에서 두 자릿수 규모의 1차 공급업체와 함께 일하며, 1차 공급업체는 다시 또 다른 두 자릿수 규모의 하위 공급업체를 관리하여 하위 컴포넌트를 공급받습니다. 이러한 다층 공급망은 OEM이 차량 통합과 브랜드 아이덴티티에 집중하면서, 전문화된 공급업체의 역량을 활용해 비용을 절감할 수 있게 합니다. 동시에 공급업체들은 자신들의 범위 내 업무를 책임지고 수행합니다. 따라서 공급업체 계층 간 긴밀한 조율은 성공적인 차량 프로그램에 필수적입니다.

그러나 OEM과 1차 공급업체는 자체적인 소프트웨어 전문성을 보유하고 있으며, 자동차 표준 규격에 맞춰 작성되지 않은 소프트웨어 인터페이스를 관리합니다. 2차 및 3차 공급업체는 자신의 소프트웨어 컴포넌트를 1차 공급업체의 ECU(전자제어장치)의 하드웨어 및 소프트웨어와 원활하게 통합해야 합니다. 그 결과, 공급업체 간 비호환성으로 인해 소프트웨어 통합이 실패할 위험이 존재합니다.

차량 출시가 다가오면, 1차 공급업체는 OEM 통합 테스트를 위해 프로토타입을 제공합니다. 이를 통해 설계 변경이 필요한 문제들을 식별합니다. OEM 요구사항 변경은 공급망 하위 단계까지 다시 전달되어, Tier-N 공급업체들이 소프트웨어를 업데이트·통합·검증하는 데 긴 작업 주기를 발생시킵니다. 이는 늦은 통합, 의사소통 부족, 불완전한 요구사항, 비호환 솔루션 및 인터페이스로 인해 많은 실패를 초래하며, OEM 차량 SOP(start of production, 양산 개시)가 지연되는 원인이 됩니다.

가상화를 활용한 소프트웨어 우선 접근(software-first)과 개발 주기 단축(shift-left)

가상 임베디드 개발 타깃(virtual embedded development target, vEDT)은 물리적 ECU, 코크핏 도메인 컨트롤러(cockpit domain controller, CDC), 존 컴퓨트 유닛(zonal compute unit, ZCU), 고성능 컴퓨트 노드(HPC)의 기능을 그대로 재현하도록 설계되었습니다. 가상화는 OEM과 공급업체가 하드웨어와 소프트웨어 개발 주기를 분리하고, 물리적 타깃 하드웨어가 준비되기 전이라도 차량 개발 주기 초기에 소프트웨어 개발과 통합 테스트를 시작할 수 있도록 합니다(일명 “shift-left”).

OEM과 공급업체의 vEDT는 AWS 네트워크 위에서 자동차 프로토콜을 사용해 안전하게 연결·통신하며, 물리적 EDT 간 차량 내 통신을 가상화합니다. 이를 통해 클라우드 내에 가상 전기·전자 아키텍처(virtual Electrical/Electronic architecture, vEE) 또는 가상 차량 (서브)시스템이 구축됩니다. vEDT와 vEE를 활용하면 OEM과 공급업체는 더 이른 시점에 통합 및 테스트를 수행하여 공급업체 간 인터페이스 비호환성과 소프트웨어 문제를 조기에 식별·완화할 수 있습니다.

또한 vEDT는 자동차 소프트웨어 개발에서 혁신의 장벽을 낮추며, 온디맨드 프로비저닝과 종량제(pay-as-you-go) 모델을 도입합니다. 또한 ARM aarch64 명령어 집합 아키텍처(Instruction Set Architecture, ISA) 를 기반으로 하는 vEDT는 QEMU와 같은 시뮬레이터의 낮은 효율의 명령어 변환 방식과 달리, AWS Graviton 프로세서에서 비트 단위 동등성(bit-parity) 으로 실행됩니다.

아키텍처 개요

이 아키텍처는 OEM이 vEDT와 AWS 서비스를 활용해 자사 개발자와 두 개의 공급업체 — 이번 사례에서는 ETAS와 Panasonic Automotive(PASA) — 간의 보다 원활한 협업을 가능하게 할 수 있는 잠재력을 보여줍니다. 이는 그림 1의 아키텍처에 표시된 세 개의 AWS 계정으로 반영되어 있습니다.

이 경우, vEDT는 Amazon Virtual Private Cloud(VPC) 내부의 Amazon Elastic Compute Cloud(EC2) 인스턴스에서 안전하게 실행됩니다. 각 공급업체의 VPC 내에서 실행되는 다수의 vEDT는 AWS Transit Gateway를 사용해 상호 연결되어 가상의 차량 E/E 아키텍처를 형성합니다.

우리는 물리적 타깃을 vEDT로 격리된 환경에서 복제함으로써, 코크핏(cockpit) 애플리케이션 개발자와 AUTOSAR Adaptive 애플리케이션 개발자가 각각의 소스 코드와 데이터를 공유하지 않고도 소프트웨어를 개발, 통합, 테스트할 수 있음을 보여줍니다. 아키텍처의 각 부분은 [1]에서 [8]까지 번호가 매겨져 있으며, 이후 설명에서 이 번호로 참조됩니다.

그림 1: 기술 아키텍처 개요

OEM 환경

OEM 계정에는 두 가지 가상 개발 환경이 있습니다. 첫 번째 [1]는 AUTOSAR Adaptive 애플리케이션 설계 및 AUTOSAR 매니페스트 구성을 위한 도구인 ETAS ISOLAR-VRTE를 제공합니다. 또한 Microsoft의 원격 데스크톱 프로토콜(RDP)의 오픈소스 구현인 XRDP 서버가 포함되어 있어 AUTOSAR Adaptive 개발자가 그래픽 방식으로 환경에 접속할 수 있습니다. 이 스택은 AWS Marketplace에서 AMI 형태로 제공되며, 지원되는 Amazon EC2 인스턴스에 원클릭 배포가 가능합니다. 두 번째 [2]는 Rightware에서 제공하는 Kanzi Studio로, 계기판, 헤드업 디스플레이, 인포테인먼트 시스템의 사용자 인터페이스를 설계할 수 있습니다. 이 AMI는 또한 Amazon EC2 인스턴스에서 보안 원격 데스크톱 경험을 제공하기 위해 설계된 고성능 원격 디스플레이 프로토콜인 NICE DCV를 포함하고 있으며, 데스크톱 클라이언트 또는 브라우저를 통해 직접 접속할 수 있습니다.

개발자가 최신 변경 사항에 만족하면 각 개발자는 자신의 vEDT에서 SSH를 통해 코드를 즉시 빌드, 푸시, 테스트할 수 있습니다.

• AUTOSAR Adaptive 개발자는 t4g EC2 인스턴스 [3] (AWS Graviton 2 프로세서, ARM v8)에서 실행합니다.
• HMI 개발자의 경우, g5g.metal Amazon EC2 인스턴스 [4] (NVIDIA T4G Tensor Core GPUs 및 AWS Graviton 2 프로세서)에서 Panasonic Automotive vSkipGen™ AMI를 활용하여 작업하며, 이는 AWS Marketplace에서 제공됩니다.

OEM과 공급업체 간 협업

아키텍처(그림 1)에 표시된 것처럼, 두 vEDT는 각각 ETAS와 Panasonic Automotive(PASA)의 별도 AWS 계정에서 실행됩니다. AWS 계정 간 보안 통신은 AWS Transit Gateway(TGW)와 AWS Resource Access Manager(RAM)를 통해 가능합니다. 이 설정의 또 다른 장점은 계정 간 통신뿐만 아니라 리전 간 통신도 허용한다는 점입니다. 즉, OEM 관점에서 미국의 개발팀이 독일의 ETAS 및 일본의 PASA와 협업할 수 있는 것입니다. 아래는 OEM AWS 계정과 공급업체 계정(예: ETAS AWS 계정) 간 이러한 설정을 가능하게 하는 단계 예시입니다:

1. VPC는 CIDR이 겹치지 않아야 합니다.
2. OEM 계정에서 멀티캐스트 지원이 활성화된 TGW [5]를 생성합니다. 이후 단계에서 사용되며, 다른 매개변수는 기본값으로 두어도 됩니다.
3. OEM 계정에서 공유된 TGW를 가상 개발 환경이 실행 중인 VPC에 연결하는 TGW attachment [6]를 생성합니다.
4. TGW attachment 생성 과정에서, 가상 개발 환경이 포함된 서브넷과 동일한 가용 영역(AZ)에 위치한 서브넷을 선택합니다. 가상 개발 환경이 포함된 서브넷 자체를 선택해도 됩니다.
5. OEM 계정에서 RAM을 사용해 TGW를 ETAS 계정과 공유합니다.
6. ETAS 계정에서 RAM을 사용해 TGW 공유를 수락합니다.
7. ETAS 계정에서 공유된 TGW를 vEDT가 실행되는 VPC에 연결하는 TGW attachment [7]를 생성합니다.
8. 생성 과정에서 vEDT가 포함된 서브넷과 동일한 AZ에 위치한 서브넷을 선택해 TGW VPC attachment를 만듭니다.
9. OEM 계정에서 Transit Gateway attachments로 이동하여 TGW attachment를 수락합니다.
10. OEM 계정에서 가상 개발 환경이 포함된 프라이빗 서브넷의 라우팅 테이블을 업데이트합니다. 예: Destination = [ETAS 계정 VPC CIDR], Target = [TGW Attachment].
11. ETAS 계정에서 vEDT가 포함된 프라이빗 서브넷의 라우팅 테이블을 업데이트합니다. 예: Destination = [OEM 계정 VPC CIDR], Target = [TGW Attachment].
12. ETAS 계정에서 vEDT의 보안 그룹을 업데이트하고, Inbound 규칙에 Source = [OEM 계정 VPC CIDR]에서 SSH 트래픽을 허용하는 항목을 추가합니다.

아키텍처에 표시된 3자 협업 구성을 달성하려면, 4~11단계를 반복하되 ETAS AWS 계정 정보를 두 번째 공급업체(PASA 계정) 정보로 교체하면 됩니다.

공급업체 간 협업

AWS Transit Gateway와 AWS Resource Access Manager의 조합은 OEM이 관리·제어하는 상태에서 두 공급업체 계정 간의 통신도 가능하게 합니다. 이 아키텍처에서 vEDT는 차량 내 물리적 임베디드 타깃이 사용하는 통신 프로토콜인 SOME/IP를 통해 통신해야 합니다. SOME/IP는 서비스 검색을 위해 멀티캐스트에 의존하므로, 기존 TGW를 활용해 계정 간(및 리전 간) 멀티캐스트와 IGMP(Internet Group Management Protocol) 지원을 기본적으로 활성화할 수 있습니다. 다음은 세 개 계정 간 이러한 구성을 활성화하는 상세 단계이며, 앞 절과 동일한 네이밍 규칙을 사용합니다:

1. OEM 계정에서 TGW 멀티캐스트 도메인 생성:
   • OEM 계정의 TGW 지정.
   • IGMPv2 지원 활성화. IGMPv2는 멀티캐스트 도메인의 동적 멤버십 관리를 가능하게 하며, VPC 내 연결된 서브넷의 호스트가 IGMPv2 프로토콜 메시지를 통해 필요 시 멀티캐스트 그룹에 가입하거나 탈퇴할 수 있게 합니다.
2. OEM 계정에서 RAM을 사용해 TGW 멀티캐스트 도메인을 ETAS 및 PASA 계정과 공유.
3. ETAS 및 PASA 계정에서 RAM을 사용해 TGW 멀티캐스트 도메인 공유 수락.
4. ETAS 및 PASA 계정에서 멀티캐스트 도메인에 연결 생성 [8]:
   • 이전 절 6단계에서 생성한 TGW Attachment 선택.
   • vEDT가 실행 중인 서브넷 선택.
5. OEM 계정에서 TGW 멀티캐스트 도메인으로 이동, 멀티캐스트 도메인을 선택한 후 ETAS 및 PASA 계정의 attachment와의 연결을 수락.
6. ETAS 및 PASA 계정에서 TGW 멀티캐스트 도메인으로 이동 → Groups 탭 선택 → Create group 클릭.
   • CIDR 범위 224.0.0.0/4 내 그룹 IP 주소 입력(예: 224.0.0.16).
   • vEDT의 ENI(Elastic Network Interface) 선택.
   • Add group members 클릭으로 완료.
7. ETAS 및 PASA 계정에서 vEDT의 보안 그룹 업데이트:
   Inbound 규칙에 Source = 0.0.0.0/32에서 Custom Protocol Type 2(IGMP) 허용 추가 (IGMP 쿼리 허용).
   추가로:
   • ETAS 계정: Source = [PASA VPC CIDR]에서 모든 UDP 트래픽 허용.
   • PASA 계정: Source = [ETAS VPC CIDR]에서 모든 UDP 트래픽 허용.
   • 아웃바운드 트래픽에 특정 제한이 필요한 경우, 최소 요구 규칙 및 네트워크 ACL 규칙을 참고.

이러한 공급업체 간 협업 구성을 통해 OEM과 공급업체는 각자의 소스 코드를 노출하지 않고도 특정 타깃과 전체 시스템에서 코드 변경 사항을 평가할 수 있습니다.

추가 참고 사항

AWS Resource Access Manager를 사용하면 OEM이 노출된 리소스와 세 계정 간의 통신을 제어할 수 있습니다. 다만, OEM과 공급업체 간 협업 섹션의 1단계에서 OEM은 공유 attachment의 자동 수락(auto accept)을 활성화할 수 있습니다. 이렇게 하면 이 Transit Gateway에 연결된 교차 계정 attachment를 자동으로 수락하여 5단계와 8단계를 생략할 수 있습니다. 공급업체 간 협업 섹션에서도 OEM은 공유 association의 자동 수락을 활성화할 수 있으며, 이를 통해 TGW 멀티캐스트 도메인에 연결된 교차 계정 서브넷 association을 자동으로 수락하여 5단계를 생략할 수 있습니다.

AWS Transit Gateway는 현재 IGMPv2를 지원합니다. Amazon EC2 인스턴스의 하드웨어 및 OS 구성에 따라, 필요한 ENI에서 IGMPv3가 기본 활성화되어 있을 수 있습니다. Ubuntu에서는 다음 명령어로 IGMPv2를 강제할 수 있습니다:

sudo sysctl -w net.ipv4.conf.[NETWORK INTERFACE].force_igmp_version=2

또는:

sudo su
echo “2” > /proc/sys/net/ipv4/conf/[NETWORK INTERFACE]/force_igmp_version

멀티캐스트 구성을 테스트하기 위해, 테스트 중인 EC2 인스턴스에 iperf를 다운로드했습니다. 자세한 절차는 여기서 확인할 수 있습니다. 서버(수신자) 실행:

iperf -s -u -B [MULTICAST GROUP IP ADDRESS] -i 1

그리고 클라이언트(송신자) 실행:

iperf -c [MULTICAST GROUP IP ADDRESS] -u -T 3 -t 20 -i 1 -b 200M

전망

vEDT는 실험 장벽을 낮추고 강력한 기능에 대한 접근을 민주화하여, 자동차 산업이 소프트웨어 정의 차량(SDV)으로 전환하는 데 도움이 되는 보다 협업적인 환경을 조성합니다. AWS Transit Gateway는 이러한 vEDT를 안전하게 상호 연결해 VPC 경계를 넘어 멀티캐스트와 같은 차량 내 서비스 검색 메커니즘을 활용해 가상의 차량 E/E 아키텍처를 구축할 수 있도록 설계되었습니다.

미래에는 Amazon Direct Connect와 같은 AWS 서비스를 활용해 로컬 HiL(Hardware-in-the-Loop) 벤치를 이 구성에 통합하여, SiL(Software-in-the-Loop) 및 OEM의 HiL 환경에 보다 일관된 접근을 제공할 수 있습니다.

결론

가상화와 공급업체 간 협업은 OEM에게 상당한 이점을 제공합니다. 예를 들어, 소프트웨어 및 통합 문제를 더 일찍 식별하고 수정할 수 있으며, 비용이 많이 드는 후반 단계의 재작업을 피할 수 있습니다. 지속적 통합 및 테스트 파이프라인에서 자동화 수준이 향상되며, 코드 변경 사항이 하드웨어 배송, 장치 플래싱 및 기타 시간이 많이 소요되는 유지 관리 작업 없이도 전파될 수 있습니다. Panasonic Automotive vSkipGen™과 ETAS RTA-VRTE StarterKit 같은 혁신은 AWS 서비스 및 기능과 결합되어 전통적인 프로세스를 재편하고, 자동차 공급망 전반에 걸친 보다 안전한 협업을 통해 전례 없는 잠재력을 열어줄 것입니다.

AWS의 제공 서비스에 대해 더 알고 싶다면 AWS for Automotive 페이지를 방문하거나 AWS 팀에 직접 문의하시기 바랍니다.