Conception basée sur des modèles pour les ingénieurs en simulation en temps réel

Principaux enseignements

• La conception basée sur des modèles donne les meilleurs résultats lorsque les modèles restent exécutables tout au long des phases de conception, de génération de code et de tests HIL, au lieu de s'arrêter à l'étape de la conception.
• La gestion des délais, les contrats d'interface et la traçabilité des exigences sont plus importants que les détails du modèle lorsque l'on se prépare à une exécution en environnement de test fiable.
• Le développement automobile traditionnel repousse les risques liés à l'intégration à un stade tardif, tandis qu'un partitionnement rigoureux des modèles et une validation traçable permettent de détecter les défaillances plus tôt.

La conception basée sur des modèles réduit les risques liés à la validation lorsque votre modèle de simulation devient l'élément même que vous exécutez en HIL.

Les équipes perdent du temps lorsque les modèles restent bloqués au stade des premières phases de conception et ne parviennent jamais à devenir des ressources de test reproductibles. Les accidents de la route ont causé 20 400 décès dans l’Union européenne en 2023, ce qui lie la discipline de validation à la sécurité publique plutôt qu’à une préférence de processus. Vous aurez besoin d’un workflow qui assure la visibilité du calendrier, des interfaces et des preuves de conformité aux exigences avant que le code n’atteigne le banc d’essai.

La conception basée sur des modèles transforme les modèles de simulation en ressources de test exécutables

La conception basée sur des modèles pour la simulation permet de transformer vos modèles d'installation et de contrôle en ressources de test exécutables qui restent utiles depuis les premières phases de conception jusqu'à la validation HIL. La valeur ajoutée réside dans une réutilisation rigoureuse. Vous détecterez plus rapidement les défauts d'interface et de synchronisation, car le même comportement est testé à chaque étape.

Une équipe de contrôle des moteurs permet d'obtenir rapidement ce résultat. Le modèle de contrôleur commence par un concept de contrôle, est ensuite testé sur un modèle d'installation pour le réglage en boucle fermée, alimente ensuite la génération de code, puis est exécuté avec injection de défauts sur un rack HIL. Vous n'avez plus besoin de redéfinir l'intention à chaque étape. Vous affinez une seule description exécutable du comportement.

Ce changement est important, car chaque transfert de responsabilité augmente le risque d'erreurs d'interprétation. Si le limiteur de courant, la mise à l'échelle des capteurs et la synchronisation de la machine à états sont déjà intégrés au modèle, vous pourrez détecter les incohérences avant même que le matériel ne soit disponible. Vous pourrez également rédiger des cas de test plus précis, car le modèle expose d'emblée les états de fonctionnement normaux et anormaux, au lieu de les laisser enfouis dans des documents distincts.

Le modèle en V relie la conception des contrôles aux preuves de validation

Le modèle en V revêt une importance particulière dans le secteur automobile, car il associe chaque choix de conception à une activité de validation correspondante. La conception basée sur des modèles s'inscrit dans cette structure lorsque chaque exigence, chaque élément de modèle et chaque cas de test restent interconnectés. Ce lien transforme la validation, qui n'est plus un simple point de contrôle en fin de processus, en une chaîne de preuves que l'on peut examiner.

Les exigences en matière de gestion des batteries constituent un exemple clair. Une règle de déclassement en fonction de la température apparaît d'abord à gauche du V en tant qu'exigence du système, puis se traduit par une logique dans le modèle du contrôleur, avant de réapparaître à droite sous forme de tests MIL, SIL et HIL avec des limites de réussite définies. Les ingénieurs en validation n'ont pas à deviner ce que prouve un test, car le cheminement reste visible.

« La conception basée sur des modèles pour la simulation signifie que vos modèles d'installation et de commande deviennent des ressources de test exécutables qui restent utiles depuis les premières phases de conception jusqu'à la validation HIL. »

Le modèle V ne suffit pas à lui seul à corriger les mauvaises habitudes de modélisation. Il prend tout son sens lorsque vos modèles sont suffisamment précis pour étayer les vérifications lors des revues de conception. C'est pourquoi les ingénieurs en validation accordent autant d'importance à la traçabilité que les ingénieurs en contrôle-commande aux performances de contrôle.

Commencez par des cas d'utilisation en boucle fermée avant de peaufiner le modèle

Les cas d'utilisation en boucle fermée doivent précéder l'affinement du modèle, car ils permettent de déterminer quels comportements doivent fonctionner correctement dans des conditions de contrainte temporelle. Un modèle détaillé dépourvu d'objectif de test ne servira à rien. Vous passerez des semaines à peaufiner des dynamiques qui n'auront aucune incidence sur la question de validation à laquelle vous cherchez réellement une réponse.

