Les tunnels de métro sont construits sous la nappe phréatique. L'eau s'infiltre en permanence par drainage. Si le système de pompage de relevage tombe en panne ou dysfonctionne, les conséquences sont immédiates : inondation du tunnel, arrêt de l'exploitation, et des coûts de remise en service considérables.
Ce type de système — apparemment simple (des pompes, un capteur de niveau, une armoire de commande) — est en réalité un système multidisciplinaire complet qui combine hydraulique, électrique, automatisme et génie civil. Et c'est précisément le type de système où l'approche MBSE (Model-Based Systems Engineering) apporte le plus de valeur.
Cet article décrit pas à pas, sur un cas réel, les 6 étapes que nous avons suivies pour concevoir, modéliser et simuler ce système de pompage — aboutissant à une réception client 100% conforme du premier coup.
La démarche classique d'ingénierie sur un système de pompage consiste généralement à rédiger un cahier des charges textuel, dimensionner les pompes, dessiner un schéma électrique et programmer l'automate. Chaque discipline travaille de son côté, et l'intégration se fait sur le chantier.
Cette approche fonctionne — jusqu'à ce qu'elle ne fonctionne plus. Les problèmes typiques sont bien connus :
Les spécifications textuelles sont ambiguës. Deux ingénieurs lisent la même phrase et en tirent deux implémentations différentes.
Le comportement du système (quelle pompe démarre quand, dans quel mode, avec quelle logique de basculement) n'est vérifié qu'au moment des essais sur site.
Les interfaces entre le capteur, le contrôleur et les pompes ne sont validées que physiquement, souvent avec des surprises.
Les modifications demandées en cours de projet ne sont pas tracées depuis l'exigence jusqu'au code automate.
L'approche MBSE change la donne en remplaçant les documents textuels par des modèles exécutables et simulables. Le système est entièrement conçu, validé et testé avant même que le premier équipement soit fabriqué.
Voici les 6 étapes que nous avons suivies, de l'analyse initiale à la simulation de performance.
Le point de départ est un schéma simplifié du système dans son environnement. Il représente les éléments physiques (tunnel, bâche à eau, pompes, capteur de niveau ultrason, tuyau d'exhaure, armoire de pompage) et leur disposition spatiale (niveau souterrain, niveau superficiel).
Ce schéma, compréhensible par tous les intervenants y compris le client, sert de base à l'analyse des exigences. On identifie les fonctions attendues (mesurer le niveau, commander les pompes, relever l'eau, évacuer en surface), les contraintes (fiabilité, redondance des pompes, modes de fonctionnement auto/manuel) et les interfaces avec l'environnement (drainage du tunnel, réseau électrique basse tension, réseau d'évacuation des eaux usées urbain).

Cette étape répond à la question : que doit faire le système ? On définit les fonctions du système et leurs enchaînements sans se préoccuper de la technologie.
Le diagramme d'activité modélise le scénario opérationnel complet :
Acquérir la sélection de mode (auto/manuel/arrêt) — point d'entrée opérateur.
Mesurer le niveau d'eau dans la bâche — acquisition du capteur ultrason.
Afficher le niveau d'eau — retour d'information vers l'opérateur.
Contrôler les pompes — logique de décision selon le mode et le niveau.
Alimenter la pompe en énergie — commande de puissance.
Relever l'eau du niveau 0 (souterrain) au niveau 1 (superficie) — la fonction utile finale.
Les flux entre fonctions sont identifiés : flux d'eau, flux d'énergie, flux d'information (niveau, mode, commandes). C'est la représentation de l'architecture logique indépendante de toute solution physique, telle que décrite par Faisandier dans sa méthodologie d'architecture système.

