Package RtjAocsFramework.ModeManagement

This package defines the classes that support mode management.

See:
Description

Class Summary

AocsMissionModeManager	This class encapsulates a mission mode manager.
CyclingModeManager	This class encapsulates a cycling mode manager that uses the "on-call mode update mechanism" to cycle through its modes in a fixed sequence.
FollowerModeManager	This class encapsulates a follower mode manager that uses the "reactive mode update" mechanism: its mode is the same as the mode of a master mode manager.
ModeChangeAction	Base class from which all objects encapsulating to be taken when a mode manager performs a mode change are derived.
ModeManager	This class encapsulates a core mode manager and acts as base class for all mode managers.
NullModeChangeAction	Dummy mode change action whose mode entry and exit methods take no action and simply pass on the request to the next item in the chain of responsibility.
TestCaseModeManagement_1	Test case for mode managers: check configuration of cycling mode manager.
TestCaseModeManagement_2	Test case for mode managers: check mode transition operations in a cycling mode manager.
TestCaseModeManagement_3	Test case for mode managers: check the follower mode manager mechanism.
TestCaseModeManagement_4	Test case for mode managers: check the AOCS mission mode manager.
TestCaseModeManagement_5	Test case for mode managers: same as TestCaseModeManagement_1 but using the default constructor for the cycling mode manager.
TestCaseModeManagement_6	Test case for mode managers: check the mode change action mechanism.
TestModeChangeAction	Dummy mode change action that increments a counter whenever its doModeExit and doModeEntry methods are called (this is useful for testing purposes).

Package RtjAocsFramework.ModeManagement Description

This package defines the classes that support mode management. Mode management is based on the Mode Management design pattern.

Current on-board systems are based on the concept of operational mode. The operational mode is an attribute of the on-board software as a whole. Its purpose is to adapt the software’s behaviour to various sets of external conditions. As one moves to a component-based approach, the basic design choice is between:

• keeping a single operational mode for the whole on-board system;
• making operational mode a property of individual components.

The first approach requires a “mode manager” object which is responsible for ensuring that each object behaves in a manner that is consistent with the current mode. This object would act as a centralized coordinator of object behaviour. As such, it would require a rather detailed understanding of how each object is constructed and of what its internal state is. This approach would weaken data encapsulation and is therefore rejected by the framework.

The selected approach makes operational mode a property of each component. Components now become responsible for updating their own operational mode in response to changes in the environment around them. A component keeps track of changes in its environment by monitoring properties of other objects. An object monitors the property of another object by using the mechanisms offered by the monitoring framelet. Note that a monitored property could also be the operational mode of another component. Hence, the traditional architecture with a system-wide operational mode could be implemented by having each component implement the same set of modes and by having components change their own mode to follow changes initiated by a “mode manager” object.

As an example of the decentralized mode concept adopted by the framework, consider the attitude controller object. The controller object is responsible for implementing the attitude control law. A controller object could have two modes: low accuracy control, and high accuracy control. The switch between the two modes could be done, for instance, on the basis of the size of the attitude error. The controller object would then register its interest in the attitude error and would ask to be notified when this error crosses a certain threshold. The notification that the attitude error has crossed the selected threshold would trigger a mode change.

More details on manoeuvre management can be found in the mode management technical note.