De l’appel d’outils à l’ingénierie en boucle fermée : comment les agents d’IA s’intègrent au développement du système « Three-Electric » pour véhicules électriques

Auteur: Johnny Liu, PDG de Dowway Vehicle

Publié le : 9 juillet 2026

Temps de lecture : 15 minutes

Catégorie: Véhicules électriques, ingénierie IA, conception basée sur des modèles (MBD)

Au-delà du phénomène des chatbots

Si votre équipe d’ingénierie logicielle automobile examine des frameworks comme Agent Hermès ou OpenClaw S’ils voient simplement un « chatbot plus intelligent », ils les utilisent mal. Dans la R&D automobile de haute intégrité, et plus particulièrement dans les systèmes « Tri-électriques » (système de gestion de batterie), ces systèmes sont souvent mal utilisés.[BMS], Unité de contrôle du véhicule[VCU]et unité de commande du moteur[MCU]— La véritable valeur d’une IA n’est pas de prendre les décisions finales à la place des ingénieurs.

Sa valeur réside plutôt dans sa capacité à organiser l’accès aux fichiers, l’appel d’outils, l’exécution de commandes CLI, le sandboxing du navigateur et la récupération des connaissances d’entreprise au sein d’un système. pipeline d’ingénierie auditable et déterministe.

Cet article explique comment les agents d’IA peuvent relier les outils fragmentés de la conception basée sur des modèles (MBD) sans compromettre la sécurité, traçant un chemin clair depuis le simple appel d’outils jusqu’à une boucle fermée d’ingénierie complète.

1. Le principal problème d’ingénierie : fichiers fragmentés, outils cloisonnés et chaînes de preuves rompues

Tout ingénieur logiciel expérimenté en groupes motopropulseurs sait qu’un défaut typique d’un système de contrôle provient rarement d’un seul fichier isolé. Prenons l’exemple suivant pour le dépannage :

• Symptôme: En conditions de basses températures, la limite de puissance de charge de la batterie chute de manière inattendue. Ce phénomène s’accompagne de limitations de couple sporadiques et d’un code d’anomalie (DTC) incohérent entre la sortie réelle du contrôleur et les spécifications du système.

Pour diagnostiquer ce problème, un ingénieur doit simultanément ouvrir, analyser et recouper un ensemble de données massif et fragmenté :

[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)

Les quatre niveaux de fragmentation

Ce flux de travail met en évidence une fragmentation importante selon quatre dimensions distinctes :

1. Fragmentation au niveau des fichiers : Les exigences résident dans Word ou IBM DOORS ; la logique de contrôle réside dans des modèles MATLAB Simulink (.slx) et les diagrammes Stateflow ; les interfaces de bus sont définies dans .dbc ou .arxml; les adresses mémoire sont définies dans .a2l; les scripts de test sont écrits en CAPL ou en Python ; les journaux de test existent dans .mdf, .dat, ou .csv fichiers.
2. Isolation de la chaîne d’outils : Les ingénieurs doivent constamment changer de contexte. Ils passent de MATLAB/Simulink (conception de modèles) à Vector CANoe (simulation de bus), Vector CANape ou TsMaster (étalonnage/mesure), Excel (cartographie des données) et aux outils de suivi des problèmes internes basés sur le Web (Jira).
3. Incohérence sémantique : La même variable physique (telle que le courant de charge cible de la batterie) pourrait être nommée Courant_de_variation_cible dans les spécifications fonctionnelles, bms_I_cible dans l’espace de travail du modèle Simulink, Courant cible BMS dans la base de données des signaux CAN DBC, et Limite de courant P_BMS_Chg_Curr Dans le fichier d’étalonnage A2L, les fréquences d’échantillonnage, les facteurs d’échelle, les unités et les plages de valeurs valides diffèrent souvent.
4. Chaînes de preuves manquantes : Une IA générative peut facilement suggérer une cause racine hypothétique. Cependant, si cette suggestion ne peut pas pointer vers une milliseconde précise dans un journal, une transition de signal spécifique dans une trace, un chemin spécifique dans un modèle Simulink ou un identifiant de cas de test spécifique, elle ne peut être acceptée comme une conclusion d’ingénierie.