Cette étape répond à la question : quel composant réalise quelle fonction ?
Chaque fonction identifiée à l'étape précédente est allouée à un élément physique concret. Le diagramme montre cette allocation par des swimlanes (couloirs) :
Acquérir Sélection Mode → alloué au Sélecteur (sur l'armoire de pompage)
Mesurer Niveau Eau → alloué au Capteur de Niveau (ultrason, dans la bâche)
Afficher Niveau Eau → alloué à l'Afficheur Niveau (sur l'armoire)
Contrôler Pompes → alloué au Contrôleur (automate dans l'armoire)
Alimenter Pompe → alloué à l'Alimentation Électrique
Relever Eau → alloué à la Pompe + Réseau hydraulique
Cette vue croisée fonctions/composants est l'équivalent exact de ce que Avoine appelle le croisement WBS/OBS/ABS dans le cost control : elle permet de tracer chaque exigence jusqu'à son implémentation physique, et donc de chiffrer l'impact de toute modification.

Cette étape répond à la question : comment les composants sont-ils connectés physiquement ?
L'architecture organique représente les éléments physiques du système et leurs interfaces. On y voit clairement :
Le système de pompage lui-même comprenant l'armoire de pompage (sélecteur, afficheur, contrôleur, alimentation électrique) et les pompes + réseau.
Les éléments externes avec lesquels le système interagit : l'opérateur, le tunnel (source de drainage), la bâche à eau, le réseau BT, le réseau d'eaux usées urbain.
Les flux physiques entre chaque composant : sélection, mode, niveau, commandes pompe, énergie, eau niv 0, eau niv 1.
C'est l'équivalent d'un Internal Block Diagram (IBD) en SysML. Chaque port, chaque connecteur, chaque flux est explicité. Aucune interface n'est laissée implicite — c'est ce qui évite les mauvaises surprises au montage.

Cette étape répond à la question : le comportement du système est-il correct dans tous les cas de figure ?
Le comportement du système est modélisé par des machines d'états finis. Chaque composant possède ses propres états et transitions :
Les sélecteurs (1 et 2) : états Marche / Arrêt / Auto, avec les transitions déclenchées par les événements opérateur.
Les pompes (1 et 2) : états Repos / Pompage, commandées par les signaux Start/Stop du contrôleur.
Le capteur de niveau : états Niveau TTH / Niveau H / Niveau B / Niveau TTB, avec les transitions liées au niveau d'eau réel.
Le contrôleur : états S1-S2 / S1-M2 / M1-S2 / M1-M2, avec la logique de basculement et de redondance.
L'ensemble est simulé : on vérifie que dans chaque combinaison de mode sélectionné et de niveau d'eau, les pompes répondent conformément aux exigences. Les cas limites sont testés sur le modèle avant tout codage automate.

Cette étape répond à la question : le système est-il dimensionné pour tenir ses performances dans les conditions réelles ?
Un modèle Modelica est construit pour simuler les performances hydrauliques du système complet : le débit de drainage entrant, le volume de la bâche, les caractéristiques des pompes, les pertes de charge dans les conduites d'aspiration et d'exhaure, et le point de rejet en surface.
La simulation permet de vérifier que le débit de pompage est suffisant pour évacuer le drainage dans tous les scénarios (débit nominal, débit de crue, fonctionnement sur une seule pompe en cas de panne). Elle permet également de valider le dimensionnement de la bâche à eau et les seuils de déclenchement du capteur de niveau.

Cette démarche en 6 étapes a produit des résultats tangibles :
Maquette virtuelle complète : le système est entièrement spécifié puis simulé avant fabrication. Les erreurs de conception sont détectées et corrigées sur le modèle, pas sur le chantier.
Génération automatique du code automate : le comportement validé au niveau modèle (machines d'états) est traduit directement en code exécutable, éliminant les erreurs de transcription manuelle.
Test progressif : le code est testé successivement sur plateforme logicielle (soft API), sur plateforme matérielle (hard API) et en usine, avec une traçabilité complète vers les exigences.
Réception client 100% conforme du premier coup : l'ensemble des essais sur site a été passé sans non-conformité, précisément parce que chaque exigence avait été vérifiée et validée en simulation avant la fabrication.
Le MBSE n'est pas réservé aux systèmes de pompage. Dès qu'un système combine plusieurs disciplines techniques, la démarche en 6 étapes s'applique.
Voici les questions à se poser :
Le comportement de votre système est-il spécifié dans un document textuel ou dans un modèle simulable ?
Les interfaces entre vos sous-systèmes sont-elles formalisées dans un modèle partagé ou gérées par échanges de documents ?
Le code automate est-il développé à partir de spécifications textuelles ou généré depuis un modèle validé ?
Lors de vos réceptions client, le taux de non-conformité au premier passage est-il acceptable ou génère-t-il des reprises significatives ?
Si le modèle n'existe pas et que la validation se fait uniquement sur site, chaque essai raté est un coût direct sur la marge. Le MBSE est un investissement en phase d'études qui se rentabilise en phase de réalisation et d'essais.
Le MBSE n'est pas uniquement une démarche d'ingénierie. C'est aussi un levier direct de maîtrise économique du projet.
Traçabilité exigences → composants : quand le client demande une modification, son impact est immédiatement mesurable. C'est la base d'une fiche de modification chiffrée et d'une réclamation documentée.
Structure du budget : la décomposition fonctions/composants du modèle MBSE alimente directement le BIPO. C'est le croisement WBS/OBS/ABS de la coûtenance, généré depuis le modèle.
Réduction des reprises : chaque problème détecté en simulation est un surcoût évité sur le chantier.
Réclamations documentées : le modèle constitue une preuve technique objective. Chaque évolution demandée par le client est tracée, valorisée et justifiable.
L'approche MBSE que nous avons mise en œuvre sur ce système de pompage est directement transposable à d'autres sous-systèmes électromécaniques de métro : ventilation, contrôle d'accès, éclairage, signalisation. Couplée à un dispositif de cost control structuré, elle constitue le meilleur levier pour protéger la marge du projet.
À PROPOS
Naviguer dans la complexité des projets de construction avec une expertise en contrôle de projet, contrôle des coûts, planification et intégration des systèmes.
S'ABONNER