Przemysł motoryzacyjny przechodzi od architektury wielu zdecentralizowanych jednostek obliczeniowych do architektury, która łączy wiele funkcji w kilku scentralizowanych jednostkach obliczeniowych, co umożliwia korzystanie z nowych funkcji, takich jak aktualizacje bezprzewodowe.
AAOS SDV wykorzystuje istniejący system i infrastrukturę Androida, aby zaoferować rozwiązanie. Ponadto producenci OEM szukają rozwiązań, które można uruchamiać w chmurze, ponieważ ułatwia to wczesny rozwój i umożliwia nowe testy.
Projektowanie
Rysunek 1. Architektura SDV Core.
AAOS for SDV Core (SDV Core) to system operacyjny oparty na Androidzie. Ze względu na swój wbudowany charakter nie implementuje stosu JVM Androida, ale wszystkie funkcje systemu są rozwijane natywnie.
SDV Core jest rozwijany głównie z myślą o środowisku zwirtualizowanym, a niektóre decyzje projektowe zakładają taką integrację. Można jednak uruchomić SDV Core natywnie, ale wymaga to większej ilości pracy integracyjnej w porównaniu z innymi wersjami Androida.
SDV Core jest przeznaczony do lokalnego systemu rozproszonego, co oznacza, że zakłada, że wiele instancji SDV Core (lub pochodnych) działa obok siebie na tym samym chipie lub w wielu systemach i mogą się one komunikować przez połączenie sieciowe. Dlatego podstawowym aspektem architektury systemu jest implementacja funkcji jako usług, które mogą być hostowane 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, i pozwala obniżyć koszty.
Szczegółowy projekt
Rysunek 2. Szczegółowa architektura SDV Core.
SDV Core pochodzi z Androida, dlatego jego architektura stara się jak najlepiej dopasować do Androida. Zasadniczo oznacza to, że SDV Core korzysta również z GKI, sterowników, HAL i bibliotek podstawowych z Androida oraz dodaje komponenty wymagane do architektury usługi.
W następnych sekcjach szczegółowo omówimy komponenty systemu.
Środowisko hosta i wirtualizacja
SDV Core jest rozwijany z założeniem, że będzie działać w środowisku wirtualnym, dlatego przyjmujemy pewne założenia dotyczące środowiska hosta:
W środowisku hosta działa hipernadzorca, który obsługuje urządzenia Virtio. Dodatkowo hipernadzorca musi implementować Ethernet lub vsock, stany zasilania i urządzenia blokowe. Ponadto hipernadzorca musi obsługiwać system Android/Linux.
Jeśli chodzi o sprzęt, SDV Core zakłada, że procesor i jednostka MMU obsługują wirtualizację sprzętową, a system jest połączony przez Ethernet. System nie musi mieć GPU, IPU, CSI, silników multimedialnych, wyświetlacza ani innych magistrali komunikacyjnych dla motoryzacji (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 również z GKI, natywnych usług systemowych (np. adbd i logd) oraz funkcji systemowych, ale nie obejmuje JVM, 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 zabezpieczeń, ale nie ma interfejsu GUI.
GKI, sterowniki i HAL
SDV Core korzysta z jądra GKI Androida z jądrem Androida 6.1. Zaletą korzystania z GKI jest to, że zmiany wprowadzane w kodzie nadrzędnym 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.
Dzięki temu SDV może mieć stabilny interfejs jądra. Możesz na przykład skompilować sterowniki jako moduły, które współpracują z GKI nawet wtedy, gdy wdrożone jest nowe jądro z poprawkami zabezpieczeń.
Jądro GKI ma stały harmonogram. Zmiany dostawcy, które powinny stać się częścią następnego jądra GKI, powinny zostać przesłane do jądra Linuksa do końca roku.
W przypadku GKI sterowniki urządzeń i moduły niewymagane do rozruchu będą kompilowane jako moduły jądra systemu i będą zawarte w dysku RAM, który jest ładowany podczas wczesnego rozruchu.Bardzo wczesne konfiguracje urządzeń, które nie mogą czekać na interfejs modułu jądra systemu (np. losowa inicjalizacja), muszą być wykonywane w drzewie urządzeń. Moduły jądra systemu nie muszą być przesyłane do upstreamu, 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 ta funkcja jest obsługiwana, lub jako inny otwarty standard (np. Open Profile dla DICE i sterownik jądra systemu open-dice dla zaufania).
To połączenie Virtio (i otwartych standardów) oraz hipernadzorcy prowadzi do abstrakcji sprzętowej. Dlatego potrzeba stosowania HAL w SDV jest minimalna, ale niektóre z nich są nadal wymagane ze względu na brak obsługi Virtio. Na przykład interfejs HAL KeyMint do kryptografii wspieranej sprzętowo i ściśle powiązany z nim interfejs HAL IRemotelyPrivisionedComponent do atestacji między maszynami wirtualnymi SDV.
Stos sieciowy i komunikacyjny
Rysunek 3. Podstawowy stos sieciowy i komunikacyjny SDV.
W przypadku sieci SDV Core zakłada, że do komunikacji między maszynami wirtualnymi dostępne są 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 systemu operacyjnego 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 i maszyną wirtualną. Maszyny wirtualne powinny używać bezpośredniej komunikacji vsock między sobą, aby umożliwić implementacji optymalizację liczby kopii.
Pamięć współużytkowana
Pamięć współdzielona jest używana tylko do komunikacji z maszyną wirtualną na potrzeby IPC (komunikacji między procesami), ale nie jest oferowana jako zwykły kanał do komunikacji między wieloma maszynami wirtualnymi. Host może używać pamięci współdzielonej do udostępniania informacji systemowi gościa, ale nie jest to przeznaczone do obsługi ruchu w sieci o wysokiej częstotliwości.
Ethernet
Ethernet jest używany do komunikacji między wieloma układami SoC, czyli do komunikacji w pojeździe. Mogą to być systemy zwirtualizowane, ale też systemy natywne lub starsze ECU.
Sieć pojazdu jest na tyle mała, że przestrzeń adresowa IPv4 wystarcza do zidentyfikowania wszystkich dostępnych systemów. Aby jednak zapewnić zgodność systemu z potencjalnymi połączeniami nadrzędnymi i przyszłymi rozwiązaniami, należy obsługiwać protokoły IPv4 i IPv6.
VLAN
VLAN to mechanizm tworzenia architektur sieci wirtualnych, który umożliwia izolowanie różnych podsieci i tworzenie sieci lokalnych. Można go używać do tworzenia różnych stref bezpieczeństwa i jest on używany w tym celu w samochodach. Wymagana jest obsługa sieci VLAN.
Protokoły
TCP i UDP
W zależności od przypadku użycia system wymaga niezawodnego lub zawodnego, ale szybkiego protokołu komunikacyjnego. Dlatego obsługiwane będą protokoły TCP i UDP.
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 słuchać. Wewnętrznie wykorzystuje pamięć współdzieloną i FMQ (szybkie kolejki wiadomości) w maszynie wirtualnej lub vsock albo Ethernet do komunikacji między maszynami wirtualnymi.
(SDV) RPC
SDV RPC implementuje zdalne wywołania procedur dla SDV z wykorzystaniem bindera. Używa wstępnie zdefiniowanego interfejsu API do wywoływania procedury zdalnej. Podobnie jak Data Tunnel, używa pamięci współdzielonej do komunikacji w maszynie wirtualnej lub vsock albo Ethernetu do komunikacji między maszynami wirtualnymi.
Platformy
SOMEIP
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 wdroży plik referencyjny.
Agent wykrywania usług (agent SD)
Zapewnia wykrywanie usług, uwierzytelnianie i autoryzację w SDV. Do komunikacji może używać dowolnej z wymienionych wcześniej metod. Do 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 ze wszystkich tych różnych protokołów, zwaną oprogramowaniem pośredniczącym. Implementuje też źródło informacji dla wszystkich sygnałów pojazdu z nowym językiem VSIDL.
Strefa neutralna
Aby odizolować części systemu i zapobiec atakom z mniej zaufanej części systemu (np. samochodowego systemu multimedialnego z niestandardowymi aplikacjami instalowanymi), sieć może wprowadzić różne strefy, w tym strefy zdemilitaryzowane. W praktyce oznacza to, że podsieci są fizycznie lub logicznie odseparowane, a przez te granice może przechodzić tylko ruch z listy dozwolonych.
Menedżer połączeń
W systemie Android powszechną praktyką jest ograniczanie liczby aplikacji i usług, które mogą samodzielnie otwierać połączenia gniazd. 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ą funkcją 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 używa aktualizacji A/B i wirtualnych aktualizacji A/B, a SDV Core będzie korzystać z tego mechanizmu. Aktualizacje A/B tworzą każdą partycję dwukrotnie, 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ą działającą wersję.
Pakiety APEX
Oprócz podziału 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 w instancji SDV, ale także do zarządzania wdrażaniem wielu usług w jednym procesie: tylko usługi, które są połączone w tym samym 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 Androida do instalowania pakietów APEX wykorzystuje kod Java do zarządzania pakietami APK w celu weryfikacji pakietów. SDV Core będzie musiał wdrożyć natywną alternatywę, aby umożliwić dynamiczną instalację pakietów APEX.
Zarządzanie aktualizacjami
Instancje SDV nie są w pełni niezależnymi jednostkami w samochodzie i wymagają koordynacji z innymi instancjami SDV i usługami samochodowymi. Na przykład po to, aby zainstalować zależności usług lub upewnić się, ż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 zależne od danych: musi istnieć podstawowa maszyna wirtualna do aktualizowania tych partycji oraz mechanizm powiadamiania innych maszyn wirtualnych o zaktualizowanej partycji i synchronizacji w celu aktualizowania wszystkich maszyn wirtualnych w tym samym czasie, aby zapewnić, że poprzedni znany stan działania nie zostanie przerwany.
Pierwsze kroki
W naszym przewodniku dla początkujących znajdziesz szczegółowe informacje o kodzie źródłowym, kompilowaniu i uruchamianiu za pomocą Cuttlefish.