Un programme de direction assistée électrique illustre bien cette séquence. Commencez par l'aide au stationnement, la correction de trajectoire, la superposition de couple et la récupération après défaillance des capteurs. Ces cas d'utilisation définissent la bande passante de couple, la dynamique de la crémaillère de direction et les simulations de défaillance que le modèle doit prendre en charge. Le système physique n'a besoin que d'un niveau de détail suffisant pour mettre en évidence le comportement du contrôleur dans ces conditions.

Cette approche permet de conserver la pertinence du modèle pour les essais HIL. Si le prochain objectif de banc d'essai est la récupération après défaillance en moins de 20 millisecondes, vous affinez les éléments qui influent sur le temps de récupération et vous remettez les détails secondaires à plus tard. Vous délimitez ainsi le champ d'application de la tâche à accomplir en boucle fermée, ce qui permet de maîtriser le coût d'exécution et de renforcer la fiabilité des résultats de validation.

Les flux de travail HIL commencent par l'établissement de budgets temporels plutôt que par des schémas fonctionnels

Les processus de travail HIL doivent commencer par la définition des budgets de temps, car l'exécution en temps réel échoue en raison de la latence bien avant d'échouer à cause de la structure visuelle du modèle. Votre schéma fonctionnel peut paraître impeccable tout en ne respectant pas les délais. Les budgets de temps vous obligent à définir les temps d'échantillonnage, les délais d'E/S et les limites de calcul avant que le modèle n'atteigne la cible.

Un banc d'essai pour onduleurs de traction met clairement le problème en évidence. La boucle de commande fonctionne à 50 microsecondes, la réponse de l'installation à 1 microseconde, et la mise à jour des E/S à un autre intervalle fixe. Si le traitement des signaux, la communication et l'enregistrement des données accaparent une trop grande partie de ce temps, on ne peut pas se fier aux résultats des tests, même si la logique de commande est correcte.

C'est pourquoi les équipes HIL performantes gèrent le temps comme s'il s'agissait d'une ressource matérielle. Vous répartirez les tâches plus tôt, réduirez la journalisation superflue et séparerez la logique de supervision, plus lente, des boucles rapides. Si vous remettez ces choix à plus tard, lors de l'intégration finale, les dépassements de temps sembleront aléatoires et le débogage se transformera en une longue recherche à travers les outils, le matériel et la structure du modèle.

Les modèles Simulink doivent disposer d'interfaces explicites avant leur déploiement en temps réel

Les modèles Simulink se déploient sans problème sur des cibles en temps réel lorsque les interfaces sont explicites, fixes et vérifiables avant le début de l'exécution. La rigueur des interfaces prime sur la taille du modèle. Si vos E/S, unités de mesure, états de démarrage et indicateurs de défaut sont ambigus, le modèle se compilera, mais échouera lors de la première session HIL significative.

Un contrôleur de freinage en est un exemple courant. La logique peut sembler correcte lors d'une simulation sur ordinateur, mais le déploiement échoue lorsque la mise à l'échelle de la vitesse des roues diffère de la carte d'E/S ou lorsque l'état de démarrage suppose une valeur de capteur qui n'existe jamais en conditions réelles. Les équipes qui utilisent OPAL-RT résolvent généralement ce problème plus tôt en rendant le contrat d'interface visible avant que le modèle ne soit compilé pour la cible.

• Définir la fréquence d'échantillonnage pour chaque voie d'entrée et de sortie.
• Verrouiller les unités, la mise à l'échelle et les types de données avant la génération du code.
• Définir les états de démarrage pour les blocs « installation » et « contrôleur ».
• Présentez les indicateurs d'erreur sous forme d'entrées testables plutôt que de logique cachée.
• Mappage des E/S de documents où les noms des modèles correspondent aux signaux de référence.

Cette liste de contrôle est courte, mais elle permet d'éviter bien des mauvaises surprises de dernière minute. Vous préparez ainsi le modèle à fonctionner comme un équipement de laboratoire plutôt que comme une simple simulation sur ordinateur. Une fois ces interfaces stabilisées, le déploiement devient une étape de validation plutôt qu'un marathon de débogage.

« La principale différence entre la conception basée sur des modèles et le développement traditionnel axé sur la documentation réside dans le moment où les risques liés à l'intégration apparaissent. »

L'ingénierie des systèmes basée sur des modèles permet d'assurer la traçabilité des exigences tout au long des tests

