Propriétés du véhicule

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

Exemple de VHAL get HVAC

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.

Exemple de configuration du système CVC avec VHAL

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 groupe VENDOR 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 type BYTES 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é.