La question n’est pas de savoir si le LLM est intelligent. La question est : Quelle est la place de l’agent IA dans la chaîne d’outils MBD, comment accède-t-il aux fichiers, quand est-il autorisé à exécuter des scripts et quand doit-il s’arrêter pour rendre le contrôle à un ingénieur humain ?

2. Les limites de l’automatisation traditionnelle face à la frontière de l’agentivité

Les services logiciels de l’industrie automobile utilisent depuis des décennies des scripts automatisés (API MATLAB, analyseurs DBC Python, suites de tests CAPL, pipelines CI/CD Jenkins et macros Excel). Ces outils sont hautement déterministes, reproductibles et entièrement auditables.

Cependant, leur utilisation engendre des coûts élevés liés aux changements de contexte. Un script Python peut analyser un fichier DBC et un script MATLAB peut effectuer une vérification de modèle, mais ils ne partagent pas le même contexte sémantique.

La matrice suivante définit les limites des scripts d’automatisation traditionnels et le rôle des agents d’IA :

Artefact d’ingénierie	Limites de l’automatisation traditionnelle	La frontière de l’agent IA
Simulink / Stateflow	Les scripts exécutent des vérifications statiques des règles de conception (comme Model Advisor) et génèrent des rapports XML. Cependant, l’interprétation de ces rapports et l’établissement du lien entre les échecs et les exigences système nécessitent toujours une intervention manuelle.	L’agent lit le rapport du conseiller en modèles et la spécification d’origine, cartographie les défaillances et génère une liste priorisée des problèmes d’ingénierie. jamais modifie directement les fichiers du modèle.
DBC / A2L / MDF	Les scripts Python ou CANape peuvent extraire des listes de signaux, mais le mappage des variables entre DBC et A2L oblige les ingénieurs à maintenir des tables de conversion Excel manuelles et fragiles.	L’agent résout dynamiquement les incohérences de mappage sémantique en analysant les facteurs d’échelle, les types de données, les unités physiques et les versions des paramètres d’étalonnage à travers DBC, A2L et les modèles.
CANOË / CAPL	Les bancs d’essai automatisés exécutent des scripts de test et exportent des rapports de test au format HTML. Cependant, identifier la cause première d’un échec nécessite une analyse manuelle des journaux.	L’agent analyse la trace de test CANoe et les fichiers journaux CAPL, isole l’horodatage exact de la défaillance, le met en corrélation avec les codes de diagnostic et rédige des corrections de script CAPL.
Spécifications requises	Les scripts standard peuvent vérifier si un document d’exigences comporte un champ ID, mais ils ne peuvent pas évaluer la clarté du texte ni cartographier la couverture des tests.	L’agent extrait les critères d’acceptation fonctionnelle, les associe aux points de test réels et génère une ébauche de matrice de traçabilité de bout en bout.
Outils Web internes	Les ingénieurs doivent copier et coller manuellement les journaux de suivi ou les codes d’erreur de diagnostic dans Jira, Confluence ou les bases de connaissances internes.	L’agent utilise des outils de recherche et de récupération pour analyser les bases de données internes, recouper les journaux d’incidents historiques et enregistrer les références en parallèle des URL sources.

3. Architecture de référence : LLM au niveau de l’orchestration

Pour déployer en toute sécurité des agents d’IA dans le développement de systèmes critiques pour la sécurité (tels que les pipelines logiciels ISO 26262 ASIL-D), le LLM doit résider strictement dans le Couche d’orchestration, complètement isolé du Boucle d’exécution de sécurité.

    ┌────────────────────────────────────────────────────────┐
    │                  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│  │
    │  └───────────────────────┘   └───────────────────────┘  │
    └────────────────────────────────────────────────────────┘

