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 int et quels modes de changement 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)
  Répertoriez la configuration de toutes les propriétés prises en charge par le VHAL. CarService utilise uniquement les propriétés prises en charge.
• 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);
  Écrivez une valeur à 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 un changement de valeur de propriété. Pour la propriété zonée, 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 le changement de valeur de la propriété du véhicule. Ne devrait être fait que pour les propriétés souscrites.
• 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 provoque le redémarrage de HAL, ce qui peut entraîner le redémarrage d'autres composants (y compris les 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 et é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 a 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é.

Type de zone

Le VHAL définit plusieurs types de zones :

Chaque propriété zonée doit utiliser un type de zone prédéfini. Chaque type de zone a un ensemble d'indicateurs binaires définis dans une énumération pour le type de zone. Par exemple, la zone SEAT définit les é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 identifiants de zone. Chaque propriété zonée peut prendre en charge un ou plusieurs identifiants de zone. Un ID de zone est composé d'un ou plusieurs drapeaux de son énumération respective. Par exemple, une propriété utilisant VehicleAreaSeat peut utiliser les ID de zone suivants :

Statut de la propriété

Chaque valeur de propriété est accompagnée d'une valeur VehiclePropertyStatus . Ceci indique l'état actuel de la propriété :

Configurer une propriété

Utilisez VehiclePropConfig pour fournir des informations de configuration pour chaque propriété. Les informations comprennent :

Gestion des propriétés de zone

Une propriété zonée équivaut à une collection de plusieurs propriétés où chaque sous-propriété est accessible avec la valeur d'ID de zone spécifiée.

• get un appel pour une propriété zonée inclut toujours l'ID de zone dans la demande. Par conséquent, seule la valeur actuelle de l'ID de zone demandé est renvoyée. Si la propriété est globale, alors l'ID de zone est 0.
• set call for zoned property inclut toujours l'ID de zone dans la demande. Par conséquent, seul l'ID de zone demandé est modifié.
• l'appel subscribe génère des événements pour tous les identifiants de zone de la propriété.

Recevoir des appels

Lors de l'initialisation, la valeur de la propriété peut ne pas être encore disponible car le message de réseau de véhicule correspondant n'a pas encore été reçu. Dans de tels cas, l'appel get doit renvoyer -EAGAIN . Certaines propriétés (telles que HVAC) ont une propriété d'alimentation marche/arrêt séparée. L'appel de get pour une telle propriété (lorsqu'il est éteint) devrait renvoyer un statut UNAVAILABLE plutôt que de renvoyer une erreur. Par exemple, obtenez la température HVAC

Figure 1 . Obtenir la température CVC (CS = CarService, VHAL = Vehicle HAL)

Définir des appels

Dans une opération typique, un appel set conduit à faire une demande de changement à travers le réseau du véhicule. Un appel set est idéalement une opération asynchrone qui revient dès que possible, mais il peut aussi être synchrone. Certains appels set peuvent nécessiter que les données initiales soient prêtes, mais lors de l'initialisation, ces données peuvent ne pas encore être disponibles. Dans de tels cas, l'appel set doit renvoyer StatusCode#TRY_AGAIN . Certaines propriétés avec mise sous tension et hors tension séparées doivent renvoyer StatusCode#NOT_AVAILABLE ou StatusCode#NOT_AVAILABLE_DISABLED lorsque la propriété est mise hors tension et qu'elle ne peut pas être set . Tant que set n'est pas rendu effectif, get ne renvoie pas nécessairement la même valeur que ce qui est défini. Par exemple, set HVAC Temperature .

Figure 2 . Régler la température CVC (CS = CarService, VHAL = Vehicle HAL)

Gestion des 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. Utilisez les instructions suivantes 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 est utilisé uniquement 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 le passage de 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 de l'ensemble du véhicule. Soyez prudent lorsque vous ajoutez une charge utile importante.
  • Property ID
    Choisissez un ID à quatre quartets 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 du véhicule qui existent déjà dans le (SDK VehiclePropertyIds ).
• Remplissez VehiclePropConfig.configString avec une brève description de la propriété personnalisée. Cela permet aux outils de vérification de cohérence de signaler la réplication accidentelle des propriétés existantes du véhicule. 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 composants natifs). Ne modifiez pas d'autres API de voiture, car cela pourrait entraîner de futurs problèmes de compatibilité.
• 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 aux propriétés du système cassera le CTS et le VTS.

Gestion des propriétés CVC

Vous pouvez utiliser le VHAL pour contrôler HVAC en définissant des propriétés liées à HVAC. 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). Exemples de propriétés définies :

Pour voir une liste complète des propriétés HVAC, recherchez VEHICLE_PROPERTY_HVAC_* dans types.hal . Lorsque la propriété HVAC utilise VehicleAreaSeat , des règles supplémentaires pour mapper une propriété HVAC zonée aux ID de zone s'appliquent. Chaque siège disponible dans la voiture doit faire partie d'un identifiant de zone dans le tableau des identifiants de zone.

Exemple Un. Une voiture a 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 ). La voiture dispose de deux unités de contrôle de la température : côté conducteur et côté passager.

• Un ensemble de mappage valide d'ID de zone pour HVAC_TEMPERATURE SET est :
  • ROW_1_LEFT | ROW_2_LEFT
  • ROW_1_RIGHT | ROW_2_CENTER | ROW_2_RIGHT
• Un mappage alternatif pour la même configuration matérielle est :
  • ROW_1_LEFT | ROW_2_LEFT | ROW_2_CENTER
  • ROW_1_RIGHT | ROW_2_RIGHT

Exemple Deux. Une voiture a trois rangées de sièges avec deux sièges dans la première rangée ( ROW_1_LEFT, ROW_1_RIGHT ), trois sièges dans la deuxième ( ROW_2_LEFT, ROW_2_CENTER, ROW_2_RIGHT ) et trois dans la troisième rangée ( ROW_3_LEFT, ROW_3_CENTER, ROW_3_RIGHT ). La voiture 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 aux 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

Gestion des propriétés du capteur

Les propriétés du capteur VHAL représentent des données de capteur réelles ou des informations de politique 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 les données sont obligatoires pour créer une application de véhicule sûre. 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.

Voir les propriétés de capteur prises en charge (dans types.hal ).

Service de cartographie des véhicules

Le service de cartographie des véhicules (VMS) fournit un mécanisme d'échange de données cartographiques entre les clients via une interface pub/sub pour prendre en charge les fonctionnalités courantes du véhicule, telles que les systèmes avancés d'assistance à la conduite (ADAS) . Les clients peuvent inclure des systèmes de véhicule s'interfaçant via la propriété VMS dans les applications VHAL ou Android privilégiées. Les données partagées sur le VMS sont destinées à être limitées aux données cartographiques à utiliser par les systèmes du véhicule et les applications de support.

VMS est destiné à être utilisé uniquement dans les implémentations Android Automotive ; AOSP ne contient pas de clients par défaut qui publient ou s'abonnent à VMS. Pour la propriété VMS dans VHAL, les types de message et les structures de données sont décrits dans VHAL 2.0 dans l'énumération VmsMessageType , qui répertorie les types de messages VMS pris en charge. Cette énumération est utilisée comme premier entier dans le tableau d'entiers des propriétés du véhicule et détermine comment le reste du message est décodé.