자동차 산업은 여러 분산 컴퓨팅 단위의 아키텍처에서 여러 기능을 무선 업데이트와 같은 새로운 기능을 지원하는 소수의 중앙 집중식 컴퓨팅 단위로 결합하는 아키텍처로 전환하고 있습니다.
AAOS SDV는 기존 Android 시스템과 인프라를 활용하여 솔루션을 제공합니다. 또한 OEM은 클라우드에서도 실행할 수 있는 솔루션을 찾고 있습니다. 이를 통해 초기 개발을 촉진하고 새로운 테스트 가능성을 실현할 수 있기 때문입니다.
디자인
그림 1. SDV 핵심 아키텍처
SDV Core용 AAOS (SDV Core)는 Android를 기반으로 하는 운영체제입니다. 임베디드 특성으로 인해 Android의 JVM 스택을 구현하지 않지만 대신 모든 시스템 기능이 기본적으로 개발됩니다.
SDV Core는 주로 가상화된 환경을 위해 개발되었으며 일부 설계 결정은 이 통합을 가정합니다. 그럼에도 불구하고 SDV Core를 기본적으로 실행할 수 있지만, 다른 Android 버전에 비해 더 많은 통합 작업이 필요합니다.
SDV Core는 로컬 분산 시스템용으로 설계되었습니다. 예를 들어 SDV Core (또는 파생 제품)의 여러 인스턴스가 동일한 칩에서 또는 여러 시스템에서 서로 나란히 실행되며 네트워크 연결을 통해 통신할 수 있다고 가정합니다. 따라서 시스템 아키텍처의 핵심 측면은 모든 인스턴스에서 호스팅할 수 있는 서비스로 기능을 구현하는 것입니다.
SDV Core는 차량 내 기능을 개발하는 데 필요한 최소한의 기능 집합입니다. 일반적인 서비스는 몇 가지 신호를 수신하고 처리한 후 결과를 다른 서비스와 공유합니다. 이 범위 제한은 SDV Core가 고급 엔진을 포함하지 않을 수 있는 다양한 SoC (단일 칩 시스템)를 실행하고 비용을 절감할 수 있도록 하기 위한 것입니다.
세부 설계
그림 2. SDV Core 상세 아키텍처
SDV Core는 Android에서 파생되므로 아키텍처는 최대한 Android와 일치하도록 시도합니다. 기본적으로 이는 SDV Core가 Android의 GKI, 드라이버, HAL, 핵심 라이브러리도 사용하고 서비스 아키텍처에 필요한 구성요소를 추가한다는 의미입니다.
다음 섹션에서는 시스템 구성요소를 자세히 설명합니다.
호스트 환경 및 가상화
SDV Core는 가상 환경에서 실행된다는 가정하에 개발되므로 호스트 환경에 관해 다음과 같은 가정을 합니다.
호스트 환경은 Virtio 기기를 지원하는 하이퍼바이저를 실행합니다. 또한 하이퍼바이저는 이더넷 또는 vsock, 전원 상태, 블록 기기를 구현해야 합니다. 또한 하이퍼바이저는 Android/Linux 실행을 지원해야 합니다.
하드웨어와 관련하여 SDV Core는 하드웨어 가상화를 지원하는 CPU와 MMU가 있고 시스템이 이더넷을 통해 연결되어 있다고 가정합니다. 시스템에 GPU, IPU, CSI, 미디어 엔진, 디스플레이 또는 기타 자동차 통신 버스 (예: CAN, LIN)가 있을 필요는 없습니다.
Android Base
SDV Core는 Android를 기반으로 하지만 시스템을 필수 시스템 기능으로 줄이고 SDV 런타임 환경을 추가합니다. 즉, SDV는 GKI, 네이티브 시스템 서비스 (예: adbd 및 logd), 시스템 기능도 사용하지만 JVM, JVM 기반 서비스 또는 시스템 애플리케이션, JVM용으로 구현된 기능은 포함하지 않습니다.
이는 SDV가 Android의 업데이트 전략과 파티션 레이아웃을 조정한다는 의미이기도 합니다. 보안 요구사항은 비슷하지만 GUI가 없습니다.
GKI, 드라이버, HAL
SDV Core는 Android 6.1 커널과 함께 Android의 GKI 커널을 사용합니다. GKI를 사용하면 업스트림에 적용된 변경사항이 결국 Android에 적용된다는 이점이 있습니다. 또한 Android는 전체 기기에서 하나의 커널을 사용합니다. 예를 들어 패치는 여러 공급업체 커널이 아닌 중앙에서 적용됩니다.
이를 통해 SDV는 안정적인 커널 인터페이스를 가질 수 있습니다. 예를 들어 보안 수정사항이 포함된 새 커널이 배포된 경우에도 GKI와 함께 작동하는 모듈로 드라이버를 컴파일할 수 있습니다.
GKI 커널에는 고정된 타임라인이 있습니다. 다음 GKI 커널의 일부가 되어야 하는 공급업체 변경사항은 연말까지 Linux 커널로 업스트림되어야 합니다.
GKI를 사용하면 기기 드라이버와 부팅에 필요하지 않은 모듈이 커널 모듈로 컴파일되고 초기 부팅 중에 로드되는 램디스크에 포함됩니다. 커널 모듈 인터페이스를 기다릴 수 없는 매우 초기 기기 구성 (예: 무작위 초기화)은 기기 트리에서 실행되어야 합니다. 커널 모듈은 업스트림할 필요가 없지만 GKI 인터페이스에 맞게 컴파일해야 합니다.
SDV Core는 Virtio 호환 하이퍼바이저를 기반으로 빌드되었다고 가정하므로, 기능이 지원되는 경우 드라이버는 Virtio 커널 모듈로 제공되거나 다른 개방형 표준 (예: DICE용 개방형 프로필 및 신뢰를 위한 open-dice 커널 드라이버)으로 제공됩니다.
Virtio (및 개방형 표준)와 하이퍼바이저의 조합은 하드웨어 추상화로 이어집니다. 따라서 SDV에서 HAL의 필요성은 최소화되지만 Virtio 지원이 누락되어 일부는 여전히 필요합니다. 예를 들어 하드웨어 기반의 암호화를 위한 KeyMint HAL과 SDV VM 간 증명을 위한 밀접하게 관련된 IRemotelyPrivisionedComponent HAL이 있습니다.
네트워킹 및 통신 스택
그림 3. SDV 핵심 네트워킹 및 통신 스택
네트워킹의 경우 SDV Core는 vsock 또는 이더넷을 사용하여 VM 간에 통신할 수 있다고 가정하며, VM 내부 통신은 바인더와 같은 IPC 메커니즘을 사용할 수도 있습니다.
SDV는 디버깅 목적으로만 직렬 통신을 지원합니다.
그림 4. 디버깅을 위한 SDV Core 직렬 지원
단일 게스트 내에서 SDV는 통신 모델 및 성능 요구사항에 따라 여러 옵션을 제공합니다.
Vsock
Vsock은 여러 VM 또는 호스트와 VM 간의 로컬 통신에 선호되는 채널입니다. VM은 구현에서 복사본 수를 최적화할 수 있도록 서로 직접 vsock 통신을 사용해야 합니다.
공유 메모리
공유 메모리는 IPC (프로세스 간 통신)를 위해 VM과 통신하는 데만 사용되며 여러 VM 간에 통신하는 일반 채널로 제공되지 않습니다. 호스트는 공유 메모리를 사용하여 게스트와 정보를 공유할 수 있지만, 고주파 네트워킹 트래픽에는 계획되지 않습니다.
이더넷
이더넷은 여러 SoC 간의 통신, 즉 차량 내 통신에 사용됩니다. 가상화된 시스템일 수도 있지만 네이티브 시스템이나 기존 ECU일 수도 있습니다.
차량 네트워크는 IPv4 주소 공간이 사용 가능한 모든 시스템을 식별하기에 충분할 정도로 작습니다. 그럼에도 불구하고 시스템이 잠재적인 업링크 및 향후 개발과 호환되도록 하려면 IPv4 및 IPv6를 지원해야 합니다.
VLAN
VLAN은 서로 다른 서브네트워크를 격리하고 로컬 네트워크를 형성할 수 있는 가상 네트워크 아키텍처를 만드는 메커니즘입니다. 이는 다양한 보안 영역을 만드는 데 사용할 수 있으며 자동차 내에서 이러한 목적으로 사용됩니다. VLAN 지원이 필요합니다.
프로토콜
TCP 및 UDP
사용 사례에 따라 시스템에는 안정적인 통신 프로토콜 또는 안정적이지 않지만 빠른 통신 프로토콜이 필요합니다. 따라서 TCP 및 UDP가 지원됩니다.
데이터 터널
데이터 터널은 SDV를 위해 새로 개발된 통신 메커니즘으로, pubsub 모델을 따르는 빠른 통신 채널을 제공합니다. 예를 들어 한 애플리케이션이 주제를 게시하면 하나 이상의 애플리케이션이 이를 수신할 수 있습니다. 내부적으로는 VM 내에서 공유 메모리와 FMQ (빠른 메시지 대기열)를 활용하거나 vsock 또는 이더넷을 활용하여 VM 간에 통신합니다.
(SDV) RPC
SDV RPC는 바인더를 활용하여 SDV의 리모트 프로시져 콜을 구현합니다. 사전 정의된 API를 사용하여 원격 프로시져를 호출합니다. 데이터 터널과 마찬가지로 VM 내 통신에는 공유 메모리를 사용하고 VM 간 통신에는 vsock 또는 이더넷을 사용합니다.
프레임워크
SOMEIP
SOMEIP는 SDV가 아닌 시스템과 통신하는 데 사용됩니다. TCP 및 UDP를 기반으로 빌드되며 특수 하드웨어나 드라이버가 필요하지 않습니다. Google은 참조를 구현합니다.
서비스 검색 에이전트 (SD 에이전트)
SDV에 서비스 검색, 인증, 승인을 제공합니다. 통신에는 이전에 언급된 방법 중 하나를 사용할 수 있습니다. 인증 및 승인을 위해 SD 에이전트는 보안 하드웨어 및 작동하는 신뢰 체인에 액세스해야 합니다.
미들웨어
SDV는 미들웨어라고 하는 다양한 프로토콜을 간편하게 사용할 수 있는 프레임워크를 개발합니다. 또한 새로운 언어 VSIDL을 사용하여 모든 차량 신호의 정보 소스를 구현합니다.
중립 구간
시스템의 신뢰도가 낮은 부분 (예: 맞춤 설치된 앱이 있는 IVI)에서 발생하는 공격을 방지하기 위해 시스템의 일부를 격리하려면 네트워크에서 비무장지대를 비롯한 다양한 영역을 도입할 수 있습니다. 실제로 이는 서브네트워크가 물리적으로 또는 논리적으로 분리되어 있으며 허용 목록에 있는 트래픽만 이러한 경계를 통과할 수 있음을 의미합니다.
연결 관리자
Android에서는 소켓 연결을 직접 열 수 있는 애플리케이션 및 서비스의 수를 제한하는 것이 일반적입니다. 대신 중앙 인스턴스가 연결을 열고 관리합니다. Android는 이 기능을 Java 서비스로 구현하므로 SDV는 자체 연결 관리자를 빌드합니다.
업데이트 가능성
SDV의 주요 기능은 업데이트 가능성입니다. SDV 수명 주기 동안 Android 시스템 업데이트와 APEX 패키지를 통해 새로운 기능을 설치할 수 있습니다.
Android 시스템 업데이트
Android는 이미 업데이트를 설치하는 메커니즘을 제공합니다. 최신 버전에서는 A/B 및 가상 A/B 업데이트를 사용하며 SDV Core는 이 메커니즘을 활용합니다. A/B 업데이트는 각 파티션을 두 번 생성하므로 두 가지 이점이 있습니다. 시스템을 백그라운드에서 업데이트할 수 있으며 업데이트가 실패하면 시스템이 마지막으로 알려진 버전으로 롤백하여 작동할 수 있습니다.
APEX 패키지
Android는 시스템을 여러 파티션으로 분할하고 업데이트할 수 있도록 하는 것 외에도, 애플리케이션과 라이브러리를 시스템 업데이트와 독립적으로 설치 및 업데이트할 수 있는 작은 패키지로 만드는 메커니즘인 APEX 패키지를 제공합니다.
SDV Core는 APEX 컨테이너를 사용하여 SDV 인스턴스에 서비스를 동적으로 설치하고, 단일 프로세스에 여러 서비스의 배포를 관리합니다. 동일한 APEX에 번들로 묶여 있고 동일한 인증서를 사용하는 서비스만 동일한 바이너리에 배포하여 보안 위험을 줄일 수 있습니다.
APEX 패키지를 설치하는 Android 메커니즘은 APK 관리를 위한 일부 Java 코드를 활용하여 패키지를 확인합니다. SDV Core는 APEX 패키지를 동적으로 설치할 수 있도록 네이티브 대안을 구현해야 합니다.
업데이트 관리
SDV 인스턴스는 자동차에서 완전히 독립적인 단위가 아니며 다른 SDV 인스턴스 및 자동차 서비스와의 조정이 필요합니다. 예를 들어 서비스 종속 항목을 설치하거나 업데이트가 안전한 시스템 상태에서만 설치되도록 하는 경우입니다.
SDV는 여러 VM에서 파티션을 사용하는 것을 고려합니다. 이러한 VM은 서로 데이터 종속성이 있으므로 VM 간의 조정이 필요합니다. 즉, 파티션을 업데이트하는 기본 VM이 있어야 하고, 업데이트된 파티션에 관해 다른 VM에 알리는 메커니즘이 있어야 하며, 이전에 알려진 작동 상태가 손상되지 않도록 모든 VM을 동시에 업데이트하기 위한 동기화가 있어야 합니다.
시작하기
시작 가이드에서는 소스 코드, Cuttlefish를 사용한 빌드 및 실행에 관한 세부정보를 제공합니다.