<Retour à Chaîne d’outils de simulation automobile

Auteur: Johnny Liu, PDG de Dowway Vehicle
Publié : 16 mars 2026
Dernière mise à jour : 16 mars 2026
Note du réviseur : Préparé à partir du rapport technique source fourni pour cet article
Type de contenu : analyse technique du secteur
Note relative à la juridiction : Cet article traite des flux de travail en ingénierie automobile dans un contexte mondial, en accordant une attention particulière à la localisation sur le marché chinois et aux pratiques d’ingénierie locales.
Clause de non-responsabilité: Cet article est destiné à la formation en ingénierie et aux discussions au sein de l’industrie. Il ne constitue pas un avis juridique, de certification ou réglementaire.

Réponse directe

Simcenter System Architect (SSA) est une plateforme d’architecture système et de co-simulation de la suite Siemens Simcenter. Pour les équipes du secteur automobile, elle assure la liaison entre les exigences, la conception fonctionnelle, l’architecture physique, la simulation, l’optimisation et la vérification. Ceci est essentiel car les véhicules modernes ne sont plus de simples produits mécaniques. Ce sont des systèmes mécaniques, électriques, électroniques et logiciels étroitement liés qui doivent être conçus et vérifiés comme un tout.

• Le développement des véhicules est passé d’un travail isolé sur les sous-systèmes à une ingénierie système transversale complète.
• SSA permet de relier les exigences, l’architecture, les modèles de simulation et la validation dans un flux de travail unique.
• Ses principaux atouts sont la co-simulation hétérogène, la traçabilité complète, la conception modulaire et l’intégration de la chaîne d’outils.
• Il est parfaitement adapté aux travaux sur les groupes motopropulseurs de véhicules électriques, la gestion thermique, les systèmes ADAS et la validation des contrôleurs de domaine.
• La version chinoise facilite l’apprentissage pour les équipes d’ingénierie locales et soutient les normes locales et la collaboration.

Les programmes automobiles modernes sont de plus en plus difficiles à gérer. L’électrification, la conduite intelligente, la connectivité et les plateformes logicielles complexes ont considérablement accru la complexité des véhicules, la rendant bien plus difficile à appréhender que l’ancien flux de travail basé sur les documents. De nombreuses équipes continuent de travailler avec des outils et des fichiers distincts, ce qui engendre des silos d’information, une lenteur des itérations et des problèmes d’intégration tardive.

C’est là que l’ingénierie système basée sur les modèles (MBSE) prend tout son sens. Elle permet aux équipes de relier les exigences, les fonctions du système, la conception physique, la simulation et la vérification au sein d’une chaîne unique. Dans le rapport que vous avez fourni, Simcenter System Architect occupe une place centrale dans cette chaîne. Il est présenté comme le hub qui relie la conception préliminaire, l’ingénierie détaillée, la vérification par simulation et l’itération de conception tout au long de la chaîne d’outils automobiles.

---

Pourquoi les équipes automobiles ont besoin d’une plateforme système

Le changement majeur dans le développement automobile ne réside pas seulement dans l’ajout de logiciels aux véhicules. Il tient au fait que le produit lui-même est devenu un système complexe. Un véhicule moderne combine :

• systèmes mécaniques tels que le châssis et la carrosserie,
• systèmes électriques tels que les batteries et les moteurs,
• systèmes électroniques tels que les calculateurs et les capteurs, et
• systèmes logiciels tels que la logique de contrôle et les fonctions embarquées.

Ces éléments ne fonctionnent pas indépendamment les uns des autres. Ils interagissent constamment. Un problème thermique peut modifier la puissance de sortie. Une stratégie de contrôle peut affecter la température de la batterie. Un délai de communication peut modifier la réponse au freinage. C’est pourquoi les outils de simulation traditionnels, basés sur un seul domaine, ne suffisent plus à eux seuls.

Le rapport identifie trois problèmes courants dans les flux de travail plus anciens :

• cloisonnement de l’information entre les équipes,
• faible vitesse d’itération, et
• Faible corrélation entre la conception et les performances réelles.

L’architecture système (SSA) se positionne comme l’outil qui résout ces problèmes en utilisant l’architecture système comme couche d’organisation. Au lieu de laisser chaque discipline travailler isolément jusqu’à une intégration tardive, elle permet à l’équipe de construire une vue système unifiée et d’effectuer une validation inter-domaines plus tôt.

---

Que fait Simcenter System Architect dans la chaîne d’outils automobiles ?

SSA fait partie de la chaîne d’outils Siemens Simcenter, mais son rôle diffère de celui d’un solveur ou d’un simulateur de domaine unique. Il ne se concentre pas sur une seule discipline. Son rôle est de connecter :

• exigences,
• architecture fonctionnelle,
• architecture physique,
• modèles de simulation,
• scénarios de validation, et
• résultats de reporting.

