where a call to init() causes the task to initialize itself and a call to execute() causes it to start executing. Separation through an abstract interface fosters reusability because it decouples the implementation of the task, which is necessarily application-specific, from the scheduling policy which is used to activate it and which is application-independent.
These three features - use of design pattern to encapsulate an architectural solution, reliance on abstract interfaces, and provision of application-independent components - are typical of frameworks and in this sense the RTOS can be seen as a framework for real-time systems.
It is useful to give an alternative view of an RTOS-based system (the so-called plug-in view):
Here, the RTOS module is shown as a component exposing slots where application-dependent components can be plugged. The application-dependent components represent the tasks to be managed by the RTOS. The slots in the RTOS are therefore the adaptation points (or hot-spots in framework terminology) where the RTOS customisation takes place. The “shape” of the slots that determines whether a certain component can be plugged in is defined by the abstract interfaces that separate task management from task implementation.
Back to Top, Back to Aocs Framework Project Home
A large part of the design of the AOCS framework can be seen as an attempt to provide a positive answer to this question. This was done by first isolating the functionalities present in an AOCS and then systematically applying to each the reusability model of the RTOS.
The functionalities that were identified in an AOCS are:
Back to Top, Back to Aocs Framework Project Home
In current AOCS systems, telemetry processing is controlled by a so-called telemetry handler that directly collects telemetry data, formats and stores them in a dedicated buffer, and then has them transferred to the ground. To accomplish its task, the telemetry handler needs an intimate knowledge of the type and format of the telemetry data: it has to know which data, in which format, and from which objects have to be collected. It is this coupling between telemetry handler and telemetry data that makes the former application-specific and hinders its re-use.
In keeping with the RTOS reuse model, the approach taken in the AOCS project is based on a design pattern – the telemetry design pattern – that calls for a separation of telemetry management from the implementation of telemetry data collection. This is achieved by endowing selected components in the AOCS software with the capacity of writing themselves to the telemetry stream. Telemetry processing is then seen as the forwarding to the ground of an image of the internal state of some of the AOCS components. The resulting architecture is:
The ability of a component to write its own state to the telemetry stream is encapsulated in the abstract interface Telemeterable which must be implemented by all components intended for inclusion in telemetry. Its basic method is writeToTelemetry. Calling it causes a component to write its internal state to the telemetry stream. The telemetry manager is responsible for keeping track of the components whose state should be sent to the telemetry stream and for calling their writeToTelemetry methods to start the forwarding of telemetry data to the ground. The telemetry manager also needs to be aware of the data stream to which the telemetry data should be written. Since the hardware characteristics of the channel over which telemetry data are transmitted to the ground differs across AOCS systems, the telemetry stream is identified by an abstract interface, TelemetryStream. This interface defines the generic operations that can be performed on a data sink representing an ideal telemetry channel.
The second step in the development of an architectural solution for AOCS telemetry management was the instantiation of the telemetry pattern for the AOCS domain. This chiefly involved providing exact definitions for the Telemeterable and TelemetryStream interfaces. The former, for instance, was eventually defined as follows:
In the selected implementation, the telemetry stream is passed as an argument to method writeToTelemetry and methods are provided to check the size and set the format of the telemetry image generated by each component.
In the third and final step of the architecture design process, the telemetry manager component was characterized. The semantics of the telemetry pattern and of its associated abstract interfaces make its definition straightforward. The core of the telemetry manager component can be represented in pseudo-code as follows:
Telemeterable*
tmList[N_TM_OBJECTS];
TelemetryStream* tmStream;
. . .
void activate() {
for (all TM objects
‘t’ in tmList)
{ t->setTelemetryFormat(tmFormat);
tmDataSize=t->getImageLength();
if (object
image fits in TM buffer)
t->writeToTelemetry(tmStream);
else
. . . // error!
}
}
Thus, the telemetry manager maintains a list of telemeterable components and, when it is activated, it calls their writeToTelemetry method. It uses the other operations exposed by Telemeterable to control the format of the telemetry images and to verify that the size of their image is consistent with the capacity of the telemetry channel. Additionally, and not shown in the pseudo code segment, the telemetry manager will offer operations to dynamically load and unload items from its internal list of telemeterable components and to set the telemetry stream at initialisation. Clearly, all these operations are application-independent and hence the telemetry manager is fully reusable component. The AOCS framework also provides a default component implementing the TelemetryStream interface for the case of a DMA-based telemetry channel that happens to be very common in AOCS systems.
The architectural solution to the telemetry management problem therefore exhibits the typical features of a framework being based on a design pattern that is specialized by abstract interfaces and a core component (the telemetry managers) and complemented by a default component (the default implementation of interface TelemetryStream).
The next figure shows a plug-in view of telemetry management. It again draws attention to the similarity between the telemetry management and the RTOS scheduling architectures and on how in both cases reusability originates in the introduction of an abstract interface to separate the management of a functionality from its implementation.
Back to Top, Back to Aocs Framework Project Home
An AOCS will typically contain several control loops serving such diverse purposes as stabilizing the attitude of the satellite, stabilizing its orbital position, controlling the execution of slews, or managing the satellite internal angular momentum.
The objects implementing these control loops tend to implement the same flow of activities starting with the acquisition and filtering of measurements from sensors, continuing with the computation, and ending with the application of commands to actuators designed to counteract any deviation of the variable under control (eg. the satellite attitude) from its desired value. Despite such similarities, existing AOCS’s do not have a unified management of closed-loop controllers which tends to be entrusted to a multiplicity of one-of-a-kind objects that are each responsible for one single control loop.
The AOCS framework by contrast exploits the similarity among closed-loop
controllers to apply to it the RTOS model of reusability. The controller
design pattern
is introduced for this purpose to separate the management of controllers
from the implementation of the (application-specific) control algorithms:
As usual, separation is obtained through an abstract interface whose key method is doControl that directs the component to acquire the sensor measurements, derive discrepancies with the current set-point, and compute and apply the commands for the actuators. Since closed-loop controllers can become unstable, method isStable is provided to ask a controller to check its own stability.
The controller manager component is responsible for maintaining a list of objects of type Controllable and for asking them to check their stability and, if the stability is confirmed, to perform their allotted control action.
As in the case of the telemetry functionality, after the controller design pattern was identified, the second step in the architectural design was its instantiation for the AOCS framework. In this case, an abstract class Controller was used instead of interface Controllable since it was decided that there is some default behaviour that deserves to be encapsulated in a base class. Operations were also added to this class to set the controller in open and closed loop and to enforce limits on the actuator commands.
After the controllable design pattern has been instantiated and its associated class interfaces have been defined, the definition of the controller manager component follows naturally. Its core is:
Controller* cnList[N_CN_OBJECTS];
. . .
void activate() {
for (all controllers
‘c’ in cnList)
{ if (c->isStable())
c->doControl();
else
. . . // error!
}
}
Thus defined, the controller manager becomes a application-independent component. The plug-in view of the controller manager is not shown but would be similar to that of the RTOS scheduler or of the telemetry manager with a controller manager that is customized with plug-in components of Controller type.
Back to Top, Back to Aocs Framework Project Home
Design patterns define solutions for design problems at application level: they prescribe recipes that allow a class of related design problems confronting application developers to be solved in a uniform manner. The term meta-pattern is instead proposed to describe commonalities in different design patterns used to address different design problems in the same framework. Just as design patterns promote consistency at application level by ensuring that similar problems arising in different locations receive similar solutions, meta-patterns support design consistency at the framework level.
The manager meta-pattern addresses the problem of managing a functionality that requires the same actions to be repeatedly performed on a class of objects providing different implementations of the functionality itself. The solution it proposes can be summarized as follows:
The manager meta-pattern was applied to all the AOCS functionalities identified in section 4.2. This resulted in a framework architecture that is both elegant and homogeneous. Extensions and upgrades are facilitated by the mutual independence of the functionality managers that makes addition of facilities to handle new functionalities easy.
Back to Top, Back to Aocs Framework Project Home
A collection of functionality managers represent the reusable architectural
skeleton of the application. This is customized for a specific application
by composition with components encapsulating the application-dependent
functionalities implementations. To each functionality manager an abstract
interface is associated.
The RTOS could be one of the functionality managers and the framework
can therefore be seen as offering a domain-specific extension to the operating
system.
It should be stressed that the same component can be used to customize several functionality managers. A closed-loop controller, for instance, would obviously be plugged into the controller manager but might also be plugged into the telemetry manager if it is desired to include its state in the telemetry stream. This situation is handled through multiple inheritance with a component implementing all the interfaces associated to the functionality managers it customizes. Component_1 in the previous figure, for instance, would have to implement (at least) the abstract interfaces corresponding to the functionality managers A and B.
Use of multiple inheritance is often resisted because it can lead to ambiguities but the AOCS framework only requires multiple inheritance of abstract interfaces which is known to be safe. This kind of multiple inheritance is used extensively throughout the AOCS framework with typical AOCS components normally implementing 5 or 6 different abstract interfaces each representing a different functionality.
The next figure shows how the application architecture implied by the AOCS framework can be recast according to the Generic Open Architecture (GOA) model. GOA is a reference architecture for embedded software to provide a foundation for effective open systems. It distinguishes four layers in a software system: application software, system services, resource access services, and physical resources. In a GOA perspective, an AOCS application is most naturally decomposed by placing the functionality managers in the system services layer alongside the operating system. This choice is dictated by the application-invariant character of the functionality managers and by the fact that they – unlike the components implementing the functionalities – need access to the hardware drivers in the resource access layer. The telemetry manager for instance has an interface to the hardware channel through which telemetry data are routed to the ground.
This figure illustrates again the affinity of functionality managers and operating systems and shows that the framework factors out of an application OS-like functionalities encapsulating them into application-independent modules.
Back to Top, Back to Aocs Framework Project Home