FDIR Spacecraft fault protection system

1. Project 1 Part 1 FDIRSpacecraft fault protection system Euro Team Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Design for Software & Systems

2. Table of ContentS • Background • Functionnal requirements • Non-functionnal requirements • Use-case model

3. Background Functionnalrequirements Non-functionnalrequirements Use-case model Background • Fault • Detected when monitored values are out-of-tolerance • Fault protection system (FDIR) • Act when the spacecraft is going through an error or a fault • FDIR is a layered system. If a lower layer cannot resolve an issue it’s forwarded to an upper layer. If the Issue cannot be resolved by the system. It’s escalated to manual control. • Automatic system • Spaceship crew and flight control can manually control the system

4. Background Functionnalrequirements Non-functionnalrequirements Use-case model Requirements • Global Requirements : • Guarantee the completion of any time critical activities of the spaceship • Keep the control of the spacecraft with safety, observability & commandability

5. Background Functionnalrequirements Non-functionnalrequirements Use-case model Requirements (cont.) • Fault Recovery :

6. Background Functionnalrequirements Non-functionnalrequirements Use-case model ReQUIREMENTS (cont.) • Safing response in the case of hazardous conditions :

7. Background Functionnalrequirements Non-functionnalrequirements Use-case model NON-Functional REQUIREMENTS • Testability • The system and its parts have to be able to be tested through inspections, simulations and analyses before on-board installation • Reliability • The system must be reliable in all operating conditions. System failure could lead to loss of human life. • Availability • The system must not lock or stall when processing data. It must work asynchronously.

8. Background Functionnalrequirements Non-functionnalrequirements Use-case model Non-functional requirements • Resilience • The system must be able to maintain an acceptable level of service in spite failures in parts of the FDRI system. • Response time • The system must respond in timely manner so that problematic systems can be shut down before any damage is done. • Documentation • Technical and software documentation has to be accurate so that the spacecraft crew and flight control know how to administer the system and perform actions through it.

9. Background Functionnalrequirements Non-functionnalrequirements Use-case model Use case diagram explaNATIONS • Most of the time FDRI works automatically. However, spaceship crew and flight control can manually control the system. • These interactions are represented in the following use case diagram.

10. Background Functionnalrequirements Non-functionnalrequirements Use-case model Use case DIAGRAM

11. Background Functionnalrequirements Non-functionnalrequirements Use-case model Use CASES Descriptions • Shutdown one part of the system: • Context of use : a part of the system is failed, we want to shutdown it • Actors : Crew / Flight control • Pre-condition: none • Post-condition: the part of the system is shutdown • Guaranty in case of success : any actions could not be done to this part • Guaranty in case of failure : the system turns on

12. Background Functionnalrequirements Non-functionnalrequirements Use-case model Use CASES Descriptions (cont.) • Restart one part of the system: • Context of use : a part of the system is shutdown, we want to restart it • Actors : Crew / Flight control • Pre-condition: the part is shutdown • Post-condition: the part is switched on • Guaranty in case of success : Any action could be done after reboot • Guaranty in case of failure : the system is off yet

13. Background Functionnalrequirements Non-functionnalrequirements Use-case model Use CASES Descriptions (cont.) • Switch to backup system: • Context of use : the current system is corrupted • Actors : Crew / Flight control • Pre-condition: none • Post-condition: the faulty system is switched to a spare system • Guaranty in case of success : the system is not corrupted yet • Guaranty in case of failure : none

14. Background Functionnalrequirements Non-functionnalrequirements Use-case model Use CASES Descriptions (cont.) • Find information about a part of the system: • Context of use : the crew wants to know some information about a part of the system • Actors : Crew / Flight control • Pre-condition: none • Post-condition: the crew receives the information • Guaranty in case of success : we have the information • Guaranty in case of failure : we don't have the information

15. Background Functionnalrequirements Non-functionnalrequirements Use-case model Sequence diagram • Fault recovering

17. Background Functionnalrequirements Non-functionnalrequirements Use-case model Sequence diagram (cont.) • Safing response in case of hazardous condition

19. Background Functionnalrequirements Non-functionnalrequirements Use-case model Sequence diagram (cont.) • Critical failure

21. Project 1 Part 1 FDIRSpacecraft fault protection system Euro Team Alauzet Pierre, Ahvenniemi Mikko, Colin Julien, Starck Benoit CS554 - Design for Software & Systems

22. references • [Eas98] Steve Easterbrook, and et al., “Experiences Using Lightweight Formal Methods for Requirements Modeling,” IEEE Transactions on Software Engineering, Vol. 24, No. 1, January 1998.