ETTC'2003 - SEE
ETTC'2003 - SEE ETTC'2003 - SEE
• Test duration is reduced : for instance, in case of SPOT5, a recovery procedure test case consists in about fifty TC groups (a TC group is a sequence of one to five TC) and several hundreds of TM parameters to check. Automatic simulation requires less than ten minutes to run such a test case. With respect to operability tests, running the same test case is much longer : about half a day and with a larger team. • Reusability : both operational data (FCPs, TC groups) and testing data (test procedures, test scripts, produced log-books) are assets which are (re)usable in different contexts : − Reusability for non-regression testing : upon change of satellite configuration (such as modification of the on-board software ), test cases can be re-run with low effort. Furthermore, test logbooks can be automatically compared for testing non regression. − Reusability for other satellites : Helios2 is the military successor of SPOT5 satellite. Helios2 shares SPOT5 platform and some payload elements. − Use for operator training : Operational et testing data together with the automatic validation technique provide easy and ready to use facilities for operator training. 3 Improve testing coverage : • Procedure coverage can be more complete because testing takes less time. • Additional test cases can be introduced. • Specified/checked TM effects can be more numerous. • Non regression testing can be conducted systematically when satellite configuration changes. Use for SPOT5 qualification Automatic validation was used along SPOT5 qualification and after launch : 1. To start with, many procedures were pre-validated by means of automatic simulation before conducting operability tests. This initial fine tuning using SINUS off line enabled to save time because errors early detection enables to avoid re-running operability tests. Errors were found in TM effect specification. But also errors were detected in TC specification. For instance, several LVC patches used in different procedures were wrong. 2. Secondly, automatic validation enabled to run more test cases and thus to cover procedure paths which were not considered during operability tests. 3. In the last months before launch (operational qualification), the focus has been put then on nonregression testing. This was particularly important in the case of SPOT5 qualification because three different versions of the on-board software were released during the operational qualification. And the last version was issued and tested only three weeks before launch. The automatic simulation technique was intensively used to run non-regression test cases and to compare produced test log-books automatically. Twenty test cases were defined to be run automatically, covering about 70% of the procedures used to recover from anomalies. These test cases were executed for each version of the on-board software. About 10.000 verifications were performed altogether. 4. After launch, validation activities went on, in particular for payload FDIR FCPs ; they were neither defined nor validated before, because of lack of time. By then, automatic validation was systematically used. Concerning these particular FDIR FCPs, the choice has been taken to differ their validation with the control centre in the loop: operability tests may be conducted only when a procedure is really needed for a satellite operation, in order to confirm automatic validation results and more important to train operators just before satellite operation. 7
7. Validation process FCP validation follows several steps. Each of them is required in order to enable FCP execution onboard the satellite: 1. Documentation analysis: FCP specification is derived and checked up on input documents (satellite operation manual, satellite database, onboard SW specification [LVC]). In particular, patch definitions are verified on source code (Ada and processor code). Notice that most FCPS had been pre-validated by satellite contractor Astrium. 2. Automatic validation with SINUS: The automatic validation technique enables to verify two types of properties : a) Liveness or fonctionnal properties : they ensure that “something good” occurs. Expected states are specified by means of TM parameter values. These specifications can be associated either to TC, FCP steps or test cases for contextual verifications. b) Safety properties : they ensure that “nothing bad” happens. They consist on ground monitoring which provide systematic verification of the non-occurrence of predefined unwanted states (expressions based on TM values) or events. SINUS interprets the same ground monitoring as CCS does during real time satellite operations. 3. Review process: periodical technical meetings are organised. They are very useful in the terms of FCPs and test results review. They also contribute to staff training. 4. Satellite Control Center in the loop: Automatic validation is not sufficient to validate because CCS is not in the loop to transmit TC. When ground control facilities (CCS) are in the loop, validation is manual: TC are sent from CCS and TM parameters are displayed and checked up manually on CCS mimics. These tests are more expensive because they involve a larger team. That is why they are only conducted when other verifications are completed. 8. Limitations and future work Limitations of procedure automatic validation are presented in relation with possible improvements: 1. Automatic validation technique does not replace operability /system tests because the satellite control center is not in the loop to transmit TC. This limitation is intrinsic to the approach. 2. For few satellite equipment or sub-systems, SINUS numeric models are not representative. That is the case for Vegetation which is SPOT5 secondary payload. Vegetation operational procedures have to be validated using BSSO and its Vegetation model. But for many procedures (platform ones and most of payload ones) SINUS representativity is sufficient : an important feedback of SPOT5 qualification is that a processor emulator together with an accurate calculator simulation model seem equivalent to hardware equipment for FCP validation. 3. Presently SINUS mimics (when running SINUS offline) differ from the ones used in the control centre. The development of a translator is under progress to generate automatically SINUS 8
- Page 79 and 80: • VX Wxorks reste l'OS de la part
- Page 81 and 82: 6.5 Exemple d'interconnexion avec d
- Page 83 and 84: PRINCIPE 7.3 Exemple de réalisatio
- Page 85 and 86: 8. LA NOUVELLE GAMME SUR PC: VÉNUS
- 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 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 138 and 139: AUS Station STA TM/TC Station STS T
- 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
7. Validation process<br />
FCP validation follows several steps. Each of them is required in order to enable FCP execution<br />
onboard the satellite:<br />
1. Documentation analysis: FCP specification is derived and checked up on input documents<br />
(satellite operation manual, satellite database, onboard SW specification [LVC]). In particular,<br />
patch definitions are verified on source code (Ada and processor code). Notice that most FCPS<br />
had been pre-validated by satellite contractor Astrium.<br />
2. Automatic validation with SINUS:<br />
The automatic validation technique enables to verify two types of properties :<br />
a) Liveness or fonctionnal properties : they ensure that “something good” occurs. Expected<br />
states are specified by means of TM parameter values. These specifications can be associated<br />
either to TC, FCP steps or test cases for contextual verifications.<br />
b) Safety properties : they ensure that “nothing bad” happens. They consist on ground<br />
monitoring which provide systematic verification of the non-occurrence of predefined unwanted<br />
states (expressions based on TM values) or events. SINUS interprets the same ground<br />
monitoring as CCS does during real time satellite operations.<br />
3. Review process: periodical technical meetings are organised. They are very useful in the terms<br />
of FCPs and test results review. They also contribute to staff training.<br />
4. Satellite Control Center in the loop: Automatic validation is not sufficient to validate because<br />
CCS is not in the loop to transmit TC. When ground control facilities (CCS) are in the loop,<br />
validation is manual: TC are sent from CCS and TM parameters are displayed and checked up<br />
manually on CCS mimics. These tests are more expensive because they involve a larger team.<br />
That is why they are only conducted when other verifications are completed.<br />
8. Limitations and future work<br />
Limitations of procedure automatic validation are presented in relation with possible improvements:<br />
1. Automatic validation technique does not replace operability /system tests because the satellite<br />
control center is not in the loop to transmit TC. This limitation is intrinsic to the approach.<br />
2. For few satellite equipment or sub-systems, SINUS numeric models are not representative. That<br />
is the case for Vegetation which is SPOT5 secondary payload. Vegetation operational<br />
procedures have to be validated using BSSO and its Vegetation model. But for many procedures<br />
(platform ones and most of payload ones) SINUS representativity is sufficient : an important<br />
feedback of SPOT5 qualification is that a processor emulator together with an accurate<br />
calculator simulation model seem equivalent to hardware equipment for FCP validation.<br />
3. Presently SINUS mimics (when running SINUS offline) differ from the ones used in the control<br />
centre. The development of a translator is under progress to generate automatically SINUS<br />
8
Change language