Une technique de simulation dans laquelle deux solveurs spécialisés et spécifiques à un domaine s’exécutent de manière coordonnée et échangent des données à des interfaces et points de synchronisation prédéfinis, plutôt que d’être remplacés par un unique solveur monolithique ; utilisée pour intégrer des modèles hétérogènes tout en conservant les capacités et la propriété intellectuelle propres à chaque outil.

Principe

La co‑simulation partitionne un système multi‑domaine en sous‑modèles exécutés par des solveurs dédiés ; la validité dépend du choix des variables d’interface échangées, du schéma de synchronisation et de la fréquence d’échange car ceux‑ci déterminent la conservation, la stabilité et la propagation d’erreur globale entre sous‑systèmes.

Démonstration

Scénario illustratif → Gestion énergétique véhicule : Situation : Un algorithme de contrôle en temps réel doit interagir avec une simulation détaillée de chaîne cinématique. Reconnaissance : L’ingénieur système choisit la co‑simulation pour préserver les solveurs fournisseurs et le comportement du contrôleur en temps réel. Action : Le solveur de chaîne cinématique et le contrôleur s’exécutent en parallèle ; à chaque intervalle de synchronisation le contrôleur envoie des consignes de couple et reçoit des vitesses d’arbre ; l’interpolation et le buffering gèrent les pas de temps différents. Conséquence : Le développement progresse avec une logique de contrôle validée et des réponses de chaîne cinématique détaillées, mais des artefacts numériques apparaissent si les intervalles de synchronisation sont trop longs, nécessitant un raffinement du pas ou des méthodes correctrices d’interface.

Mauvaise application

Supposer que la co‑simulation est numériquement équivalente à une solution monolithique est une mauvaise application. L’erreur est d’ignorer la cohérence d’interface et la conservation : si les variables échangées ne garantissent pas la conservation (énergie, masse, quantité de mouvement) ou si la synchronisation est trop grossière, la co‑simulation peut produire des résultats biaisés ou instables malgré des sous‑systèmes précis.

Conséquence

La co‑simulation permet la réutilisation d’outils spécialisés, le développement en parallèle et la protection de modèles propriétaires, accélérant l’intégration et les essais au niveau système. En revanche, elle introduit généralement des erreurs numériques supplémentaires, de la latence et des coûts de coordination ; pour des systèmes fortement couplés ou raides, elle peut générer un comportement non physique si des schémas d’interface conservatifs ou d’échange itératif ne sont pas employés.

Inversion

Lorsque le couplage est fort, que la dynamique est raide ou que la conservation stricte aux interfaces est requise, des solveurs monolithiques ou des méthodes partitionnées fortement itératives avec sous‑pas sont préférables. À l’inverse, pour la conception précoce, le hardware‑in‑the‑loop en temps réel ou la préservation d’outils fournisseurs, la co‑simulation reste adaptée.

Limite

Clairement inclus : Flux de travail multi‑domaines qui combinent différents paquets de solveurs échangeant des variables de frontière à des interfaces connues. Cas limite : Deux solveurs partageant un maillage déformable nécessitant interpolation — la précision dépend de la fidélité d’interpolation. Clairement exclu : Un seul solveur gérant nativement toutes les physiques requises ou un post‑traitement séquentiel hors exécution.

Tension sémantique

Modularité et Protection de la PI versus Fidélité Numérique — la co‑simulation préserve des chaînes d’outils modulaires et des modèles propriétaires mais peut dégrader la précision et la stabilité numériques par rapport aux approches monolithiques ; résoudre cette tension exige conception d’interface et stratégies de contrôle d’erreur.

Synthèse

La Co‑Simulation est un schéma d’ingénierie pour combiner solveurs hétérogènes : elle échange une partie de la fidélité numérique et du comportement de stabilité contre modularité, usage d’outils spécialisés et intégration pratique. Sa réussite dépend de définitions d’interface explicites, d’une stratégie de synchronisation et d’une gestion active de la conservation et de la propagation d’erreur.