| name | systems-engineering-sysml |
| description | Appliquer l'ingénierie des systèmes et la modélisation SysML pour structurer le cycle en V d'un système complexe (analyse fonctionnelle, exigences, architecture logique et physique). |
| version | 2.0.0 |
| author | EVA |
| license | Privée EVA St-Étienne |
| platforms | ["linux","macos","windows"] |
| metadata | {"EVA":{"tags":["systems-engineering","mbse","sysml","architecture","requirements","v-cycle","modeling","capella","cameo"],"related_skills":["industry40-digital-transformation","cad-bom-automation","engineering-project-management"]}} |
Ingénierie des Systèmes (MBSE & SysML)
Vue d'ensemble
Cette compétence guide la mise en œuvre de l'ingénierie système basée sur les modèles (MBSE — Model-Based Systems Engineering) pour concevoir, spécifier, valider et documenter des systèmes industriels complexes : lignes de production automatisées, usines complètes, machines spéciales, systèmes mécatroniques, infrastructures de transport.
Le MBSE repose sur l'utilisation d'un langage de modélisation commun (SysML — Systems Modeling Language) et d'un outil de modélisation (Cameo Systems Modeler, Capella, IBM Rhapsody) pour créer un modèle unique et cohérent du système, reliant :
- Les exigences (besoins clients, spécifications techniques, normes)
- Les fonctions (analyse fonctionnelle, scénarios d'utilisation)
- L'architecture logique (blocs conceptuels, flux échangés)
- L'architecture physique (composants réels, allocation des fonctions)
- Les paramètres (équations de performance, contraintes dimensionnantes)
- Les tests et la validation (liens de vérification, critères d'acceptation)
Cette approche s'oppose à l'ingénierie documentaire traditionnelle (documents Word, tableaux Excel) où la cohérence entre les vues est manuelle et sujette aux erreurs.
Cette compétence est conçue pour être actionnée par l'agent EVA lorsque l'utilisateur exprime un besoin lié à la modélisation système, l'analyse d'exigences, la conception architecturale ou la documentation structurée d'un système industriel.
Quand l'utiliser
À utiliser lorsque l'utilisateur demande de façon explicite ou implicite de :
- Structurer le cycle en V d'un projet industriel (conception système → spécifications → intégration → validation → qualification).
- Rédiger, analyser ou structurer des exigences système avec des critères d'acceptation mesurables.
- Concevoir des diagrammes SysML : diagramme d'exigences (
req), diagramme de définition de blocs (bdd), diagramme de blocs internes (ibd), diagramme d'états (stm), diagramme d'activités (act), diagramme séquentiel (sd), diagramme paramétrique (par).
- Réaliser une analyse fonctionnelle descendante (arbre fonctionnel, FAST, SADT).
- Allouer des fonctions à des composants physiques et assurer la traçabilité tout au long du cycle de vie.
- Préparer les dossiers de spécification technique, de conception détaillée ou de validation d'un système.
Le cycle en V et le MBSE
Le cycle en V structure le développement d'un système en deux branches descendante (conception) et ascendante (intégration/validation) :
┌─────────────────────────────────────────────────────┐
│ BESOINS / EXIGENCES CLIENTS │
│ (Analyse du besoin) │
└───────────────────────┬─────────────────────────────┘
│
┌───────────────────────▼─────────────────────────────┐
│ SPÉCIFICATION FONCTIONNELLE SYSTÈME │
│ (Exigences système, cas d'utilisation) │
└───────────────────────┬─────────────────────────────┘
│
┌───────────────────────▼─────────────────────────────┐
│ ARCHITECTURE LOGIQUE (Conception) │
│ (Blocs logiques, flux, comportement) │
└───────────────────────┬─────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
│ │ │
┌─────────▼─────────┐ ┌─────────▼─────────┐ ┌─────────▼─────────┐
│ SOUS-SYSTÈME A │ │ SOUS-SYSTÈME B │ │ SOUS-SYSTÈME C │
│ (Cahier des │ │ (Cahier des │ │ (Cahier des │
│ charges métier) │ │ charges métier) │ │ charges métier) │
└─────────┬─────────┘ └─────────┬─────────┘ └─────────┬─────────┘
│ │ │
┌─────────▼─────────┐ ┌─────────▼─────────┐ ┌─────────▼─────────┐
│ CONCEPTION │ │ CONCEPTION │ │ CONCEPTION │
│ DÉTAILLÉE │ │ DÉTAILLÉE │ │ DÉTAILLÉE │
└───────────────────┘ └───────────────────┘ └───────────────────┘
La branche montante du V consiste en :
- Vérification : "A-t-on construit le système correctement ?" (test unitaire, intégration, qualification par rapport aux spécifications).
- Validation : "A-t-on construit le bon système ?" (satisfaction des besoins clients, recette, qualification opérationnelle).
Les piliers de SysML
La modélisation SysML s'articule autour de neuf types de diagrammes répartis en quatre catégories :
┌──────────────────────────────────────────────────────────┐
│ EXIGENCES │
│ Requirement Diagram (req) │
│ Définit, structure et trace les exigences │
└────────────────────┬─────────────────────────────────────┘
│
┌────────────────────┼─────────────────────────────────────┐
│ │ │
▼ Comportement ▼ Structure ▼ Paramétrique
┌────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ COMPORTEMENT │ │ STRUCTURE │ │ PARAMÉTRIQUE │
│ │ │ │ │ │
│ Use Case (uc) │ │ Block Definition │ │ Parametric (par) │
│ Activity (act) │ │ Diagram (bdd) │ │ Équations, │
│ Sequence (sd) │ │ Internal Block │ │ contraintes │
│ State Machine │ │ Diagram (ibd) │ │ physiques │
│ (stm) │ │ Package Diagram │ │ │
└────────────────┘ └────────────────────┘ └────────────────────┘
1. Diagramme d'exigences (req)
Le diagramme req structure les exigences sous forme hiérarchique et définit les relations entre elles :
| Relation | Notation SysML | Signification |
|---|
| Dérivation | deriveReqt | L'exigence enfant détaille ou raffine l'exigence parente |
| Satisfaction | satisfy | Un bloc physique ou une fonction réalise l'exigence |
| Vérification | verify | Un cas de test ou une procédure vérifie l'exigence |
| Raffinement | refine | Un modèle ou une analyse affine l'exigence |
| Copie | copy | L'exigence est recopiée d'un autre contexte |
Bonnes pratiques pour les exigences :
- Chaque exigence doit avoir un identifiant unique (ex : REQ-SYS-001).
- La description doit être mesurable et testable. Pas de termes vagues comme "rapide", "sûr", "ergonomique".
- Structure : Le [système] doit [action] dans [condition] avec [critère de performance].
- Exemple : "REQ-SYS-042 — La ligne de conditionnement doit atteindre une cadence nominale de 40 pièces par minute pour un produit de dimensions 150 × 200 × 80 mm."
2. Diagramme de définition de blocs (bdd)
Le bdd représente la structure statique du système :
- Blocs : Éléments du système (physiques ou logiques) avec leurs propriétés.
- Compositions : Relation partie-de (ex : un moteur contient un stator, un rotor, des roulements).
- Spécialisations : Relation est-un-type-de (ex : un moteur asynchrone est un type de moteur électrique).
- Multiplicités : Combien d'instances (1, 2, 0..*, etc.)
Exemple de bdd simplifié :
┌──────────────────────────────┐
│ [Block] Ligne de Production │
│ + propriétés: │
│ - cadence: pièces/min │
│ - trs: % │
├──────────────────────────────┤
│ Composition (part-of) │
├──────────────────────────────┤
│ 1 ──► [Block] Convoyeur │
│ 1 ──► [Block] Poste Assemblage│
│ 1 ──► [Block] Armoire Cde │
└──────────────────────────────┘
3. Diagramme de blocs internes (ibd)
Le ibd décrit les flux (matière, énergie, informations) qui transitent entre les parties internes d'un bloc via des ports :
┌─── Ligne de Production ───────────────────────────────────────┐
│ │
│ ┌──────────┐ Pièce brute ┌──────────────┐ Pièce usinée │
│ │ Convoyeur │────────────►│ Poste Assy │──────────────► ...│
│ │ Entrée │ │ │ │
│ └──────────┘ └──────────────┘ │
│ │ │ │
│ │ Signal "pièce prête" │ Ordre d'actionnement │
│ ▼ ▼ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Armoire de Commande │ │
│ │ Port : Ethernet/IP, 24VDC │ │
│ └────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
4. Diagramme d'états (stm)
Le stm modélise les modes de fonctionnement du système (ou d'un bloc). Indispensable pour les machines automatisées :
[Initial] ──► ┌──────────────┐
│ ARRÊT │
└──────┬───────┘
│ Ordre de marche
▼
┌──────────────┐
┌────►│ MARCHE │◄────┐
│ │ (Production) │ │ Reprise auto
│ └──────┬───────┘ │
│ │ Panne │
│ ▼ │
│ ┌──────────────┐ │
│ │ PANNE │─────┘
│ │ (Arrêt forcé)│
│ └──────────────┘
│
│ Ordre d'arrêt
▼
┌──────────────┐
│ ARRÊT │
│ (Maintenance) │
└──────────────┘
5. Diagramme paramétrique (par)
Le par exprime les contraintes physiques (équations) liant les propriétés des blocs. Exemple : contrainte de puissance d'un moteur :
$$P_{moteur} = C \cdot \omega$$
$$P_{moteur} \ge \frac{P_{charge}}{\eta_{transmission}}$$
Le diagramme par lie ces équations aux propriétés réelles des blocs définis dans le ibd ou le bdd.
Méthode ARCADIA / Capella
L'approche ARCADIA (Architecture Analysis & Design Integrated Approach), implémentée dans l'outil Capella, est une méthode MBSE complète décomposée en cinq niveaux :
- Analyse du besoin opérationnel (OA) : Ce que les utilisateurs veulent faire (sans le système).
- Analyse du besoin système (SA) : Ce que le système doit faire pour les utilisateurs (cas d'utilisation, fonctions système).
- Architecture logique (LA) : Comment le système réalise les fonctions (décomposition logique, flux).
- Architecture physique (PA) : Solution concrète (composants réels, allocation des fonctions logiques).
- EPBS (End Product Breakdown Structure) : Décomposition des produits réalisant l'architecture physique.
Pièges Courants (Common Pitfalls)
1. Exigences ambiguës ou invérifiables
Erreur : Écrire des exigences subjectives comme "La ligne de production doit être rapide et sûre". Ce type de formulation est inutile car impossible à tester. Une exigence non testable ne pourra jamais être validée, ce qui crée des litiges lors de la recette.
Correction : Appliquer la règle SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporellement défini) :
- "La ligne de production doit avoir une cadence nominale de 40 pièces par minute ± 5 % en régime stabilisé [REQ-002]."
- "La ligne de production doit être conforme à la Directive Machine 2006/42/CE et à la norme IEC 62061 (sécurité fonctionnelle) [REQ-003]."
2. Diagrammes de blocs internes (ibd) déconnectés du monde réel
Erreur : Relier des ports SysML sans spécifier la nature et le type des flux échangés. Par exemple, connecter le port d'un moteur à une vanne sans préciser s'il s'agit d'un signal électrique 24 VDC, d'une consigne analogique 4-20 mA, d'un bus de terrain Profinet ou d'un flux d'énergie mécanique (couple × vitesse).
Correction : Définir rigoureusement les Flow Properties sur chaque port :
| Port | Type de flux | Nature | Unité | Protocole |
|---|
| Moteur.entrée_énergie | Énergie électrique | Triphasé 400 V | kW | — |
| Moteur.sortie_vitesse | Information | Mesure codeur | tr/min | SSI |
| Vanne.consigne | Information | Signal analogique | 4-20 mA | — |
| Vanne.position | Information | Feedback | 0-100 % | HART |
3. Surcharge de modélisation sans valeur ajoutée
Erreur : Modéliser tous les détails du système au même niveau de granularité, même ceux qui n'ont aucun impact sur la conception, la validation ou l'intégration. Le modèle devient illisible, impossible à maintenir, et sa valeur ajoutée par rapport à des schémas simples s'évapore.
Correction : Appliquer le principe de sélectivité : ne modéliser en SysML que ce qui apporte de la valeur à la traçabilité des exigences, à la validation des interfaces ou à la compréhension architecturale. Les détails d'implémentation pure (câblage interne d'une armoire, routine logicielle) restent dans les outils métiers (EPLAN, code source). Chaque élément du modèle doit répondre à la question : "À quelle décision de conception ou de validation ce modèle contribue-t-il ?"
4. Absence de réconciliation entre vues fonctionnelle et physique
Erreur : Définir l'analyse fonctionnelle et l'architecture physique dans des documents (ou des outils) séparés, sans lien systématique. Après une modification de l'architecture physique (ex : remplacement d'un vérin pneumatique par un moteur électrique), personne ne met à jour l'analyse fonctionnelle associée, et le lien fonction-solution se perd.
Correction : Utiliser les relations de traçabilité SysML (satisfy, allocate) pour lier chaque fonction du diagramme d'activités (act) au bloc physique qui la réalise dans le bdd. Lorsqu'un composant change, l'outil MBSE signale les fonctions impactées. Maintenir une matrice de traçabilité fonctions ↔ composants à chaque jalon de conception.
Liste de vérification (Checklist)
