Real-Time Java AOCS Framework v1.0 API Specification

Package RtjAocsFramework.ReconfigurationManagement

This package defines the classes that support reconfiguration management.

See:
          Description

Interface Summary
Reconfigurable Interface characterizing reconfiguration managers.
 

Class Summary
ConfigurationState This class encapsulates the state of a reconfiguration manager.
ReconfigurerHelper Helper class for managing a reconfiguration group.
TestCaseReconfiguration_1 Test case for reconfiguration classes: check reconfigurer helper with default constructor.
TestCaseReconfiguration_5 Test case for reconfiguration classes: same as TestCaseReconfiguration_1 but using the default constructor for ReconfigurerHelper.
 

Package RtjAocsFramework.ReconfigurationManagement Description

This package defines the classes that support reconfiguration management. Reconfiguration management is based on the Reconfiguration Management design pattern. More information can be found in the reconfiguration management technical note.

Definition of Key Terms

If the same functionality can be implemented in two or more independent ways, then the functionality is said to be redundant. A redundant functionality can be reconfigured. Reconfiguration means switching between different independent implementations of the same functionality.

Functionalities in the AOCS software are implemented as services (method calls) provided by objects. The functionality with respect to which reconfiguration takes place is called the reconfigurable functionality. The reconfigurable functionality must be represented by an interface.

A reconfiguration group is a set of objects that together offer a redundant functionality. A reconfiguration group can be the object of a reconfiguration.

A redundant object is an object belonging to a reconfiguration group.

The order of the reconfiguration group is the number of independent, functionally equivalent, configurations offered by the group.

Configurations in a reconfiguration group may be ranked according to the performance level with which they implement the group’s functionality.

A configuration in a reconfiguration group is marked either “healthy” or “unhealthy”. When a reconfiguration takes place, the configuration the group is configuring away from is marked as “unhealthy”.

Some Examples

Reconfiguration usually occurs in response to detection of an error: if one implementation of a functionality is found to be faulty, reconfiguration makes the functionality available again by switching from a faulty to a (hopefully) correct implementation.

An example of a redundant group is the objects representing two aligned sun sensors (prime and redundant sun sensor). In this case, the functionality is the provision of sun position information. A reconfiguration means switching from one to the other sun sensor. The order of this reconfiguration group is 2. If the two sun sensors have identical characteristics, then the two configurations have the same ranking, otherwise the configuration including the most accurate sun sensor has the higher ranking.

Another example of a redundant group is a set of four non-aligned gyros .  The functionality offered by this group is the provision of 3-axis rate information. A reconfiguration means to switch from one set of three gyros to a different set of three gyros. The order of this reconfiguration group is four (there are four sub-sets of three gyros in a set of four gyros). The ranking of the four configurations depends on the characteristics of the gyros and on their geometric disposition.

Still another example of reconfiguration group is represented by a set of the following units: a fine sun sensor, a 3-axis gyro package, and an autonomous star tracker. The functionality offered by this group is the provision of high-accuracy attitude information. High accuracy attitude information can be provided either by combining fine sun sensor and gyro data or directly by an autonomous star tracker. Hence, this group has a reconfiguration order of 2 (in one configuration the FSS and GYR are used, and in the other configuration the AST is used). The ranking of the two configurations depends on the relative accuracy of the sensors and on the quality of the data filtering used in the FSS/GYR configuration.
 
 


Real-Time Java AOCS Framework v1.0 API Specification

Real-Time Java AOCS Framework project home page

Automatic Control Laboratory, ETH Zuerich
Physikstrasse 3
CH-8092 Zuerich, Switzerland