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.