Display Safety steruje kontrolerami domeny i umożliwia systemowi Android obsługę wszystkich wyświetlaczy w samochodzie, w tym tych, które muszą spełniać wymagania dotyczące bezpieczeństwa i dostępności.
Rysunek 1. Przegląd klastra.
Powiązane informacje
Więcej informacji o GitHub znajdziesz w artykule Automotive Design for Compose.
Terminologia
- Platforma
- Połączenie sprzętu, hiperwizora, systemu operacyjnego i powiązanych bibliotek.
- Monitor bezpieczeństwa
- Aplikacja do monitorowania stanu pojazdu i sprawdzania, czy odpowiednie informacje wizualne są wyświetlane użytkownikowi zgodnie z oczekiwaniami.
Komponenty Display Safety
Oprogramowanie Display Safety składa się z 3 głównych komponentów:
DriverUI: aplikacja systemowa Androida, która renderuje cały wyświetlacz zestawu wskaźników, z wyłączeniem elementów bezpieczeństwa lub elementów regulacyjnych renderowanych przez HAR.
Renderer o wysokiej dostępności (HAR): proces zarządzania jakością, który renderuje elementy wyświetlacza, które muszą być widoczne szybko po zimnym rozruchu, oraz elementy zastępcze, gdy Android jest niedostępny. HAR jest przenośny i koncentruje się na najważniejszych informacjach dotyczących jazdy.
Łańcuch narzędzi do projektowania bezpieczeństwa: zestaw narzędzi do generowania konfiguracji implementacji monitora bezpieczeństwa na podstawie źródła projektu, aby osiągnąć odpowiednie cele bezpieczeństwa ASIL-B.
Wszystkie komponenty używają łańcucha narzędzi do projektowania, Automotive Design for Compose, aby sprawdzić, czy zostały utworzone na podstawie tej samej definicji projektu OEM.
Rysunek 2. Komponenty Display Safety.
Renderer o wysokiej dostępności
HAR jest napisany w języku Rust i składa się z tych komponentów:
Warstwa abstrakcji platformy (PAL). Abstrakcja do interfejsu z wieloma podsystemami, w tym grafiką, kamerą, dźwiękiem, danymi wejściowymi użytkownika (np. elementami sterującymi na kierownicy), danymi pojazdu (zwanymi też sygnałami lub właściwościami), konfiguracją pojazdu (np. benzynowym lub elektrycznym, z kierownicą po lewej lub prawej stronie) oraz preferencjami użytkownika (np. km/h i mph).
Implementacja PAL dla docelowej platformy.
Aplikacja HAR opracowana za pomocą PAL.
Google definiuje PAL i udostępnia implementacje referencyjne PAL oraz aplikacji HAR. Referencyjna aplikacja HAR zawiera wszystkie elementy składowe i pętlę główną. Producenci OEM powinni dostosować implementację PAL i aplikację HAR do swoich wymagań. HAR używa do renderowania Impeller.
Więcej informacji znajdziesz w tych artykułach:
DriverUI
Interfejs użytkownika klastra jest zwykle umieszczony za kierownicą na osobnym wyświetlaczu. Producenci OEM stopniowo łączą klaster i IVI. Ten połączony interfejs użytkownika to DriverUI.
DriverUI to aplikacja systemowa Androida, która renderuje cały wyświetlacz zestawu wskaźników, z wyłączeniem elementów bezpieczeństwa lub elementów regulacyjnych renderowanych przez HAR. DriverUI wyświetla informacje związane z odtwarzaniem multimediów, połączeniami telefonicznymi, mapami, nawigacją i innymi elementami. Jest implementowany za pomocą Automotive Design for Compose.
AAOS ma 2 interfejsy API do tworzenia zestawów wskaźników. Interfejs API zestawów wskaźników (zwany też Cluster 1) jest w trybie konserwacji. Zachęcamy producentów OEM do przejścia na interfejs API ClusterHomeManager (zwany też Cluster 2).
Google udostępnia implementacje referencyjne interfejsów API Cluster 1 i Cluster 2.
Więcej informacji znajdziesz w artykule DriverUI.
Łączenie danych wyjściowych HAR i DriverUI
HAR i DriverUI używają osobnych wyświetlaczy do renderowania interfejsu użytkownika. Oba dane wyjściowe są łączone i wyświetlane jako jeden obraz w DriverUI.
Aby to osiągnąć, HAR kontroluje przezroczystość obszarów, w których wyświetlają się dane wyjściowe Androida, na podstawie okresowych komunikatów o stanie wysyłanych przez DriverUI, które wskazują, że jest on uruchomiony.
Gdy DriverUI nie jest uruchomiony, HAR wykrywa brak komunikatów o stanie i renderuje obszary DriverUI jako nieprzezroczyste oraz wyświetla elementy zastępcze. Gdy komunikaty o stanie są odbierane, HAR usuwa elementy zastępcze i ustawia obszary DriverUI jako przezroczyste.
DriverUI i HAR komunikują się ze sobą za pomocą zdalnych wywołań procedur (RPC). Komunikat o stanie jest przykładem danych wysyłanych przez kanał RPC i zawiera sygnaturę czasową jako jedno z pól.
Do RPC używany jest gRPC. W SDV stos komunikacyjny SDV udostępnia klienta bramy SDV do wykrywania i ustanawiania kanału z DriverUI do HAR.
Rysunek 3. Kompozycja HAR i DriverUI.
Łańcuch narzędzi do projektowania bezpieczeństwa
Łańcuch narzędzi do projektowania bezpieczeństwa to seria narzędzi, których producent OEM może używać w kolejności do dostarczania rozwiązania monitora bezpieczeństwa wygenerowanego na podstawie dokumentu projektu Figma.
Kompilator projektu bezpieczeństwa tworzy artefakty bezpieczeństwa, które umożliwiają dalsze generowanie kodu na potrzeby tworzenia monitora bezpieczeństwa. Ten podział między kompilacją projektu a generowaniem kodu umożliwia uzyskanie przez używany generator kodu oceny ISO-26262 TCL-3.
Rysunek 4. Korzystanie z łańcucha narzędzi do projektowania bezpieczeństwa.
Po wygenerowaniu artefaktów kompilatora łańcuch narzędzi może wygenerować raport czytelny dla człowieka. Ten raport to plik, który inżynier ds. bezpieczeństwa OEM może sprawdzić, aby zweryfikować artefakty wygenerowane na podstawie projektu Figma.
Google udostępnia implementację referencyjną monitora bezpieczeństwa, która nie ma certyfikatu ASIL. Producenci OEM powinni dostosować monitor bezpieczeństwa do swoich wymagań i uzyskać certyfikat implementacji.
Więcej informacji znajdziesz w artykule Łańcuch narzędzi do projektowania bezpieczeństwa.
Display Safety w SDV
Możesz tworzyć i uruchamiać Display Safety w SDV. SDV jest w pełni funkcjonalny i używa 2 maszyn wirtualnych gościa do uruchamiania pełnego klastra Display Safety.
Software Defined Vehicle
Software Defined Vehicle (SDV) z systemem operacyjnym Android Automotive (AAOS):
- Wymaga 2 maszyn wirtualnych gościa, aby wyświetlić cały klaster.
- Uruchamia HAR w SDV Media (znanym też jako maszyna wirtualna szybkiego rozruchu) w maszynie wirtualnej gościa.
- Uruchamia DriverUI w osobnej maszynie wirtualnej gościa, która uruchamia maszynę wirtualną SDV-IVI.