Fahrzeugeigenschaften

Die Schnittstelle Vehicle Hardware Abstraction Layer (VHAL) definiert die Eigenschaften, die OEMs implementieren können, und enthält Eigenschaftsmetadaten (z. B. ob die Eigenschaft ein int ist und welche Änderungsmodi zulässig sind). Die VHAL-Schnittstelle basiert auf dem Zugriff (Lesen, Schreiben, Abonnieren) einer Eigenschaft, die eine Abstraktion für eine bestimmte Funktion darstellt.

HAL-Schnittstellen

Die VHAL verwendet die folgenden Schnittstellen:

• getAllPropConfigs() erzeugt (vec<VehiclePropConfig>propConfigs)
  Listen Sie die Konfiguration aller Eigenschaften auf, die von der VHAL unterstützt werden. CarService verwendet nur unterstützte Eigenschaften.
• getPropConfigs(vec<int32_t> props) generiert (StatusCode status,vec<VehiclePropConfig> propConfigs);
  Gibt die Konfiguration ausgewählter Eigenschaften zurück.
• set(VehiclePropValue propValue) erzeugt (StatusCodestatus);
  Schreiben Sie einen Wert in Eigenschaft. Das Ergebnis des Schreibens wird pro Eigenschaft definiert.
• subscribe(IVehicleCallback callback, vec<SubscribeOptions> options) generiert (StatusCode status);
  Beginnen Sie mit der Überwachung einer Eigenschaftswertänderung. Für gezonte Eigenschaften generiert unsubscribe(IVehicleCallback callback, int32_t propId) (StatusCode status);

Die VHAL verwendet die folgenden Callback-Schnittstellen:

• oneway onPropertyEvent(vec<VehiclePropValue>propValues);
  Benachrichtigt die Wertänderung des Fahrzeugs. Sollte nur für abonnierte Eigenschaften durchgeführt werden.
• oneway onPropertySetError(StatusCode errorCode,int32_t propId,int32_tareaId);
  Geben Sie einen globalen Fehler auf VHAL-Ebene oder einen Fehler pro Eigenschaft zurück. Ein globaler Fehler führt zu einem Neustart des HAL, was zum Neustart anderer Komponenten (einschließlich Anwendungen) führen kann.

Fahrzeugeigenschaften

Eigenschaften können schreibgeschützt, schreibgeschützt (zur Weitergabe von Informationen an die VHAL-Ebene) oder schreib- und lesbar sein (die Unterstützung der meisten Eigenschaften ist optional). Jede Eigenschaft wird eindeutig durch einen int32-Schlüssel identifiziert und hat einen vordefinierten Typ ( value_type ):

• BYTES
• BOOLEAN
• EPOCH_TIME
• FLOAT
• FLOAT[]
• INT32
• INT32[]
• INT64
• INT64[]
• STRING
• MIXED

Eine Zoneneigenschaft kann mehr als einen Wert haben, basierend auf der Anzahl der Zonen, die von der Eigenschaft unterstützt werden.

Gebietstypen

Die VHAL definiert mehrere Bereichstypen:

Jedes Zonengrundstück muss einen vordefinierten Flächentyp verwenden. Jeder Bereichstyp hat einen Satz von Bitflags, die in einer Aufzählung für den Bereichstyp definiert sind. Beispielsweise definiert der SEAT Bereich VehicleAreaSeat Aufzählungen:

• ROW_1_LEFT = 0x0001
• ROW_1_CENTER = 0x0002
• ROW_1_RIGHT = 0x0004
• ROW_2_LEFT = 0x0010
• ROW_2_CENTER = 0x0020
• ROW_2_RIGHT = 0x0040
• ROW_3_LEFT = 0x0100
• ...

Bereichs-IDs

In Zonen unterteilte Grundstücke werden über Bereichs-IDs adressiert. Jedes in Zonen aufgeteilte Grundstück kann eine oder mehrere Bereichs-IDs unterstützen. Eine Bereichs-ID besteht aus einem oder mehreren Flags aus ihrer jeweiligen Aufzählung. Beispielsweise könnte eine Eigenschaft, die VehicleAreaSeat verwendet, die folgenden Bereichs-IDs verwenden:

Eigentumsstatus

Jeder Eigenschaftswert enthält einen VehiclePropertyStatus Wert. Dies zeigt den aktuellen Status für die Eigenschaft an:

Konfigurieren einer Eigenschaft

Verwenden Sie VehiclePropConfig , um Konfigurationsinformationen für jede Eigenschaft bereitzustellen. Zu den Informationen gehören:

Umgang mit Zoneneigenschaften

