Le générateur de configuration de métriques (MCG) valide les configurations de métriques en vérifiant les noms des signaux, en effectuant une vérification de type sur les expressions et en déduisant les types de sortie. Pour effectuer ces tâches, MCG doit accéder aux définitions de messages de tampon de protocole (protobuf) pour les signaux du véhicule.
Dans SDV, les signaux et les services du véhicule sont définis à l'aide du langage de définition d'interface de service du véhicule (VSIDL). VSIDL utilise des fichiers protobuf pour spécifier les messages, et ces fichiers protobuf constituent la base d'un catalogue de signaux.
Pour que les définitions de signaux soient disponibles pour MCG, vous devez empaqueter ces fichiers protobuf VSIDL dans un FileDescriptorSet protobuf et l'importer dans le service MCG. MCG utilise le terme catalogue de signaux de véhicule pour ces ensembles de définitions importés et versionnés (ce qui fait d'un catalogue de signaux de véhicule la forme compilée et importée des définitions de messages proto dans votre catalogue VSIDL).
Qu'est-ce qu'un catalogue de signaux de véhicule ?
Un catalogue de signaux de véhicule fournit à MCG des définitions de signaux pour la validation, empaquetées sous la forme d'un fichier protobuf FileDescriptorSet.
Dans MCG, les catalogues sont identifiés par une chaîne de version que vous attribuez lors de l'importation, ce qui vous permet de gérer plusieurs ensembles de définitions de signaux distincts. Par exemple, vous pouvez gérer différentes versions de catalogue pour les versions logicielles (v1.0, v1.1, v2.0) ou pour différents modèles de véhicules ou configurations matérielles (suv-my2025, sedan-my2025). Chaque configuration de métriques utilise le champ vs_version pour référencer un catalogue spécifique, qui définit les signaux disponibles en tant que sources de données et fournit des définitions de signaux pour l'inférence et la validation des types.
Créer une instance de FileDescriptorSet
Comme décrit dans Définir des messages et des services RPC, les signaux du véhicule sont définis en tant que messages protobuf dans des fichiers protobuf. Si vous faites partie d'un projet SDV, utilisez les fichiers protobuf du catalogue VSIDL de votre projet pour créer une instance de FileDescriptorSet.
Pour créer un catalogue pour MCG, regroupez vos fichiers protobuf dans un fichier binaire FileDescriptorSet à l'aide de protoc. Si tous vos fichiers protobuf se trouvent dans un seul dossier, exécutez la commande suivante pour générer vehicle_signals.pb :
protoc --include_imports --descriptor_set_out=vehicle_signals.pb path/to/your/protos/*.proto
Importer et gérer des catalogues
L'importation de votre ensemble de définitions de signaux en tant que catalogue vous permet de le référencer par nom de version dans les requêtes de configuration des métriques.
Ajouter ou mettre à jour une version de catalogue
Après avoir généré le fichier de catalogue vehicle_signals.pb, vous pouvez l'importer et le gérer à l'aide des points de terminaison de l'API MCG sous /api/v2/vs/. Le point de terminaison permettant d'ajouter ou de mettre à jour un catalogue, POST /api/v2/vs/, nécessite que le FileDescriptorSet soit transmis sous forme de chaîne encodée en base64 dans la charge utile JSON.
Pour encoder vehicle_signals.pb pour l'utilisation de l'API, utilisez la commande base64. L'option -w 0 désactive le retour à la ligne afin que la chaîne encodée apparaisse sur une seule ligne :
VEHICLE_SIGNALS_BASE64=$(base64 -w 0 vehicle_signals.pb)
Pour importer vehicle_signals.pb en tant que nouvelle version (par exemple, v1.0) ou pour mettre à jour une version existante, envoyez une requête POST avec le contenu encodé en base64 au point de terminaison /api/v2/vs/ avec un nom de version unique.
Le corps de la requête doit être un objet JSON contenant la chaîne version et la chaîne vehicle_signals encodée en base64 :
{
"version": "v1.0",
"vehicle_signals": "Q2lSb1pYB3jCRkRt..."
}
L'exemple suivant montre comment importer vehicle_signals.pb en tant que version v1.0 à l'aide de curl. L'exemple utilise printf pour construire la charge utile JSON et la transmet à curl, ce qui évite d'avoir à créer un fichier JSON contenant une chaîne base64 très longue sur une seule ligne :
# 1. Encode the FileDescriptorSet to a Base64 string VEHICLE_SIGNALS_BASE64=$(base64 -w 0 vehicle_signals.pb) # 2. Define catalog version and build JSON payload VERSION="v1.0" JSON_PAYLOAD=$(jq -n --arg v "$VERSION" --arg d "$VEHICLE_SIGNALS_BASE64" \ '{version: $v, vehicle_signals: $d}') # 3. POST the data to the API endpoint echo "$JSON_PAYLOAD" | curl -H "Content-Type: application/json" --data-binary @- "$SERVICE_URL/api/v2/vs/"
Lister et supprimer des versions
Vous pouvez lister toutes les versions de catalogue disponibles ou supprimer une version spécifique :
Lister les versions : pour afficher la liste des identifiants de toutes les versions de catalogue importées, envoyez une requête
GETà/api/v2/vs/. Consultez GET /api/v2/vs/.Supprimer une version : pour supprimer un catalogue, envoyez une requête
DELETEà/api/v2/vs/{version}, où{version}est l'identifiant fourni lors de l'importation du catalogue (par exemple,v1.0). Consultez DELETE /api/v2/vs/{version}.
Pour en savoir plus sur tous les points de terminaison, consultez la documentation de référence de l'API.
Utiliser un catalogue dans les configurations de métriques
Une fois la version importée, référencez-la dans les configurations de métriques à l'aide du champ vs_version :
{ "vs_version": "v1.0", ... }
Lorsque cet objet JSON est envoyé aux points de terminaison /api/v2/generate_metrics_config ou /api/v2/validate_metrics_config, MCG utilise les définitions de signaux du catalogue v1.0 pour effectuer la validation et l'inférence de type.