자동차 업계는 많은 분산형 컴퓨팅 장치의 아키텍처에서 무선 업데이트와 같은 새로운 기능을 지원하는 몇 개의 중앙 집중식 컴퓨팅 장치에 여러 기능을 결합하는 아키텍처로 전환하고 있습니다.
AAOS SDV는 기존 Android 시스템과 인프라를 활용하여 솔루션을 제공합니다. 또한 OEM은 클라우드에서 실행할 수 있는 솔루션을 찾고 있습니다. 클라우드에서 실행하면 초기 개발이 용이하고 새로운 테스트 가능성이 열리기 때문입니다.
디자인
그림 1. SDV Core 아키텍처
SDV Core용 AAOS (SDV Core)는 Android를 기반으로 하는 운영체제입니다. 내장형 특성으로 인해 Android의 JVM 스택을 구현하지 않고 모든 시스템 기능이 기본적으로 개발됩니다.
SDV Core는 주로 가상화된 환경을 위해 개발되며 일부 설계 결정은 이러한 통합을 가정합니다. 그럼에도 불구하고 SDV Core를 기본적으로 실행할 수 있지만 다른 Android 출시 버전과 비교하여 더 많은 통합 작업이 필요합니다.
SDV Core는 로컬 분산 시스템을 위해 설계되었습니다. 예를 들어 SDV Core (또는 파생 상품)의 여러 인스턴스가 동일한 칩 또는 여러 시스템에서 서로 옆에 실행되며 네트워크 연결을 통해 통신할 수 있다고 가정합니다. 따라서 시스템 아키텍처의 핵심 측면은 인스턴스에서 호스팅할 수 있는 서비스로 기능을 구현하는 것입니다.
SDV Core는 차량 내 기능을 개발하기 위한 최소한의 기능 집합입니다. 일반적인 서비스는 몇 개의 신호를 수신하고 처리한 후 결과를 다른 서비스와 공유합니다. 이 범위 제한은 SDV Core가 고급 엔진을 포함하지 않고 비용을 절감할 수 있는 다양한 SoC (System-on-a-chip)를 실행할 수 있도록 하기 위한 것입니다.
세부 설계
그림 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 기본
SDV Core는 Android를 기반으로 하지만 시스템을 필수 시스템 기능으로 줄이고 SDV 런타임 환경을 추가합니다. 즉, SDV도 GKI, 기본 시스템 서비스 (예: adbd, logd), 시스템 기능을 사용하지만 JVM, JVM 기반 서비스 또는 시스템 애플리케이션, JVM용으로 구현된 기능은 포함하지 않습니다.
이는 SDV가 Android의 업데이트 전략과 파티션 레이아웃을 채택한다는 의미이기도 합니다. 보안 요구사항은 비슷하지만 GUI는 없습니다.
GKI, 드라이버, HAL
SDV Core는 Android 6.1 커널과 함께 Android's GKI kernel을 사용합니다. GKI를 사용하는 이점은 업스트림에 적용되는 변경사항이 결국 Android에 적용된다는 것입니다. 또한 Android는 전체 기기에서 하나의 커널을 사용합니다. 예를 들어 패치는 여러 공급업체 커널이 아닌 중앙에서 적용됩니다.
이를 통해 SDV는 안정적인 커널 인터페이스를 가질 수도 있습니다. 예를 들어 보안 수정사항이 포함된 새 커널이 배포되더라도 GKI와 호환되는 모듈로 드라이버를 컴파일할 수 있습니다.
GKI 커널에는 고정된 타임라인이 있습니다. 다음 GKI 커널의 일부가 되어야 하는 공급업체 변경사항은 연말까지 Linux 커널에 업스트림되어야 합니다.
GKI를 사용하면 기기 드라이버와 부팅에 필요하지 않은 모듈이 커널 모듈로 컴파일되고 초기 부팅 중에 로드되는 램디스크에 포함됩니다. 커널 모듈 인터페이스를 기다릴 수 없는 매우 초기 기기 구성 (예: 임의 초기화)은 기기 트리에서 실행해야 합니다. 커널 모듈은 업스트림할 필요는 없지만 GKI 인터페이스에 대해 컴파일해야 합니다.
SDV Core는 Virtio 호환 하이퍼바이저를 기반으로 빌드된다고 가정하므로 기능이 지원되는 경우 드라이버는 Virtio 커널 모듈로 또는 다른 공개 표준 (예: DICE용 공개 프로필 및 신뢰를 위한 공개 DICE 커널 드라이버)으로 제공됩니다.
Virtio (및 공개 표준)와 하이퍼바이저의 조합은 하드웨어 추상화로 이어집니다. 따라서 SDV에서 HAL의 필요성은 최소화되지만 Virtio 지원이 누락되어 일부는 여전히 필요합니다. 예를 들어 하드웨어 기반의 암호화를 위한 KeyMint HAL과 SDV VM 간의 증명을 위한 밀접하게 관련된 IRemotelyPrivisionedComponent HAL이 있습니다.
네트워킹 및 통신 스택
그림 3. SDV Core 네트워킹 및 통신 스택
네트워킹의 경우 SDV Core는 VM 간에 통신하는 데 vsock 또는 이더넷을 사용할 수 있다고 가정합니다. 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 기능은 업데이트 가능성입니다. 새로운 기능은 Android 시스템 업데이트 및 APEX 패키지를 통해 SDV 수명 전반에 걸쳐 설치할 수 있습니다.
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을 동시에 업데이트하기 위한 동기화가 있어야 합니다.