Sciences de l'ingénieur (Spé) — Ingénierie système
Analyse fonctionnelle et structurelle avancée (SysML complet)
Modélisation SysML : diagrammes des exigences, de cas d'utilisation, de blocs, d'activité, de séquence, d'états et paramétrique
Résumé synthétiqueFiche en 4 sectionsQuiz de 10 questionsGratuit, sans pub
Résumé
Avant de concevoir un robot, un drone ou une voiture autonome, l'ingénieur doit **décrire le système** sans ambiguïté : que doit-il faire ? de quoi est-il fait ? comment circulent l'énergie et l'information ? C'est le rôle de l'**ingénierie système** et de son langage de référence en SI, le **SysML** (*Systems Modeling Language*), dérivé d'UML. SysML offre neuf diagrammes complémentaires : le diagramme des **exigences** (req) formalise le cahier des charges (« le robot doit se déplacer à $1\ \mathrm{m/s}$ »), le diagramme de **blocs** (bdd) décrit l'architecture, le diagramme de **blocs internes** (ibd) détaille les flux de matière, d'énergie et d'information. Les diagrammes **comportementaux** — séquence (sd), états (stm), activité (act) — racontent comment le système réagit dans le temps. Enfin, le diagramme **paramétrique** (par) relie les équations physiques (par exemple $P = C \times \omega$) aux paramètres à dimensionner. Maîtriser SysML, c'est apprendre à penser un système pluritechnique comme un tout cohérent, du besoin global jusqu'à la solution technique.
Le **SysML** est un langage **graphique** de modélisation adapté aux systèmes pluritechniques (mêlant mécanique, électronique et informatique). Il ne sert pas à programmer, mais à **décrire et communiquer** : chaque diagramme apporte un point de vue précis. On commence en général par les diagrammes **structurels**, qui répondent aux questions « que doit faire le système ? » et « de quoi est-il fait ? ».
- **SysML** est dérivé d'**UML** mais étendu aux systèmes physiques, pas seulement logiciels.
- Le diagramme des **exigences** (req) formalise le cahier des charges : exigences fonctionnelles, de performance, de sécurité, reliées par les relations *derive*, *satisfy*, *verify*.
- Le diagramme de **cas d'utilisation** (uc) identifie les **acteurs** (utilisateur, environnement) et les **fonctions de service** rendues.
- Le diagramme de **définition de blocs** (bdd) décompose le système en **sous-systèmes hiérarchiques** avec leurs propriétés (valeurs, opérations).
- Le diagramme de **blocs internes** (ibd) montre les **flux** circulant entre blocs via des **ports** et **connecteurs** : matière, énergie ou information.
- Règle de cohérence : chaque bloc du **bdd** doit se retrouver dans l'**ibd**, et chaque exigence doit être *satisfaite* par au moins un bloc.
Exemple
Pour un portail automatique, le **req** contient l'exigence « ouvrir en moins de $8\ \mathrm{s}$ ». Le **bdd** décompose le système en *motoréducteur*, *carte de commande*, *capteurs*, *vantail*. L'**ibd** montre le flux d'énergie électrique de l'alimentation vers le moteur, et le flux d'information du capteur de position vers la carte. Une relation *satisfy* relie le bloc *motoréducteur* à l'exigence de temps d'ouverture.
Piège à éviter
Ne confonds pas **bdd** et **ibd** : le **bdd** décrit *de quoi* le système est composé (sa structure hiérarchique), l'**ibd** décrit *comment* les composants sont **reliés** et quels flux ils échangent. Ce sont deux vues complémentaires, pas deux noms du même diagramme.
Une fois la structure posée, il faut décrire **comment le système se comporte dans le temps** : dans quel ordre les actions s'enchaînent, quels états il traverse, comment il dialogue avec son utilisateur. C'est le rôle des diagrammes **comportementaux**, indispensables dès qu'il y a une logique séquentielle (un automatisme).
- Le diagramme d'**états** (stm) modélise les **états** du système (veille, marche, arrêt d'urgence) et les **événements** qui déclenchent les **transitions**.
- Chaque transition s'écrit *événement [garde] /action* : un **événement déclencheur**, une **condition de garde** $[\text{condition}]$ booléenne, et une **action** exécutée.
- Le diagramme d'**activité** (act) décrit l'**enchaînement des actions**, les **branchements conditionnels** et les tâches menées en **parallèle**.
- Le diagramme de **séquence** (sd) décrit les **échanges chronologiques de messages** ; les entités sont représentées par des **lignes de vie** (*lifelines*) verticales.
- Ces vues comportementales **complètent** les vues structurelles pour obtenir une description complète et exploitable du système.
Exemple
Pour un distributeur de boissons, le **stm** comporte les états *Attente*, *Sélection*, *Paiement*, *Distribution*. La transition *Attente → Sélection* a pour événement « appui touche produit ». La transition *Paiement → Distribution* porte la garde $[\text{somme insérée} \geq \text{prix}]$ : tant que la condition est fausse, la machine reste en *Paiement*.
Piège à éviter
Une **condition de garde** n'est pas un **événement**. L'événement (l'appui sur un bouton) *déclenche* la tentative de transition ; la garde $[\text{condition}]$ doit en plus être **vraie** pour que la transition s'effectue réellement. Si la garde est fausse, l'événement est ignoré et l'état ne change pas.
Modéliser ne suffit pas : il faut **vérifier que les choix techniques satisfont les performances exigées**. Le diagramme **paramétrique** (par) fait le pont entre le modèle SysML et les **équations physiques**, en encapsulant les relations de la mécanique, de l'électricité ou de l'énergétique.
- Le diagramme **paramétrique** (par) associe des **équations physiques** aux paramètres du système (vitesse, couple, puissance…).
- Les **blocs de contrainte** (*constraint blocks*) encapsulent une relation mathématique, par exemple $P = C \times \omega$ ou $v = R\,\omega$.
- Il permet de **vérifier** qu'une exigence de performance est tenue par les composants choisis, avant tout prototypage.
- Il fait le lien direct avec les **calculs de dimensionnement** : RDM, énergétique, cinématique.
- Les paramètres y sont reliés par des **ports** : on connecte la valeur d'un bloc (le couple moteur) à une variable de l'équation.
Exemple
Un moteur doit entraîner une charge réclamant $P = 600\ \mathrm{W}$ à $\omega = 150\ \mathrm{rad/s}$. Le bloc de contrainte $P = C \times \omega$ donne le couple nécessaire : $C = \dfrac{P}{\omega} = \dfrac{600}{150} = 4\ \mathrm{N{\cdot}m}$. Si le moteur retenu fournit $5\ \mathrm{N{\cdot}m}$, l'exigence est **satisfaite** avec une marge.
Piège à éviter
Le diagramme paramétrique **ne calcule pas tout seul** : il **relie** des grandeurs par des équations, mais c'est l'ingénieur (ou l'outil de simulation) qui exploite ces relations. Oublier de vérifier l'**homogénéité des unités** ($\mathrm{W}$, $\mathrm{N{\cdot}m}$, $\mathrm{rad/s}$) avant de conclure est l'erreur classique.
L'analyse système suit une **démarche descendante** : on part du **besoin global** (les exigences) pour aller vers la **solution technique détaillée**. Au cœur de cette démarche, la **chaîne fonctionnelle** décrit le chemin de l'information et de l'énergie à travers le système.
- **Analyse descendante** : du besoin global (req) vers la solution détaillée (bdd, ibd), en raffinant progressivement.
- **Analyse fonctionnelle externe** : identifier les **fonctions de service** (diagramme pieuvre, uc) ; **analyse interne** : décomposer en **fonctions techniques**.
- La **chaîne d'énergie** suit l'ordre **Alimenter → Distribuer → Convertir → Transmettre → Agir** sur la matière d'œuvre.
- La **chaîne d'information** suit l'ordre **Acquérir → Traiter → Communiquer** ; elle **commande** la chaîne d'énergie et reçoit en retour les **mesures** des capteurs.
- La **traçabilité** entre exigences et blocs est assurée par les relations *satisfy* (un bloc satisfait une exigence) et *verify* (un test la vérifie).
- En projet SI, on démarre par le **req** et le **bdd**, puis on détaille les autres diagrammes selon le besoin d'analyse.
Exemple
Sur une éolienne domestique : *Acquérir* (anémomètre mesurant le vent) → *Traiter* (calculateur d'orientation) → *Communiquer* (ordre au moteur d'orientation). En parallèle, la chaîne d'énergie *Convertit* l'énergie du vent (génératrice) → *Transmet* (multiplicateur) → *Agit* en produisant de l'électricité. La chaîne d'information **pilote** l'orientation de la chaîne d'énergie.
Piège à éviter
Ne mélange pas les deux chaînes : *Acquérir, Traiter, Communiquer* appartiennent à la chaîne d'**information** ; *Convertir, Transmettre, Agir* à la chaîne d'**énergie**. Un **capteur** est dans la chaîne d'information, un **actionneur** (moteur, vérin) dans la chaîne d'énergie : les confondre fausse toute l'analyse fonctionnelle.
Quiz - Analyse fonctionnelle et structurelle (SysML)
10 questions
Articles utiles
Questions fréquentes
Les points clés à retenir sur Analyse fonctionnelle et structurelle avancée (SysML complet), extraits du quiz de révision.
Quel diagramme SysML formalise le cahier des charges du système ?
Réponse :
Diagramme des exigences (req)
Le diagramme des **exigences** (req) recense et structure les besoins fonctionnels et non fonctionnels issus du cahier des charges, reliés par *derive*, *satisfy* et *verify*. Le bdd, lui, décrit l'architecture matérielle.
Que représente le diagramme de blocs internes (ibd) ?
Réponse :
Les flux (matière, énergie, information) entre les composants internes
L'**ibd** détaille les **flux** circulant entre les blocs internes via des **ports** et **connecteurs** : matière, énergie ou information. La hiérarchie, elle, est portée par le bdd.
Quelle relation SysML indique qu'un bloc satisfait une exigence ?
Réponse :
satisfy
La relation *satisfy* relie un **bloc** (solution technique) à une **exigence** qu'il permet de remplir. *verify* relie un cas de test à l'exigence, *derive* relie deux exigences entre elles.
Le diagramme d'états (stm) est particulièrement utile pour modéliser :
Réponse :
Les différents modes de fonctionnement et leurs transitions
Le **stm** modélise les **états** du système (veille, marche, arrêt d'urgence…) et les **événements** provoquant les transitions. C'est l'outil des systèmes à logique séquentielle.