Qualiopi

SysML v2

Cette formation conduit un ingénieur sans bagage MBSE jusqu'à une pratique autonome de SysML v2, le standard OMG adopté en version finale en 2025.

5 jours

4 000 € HT

SysML v2

Python

Contactez-nous pour planifier une session.

Objectifs pédagogiques

Expliquer la valeur du MBSE et le positionnement de SysML v2 (apports par rapport à la v1, place dans l'écosystème d'ingénierie).
Maîtriser le paradigme Définition / Usage, clé de lecture de tout le langage.
Organiser un modèle propre : packages, bibliothèques standard, unités, imports, visibilité, et en vérifier la bonne formation.
Capturer un référentiel d'exigences traçable, y compris des exigences à base de contraintes formelles, et le relier à des cas d'usage et des acteurs.
Décrire l'architecture d'un système : parties, attributs, ports, interfaces, connexions et flux de matière / énergie / information, ainsi que ses variantes.
Modéliser le comportement par actions et par états, puis allouer ce comportement sur la structure.
Conduire une analyse paramétrique (budgets de masse, d'énergie, de marge) et formaliser la vérification reliant cas de test et exigences.
Distinguer, sur des cas concrets, ce qu'il est pertinent de formaliser de ce qui doit rester en texte.

Matin : qu'est-ce que modéliser un système ; pourquoi le MBSE, pourquoi SysML v2 ; le paradigme Définition / Usage comme concept structurant ; notation textuelle. TP : premières définitions et usages de MARTINET, validation du modèle.
Après-midi : organisation du modèle - packages, bibliothèques standard, unités SI, imports, visibilité ; attributs et valeurs typées ; bonne formation. TP : modèle MARTINET organisé, unités branchées.

Matin : le concept d'exigence et de traçabilité, puis sa modélisation - déclaration, hiérarchie, identifiants, relations satisfy / derive / refine. TP : référentiel d'exigences MARTINET tracé vers la structure.
Après-midi : exigences à base de contraintes formelles ; acteurs et cas d'usage ; liens cas d'usage ↔ exigences. TP : contraintes simples, cas d'usage reliés.

Matin : décomposition en parties, attributs, ports et conjugaison de ports. TP : décomposition de MARTINET, définition des ports.
Après-midi : interfaces, connexions, flux de matière / énergie / information ; variantes et configurations. TP : architecture connectée, un point de variation.

Matin : comportement par actions et activités - flux de contrôle et de données, entrées / sorties. TP : fonction principale de mission en actions.
Après-midi : comportement par états - transitions, déclencheurs, gardes, entry / do / exit ; allocation du comportement sur la structure. TP : machine à états des modes de MARTINET, allocation sur l'architecture.

Matin : analyses et contraintes paramétriques - budgets de masse, d'énergie / autonomie, de marge ; lien analyse ↔ exigences. TP : budgets de masse et d'autonomie de MARTINET.
Après-midi : vérification - cas de test, liaison verify vers les exigences, scénarios et verdicts ; panorama de l'échange de modèles par API (bloc optionnel) ; bilan. TP : un cas de test « autonomie ≥ seuil » vérifiant une exigence du Jour 2 via l'analyse paramétrique.