C’est pourquoi elle s’intègre parfaitement à l’ingénierie système basée sur les modèles (MBSE) pour l’automobile. Dans un programme de véhicule classique, le flux de travail passe de la définition du concept à la conception des sous-systèmes, puis à la simulation, à la validation et enfin à la gestion du cycle de vie. L’architecture logicielle (SSA) assure la cohérence de ces étapes et garantit la continuité de la logique.

Cela est particulièrement important lorsque les équipes doivent comparer rapidement les options d’architecture, avant même la disponibilité des prototypes matériels. Un schéma statique ne le permet pas. Une feuille de calcul non connectée ne le permet pas non plus. Seule une plateforme d’architecture système avec co-simulation le permet.

---

Principaux avantages de Simcenter System Architect pour l’ingénierie automobile

1. Co-simulation hétérogène multidisciplinaire

Le rapport insiste fortement sur ce point, et à juste titre. Le développement automobile fait intervenir simultanément de nombreuses disciplines. Les ingénieurs châssis, les équipes en charge des groupes motopropulseurs, des batteries, des systèmes de contrôle, des logiciels et les architectes électriques et électroniques utilisent souvent des outils et des formats de modélisation différents.

SSA prend en charge l’intégration de modèles hétérogènes via des interfaces standard telles que FMI/FMU et les flux de travail de type Modelica SSP. Cela inclut les modèles provenant d’outils tels que :

• Simcenter Amesim,
• MATLAB/Simulink, et
• Environnements basés sur Modelica

peuvent être intégrés dans une architecture de simulation système unique sans remaniement important des modèles originaux.

C’est un progrès considérable pour l’ingénierie automobile. Prenons l’exemple d’un véhicule électrique. Le modèle thermique de la batterie peut être géré par Amesim, la stratégie de commande du moteur par Simulink, et d’autres modèles système peuvent provenir d’environnements différents. Grâce à SSA, ces modèles peuvent fonctionner simultanément dans une seule configuration, permettant ainsi aux ingénieurs d’étudier en même temps les flux d’énergie, le comportement thermique et la réponse de la commande.

Cela permet de détecter plus facilement les problèmes au niveau du système avant le début de l’intégration matérielle.

2. Traçabilité complète des exigences basée sur l’ingénierie système basée sur les modèles (MBSE)

Le rapport souligne également un second problème du développement automobile : les exigences sont souvent dissociées de la conception et de la validation. Les équipes peuvent commencer par un document d’exigences, puis utiliser des outils de conception et de simulation qui ne sont pas étroitement liés à l’objectif initial. En cas de problème, remonter à l’exigence concernée devient alors long et complexe.

SSA répond à ce besoin en prenant en charge l’importation, la décomposition, l’allocation et la traçabilité des exigences. Une cible de véhicule de niveau supérieur peut être divisée en cibles de sous-systèmes et de composants, puis associée à des modèles d’architecture, des cas de simulation et des résultats de validation.

Un bon exemple tiré du rapport est celui d’une cible de freinage d’urgence automatique telle que :

Temps de réponse AEB ≤ 100 ms

Cette exigence peut être attribuée à :

• perception,
• décision, et
• sous-systèmes d’actionnement.

À partir de là, les ingénieurs peuvent vérifier si l’architecture et les résultats de la simulation sont conformes à l’objectif initial. Dans le cas contraire, ils peuvent remonter à la source du problème, du résultat infructueux jusqu’au sous-système ou au paramètre précis qui en est à l’origine.

3. Conception d’architecture modulaire et itération rapide

Les programmes de développement de véhicules adoptent rarement une architecture fixe dès le départ. Les équipes comparent les concepts, modifient les paramètres des composants, remplacent les blocs de conception et effectuent des études de compromis à maintes reprises.

SSA offre un environnement de conception modulaire graphique permettant aux ingénieurs de créer des blocs d’architecture, de les connecter via des interfaces standard et de les modifier rapidement. Le rapport souligne son utilité tant pour la phase de conception préliminaire que pour l’ingénierie détaillée, car il prend en charge :

• bâtiment d’architecture par glisser-déposer,
• composants modulaires,
• interfaces standard,
• modélisation paramétrée et
• Analyse de sensibilité.

Cela accélère le processus d’itération de la conception. Les ingénieurs peuvent ajuster la capacité de la batterie, la puissance du moteur, les paramètres de contrôle, la rigidité de la suspension ou toute autre valeur clé et étudier la réaction de l’ensemble du véhicule.

Le rapport souligne même que Hyundai a utilisé l’optimisation des paramètres basée sur l’analyse de la structure du réseau (SSA) pour réduire un processus d’optimisation d’une semaine à 15 minutes. Une telle rapidité est cruciale lorsque les décisions architecturales doivent être prises rapidement.

