FDIR Check Design Pattern


Offer a solution to the unified management of fault detection, isolation and recovery (FDIR) check that is independent of the specific FDIR check.

Based On

This pattern is based on the principle of object composition and encapsulation.


On-board systems perform FDIR checks. An FDIR check usually consists of at least two separate actions: the fault detection and isolation check (FDI check) and the recovery action. The FDI check must ascertain whether a fault has occurred and it must identify the cause of the fault. The recovery action must remove or at least counteract the fault. The recovery action is performed only if the fault detection and isolation check has revealed the existence of a fault and has given an indication of where its origin lies. Both the FDI check and the recovery action may of course be subdivided into sub-checks and sub-actions that are executed in sequence.

The OBS Environment offers design patterns that cover the performance of FDI checks (the variable monitoring design pattern) and of recovery actions (the recovery action design pattern). The present design pattern offers a solution to the problem of performing a complete FDIR check in a unified manner that is independent of both the particular FDI check and the particular recovery action.

Dictionary Entries

The following abstractions or domain-wide concepts are defined to support the implementation of this design pattern:


The design pattern assumes that the FDI check and the recovery action are encapsulated in components that are characterized by, respectively, an "FDI check" interface and a "recovery action" interface. The presence of these interfaces makes it possible to define an FDIR Check component as shown in the class diagram that encapsulates both the FDI check and recovery action components and that manages their execution.

The FDIR check component exposes an execute operation. Its execution causes the FDI check to be executed first, its outcome to be evaluated and, if this outcome indicates that a fault has occurred, the recovery action to be executed.

Obviously, the FDIR check must be configurable and it would normally expose operations to load the FDI check and the recovery action components.

Normally, several FDIR checks must be executed. For this reason, the client component in the class diagram is shown as holding references to multiple FdirCheck components.



A typical operational scenario for this design pattern is:



There is a need to implement an FDIR policy that is independent of the particular FDI checks and recovery actions that are used by the application.

Implementation Issues

The discussion above assumes that there is a single FDI check component. The pattern could easily be adapted to the case where fault detection and fault isolation are split and encapsulated in two different components. The only requirement for the use of the pattern is that these components be characterized by an abstract interface.

There is normally a requirement that it must be possible to enable and disable FDIR checks. Enabling and disabling must be possible both at the level of the individual FDIR check and at the global level (all checks are simultaneously enabled/disabled). With the concept proposed by this design patterns, such requirements can be easily implemented by endowing the FdirCheck component with an enable status that can be set both at the level of the individual component and at the class level (implementation as a static variable). The implementation of the execute operations would then have to be modified to check the enabled status before executing the FDI check and its attendant recovery action.

There is often a requirement that FDIR checks be conditional: they must be executed only if certain conditions hold (e.g. if the satellite is in a certain operational mode). With the concept proposed here, this type of requirement can be implemented by treating the FdirCheck component as a form of conditional punctual action in the sense of the punctual action design pattern. The execution check can then be used to implement the conditions for the execution of the FDIR Check.

OBS Framework Mapping

The implementation of this design pattern in the OBS Framework is supported by the following classes:

Sample Code

Consider an application that implements two FDI checks that are encapsulated in concrete classes: ConcreteFdiCheck_A and ConcreteFdiCheck_B. These two classes implement the abstrat interface FDICheck that characterizes all FDI checks. Assume that the recovery actions associated to these FDI checks are: ConcreteRecovery_A and ConcreteRecovery_B.

If the approach proposed by this design pattern is followed, then the initialization phase of the application will contain code like this:

    ConcreteFdiCheck_A* pFdiCheck_1;
    ConcreteFdiCheck_B* pFdiCheck_2;
    ConcreteRecovery_A* pRecovery_1;
    ConcreteRecovery_B* pRecovery_2;
    . . .
    // create and configure first FDIR Check component
    FdirCheck fdirCheck_1;
    // create and configure second FDIR Check component
    FdirCheck fdirCheck_2;
The operational phase of the application that is responsible for implementing the FDIR policy will instead contain code like this:
Clearly, the configuration of the two FDIR check components can be dynamically changed at run time (for instance, by loading new recovery actions) without this having any impact on the above code. The implementation of the FDIR policy has thus been decoupled from the implementation of the individual FDI checks and recovery actions.




A. Pasetti (P&P Software)

Last Modified


Contact Us | The OBS Framework Project