Industri mobil beralih dari arsitektur yang memiliki banyak unit komputasi terdesentralisasi ke arsitektur yang menggabungkan beberapa fungsi menjadi beberapa unit komputasi terpusat yang memungkinkan fitur baru seperti update over the air.
SDV AAOS memanfaatkan sistem dan infrastruktur Android yang ada untuk menawarkan solusi. Selain itu, OEM mencari solusi yang juga dapat berjalan di Cloud karena hal ini memfasilitasi pengembangan awal dan memungkinkan kemungkinan pengujian baru.
Desain
Gambar 1. Arsitektur SDV Core.
AAOS untuk SDV Core (SDV Core) adalah sistem operasi yang berbasis Android. Karena sifatnya yang tersemat, sistem ini tidak mengimplementasikan stack JVM Android, tetapi semua fungsi sistem dikembangkan secara native.
SDV Core terutama dikembangkan untuk lingkungan virtual dan beberapa keputusan desain mengasumsikan integrasi ini. Namun, SDV Core dapat dijalankan secara native, tetapi hal ini memerlukan lebih banyak pekerjaan integrasi dibandingkan dengan rilis Android lainnya.
SDV Core dirancang untuk sistem terdistribusi lokal, misalnya, sistem ini mengasumsikan bahwa beberapa instance SDV Core (atau turunannya) berjalan berdampingan di chip yang sama, atau di beberapa sistem, dan dapat berkomunikasi melalui koneksi jaringan. Oleh karena itu, aspek inti dari arsitektur sistem adalah penerapan fungsionalitas sebagai layanan yang dapat dihosting di salah satu instance.
SDV Core adalah kumpulan fungsi minimal untuk mengembangkan fungsi dalam mobil. Layanan umum akan menerima beberapa sinyal, memprosesnya, dan membagikan hasilnya ke layanan lain. Batasan cakupan ini disengaja karena memungkinkan SDV Core menjalankan berbagai SoC (System-on-a-chip) yang mungkin tidak berisi mesin lanjutan dan menghemat biaya.
Desain mendetail
Gambar 2. Arsitektur mendetail SDV Core.
SDV Core berasal dari Android, sehingga arsitekturnya mencoba menyesuaikan dengan Android sebaik mungkin. Pada dasarnya, ini berarti SDV Core juga menggunakan GKI, driver, HAL, dan library inti dari Android, serta menambahkan komponen yang diperlukan untuk arsitektur layanan.
Bagian berikut akan membahas komponen sistem secara mendetail.
Lingkungan host dan Virtualisasi
SDV Core dikembangkan dengan asumsi bahwa SDV Core akan berjalan di lingkungan virtual, sehingga kami membuat beberapa asumsi tentang lingkungan host:
Lingkungan host menjalankan hypervisor yang mendukung perangkat Virtio. Selain itu, hypervisor harus mengimplementasikan Ethernet atau vsock, status daya, dan perangkat blok. Selain itu, hypervisor harus mendukung Android/Linux.
Terkait hardware, SDV Core mengasumsikan CPU dan MMU yang memiliki dukungan virtualisasi hardware dan bahwa sistem terhubung melalui Ethernet. Sistem tidak perlu memiliki GPU, IPU, CSI, mesin media, layar, atau bus komunikasi otomotif lainnya (misalnya, CAN, LIN).
Android Base
SDV Core didasarkan pada Android, tetapi mengurangi sistem menjadi fungsi sistem
yang penting, dan menambahkan lingkungan runtime SDV. Artinya, SDV juga
menggunakan GKI, layanan sistem native (misalnya, adbd dan logd), dan fungsi
sistem, tetapi tidak menyertakan JVM, dan layanan berbasis JVM atau aplikasi
sistem, atau fitur yang diimplementasikan untuk JVM.
Artinya, SDV juga akan menyesuaikan strategi update dan tata letak partisi Android. Sistem ini memiliki persyaratan keamanan yang serupa, tetapi tidak memiliki GUI.
GKI, Driver, dan HAL
SDV Core menggunakan kernel GKI Android dengan kernel 6.1 Android. Keuntungan menggunakan GKI adalah perubahan yang masuk ke upstream pada akhirnya akan masuk ke Android. Selain itu, Android menggunakan satu kernel di seluruh perangkat. Misalnya, patch diterapkan secara terpusat, bukan ke beberapa kernel vendor.
Hal ini juga memungkinkan SDV memiliki antarmuka kernel yang stabil. Misalnya, Anda dapat mengompilasi driver sebagai modul yang berfungsi dengan GKI bahkan saat kernel baru dengan perbaikan keamanan di-deploy.
Kernel GKI memiliki linimasa yang tetap, perubahan vendor yang seharusnya menjadi bagian dari kernel GKI berikutnya harus di-upstream ke kernel Linux hingga akhir tahun.
Dengan GKI, driver perangkat dan modul yang tidak diperlukan untuk booting akan dikompilasi sebagai modul kernel, dan akan dimuat dalam ramdisk yang dimuat selama booting awal. Konfigurasi perangkat yang sangat awal dan tidak dapat menunggu antarmuka modul kernel (misalnya, inisialisasi acak) harus dilakukan di device tree. Modul kernel tidak wajib di-upstream, tetapi harus dikompilasi terhadap antarmuka GKI.
Karena SDV Core mengasumsikan bahwa SDV Core dibangun di atas hypervisor yang kompatibel dengan Virtio, driver dikirimkan sebagai modul kernel Virtio jika fitur tersebut didukung, atau sebagai standar terbuka lainnya (misalnya, Open Profile untuk DICE dan driver kernel open-dice untuk kepercayaan).
Kombinasi Virtio (dan standar terbuka) serta hypervisor ini menghasilkan abstraksi hardware. Oleh karena itu, kebutuhan akan HAL di SDV sangat minim, tetapi beberapa masih diperlukan karena tidak adanya dukungan Virtio. Misalnya, KeyMint HAL untuk kriptografi yang didukung hardware dan HAL IRemotelyPrivisionedComponent yang terkait erat untuk pengesahan di antara VM SDV.
Stack Jaringan dan Komunikasi
Gambar 3. Stack Jaringan dan Komunikasi Inti SDV.
Untuk jaringan, SDV Core mengasumsikan bahwa vsock atau Ethernet tersedia untuk berkomunikasi di seluruh VM, komunikasi internal VM juga dapat menggunakan mekanisme IPC seperti binder.
SDV mendukung komunikasi serial hanya untuk tujuan proses debug.
Gambar 4. Dukungan serial SDV Core untuk proses debug.
Dalam satu tamu, SDV menyediakan beberapa opsi yang bergantung pada model komunikasi dan persyaratan performa.
Vsock
Vsock adalah saluran pilihan untuk komunikasi lokal antara beberapa VM atau Host dan VM. VM harus menggunakan komunikasi vsock langsung antara satu sama lain untuk memungkinkan implementasi mengoptimalkan jumlah salinan.
Memori Bersama
Memori bersama hanya digunakan untuk berkomunikasi dengan VM untuk IPC (komunikasi antarproses), tetapi tidak ditawarkan sebagai saluran reguler untuk berkomunikasi antara beberapa VM. Host dapat menggunakan memori bersama untuk berbagi informasi dengan tamu, tetapi tidak direncanakan untuk traffic jaringan frekuensi tinggi.
Ethernet
Ethernet digunakan untuk komunikasi antara beberapa SoC, yaitu untuk komunikasi dalam kendaraan. Sistem ini dapat berupa sistem virtual, tetapi juga sistem native atau ECU lama.
Jaringan kendaraan cukup kecil sehingga ruang alamat IPv4 cukup untuk mengidentifikasi semua sistem yang tersedia. Namun, untuk memastikan bahwa sistem kompatibel dengan potensi uplink dan pengembangan di masa mendatang, IPv4 dan IPv6 harus didukung.
VLAN
VLAN adalah mekanisme untuk membuat arsitektur jaringan virtual yang memungkinkan isolasi subnetwork yang berbeda dan pembentukan jaringan lokal. Hal ini dapat digunakan untuk membuat zona keamanan yang berbeda, dan digunakan untuk tujuan tersebut di dalam mobil. Dukungan VLAN diperlukan.
Protokol
TCP dan UDP
Bergantung pada kasus penggunaan, sistem memerlukan protokol komunikasi yang andal atau tidak andal, tetapi cepat. Oleh karena itu, TCP dan UDP akan didukung.
Tunnel Data
Data Tunnel adalah mekanisme komunikasi yang baru dikembangkan untuk SDV yang menawarkan saluran komunikasi cepat mengikuti model pubsub, misalnya satu aplikasi memublikasikan topik sementara satu atau beberapa aplikasi dapat memprosesnya. Secara internal, library ini menggunakan memori bersama dan FMQ (antrean pesan cepat) dalam VM, atau vsock atau Ethernet untuk berkomunikasi di seluruh VM.
RPC (SDV)
RPC SDV mengimplementasikan remote procedure call untuk SDV yang memanfaatkan binder. gRPC menggunakan API yang telah ditentukan untuk memanggil prosedur jarak jauh. Mirip dengan Data Tunnel, fitur ini menggunakan memori bersama untuk komunikasi dalam VM, atau vsock atau Ethernet untuk komunikasi lintas VM.
Framework
SOMEIP
SOMEIP digunakan untuk berkomunikasi dengan sistem non-SDV. Protokol ini dibangun di atas TCP dan UDP serta tidak memerlukan hardware atau driver khusus. Google akan menerapkan referensi.
Agen Penemuan Layanan (Agen SD)
Layanan ini menyediakan penemuan layanan, autentikasi, dan otorisasi ke SDV. Untuk komunikasi, agen dapat menggunakan salah satu metode yang disebutkan sebelumnya. Untuk autentikasi dan otorisasi, Agen SD akan memerlukan akses ke hardware keamanan, dan rantai kepercayaan yang berfungsi.
Middleware
SDV mengembangkan framework untuk menyederhanakan penggunaan semua protokol yang berbeda tersebut, yang disebut Middleware. Arsitektur ini juga menerapkan sumber kebenaran untuk semua sinyal kendaraan dengan bahasa baru VSIDL.
Zona netral
Untuk mengisolasi bagian sistem guna mencegah serangan dari bagian sistem yang kurang tepercaya (misalnya, IVI dengan aplikasi terinstal kustom), jaringan dapat memperkenalkan zona yang berbeda, termasuk zona demiliterisasi. Dalam praktiknya, ini berarti subnetwork dipisahkan secara fisik atau logis, dan hanya traffic dalam daftar yang diizinkan yang dapat melewati batas tersebut.
Pengelola Konektivitas
Di Android, sudah menjadi praktik umum untuk membatasi jumlah aplikasi dan layanan yang dapat membuka koneksi soket sendiri. Sebagai gantinya, instance pusat bertanggung jawab untuk membuka dan mengelola koneksi. Karena Android menerapkan fungsi ini dalam layanan Java, SDV akan membangun pengelola konektivitasnya sendiri.
Kapasitas update
Fitur utama SDV adalah kapasitas update. Fitur baru dapat diinstal selama masa pakai SDV melalui update sistem Android dan paket APEX.
Pembaruan Sistem Android
Android sudah menyediakan mekanisme untuk menginstal update. Android menggunakan update A/B dan A/B virtual di versi terbaru, dan SDV Core akan memanfaatkan mekanisme ini. Update A/B membuat setiap partisi dua kali, yang memberikan dua keuntungan: sistem dapat diupdate di latar belakang, dan jika update gagal, sistem dapat di-roll back ke versi terakhir yang diketahui berfungsi.
Paket APEX
Selain membagi sistem menjadi beberapa partisi dan membuatnya dapat diupdate, Android juga menyediakan paket APEX, mekanisme untuk memasukkan aplikasi dan library ke dalam paket kecil yang dapat diinstal dan diupdate secara independen dari update sistem.
SDV Core akan menggunakan container APEX untuk menginstal layanan secara dinamis di instance SDV, tetapi juga untuk mengelola deployment beberapa layanan ke dalam satu proses: hanya layanan yang dipaketkan dalam APEX yang sama dan menggunakan sertifikat yang sama yang dapat di-deploy dalam biner yang sama untuk mengurangi risiko keamanan.
Mekanisme Android untuk menginstal paket APEX memanfaatkan beberapa kode Java untuk pengelolaan APK guna memverifikasi paket. SDV Core perlu mengimplementasikan alternatif native untuk memungkinkan penginstalan paket APEX secara dinamis.
Pengelolaan Update
Instance SDV bukanlah unit yang sepenuhnya independen di dalam mobil, dan memerlukan orkestrasi dengan instance SDV dan layanan mobil lainnya. Misalnya, untuk menginstal dependensi layanan atau untuk memastikan update hanya diinstal dalam status sistem yang aman.
SDV mempertimbangkan penggunaan partisi di beberapa VM. Hal ini memerlukan koordinasi antara VM tersebut, karena VM tersebut memiliki dependensi data satu sama lain: harus ada VM utama untuk mengupdate partisi tersebut, dan mekanisme untuk memberi tahu VM lain tentang partisi yang diupdate dan sinkronisasi untuk mengupdate semua VM secara bersamaan guna memastikan status kerja yang diketahui sebelumnya tidak rusak.
Memulai
Panduan Memulai kami memberikan detail tentang kode sumber, membangun, dan meluncurkan dengan Cuttlefish.