Project Overview

The goal of the AOCS Framework Project is to design and prototype an object-oriented software framework for the AOCS software.

Currently, the AOCS software is rewritten from scratch for every new system. Yet, the fact that the overall structure and requirements of an AOCS change little from mission to mission should allow a substantial level of reuse. For instance, all AOCS systems must be able to process telecommands, to generate telemetry, to perform failure detection checks, to implement control laws, etc. This project uses framework technology to capture this commonality of functionality and to make it re-usable across projects.

Software frameworks are a promising application of object-oriented technology that promote the reuse, extensibility and maintainability of software. They are well-established in the area of system software (graphical user interfaces, editors, operating systems). Frameworks differ from other re-use technologies because they make architectural (as opposed to code) re-use possible.

Project Objectives
Assumptions
Technology
Framework Architecture
Framework Testing Approach
Programme of Work
Application to Other Spacecraft Subsystems
Related Projects

Back to AOCS Framework Home Page

Project Objectives

The specific objectives pursued for the AOCS framework are:

Architectural Reusability: At present, most AOCS systems are re-designed for each new mission. In some cases, code fragments are re-used across missions (generally only if the same contractor is responsible for software development in different missions) but the architecture - often the toughest part to design - cannot be ported at all. The objective is to produce a system that encapsulates a generic architecture for an AOCS system allowing re-use of architecture or architectural features across missions.

Component Reusability: AOCS software re-usability is now possible at most at the subroutine level and even this is usually very difficult because small functionality changes need code changes and hence complete re-testing of the subroutine. The objective is to build a system made up of components that can be re-used as binary units without changes while allowing functionality tuning through inheritance or object composition.

Architectural Extensibility: at present, it is possible to extend the functionality of an AOCS system by modifying the algorithms coded in its subroutines. Changes with architectural impacts (eg adding a new mode or a new telecommand) are, however, much harder and more expensive to implement. The objective is build a system that, while freezing certain architectural decisions, leaves other explicitly open for modification.

Compatibility with Autocode Tools: The objective is to build an architecture that allows embedding of code generated by autocode tools (eg Matlab or Xmath)

Object Oriented Design: Current AOCS software systems follow the modular paradigm. The objective is to design a system that conforms to truly object-oriented (as opposed to merely object-based) principles. Object-orientation is regarded as the soundest paradigm in software design available at the moment.

Click here for an overview of the design principles used in the AOCS Framework Project to attain the above objectives.

Back to Top, Back to Aocs Framework Project Home

Assumptions

The ultimate objective of this project is to improve the re-usability - and hence lower the cost and enhance the reliability - of AOCS software. This objective is achieved by exploiting recent advances in software engineering (the transition to the OO paradigm) and in microprocessor technology (the space-qualification of the ERC32 processor).

Technological advances can be used either to expand the functionality of a class of software or to improve its quality. Historically, the emphasis has been on the former task. This is why successive revolutions in software engineering - the transition to compiled languages, then to procedural languages, and still later to modular languages - have not had a major impact on software quality (programs are as error prone and as poorly readable/reusable today as they were in the sixties!). The intention of this project is to concentrate on the latter task. Hence, the AOCS Framework covers only the present functionalities of AOCS systems. By constraining functionality to its present level, technological advances will be leveraged to improve quality and reduce development costs.

The framework design is therefore based on the following assumptions:

Implementation on the ERC32 processor
Use of object-oriented languages and constructs
Restriction to functionalities implemented on existing AOCS

Back to Top, Back to Aocs Framework Project Home

Technology

The project objectives stated above are achieved through the application of component and framework technologies.

The term component is used here designates a binary unit of reuse that can be configured for use in a specific application at run-time. Real Time Operating Systems (RTOS) are examples of components with non-standard interfaces in use in the real-time field. RTOS´s offer a reusable solution to a specific problem and can be purchased as off-the-shelf items. This project attempts to show that in an AOCS system there are other parts of the software that can be packaged as reusable entities.

Collections of components with predefined cooperations among them are called frameworks. Frameworks capture an architectural design optimized for a specific domain. They predefine the composition and interaction of the components of a system while at the same time allowing for customization by providing hooks where default behaviour can be overridden. Frameworks differ from other reuse technologies because they make architectural (as opposed to code) reuse possible and because they rely on object composition and inheritance as functionality-extension mechanisms.

Software frameworks are built on object-oriented languages. The AOCS framework is being developed in C++ but could be ported to other OO languages.

