Management of modes and states is a wide, complex, and often underestimated part of systems engineering. As systems and missions become more complex, the potential combination of modes and states across system, subsystem, and component levels becomes exponential and difficult to master. This presentation proposes a methodological approach for studying and integrating the impact of modes and states on the architecture definition. It establishes the concepts of configuration and situation as keys to analyzing these impacts. The presentation illustrates this approach with the use case of a nano-satellite and demonstrates how the approach is supported by a modeling tool.
Modes and states are amongst the most ambiguous and the least understood concepts in systems engineering. Several aspects have to be considered:
- The specification of the expected functional behavior of the system in different contexts
- The supervision of the expected functional behavior of the system and the detection of possible failures
- The combinatory of the modes and states of the system and of its components
- The possible dynamic reconfigurations to be performed during system operation, in particular in reaction to failures
- The startup and stopping of the system and its components
- Etc.
Challenges are numerous:
- Being able to prove that the system expected behavior can be reached in all possibly realizable combinations of modes, states, at system and subsystem level.
- Being able to study the reconfigurations of the system while it operates.
- Using modes and states as a support to perform analyses on the system. For example, in the domain of satellite launchers, the mass, power and communications profiles vary significantly according to the flying phases, and the modes of each subsystem
________________________
Overview of the approach
__
1. Specification of modes and associated atomic configurations. The first step consists in defining the expected behavior to face the different contexts the system will face. This includes all or parts of the following:
- Identification of the different contexts required simultaneously: for example, operational mission or training, fully operational or maintenance, autonomous or remotely piloted by an operator, etc.
- For each context, formalization of one mode machine specifying all possible transitions
- The content of each mode is then detailed in an atomic configuration that primarily describes the functional and non-functional content (required capabilities, functions, scenarios and functional chains to be played, etc.) but might also include some structural content (components, interfaces, physical connections, etc.).
- The triggers and conditions for all possible transitions between modes within a mode machine can then be specified, and if possible, related to elements such as functional exchanges or execution of functions.
__
2. Specification of states and associated atomic configurations. The different simultaneous state machines that can impact the content and behavior of the system (presence or absence of components, health status of physical components, environmental conditions, etc.) can be defined following the same patterns as the ones used for the definition of modes. Atomic configurations are also used to primarily describe how specific states translate in terms of structural content and associated properties.
__
3. Identification of “superposition” situations. Once the expected behavior of the system is specified, it has to be confronted to the situations that can influence or harm it during its operating time. Each situation identifies the required superposition of modes (logical combination of modes in each mode machine) as well as the states likely to occur in this situation (typically feared states like attack, failure, external disturbance, etc.). A situation is a combination of distinct modes and states, all currently active in their own context.
__
4. Definition of global configurations of interest. Unlike atomic configurations, global configurations are not directly associated to any specific mode or state. Instead, they are used to capture an expected system behavior of interest. There are multiple reasons why a specific system behavior (scenario, functional chain, etc.) can be of interest: because it corresponds to a particularly critical point of the system, because it is a customer specific request, because it is a minimal behavior to be preserved whatever the operating conditions, etc.
__
5. Computation of the global configuration corresponding to each situation of modes and states. Each superposition situation of several modes aggregates constraints coming from the atomic configurations associated to each mode. These atomic configurations have to be combined, which might bring contradictions (for example, a function can be required in a mode and rejected in another, a functional chain can become incomplete because of rejected functions, etc.). The following step of the approach is therefore to build the global computed configuration, merging all atomic configurations associated to the modes involved in the considered situation. The merging rules have to be refined (this is the topic of an ongoing work), but a simple union is a good starting point. The internal consistency of this resulting global configuration can then be analyzed. Inconsistencies mean either the modes machines or the atomic configurations have to be reworked.
__
6. Confrontation with expected global configuration of interest. Optionally for each given situation, if global configurations of interest have been defined, it is possible to compare them to the global computed configuration and detect inconsistencies.
__
7. Analysis of the computed global configurations for situations mixing modes and states. From a technical or conceptual standpoint, situations involving states could be managed the same way as situations involving only modes. However, it is generally recommended to treat them incrementally, in a second step.
__
8. Adaptation of the architecture. If the delta between the expected behavior and the result of the analysis is not acceptable, a compromise has to be sought, if possible by reworking the architecture to restore the expected behavior. This can take several forms, including:
- Functional reallocation (for example to move critical functions in a less vulnerable component)
- Introduction of degraded modes (for example triggering a dynamic reconfiguration of resources), introduction of redundancy
- Improvement of configurations associated to certain states (using for example more reliable components)