Eine Zoneneigenschaft entspricht einer Sammlung mehrerer Eigenschaften, wobei auf jede Untereigenschaft mit dem angegebenen Bereichs-ID-Wert zugegriffen werden kann.

• get call for zoned property enthält immer die Bereichs-ID in der Anforderung. Daher wird nur der aktuelle Wert für die angeforderte Bereichs-ID zurückgegeben. Wenn es sich um eine globale Eigenschaft handelt, ist die Bereichs-ID 0.
• set call for zoned property enthält immer die Bereichs-ID in der Anforderung. Daher wird nur die angeforderte Bereichs-ID geändert.
• Der Aufruf subscribe generiert Ereignisse für alle Bereichs-IDs für die Eigenschaft.

Anrufe erhalten

Während der Initialisierung ist der Wert für die Eigenschaft möglicherweise noch nicht verfügbar, da die passende Fahrzeugnetzwerknachricht noch nicht empfangen wurde. In solchen Fällen sollte der get Aufruf -EAGAIN zurückgeben. Einige Eigenschaften (z. B. HVAC) haben eine separate Ein-/Aus-Leistungseigenschaft. Der Aufruf von get für eine solche Eigenschaft (im ausgeschalteten Zustand) sollte einen Status UNAVAILABLE zurückgeben, anstatt einen Fehler zurückzugeben. Rufen Sie beispielsweise die HLK-Temperatur ab

Abbildung 1 . Holen Sie sich die HVAC-Temperatur (CS = CarService, VHAL = Vehicle HAL)

Anrufe einstellen

Bei einer typischen Operation führt ein set Anruf dazu, dass eine Änderungsanforderung über das Fahrzeugnetzwerk gestellt wird. Ein set Aufruf ist idealerweise eine asynchrone Operation, die so schnell wie möglich zurückkehrt, aber er kann auch synchron sein. Einige set Aufrufe erfordern möglicherweise, dass anfängliche Daten bereit sind, aber während der Initialisierung sind solche Daten möglicherweise noch nicht verfügbar. In solchen Fällen sollte der set Aufruf StatusCode#TRY_AGAIN zurückgeben. Einige Eigenschaften mit separatem Ein- und Ausschalten sollten StatusCode#NOT_AVAILABLE oder StatusCode#NOT_AVAILABLE_DISABLED zurückgeben, wenn die Eigenschaft ausgeschaltet ist und set nicht durchgeführt werden kann. Bis set wirksam gemacht wird, gibt get nicht unbedingt den gleichen Wert wie set zurück. set HVAC Temperature .

Abbildung 2 . HVAC-Temperatur einstellen (CS = CarService, VHAL = Vehicle HAL)

Umgang mit benutzerdefinierten Eigenschaften

Um partnerspezifische Anforderungen zu unterstützen, lässt die VHAL benutzerdefinierte Eigenschaften zu, die auf System-Apps beschränkt sind. Verwenden Sie die folgenden Richtlinien, wenn Sie mit benutzerdefinierten Eigenschaften arbeiten:

• Die Property-ID sollte mithilfe der folgenden Felder generiert werden:
  • VehiclePropertyGroup:VENDOR
    Die VENDOR Gruppe wird nur für benutzerdefinierte Eigenschaften verwendet.
  • VehicleArea
    Wählen Sie einen geeigneten Bereichstyp aus.
  • VehiclePropertyType
    Wählen Sie den richtigen Datentyp aus. Der Typ BYTES erlaubt die Übergabe von Rohdaten, was in den meisten Fällen ausreichend ist. Das häufige Senden großer Datenmengen über benutzerdefinierte Eigenschaften kann den Zugriff auf das gesamte Fahrzeugnetzwerk verlangsamen – seien Sie vorsichtig, wenn Sie eine große Nutzlast hinzufügen.
  • Property ID
    Wählen Sie eine Vier-Nibble-ID für die benutzerdefinierte Eigenschaft aus.
• Um eine Fragmentierung des Ökosystems zu verhindern, dürfen benutzerdefinierte Eigenschaften nicht verwendet werden, um Fahrzeugeigenschaften zu replizieren, die bereits im ( VehiclePropertyIds SDK) vorhanden sind.
• Füllen Sie VehiclePropConfig.configString mit einer kurzen Beschreibung der benutzerdefinierten Eigenschaft aus. Dies ermöglicht Plausibilitätsprüfungstools, um die versehentliche Replikation vorhandener Fahrzeugeigenschaften zu kennzeichnen. Zum Beispiel "Warnblinkanlage".
• Zugriff über CarPropertyManager (für Java-Komponenten) oder über die Vehicle Network Service API (für native). Ändern Sie keine anderen Auto-APIs, da dies zu zukünftigen Kompatibilitätsproblemen führen kann.
• Wählen Sie nach der Implementierung von Anbietereigenschaften nur die Berechtigungsliste in der VehicleVendorPermission Enumeration für Anbietereigenschaften aus. Durch das Zuordnen von Anbieterberechtigungen zu Systemeigenschaften werden CTS und VTS beschädigt.

