 |
In order to understand the benefits of implementing the AOCS Framework components using a component standards, consider the problem of reporting data to telemetry. The skeleton of an object-oriented architecture for this problem was presented in another example. The proposed design is based on the following abstract class (represented using C++ style):
class Telemeterable
{
void
writeToTelemetry()=0;
}
This class encapsulates the fundamental functionality required for telemetry
data handling, namely the ability of an object to write its own state to
a telemetry stream. The classes of objects whose state might have to be
sent to telemetry are made to inherit from class Telemeterable.
This means that they will have to provide an implementation for the writeToTelemetry
method. The telemetry manager now must simply keep a list of references
to objects of type Telemeterable
and must periodically call method writeToTelemetry
on each object in the list. The resulting architecture is shown in the
figure:
|
The arrows indicate an inheritance relationship. The red box is the telemetry manager. This is an application-independent and hence fully reusable component. In the current implementation, the telemetry manager and its telemetry obects must reside in the same address space since the telemetry managers handles the telemetry objects through pointers to objects of type Telemeterable.
Telemetry management is a function that is usually performed by every
subsystem on a satellite. If the subsystems are physically located on different
processors, or even only in different partitions on the same processor,
then each subsystem will require its own telemetry manager component. This
is clearly wasteful. A more efficient architecture has a single telemetry
manager that is able to see all its telemetry objects as if they resided
in the same address space. A component infrastructure provides precisely
the mechanisms to make this possible. This situation is shown in the next
figure where the dashed line represents the boundary between the processor
where the telemetry manager is located (normally the satellite central
computer) and another processor (for instance, the AOCS computer). The
telemetry manager performs calls to method writeToTelemetry upon
objects that may reside on other processors (or in different partitions
on the same processor) but is unaware of any difference with respect to
the case of local method calls. The translation from one address space
to another and the shuffling of any method parameters is done by the component
infrastructure invisibly to the telemetry manager or its clients.
 |
The basic implementation of the telemetry manager is as follows:
Telemeterable* list[N];
. . .
for (all objects
in list) do
list[i]->writeToTelemetry();
Unless a component infrastructure is assumed, the telemetry manager must reside in the same process (same address space) as the telemetry objects. Moreover, in practice, it will often be necessary for all participants in the telemetry management architecture to have been written in the same language and compiled with the same compiler.
If, however, both the telemetry manager and the telemetry objects are implemented on top of a component infrastructure (such as for instance CORBA or COM) then the telemetry manager may reside in one process and the telemetry objects may reside in other processes or even on other processors. This would make it possible to have on a satellite one single telemetry manager component located in the satellite computer that is responsible for controlling the telemetry flow from objects residing in all other satellite processors (eg. the AOCS computer).
Back to Framework Design Principles, Back to Aocs Framework Project Home