Ingénierie système, MBSE & V&V
Plus un système devient complexe, moins il est possible de l’optimiser en améliorant chaque sous-système séparément. Une batterie plus grande change masse et thermique ; une antenne plus puissante change énergie et pointage ; une nouvelle procédure change logiciel, formation et opérations. L’ingénierie système organise ces dépendances depuis les besoins des parties prenantes jusqu’à la preuve que le produit réalisé répond réellement à la mission.
Objectifs de maîtrise
- expliquer les concepts avec les unités et les hypothèses
- refaire un calcul simple à la main avant d’utiliser un outil
- identifier au moins un mode de panne ou une limite du modèle
- relier la discipline à une architecture martienne complète
1. Besoin, objectif, exigence : trois niveaux à ne pas confondre
Un besoin exprime pourquoi une capacité est nécessaire. Un objectif décrit ce que la mission cherche à accomplir. Une exigence impose une propriété vérifiable au système. « Survivre sur Mars » n’est pas une bonne exigence ; « maintenir la pression de l’habitat dans une plage définie pendant telle durée après une panne simple » peut le devenir. Une exigence claire possède un sujet, une action, une condition et un critère mesurable.
Réflexe d’ingénierie. Pour « besoin, objectif, exigence : trois niveaux à ne pas confondre », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
2. ConOps : raconter comment le système sera réellement utilisé
Le Concept of Operations décrit acteurs, phases, environnements, flux d’information, états et scénarios nominaux ou dégradés. Il évite de concevoir une machine sans comprendre le travail humain autour d’elle. Une excellente exigence technique peut être inutile si le scénario d’exploitation est faux. Le ConOps est donc un pont entre mission, opérations et architecture.
Réflexe d’ingénierie. Pour « conops : raconter comment le système sera réellement utilisé », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
3. Décomposition fonctionnelle et architecture
On part des fonctions nécessaires puis on décide quels éléments physiques ou logiciels les réalisent. Cette séparation empêche de choisir trop tôt une solution favorite. Une fonction « rejeter la chaleur » peut être réalisée par différentes combinaisons de radiateurs, boucles et modes d’exploitation. L’architecture alloue ensuite fonctions, performances et interfaces aux sous-systèmes.
Réflexe d’ingénierie. Pour « décomposition fonctionnelle et architecture », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
4. Interfaces : là où les bons sous-systèmes peuvent devenir un mauvais système
Une interface ne se limite pas à un connecteur. Elle inclut mécanique, énergie, données, thermique, logiciel, procédures et responsabilités. Les unités, tolérances, états autorisés et comportement en panne doivent être définis. Les problèmes d’intégration viennent souvent de suppositions implicites faites différemment par deux équipes.
Réflexe d’ingénierie. Pour « interfaces : là où les bons sous-systèmes peuvent devenir un mauvais système », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
5. Budgets et marges comme outils de décision
Masse, puissance, énergie, débit de données, volume, temps d’équipage et performance sont suivis comme des budgets. La marge n’est pas un pourcentage décoratif : elle absorbe incertitude et maturation. Quand une marge diminue, la décision doit être visible. Les budgets créent un langage commun entre disciplines qui autrement optimiseraient chacune leur propre critère.
Réflexe d’ingénierie. Pour « budgets et marges comme outils de décision », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
6. MBSE : utiliser un modèle pour relier les produits d’ingénierie
Model-Based Systems Engineering ne signifie pas produire de beaux diagrammes. Un modèle utile relie exigences, fonctions, composants, interfaces et preuves de V&V afin qu’un changement laisse une trace. SysML peut formaliser ces relations. Le modèle ne remplace pas le jugement ; il réduit surtout les incohérences cachées entre documents indépendants.
Réflexe d’ingénierie. Pour « mbse : utiliser un modèle pour relier les produits d’ingénierie », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
7. Vérification et validation : deux questions différentes
La vérification demande si le produit respecte ses exigences : analyse, inspection, démonstration ou essai. La validation demande si le produit convient réellement à l’usage et aux attentes de mission. Un système peut être parfaitement vérifié contre de mauvaises exigences et pourtant être inutile. Les deux boucles doivent donc rester visibles depuis le début du projet.
Réflexe d’ingénierie. Pour « vérification et validation : deux questions différentes », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
8. Matrice de vérification et traçabilité
Pour chaque exigence importante, on identifie une méthode, un niveau, une configuration d’essai, un responsable et un résultat attendu. Cette matrice évite de découvrir trop tard qu’une exigence est impossible à prouver. La traçabilité permet aussi de répondre à la question inverse : si un test échoue, quelles exigences, fonctions et décisions sont affectées ?
Réflexe d’ingénierie. Pour « matrice de vérification et traçabilité », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
9. Configuration et changement
Un système spatial évolue. La gestion de configuration établit ce qui constitue la référence à un instant donné : exigences, logiciel, dessins, paramètres et procédures. Une modification doit être évaluée pour ses effets transversaux. Sans baseline et contrôle des changements, une correction locale peut réintroduire un défaut ailleurs — exactement le problème que l’anti-régression cherche à empêcher.
Réflexe d’ingénierie. Pour « configuration et changement », noter d’abord les entrées, les sorties, les unités et la plage de validité. Puis construire un cas nominal et un cas dégradé. Ce double calcul empêche de confondre une relation mathématique correcte avec une architecture réellement exploitable sur Mars.
Exemple calculé pas à pas
La méthode de travail est toujours la même : écrire ce que représente chaque symbole, convertir toutes les unités vers un système cohérent, effectuer l’opération, puis traduire le résultat en phrase. Enfin, faire un contrôle d’ordre de grandeur. Si le résultat change de facteur mille lorsqu’on passe de millimètres à mètres, la conversion doit être visible dans le calcul.
Exercice progressif
- Choisir un cas simple et lister toutes les données avec leurs unités.
- Calculer le résultat nominal sans marge.
- Modifier le paramètre le plus incertain de ±20 % et comparer.
- Ajouter une panne crédible et expliquer quel indicateur permet de la détecter.
- Décider si le système continue, se dégrade ou doit s’arrêter.
Solution raisonnée
Une bonne solution ne se résume pas au nombre final. Elle montre les conversions, la logique de la formule, la sensibilité et la décision. Si deux hypothèses différentes conduisent à la même décision opérationnelle, la conception est relativement robuste à cette incertitude. Si une petite variation inverse la décision, le paramètre doit devenir une priorité de mesure ou de marge.
Mini-projet de validation
Construire une note d’ingénierie de deux à quatre pages appliquant le cours à un sous-système martien. Le document doit contenir : besoin, hypothèses, schéma fonctionnel, calcul manuel, vérification par un second calcul ou une simulation, incertitudes, panne injectée, critères de décision et trois références primaires. L’objectif est de produire une chaîne de preuve que quelqu’un d’autre peut relire et refaire.
Erreurs classiques à détecter
- mélanger unités ou repères sans conversion visible ;
- présenter une valeur calculée comme une donnée mesurée ;
- ignorer la plage de validité d’un modèle ;
- confondre précision numérique et exactitude physique ;
- dimensionner sur le seul cas nominal sans marge ni mode dégradé.