Die Vehicle Hardware Abstraction Layer (VHAL)-Schnittstelle definiert die Eigenschaften, die OEMs implementieren können, und enthält Attributmetadaten (z. B. ob es sich um ein Int-Attribut handelt und welche Änderungsmodi zulässig sind). Die VHAL-Schnittstelle basiert auf dem Zugriff auf eine Property (Lesen, Schreiben, Abonnieren), die eine Abstraktion für eine bestimmte Funktion ist.
HAL-Schnittstellen
Die VHAL verwendet die folgenden Schnittstellen:
getAllPropConfigs()generiert(vec<VehiclePropConfig>propConfigs)
Listet die Konfiguration aller von der VHAL unterstützten Properties auf. Für CarService werden nur unterstützte Properties verwendet.getPropConfigs(vec<int32_t> props)generiert(StatusCode status,vec<VehiclePropConfig> propConfigs);
Gibt die Konfiguration der ausgewählten Properties zurück.set(VehiclePropValue propValue)generiert(StatusCodestatus);
Schreibt einen Wert in die Property. Das Ergebnis der Schreibvorgänge wird pro Property definiert.subscribe(IVehicleCallback callback, vec<SubscribeOptions> options)generiert(StatusCode status);
Überwachung einer Property-Wertänderung starten. Für eine Zoneneigenschaft wird mitunsubscribe(IVehicleCallback callback, int32_t propId)(StatusCode status);generiert.
Die VHAL verwendet die folgenden Callback-Schnittstellen:
oneway onPropertyEvent(vec<VehiclePropValue>propValues);
Benachrichtigt über die Änderung des Werts der Fahrzeugeigenschaft. Sollte nur für abonnierte Properties erfolgen.oneway onPropertySetError(StatusCode errorCode,int32_t propId,int32_tareaId);
Gibt einen globalen Fehler auf VHAL-Ebene oder einen Fehler pro Property zurück. Ein globaler Fehler führt zum Neustart der HAL, was zum Neustart anderer Komponenten (einschließlich Anwendungen) führen kann.
Fahrzeugeigenschaften
Properties können schreibgeschützt, nur lesbar (zum Übergeben von Informationen an die VHAL-Ebene) oder les- und schreibbar sein. Die Unterstützung der meisten Properties ist optional. Jede Property wird durch einen int32-Schlüssel eindeutig identifiziert und hat einen vordefinierten Typ (value_type):
BYTESBOOLEANEPOCH_TIMEFLOATFLOAT[]INT32INT32[]INT64INT64[]STRINGMIXED
Eine Zoneneigenschaft kann je nach Anzahl der von der Unterkunft unterstützten Zonen mehrere Werte haben.
Gebietstypen
Die VHAL definiert mehrere Gebietstypen:
| Gebietstyp | Beschreibung |
|---|---|
GLOBAL |
Diese Property ist ein Singleton und hat keine weiteren Bereiche. |
WINDOW |
Fensterbasierter Bereich, verwendet VehicleAreaWindow-Enum. |
MIRROR |
Gebiet basierend auf Spiegeln, verwendet VehicleAreaMirror-Enum. |
SEAT |
Bereich basierend auf Sitzplätzen, verwendet VehicleAreaSeat-Enum. |
DOOR |
Bereich basierend auf Türen, verwendet VehicleAreaDoor-Enum. |
WHEEL |
Fläche basierend auf Rädern, verwendet VehicleAreaWheel-Enum. |
Für jede Zoneneigenschaft muss ein vordefinierter Gebietstyp verwendet werden. Für jeden Gebietstyp gibt es eine Reihe von Bitflags, die in einem Enum für den Gebietstyp definiert sind. Für den Bereich SEAT werden beispielsweise VehicleAreaSeat-Enume definiert:
ROW_1_LEFT = 0x0001ROW_1_CENTER = 0x0002ROW_1_RIGHT = 0x0004ROW_2_LEFT = 0x0010ROW_2_CENTER = 0x0020ROW_2_RIGHT = 0x0040ROW_3_LEFT = 0x0100- …
Gebiets-IDs
Zonenspezifische Properties werden über Gebiets-IDs adressiert. Jedes unterteilte Hotel kann eine oder mehrere Gebiets-IDs unterstützen. Eine Regions-ID besteht aus einem oder mehreren Flags aus dem entsprechenden Enum. Für eine Property mit VehicleAreaSeat können beispielsweise die folgenden Gebiets-IDs verwendet werden:
| Artikel | Beschreibung |
|---|---|
ROW_1_LEFT | ROW_1_RIGHT |
Die Zonen-ID gilt für beide Vordersitze. |
ROW_2_LEFT |
Gilt nur für den linken Rücksitz. |
ROW_2_RIGHT |
Gilt nur für den rechten Rücksitz. |
Unterkunftsstatus
Jeder Attributwert hat einen VehiclePropertyStatus-Wert.
Hier sehen Sie den aktuellen Status der Property:
| Artikel | Beschreibung |
|---|---|
AVAILABLE |
Die Property ist verfügbar und der Wert ist gültig. |
UNAVAILABLE |
Der Wert der Unterkunft ist derzeit nicht verfügbar. Wird für vorübergehend deaktivierte Funktionen für eine unterstützte Property verwendet. |
ERROR |
Mit dieser Unterkunft stimmt etwas nicht. |
Property konfigurieren
Verwenden Sie VehiclePropConfig, um Konfigurationsinformationen für jede Property anzugeben. Zu den Informationen gehören:
| Variable | Beschreibung |
|---|---|
access |
r, w, rw |
changeMode |
Gibt an, wie eine Property überwacht wird: bei Änderungen oder kontinuierlich. |
areaConfigs |
areaId, min und max |
configArray |
Zusätzliche Konfigurationsparameter. |
configString |
Zusätzliche Informationen, die als String übergeben werden. |
minSampleRate |
maxSampleRate |
prop |
Property-ID, int |
Zoneneigenschaften verarbeiten
Eine Zonen-Property entspricht einer Sammlung mehrerer Properties, auf die über den angegebenen Wert der Gebiets-ID zugegriffen werden kann.
- Der
get-Aufruf für eine Zoneneigenschaft enthält immer die Gebiets-ID in der Anfrage. Daher wird nur der aktuelle Wert für die angeforderte Gebiets-ID zurückgegeben. Wenn es sich um eine globale Property handelt, ist die Gebiets-ID 0. - Der
set-Aufruf für eine Zoneneigenschaft enthält immer die Gebiets-ID in der Anfrage. Daher wird nur die angeforderte Gebiets-ID geändert. - Bei einem
subscribe-Aufruf werden Ereignisse für alle Gebiets-IDs der Property generiert.
Anrufe erhalten
Während der Initialisierung ist der Wert für die Property möglicherweise noch nicht verfügbar, da die entsprechende Nachricht des Fahrzeugnetzwerks noch nicht empfangen wurde. In solchen Fällen sollte der get-Aufruf -EAGAIN zurückgeben. Einige Unterkünfte (z. B. HLK) haben ein separates Attribut für Ein-/Ausschalten. Wenn get für eine solche Eigenschaft aufgerufen wird, sollte bei ausgeschaltetem Gerät ein UNAVAILABLE-Status zurückgegeben werden, anstatt einen Fehler. Beispiel: HLK-Temperatur abrufen
Abbildung 1 HLK-Temperatur abrufen (CS = CarService, VHAL = Vehicle HAL)
Anrufe
Bei einem normalen Vorgang führt ein set-Aufruf zu einer Änderungsanfrage im gesamten Fahrzeugnetzwerk. Ein set-Aufruf ist idealerweise ein asynchroner Vorgang, der so schnell wie möglich zurückgegeben wird. Er kann aber auch synchron sein. Für einige set-Aufrufe müssen möglicherweise anfängliche Daten verfügbar sein. Während der Initialisierung sind diese Daten jedoch möglicherweise noch nicht verfügbar. In solchen Fällen sollte der set-Aufruf StatusCode#TRY_AGAIN zurückgeben. Bei einigen Unterkünften mit separatem Ein- und Ausschalten sollte StatusCode#NOT_AVAILABLE oder StatusCode#NOT_AVAILABLE_DISABLED zurückgegeben werden, wenn die Unterkunft ausgeschaltet ist und set nicht durchgeführt werden kann. Bis set wirksam wird, gibt get nicht unbedingt den festgelegten Wert zurück. Beispiel: set HVAC Temperature.
Abbildung 2: HLK-Temperatur festlegen (CS = CarService, VHAL = Vehicle HAL)
Umgang mit benutzerdefinierten Properties
Zur Unterstützung partnerspezifischer Anforderungen sind in der VHAL benutzerdefinierte Properties zulässig, die auf System-Apps beschränkt sind. Beachten Sie beim Arbeiten mit benutzerdefinierten Properties die folgenden Richtlinien:
- Die Property-ID sollte mit den folgenden Feldern generiert werden:
VehiclePropertyGroup:VENDOR
Die GruppeVENDORwird nur für benutzerdefinierte Properties verwendet.VehicleArea
Wählen Sie einen geeigneten Gebietstyp aus.VehiclePropertyType
Wählen Sie den richtigen Datentyp aus. DerBYTES-Typ ermöglicht die Weitergabe von Rohdaten, was in den meisten Fällen ausreicht. Wenn Sie häufig Big Data über benutzerdefinierte Properties senden, kann das den Zugriff auf das gesamte Fahrzeugnetzwerk verlangsamen. Seien Sie daher vorsichtig, wenn Sie eine große Nutzlast hinzufügen.Property ID
Wählen Sie eine vierstellige Nibble-ID für die benutzerdefinierte Property aus.
- Um eine Fragmentierung des Werbesystems zu vermeiden, dürfen benutzerdefinierte Properties nicht verwendet werden, um Fahrzeugeigenschaften zu replizieren, die bereits im SDK (VehiclePropertyIds) vorhanden sind.
- Geben Sie unter
VehiclePropConfig.configStringeine kurze Beschreibung der benutzerdefinierten Property ein. So können Tools zur Plausibilitätsprüfung die versehentliche Replikation vorhandener Fahrzeugeigenschaften melden. Beispiel: „Stand der Warnblinkanlage“ - Zugriff über
CarPropertyManager(für Java-Komponenten) oder über die Vehicle Network Service API (für native Apps). Ändern Sie keine anderen Auto-APIs, da dies zu zukünftigen Kompatibilitätsproblemen führen kann. - Wählen Sie nach der Implementierung von Anbieter-Properties nur die Berechtigungsliste im
VehicleVendorPermission-Enum für Anbieter-Properties aus. Wenn Sie Anbieterberechtigungen Systemeigenschaften zuordnen, funktionieren CTS und VTS nicht mehr.
Umgang mit HLK-Eigenschaften
Sie können die VHAL verwenden, um die HLK zu steuern, indem Sie HLK-bezogene Eigenschaften festlegen. Die meisten HLK-Properties sind Zonen-Properties, einige sind jedoch nicht zoniert (global). Beispiele für definierte Properties:
| Attribut | Zweck |
|---|---|
VEHICLE_PROPERTY_HVAC_TEMPERATURE_SET |
Temperatur pro Zone festlegen |
VEHICLE_PROPERTY_HVAC_RECIRC_ON |
Umwälzung pro Zone steuern |
Eine vollständige Liste der HLK-Properties finden Sie in types.hal unter VEHICLE_PROPERTY_HVAC_*. Wenn für die HLK-Property VehicleAreaSeat verwendet wird, gelten zusätzliche Regeln für die Zuordnung einer HLK-Property mit Zonen zu Gebiets-IDs. Jeder verfügbare Sitz im Auto muss Teil einer Bereichs-ID im Bereichs-ID-Array sein.
Beispiel 1 Ein Auto hat zwei Vordersitze (ROW_1_LEFT, ROW_1_RIGHT) und drei Rücksitze (ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT). Es hat zwei Temperaturregler: auf der Fahrer- und der Beifahrerseite.
- Ein gültiger Zuordnungssatz von Gebiets-IDs für
HVAC_TEMPERATURE SETist:ROW_1_LEFT | ROW_2_LEFTROW_1_RIGHT | ROW_2_CENTER | ROW_2_RIGHT
- Eine alternative Zuordnung für dieselbe Hardwarekonfiguration ist:
ROW_1_LEFT | ROW_2_LEFT | ROW_2_CENTERROW_1_RIGHT | ROW_2_RIGHT
Beispiel 2 Ein Auto hat drei Sitzreihen mit zwei Sitzen in der ersten Reihe (ROW_1_LEFT, ROW_1_RIGHT), drei Sitzen in der zweiten Reihe (ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT) und drei Sitzen in der dritten Reihe (ROW_3_LEFT, ROW_3_CENTER, ROW_3_RIGHT). Das Auto hat drei Temperaturregler: Fahrerseite, Beifahrerseite und Rückseite. Eine sinnvolle Möglichkeit, HVAC_TEMPERATURE_SET zu Gebiets-IDs zuzuordnen, ist ein Array mit drei Elementen:
ROW_1_LEFTROW_1_RIGHTROW_2_LEFT | ROW_2_CENTER | ROW_2_RIGHT | ROW_3_LEFT | ROW_3_CENTER | ROW_3_RIGHT
Umgang mit Sensoreigenschaften
VHAL-Sensoreigenschaften stellen echte Sensordaten oder Richtlinieninformationen wie den Fahrstatus dar. Auf einige Sensorinformationen (z. B. den Fahrstatus und den Tag-/Nachtmodus) kann jede App uneingeschränkt zugreifen, da diese Daten für die Entwicklung einer sicheren Fahrzeug-App erforderlich sind. Andere Sensordaten (z. B. die Fahrzeuggeschwindigkeit) sind sensibler und erfordern bestimmte Berechtigungen, die Nutzer verwalten können.
Siehe die unterstützten Sensoreigenschaften (in types.hal).
Fahrzeugkartendienst
Der Fahrzeugkartendienst (Vehicle Map Service, VMS) bietet einen Mechanismus zum Austausch von Kartendaten zwischen Clients über eine Pub/Sub-Schnittstelle, um gängige Fahrzeugfunktionen wie erweiterte Fahrerassistenzsysteme (Advanced Driver Assistance Systems, ADAS) zu unterstützen. Clients können Fahrzeugsysteme umfassen, die über die VMS-Eigenschaft in der VHAL oder über privilegierte Android-Anwendungen kommunizieren. Die über den VMS freigegebenen Daten sollen sich auf Kartendaten für die Verwendung durch Fahrzeugsysteme und unterstützende Apps beschränken.
Der Fahrzeugkartendienst ist nur für Android Automotive-Implementierungen vorgesehen. AOSP enthält keine Standardclients, die den Fahrzeugkartendienst veröffentlichen oder abonnieren. Für die VMS-Eigenschaft in der VHAL werden die Nachrichtentypen und Datenstrukturen in VHAL 2.0 im Enum VmsMessageType beschrieben, in dem die Typen der unterstützten VMS-Nachrichten aufgeführt sind. Dieser Enum wird als erste Ganzzahl im Array der Ganzzahlen der Fahrzeugeigenschaft verwendet und bestimmt, wie der Rest der Nachricht decodiert wird.