Industri mobil beralih dari arsitektur yang terdiri dari banyak unit komputasi terdesentralisasi ke arsitektur yang menggabungkan beberapa fungsi ke dalam beberapa unit komputasi terpusat yang memungkinkan fitur baru seperti update over the air.
AAOS SDV menggunakan 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 Inti SDV.
AAOS untuk Inti SDV (Inti SDV) adalah sistem operasi yang berbasis Android. Karena sifatnya yang tersemat, sistem operasi ini tidak menerapkan stack JVM Android, tetapi semua fungsi sistem dikembangkan secara native.
Inti SDV terutama dikembangkan untuk lingkungan tervirtualisasi dan beberapa keputusan desain mengasumsikan integrasi ini. Namun, Inti SDV dapat dijalankan secara native, tetapi hal ini memerlukan lebih banyak pekerjaan integrasi dibandingkan dengan rilis Android lainnya.
Inti SDV dirancang untuk sistem terdistribusi lokal. Misalnya, sistem ini mengasumsikan bahwa beberapa instance Inti SDV (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 fungsi sebagai layanan yang dapat dihosting di salah satu instance.
Inti SDV 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 sengaja dibuat karena memungkinkan Inti SDV menjalankan berbagai SoC (System-on-a-chip) yang mungkin tidak berisi mesin canggih dan menghemat biaya.
Desain mendetail
Gambar 2. Arsitektur mendetail Inti SDV.
Inti SDV berasal dari Android, sehingga arsitekturnya mencoba untuk selaras dengan Android sebaik mungkin. Pada dasarnya, hal ini berarti Inti SDV 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
Inti SDV dikembangkan dengan asumsi bahwa sistem ini 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 menerapkan Ethernet atau vsock, status daya, dan perangkat blok. Selain itu, hypervisor harus mendukung Android/Linux.
Terkait hardware, Inti SDV mengasumsikan CPU dan MMU yang memiliki dukungan virtualisasi hardware dan sistem terhubung melalui Ethernet. Sistem tidak diwajibkan untuk memiliki GPU, IPU, CSI, mesin media, tampilan, atau bus komunikasi otomotif lainnya (misalnya, CAN, LIN).
Basis Android
Inti SDV didasarkan pada Android, tetapi mengurangi sistem ke fungsi sistem 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 atau aplikasi sistem berbasis JVM, maupun fitur yang diterapkan untuk JVM.
Hal ini juga berarti SDV akan mengadaptasi strategi update dan tata letak partisi Android. Sistem ini memiliki persyaratan keamanan yang serupa, tetapi tidak memiliki GUI.
GKI, Driver, dan HAL
Pengguna Inti SDV menggunakan kernel GKI Android dengan kernel Android 6.1. Keuntungan menggunakan GKI adalah perubahan yang masuk ke upstream pada akhirnya akan masuk ke Android. Selain itu, Android menggunakan satu kernel di seluruh fleet. 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 meskipun kernel baru dengan perbaikan keamanan di-deploy.
Kernel GKI memiliki linimasa tetap. Perubahan vendor yang akan menjadi bagian dari kernel GKI berikutnya harus di-upstream ke kernel Linux hingga akhir tahun.
Dengan GKI, driver perangkat dan modul yang tidak diperlukan saat booting akan dikompilasi sebagai modul kernel, dan akan dimuat dalam ramdisk yang dimuat selama booting awal. Konfigurasi perangkat yang sangat awal yang tidak dapat menunggu antarmuka modul kernel (misalnya, inisialisasi acak) harus dilakukan di pohon perangkat. Modul kernel tidak diwajibkan untuk di-upstream, tetapi harus dikompilasi terhadap antarmuka GKI.
Karena Inti SDV mengasumsikan bahwa sistem ini dibangun di atas hypervisor yang kompatibel dengan Virtio, driver dikirimkan sebagai modul kernel Virtio jika fitur ini didukung, atau sebagai standar terbuka lainnya (misalnya, Open Profile for 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 HAL masih diperlukan karena tidak adanya dukungan Virtio. Misalnya, KeyMint HAL untuk kriptografi yang didukung hardware dan IRemotelyPrivisionedComponent HAL yang terkait erat untuk pengesahan di antara VM SDV.
Stack Jaringan dan Komunikasi
Gambar 3. Stack Jaringan dan Komunikasi Inti SDV.
Untuk jaringan, Inti SDV mengasumsikan bahwa vsock atau Ethernet tersedia untuk berkomunikasi di seluruh VM. Komunikasi internal VM juga dapat menggunakan mekanisme IPC seperti binder.
SDV hanya mendukung komunikasi serial untuk tujuan proses debug.
Gambar 4. Dukungan serial Inti SDV 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 satu sama lain untuk memungkinkan penerapan mengoptimalkan jumlah salinan.
Memori Bersama
Memori bersama hanya digunakan untuk berkomunikasi dengan VM untuk IPC (komunikasi antar-proses), 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 akan digunakan untuk komunikasi antara beberapa SoC, yaitu untuk komunikasi dalam kendaraan. Hal ini dapat berupa sistem tervirtualisasi, 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 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 membentuk 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
Tunnel Data adalah mekanisme komunikasi yang baru dikembangkan untuk SDV yang menawarkan saluran komunikasi cepat yang mengikuti model pubsub. Misalnya, satu aplikasi memublikasikan topik sementara satu atau beberapa aplikasi dapat mendengarkannya. Secara internal, mekanisme ini menggunakan memori bersama dan FMQ (antrean pesan cepat) dalam VM, atau vsock atau Ethernet untuk berkomunikasi di seluruh VM.
RPC (SDV)
RPC SDV menerapkan remote procedure call untuk SDV yang memanfaatkan binder. RPC ini menggunakan API yang telah ditentukan untuk memanggil prosedur jarak jauh. Mirip dengan Tunnel Data, RPC 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. SOMEIP dibangun di atas TCP dan UDP dan tidak memerlukan hardware atau driver khusus. Google akan menerapkan referensi.
Agen Penemuan Layanan (Agen SD)
Agen ini menyediakan penemuan layanan, autentikasi, dan otorisasi ke SDV. Untuk komunikasi, agen ini 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. Middleware ini juga menerapkan sumber tepercaya 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 yang diinstal kustom), jaringan dapat memperkenalkan zona yang berbeda, termasuk zona demiliterisasi. Dalam praktiknya, hal ini berarti subnetwork dipisahkan secara fisik atau logis, dan hanya traffic yang diizinkan yang dapat melewati batas tersebut.
Pengelola Konektivitas
Di Android, membatasi jumlah aplikasi dan layanan yang dapat membuka koneksi soket sendiri adalah praktik umum. Sebagai gantinya, instance pusat bertanggung jawab untuk membuka dan mengelola koneksi. Karena Android menerapkan fungsi ini dalam layanan Java, SDV akan membuat 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.
Update Sistem Android
Android sudah menyediakan mekanisme untuk menginstal update. Android menggunakan update A/B dan A/B virtual dalam versi terbaru, dan Inti SDV 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 melakukan rollback 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 menempatkan aplikasi dan library ke dalam paket kecil yang dapat diinstal dan diupdate secara independen dari update sistem.
Inti SDV akan menggunakan container APEX untuk menginstal layanan secara dinamis pada instance SDV, tetapi juga untuk mengelola deployment beberapa layanan ke dalam satu proses: hanya layanan yang di-bundling 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. Inti SDV harus menerapkan 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 dan sinkronisasi yang diupdate untuk mengupdate semua VM secara bersamaan guna memastikan status kerja sebelumnya tidak rusak.