Req2Road: A GenAI Pipeline for SDV Test Artifact Generation and On-Vehicle Execution

1. Problema y Contexto

La transición hacia Vehículos Definidos por Software (SDV) ha incrementado drásticamente la complejidad del software, el volumen de pruebas y la variabilidad de los requisitos. El artículo identifica varios cuellos de botella críticos en el proceso actual de verificación y validación:

• Heterogeneidad de Entradas: Los requisitos se expresan en lenguaje natural, pero las especificaciones combinan texto, tablas y diagramas (UML, flujos de estado), lo que dificulta la derivación automática de pruebas.
• Desconexión de Herramientas: Los activos de prueba están dispersos en cadenas de herramientas heterogéneas, creando brechas de interoperabilidad.
• Falta de Portabilidad: Las pruebas suelen estar "hardcodeadas" con señales específicas del hardware, lo que impide su reutilización entre diferentes bancadas de prueba (SiL, HiL) y vehículos.
• Inconsistencia: A pesar de estándares como ASPICE, la planificación de pruebas sigue siendo manual, inconsistente y poco alineada con requisitos en evolución.

2. Metodología: El Pipeline Req2Road

Req2Road (Requirements-to-Road) es una arquitectura basada en Inteligencia Artificial Generativa (GenAI) diseñada para transformar artefactos de requisitos heterogéneos en scripts de prueba ejecutables. El pipeline consta de cuatro fases principales:

A. Generación de Escenarios Gherkin (Fase Inicial)

• Entrada: Requisitos en lenguaje natural y diagramas de flujo de comportamiento.
• Modelos: Se utilizan Modelos de Lenguaje Grande (LLM) y Modelos Visuales-Linguísticos (VLM).
  • Los VLM (como Qwen 2.5 VL 72B o Gemini 2.5 Pro) extraen lógica y señales de diagramas UML.
  • Los LLM (como GPT-5) generan escenarios estructurados en sintaxis Gherkin (formato Given/When/Then) basados en los requisitos y la información visual.
• Técnicas: Se emplean Chain of Thought (Cadena de Pensamiento) y Few-Shot Learning para mejorar la precisión.

B. Mapeo de Señales VSS (Vehicle Signal Specification)

• Desafío: Evitar la alucinación de señales inexistentes y asegurar la portabilidad.
• Solución: Integración con el estándar VSS (especificación neutral de señales del vehículo).
• Proceso RAG (Generación Aumentada por Recuperación):
  1. Se utiliza un codificador SentenceTransformer para incrustar el escenario y el catálogo VSS.
  2. Se realiza una búsqueda de vecinos más cercanos para pre-seleccionar un subconjunto pequeño de señales candidatas (ej. 16 señales) en lugar de usar todo el catálogo (982 señales).
  3. Un cross-encoder re-rankear las candidatas.
  4. El LLM selecciona las señales relevantes de esta lista acortada para mapearlas a las rutas VSS en el escenario Gherkin.

C. Refinamiento y Generación de Código

