21.04.2013 Views

ETTC'2003 - SEE

ETTC'2003 - SEE

ETTC'2003 - SEE

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

a satellite anomaly from ground. On-board FDIR will automatically perform the<br />

reconfiguration. This type of procedure is used to run in a redundant equipment (such as earth<br />

sensors) or to anticipate nominal equipment failure.<br />

3. Reconfiguration to redundant equipment managed by ground: no reconfiguration mechanism is<br />

implemented on-board. The model of such FCP is the following : (1) replace commands sent<br />

by the on-board SW to nominal equipment by commands sent to redundant one. It is done<br />

through on-board SW patches (as far as SPOT/HELIOS satellites are concerned). (2) configure<br />

monitoring to redundant parameters instead of to nominal ones ; and vice versa. This is done<br />

also by patch.<br />

4. Reconfiguration to nominal equipment managed by ground: same principle as procedures of<br />

type 3. But this type of FCP is usually not defined in Flight Control Manuals because its use is<br />

rare.<br />

3. Test case definition<br />

A test-case model for FCPS of type 1 (recovery managed by on-board SW) is introduced. To<br />

validate such FCPS the steps are the following :<br />

1. Satellite initial context is a routine one with an operational payload; this context results from a<br />

previous simulation and is restored to start the scenario.<br />

2. Withdraw FCP is first executed to reconfigure to redundant equipment; this is the initial state of<br />

the recovery FCP, which is the procedure to validate. This procedure includes all the required<br />

telemetry verifications to check that the redundant configuration is correctly reached.<br />

3. Recovery FCP is run to return to nominal configuration and verifications are performed.<br />

4. Programming message execution (MdP) comes afterwards: this step is important because it<br />

consists in testing the capacity of running programming messages on redundant equipment.<br />

Furthermore, some devices require MdP execution to be switched on. The same MdP is used<br />

for all test-cases. It was constructed to be as complete as possible in the terms of payload use.<br />

5. Withdraw FCP is executed to finalise the test-case: the objective is ensure that on-board FDIR<br />

is still capable to withdraw to redundant configuration when an anomaly occurs. This<br />

verification is necessary because of the use of patches within “withdraw FCP”.<br />

Notice that “recovery FCP” validation requires to define and validate corresponding “withdraw<br />

FCP”, even if the latter is less important because less likely to be used operationally.<br />

4. Testing facilities<br />

Two satellite operation simulators were used during the compatibility, Technical (QT) and<br />

Operational Qualification (QO) phases for satellite SPOT5.<br />

The first simulator, the BSSO (Banc Système Satellite Opérationnel – Operational Satellite<br />

System Test-bench), is a hybrid test-bench, i.e. composed of hardware and software elements,<br />

developed by the satellite prime contractor (ASTRIUM). The main characteristic of this simulator is<br />

the presence of real hardware (mock-ups) for all equipment containing software (OBC, etc.).<br />

The second simulator, SINUS (Simulateur Numérique Satellite – satellite digital simulator), is a<br />

purely digital simulator developed by CNES as internal prime contractor. Its main characteristic is<br />

the presence of an MA31750 processor emulator which allows it to operate faster than real-time.<br />

4

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!