Des frameworks comme OpenClaw définir les outils comme des fonctions structurées que l’agent peut invoquer (exécution, récupération Web, recherche locale, messagerie). De même, Agent Hermès utilise un environnement sandbox local pour exécuter les utilitaires système en toute sécurité.

Pour les logiciels automobiles, nous devons établir cinq garde-fous de sécurité absolus :

1. Mise en sandbox du stockage en lecture seule : L’agent doit fonctionner sur un instantané en lecture seule ou sur une branche git dédiée de l’espace de travail (./project_snapshotIl ne doit jamais avoir d’accès en écriture aux branches de production, aux clés cryptographiques ou aux référentiels de base propriétaires.
2. Appel d’outils autorisés : L’agent ne peut pas exécuter de commandes shell brutes. Il doit interagir avec l’écosystème d’ingénierie en invoquant une liste blanche de scripts d’exécution Python ou MATLAB pré-écrits et déterministes.
3. Journalisation des contraintes d’exécution : Chaque exécution de script doit se dérouler dans un répertoire spécifique, respecter les délais d’exécution et capturer automatiquement toutes les données. sortie standard, erreur standardLes journaux contiennent les codes de sortie et les hachages des fichiers d’entrée. Ces informations sont conservées dans une piste d’audit inaltérable.
4. Profils de navigateur isolés : Pour la récupération sur le Web (par exemple, la recherche de définitions de normes ASAM ou la consultation de tableaux Jira internes), l’agent doit utiliser un profil de navigateur dédié, totalement isolé des informations d’identification SSO personnelles ou d’entreprise.
5. Ségrégation des locataires de la base de connaissances : Lors de la connexion à des bases de données de génération augmentée par récupération (RAG) contenant des directives d’étalonnage propriétaires ou des données de débogage de projets antérieurs, le système doit appliquer un contrôle d’accès basé sur les rôles (RBAC) strict pour empêcher les fuites de propriété intellectuelle entre clients.

4. Intégration étape par étape : mappage de l’agent à la chaîne d’outils MBD

Examinons comment un agent d’IA exécute un flux de travail MBD complet en quatre étapes.

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)

Étape 4.1 : Élaboration de la matrice de spécification des exigences pour les tests

L’agent ingère les documents de spécifications (tels que les fichiers Markdown ou JSON exportés depuis DOORS). Il analyse chaque clause fonctionnelle pour en extraire :

• Conditions préalables (par exemple, Température de la batterie < -10 °C)
• Entrées actives (telles que Charge_Plug_Detected == TRUE)
• Résultats attendus du système (tels que Limite de courant de charge maximale == 15A)
• Affections diagnostiques associées.

Au lieu d’essayer d’écrire le code final, l’agent génère un flux structuré Projet de matrice de test au format JSON, définissant des points de validation explicites pour les tests MIL/SIL/HIL ultérieurs.

Étape 4.2 : Vérification du modèle pour l’émission des listes de contrôle

L’agent est bloqué et ne peut pas modifier les modèles Simulink (.slx) ou directement des diagrammes Stateflow. Au lieu de cela, il exécute un script MATLAB local via l’interface de ligne de commande. Ce script d’exécution :

1. Ouvre MATLAB dans une session sans interface graphique.
2. Exécute des vérificateurs de règles de conception statiques personnalisés (tels que la vérification des conventions d’appellation ou la recherche de ports de signal non liés).
3. Exporte un rapport de diagnostic structuré.

L’agent lit ce rapport, le compare aux directives de conception logicielle et génère une liste de contrôle structurée mettant en évidence les erreurs (telles que le diagramme de flux d’état). Gestionnaire de frais « manque un chemin de transition par défaut ».

Étape 4.3 : Cartographie sémantique des champs DBC, A2L et d’étalonnage

Cette étape associe les signaux de communication physiques à la mémoire interne du contrôleur. L’agent fait appel à un analyseur Python dédié pour lire le fichier CAN DBC et le fichier A2L du contrôleur.

Il construit ensuite une table de correspondance des variables unifiée et vérifie les divergences critiques :

[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]