ETTC'2003 - SEE

3. Organisation et Démarche
3.1. Caractéristiques de la qualification du segment sol
Comme introduit au § 2, la qualification du segment sol a été fortement contrainte par la
multiplicité des interfaces, les contraintes de sécurité, les contraintes planning en raison du
nombre élevé de reports successifs du lancement, la désynchronisation des arrivées de certains
sous-systèmes importants comme le SSDS (un an après la QT système).
Pour arriver à réguler l'ensemble des partenaires et leurs expérimentations, une Autorité
spécifique de Gestion, définition et planification fine des Expérimentations a été créée (AGE).
En parallèle à la validation du segment sol, les essais satellite se poursuivaient en salle
blanche à Cannes. Ces essais ont continué à apporter de nombreuses évolutions du LV ayant
un impact sur l'interface bord/sol. Celles-ci ont donné lieu à la nécessité de faire évoluer de
manière significative les logiciels du centre de contrôle.
Un cycle itératif a dû être mis en place pour recetter et intégrer les modifications en un temps
toujours restreint dans les phases de qualification du segment sol
3.2. Méthodologie
La philosophie de validation s'est inspirée des enchaînements classiques d'intégration,
assemblage et qualification technique de chaque sous-système, puis du cycle assemblage,
qualification technique et opérationnelle au niveau du système complet.
L'ensemble des contraintes énoncées au § 3.1 a conduit à distinguer 3 phases de QT/QO de
niveau système : une QT/QO spécifique à la mise à poste, une aux IOT, au maintien à poste et
aux expérimentations plateforme ou charge utile et une troisième liée à l'AGE.
3 Phases d'essais d'opérabilité du satellite concernant la plate-forme et l'ensemble des charges
utiles expérimentales, d'une durée totale de 120 heures ont été également effectués.
La diversité des interfaces a été prise en compte au travers des 3 documents suivants :
- Matrice de conformité aux spécifications systèmes et d'interfaces pour s’assurer que
chaque exigence était couverte par un essai,
- Matrice des échanges des données,
- "Diagramme de séquences" identifiant les acteurs et permettant de schématiser la
fonction entre deux sous-systèmes et les échanges associés, (cf. Annexe)
L’ensemble des ces documents a permis de définir un plan d’essai système fournissant la
colonne vertébrale des qualifications à effectuer, puis des plans d’essais détaillés. Au titre du
cycle itératif de validation, ces documents ont été mis à jour avant chaque nouvelle étape de
validation.
Les plans d'essais ont ainsi été affinés progressivement en fonction des modifications liées
aux interfaces notamment externes et bord-sol, et de leur état de maturité.
Tout essai est régi par le canevas suivant :
• Un Bilan Technique, avant l’essai, permet de réunir tous les intervenants de chaque sous
système afin de dresser un état (version courante, anomalies ouvertes, limitations…), de
planifier et mettre en place l’essai.
• Durant l’essai, le journal d’essai permet de tracer toutes les actions effectuées et chaque
anomalie est répertoriée. En fin d’essai, tous les contextes et données de l’essai sont
sauvegardés et archivés.
7/13