De la selección de herramientas a la ingeniería de circuitos cerrados: cómo los agentes de IA se integran en el desarrollo de sistemas eléctricos de tres componentes.

Autor: Johnny Liu, director ejecutivo de Dowway Vehicle

Publicado el: 9 de julio de 2026

Tiempo de lectura: 15 minutos

Categoría: Vehículos eléctricos, ingeniería de IA, diseño basado en modelos (MBD)

Más allá del bombo publicitario de los chatbots

Si su equipo de ingeniería de software automotriz considera marcos como Agente de Hermes o OpenClaw y simplemente ven un “chatbot más inteligente”, los están usando mal. En la I+D automotriz de alta integridad, especialmente dentro de los sistemas “Trieléctricos” (Sistema de Gestión de Baterías).[BMS]Unidad de control del vehículo[VCU]y unidad de control del motor[MCU])—el verdadero valor de una IA no reside en tomar las decisiones finales por los ingenieros.

En cambio, su valor reside en su capacidad para organizar el acceso a archivos, la llamada a herramientas, la ejecución de comandos CLI, el aislamiento del navegador y la recuperación del conocimiento empresarial en un solo lugar. canalización de ingeniería auditable y determinista.

Este artículo explica cómo los agentes de IA pueden conectar las herramientas fragmentadas del diseño basado en modelos (MBD, por sus siglas en inglés) sin comprometer la seguridad, trazando un camino claro desde la simple llamada a herramientas hasta un ciclo de ingeniería cerrado completo.

1. El principal problema de la ingeniería: archivos fragmentados, herramientas aisladas y cadenas de evidencia rotas.

Cualquier ingeniero de software de sistemas de propulsión con experiencia sabe que un defecto típico del sistema de control rara vez se origina en un solo archivo aislado. Considere este escenario estándar de resolución de problemas:

• Síntoma: En condiciones de baja temperatura, el límite de potencia de carga de la batería disminuye inesperadamente. Esto ocurre junto con limitaciones de par esporádicas y una discrepancia en el código de diagnóstico de averías (DTC) entre la salida real del controlador y las especificaciones del sistema.

Para diagnosticar este problema, un ingeniero debe abrir, analizar y cotejar simultáneamente un conjunto de datos masivo y fragmentado:

[System Requirements] ── (DOORS / Word)
       │
[Software Model]       ── (MATLAB Simulink / Stateflow)
       │
[Network Interfaces]   ── (DBC / ARXML)
       │
[Memory Mapping]       ── (ASAP2 / A2L / Calibration Parameters)
       │
[Real-world Behavior]  ── (Vector CANoe Trace / CANape Logs / MDF4)

Los cuatro niveles de fragmentación

Este flujo de trabajo pone de manifiesto una grave fragmentación en cuatro dimensiones distintas:

1. Fragmentación a nivel de archivo: Los requisitos residen en Word o IBM DOORS; la lógica de control reside en modelos de MATLAB Simulink (.slx) y diagramas de Stateflow; las interfaces de bus se definen en .dbc o .arxml; las direcciones de memoria se definen en .a2l; los scripts de prueba están escritos en CAPL o Python; los registros de prueba existen en .mdf, .dat, o .csv archivos.
2. Aislamiento de la cadena de herramientas: Los ingenieros deben cambiar de contexto constantemente. Pasan de MATLAB/Simulink (diseño de modelos) a Vector CANoe (simulación de bus), Vector CANape o TsMaster (calibración/medición), Excel (mapeo de datos) y sistemas internos de seguimiento de incidencias basados ​​en la web (Jira).
3. Inconsistencia semántica: La misma variable física (como la corriente de carga de la batería objetivo) podría llamarse Cambio_de_Objetivo_Actual en la especificación de requisitos funcionales, bms_I_target en el espacio de trabajo del modelo Simulink, BMS_ObjetivoActual en la base de datos de señales CAN DBC y P_BMS_Chg_Curr_Limit en el archivo de calibración A2L. A menudo tienen diferentes frecuencias de muestreo, factores de escala, unidades y rangos de valores válidos.
4. Cadenas de evidencia desaparecida: Una IA generativa puede sugerir fácilmente una causa raíz hipotética. Sin embargo, si esa sugerencia no puede señalar un milisegundo específico en un registro, una transición de señal específica en un rastro, una ruta específica en un modelo de Simulink o un ID de caso de prueba específico, entonces no puede aceptarse como una conclusión de ingeniería.