4. Intégration transparente avec la chaîne d’outils automobiles

Un autre point fort du rapport réside dans la place de SSA au sein de la chaîne d’outils de développement automobile. Il est conçu pour se connecter avec :

• NX pour les données CAO,
• Simcenter 3D pour les travaux de CAE,
• Laboratoire d’essais Simcenter pour les données de test et de validation,
• Teamcenter pour la gestion du cycle de vie des produits et des produits (PLM), et
• Flux de travail Git ou basés sur des fichiers pour la gouvernance des modèles.

Cela signifie que les modèles d’architecture, les données de simulation, les exigences, les rapports et les enregistrements du cycle de vie peuvent rester liés au lieu d’être stockés dans des systèmes distincts avec des conflits de versions.

Dans le cadre d’un travail d’ingénierie concret, cela réduit la duplication des données, fluidifie les transferts et assure la traçabilité tout au long du processus de développement.

---

Modules fonctionnels principaux de l’architecte système Simcenter

Module de conception d’architecture système

C’est le cœur de SSA. Il offre aux équipes un environnement graphique et modulaire pour la construction de modèles d’architecture système.

Modélisation de l’architecture fonctionnelle

Le premier mode de modélisation s’intéresse au fonctionnement du système. Dans le domaine automobile, cela signifie construire une représentation fonctionnelle du véhicule ou du sous-système.

Par exemple, un système de commande de véhicule peut être décomposé en :

• fonctions de détection,
• fonctions de décision, et
• fonctions d’exécution.

Le rapport utilise cette structure pour expliquer le flux logique au sein du système. Les modules de détection transmettent les données environnementales aux modules de décision. Ces derniers traitent ces données et envoient des commandes de contrôle aux modules d’exécution.

Ce type de modélisation est utile lors de la phase de conception car il aide les équipes à définir les limites et la logique du système avant que les choix définitifs en matière de matériel ne soient effectués.

Modélisation de l’architecture physique

Le second mode de modélisation s’intéresse à la composition du système. Il s’agit d’attribuer des fonctions à des composants physiques tels que :

• caméras,
• unités radar,
• contrôleurs de domaine,
• étriers de frein,
• moteurs, et
• composants de la batterie.

Le rapport note également que la modélisation de l’architecture physique définit les interfaces des composants, notamment :

• interfaces électriques,
• interfaces mécaniques, et
• interfaces de communication.

Cela a son importance dans l’ingénierie détaillée car cela relie les fonctions aux choix de conception réels et aux travaux d’intégration ultérieurs.

Conception architecturale hiérarchique

SSA prend en charge la conception d’architecture en couches. Les équipes peuvent travailler à partir de :

• niveau du véhicule,
• au niveau du sous-système,
• au niveau des composants.

Le rapport donne un exemple clair de cette logique :

Architecture du véhicule → Architecture du sous-système d’alimentation → Architecture des composants de la batterie

Ce type de hiérarchie permet de conserver un modèle lisible et aide les grandes équipes à répartir le travail de manière contrôlée.

Bibliothèques de composants automobiles réutilisables

Le rapport mentionne également des bibliothèques automobiles intégrées ou réutilisables, notamment des blocs standard pour :

• groupe motopropulseur,
• châssis,
• suspension, et
• unités de contrôle.

Cela réduit le travail de modélisation répétitif et offre aux équipes un point de départ plus standardisé.

---

Module de gestion des exigences et de traçabilité

Ce module est construit autour d’une idée simple : les exigences ne doivent pas être exclues du flux de travail d’ingénierie.

Importation des exigences

Selon le rapport, la SSA peut importer les exigences de sources telles que :

• Excel, et
• Documents d’exigences de type DOORS.

Cela facilite l’intégration des objectifs de programme de haut niveau dans l’architecture et l’environnement de simulation.

Décomposition des exigences

Le rapport fournit ici un exemple détaillé. Un objectif au niveau du véhicule, tel que :

Autonomie NEDC ≥ 600 km

peuvent être décomposées en exigences de sous-systèmes et de composants, telles que :

• capacité de la batterie ≥ 80 kWh,
• puissance maximale du moteur ≥ 150 kW, et
• densité énergétique monocellulaire ≥ 280 Wh/kg.

Il s’agit d’une étape très concrète car elle transforme les objectifs généraux du produit en valeurs que les ingénieurs peuvent utiliser pour la conception et la vérification.

Répartition des besoins

Après analyse, ces exigences sont attribuées aux blocs d’architecture appropriés. Un objectif de capacité de batterie est défini pour le système de batterie. Un objectif de puissance est défini pour le moteur et le système d’entraînement. Un objectif de synchronisation est défini pour les blocs de détection, de calcul et d’actionnement.

Traçabilité ascendante et descendante

Le rapport met en évidence un point important. La SSA soutient :

