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.
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.
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
executeoperation. 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
The component that is in charge of implementing the FDIR policy.
Abstract interface characterizing a generic FDI check.
The component encapsulating a specific FDI check.
Abstract interface characterizing a generic recovery action.
The component encapsulating a specific recovery action.
A typical operational scenario for this design pattern is:
- During the initialization phase, an
FdirCheckcomponent is created for each FDIR check foreseen by the application.
FdirCheckcomponents are configured with the FDI check and associated recovery actions.
FdirCheckcomponents are loaded into the client component which is in charge of the FDIR policy.
- The client component periodically executes all the
FdirCheckcomponents in sequence.
- The configuration of the
FdirCheckcomponents may be changed dynamically while the application is running (for instance, in order to associate a new recovery action to an certain fault.
It is easier to design a reusable component that is responsible for implementing the
FDIR policy. This component can be made reusable if it only handles
FdirCheckcomponents which are independent of the (application-dependent) FDI checks and recovery actions.
It is easier to tune the FDIR policy at run time. This can be done by reconfiguring the
- The definition of FDI check, recovery action and FDIR check components provides a conceptual framework for formulating the FDIR policy of an application. Users are forced to think about individual FDIR checks, about the recovery actions to be associated to them, and about their joint execution. In particular, users are forced to think of FDI checks and recovery actions as indivisible and closely linked: in an embedded system, it does not make sense to define an FDI check for which no recovery action can be specified and, conversely, it does not make sense to define recovery actions for faults that cannot be detected.
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.
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
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
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
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:
- FdirCheckcomponent -->
Consider an application that implements two FDI checks that are encapsulated in concrete
two classes implement the abstrat interface
FDICheck that characterizes all
Assume that the recovery actions associated to these FDI checks are:
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; fdirCheck_1.setFDICheck(pFdiCheck_1); fdirCheck_1.setRecoveryAction(pRecovery_1); // create and configure second FDIR Check component FdirCheck fdirCheck_2; fdirCheck_2.setFDICheck(pFdiCheck_2); fdirCheck_2.setRecoveryAction(pRecovery_2);The operational phase of the application that is responsible for implementing the FDIR policy will instead contain code like this:
fdirCheck_1.execute(); fdirCheck_2.execute();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)