La cuestión no es cuán inteligente es el LLM. La cuestión es: ¿En qué posición se encuentra el agente de IA dentro de la cadena de herramientas MBD, cómo accede a los archivos, cuándo se le permite ejecutar scripts y cuándo debe detenerse para devolver el control a un ingeniero humano?

2. Los límites de la automatización tradicional frente al límite de la agencia

Los departamentos de software del sector automotriz llevan décadas utilizando scripts automatizados (API de MATLAB, analizadores DBC de Python, conjuntos de pruebas CAPL, pipelines de CI/CD de Jenkins y macros de Excel). Estas herramientas son altamente deterministas, repetibles y completamente auditables.

Sin embargo, presentan altos costos de cambio de contexto. Un script de Python puede analizar un DBC y un script de MATLAB puede realizar una verificación del modelo, pero no comparten el contexto semántico.

La siguiente matriz define dónde se estancan los scripts de automatización tradicionales y dónde deberían intervenir los agentes de IA:

Artefacto de ingeniería	Limitaciones de la automatización tradicional	El límite del agente de IA
Simulink / Stateflow	Los scripts ejecutan comprobaciones de reglas de diseño estáticas (como Model Advisor) y generan informes XML. Sin embargo, la interpretación de estos informes y la vinculación de los fallos con los requisitos del sistema aún requieren trabajo manual.	El agente lee el informe del Asesor de modelos y la especificación original, mapea las fallas y genera una lista de problemas de ingeniería priorizados. nunca Edita directamente los archivos del modelo.
DBC / A2L / MDF	Los scripts de Python o CANape pueden extraer listas de señales, pero la asignación de variables entre DBC y A2L requiere que los ingenieros mantengan tablas de conversión de Excel manuales y frágiles.	El agente resuelve dinámicamente las discrepancias en el mapeo semántico analizando los factores de escala, los tipos de datos, las unidades físicas y las versiones de los parámetros de calibración en DBC, A2L y los modelos.
CANoe / CAPL	Los bancos de pruebas automatizados ejecutan scripts de prueba y exportan informes de prueba en formato HTML. Sin embargo, para encontrar la causa raíz de un resultado de “Fallo”, es necesario analizar manualmente los registros.	El agente analiza los archivos de registro de la prueba CANoe y de CAPL, aísla la marca de tiempo exacta del fallo, la correlaciona con los códigos de diagnóstico y elabora correcciones para el script de CAPL.
Requisitos Especificaciones	Los scripts estándar pueden verificar si un documento de requisitos tiene un campo de identificación, pero no pueden evaluar la claridad del texto ni mapear la cobertura de las pruebas.	El agente extrae los criterios de aceptación funcionales, los compara con los puntos de prueba reales y genera un borrador de matriz de trazabilidad de extremo a extremo.
Herramientas web internas	Los ingenieros deben copiar y pegar manualmente los registros de seguimiento o los códigos de error de diagnóstico en Jira, Confluence o bases de conocimiento internas.	El agente utiliza herramientas de búsqueda y recuperación para examinar bases de datos internas, cotejar registros históricos de incidencias y registrar referencias junto con las URL de origen.

3. Arquitectura de referencia: LLM en la capa de orquestación

Para implementar de forma segura agentes de IA en el desarrollo de sistemas críticos para la seguridad (como las canalizaciones de software ISO 26262 ASIL-D), el LLM debe residir estrictamente en el Capa de orquestación, completamente aislado de la Ciclo de ejecución de seguridad.

    ┌────────────────────────────────────────────────────────┐
    │                  HUMAN ENGINEER (Review)               │
    └───────────────────────────▲────────────────────────────┘
                                │
               [State / Logs]   │   [Approve / Correct]
                                │
    ┌───────────────────────────▼────────────────────────────┐
    │             LLM ORCHESTRATION LAYER (Agent)            │
    │  - Plan Formulation        - Context Assembly          │
    │  - Semantic Mapping        - Reasoning & Tool-calling  │
    └───────────────────────────┬────────────────────────────┘
                                │
            [Authorized Tool Calls] / [Structured Outputs]
                                │
    ┌───────────────────────────▼────────────────────────────┐
    │               AUDITABLE EXECUTION LAYER                │
    │  ┌───────────────────────┐   ┌───────────────────────┐  │
    │  │  Sandboxed Environment│   │   Whitelisted Tools   │  │
    │  │  - Read-Only Snapshots│   │   - MATLAB / CANoe APIs│  │
    │  │  - Isolated Browsers  │   │   - Python/CAPL Parsers│  │
    │  └───────────────────────┘   └───────────────────────┘  │
    └────────────────────────────────────────────────────────┘