• traçabilité ascendante, des exigences à la conception, puis à la simulation et enfin à la validation, et
• traçabilité inverse d’un résultat non concluant jusqu’à l’exigence initiale.

Si un véhicule n’atteint pas son objectif d’autonomie, les ingénieurs peuvent identifier la cause du problème (taille de la batterie, rendement du moteur, stratégie thermique ou logique de contrôle) plutôt que de procéder par suppositions.

Cela permet de gagner du temps et de maintenir l’itération ciblée.

---

Module de co-simulation multidisciplinaire

Ce module transforme l’architecture en un modèle de système fonctionnel.

Importation et compatibilité des modèles

Le rapport répertorie les principaux environnements d’outils pertinents ici :

• Simcenter Amesim pour les modèles mécaniques et thermiques,
• MATLAB/Simulink pour les modèles de stratégie de contrôle, et
• Modelica pour les modèles multiphysiques.

Ces éléments peuvent être intégrés via des interfaces standard comme FMI/FMU, ce qui évite à l’équipe de devoir reconstruire chaque modèle à partir de zéro.

Pour les équipes du secteur automobile, cela signifie que différents groupes peuvent conserver leurs outils de modélisation préférés tout en contribuant à une configuration de simulation unique au niveau du système.

Configuration du scénario de simulation

Le rapport présente plusieurs scénarios automobiles réalistes, notamment :

• cycle NEDC,
• cycle WLTP,
• conditions de montée en côte, et
• conditions de freinage.

Les paramètres de scénario peuvent inclure :

• vitesse du véhicule,
• température ambiante et
• conditions de charge.

Cette partie est importante car un modèle de système n’est utile que lorsqu’il est testé dans des conditions de fonctionnement réalistes. Un modèle thermique de batterie en laboratoire est une chose. Un modèle thermique de batterie en charge rapide ou en conduite à grande vitesse en est une autre.

Analyse des résultats

Le rapport indique que SSA prend en charge la visualisation des résultats grâce à :

• courbes,
• graphiques, et
• animations.

Il permet également une comparaison directe des différentes options d’architecture. Les ingénieurs peuvent vérifier des valeurs telles que :

• tension de la batterie,
• vitesse du moteur,
• déplacement de la suspension et
• performances thermiques.

Cela permet de repérer plus facilement les goulots d’étranglement et de comparer les choix d’architecture de manière structurée.

---

Module d’optimisation et d’analyse

Ce module traite de l’amélioration de la conception et des compromis architecturaux.

Optimisation paramétrique

Le rapport indique que l’analyse spectrale singulière (SSA) peut optimiser des paramètres tels que :

• capacité de la batterie,
• puissance du moteur,
• la rigidité de la suspension, et
• valeurs de la stratégie de contrôle.

Les objectifs d’optimisation peuvent inclure :

• portée maximale,
• consommation d’énergie minimale, ou
• meilleures performances NVH.

Le rapport mentionne l’utilisation de méthodes telles que les algorithmes génétiques et l’optimisation basée sur le gradient.

Un résultat mentionné dans le texte source est que Hyundai, grâce à l’utilisation de l’IA dans l’ensemble du processus, a réduit le temps d’évaluation d’une exigence individuelle de 2 minutes à 0,1 seconde. Cela démontre comment l’automatisation au niveau du système peut réduire le temps d’itération de la conception.

Optimisation multi-objectif

Ceci est très important dans le secteur automobile car les objectifs de conception sont souvent contradictoires. Le rapport donne des exemples tels que :

• autonomie par rapport à l’accélération, et
• Allègement versus résistance structurelle.

SSA prend en charge l’optimisation multi-objectifs avec des objectifs pondérés, permettant ainsi aux équipes de rechercher une architecture qui équilibre les besoins concurrents plutôt que de se concentrer sur un seul indicateur de performance clé (KPI).

Analyse de sensibilité

L’analyse de sensibilité permet d’identifier les paramètres les plus importants. Le rapport donne des exemples tels que :

• capacité de la batterie,
• rendement du moteur, et
• coefficient de traînée

en ce qui concerne l’autonomie du véhicule.

Cela permet aux équipes de concentrer leurs efforts d’ingénierie là où ils auront le plus d’impact.

---

Module de gestion des rapports et de la collaboration

Ce module traite de la communication technique, de la gouvernance et du contrôle du cycle de vie.

Génération automatisée de rapports

Le rapport indique que la SSA peut générer :

• rapports de conception architecturale,
• rapports de validation de simulation, et
• rapports de traçabilité des exigences.

Ces rapports peuvent inclure des schémas d’architecture, des résultats de simulation et des listes d’exigences. Ils sont utiles non seulement pour les revues internes, mais aussi pour la documentation technique conforme aux normes.

Collaboration et autorisations