• Los escenarios Gherkin refinados (con rutas VSS explícitas) se convierten en scripts de prueba ejecutables.
• Modelo: Se utiliza GPT-4.1 para la generación de código Python.
• Contexto: El prompt incluye el escenario Gherkin, ejemplos de la API de cliente KUKSA (para acceso a señales) y plantillas del framework Behave.
• Salida: Archivos .feature, environment.py y definiciones de pasos (steps/*.py).

D. Ejecución

• Los artefactos generados se ejecutan en dos entornos:
  1. SiL (Software-in-the-Loop): En el entorno digital.auto (sandbox en la nube).
  2. ViL (Vehicle-in-the-Loop): En un vehículo real equipado con una unidad de procesamiento NVIDIA Jetson, utilizando el mismo código sin modificaciones lógicas, solo cambiando los parámetros de conexión.

3. Caso de Estudio

El pipeline se evaluó sobre un Sistema de Detección de Presencia de Niños (CPDS), un sistema de seguridad crítica basado en las directrices de Euro NCAP.

• Escenario: Detección de un niño no atendido en un vehículo estacionado, seguido de una lógica de escalada temporal (notificaciones, activación de HVAC, luces exteriores, contacto con emergencias).
• Datos: 36 requisitos en lenguaje natural y un diagrama de flujo de estados con 8 estados y 11 transiciones.
• Ejemplo específico: Se analizó en detalle la "Intervención I" (Ajuste del sistema HVAC).

4. Resultados Clave

La evaluación cuantitativa y cualitativa arrojó los siguientes hallazgos:

• Tasa de Éxito en Conversión: De los 36 requisitos, 32 (89%) se transformaron en escenarios Gherkin ejecutables sin modificaciones manales. Los 4 restantes requirieron ajustes dirigidos, principalmente en casos extremos mal especificados o condiciones "OR" ambiguas.
• Calidad del Mapeo VSS:
  • El uso de RAG con una lista corta (16 candidatos) fue crucial. Con este enfoque, GPT-4o-mini logró un 100% de coincidencia con el conjunto de referencia (Gold Set) y 0 falsos positivos.
  • Sin filtrado (catálogo completo de 982 señales), la calidad se degradó significativamente, aumentando los falsos positivos y reduciendo la precisión.
• Generación de Código:
  • Para requisitos individuales, los modelos alcanzaron un pass@3 de 1 (éxito total).
  • Para escenarios complejos que combinaban 3 requisitos, solo GPT-4.1 logró generar soluciones completamente correctas; otros modelos fallaron en lógica de terminación o sintaxis.
• Ejecutabilidad End-to-End: Los scripts generados funcionaron correctamente tanto en la simulación digital.auto como en el vehículo real, demostrando la portabilidad de los artefactos.

5. Contribuciones Principales

1. Pipeline Arquitectónico End-to-End: Demostración de un flujo de trabajo completo que va desde requisitos heterogéneos (texto + diagramas) hasta pruebas ejecutables en SDV, utilizando GenAI.
2. Estrategia de Mapeo Híbrida (RAG + VSS): Validación de que el pre-filtrado de señales mediante RAG es esencial para evitar alucinaciones en catálogos grandes, asegurando la portabilidad mediante el estándar VSS.
3. Validación en Entornos Reales (ViL): Demostración práctica de que los artefactos generados por IA pueden ejecutarse en un vehículo físico con cambios mínimos de configuración, cerrando la brecha entre simulación y realidad.
4. Modelos Locales vs. Nube: Evaluación comparativa que muestra que, aunque los modelos comerciales son más precisos, los modelos locales (como Qwen 2.5 VL) son viables y necesarios para proteger la propiedad intelectual de requisitos confidenciales.

6. Significado y Limitaciones

Significado:
El trabajo demuestra que la IA generativa, cuando se gobierna mediante arquitecturas de recuperación (RAG), estándares de señalización (VSS) y revisión humana (Human-in-the-Loop), puede acelerar significativamente la creación de pruebas para vehículos definidos por software. Ofrece un camino viable para automatizar la trazabilidad desde requisitos naturales hasta la ejecución en hardware.

Limitaciones y Futuro:

• Complejidad Lógica: El rendimiento decae en escenarios con múltiples requisitos combinados o condiciones lógicas complejas (OR/AND), requiriendo revisión humana.
• Calidad de los Requisitos: La precisión depende de la claridad de los requisitos de entrada; especificaciones ambiguas generan errores.
• Seguridad y Gobernanza: Se necesitan marcos de validación más estrictos (sandboxing, validación de esquemas) antes de confiar en pruebas generadas por IA para decisiones de liberación de seguridad crítica.
• Escalabilidad: Se requiere más investigación para validar el enfoque en conjuntos de requisitos más grandes y arquitecturas de vehículos diversas.

En resumen, Req2Road no es una solución totalmente autónoma, sino una herramienta de aumento que reduce la carga manual de la ingeniería de pruebas, estandariza la interfaz de señalización y permite una iteración más rápida en el desarrollo de SDV.