L'ingénierie des systèmes basée sur des modèles garantit l'intégrité des tests, car elle préserve le lien entre l'intention des exigences, le comportement du modèle et les résultats des tests. Les ingénieurs en validation ont besoin de cette chaîne pour expliquer pourquoi un résultat a été validé ou rejeté. Sans elle, l'exécution des tests génère certes des journaux, mais ne fournit pas de preuve solide.

Une exigence relative au contrôle de charge illustre bien ce point. Cette exigence définit une limite de courant en cas de déclassement thermique ; le modèle système relie cette limite à des signaux et à des modes, et le test HIL vérifie à la fois la valeur limite et le temps de transition après un défaut de température. En cas d'échec du test, il est possible de remonter à la source du problème au niveau de la logique, de l'étalonnage ou de la formulation de l'exigence, plutôt que de se disputer sur la responsabilité.

C'est là que la conception basée sur des modèles et l'ingénierie des systèmes basée sur des modèles se rejoignent. L'une vous fournit un comportement exécutable. L'autre veille à ce que ce comportement reste en adéquation avec l'intention du système. Si vous êtes ingénieur en validation, cette combinaison vous permettra de gagner du temps lors des revues, car chaque test ayant échoué est déjà associé à un contexte, à des hypothèses et à des limites d'acceptation.

Le développement traditionnel masque les risques liés à l'intégration jusqu'aux dernières phases des essais automobiles

La principale différence entre la conception basée sur des modèles et le développement traditionnel axé sur la documentation réside dans le moment où les risques liés à l'intégration apparaissent. La conception basée sur des modèles met en évidence les problèmes liés au comportement, à la synchronisation et aux interfaces alors qu'il est encore possible de réexécuter rapidement le modèle. Les processus traditionnels repoussent bon nombre de ces découvertes vers les essais au banc et sur véhicule, où chaque correction prend davantage de temps.

Un transfert classique illustre bien ce schéma. Les spécifications sont gérées dans un outil, la logique de contrôle dans un autre, et l'équipe HIL reçoit un logiciel compilé sans avoir une vision claire des hypothèses sous-jacentes. Lorsqu'une erreur d'arbitrage de couple survient, l'équipe doit examiner simultanément la documentation, le code et la configuration du banc d'essai. La mauvaise qualité des logiciels a coûté aux États-Unis au moins 2,41 billions de dollars en 2022, ce qui montre à quel point la détection tardive des défauts peut coûter cher lorsque le retour d'information sur l'intégration n'arrive qu'après le transfert de la conception.

Il ne s'agit pas de choisir entre la documentation et les modèles. Les deux sont indispensables. La meilleure approche consiste à faire en sorte que le modèle porte une intention exécutable, puis à utiliser la documentation pour définir les exigences, les hypothèses et les preuves de mise en production. Cette séquence permet de centrer les tests automobiles sur la validation plutôt que sur la reconstruction.

Un mauvais partitionnement du modèle compromet le déterminisme sur les cibles en temps réel

Un mauvais partitionnement du modèle rompt le déterminisme, car les tâches rapides et lentes interfèrent entre elles dès lors qu'elles partagent un chemin d'exécution inadapté. Les applications en temps réel nécessitent une séparation claire entre les détails de l'installation, les boucles de contrôle, les communications et la journalisation. Si cette séparation est insuffisante, les dépassements se dissimuleront au sein de l'activité de test normale et vos résultats ne seront plus fiables.

C'est souvent sur un banc d'essai d'électronique de puissance que ce problème apparaît en premier. Le modèle de commutation doit être traité sur un chemin d'exécution rapide, tandis que le contrôle de supervision, l'interaction avec l'utilisateur et la journalisation des fichiers doivent être traités sur des chemins plus lents. Si vous les placez tous dans une seule partition, une simple modification de la journalisation peut modifier la latence au point de fausser le résultat d'une boucle de courant. Les ingénieurs se retrouvent alors à chercher à résoudre un problème de contrôle qui est en réalité un problème d'ordonnancement.

Une conception basée sur des modèles de qualité repose sur un découpage rigoureux, car le déterminisme fait partie intégrante des preuves de validation et n'est pas une simple note de bas de page technique. Les équipes qui respectent cette rigueur tirent généralement davantage de valeur d'OPAL-RT, car le simulateur est alimenté dès le départ par une structure de modèle qui tient compte de la synchronisation, des interfaces et de l'intention de test. C'est ce qui vous permet d'avoir confiance dans les résultats obtenus sur banc une fois le débogage terminé.