Le rapport indique que la SSA prend en charge le travail multi-utilisateurs et les autorisations basées sur les rôles, notamment des rôles tels que :

• designers,
• les critiques, et
• administrateurs.

Ceci est important dans les grands programmes de véhicules car le travail d’architecture, le travail de simulation et la gestion des exigences appartiennent souvent à des équipes différentes.

PLM et lien avec le cycle de vie

Le rapport souligne également l’intégration avec les outils PLM, permettant ainsi de lier les rapports, les modèles d’architecture et les données de simulation aux flux de travail du cycle de vie. Cela facilite :

• contrôle de version,
• tenue de registres et
• traçabilité ultérieure.

Le texte source mentionne qu’AZL utilise ce type de flux de travail connecté dans le cadre des travaux sur le NVH des véhicules électriques afin que les données de test et les données de simulation puissent être rassemblées dans un ensemble de rapports standard.

---

Cas d’utilisation en ingénierie 1 : Conception de l’architecture et optimisation des performances du groupe motopropulseur d’un véhicule électrique

Le premier cas présenté dans le rapport concerne un constructeur automobile généraliste développant un nouveau véhicule électrique à batterie. Le programme a rencontré plusieurs problèmes communs :

• difficulté à choisir la meilleure architecture de groupe motopropulseur,
• validation complexe des performances interdomaines, et
• la nécessité d’équilibrer l’autonomie et la consommation d’énergie.

SSA a été utilisé comme principal outil au niveau du système.

Étape 1 : Importer et détailler les cibles au niveau du véhicule

Le rapport source cite les principales cibles comme suit :

• Autonomie NEDC ≥ 650 km,
• Accélération de 0 à 100 km/h en ≤ 6,5 secondes, et
• consommation d’énergie ≤ 12 kWh par 100 km.

Ces cibles de niveau supérieur ont été importées dans SSA et décomposées en cibles de sous-systèmes et de composants, telles que :

• capacité de la batterie ≥ 85 kWh,
• puissance maximale du moteur ≥ 160 kW, et
• Rendement de la commande électrique ≥ 95 %.

Cela a permis de créer le lien entre les objectifs du véhicule et l’architecture d’ingénierie.

Étape 2 : Élaborer des architectures fonctionnelles et physiques

L’équipe a ensuite conçu des architectures de groupe motopropulseur fonctionnelles et physiques dans SSA. À l’aide de bibliothèques de composants automobiles, elle a défini une chaîne physique composée de :

• bloc-batterie,
• moteur,
• système de commande électrique, et
• réducteur.

Trois options architecturales ont été comparées :

• propulsion arrière à un seul moteur,
• transmission intégrale à deux moteurs, et
• traction avant à un seul moteur avec prolongateur d’autonomie.

Cette étape a permis à l’équipe de disposer d’une méthode structurée pour comparer les concepts au lieu de s’appuyer sur des présentations statiques.

Étape 3 : Exécuter une co-simulation multidisciplinaire

Le rapport indique que l’équipe a importé :

• un modèle de gestion thermique des batteries intégré à Simcenter Amesim, et
• un modèle de stratégie de commande de moteur construit sous MATLAB/Simulink.

Ils ont ensuite configuré les conditions NEDC, haute vitesse et de course en côte pour simuler les trois concepts d’architecture. Principaux résultats :

• practice de golf,
• accélération,
• consommation d’énergie et
• température de la batterie.

Il s’agit là d’un des exemples les plus clairs, dans le rapport, de la valeur ajoutée de l’analyse de la demande en services logiciels (SSA) dans le développement de véhicules réels.

Étape 4 : Optimiser et sélectionner la meilleure architecture

Le rapport indique que l’équipe a utilisé une optimisation multi-objectifs avec des objectifs tels que :

• portée maximale,
• consommation d’énergie minimale, et
• meilleures performances d’accélération.

Après optimisation, la solution sélectionnée était la architecture à double moteur et à traction intégrale. Le rapport donne les résultats finaux suivants :

• autonomie de 680 km,
• 0 à 100 km/h en 5,8 secondes, et
• 11,2 kWh aux 100 km.

Ces résultats ont permis d’atteindre les objectifs fixés pour le véhicule.

Étape 5 : Suivre les exigences et générer des rapports

L’équipe a ensuite utilisé les fonctions de traçabilité SSA pour confirmer que la conception des composants correspondait aux exigences initiales. Ils ont généré :

• rapports sur l’architecture du groupe motopropulseur, et
• rapports de validation de simulation,

puis ont envoyé les résultats au système PLM pour les traitements en aval tels que la sélection des composants et la préparation du prototype.

Le rapport indique que cela a permis de raccourcir de 30 % le cycle de développement de l’architecture du groupe motopropulseur et d’accroître de 40 % l’efficacité de la validation par simulation.

---

