Combiner la MBSE et l’approche Model-Based Design pour accélérer le développement des groupes motopropulseurs électriques

Dans l'ensemble de l'industrie des véhicules électriques (VE) et de la e-mobilité, les équipes d'ingénierie responsables du développement des groupes motopropulseurs électriques sont confrontées à un certain nombre de défis communs. Parmi ceux-ci figurent non seulement la complexité croissante des produits, mais également la nécessité de livrer des produits de haute qualité plus rapidement tout en maîtrisant les coûts et en garantissant la conformité des processus aux normes ASPICE, ISO^® 26262 et autres.

Pour relever ces défis, nous avons eu l'opportunité unique de combiner la vaste expérience de nos employés en matière d'e- mobilité avec le démarrage d'une nouvelle entreprise. Nous avons établi un processus de développement allégé avec une chaîne d’outils cohérente qui remédie aux faiblesses que nous avions constatées dans les approches précédentes.

Après une évaluation approfondie des options disponibles, nous avons adopté un workflow combinant MBSE et l’approche Model-Based Design en utilisant les produits MATLAB^® et Simulink^®, ainsi que le logiciel de gestion du cycle de vie des applications (ALM) Polarion™. Le processus d’ingénierie système selon ASPICE est illustré dans la figure 1. Ce workflow présente déjà des avantages avérés dans plusieurs domaines. Il nous permet de travailler à partir d’une source unique et fiable et de parvenir à une réutilisation substantielle des produits de travail dans toutes les disciplines et tous les projets. De plus, il permet à nos ingénieurs de se concentrer sur le développement de fonctionnalités plutôt que sur la conformité aux processus, tout en établissant la traçabilité des exigences aux architectures, modèles, code et tests. Il est également important de noter qu’il nous permet d’appliquer le paradigme du « décalage vers la gauche » à l’ingénierie des systèmes, ce qui rend possible l’analyse du comportement dynamique du système au niveau du système et, en particulier, l’identification précoce des erreurs de spécification dans le processus global.

Modélisation de l’architecture système avec System Composer

Dans les processus classiques de développement de produits, les erreurs de spécification du système sont souvent identifiées pour la première fois lorsque les prototypes sont disponibles et lorsqu'ils sont testés par rapport à la spécification du système. Cela entraîne généralement des coûts de correction d’erreurs élevés et conduit partiellement à des retards critiques dans le projet. Afin d’éviter ces coûts supplémentaires et imprévisibles dus à des erreurs de spécification au niveau du système, nous cherchons à vérifier l’exactitude de la spécification le plus tôt possible dans le processus. Dans notre workflow, nous utilisons System Composer™ pour définir des architectures système simulables, ce qui nous permet de décaler en amont les activités de test et de validation et de les automatiser avec des pipelines CI, comme indiqué également dans la figure 1.

De plus, nous maintenons une correspondance exacte entre les composants du système et leurs composants d’architecture logicielle correspondants dans System Composer et Simulink, ce qui permet d’analyser le comportement dynamique au niveau système. Ainsi, les modèles comportementaux au niveau système peuvent être utilisés comme une ébauche par les ingénieurs logiciels, qui réutilisent non seulement les interfaces mais aussi les modèles comportementaux définis dans l’architecture système comme point de départ lors du développement de designs détaillés pour la production logicielle dans Simulink. De plus, il existe une réutilisation élevée des modèles et les environnements de simulation sont largement réutilisés entre les départements. Par exemple, le même modèle de système physique pour les simulations et tests en boucle fermée est utilisé dans le département système, hardware et logiciel, et peut également s’exécuter directement sur notre système HIL Speedgoat^® en temps réel. Un schéma décrivant les dépendances est présenté dans la figure 2.

De plus, nous utilisons Requirements Toolbox™ et le Connecteur Polarion pour Simulink pour relier les exigences gérées dans Polarion aux éléments architecturaux définis dans les modèles System Composer. Nous relions également les éléments de design détaillés au sein des modèles Simulink des implémentations logicielles grâce à ce connecteur. Cette configuration permet une traçabilité bidirectionnelle entre la spécification et l’implémentation sans synchronisation manuelle, facilitant la collaboration entre des équipes multidisciplinaires et contribuant à garantir la cohérence tout au long du cycle de développement.

Modélisation physique avec Simscape

Les simulations en boucle fermée au niveau système, logiciel ou hardware, nécessitent un modèle physique du groupe motopropulseur du véhicule électrique. Nous avons créé ce modèle dans Simscape™ et Simscape Electrical™. La figure 3 présente une vue d'ensemble. Ce modèle multidomaine comprend des composants modulaires pour la batterie de la transmission, le câble CC, le filtre d'interférence électromagnétique (EMI), l'onduleur, le jeu de barres CA, les entraînements électriques, les modèles de charge et le refroidissement. Dans ce modèle, nous pouvons également intégrer des modèles d'ordre réduit pour les effets thermiques et électromagnétiques provenant d'outils CAE comme Ansys Maxwell afin de préserver les temps de simulation prévus.

