Percée en automatisation accélère le développement des contrôles pour véhicules électriques
Dans un domaine où les millisecondes peuvent faire la différence entre des performances optimales et une latence système, la course pour rationaliser le développement des véhicules électriques (VE) n’a jamais été aussi urgente. Alors que l’électrification redessine le paysage automobile, les ingénieurs sont sous une pression immense – non seulement pour innover plus rapidement, mais pour le faire de manière fiable, sûre et à grande échelle. Dans ce contexte, une nouvelle méthodologie, récemment dévoilée dans une étude publiée dans le Journal de l’Université de Technologie de Chongqing (Sciences Naturelles), attire une attention sérieuse des milieux universitaires et industriels pour sa promesse de réduire le temps de développement, de diminuer les erreurs humaines et de standardiser l’intégration de logiques de contrôle complexes dans le matériel réel.
Au cœur de cette innovation se trouve une fusion transparente entre la conception de stratégies de contrôle de haut niveau et la configuration des pilotes embarqués de bas niveau – deux domaines historiquement et obstinément cloisonnés. Traditionnellement, le développement d’une unité de contrôle de véhicule (VCU), le « cerveau » de tout véhicule électrique pur, suit un workflow en V : les ingénieurs conçoivent la logique de contrôle de la couche applicative (par exemple, l’arbitrage de couple, la logique de changement de vitesse), la simulent abondamment, génèrent du code automatiquement (souvent via MATLAB/Simulink), puis cousent manuellement cette logique avec les pilotes matériels sous-jacents – codés séparément pour des microcontrôleurs comme les séries STM32. Cette étape finale d’intégration, truffée de incohérences de variables, de dérives de version et d’erreurs de saisie manuelle, a longtemps été un goulot d’étranglement.
L’approche nouvellement proposée renverse la situation. Au lieu de générer le code applicatif et le code des pilotes dans des environnements disjoints, l’équipe – dirigée par Huan Shen, Jianguo Mao, Fuliang Zhou, Wei Chen et Zhiwei Yan du Collège d’Ingénierie de l’Énergie et de la Propulsion de l’Université d’Aéronautique et d’Astronautique de Nanjing – a démontré un workflow entièrement co-simulé et co-généré. Leur méthode exploite deux outils étroitement couplés de STMicroelectronics et MathWorks : STM32CubeMX et STM32-MAT/TARGET, ce dernier étant un package d’intégration officiel pour Simulink qui traduit les configurations des périphériques au niveau de la puce en blocs Simulink glisser-déposer.
Imaginez : autrefois, construire une VCU moderne était comme assembler une voiture de sport haut de gamme dans deux garages séparés – un pour le moteur et la transmission, un autre pour le châssis et l’électronique – avec des ingénieurs faisant la navette, espérant que les points de montage et les faisceaux de câbles correspondent. Désormais, avec ce workflow, c’est comme si le véhicule entier sortait d’une seule et unique ligne d’assemblage synchronisée – moteur, ECU, capteurs et actionneurs tous modélisés, simulés et compilés dans un environnement unifié.
Les implications sont substantielles – pas seulement pour l’efficacité, mais pour la sécurité et l’évolutivité.
Décomposons ce à quoi cela ressemble concrètement. Les chercheurs ont sélectionné le STM32F407ZGT6, un microcontrôleur 32 bits ARM Cortex-M4 largement utilisé dans le prototypage automobile et les ECU de production de milieu de gamme. Plutôt que d’écrire du code C au niveau des registres pour les convertisseurs analogique-numérique (ADC), les entrées/sorties à usage général (GPIO) ou la communication UART, ils ont d’abord configuré tous les périphériques matériels – assignations de broches, arbres d’horloge, taux d’échantillonnage, priorités d’interruption – visuellement dans STM32CubeMX. Une fois exportée, cette configuration était automatiquement importée dans Simulink sous forme de bibliothèque de blocs prêts à l’emploi : ADC_Read, GPIO_Read, UART_TX, etc.
Ces blocs n’étaient pas des ébauches ou des espaces réservés ; ils étaient des représentations fonctionnellement précises des vrais pilotes matériels. Cela signifiait que lorsque l’équipe construisait sa logique de couche applicative – couvrant des fonctions critiques comme la séquence de mise en marche/arrêt du véhicule, la gestion de l’état des vitesses, l’interprétation des signaux des pédales et l’arbitrage du couple – elle pouvait câbler de vraies entrées de capteurs (par exemple, la position de la pédale d’accélérateur, l’état du frein, les signaux du sélecteur de vitesse) directement dans des blocs algorithmiques sur la même toile de modélisation. Finis les suppositions sur les types de données ou les facteurs d’échelle. Finis les tailles de tampon non alignées ou les appels d’initialisation manqués.
Un aspect particulièrement élégant de la stratégie réside dans la façon dont elle gère l’enchaînement des états – un aspect notoirement difficile du contrôle des VE. Prenons le processus de mise sous tension du véhicule. Il doit suivre un ordre strict « basse tension d’abord, puis haute tension » pour éviter des arcs électriques catastrophiques ou des dommages à l’électronique sensible comme le système de gestion de batterie (BMS) ou l’onduleur du moteur. Dans les workflows conventionnels, cette séquence serait codée de manière procédurale : une série de vérifications if-else, de déclencheurs temporels et de bascules de drapeaux – difficile à visualiser, encore plus à vérifier.
Ici, l’équipe a modélisé les flux de puissance montants/descendants comme des machines à états embarquées dans Simulink, avec des transitions régies non seulement par des conditions logiques, mais aussi par des signaux matériels en temps réel tirés de la couche virtuelle des pilotes. Par exemple, lorsque le signal GPIO simulé « KEY_ON » passait à l’état haut, le modèle déclenchait la VCU pour réveiller le BMS (via un signal CAN virtuel ou discret), attendait un acquittement « BMS_OK » (simulé comme une constante 0 dans ce prototype), puis commandait le relais de précharge. Le système surveillait continuellement une « tension contrôleur » simulée (alimentée par un bloc ADC imitant la lecture d’un diviseur de tension) et ne fermait le contacteur principal qu’une fois la différence de tension entre le contrôleur et la batterie tombée en dessous de 15 volts – reproduisant la logique de précharge réelle.
Point crucial, ce n’était pas qu’un simple théâtre de simulation. Une fois le modèle complet – logique applicative entrelacée avec les pilotes matériels – assemblé, l’équipe a utilisé Real-Time Workshop (RTW) de Simulink pour générer automatiquement un projet C complet, prêt à compiler pour Keil µVision (un IDE de développement ARM standard). En arrière-plan, MATLAB invoquait STM32CubeMX via l’automatisation COM, garantissant que le code généré restait parfaitement synchronisé avec la couche d’abstraction matérielle (HAL) configurée. Aucune édition manuelle. Aucune incohérence de copier-coller. Un clic, une base de code cohérente.
Puis vint le vrai test : le déploiement.
Les chercheurs ont construit un banc d’essai semi-physique. Des potentiomètres mécaniques remplaçaient les pédales d’accélérateur et de frein. Des boutons-poussoirs tactiles imitaient les positions de la clé (OFF/ON/START) et les sélecteurs de vitesse (D/N/R). Ceux-ci envoyaient de vrais signaux analogiques et numériques vers les broches physiques de la carte STM32 – aucune entrée simulée ici. Pendant ce temps, un PC hôte basé sur LabVIEW surveillait la télémétrie UART en flux continu en provenance de la VCU, enregistrant en temps réel les horodatages, les drapeaux d’état, les demandes de couple et les lectures de tension.
Les résultats étaient frappants – non pas parce que la VCU effectuait de nouvelles fonctions, mais parce qu’elle exécutait des fonctions connues de manière impeccable et prévisible dès le premier démarrage.
Dans une séquence de test, à 1,3 seconde, le bouton « KEY_ON » était pressé. En quelques millisecondes, la VCU déclenchait le signal de réveil du BMS et fermait le relais de précharge (PreRelay = 1). Alors que l’opérateur tournait lentement le potentiomètre de « tension contrôleur », le système restait en mode précharge – en attente – jusqu’à ce que la tension simulée atteigne 85 V (contre une batterie fixe de 100 V), moment auquel, précisément comme conçu, le relais de précharge s’ouvrait (PreRelay = 0) et le relais principal se fermait (MainRelay = 1). Mise sous tension basse tension terminée.
Puis, à 3,9 secondes, « KEY_START » était actionné. La VCU activait le contrôleur de moteur (MCU_Enable = 1), vérifiait l’absence de défaut et activait le convertisseur DC/DC. Le système entrait en mode « Prêt » – témoins allumés, aucune erreur, groupe motopropulseur amorcé. Toutes les transitions correspondaient à la chronologie et aux dépendances logiques attendues. Aucune étape manquée. Aucune condition de concurrence.
Plus révélateur encore était la simulation de conduite dynamique. À 1,2 seconde, le sélecteur de vitesse passait de Neutre à Drive. La VCU confirmait que la vitesse du véhicule était inférieure à 8 km/h (un verrouillage de sécurité pour l’engagement avant) et autorisait le changement. Puis, à 1,4 seconde, l’accélérateur était pressé à 30% – et le couple augmentait progressivement, initiant un mouvement avant dans le modèle de dynamique simulé.
Le vrai test de résistance survint à 2,3 secondes : un passage direct de Drive à Reverse tout en roulant encore vers l’avant à 5 km/h. La sagesse conventionnelle – et de nombreux ECU de production – rejetteraient cela comme dangereux. Mais l’équipe avait explicitement encodé une autorisation de changement bidirectionnel à basse vitesse (≤8 km/h) pour améliorer la maniabilité urbaine sans compromettre la sécurité. Et le système a obtempéré : le couple a inversé son signe, la décélération a commencé, la vitesse est tombée à zéro et le mouvement arrière a commencé – sans accroc, sans désengagement.
Ensuite, le moment décisif : à 5,0 secondes, la pédale de frein était pressée. Instantanément – dans le même cycle de contrôle – la commande de couple tombait à zéro, quelle que soit la position de l’accélérateur. Cette « priorité absolue au freinage » est une exigence de sécurité non négociable, imposée mondialement. Le fait qu’elle se soit déclenchée immédiatement, même lors d’une accélération aggressive, validait non seulement la logique, mais aussi le déterminisme en temps réel du code auto-généré. Plus tard, à 18,2 secondes, une autre application des freins surchargeait une entrée pleine accélération avec une fiabilité identique – un comportement essentiel pour les interventions d’urgence.
Ce qui ressort n’est pas une IA tape-à-l’œil ou un matériel exotique. C’est la rigueur. C’est l’élimination du mode de défaillance le plus évitable dans le développement automobile embarqué : l’erreur de transcription humaine. Combien de rappels sur le terrain ont découlé d’une faute de frappe dans un facteur d’échelle de signal CAN ? D’une initialisation manquée d’un watchdog ? D’un décalage de version entre une mise à jour d’algorithme et sa dépendance HAL ?
Ce travail contourne ces risques par conception. Lorsque le modèle Simulink est le cahier des charges, et que le code est le modèle – compilé en entier, sans intervention manuelle – le chemin du concept au silicium devient auditable, reproductible et certifiable. C’est une musique aux oreilles des ingénieurs de sécurité fonctionnelle travaillant sous ISO 26262. La traçabilité s’améliore. La couverture des tests devient plus significative. La réutilisation des modèles across les plateformes de véhicules – disons, d’un VE urbain à une camionnette utilitaire légère – devient réalisable sans des semaines de travail de réintégration.
Les vétérans de l’industrie noteront des parallèles avec la vision d’AUTOSAR d’une architecture logicielle stratifiée et standardisée. Mais là où l’adoption complète d’AUTOSAR reste coûteuse et complexe pour les petits constructeurs ou les startups, cette voie Simulink + STM32-MAT/TARGET offre un terrain d’entente pragmatique : assez rigoureuse pour les fonctions critiques pour la sécurité, mais assez accessible pour le prototypage rapide et la recherche académique.
Bien sûr, l’article reconnaît que sa portée est une preuve de concept. Les signaux de défaut étaient câblés en dur (BMS_Fault = 0, VCU_Fault = 0), simplifiant la validation. Les véhicules réels doivent gérer des dizaines de drapeaux de défaut asynchrones, des courbes de déclassement thermique, la surveillance de l’isolement et des stratégies de mode dégradé – des couches non encore modélisées ici. Et bien que les performances en temps réel aient été vérifiées sur un MCU représentatif, la mise à l’échelle vers des processeurs multi-cœurs ou des architectures à déclenchement temporel (par exemple, pour les systèmes ASIL-D) nécessiterait une intégration plus poussée avec les ordonnanceurs RTOS et les unités de protection mémoire.
Les auteurs eux-mêmes pointent vers la prochaine étape logique : la co-validation matériel-en-boucle (HIL). Comparer la sortie du code embarqué auto-généré avec la simulation hors ligne Simulink originale – pas seulement en logique, mais en fidélité temporelle – permettrait de quantifier le gigue, le temps d’exécution pire cas (WCET) et la latence d’interruption sous charge. Ces données sont essentielles avant un déploiement en production.
Pourtant, les fondations sont solides. Et son timing ne pourrait être meilleur.
Considérez les tendances macro : les startups de VE font face à des demandes brutales d’efficacité capitalistique. Les constructeurs historiques se démènent pour recycler des milliers d’ingénieurs imprégnés de la logique thermique. Les organismes de réglementation renforcent leur scrutiny sur la sécurité définie par logiciel. Dans cet environnement, les outils qui compressent les cycles de développement sans sacrifier la rigueur ne sont pas juste pratiques – ils sont existentiels.
Déjà, des rumeurs suggèrent que des équipementiers de premier rang testent des workflows similaires. Certains étendent le paradigme au-delà des VCU – à la gestion de batterie, aux systèmes thermiques, même aux contrôleurs de direction par câble. Le dénominateur commun ? Gardez le modèle comme autorité. Laissez la machine écrire le code.
Est-ce que cela remplacera l’assemblage optimisé manuellement pour le contrôle moteur à ultra-faible latence ? Probablement pas. Il y aura toujours une place pour un artisanat embarqué de niveau artisanal à la pointe de la performance. Mais pour la grande majorité des fonctions de contrôle du véhicule – gestion d’état, arbitrage de signaux, transitions de mode, séquençage de diagnostic – ce niveau d’automatisation n’est pas seulement viable. Il devient une meilleure pratique.
De retour à Nanjing, la configuration du labo peut sembler modeste : une platine d’expérimentation, quelques potentiomètres, un ordinateur portable exécutant LabVIEW. Mais ce qu’elle représente est bien plus grand : une révolution tranquille dans la façon dont les véhicules intelligents naissent – non pas dans des silos fragmentés de code et de matériel, mais comme des systèmes unifiés, auto-cohérents, vérifiés avant que la première soudure ne refroidisse.
Alors que l’électrification accélère, le goulot d’étranglement n’est plus la chimie de la batterie ou la topologie du moteur. C’est la bande passante ingénierie. Des méthodes comme celle-ci ne font pas que sauver des semaines de migraines d’intégration – elles libèrent un espace cognitif pour que les ingénieurs se concentrent sur ce qui différencie vraiment les véhicules : la sensation de conduite, la nuance de la récupération d’énergie, les stratégies thermiques adaptatives, la résilience des mises à jour over-the-air. L’expérience, pas la plomberie.
Et dans une industrie où la fidélité à la marque dépend désormais autant de la réactivité logicielle que de la dynamique du châssis, ce changement de focus pourrait s’avérer décisif.
Une note finale : le DOI de l’article – 10.3969/j.issn.1674–8425(z).2023.05.002 – n’est pas qu’une note de citation. C’est un point de repère. Un marqueur dans la transition du « code comme artisanat » au « code comme artefact continu et vérifié ». Pour les développeurs aux prises quotidiennement avec la dérive d’intégration et la dette de test, cela vaut le coup d’être mis en favori.
Parce que le futur du contrôle véhicule ne sera pas écrit ligne par ligne en C. Il sera modélisé, simulé et généré – de bout en bout – avec confiance. Et ce futur, grâce à des travaux comme celui-ci, est déjà sur la piste d’essai.
Huan Shen, Fuliang Zhou, Jianguo Mao, Wei Chen, Zhiwei Yan, Collège d’Ingénierie de l’Énergie et de la Propulsion, Université d’Aéronautique et d’Astronautique de Nanjing, Journal de l’Université de Technologie de Chongqing (Sciences Naturelles), DOI : 10.3969/j.issn.1674–8425(z).2023.05.002