Marcos como OpenClaw Definir las herramientas como funciones estructuradas que el Agente puede invocar (ejecución, recuperación web, búsqueda local, mensajería). De manera similar, Agente de Hermes Utiliza un entorno aislado local para ejecutar las utilidades del sistema de forma segura.

Para el software automotriz, debemos establecer cinco medidas de seguridad absolutas:

1. Aislamiento de almacenamiento de solo lectura: El agente debe operar en una instantánea de solo lectura o en una rama git dedicada del espacio de trabajo (./project_snapshot). Nunca debe tener acceso de escritura a las ramas de producción, las claves criptográficas o los repositorios de línea base propietarios.
2. Llamada de herramientas autorizada: El agente no puede ejecutar comandos de shell directamente. En su lugar, debe interactuar con el ecosistema de ingeniería invocando una lista blanca de scripts de ejecución preescritos y deterministas en Python o MATLAB.
3. Registro de restricciones de ejecución: Cada ejecución de script debe ejecutarse dentro de un directorio estricto, aplicar límites de tiempo de espera de ejecución y capturar automáticamente todo salida estándar, error estándar, códigos de salida y hashes de archivos de entrada. Estos registros se conservan en un registro de auditoría inalterable.
4. Perfiles de navegador aislados: Para la recuperación de información web (como la búsqueda de definiciones estándar de ASAM o la consulta de tableros internos de Jira), el agente debe utilizar un perfil de navegador dedicado que esté completamente aislado de las credenciales de SSO personales o empresariales.
5. Segregación de inquilinos de la base de conocimientos: Al conectarse a bases de datos de generación aumentada por recuperación (RAG) que contienen directrices de calibración propietarias o datos de depuración de proyectos anteriores, el sistema debe aplicar un estricto control de acceso basado en roles (RBAC) para evitar fugas de propiedad intelectual entre clientes.

4. Integración paso a paso: Asignación del agente a la cadena de herramientas MBD

Analicemos cómo un agente de IA ejecuta un flujo de trabajo MBD completo de cuatro pasos.

Step 1: Parse Specs ──► Step 2: Scan Model ──► Step 3: Align Signals ──► Step 4: Parse Logs
 (Requirements to         (MATLAB Report         (DBC to A2L          (CANoe Trace
   Test Matrix)            Analyzer)               Mapping)             to Evidence)

Paso 4.1: Especificación de requisitos para la elaboración de la matriz de pruebas

El agente ingiere documentos de requisitos (como archivos Markdown o JSON exportados desde DOORS). Analiza cada cláusula funcional para extraer:

• Precondiciones (por ejemplo, Temperatura de la batería < -10 °C)
• Entradas activas (como Enchufe de carga detectado == VERDADERO)
• Salidas esperadas del sistema (tales como Límite_de_corriente_máxima_carga == 15A)
• Afecciones diagnósticas asociadas.

En lugar de intentar escribir el código final, el Agente genera un código estructurado. Borrador de la matriz de pruebas en formato JSON, definiendo puntos de validación explícitos para las pruebas MIL/SIL/HIL posteriores.

Paso 4.2: Verificación del modelo para emitir listas de verificación

El agente tiene bloqueado el acceso para modificar modelos de Simulink (.slx) o diagramas de Stateflow directamente. En su lugar, invoca un script local de MATLAB a través de la interfaz de línea de comandos. Este script de ejecución:

1. Abre MATLAB en una sesión sin interfaz gráfica.
2. Ejecuta comprobadores de reglas de diseño estático personalizados (como la comprobación de convenciones de nomenclatura o la búsqueda de puertos de señal no vinculados).
3. Exporta un informe de diagnóstico estructurado.

El agente lee este informe, lo coteja con las directrices de diseño del software y genera una lista de verificación estructurada que resalta los errores (como “diagrama de Stateflow”). Administrador de cargos falta una ruta de transición predeterminada”).

Paso 4.3: Mapeo semántico de los campos DBC, A2L y de calibración.

Este paso relaciona las señales de comunicación físicas con la memoria interna del controlador. El agente llama a un analizador Python específico para leer el archivo CAN DBC y el archivo A2L del controlador.

A continuación, crea una tabla unificada de asignación de variables y comprueba si existen discrepancias críticas:

[Signal: BMS_Target_I] ── (DBC Unit: Ampere | Scale: 0.1 | Offset: 0)
                                 VS
[Parameter: Target_I_Cal] ── (A2L Unit: Ampere | Scale: 0.01 | Offset: -40)
                                 ▲
                         [Agent Flags Mismatch]