This package defines the classes that support object monitoring. Object monitoring is based on Direct Monitoring design pattern and on the Monitoring Thorough Change Notification design pattern. In general, objects need to monitor each other in order to coordinate their behaviour and for purposes of failure management.

The term monitoring or monitoring action refers to the observation of a change over time in the value of a property. The object performing the monitoring action is called the monitor. The property being monitored is called the monitored property.

Types of Monitored Properties

In general, there are two types of properties that can be monitored in the framework:

• Bound properties

These are properties that are linked to events. Their change results in the firing of an event by the object that owns the property. Monitoring of these properties is based on the Monitoring Thorough Change Notification design pattern.

• Monitorable properties

These are properties that are exposed by objects implementing the interface Monitorable and whose value can be access using the getMonitorableProperty method. Monitoring of these properties is based on the Direct Monitoring design pattern.

Change Objects

At the most basic level, monitors are interested in any change in the monitored property. More frequently, however, they are only interested in certain types of changes. For instance, a failure detection manager may be interested in knowing when the output of a sun sensor exceeds certain pre-specified boundaries, as this might indicate that the spacecraft is going out of control or that the sensor itself is faulty. If the failure detection manager were notified every time the sun sensor output changes, it would have to implement a sensor-specific filtering mechanism to identify the out-of-range changes that might signal a failure. In order to avoid burdening monitors with the need to implement highly specific (and hence non-reusable) filters, the concept of change is encapsulated in objects which are called change objects.

Thus, a change object is an object that encapsulates a specific time profile for a property value. The change is said to have occurred when the property value has violated the time profile.

A change object may encapsulate any time profile. Typical change objects that are likely to be useful in an AOCS (and that are therefore provided as default components by the framework) include:

• Simple change: the change occurs when the monitored property changes its value.

Example: the mode manager of an object registers with the mission manager to be notified whenever the mission mode changes.

• Out-of-range change: the change occurs whenever the monitored property moves outside a pre-defined range.

Example: when a property drifts outside a range of values representing physically possible values, a fault is likely to have arisen. Hence, the failure detection manager registers with the objects representing sensors to be notified when their outputs leave the permitted range.

• Delta change: the change occurs whenever the monitored property changes by more than a pre-defined delta value.

Example: when the output of a sensor suddenly “jumps” by more than a certain threshold, a fault is likely to have arisen. Hence, the failure detection manager registers with the objects representing sensors to be notified when their outputs change too abruptly.

• Filtered delta change: monitors are notified whenever the filtered value of the monitored property changes by more than a pre-defined threshold.

Example: the failure detection manager of the previous example may wish to ignore “spikes” in sensor outputs that might be due to freak conditions not indicative of a real fault. In that case, it registers with the sensor objects to be informed whether its output, after filtering for spikes, exhibits a suspicious change.

Other types of changes may be defined on an ad hoc basis.

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