El Generador de configuración de métricas (MCG) valida las configuraciones de métricas verificando los nombres de las señales, realizando la verificación de tipos en las expresiones y deduciendo los tipos de salida. Para realizar estas tareas, el MCG necesita acceso a las definiciones de mensajes de búfer de protocolo (protobuf) para las señales del vehículo.
En SDV, las señales y los servicios del vehículo se definen con el lenguaje de definición de interfaz de servicio del vehículo (VSIDL). VSIDL usa archivos protobuf para especificar mensajes, y estos archivos protobuf forman la base de un catálogo de señales.
Para que las definiciones de señales estén disponibles para el MCG, debes empaquetar estos archivos protobuf de VSIDL en un FileDescriptorSet de protobuf y subirlo al servicio del MCG. El MCG usa el término Catálogo de señales del vehículo para estos conjuntos de definiciones subidos y versionados (lo que esencialmente convierte un Catálogo de señales del vehículo en la forma compilada y subida de las definiciones de mensajes proto en tu catálogo de VSIDL).
¿Qué es un Catálogo de señales del vehículo?
Un Catálogo de señales del vehículo proporciona al MCG definiciones de señales para la validación, empaquetadas como un FileDescriptorSet de protobuf.
En el MCG, los catálogos se identifican con una cadena de versión que asignas durante la carga, lo que te permite administrar varios conjuntos de definiciones de señales distintos. Por ejemplo, puedes mantener diferentes versiones de catálogo para lanzamientos de software (v1.0, v1.1, v2.0) o para diferentes modelos de vehículos o configuraciones de hardware (suv-my2025, sedan-my2025). Cada configuración de métricas usa el campo vs_version para hacer referencia a un catálogo específico, que define las señales que están disponibles como fuentes de datos y proporciona definiciones de señales para la validación y la deducción de tipos.
Crea una instancia de FileDescriptorSet
Como se describe en Define mensajes y servicios de RPC, las señales del vehículo
se definen como mensajes protobuf en archivos protobuf. Si formas parte de un proyecto de SDV, usa los archivos protobuf del catálogo de VSIDL de tu proyecto para crear una instancia de FileDescriptorSet.
Para crear un catálogo para el MCG, agrupa tus archivos protobuf en un archivo binario FileDescriptorSet con protoc. Si todos tus archivos protobuf están en una carpeta, ejecuta el siguiente comando para generar 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
Sube y administra catálogos
Subir tu conjunto de definiciones de señales como un catálogo te permite hacer referencia a él por nombre de versión en las solicitudes de configuración de métricas.
Agrega o actualiza una versión del catálogo
Después de generar el archivo de catálogo vehicle_signals.pb, puedes subirlo y administrarlo con los extremos de la API del MCG en /api/v1/vs/. El extremo para agregar o actualizar un catálogo, POST /api/v1/vs/, requiere que se pase el FileDescriptorSet como una cadena codificada en Base64 en la carga útil de JSON.
Para codificar vehicle_signals.pb para el uso de la API, usa el comando base64. La marca -w 0 inhabilita el ajuste de línea para que la cadena codificada aparezca en una sola línea:
VEHICLE_SIGNALS_BASE64=$(base64 -w 0 vehicle_signals.pb)
Para subir vehicle_signals.pb como una versión nueva (por ejemplo, v1.0) o actualizar una versión existente, envía una solicitud POST con el contenido codificado en Base64 al extremo /api/v1/vs/ con un nombre de versión único.
El cuerpo de la solicitud debe ser un objeto JSON que contenga la cadena version y la cadena vehicle_signals codificada en Base64:
{
"version": "v1.0",
"vehicle_signals": "Q2lSb1pYB3jCRkRt..."
}
En el siguiente ejemplo, se muestra cómo subir vehicle_signals.pb como la versión v1.0 con curl. En el ejemplo, se usa printf para construir la carga útil de JSON y se canaliza a curl, lo que evita la necesidad de crear un archivo JSON que contenga una cadena Base64 de una sola línea muy larga:
# 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/"
Enumera y borra versiones
Puedes enumerar todas las versiones de catálogo disponibles o borrar una versión específica:
Enumera versiones: Para ver una lista de identificadores de todas las versiones de catálogo subidas, envía una solicitud
GETa/api/v1/vs/. Consulta GET /api/v1/vs/.Borra una versión: Para quitar un catálogo, envía una solicitud
DELETEa/api/v1/vs/{version}, donde{version}es el identificador proporcionado cuando se subió el catálogo (por ejemplo,v1.0). Consulta DELETE /api/v1/vs/{version}.
Para obtener detalles completos sobre todos los extremos, consulta la Referencia de la API.
Usa un catálogo en las configuraciones de métricas
Cuando se suba, haz referencia a una versión del catálogo en las configuraciones de métricas con el campo vs_version:
{ "vs_version": "v1.0", ... }
Cuando este objeto JSON se envía a los extremos /api/v1/generate_metrics_config o /api/v1/validate_metrics_config, el MCG usa las definiciones de señales del catálogo v1.0 para realizar la validación y la deducción de tipos.