Space systems are developed using rigorous processes. In Europe, these are most often in accordance with ECSS (European Cooperation for Space Standardization) standards. These standards describe processes that ensure a high level of safety and reliability in the execution of missions. While the use of assurance cases is not explicitly required by ECSS standards, they are often used in practice for complex systems as an element of verification in the project reviews of subsequent phases of the system life cycle.
The context of space projects and ECSS standards
Before moving on to the subject of argumentation for space systems, it should be said that the processes related to such systems are tightly organised throughout development up to flight acceptance, then during operation, which can last many years, until disposal. Strict rules regarding requirements management, testing, verification and validation, and reviews are applied. Reviews continuously generate RIDs (Review Item Discrepancy) requests, the resolution of which is tracked. The gates of the successive phases are defined and the conditions for passing through them are precisely defined. We are talking primarily about the ECSS standards used in Europe, but NASA’s standards are equally rigorous. In such formalised processes, is the use of an assurance case an additional formality, or does it offer benefits?
We would probably not recommend using an assurance case for small CubeSat projects, given the low level of complexity involved. However, it complements the system development process well in larger projects. ECSS standards specify the actions to be taken and the artefacts to be produced. The assurance case demonstrates why you can trust that the system actually possesses the required properties. The argumentation should not merely be a checklist of the standard’s requirements because otherwise we would lose the benefits of using it. Rather, it should present a logical sequence from objectives through argumentation and justification to evidence, all the while remaining in compliance with ECSS standards.
- An assurance case helps identify gaps, such as missing evidence.
- It improves reviews. For reviewers, it allows reviewers to easily trace from objectives to the supporting evidence.
- It makes it easier to scope and manage changes.
- It supports communication between the different groups involved in the project.
- It documents decisions and their justification, which can be useful especially in long-term projects.
Assurance case architecture
As part of our work, we have developed an assurance case architecture that can be used for various systems where ECSS standards apply, assuming a small level of customisation. Our focus is on unmanned missions, excluding any aspects of planetary missions or return to Earth.
The architecture is organised as a modular assurance case. Each module has a clearly defined purpose and scope of responsibility. MAC (Mission Assurance Case) integrates all lower-level arguments and supports lifecycle phase decisions. MA demonstrates that mission objectives are achievable. TA demonstrates that the system possesses the required technical properties and is decomposed into Safety (TA1), Dependability (TA2), Software Assurance (TA3) and Cybersecurity (TA4) modules. CA demonstrates why the argument should be trusted and is decomposed into Verification & Validation (CA1) and Product Assurance (CA2) modules. OP addresses operational capability, while RG addresses residual risk acceptance and governance. The module diagram below presents all the modules of the assurance case. The argument is still under development, but the architecture appears stable.
The diagram uggests that the modules support the main MAC module while being independent of each other; this, however, is a simplification of the diagram itself. The MA/TA/OP modules share evidence with the RG module, which includes holistic risk management. The binding of these modules to CA modules, which can be called the confidence argument, is done by contracts, which is not shown in the diagram.
Argument evolution
Modules evolve through successive phases of the system life cycle. The first phase, Phase 0 (Mission Analysis), is unique. During this phase, the purpose of the assurance case is not to demonstrate that the system meets the requirements, but rather to show that the system can be built and the mission objectives achieved, that no unacceptable risks have been identified at the mission level and that there are no significant technical or operational barriers. This argument is simpler than the full architecture presented above.
The architecture is applicable starting from Phase A (Feasibility). In each subsequent phase, the argumentation is expanded to include further groups of evidence. In Phase A, these are mainly feasibility analyses and preliminary models. Phase B (Preliminary Definition) adds analyses, engineering designs and budgets. Phase C (Detailed Definition) extends the assurance case with detailed design, safety analyses (FTA, FMECA) and reviews. Full verification and independent assessment are carried out in phase D (Qualification & Acceptance), which ends with a Flight Acceptance Review (FAR).
In Prase E (Utilisation), which can last several years (excluding a short subphase E1 – Launch and Early Orbit Phase), operational data is used. The purpose of the argument is to maintain confidence that the mission objectives are being achieved. To a limited extent, there may be changes to the system itself, such as software updates.This argument is simpler than the full architecture presented above.”
Summary
The presented assurance case architecture is oriented towards the characteristics of the system, which corresponds to the main perspective of reviewers. The full life cycle of such an argumentation spans several years. They have clearly defined responsibilities and can use common evidence through explicit contracts or dependencies between modules. Thanks to this, the architecture is scalable and allows for gradual maturation of the argumentation from phase 0 to phase F. At the same time, it supports reviews carried out in subsequent phases, including the aforementioned FAR, which is the main decision-making point allowing the system to fly.
The architecture of the argument evolves with the successive phases of the system’s life cycle. This architecture will be maintained for a few years. Although we have discussed the basic assumptions of this architecture, there are still many important related topics. These will be covered in subsequent posts.
The presented assurance case architecture is developed as part of a project carried out jointly with the Gdańsk University of Technology.
Andrzej Wardziński