Future Developments

The following projects are considered as follow-ups to the AOCS Framework Project:

The first project started in February under phase II of the present contract with ESA. It is described under the Real Time Java Project web site. The second project was briefly started but then suspended due to lack of funding. The other projects only exist as proposals.

Back to Top, Back to Aocs Framework Project Home

Java Implementation

The version under development of the AOCS Framework is written in C++. Java is in many respects a better language for the this type of application because it is simpler and safer, it includes a tasking model, and it offers built-in support for components. Unfortunately, in its standard version, Java is at present unsuitable for use in real-time applications. Additionally, the interpreted nature of the language causes long execution times which might be incompatible with the CPU-constrained environment of an on-board processor.

Both these concerns are being addressed. On the one side, real-time extensions of Java are currently under development that guarantee predictable execution times and a stricter threading model. While on the other side, pre-compilation techniques and processors implementing the Java Virtual Machine promise to bring the performance of Java code in line with that of languages like C or C++.

The objective of this follow-up project is to port the existing version of the AOCS Framework to Java and then test it on a real-time Java platform. One option under consideration at present is the use of the aJile board that offers a hardware implementation of the JVM which includes one of the most recent version of the experimental real-time API's of Java. An alternative implementation option is the Jbed system of Esmertec.

This activity is being pursed as part of the Real Time Java Project.

Back to Top, Back to Aocs Framework Project Home

Delegate Object Mechanism

Mainstream component middleware (CORBA or DCOM) is difficult or impossible to use in distributed real-time applications because it does not guarantee timing predictability. This project aims to develop a concept to allow framework components to interact as if they resided within the same address space even when they are located in different processes or in different CPUs while at the same time preserving the timing predictability that is essential to real-time applications. The objective is develop a middleware infrastructure that is specifically optimized for the AOCS Framework. 

This activity was briefly started in a dedicated project but was then suspended.

Back to Top, Back to Aocs Framework Project Home

Integration with Simulation Environment

An AOCS application must undergo extensive testing before being deployed. Realistic testing can only be done by running the AOCS software in a representative hardware environment that reproduces the characteristics of the target AOCS processor. This type of testing with hardware in the loop is however very expensive and can only be done towards the end of the development cycle of the software. In the early stages of the development process, functional testing can be sufficient and would be best done in the same all-software environment in which the AOCS application is being developed.

This project aims at complementing the AOCS framework with a simulation framework that is designed to make it easy to perform functional tests on an AOCS application by simulating the AOCS and its external environment in open- and closed-loop. The testing framework will include hooks where users can specify the models for the external environment and the type of data monitoring and data logging that they wish to perform on the AOCS under test. More information on the requirements of simulation framework are given in a dedicated page.

Back to Top, Back to Aocs Framework Project Home

Proba Flight Experiment

A framework is a tool to generate applications within a certain domain. The AOCS prototype framework developed in phase I implemented the main functionalities of an AOCS framework and was tested by using it to generate a prototype AOCS. The prototype AOCS is a simplified AOCS.

This project aims at extending the prototype framework to become a full AOCS framework and at using it to generate an AOCS software to be flight-tested on Proba. Proba is a microsatellite being developed by ESA as a technology demonstration mission. It is expected to be launched in the second half of 2001.

Back to Top, Back to Aocs Framework Project Home

CORBA Implementation

The version under development of the AOCS Framework is designed as a set of components where the term component is used to designate a binary unit of reuse implementing one or more interfaces. The framework prototype however is not built upon a component infrastructure.

The objective of this follow-up project is to implement the AOCS framework on the TAO system. TAO is a real-time CORBA implementation.

See this example for an illustration of the benefits of implementing the AOCS framework on top of a component standard.

Back to Top, Back to Aocs Framework Project Home

Real-Time IDL

Once the AOCS Framework is built upon a component infrastructure (such as CORBA), the interfaces of the AOCS components will have to be specified in a language like IDL. Existing versions of IDL, however, are inadequate for real-time and mission-critical systems because in such systems interface information should include timing and criticality data (at the very least). Thus, a declaration of a method interface should include a specification on the execution time of this method and when two components are plugged together, a check should be performed that they are compatible not only in terms of their signature but also in terms of their timing requirements

For instance, suppose component A needs a service from component B. The interface of component A must specify what is the maximum time that A is prepared to wait for its request to be serviced and the interface of component B must specify what is the maximum time for the servicing of the request. Plugging together of the two components should only be allowed when the two timing specifications are compatible.

Because of the criticality of real-time systems, the interface of their components should also specify some kind of access control. For instance, a component should be able to specify that some of its methods are only accessible from components of a certain type. Once again, plugging together of components should only be allowed when the access control restrictions are met.

The objective of this follow-up project is to develop a version of IDL suitable for specification of interface of real-time components and to test its implementation on a port of the AOCS Framework to an component infrastructure.

Back to Top, Back to Aocs Framework Project Home

Application to Other Systems

The AOCS Framework is being aimed at the Attitude and Orbit Control Subsystem of satellites. However, many of the constructs it proposes are of wider applicability. The framework, for instance, covers functionalities like: Such functionalities are found in many (if not all) spacecraft subsystems. Indeed, fucntionally similar concepts are found in most embedded control systems.

The objective of this follow-up project is to exploit the structure of the AOCS framework - which is built as a collection of lower-level entities (the so-called framelets) - to port it to other spacecraft subsystems or to other kinds of embedded control systems.

Back to Top, Back to Aocs Framework Project Home

Last updated on Feb. 5-th 2002 by Alessandro Pasetti