Pour permettre à nos ingénieurs de sélectionner le niveau de fidélité pour tout composant du cas d'utilisation de simulation actuel, nous avons implémenté un système de gestion de variant utilisant des variants de modèle. Par exemple, en utilisant Variant Manager for Simulink, une équipe peut choisir d’exécuter des simulations de base avec un bloc de variant qui modélise la batterie comme une source de tension constante simple. Par le suite, il est possible de passer aux variants RC ou RL du circuit de la batterie pour examiner respectivement les comportements capacitifs à basse fréquence ou les comportements inductifs à haute fréquence. De même, nos ingénieurs peuvent utiliser un variant simple de source de tension contrôlée pour l’onduleur afin d’accélérer la simulation ou choisir un variant de plus haute fidélité avec un comportement de commutation réaliste pour évaluer les effets PWM. Un exemple de gestion de ces variants dans le Variant Manager est présenté à la figure 4.

Simulation en boucle fermée, génération de code et tests HIL en temps réel

Avec l’architecture système définie dans System Composer et le modèle de système physique détaillé en place, il est possible pour nous d’exécuter des simulations en boucle fermée à plusieurs niveaux à l’aide de modèles de comportement du système, de modèles d’architecture logicielle ou de modèles de design détaillés dans Simulink, comme illustré à la figure 5.

Cela nous permet de « déplacer vers la gauche » nos activités de validation qui sont déjà au niveau système, minimisant ainsi les erreurs de spécification des fonctions complexes du système d’entraînement.

Dans cet environnement, nous pouvons analyser le comportement du produit au niveau système en utilisant MATLAB, ainsi que le Data Inspector, pour visualiser les signaux, les indicateurs de performance et les relations temporelles. Un exemple des résultats de simulation en boucle fermée de notre architecture système pour analyser le comportement de contrôle du courant d'une commande vectorielle peut être vu à la figure 6. Des tests automatisés peuvent être exécutés dans cette configuration en boucle fermée au niveau système ou pour des composants architecturaux dédiés à l'aide de Simulink Test™. De plus, ces résultats de tests sont automatiquement synchronisés avec Polarion pour permettre un suivi et un reporting actualisés du projet par rapport à la spécification des cas de test.

Cette approche de développement cohérente ne s’arrête pas aux limites du domaine mais continue au-delà. Au fur et à mesure que nous progressons dans les différentes étapes du cycle en V, en progressant de la spécification système à la spécification logicielle, à l’architecture, à l’approche Model-Based Design et à l’implémentation, le processus s'étend naturellement vers la génération de code ainsi que les tests MIL, PIL et HIL. Ici, nous utilisons Embedded Coder^® pour générer du code à partir de nos modèles d’architecture logicielle ou de design détaillé dans Simulink, l’intégrer dans une pile AUTOSAR^® et le déployer sur un microcontrôleur Infineon^® AURIX™ TC3xx. Le modèle de système physique déjà présenté est ensuite déployé sur un FPGA d’une machine cible Speedgoat temps réel à l’aide de HDL Coder™ et Simulink Real-Time™. Cette configuration permet de vérifier le bon comportement logiciel du produit final sur un HIL. De plus, afin d'exploiter les synergies et de réduire les coûts d’équipement et de développement, la même plateforme HIL est utilisée pour réaliser les tests d’intégration et de vérification du système avant les tests finaux sur banc d’essai.

Avantages réalisés et améliorations continues de l'intégration

Notre approche, basée sur le workflow et la chaîne d’outils, a été validée lors du développement d’un onduleur 800 V à base de carbure de silicium, capable de délivrer jusqu’à 600 kilowatts de puissance de pointe pour des applications de traction automobile. La participation au programme MathWorks Startup nous a aidés à réduire le temps de commercialisation de ce produit tout en maîtrisant les coûts, un impératif pour pratiquement toutes les jeunes entreprises.

Nous continuons à étendre et à améliorer notre workflow. Par exemple, nous utilisons déjà l'intégration continue (CI) avec Jenkins^® et Bitbucket^® pour effectuer en continu des tests unitaires, d'intégration et de vérification de logiciels. Nous travaillons également à étendre ce workflow d’automatisation basé sur l’intégration continue (CI) plus en amont du cycle en V afin de permettre la vérification automatisée basée sur CI de nos architectures système.