Cas d’utilisation en ingénierie 2 : Conception de l’architecture du contrôleur de domaine de conduite autonome et validation de la sécurité fonctionnelle

Le deuxième cas présenté dans le rapport porte sur un contrôleur de domaine de conduite automatisée de niveau 2+. Les principaux défis rencontrés étaient les suivants :

• logique fonctionnelle complexe,
• coordination multi-modules difficile, et
• Validation de la sécurité fonctionnelle selon les exigences de la norme ISO 26262 ASIL-B.

L’analyse de la sécurité logicielle (SSA) a été utilisée pour soutenir à la fois le travail d’architecture et la simulation axée sur la sécurité.

Étape 1 : Définir et allouer les exigences fonctionnelles

Le rapport énumère des caractéristiques telles que :

• AEB,
• ACC, et
• maintien de la voie.

Ces exigences ont été décomposées en :

• perception,
• décision,
• exécution, et
• modules de communication.

Dans le même temps, l’équipe a défini des objectifs de sécurité et des niveaux de risque conformes à la norme ISO 26262.

Étape 2 : Concevoir l’architecture du contrôleur et définir les interfaces

L’architecture a réuni :

• interfaces caméra et radar dans la couche de détection,
• Allocation des ressources CPU/GPU dans la couche de décision,
• interfaces de freinage et de direction dans la couche d’exécution, et
• Interfaces CAN, LIN et Ethernet dans la couche de communication.

Le rapport souligne que la définition des interfaces est une composante essentielle du processus d’architecture, et non un détail mineur. Dans le développement des contrôleurs, de nombreux problèmes proviennent de la synchronisation, de la communication et des hypothèses relatives aux interfaces, et non de la seule finalité de l’algorithme.

Étape 3 : Simulation de cas de défaillance pour la validation de la sécurité fonctionnelle

Le rapport indique que SSA a été utilisé conjointement avec :

• Modèles de stratégie de contrôle MATLAB/Simulink, et
• Données de test du laboratoire Simcenter Testlab.

L’équipe a élaboré des scénarios de défaillance tels que :

• panne de la caméra,
• interruption des communications et
• Défaillance de l’actionneur.

Ces simulations ont été utilisées pour vérifier les diagnostics et la réponse tolérante aux pannes.

Étape 4 : Optimiser l’architecture

D’après les résultats de la simulation, l’équipe a identifié des problèmes de sécurité tels que :

• délai de communication élevé et
• Temps de réponse lent pour le diagnostic des pannes.

Ils ont ensuite utilisé l’optimisation des paramètres SSA pour ajuster :

• configuration du protocole de communication,
• calculer l’allocation et
• stratégie de diagnostic.

Cela a permis d’améliorer la sécurité et la fiabilité avant les étapes d’intégration ultérieures.

Étape 5 : Générer des résultats axés sur la conformité

Les résultats finaux comprenaient :

• rapports de conception d’architecture de contrôleur,
• rapports de validation de la sécurité fonctionnelle et
• enregistrements de traçabilité.

Ces travaux ont permis de soutenir ultérieurement la certification et la préparation à la production.

Le rapport indique que ce cas montre comment SSA peut soutenir le développement de contrôleurs de domaine de manière structurée et conforme aux normes, et pas seulement la modélisation de systèmes physiques.

---

Adaptation de la version chinoise et valeur de l’ingénierie locale

Le rapport comprend une section dédiée à la version chinoise de Simcenter System Architect, et cette partie devrait être conservée dans l’article car elle apporte une réelle valeur ajoutée au public visé.

La version chinoise conserve l’intégralité des fonctionnalités de base de la version anglaise tout en ajoutant la prise en charge des langues locales, telles que :

• Texte intégral de l’interface en chinois,
• Menus et documents d’aide en chinois,
• prise en charge de l’importation et de la modification des documents d’exigences chinois, et
• Assistance technique et formation en chinois.

Le rapport souligne également le soutien apporté aux normes et standards locaux, notamment en faisant référence à des éléments tels que : Exigences de sécurité relatives aux véhicules électriques GB/T 28950-2012.

Cela est utile pour plusieurs raisons.

Premièrement, cela réduit la barrière à l’apprentissage pour les équipes d’ingénierie en Chine.
Deuxièmement, cela facilite le travail de définition des exigences et la collaboration quotidienne dans les projets locaux.
Troisièmement, elle conserve des données entièrement compatibles avec la version anglaise, ce qui favorise la collaboration transfrontalière entre les équipes basées en Chine et celles à l’étranger.

Cela signifie qu’une équipe en Chine peut utiliser la version chinoise tandis qu’un partenaire international utilise la version anglaise sans interrompre le flux de données d’ingénierie partagé.

---

Notes techniques pour la mise en œuvre concrète