Umgang mit HLK-Eigenschaften

Sie können das VHAL verwenden, um HVAC zu steuern, indem Sie HVAC-bezogene Eigenschaften festlegen. Die meisten HLK-Eigenschaften sind in Zonen aufgeteilte Eigenschaften, obwohl einige nicht in Zonen aufgeteilte (globale) Eigenschaften sind. Beispiele für definierte Eigenschaften umfassen:

Um eine vollständige Liste der HVAC-Eigenschaften anzuzeigen, suchen Sie nach VEHICLE_PROPERTY_HVAC_* in types.hal . Wenn die HVAC-Eigenschaft VehicleAreaSeat verwendet, gelten zusätzliche Regeln für die Zuordnung einer gezonten HVAC-Eigenschaft zu Bereichs-IDs. Jeder verfügbare Sitz im Auto muss Teil einer Bereichs-ID im Bereichs-ID-Array sein.

Beispiel eins. Ein Auto hat zwei Vordersitze ( ROW_1_LEFT, ROW_1_RIGHT ) und drei Rücksitze ( ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT ). Das Auto hat zwei Temperaturregeleinheiten: die Fahrerseite und die Beifahrerseite.

• Ein gültiger Zuordnungssatz von Bereichs-IDs für HVAC_TEMPERATURE SET ist:
  • ROW_1_LEFT | ROW_2_LEFT
  • ROW_1_RIGHT | ROW_2_CENTER | ROW_2_RIGHT
• Eine alternative Zuordnung für dieselbe Hardwarekonfiguration ist:
  • ROW_1_LEFT | ROW_2_LEFT | ROW_2_CENTER
  • ROW_1_RIGHT | ROW_2_RIGHT

Beispiel zwei. Ein Auto hat drei Sitzreihen mit zwei Sitzen in der ersten Reihe ( ROW_1_LEFT, ROW_1_RIGHT ), drei Sitzen in der zweiten ( 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 Temperaturregeleinheiten: Fahrerseite, Beifahrerseite und Heck. Eine vernünftige Möglichkeit, HVAC_TEMPERATURE_SET Bereichs-IDs zuzuordnen, ist ein Array mit drei Elementen:

• ROW_1_LEFT
• ROW_1_RIGHT
• ROW_2_LEFT | ROW_2_CENTER | ROW_2_RIGHT | ROW_3_LEFT | ROW_3_CENTER | ROW_3_RIGHT

Umgang mit Sensoreigenschaften

VHAL-Sensoreigenschaften repräsentieren reale Sensordaten oder Richtlinieninformationen wie den Fahrstatus. Einige Sensorinformationen (z. B. Fahrstatus und Tag-/Nachtmodus) sind für jede App ohne Einschränkung zugänglich, da die Daten zwingend erforderlich sind, um eine sichere Fahrzeuganwendung zu erstellen. Andere Sensorinformationen (z. B. Fahrzeuggeschwindigkeit) sind sensibler und erfordern spezielle Berechtigungen, die Benutzer verwalten können.

Siehe die unterstützten Sensoreigenschaften (in types.hal ).

Fahrzeugkartendienst

Der Fahrzeugkartendienst (VMS) stellt einen Mechanismus zum Austauschen von Kartendaten zwischen Clients über eine Pub/Sub-Schnittstelle bereit, um allgemeine Fahrzeugfunktionen, wie z. B. erweiterte Fahrerassistenzsysteme (ADAS), zu unterstützen. Clients können Fahrzeugsystemschnittstellen über die VMS-Eigenschaft in die VHAL- oder privilegierten Android-Anwendungen integrieren. Auf VMS geteilte Daten sollen auf Kartendaten zur Verwendung durch Fahrzeugsysteme und unterstützende Apps beschränkt sein.

VMS ist nur für die Verwendung in Android Automotive-Implementierungen vorgesehen; AOSP enthält keine Standardclients, die VMS veröffentlichen oder abonnieren. Für die VMS-Eigenschaft in VHAL werden die Nachrichtentypen und Datenstrukturen in VHAL 2.0 in der VmsMessageType Enumeration beschrieben, die die Typen der unterstützten VMS-Nachrichten auflistet. Diese Aufzählung wird als erste Ganzzahl im Array der Fahrzeugeigenschaften-Ganzzahlen verwendet und bestimmt, wie der Rest der Nachricht decodiert wird.