Przemysł motoryzacyjny odchodzi od architektury z wieloma zdecentralizowanymi jednostkami obliczeniowymi na rzecz architektury, która łączy wiele funkcji w kilku scentralizowanych jednostkach obliczeniowych, umożliwiając nowe funkcje, takie jak aktualizacje bezprzewodowe.
AAOS SDV korzysta z istniejącego systemu Android i infrastruktury, aby oferować rozwiązanie. Ponadto producenci OEM szukają rozwiązań, które mogą działać w chmurze, ponieważ ułatwia to wczesne etapy rozwoju i umożliwia nowe możliwości testowania.
Projektowanie
Rysunek 1. Architektura SDV Core.
AAOS for SDV Core (SDV Core) to system operacyjny oparty na Androidzie. Ze względu na wbudowany charakter nie implementuje stosu JVM Androida, ale wszystkie funkcje systemu są opracowywane natywnie.
SDV Core jest opracowywany głównie z myślą o środowisku wirtualnym, a niektóre decyzje projektowe zakładają taką integrację. Niemniej jednak można uruchomić SDV Core natywnie, ale wymaga to większego nakładu pracy związanej z integracją w porównaniu z innymi wersjami Androida.
SDV Core jest przeznaczony do lokalnego systemu rozproszonego, np. zakłada, że wiele instancji SDV Core (lub jego pochodnych) działa obok siebie na tym samym chipie lub w wielu systemach i może komunikować się za pomocą połączenia sieciowego. Dlatego podstawowym aspektem architektury systemu jest implementacja funkcji jako usług, które można hostować na dowolnej instancji.
SDV Core to minimalny zestaw funkcji do tworzenia funkcji w samochodzie. Typowa usługa otrzymuje kilka sygnałów, przetwarza je i udostępnia wynik innym usługom. To ograniczenie zakresu jest celowe, ponieważ umożliwia SDV Core działanie na wielu różnych układach SoC (System-on-a-chip), które mogą nie zawierać zaawansowanych silników, co pozwala obniżyć koszty.
Szczegółowy projekt
Rysunek 2. Szczegółowa architektura SDV Core.
SDV Core wywodzi się z Androida, dlatego jego architektura jest w jak największym stopniu zgodna z Androidem. Oznacza to, że SDV Core korzysta też z GKI, sterowników, HAL-i i bibliotek podstawowych z Androida oraz dodaje komponenty wymagane w architekturze usługi.
W kolejnych sekcjach omówimy szczegółowo komponenty systemu.
Środowisko hosta i wirtualizacja
SDV Core jest opracowywany z założeniem, że będzie działać w środowisku wirtualnym, dlatego przyjmujemy pewne założenia dotyczące środowiska hosta:
Środowisko hosta uruchamia hiperwizor, który obsługuje urządzenia Virtio. Dodatkowo hiperwizor musi obsługiwać Ethernet lub vsock, stany zasilania i urządzenia blokowe. Ponadto hiperwizor musi obsługiwać system Android/Linux.
W przypadku sprzętu SDV Core zakłada, że procesor i MMU obsługują wirtualizację sprzętową, a system jest połączony przez Ethernet. System nie musi mieć procesora graficznego, procesora IPU, interfejsu CSI, silników multimedialnych, wyświetlacza ani innych samochodowych magistrali komunikacyjnych (np. CAN, LIN).
Android Base
SDV Core jest oparty na Androidzie, ale ogranicza system do podstawowych funkcji systemowych i dodaje środowisko wykonawcze SDV. Oznacza to, że SDV korzysta też z GKI, natywnych usług systemowych (np. adbd i logd) oraz funkcji systemowych, ale nie obejmuje JVM ani usług opartych na JVM, aplikacji systemowych ani funkcji zaimplementowanych dla JVM.
Oznacza to również, że SDV dostosuje strategię aktualizacji i układ partycji Androida. Ma podobne wymagania dotyczące bezpieczeństwa, ale nie ma graficznego interfejsu użytkownika.
GKI, sterowniki i HAL
Użytkownicy SDV Core jądra GKI Androida z jądrem Androida 6.1. Zaletą korzystania z GKI jest to, że zmiany wprowadzane w górę strumienia ostatecznie trafiają do Androida. Dodatkowo Android używa jednego jądra na wszystkich urządzeniach. Na przykład poprawki są stosowane centralnie, a nie do wielu jąder dostawców.
Umożliwia to również SDV stabilny interfejs jądra. Możesz na przykład skompilować sterowniki jako moduły, które działają z GKI nawet wtedy, gdy zostanie wdrożone nowe jądro z poprawkami zabezpieczeń.
Jądro GKI ma stały harmonogram, a zmiany dostawców, które powinny stać się częścią następnego jądra GKI, należy przesłać do jądra systemu Linux do końca roku.
W przypadku GKI sterowniki urządzeń i moduły niewymagane do uruchomienia będą kompilowane jako moduły jądra i będą znajdować się w dysku RAM, który jest ładowany podczas wczesnego uruchamiania.Bardzo wczesne konfiguracje urządzeń, które nie mogą czekać na interfejs modułu jądra (np. inicjowanie losowe), muszą być wykonywane w drzewie urządzenia. Moduły jądra nie muszą być przesyłane do repozytorium upstream, ale muszą być kompilowane z interfejsami GKI.
Ponieważ SDV Core zakłada, że jest zbudowany na hipernadzorcy zgodnym z Virtio, sterowniki są dostarczane jako moduły jądra systemu Virtio, jeśli funkcja jest obsługiwana, lub jako inny otwarty standard (np. Open Profile for DICE i sterownik jądra systemu open-dice dla zaufania).
Połączenie Virtio (i otwartych standardów) z hiperwizorem prowadzi do abstrakcji sprzętowej. Dlatego w przypadku SDV potrzeba HAL jest minimalna, ale niektóre z nich są nadal wymagane ze względu na brak obsługi Virtio. Na przykład KeyMint HAL do kryptografii opartej na sprzęcie i powiązany z nim IRemotelyPrivisionedComponent HAL do atestowania między maszynami wirtualnymi SDV.
Stos sieciowy i komunikacyjny
Rysunek 3. SDV Core Networking and Communication Stack.
W przypadku sieci SDV Core zakłada, że do komunikacji między maszynami wirtualnymi dostępne są gniazda vsock lub Ethernet. Komunikacja wewnątrz maszyny wirtualnej może też korzystać z mechanizmów IPC, takich jak binder.
SDV obsługuje komunikację szeregową tylko na potrzeby debugowania.
Rysunek 4. Obsługa portu szeregowego SDV Core na potrzeby debugowania.
W ramach jednego gościa SDV udostępnia wiele opcji, które zależą od modelu komunikacji i wymagań dotyczących wydajności.
Vsock
Vsock to preferowany kanał komunikacji lokalnej między wieloma maszynami wirtualnymi lub hostem a maszyną wirtualną. Maszyny wirtualne powinny komunikować się ze sobą bezpośrednio za pomocą gniazd vsock, aby umożliwić optymalizację liczby kopii.
Pamięć współużytkowana
Pamięć współdzielona jest używana tylko do komunikacji z maszyną wirtualną w ramach IPC (komunikacji międzyprocesowej), ale nie jest oferowana jako zwykły kanał komunikacji między wieloma maszynami wirtualnymi. Host może używać pamięci współdzielonej do udostępniania informacji gościowi, ale nie jest ona przeznaczona do ruchu sieciowego o wysokiej częstotliwości.
Ethernet
Ethernet będzie używany do komunikacji między wieloma układami SoC, czyli do komunikacji w pojeździe. Mogą to być systemy wirtualne, ale także systemy natywne lub starsze ECU.
Sieć pojazdu jest wystarczająco mała, aby przestrzeń adresowa IPv4 wystarczyła do identyfikacji wszystkich dostępnych systemów. Aby jednak zapewnić zgodność systemu z potencjalnymi połączeniami wychodzącymi i przyszłym rozwojem, należy obsługiwać protokoły IPv4 i IPv6.
VLAN
Sieć VLAN to mechanizm tworzenia wirtualnych architektur sieciowych, który umożliwia izolowanie różnych podsieci i tworzenie sieci lokalnych. Można go używać do tworzenia różnych stref bezpieczeństwa, co jest wykorzystywane w samochodach. Wymagana jest obsługa sieci VLAN.
Protokoły
TCP i UDP
W zależności od zastosowania system wymaga niezawodnego lub szybkiego, ale mniej niezawodnego protokołu komunikacji. Dlatego protokoły TCP i UDP będą obsługiwane.
Tunel danych
Data Tunnel to nowo opracowany mechanizm komunikacji dla SDV, który oferuje szybki kanał komunikacji zgodny z modelem pubsub. Na przykład jedna aplikacja publikuje temat, a jedna lub więcej aplikacji może go nasłuchiwać. Wewnętrznie korzysta z pamięci współdzielonej i FMQ (szybkich kolejek wiadomości) w ramach maszyny wirtualnej lub z gniazd vsock albo Ethernetu do komunikacji między maszynami wirtualnymi.
RPC (SDV)
SDV RPC implementuje zdalne wywołania procedur dla SDV przy użyciu narzędzia Binder. Używa on predefiniowanego interfejsu API do wywoływania procedury zdalnej. Podobnie jak w przypadku tunelu danych, do komunikacji w ramach maszyny wirtualnej używana jest pamięć współdzielona, a do komunikacji między maszynami wirtualnymi – vsock lub Ethernet.
Platformy
SOMEIP
Protokół SOMEIP służy do komunikacji z systemami innymi niż SDV. Jest on oparty na protokołach TCP i UDP i nie wymaga specjalnego sprzętu ani sterowników. Google zaimplementuje odwołanie.
Agent wykrywania usług (SD Agent)
Zapewnia wykrywanie usług, uwierzytelnianie i autoryzację w przypadku SDV. Do komunikacji może używać dowolnej z wcześniej wymienionych metod. Na potrzeby uwierzytelniania i autoryzacji agent SD będzie potrzebować dostępu do sprzętu zabezpieczającego i działającego łańcucha zaufania.
Oprogramowanie pośredniczące
SDV opracowuje platformę, która upraszcza korzystanie z tych wszystkich protokołów. Nazywa się ona Middleware. Wprowadza też źródło informacji o wszystkich sygnałach pojazdu w nowym języku VSIDL.
Strefa neutralna
Aby odizolować części systemu i zapobiec atakom z mniej zaufanej części systemu (np. IVI z niestandardowymi zainstalowanymi aplikacjami), sieć może wprowadzić różne strefy, w tym strefy zdemilitaryzowane. W praktyce oznacza to, że podsieci są fizycznie lub logicznie odseparowane i tylko ruch z listy dozwolonych może przekraczać ich granice.
Menedżer połączeń
W Androidzie powszechną praktyką jest ograniczanie liczby aplikacji i usług, które mogą samodzielnie otwierać połączenia gniazdowe. Zamiast tego za otwieranie połączeń i zarządzanie nimi odpowiada centralna instancja. Ponieważ Android implementuje tę funkcję w usłudze Java, SDV utworzy własnego menedżera połączeń.
Możliwość aktualizacji
Kluczową cechą SDV jest możliwość aktualizacji. Nowe funkcje można instalować przez cały okres eksploatacji SDV za pomocą aktualizacji systemu Android i pakietów APEX.
Aktualizacje systemu Android
Android ma już mechanizm instalowania aktualizacji. W najnowszych wersjach korzysta z aktualizacji A/B i wirtualnych aktualizacji A/B, a SDV Core będzie wykorzystywać ten mechanizm. Aktualizacje A/B tworzą każdą partycję 2 razy, co daje 2 korzyści: system można aktualizować w tle, a jeśli aktualizacja się nie powiedzie, system może przywrócić ostatnią znaną wersję.
Pakiety APEX
Oprócz podzielenia systemu na wiele partycji i umożliwienia ich aktualizacji Android udostępnia też pakiety APEX, czyli mechanizm umieszczania aplikacji i bibliotek w małych pakietach, które można instalować i aktualizować niezależnie od aktualizacji systemu.
SDV Core będzie używać kontenerów APEX do dynamicznego instalowania usług na instancji SDV, a także do zarządzania wdrażaniem wielu usług w jednym procesie: tylko usługi, które są połączone w tym samym pakiecie APEX i używają tego samego certyfikatu, mogą być wdrażane w tym samym pliku binarnym, aby zmniejszyć ryzyko związane z bezpieczeństwem.
Mechanizm instalacji pakietów APEX na Androidzie wykorzystuje kod Java do zarządzania plikami APK w celu weryfikacji pakietów. SDV Core będzie musiało zaimplementować natywną alternatywę, aby umożliwić dynamiczną instalację pakietów APEX.
Zarządzanie aktualizacjami
Instancje SDV nie są w samochodzie w pełni niezależnymi jednostkami i wymagają koordynacji z innymi instancjami SDV i usługami samochodowymi. Na przykład w celu zainstalowania zależności usługi lub zapewnienia, że aktualizacje są instalowane tylko w bezpiecznym stanie systemu.
SDV rozważa użycie partycji na wielu maszynach wirtualnych. Wymaga to koordynacji między tymi maszynami wirtualnymi, ponieważ są one od siebie zależne pod względem danych: musi istnieć podstawowa maszyna wirtualna, która będzie aktualizować te partycje, oraz mechanizm powiadamiania innych maszyn wirtualnych o zaktualizowanej partycji i synchronizacji w celu jednoczesnego aktualizowania wszystkich maszyn wirtualnych, aby nie naruszyć poprzedniego znanego stanu działania.
Pierwsze kroki
W naszym przewodniku dla początkujących znajdziesz szczegółowe informacje o kodzie źródłowym, kompilowaniu i uruchamianiu za pomocą Cuttlefish.