ETTC'2003 - SEE
ETTC'2003 - SEE ETTC'2003 - SEE
AUS Station STA TM/TC Station STS TM/TC/LOC Station SLF MD Le schéma suivant explicite la variété importante d'interfaces : KOUROU Station KUK TM/TC/LOC Liaison RNIS RTD Liaison RNIC TM/TC/LOC COR/COO CCES Télégestion Station STS - SLF SIMULATEUR Satellite MINI SSV Station SLF MD RTD HBK VISUTM + Navigateur Internet Station SLF MD Liaisons RNIC PC LOC Traitement MA/MD FT OUTIL POM Préparation Données Ops (POM/BD TM/TC/Displays) VISUTM + Navigateur Internet VISUTM Visualisation/Monitoring TM PC SUPRES Supervision Reseau SERVEUR WWW Interne Extraction/ analyse TM/JDB/Données Ops & Expé ODS Liaisons RTC et Internet Calculs Orbitographie/Manoeuvre ESA/REDU VISUTM + Navigateur Internet 6/13 FRONTAL TM/TC Acquisition TM/ Préparation & envoi TC TERMINAUX X Dialogue TC BDT Interne Stockage TM/JDB/Données Ops/ Expé AGENDA Planification Opérations AGE Expérimentations CU ROC DGA Navigateur Internet AGENDA : Planification Expés + STENPO : Prévisions bilan de puissance Liaisons RTC RTD SSDS VISUTM + Navigateur Internet RTD TIME NAVIGATOR Sauvegarde/Archivage/ Restauration Données & Applis SDM EXPER SERVEUR WWW Externe Extraction/ analyse TM/JDB/Données Expé RTD BDT Externe Stockage TM/JDB/ /Données Expé Préparation/Traitement Expés GPS & Orbito Surveillance du spectre ROC PC MES Messagerie Opérationnelle (CCES Expérimentateurs) Liaisons RTC VISUTM + Navigateur Internet
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
- Page 87 and 88: • Un IHM de sélection des param
- Page 89 and 90: 9. CONCLUSION OSIRIS a maintenant g
- Page 91 and 92: TABLE DES MATIERES 1. LE DATA-LINK
- Page 93 and 94: AVIONS appartenant au réseau 25_P_
- Page 95 and 96: • Les données à émettre sur le
- Page 97 and 98: • 25_P_2/04 PCM émis par l'avion
- Page 99 and 100: 3.2 Le temps différé • En temps
- Page 101 and 102: 4. CONCLUSION • Toutes les IHM in
- Page 103 and 104: INTRODUCTION Pour définir des proc
- Page 105 and 106: - Ecarts de position en temps réel
- Page 107: ANNEXE 1 CONSTITUTION CONSTITUTION
- Page 110 and 111: They however incorporate some eleme
- Page 112 and 113: As technology evolves, the boundary
- Page 114 and 115: shown below together with the AGE c
- Page 116 and 117: BACK ESSAIS SYSTEME SUR LES PROJETS
- Page 118 and 119: 3 qui contient le logiciel de vol.
- Page 120 and 121: 5 • essais en station « in vivo
- Page 122 and 123: Avis, options et recommandations (5
- Page 124 and 125: BACK Automatic Validation of Flight
- Page 126 and 127: − The second level provides all d
- Page 128 and 129: The operational flexibility of SINU
- Page 130 and 131: • Test duration is reduced : for
- Page 132 and 133: mimics from CCS ones. The objective
- Page 134 and 135: 1. Introduction ...................
- Page 136 and 137: 2. Présentation Le segment sol Ste
- Page 140 and 141: • La Commission de Revue d’Essa
- Page 142 and 143: Certains essais particuliers liés
- Page 144 and 145: Id Nom flux EXP37 Plan de vol Annex
- Page 146 and 147: TTC’2003 Stentor 10/06/2003 QUALI
- Page 148 and 149: TTC’2003 Le Programme Stentor 10/
- Page 150 and 151: TTC’2003 Satellite GEO TM/TC/Rang
- Page 152 and 153: TTC’2003 •Equipes CNES : Qualif
- Page 154 and 155: TTC’2003 •L’organisation mise
- Page 156 and 157: TTC’2003 Interfaces Externes :
- Page 158 and 159: TTC’2003 Les Contraintes de Déve
- Page 160 and 161: TTC’2003 Contient ontient la la m
- Page 162 and 163: TTC’2003 10/06/2003 Qualification
- Page 164 and 165: TTC’2003 10/06/2003 Qualification
- Page 166 and 167: BACK Résumé : Outil de traitement
- Page 168 and 169: 1 Principes généraux de l’outil
- Page 170 and 171: 1.2.3 Valise de piste L’outil peu
- Page 172 and 173: 2 Capacités fonctionnelles 2.1 Arc
- Page 174 and 175: Vue f(t) 2.3.1 Vues y=f(t) Ces vues
- Page 176 and 177: Maquette aéronef Alarmes Bar-graph
- Page 178 and 179: 2.3.3 Représentation trajectograph
- Page 180 and 181: 2.3.5 Vidéo Par ailleurs, si le ma
- Page 182 and 183: 3 Concept de structure d’accueil
- Page 184 and 185: 4 Exemples d’utilisation 4.1.1 HB
- Page 186 and 187: SESSION 3 : Capteurs et dispositifs
3. Organisation et Démarche<br />
3.1. Caractéristiques de la qualification du segment sol<br />
Comme introduit au § 2, la qualification du segment sol a été fortement contrainte par la<br />
multiplicité des interfaces, les contraintes de sécurité, les contraintes planning en raison du<br />
nombre élevé de reports successifs du lancement, la désynchronisation des arrivées de certains<br />
sous-systèmes importants comme le SSDS (un an après la QT système).<br />
Pour arriver à réguler l'ensemble des partenaires et leurs expérimentations, une Autorité<br />
spécifique de Gestion, définition et planification fine des Expérimentations a été créée (AGE).<br />
En parallèle à la validation du segment sol, les essais satellite se poursuivaient en salle<br />
blanche à Cannes. Ces essais ont continué à apporter de nombreuses évolutions du LV ayant<br />
un impact sur l'interface bord/sol. Celles-ci ont donné lieu à la nécessité de faire évoluer de<br />
manière significative les logiciels du centre de contrôle.<br />
Un cycle itératif a dû être mis en place pour recetter et intégrer les modifications en un temps<br />
toujours restreint dans les phases de qualification du segment sol<br />
3.2. Méthodologie<br />
La philosophie de validation s'est inspirée des enchaînements classiques d'intégration,<br />
assemblage et qualification technique de chaque sous-système, puis du cycle assemblage,<br />
qualification technique et opérationnelle au niveau du système complet.<br />
L'ensemble des contraintes énoncées au § 3.1 a conduit à distinguer 3 phases de QT/QO de<br />
niveau système : une QT/QO spécifique à la mise à poste, une aux IOT, au maintien à poste et<br />
aux expérimentations plateforme ou charge utile et une troisième liée à l'AGE.<br />
3 Phases d'essais d'opérabilité du satellite concernant la plate-forme et l'ensemble des charges<br />
utiles expérimentales, d'une durée totale de 120 heures ont été également effectués.<br />
La diversité des interfaces a été prise en compte au travers des 3 documents suivants :<br />
- Matrice de conformité aux spécifications systèmes et d'interfaces pour s’assurer que<br />
chaque exigence était couverte par un essai,<br />
- Matrice des échanges des données,<br />
- "Diagramme de séquences" identifiant les acteurs et permettant de schématiser la<br />
fonction entre deux sous-systèmes et les échanges associés, (cf. Annexe)<br />
L’ensemble des ces documents a permis de définir un plan d’essai système fournissant la<br />
colonne vertébrale des qualifications à effectuer, puis des plans d’essais détaillés. Au titre du<br />
cycle itératif de validation, ces documents ont été mis à jour avant chaque nouvelle étape de<br />
validation.<br />
Les plans d'essais ont ainsi été affinés progressivement en fonction des modifications liées<br />
aux interfaces notamment externes et bord-sol, et de leur état de maturité.<br />
Tout essai est régi par le canevas suivant :<br />
• Un Bilan Technique, avant l’essai, permet de réunir tous les intervenants de chaque sous<br />
système afin de dresser un état (version courante, anomalies ouvertes, limitations…), de<br />
planifier et mettre en place l’essai.<br />
• Durant l’essai, le journal d’essai permet de tracer toutes les actions effectuées et chaque<br />
anomalie est répertoriée. En fin d’essai, tous les contextes et données de l’essai sont<br />
sauvegardés et archivés.<br />
7/13