Une plateforme, soixante satellites : la gestion de configuration des constellations

Une constellation repose sur une promesse : concevoir le satellite une fois, puis le construire de nombreuses fois. En pratique, les satellites d'une constellation sont presque identiques, pas identiques. Un fournisseur change un composant entre le lot 2 et le lot 3. Un plan orbital embarque une option de charge utile différente. Une unité qui a échoué en recette est reprise. Quelques satellites volent avec une dérogation acceptée après revue.

Chacune de ces différences est petite. Ensemble, sur des dizaines de satellites et plusieurs années de production, elles rendent difficile une question simple : qu'y a-t-il exactement sur le satellite 37 ?

Ce que demande l'ECSS-M-ST-40C

L'ECSS-M-ST-40C, la norme ECSS de gestion de la configuration et de l'information, définit quatre activités qui s'appliquent à tout produit spatial, quel que soit le volume de production :

• —L'identification de la configuration : définir les articles de configuration et les documents qui les décrivent, et établir des baselines à des points convenus du programme.
• —La maîtrise de la configuration : gérer chaque modification d'une baseline par un processus formel, y compris les demandes de modification et le traitement des dérogations.
• —L'enregistrement de l'état de la configuration : tracer et publier la configuration courante de chaque article et l'état de chaque modification.
• —La vérification et l'audit de la configuration : vérifier que le produit tel que construit correspond à sa documentation de configuration.

Pour un seul satellite, beaucoup d'équipes gèrent cela avec des documents et des tableurs. Pour une constellation, les quatre mêmes activités doivent s'appliquer à chaque unité, et le volume d'enregistrements grandit à chaque lot.

Pourquoi les tableurs cèdent à l'échelle d'une flotte

L'approche habituelle consiste à copier. Chaque satellite reçoit sa propre liste telle que construite, dérivée de la conception de référence. Quand la référence change, quelqu'un met à jour chaque copie. Quand un satellite s'écarte, quelqu'un le note dans le dossier de ce satellite.

Cela fonctionne pour cinq satellites. À soixante, trois problèmes apparaissent :

• —Les copies divergent. Une modification appliquée à la référence est oubliée sur deux satellites. Personne ne le voit avant un audit ou une analyse d'anomalie.
• —Les dérogations se perdent. Une dérogation acceptée sur une unité est notée dans un document que le lot suivant ne lit pas.
• —Les questions d'impact prennent des jours. Quand une pièce partagée pose problème, l'équipe doit savoir quels satellites la portent, dans quelle révision, et quelles exigences et quels essais sont touchés. Avec des copies, il faut ouvrir chaque dossier.

Une plateforme partagée et les écarts de chaque satellite

La structure qui fonctionne, c'est l'héritage plutôt que la copie. La plateforme est modélisée une fois : ses exigences, sa structure produit, ses interfaces et sa vérification. Chaque satellite hérite de la plateforme et n'enregistre que ce qui diffère : une autre révision de composant, une option de charge utile, une dérogation acceptée, une reprise.

Dans Koddex, les variantes fonctionnent ainsi. Une variante de satellite hérite de la plateforme commune, et ses propres éléments et attributs remplacent ceux de la plateforme là où ils diffèrent. La configuration du satellite 37 est alors la plateforme plus ses écarts enregistrés, calculée plutôt que tenue à la main.

Les baselines suivent la même logique. Le programme fige une baseline de la plateforme à chaque revue, et la configuration telle que construite de chaque satellite peut être figée à la recette. Vous pouvez comparer deux baselines côte à côte : la plateforme avant et après une modification, ou deux satellites de lots différents.

Ce qui se passe quand une pièce partagée change

Supposons qu'un fournisseur annonce une modification d'un composant utilisé sur tous les satellites à partir du lot 2. Les questions sont toujours les mêmes :

1. 1.Quels satellites portent ce composant, et dans quelle révision ?
2. 2.Quelles exigences dépendent de ses propriétés (masse, puissance, comportement thermique, tenue aux radiations) ?
3. 3.Quels essais et quelles analyses ont vérifié ces exigences, et sont-ils encore valables ?
4. 4.Quels satellites sont déjà construits, et lesquels peuvent encore recevoir la modification ?

Avec un modèle partagé, l'analyse d'impact répond à ces questions dans une seule vue : Koddex suit les liens du composant vers chaque variante de satellite, exigence, essai et baseline qui en dépend. Le comité de modification voit la liste complète avant de décider, et la décision et sa raison sont enregistrées sur les éléments concernés.

Le périmètre des fournisseurs

Les programmes de constellation s'appuient sur de nombreux fournisseurs. Chacun doit voir les interfaces et les exigences de son équipement, et rien d'autre. Dans Koddex, les droits d'accès sont définis par partenaire sur le même modèle : un fournisseur travaille dans son périmètre, l'exigence reste liée au satellite, et le maître d'œuvre garde une seule source de vérité au lieu d'échanger des tableurs.

Là où les agents IA aident

L'enregistrement de l'état de la configuration relève en grande partie de la tenue de registres, ce qui en fait un bon terrain pour des agents qui travaillent comme des coéquipiers. Un ingénieur peut leur assigner des tâches comme :

• —« Lister chaque satellite qui porte la révision C de ce composant et rédiger la demande de modification. »
• —« Vérifier que chaque dérogation acceptée sur le lot 3 apparaît dans la configuration telle que construite. »
• —« Comparer les baselines telles que construites des satellites 12 et 37 et résumer les différences. »

L'agent travaille sur une branche, prépare le résultat, commente ce qu'il a trouvé et le remet pour relecture. Le gestionnaire de configuration l'approuve ou le corrige. Chaque action est enregistrée dans le journal d'activité.

Par où commencer

Un premier périmètre réaliste : une plateforme et deux satellites de lots différents.

• —Modéliser la structure produit de la plateforme et ses principales exigences.
• —Créer les deux satellites comme variantes et enregistrer leurs différences connues.
• —Figer une baseline de chacun et les comparer.
• —Lancer l'impact d'une vraie modification de composant.

Si la comparaison fait apparaître une différence que personne n'avait notée, le modèle s'est déjà rentabilisé. Pour aller plus loin : Koddex pour les programmes spatiaux, ou le cycle en V mené sur les mêmes données.