Le rapport fournit également des conseils pratiques sur l’utilisation de l’architecture logicielle logicielle (SSA) dans les projets d’ingénierie. Ces détails sont essentiels car ils répondent à la question que se pose toute équipe après avoir pris connaissance d’une plateforme : à quoi faut-il faire attention ?

Normalisation des modèles

Dans le cadre de la cosimulation multi-domaines, les modèles importés doivent respecter des normes uniformes. Le rapport indique que les équipes doivent s’assurer que les modèles sont conformes aux exigences FMI/FMU lorsque cela est nécessaire et que les unités, les paramètres d’interface et les définitions de données sont cohérents.

Il est également recommandé de constituer une bibliothèque de modèles standard interne afin que les équipes puissent réutiliser les modèles avec moins de risques d’incompatibilité.

Exigences de qualité

Le texte source met en garde contre les exigences vagues telles que « améliorer la portée ». Une exigence devrait être :

• mesurable,
• testable, et
• lié à une méthode de vérification.

Sans cette discipline, la traçabilité s’affaiblit et le modèle d’architecture perd de sa valeur.

Scénarios de simulation raisonnables

Le rapport indique que les scénarios de simulation doivent correspondre aux conditions de fonctionnement réelles. Des paramètres tels que :

• température ambiante,
• état des routes et
• charger

devrait refléter les cas d’utilisation réels des véhicules.

Un exemple précis cité dans le rapport est un programme de véhicules électriques pour le nord de la Chine qui devrait inclure conditions de basse température à -20°C vérifier la fiabilité de la batterie et de la gestion thermique.

Gestion de la collaboration d’équipe

Les grands projets automobiles impliquent de nombreux groupes. Le rapport recommande des autorisations utilisateur claires, des responsabilités d’équipe clairement définies et un flux de collaboration structuré entre :

• équipes de conception architecturale,
• équipes de simulation, et
• équipes de gestion des exigences.

Sans cela, les conflits de versions et le travail dupliqué peuvent réapparaître même si l’outil lui-même est performant.

Intégration approfondie de la chaîne d’outils

La dernière recommandation est d’exploiter pleinement l’intégration de SSA avec les outils Simcenter et les systèmes PLM. Le rapport cite Teamcenter comme exemple clé. Les résultats de simulation doivent être intégrés aux documents de conception et d’exigences. Ils doivent être liés afin de faciliter leur consultation et leur réutilisation ultérieures.

---

Pourquoi l’architecture système Simcenter est importante pour l’avenir

Le rapport se termine par une section tournée vers l’avenir, qu’il convient de conserver car elle explique pourquoi cet outil est important sur le long terme.

Les systèmes embarqués deviendront de plus en plus complexes à mesure que l’électrification, la connectivité, l’intelligence et l’architecture logicielle progresseront. Cela augmentera les besoins en :

• meilleure modélisation au niveau du système,
• simulation inter-domaines plus rapide,
• un contrôle des exigences plus strict et
• Validation de la sécurité et des performances plus fiable.

Le rapport évoque également la future combinaison de l’Afrique subsaharienne avec :

• L’IA et
• Méthodes de jumeaux numériques.

Cette orientation est logique. À mesure que les modèles s’agrandissent et que les programmes évoluent plus rapidement, les équipes d’ingénierie auront besoin de davantage d’automatisation pour les études d’architecture, l’optimisation et l’aide à la décision au niveau du système.

Le rapport conclut que l’ingénierie système basée sur les modèles (MBSE) devient une méthode fondamentale du développement automobile, et non plus une pratique marginale. Dans ce contexte, l’analyse de la structure logicielle (SSA) devient bien plus qu’un simple connecteur de simulation : elle constitue une couche de travail centrale dans le flux de développement complet.

---

Foire aux questions

Qu’est-ce que Simcenter System Architect et comment s’intègre-t-il à la chaîne d’outils MBSE automobile ?

Réponse courte :
Il s’agit de la couche d’architecture système qui relie les exigences, la conception du système, les ressources de simulation et la validation dans un flux de travail MBSE automobile.

Simcenter System Architect est une plateforme de modélisation et de co-simulation d’architecture système appartenant à la suite Siemens Simcenter. Dans le secteur automobile, elle intervient généralement entre la définition des exigences et la simulation technique détaillée. Elle relie les exigences, l’architecture fonctionnelle, l’architecture physique, les modèles multi-domaines et la validation système, permettant ainsi aux équipes d’étudier différentes options d’architecture avant même la disponibilité des prototypes matériels.

Comment Simcenter System Architect prend-il en charge la co-simulation multidisciplinaire ?

Réponse courte :
Il permet de faire fonctionner ensemble des modèles issus de différents outils d’ingénierie dans une configuration système unique.

