MBSE avec SysML v2 : des diagrammes aux décisions

L'ingénierie système a un problème de réputation. Le MBSE (Model-Based Systems Engineering) est souvent perçu comme un exercice de documentation imposé par les grands donneurs d'ordre aérospatiaux — une case à cocher avant que le vrai travail commence. C'est le mauvais modèle mental, et il coûte cher aux projets.

Le vrai problème que résout le MBSE

Sur les projets embarqués complexes, la dérive des exigences est fatale. Un ingénieur matériel conçoit un circuit de conditionnement de signal pour une plage de capteurs que l'ingénieur firmware a déjà modifiée. Un débit UART est mis à jour dans un prototype sans se propager dans la checklist DFM. Un dispositif médical est livré avec une exigence qui a été testée mais jamais formellement tracée jusqu'à un enregistrement de validation. Ce ne sont pas des échecs de processus — ce sont des échecs de communication au niveau système.

Ce que SysML v2 change

SysML v2 (la révision 2024) est une amélioration substantielle par rapport à la v1 :

• •Syntaxe plus claire pour les définitions de blocs et les connexions de ports.
• •Support natif pour la traçabilité des exigences (relations satisfy, verify).
• •Meilleure intégration avec les outils d'exécution de modèles.
• •Une spécification conçue pour être lisible par les machines, pas seulement par les humains.

Ce dernier point est le plus important pour les ingénieurs embarqués. Un modèle SysML qui peut être interrogé de manière programmatique — "montrez-moi toutes les exigences pas encore couvertes par un test" — est un outil de gestion de projet en direct, pas une annexe PDF.

Un point de départ pratique

Vous n'avez pas besoin de tout modéliser. Les artefacts SysML à plus haute valeur pour les projets embarqués :

• •Diagramme de cas d'utilisation — qui utilise le système et qu'attend-il ? Force l'alignement précoce entre matériel, logiciel et client.
• •Diagramme de définition de blocs (BDD) — définit les limites des sous-systèmes et les interfaces. Évite les conversations "je pensais que tu gérais le cadrage CAN".
• •Diagramme d'exigences — lie chaque exigence à un test. Rend la V&V traçable sans tableur séparé.

Exemple réel : la plateforme de test de batteries

Pour la plateforme de test de batteries Volthium, un BDD SysML en début de phase de conception aurait rendu la frontière d'interface multi-protocoles explicite dès le premier jour : le SmartBridge comme bloc matériel avec des ports définis (CAN, UART, Ethernet, Bluetooth), chacun connecté à des blocs adaptateurs logiciels. Au lieu de découvrir l'architecture par itération, nous l'aurions eue sur papier avant d'écrire la première ligne de firmware.

C'est à ça que ressemble le MBSE bien fait — pas des diagrammes pour les parties prenantes, mais des décisions capturées assez tôt pour prévenir la refonte en fin de projet.

Par où commencer

Commencez par un projet, un type de diagramme. Choisissez le BDD. Cartographiez vos sous-systèmes et leurs interfaces. Faites une revue avec le matériel et le logiciel ensemble. Vous trouverez au moins trois hypothèses qui ne correspondent pas entre les deux équipes. Corrigez-les avant d'écrire du code. C'est le MBSE en pratique.