Back to Top, Back to Aocs Framework Project Home

Framework Architecture

The project objectives stated above are achieved by developing a component-based software framework for the AOCS domain.

The inspiration for the design of the AOCS framework was drawn from the example of Real Time Operating Systems (RTOS). RTOS's constitute a very successful - and often overlooked - example of software reuse in the real-time field. For over two decades, packages have been available as commercial off-the-shelf products that offer generic solutions for the management of functionalities like task scheduling or synchronization of access to shared resources. Reusability is achieved by separating the management of these functionalities from their implementations.

The question that was asked early in the AOCS project was: if the management of functionalities like task scheduling can be encapsulated in application-independent and hence reusable components, why shouldn't the same be possible for typical AOCS functionalities like telecommand management, telemetry management, controller management, failure detection and recovery management, etc?

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. This approach resulted in an architecture that sees the AOCS framework as a domain specific extension to the operating system.

Click here for a more detailed description of the framework architecture.

Back to Top, Back to Aocs Framework Project Home

Framework Testing Approach

Software frameworks are not runnable applications, they are artifacts from which such applications can be instantiated. The problem of testing a framework (as opposed to testing the applications instantiated from it) is currently unsolved and a subject of research. In the AOCS framework project, testing was done at three levels. At design level, implementation cases were used to continuously check the adequacy of the framework design.

At unit level, framework components were tested through conventional test harnesses that provide an environment within which the component under test can be embedded and its behaviour verified.

At system level, the prototype framework was used to instantiate a prototype AOCS application. The AOCS prototype is a simplified AOCS software which is implemented using the constructs offered by the AOCS prototype framework. It is not intended to be representative of any real AOCS. Its interest lies simply in the extent to which it allows the functionalities of the AOCS prototype framework to be exercised and the constructs exported by it to be utilized.

The AOCS prototype was tested on an ERC32 target simulator where measurements were also performed to estimate the overheads in terms of memory and CPU usage that are introduced by the use of framework technology. The results of these measurements are presented here.

It should be stressed that the amount of testing performed on the framework prototype is inadequate to allow its immediate operational usage. The objective of the AOCS framework study was not to develop a product for commercial use but rather to test and assess a new and promising technology. The prototype framework would however be suitable as a basis for the development of a commercial AOCS framework.

Back to Top, Back to Aocs Framework Project Home

Programme of Work

The project is divided into two phases. The main tasks foreseen for phase I are:

Architectural design of the AOCS framework
Partial implementation of an AOCS framework (framework prototype)
Testing of the framework prototype by using it to develop a prototype AOCS
Testing of the prototype AOCS on an ERC32 simulator and/or on an ERC32 board

The programme of work for phase II is subject to review on the basis of the results of phase I. A list of potential objectives for phase II have been identified and are being discussed with ESA.

Back to Top, Back to Aocs Framework Project Home

Application to Other Spacecraft Subsystems

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:

telemetry handling,
telecommand handling,
failure detection,
failure recovery,
sequential data processing,
reconfiguration management

Such functionalities are found in many (if not all) spacecraft subsystems. Since the framework is built as a collection of lower-level entities (the so-called framelets), it would be easy to port it to other subsystems. In fact, most of the AOCS framework could be easily adapted to a generic embedded control system.

Back to Top, Back to Aocs Framework Project Home

Related Projects

The design of the AOCS Framework is being used as a test case for a new framework design methodology that is being developed in a separate project (the Framework Methodology Project). The chief innovations introduced by the new framework design methodology and applied to the AOCS Framework Project are framelets and implementation cases.

Framelets are "small frameworks" that solve, as self-standing units, specific problems within the framework. They make no assumptions about application execution control and are designed to be composed with each other. A framework is obtained as a combination of framelets. Framelets simplify the development and extension of frameworks, and make their integration with other frameworks and with other software simpler.

Implementation cases are introduced as ways to continuously monitor the adequacy of an evolving framework design. They describe an aspect of the framework instantiation process by specifying how an architectural feature for an application can be implemented using the constructs offered by the framework. Implementation cases narrow the abstraction gap between frameworks and application by forcing designers to think about the reification of the abstractions they are creating while at the same time giving them the opportunity to test the adequacy of these abstractions. Implementation cases can also be used to specify a framework or as cookbook-style recipes to document its usage.

Click here for an overview of follow-up projects for the AOCS Framework Project.

Back to Top , Back to Aocs Framework Project Home

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