SSA prend en charge l’intégration de modèles hétérogènes issus de différents domaines et outils. Le rapport mentionne notamment Simcenter Amesim, MATLAB/Simulink et les modèles basés sur Modelica, avec une interopérabilité assurée par des interfaces telles que FMI/FMU. Ceci permet aux équipes automobiles de simuler les interactions entre la mécanique, l’électronique, les systèmes de contrôle, le comportement thermique et d’autres domaines dans un environnement unique, au lieu de les vérifier individuellement.

Pourquoi l’ingénierie système basée sur les modèles (MBSE) est-elle importante pour le développement des systèmes automobiles modernes ?

Réponse courte :
Parce que les véhicules modernes sont trop complexes pour être bien gérés avec des documents déconnectés et des outils de sous-systèmes isolés.

Les véhicules intègrent désormais des systèmes mécaniques, électriques, électroniques et logiciels au sein d’un produit unique et étroitement lié. L’ingénierie système basée sur les modèles (MBSE) offre aux équipes une méthode structurée pour définir, décomposer, allouer et vérifier les exigences grâce à des modèles formels. Dans le flux de travail décrit par le rapport, l’architecture logicielle (SSA) sert de plateforme système reliant l’architecture et la simulation, permettant ainsi aux équipes de valider leurs choix plus tôt et d’anticiper les problèmes de dernière minute.

Comment Simcenter System Architect s’intègre-t-il aux autres outils d’ingénierie ?

Réponse courte :
Il relie le travail d’architecture système aux outils de conception, de simulation, de test et de cycle de vie.

Le rapport mentionne l’intégration avec Simcenter Amesim, NX, Simcenter 3D, Simcenter Testlab, Teamcenter et la gestion de modèles par Git ou par fichiers. Ceci permet de maintenir la cohérence des exigences, des modèles, des rapports et des données de validation tout au long du cycle de vie de l’ingénierie. Au lieu de stocker les enregistrements d’architecture, de simulation et de cycle de vie dans des systèmes distincts, les équipes peuvent ainsi conserver un fil conducteur de développement plus continu.

Quels sont les principaux cas d’utilisation de Simcenter System Architect dans le secteur automobile ?

Réponse courte :
Les principaux cas d’utilisation sont la conception des groupes motopropulseurs de véhicules électriques, les études thermiques des batteries, les travaux sur la stratégie énergétique, la conception des systèmes ADAS et des contrôleurs de domaine, et la validation axée sur la sécurité fonctionnelle.

Le rapport présente deux cas complets. Le premier porte sur la conception et l’optimisation de l’architecture du groupe motopropulseur d’un véhicule électrique, incluant la gestion thermique de la batterie et la simulation du cycle de conduite. Le second concerne un contrôleur de domaine de conduite automatisée de niveau 2+, incluant l’allocation des fonctionnalités, la définition des interfaces, la simulation des pannes et la validation de la sécurité. Ces cas illustrent comment l’analyse de la structure du système (SSA) est utilisée pour les premières décisions d’architecture et la vérification ultérieure du système.

---

Conclusion finale

Simcenter System Architect est utile en ingénierie automobile car il offre aux équipes un point d’accès unique pour connecter les exigences, l’architecture, la simulation, l’optimisation et la vérification.

D’après le rapport source, sa valeur est évidente dans quatre domaines :

• co-simulation hétérogène,
• traçabilité complète,
• itération d’architecture modulaire, et
• Intégration de la chaîne d’outils.

Ses cinq principaux groupes fonctionnels sont également clairs :

• conception de l’architecture système,
• gestion des exigences et traçabilité,
• co-simulation multidisciplinaire,
• optimisation et analyse, et
• Gestion des rapports et de la collaboration.

Les deux cas d’ingénierie présentés dans le rapport illustrent le même phénomène sous différents angles. Dans le développement des véhicules électriques, l’analyse de la structure des systèmes (SSA) aide les équipes à comparer les concepts de groupes motopropulseurs et à optimiser l’autonomie, l’accélération, la consommation d’énergie et le comportement thermique. Dans le développement des systèmes de contrôle de conduite automatisée, elle facilite l’organisation des fonctionnalités, des interfaces, de la logique de sécurité, des cas de défaillance et des enregistrements de conformité.

La version chinoise apporte une valeur ajoutée concrète aux équipes d’ingénierie locales sans pour autant freiner la collaboration mondiale.

Dans son ensemble, le rapport présente SSA comme une véritable plateforme de développement au niveau système pour les programmes de véhicules modernes, en particulier lorsque la complexité, la traçabilité et l’intégration interdomaines sont des facteurs déterminants de la charge de travail.

---

Biographie de l’auteur

Johnny Liu est le PDG de Dowway Vehicle. Il travaille sur la stratégie d’ingénierie automobile, la planification de l’architecture système et les méthodes de développement numérique pour les véhicules électriques, les véhicules intelligents et les programmes d’ingénierie interdomaines.

---