Relationship to Autocode Approach

Framework technology is used in this project to improve the reusability of the AOCS software. Automatic code generation (or autocoding) is another reuse technique that is increasingly proposed for embedded control systems like the AOCS. In this domain, autocoding is usually done with tools like MatrixX/Xmath or Matlab.

The two techniques - autocoding and frameworks - differ on at least three counts:

In the AOCS Framework Project the two techniques are regarded as having complementary strengths and weaknesses. One of the project objectives is to ensure that the AOCS framework can be integrated with automatically generated code. For this purpose, the framework offers wrapper components where autocode routines (possibly representing complex hierarchies of nested blocks and super-blocks) can be plugged in. This approach is illustrated in the figure:
 

The yellow area represents the architectural backbone of the application. This remains fixed in one application domain and is provided by the framework. The red blocks are application-specific. They override or otherwise cooperate with framework objects to customize its behaviour. In an AOCS context, the red blocks could be objects implementing the control law or state estimation algorithms for a particular mission. These are precisely the kind of objects that can be efficiently generated by autocode tools. The synthesis proposed by the AOCS Framework project hence is based on a system where the architectural skeleton of the AOCS software is provided by the framework while the mission specific parts are provided by the autocode tools of dynamical simulators like Xmath or MatLab.

Finally, note that frameworks, too, are often supplemented with automatic code generators. Combining them with the autocode generators of dynamical simulation tools would increase the share of AOCS software that is generated without manual intervention.
The vision driving this project is that of a system where framework and dynamics autocode facilities are integrated creating an environment where AOCS engineers can develop their software by writing only a minimal amount of code.

Back to Top, Back to Aocs Framework Project Home

Architectural Design

An autocode tool does not by itself facilitate the design of the software architecture. Given the architecture, the tool makes it easy to generate the software but the design of the architecture still has to be done manually by the user on an ad hoc basis. This is a serious drawback because the architectural design is by far the hardest part in the development process and one whose complexity will grow as the complexity of the underlying system grows.

By contrast, use of a framework relieves developers of the need to define the architecture of their software because the architecture would be built into the framework (indeed, the framework is the architecture).

Back to Top, Back to Aocs Framework Project Home

Generality

Autocode tools are more general than frameworks. They are targeted at a very wide range of users (eg. Xmath is targeted at dynamic system modelling, not just at AOCS modelling). Frameworks are instead aimed at rather narrow application domains. The framework developed in this project for instance is specifically targeted at AOCS applications.

Frameworks therefore suffer from having a restricted field of application but benefit from being endowed with abstractions that are tailored to this application domain. The availability of higher-level abstractions makes the users code simpler and more readable, and hence more re-usable and easier to maintain.

Consider for instance the case of AOCS software development. A generic autocode tool is unlikely to have an abstraction for ‘reaction wheel’ or for 'telecommand' because such an object is not required in the vast majority of dynamical system applications. The object must therefore be built from simpler entities for each new AOCS application. An AOCS framework would instead be likely to predefine both types of abstraction offering powerful constructs to manipulate them. This results in greater ease of use (and reuse) and in more readable code.

The generality of autocode tools also implies that they seldom can generate more than a fraction of the total code required for the AOCS: it would be difficult to find a tool that offers higher-level abstractions covering such diverse functionalities as control algorithm implementation, telemetry handling, or failure recovery. An AOCS-specific framework would instead cover all the AOCS functionalities and would thus assist the generation of all AOCS code.

Back to Top, Back to Aocs Framework Project Home

Simulation

Autocode tools (notably Xmath and Matlab) are usually built on top of environments that were intended as simulation and algorithm design environments, not as design environments for the architecture of complex systems. The facilities they provide are correspondingly optimized for the former tasks and make them awkward to use as architectural design tools. One important consequence is that code or model reuse across projects is very difficult: understanding a complex Xmath or Matlab model can be as difficult as understanding a complex piece of code. An AOCS framework, on the other hand, is specifically designed to be portable across projects and to have a structure that facilitates maintainability, re-use and understandability. Another consequence is the lack of support in autocode tools for complex data structures which often makes architectural design unnecessarily complex and error prone.

The origin of autocode environments as simulation tools is also their greatest strength. An autocode system provides a seamless integration of validation and development facilities. Although a framework that is based on components can also be oriented towards integrating development and testing environment, it is clear that at present a framework solution is in this respect definitely inferior to an autocode solution.

Back to Top, Back to Aocs Framework Project Home

Last updated on Jun. 24-th 2002 by Alessandro Pasetti