Le générateur de configuration de métriques (MCG, Metrics Configuration Generator) valide les configurations de métriques en vérifiant les noms de signaux, en effectuant une vérification de type sur les expressions et en déduisant les types de sortie. Pour effectuer ces tâches, le MCG doit avoir accès aux définitions de messages de tampon de protocole (protobuf) pour les signaux du véhicule.
Dans le SDV, les signaux et les services du véhicule sont définis à l'aide du langage de définition d'interface de service de véhicule (VSIDL). Le VSIDL utilise des fichiers protobuf pour spécifier les messages, et ces fichiers protobuf constituent la base d'un catalogue de signaux.
Pour rendre les définitions de signaux disponibles pour le MCG, vous devez regrouper ces fichiers protobuf VSIDL dans un FileDescriptorSet protobuf et l'importer dans le service MCG. Le MCG utilise le terme catalogue de signaux de véhicule pour ces ensembles de définitions importés et versionnés (ce qui fait essentiellement 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 au MCG des définitions de signaux pour la validation, regroupées dans un FileDescriptorSet protobuf.
Dans le 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 conserver 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 de type.
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 le 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 <var label="path to folder with .proto files">path/to/your/protos</var>/*.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 de 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/v1/vs/. Le point de terminaison permettant d'ajouter ou de mettre à jour un catalogue, POST /api/v1/vs/, nécessite que le FileDescriptorSet soit transmis en tant que chaîne encodée en base64 dans la charge utile JSON.
Pour encoder vehicle_signals.pb en vue d'une utilisation de l'API, utilisez la commande base64. L'indicateur -w 0 désactive le retour à la ligne afin que la chaîne encodée s'affiche 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/v1/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 redirige vers curl, ce qui évite d'avoir à créer un fichier JSON contenant une très longue chaîne base64 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="<var label="catalog version">v1.0</var>"
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/v1/vs/"
Répertorier et supprimer des versions
Vous pouvez répertorier toutes les versions de catalogue disponibles ou supprimer une version spécifique :
Répertorier les versions : pour afficher la liste des identifiants de toutes les versions de catalogue importées, envoyez une requête
GETà/api/v1/vs/. Consultez GET /api/v1/vs/.Supprimer une version : pour supprimer un catalogue, envoyez une
DELETErequête à/api/v1/vs/{version}, où{version}est l'identifiant fourni lors de l'importation du catalogue (par exemple,v1.0). Consultez DELETE /api/v1/vs/{version}.
Pour obtenir des informations complètes 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 importée, référencez une version de catalogue 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/v1/generate_metrics_config ou /api/v1/validate_metrics_config, le MCG utilise les définitions de signaux du catalogue v1.0 pour effectuer la validation et l'inférence de type.