ECSS-E-ST-10-02C en pratique : construire la matrice de vérification pendant la conception du satellite

Chaque programme satellite finit par produire le même document : un tableau qui liste chaque exigence, la manière dont elle sera vérifiée, à quel niveau, et si elle l'a déjà été. L'ECSS-E-ST-10-02C, la norme européenne de vérification des produits spatiaux, appelle l'outil qui suit cet état le Verification Control Document (VCD). Les équipes parlent souvent de matrice de vérification.

La norme ne dit pas quand la construire. En pratique, beaucoup d'équipes la remplissent tard, dans les semaines qui précèdent la revue critique de conception (CDR), en reparcourant les documents d'exigences, les rapports d'analyse et les plans d'essais. Cet article explique pourquoi la construire dès la première exigence va plus vite, et à quoi cela ressemble quand exigences, conception et vérification vivent dans le même modèle.

Ce que demande l'ECSS-E-ST-10-02C

L'ECSS-E-ST-10-02C définit le processus de vérification des produits spatiaux. En résumé, elle demande au projet de :

• —Attribuer une méthode de vérification à chaque exigence : essai (T), analyse (A), revue de conception (R) ou inspection (I), seule ou combinée.
• —Attribuer un niveau de vérification : équipement, sous-système, élément ou système.
• —Attribuer une étape de vérification : par exemple qualification, recette, pré-lancement ou en orbite.
• —Suivre l'état de chaque vérification jusqu'à sa clôture avec une preuve : rapport d'essai, rapport d'analyse, compte rendu de revue ou d'inspection.

La séquence des revues est définie par l'ECSS-M-ST-10C. À chaque revue (PDR, CDR, puis revue de qualification et revue de recette), le projet montre où en est la vérification. Le VCD est le document que lisent les relecteurs pour répondre à une question : pour chaque exigence, sait-on comment elle sera prouvée, et l'a-t-elle été ?

Pourquoi la matrice est souvent construite tard

Trois habitudes repoussent la matrice à la fin de la conception.

Exigences et vérification vivent dans des fichiers différents. La spécification d'exigences est un document. Le plan de vérification en est un autre. Les procédures d'essai et les rapports d'analyse en représentent des dizaines. La matrice est l'endroit où ils se rejoignent : elle ne peut donc être remplie qu'une fois qu'ils existent tous.

La méthode est choisie trop tard. Une exigence comme « l'ensemble roue à réaction doit supporter les niveaux de vibration aléatoire de qualification » a une méthode évidente (essai). Beaucoup d'autres n'en ont pas. Quand personne ne choisit la méthode au moment où l'exigence est écrite, la décision attend que quelqu'un doive remplir la matrice.

Les modifications cassent la matrice sans bruit. Une exigence est reformulée après la PDR, un sous-système est repris, un essai est fusionné avec un autre. Chaque modification devrait mettre la matrice à jour. Quand la matrice est un tableur tenu par une seule personne, elle s'écarte de l'état réel de la conception, et l'écart apparaît pendant la préparation de la revue.

Le résultat est un rush bien connu : avant la CDR, les ingénieurs système passent des semaines à réconcilier les identifiants d'exigences, à chercher des rapports d'analyse et à vérifier que chaque ligne pointe vers une vraie preuve.

Construire la matrice dès la première exigence

L'alternative est simple à décrire. Quand une exigence est créée, elle porte déjà :

1. 1.Sa méthode de vérification (T, A, R, I).
2. 2.Son niveau et son étape de vérification.
3. 3.Un lien vers l'activité de vérification qui la clôturera : un cas d'essai, une analyse, un point de revue ou une inspection.

Quand l'activité de vérification produit sa preuve, la preuve est liée à l'activité. La matrice n'est alors plus un document que quelqu'un écrit. C'est une vue du modèle : on filtre les exigences, on affiche leur méthode, leur niveau, leur étape et leur état, et on l'exporte pour la revue.

Dans Koddex, c'est ainsi que sont modélisées exigences et vérification. Chaque exigence est un élément avec ses propres attributs, lié aux éléments de conception qui la satisfont et aux essais ou analyses qui la vérifient. La matrice de vérification est générée à partir de ces liens : elle est à jour le jour de la revue. La même structure porte tout le cycle en V : la branche gauche définit et décompose, la branche droite prouve, et les liens entre les deux sont explicites.

Ce qui change à chaque revue

À la PDR, la matrice montre la méthode et le niveau de chaque exigence. Les relecteurs voient tôt quelles exigences dépendent d'un essai qui n'existe pas encore, ou d'une analyse sans responsable. Ces trous coûtent peu à combler à la PDR.

À la CDR, la matrice montre quelles activités de vérification sont planifiées, lesquelles ont commencé et lesquelles sont closes. Comme la matrice est générée à partir du modèle, la préparer prend quelques heures au lieu de plusieurs semaines.

Aux revues de qualification et de recette, la preuve est déjà attachée à chaque ligne. La question « où est le rapport qui prouve cette exigence ? » a une réponse à un clic.

Ce qui se passe quand une exigence change

C'est sur les modifications qu'un modèle lié se rentabilise. Quand une exigence est reformulée ou que sa valeur change, Koddex liste les éléments de conception, les activités de vérification et les preuves qui en dépendent. L'essai qui vérifiait l'ancienne valeur est signalé comme rouvert. L'ingénieur décide si l'essai doit être refait ou si la preuve existante reste valable. C'est l'analyse d'impact que les équipes font sinon de mémoire.

Là où les agents IA aident

Une grande partie de la tenue de la vérification est répétitive : vérifier que chaque exigence a une méthode, que chaque cas d'essai remonte à au moins une exigence, que chaque vérification close a sa preuve attachée. Les agents Koddex prennent ces tâches comme le ferait un collègue. Un ingénieur assigne la tâche, par exemple « vérifier la couverture de vérification du sous-système puissance avant le dossier de CDR ». L'agent travaille sur une branche, liste les trous, commente chacun et propose les liens manquants. L'ingénieur relit le résultat et le fusionne. Chaque action de l'agent est enregistrée dans le journal d'activité, dans les droits de son compte.

L'ingénieur garde les décisions : quelle méthode est acceptable, si une analyse suffit, si une dérogation est justifiée. L'agent supprime les heures de recoupement autour de ces décisions.

Par où commencer

Pas besoin de modéliser tout un engin pour commencer. Un bon premier périmètre est un sous-système et ses exigences :

• —Importer les exigences du sous-système (Koddex structure une spécification PDF ou tableur en exigences liées, qu'un ingénieur relit).
• —Ajouter à chaque exigence sa méthode, son niveau et son étape de vérification.
• —Lier les cas d'essai et les analyses existants.
• —Générer la matrice et la comparer avec celle que vous tenez aujourd'hui.

La différence apparaît en général tout de suite : des exigences sans méthode, des essais qui ne vérifient rien de la liste, des preuves qui existent mais ne sont référencées nulle part. Combler ces trous à ce stade, c'est ce qui raccourcit la revue suivante.

Voyez comment fonctionne la gestion des exigences dans Koddex, ou réservez une démo sur l'un de vos sous-systèmes.