OBS Framework

Implementation - Real Time Issues

Code Level Compatibility

At code level, the OBS Framework components are implemented to make static analysis of execution times possible. More precisely, the component expose two types of methods:initialization methods and operational methods. The former are intended to be called only during the application initialization phase and before the real-time part of the application has been entered. The latter may be called at any time. All operations that are not compatible with static timing analysis are confined to the initialization methods. This in particular applies to dynamic memory allocation operations. In an application instantiated from the OBS Framework, all memory for the application components is allocated at initialization time.

In some cases, there is a need to dynamically gain access to a new component. This is for instance the case for telecommand components that must be configured when the telecommand is received. For these situations, the framework providesdynamic component factories that can provide unconfigured components from an internally managed pool of preallocated component instances. The dynamic factory components are tailored to the needs of a particular application and are therfore generated by a dedicated generator meta-component.

The architecture of the OBS Framework is heavily based on object-oriented design patterns. Such design patterns sometimes introduce recursion. The depth of the recursion, however, can always be statically bounded which ensures compatibility with static timing analysis.

Architectural Level Compatibility

In its default form, the OBS Framework is only compatible with a cyclical non-preemptive real-time architecture. The typical entry points for a scheduler are the activate methods that are exposed by the following components:

• CC_TelecommandManager
• CC_TelemetryManager
• CC_ManoeuvreManager
• CC_PunctualActionManager
• CC_FSM
• Concrete telecommand loaders derived from the abstract class TelecommandLoader

However, it should be stressed that application designers are in principle free to use other methods offered by the framework components. For instance, in another typical case, they might choose to link to the scheduler theexecute methods declared by punctual action components (components derived from the base abstract classPunctualAction).

The OBS Framework does not implement any synchronization or concurrency mechanisms. All method calls are synchronous and non-blocking. Furthermore, all methods are intended to model actions that are executed in a very short period of time. Actions that are intended to extend over prolonged periods of time can be modelled using the manoeuvre mechanism (see the manoeuvre management design pattern).

If it is desired to use real-time architectures other than a simple cyclical non-preemptive architecture, then the framework components must be modified to be endowed with synchronization mechanisms and with activation mechanisms. For this purpose, the OBS Framework will offer transformer meta-components that can automate this tailoring process. The meta-components will implement various synchronization and activation mechanisms (e.g. Java-like synchronize, Ada-like protected types, HRT-HOOD style cyclical and sporadic objects, etc). The implementation will make use of operating system primitives and the meta-components will therefore model the most commong operating systems for OBS applications.