L'interface Vehicle Hardware Abstraction Layer (VHAL) définit les propriétés que les OEM peuvent implémenter et contient des métadonnées de propriété (par exemple, si la propriété est un entier et quels modes de modification sont autorisés). L'interface VHAL est basée sur l'accès (lecture, écriture, abonnement) à une propriété, qui est une abstraction pour une fonction spécifique.
Interfaces HAL
Le VHAL utilise les interfaces suivantes:
getAllPropConfigs()
génère(vec<VehiclePropConfig>propConfigs)
Liste la configuration de toutes les propriétés compatibles avec le VHAL. CarService n'utilise que les propriétés compatibles.getPropConfigs(vec<int32_t> props)
génère(StatusCode status,vec<VehiclePropConfig> propConfigs);
. Renvoie la configuration des propriétés sélectionnées.set(VehiclePropValue propValue)
génère(StatusCodestatus);
Écrit une valeur dans la propriété. Le résultat de l'écriture est défini par propriété.subscribe(IVehicleCallback callback, vec<SubscribeOptions> options)
génère(StatusCode status);
Commencez à surveiller la modification d'une valeur de propriété. Pour les propriétés zonées,unsubscribe(IVehicleCallback callback, int32_t propId)
génère(StatusCode status);
Le VHAL utilise les interfaces de rappel suivantes:
oneway onPropertyEvent(vec<VehiclePropValue>propValues);
Notifie la modification de la valeur de la propriété du véhicule. Ne doit être effectué que pour les propriétés abonnées.oneway onPropertySetError(StatusCode errorCode,int32_t propId,int32_tareaId);
Renvoie une erreur de niveau VHAL global ou une erreur par propriété. Une erreur globale entraîne le redémarrage du HAL, ce qui peut entraîner le redémarrage d'autres composants (y compris des applications).
Propriétés du véhicule
Les propriétés peuvent être en lecture seule, en écriture seule (utilisées pour transmettre des informations au niveau VHAL) ou en lecture/écriture (la prise en charge de la plupart des propriétés est facultative). Chaque propriété est identifiée de manière unique par une clé int32 et possède un type prédéfini (value_type
):
BYTES
BOOLEAN
EPOCH_TIME
FLOAT
FLOAT[]
INT32
INT32[]
INT64
INT64[]
STRING
MIXED
Une propriété zonée peut avoir plusieurs valeurs, en fonction du nombre de zones prises en charge par la propriété.
Types de zones
Le VHAL définit plusieurs types d'aires:
Type de zone | Description |
---|---|
GLOBAL |
Cette propriété est un singleton et ne comporte pas plusieurs zones. |
WINDOW |
Zone basée sur les fenêtres, utilise l'énumération VehicleAreaWindow . |
MIRROR |
Zone basée sur les miroirs, utilise l'énumération VehicleAreaMirror . |
SEAT |
Zone basée sur le nombre de sièges, utilise l'énumération VehicleAreaSeat . |
DOOR |
Zone basée sur les portes, utilise l'énumération VehicleAreaDoor . |
WHEEL |
Zone basée sur les roues, utilise l'énumération VehicleAreaWheel . |
Chaque propriété zonée doit utiliser un type d'espace prédéfini. Chaque type d'aire est associé à un ensemble d'indicateurs définis dans une énumération. Par exemple, la zone SEAT
définit des énumérations VehicleAreaSeat
:
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
- ...
ID de zone
Les propriétés zonées sont adressées via des ID de zone. Chaque propriété zonée peut prendre en charge un ou plusieurs ID de zone. Un ID de zone est composé d'un ou de plusieurs indicateurs de son énumération respective. Par exemple, une propriété utilisant VehicleAreaSeat
peut utiliser les ID de zone suivants:
Élément | Description |
---|---|
ROW_1_LEFT | ROW_1_RIGHT |
L'ID de zone s'applique aux deux sièges avant. |
ROW_2_LEFT |
S'applique uniquement au siège arrière gauche. |
ROW_2_RIGHT |
S'applique uniquement au siège arrière droit. |
État de l'établissement
Chaque valeur de propriété est associée à une valeur VehiclePropertyStatus
.
Il indique l'état actuel de la propriété:
Élément | Description |
---|---|
AVAILABLE |
La propriété est disponible et la valeur est valide. |
UNAVAILABLE |
La valeur de l'établissement n'est actuellement pas disponible. Utilisé pour les fonctionnalités temporairement désactivées d'une propriété compatible. |
ERROR |
Un problème est survenu avec cet établissement. |
Configurer une propriété
Utilisez VehiclePropConfig
pour fournir des informations de configuration pour chaque propriété. Informations à inclure:
Variable | Description |
---|---|
access |
r , w , rw |
changeMode |
Représente la façon dont une propriété est surveillée, en cas de modification ou en continu. |
areaConfigs |
Valeurs areaId , min et max . |
configArray |
Paramètres de configuration supplémentaires. |
configString |
Informations supplémentaires transmises sous forme de chaîne. |
minSampleRate |
maxSampleRate |
prop |
ID de la propriété, int |
Gérer les propriétés de zone
Une propriété zonée équivaut à un ensemble de plusieurs propriétés, chacune pouvant être accessible avec la valeur d'ID de zone spécifiée.
- L'appel
get
pour une propriété zonée inclut toujours l'ID de zone dans la requête. Par conséquent, seule la valeur actuelle de l'ID de zone demandé est renvoyée. Si la propriété est globale, l'ID de zone est 0. - L'appel
set
pour une propriété zonée inclut toujours l'ID de zone dans la requête. Par conséquent, seul l'ID de zone demandé est modifié. - L'appel
subscribe
génère des événements pour tous les ID de zone de la propriété.
Recevoir des appels
Lors de l'initialisation, la valeur de la propriété n'est peut-être pas encore disponible, car le message réseau du véhicule correspondant n'a pas encore été reçu. Dans ce cas, l'appel get
doit renvoyer -EAGAIN
. Certaines propriétés (comme le CVC) disposent d'une propriété d'alimentation marche/arrêt distincte. L'appel de get
pour une telle propriété (lorsqu'appareil est éteint) doit renvoyer un état UNAVAILABLE
plutôt qu'une erreur. Par exemple, obtenir la température du système CVC
Figure 1 : Obtenir la température du système CVC (CS = CarService, VHAL = Vehicle HAL)
Configurer les appels
Dans une opération typique, un appel set
entraîne l'envoi d'une demande de modification sur le réseau du véhicule. Un appel set
est idéalement une opération asynchrone qui renvoie dès que possible, mais il peut également être synchrone. Certains appels set
peuvent nécessiter que les données initiales soient prêtes, mais lors de l'initialisation, ces données ne sont peut-être pas encore disponibles. Dans ce cas, l'appel set
doit renvoyer StatusCode#TRY_AGAIN
. Certaines propriétés avec une mise en marche et une mise hors tension distinctes doivent renvoyer StatusCode#NOT_AVAILABLE
ou StatusCode#NOT_AVAILABLE_DISABLED
lorsque la propriété est éteinte et que set
ne peut pas être effectuée. Tant que set
n'est pas appliqué, get
ne renvoie pas nécessairement la même valeur que celle définie. Par exemple, set HVAC Temperature
.
Figure 2 : Définir la température du système CVC (CS = CarService, VHAL = Vehicle HAL)
Gérer les propriétés personnalisées
Pour répondre aux besoins spécifiques des partenaires, le VHAL autorise les propriétés personnalisées limitées aux applications système. Suivez les consignes ci-dessous lorsque vous travaillez avec des propriétés personnalisées:
- L'ID de propriété doit être généré à l'aide des champs suivants :
VehiclePropertyGroup:VENDOR
Le groupeVENDOR
n'est utilisé que pour les propriétés personnalisées.VehicleArea
Sélectionnez un type de zone approprié.VehiclePropertyType
Sélectionnez le type de données approprié. Le typeBYTES
permet de transmettre des données brutes, ce qui est suffisant dans la plupart des cas. L'envoi fréquent de données volumineuses via des propriétés personnalisées peut ralentir l'accès au réseau du véhicule dans son ensemble. Soyez prudent lorsque vous ajoutez une charge utile importante.Property ID
Choisissez un ID à quatre octets pour la propriété personnalisée.
- Pour éviter la fragmentation de l'écosystème, les propriétés personnalisées ne doivent pas être utilisées pour répliquer les propriétés des véhicules qui existent déjà dans le SDK VehiclePropertyIds.
- Remplacez
VehiclePropConfig.configString
par une brève description de la propriété personnalisée. Cela permet aux outils de validation de détecter la réplication accidentelle de propriétés de véhicule existantes. (par exemple, "état des feux de détresse"). - Accès via
CarPropertyManager
(pour les composants Java) ou via l'API Vehicle Network Service (pour les applications natives). Ne modifiez pas d'autres API de voiture, car cela pourrait entraîner des problèmes de compatibilité à l'avenir. - Après avoir implémenté les propriétés du fournisseur, sélectionnez uniquement la liste des autorisations dans l'énumération
VehicleVendorPermission
pour les propriétés du fournisseur. Le mappage des autorisations du fournisseur sur les propriétés système entraînera l'échec des CTS et VTS.
Gérer les propriétés de CVC
Vous pouvez utiliser le VHAL pour contrôler le système CVC en définissant des propriétés liées au CVC. La plupart des propriétés CVC sont des propriétés zonées, bien que plusieurs soient des propriétés non zonées (globales). Voici quelques exemples de propriétés définies:
Propriété | Objectif |
---|---|
VEHICLE_PROPERTY_HVAC_TEMPERATURE_SET |
Définissez la température par zone. |
VEHICLE_PROPERTY_HVAC_RECIRC_ON |
Contrôlez la recirculation par zone. |
Pour obtenir la liste complète des propriétés CVC, recherchez VEHICLE_PROPERTY_HVAC_*
dans types.hal
. Lorsque la propriété CVC utilise VehicleAreaSeat
, des règles supplémentaires s'appliquent pour mapper une propriété CVC zonée sur des ID de zone. Chaque siège disponible dans la voiture doit faire partie d'un ID de zone dans le tableau des ID de zone.
Exemple 1 Une voiture comporte deux sièges avant (ROW_1_LEFT, ROW_1_RIGHT
) et trois sièges arrière (ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT
). Elle dispose de deux unités de contrôle de la température: côté conducteur et côté passager.
- Voici un ensemble de mappage valide d'ID de zone pour
HVAC_TEMPERATURE SET
:ROW_1_LEFT | ROW_2_LEFT
ROW_1_RIGHT | ROW_2_CENTER | ROW_2_RIGHT
- Voici un autre mappage pour la même configuration matérielle:
ROW_1_LEFT | ROW_2_LEFT | ROW_2_CENTER
ROW_1_RIGHT | ROW_2_RIGHT
Exemple 2 Une voiture comporte trois rangées de sièges, avec deux sièges à l'avant (ROW_1_LEFT, ROW_1_RIGHT
), trois au milieu (ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT
) et trois à l'arrière (ROW_3_LEFT, ROW_3_CENTER, ROW_3_RIGHT
). Elle dispose de trois unités de contrôle de la température: côté conducteur, côté passager et arrière. Un moyen raisonnable de mapper HVAC_TEMPERATURE_SET
sur les ID de zone consiste à utiliser un tableau à trois éléments:
ROW_1_LEFT
ROW_1_RIGHT
ROW_2_LEFT | ROW_2_CENTER | ROW_2_RIGHT | ROW_3_LEFT | ROW_3_CENTER | ROW_3_RIGHT
Gérer les propriétés des capteurs
Les propriétés de capteur VHAL représentent des données de capteur réelles ou des informations sur les règles, telles que l'état de conduite. Certaines informations des capteurs (telles que l'état de conduite et le mode jour/nuit) sont accessibles par n'importe quelle application sans restriction, car ces données sont obligatoires pour créer une application de véhicule sécurisée. D'autres informations de capteur (telles que la vitesse du véhicule) sont plus sensibles et nécessitent des autorisations spécifiques que les utilisateurs peuvent gérer.
Consultez les propriétés de capteur compatibles (dans types.hal
).
service de cartographie pour véhicule (VMS)
Le service de cartographie pour véhicule (VMS) fournit un mécanisme permettant d'échanger des données cartographiques entre les clients via une interface pub/sub pour prendre en charge les fonctionnalités courantes des véhicules, telles que les systèmes avancés d'assistance à la conduite (ADAS). Les clients peuvent inclure des systèmes de véhicule qui s'interfacent via la propriété VMS dans le VHAL ou les applications Android privilégiées. Les données partagées sur le VMS sont censées être limitées aux données cartographiques à utiliser par les systèmes du véhicule et les applications associées.
Le VMS n'est destiné qu'aux implémentations Android Automotive. AOSP ne contient pas de clients par défaut qui publient ou s'abonnent au VMS. Pour la propriété VMS dans VHAL, les types de messages et les structures de données sont décrits dans VHAL 2.0 dans l'énumération VmsMessageType
, qui liste les types de messages VMS compatibles. Cet énumération est utilisée comme premier entier dans le tableau d'entiers des propriétés du véhicule et détermine la façon dont le reste du message est décodé.