General Design Principles

The general design principles followed when designing the architecture for the AOCS Framework are discussed under the following headings:

Boundary Conditions

Broadly speaking, the ultimate objective of the AOCS Framework 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 SPARC 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.

Back to Top, Back to Aocs Framework Project Home

Object-Oriented Design

The term object-oriented design as used in the space sector often refers to systems that are more properly called object-based. Object-based methodologies (eg. HOOD) build a software system as a collection of hierarchical objects that encapsulate data while exposing operations to handle them. The design process they prescribe typically starts with an analysis of the problem domain to identify concrete classes and concrete objects. They often result in designs that are hierarchical in the sense that objects and classes are nested within each other.

The AOCS Framework Project adopts a truly object-oriented methodology which puts the emphasis not on objects but on abstract interfaces. With this approach, the design begins by identifying abstract functionalities that are then encapsulated in abstract interfaces. Objects (and the concrete classes from which they are instantiated) are derived at a later stage of the design process as instances of derived classes that implement one or more abstract interfaces. The resulting architecture is hierarchical in the sense that it is based on hierarchical class trees with abstract classes at the top of the tree and concrete classes at the bottom.

See this example for an illustration of the difference between object-based and object-oriented design.

Back to Top, Back to Aocs Framework Project Home

A Component-Based Framework

The AOCS Framework is intended to be component-based. In a first instance, the term component is used to designate an entity that satisfies the following requirements: The framework components are intended to be configured for use in a specific mission at run-time. In this phase, the objective is to construct the framework as a set of modules that can be re-used without changes to their source code. Behaviour adaptation is to be achieved entirely through inheritance and/or object composition.

In a second instance, the components may be implemented using a component standard (CORBA, JavaBeans or DCOM) to allow inter-operability across language, compiler, process, and processor barriers. The implementation choices currently being considered are described in the future development section.

The availability of software components in the AOCS domain would bring the development of the AOCS software in line with the development of hardware systems. In the long run, a commercial market for software components would emerge similar in character to the market for, say, AOCS sensors or AOCS actuators. The AOCS system, both its hardware and its software, would then be built by system designers assembling commercially available hardware and software components with standardized interfaces. These components could be deployed both in the AOCS computer and in a simulator for off-line software validation.

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

Use of Design Patterns

Design patterns are optimized solutions to recurring architectural problems in the framework domain (see E. Gamma et al. (1995), Design Patterns – Elements of Reusable Object Oriented Software). Since they encapsulate reusable architectural solutions, and since frameworks are intended as vehicles for architectural reuse, design patterns are regarded as the heart of a framework. Additionally, design patterns promote architectural uniformity by ensuring that similar problems in different parts of the same application receive similar solutions. This endows the application architecture with a single “look & feel” that makes using and expanding it considerably easier. Design uniformity is an important aspect of architectural reusability and a second important contribution of design patterns to frameworks.

Wherever possible, the AOCS Framework design makes use of standard design patterns (such as those from the well-known Gamma book). However, in many cases, the framework proposes design patterns that are tailored to the needs of the AOCS domain. Taken together, these design patterns provide the conceptual and architectural foundation of the AOCS framework.

Back to Top, Back to Aocs Framework Project Home

The Framework as a Domain-Specific OS Extension

One of the challenges of the AOCS project lay in the real-time and embedded characteristics of this type of applications which has seldom been the target of frameworks. In the initial phase of the project, however, it was realized that Real Time Operating Systems (RTOS) represent a highly successful example of software reuse frameworks for real-time systems. Because of their record in providing reusable software solutions, it was felt that they could serve as conceptual models for the AOCS framework. The AOCS framework was therefore deliberately developed as a domain-specific extension to the RTOS. As a result, the structure of an application instantiated from the AOCS framework is as shown in the figure:

As shown in the figure, a number of so-called functionality managers are now placed alongside the RTOS. LIke it they are application-independent and are intended to be reused as binary entities that are configured for use in a specific application at run-time. Each functionality manager is responsible for managing one particular functionality in the AOCS application. Thus, for instance, there is a telemetry manager, a telecommand manager, a controller manager, a failure detection manager , etc.

The functionality managers and their function in the AOCS Framework are discussed in greater detail in section 4 of this paper.

Back to Top, Back to Aocs Framework Project Home

Behaviour Adaptation Mechanisms

The derivation of an AOCS software from the AOCS Framework requires the adaptation of its behaviour to the specific needs of the particular AOCS software being derived (framework instantiation process). The framework uses two basic behaviour adaptation mechanisms: inheritance and object composition. The former mechanism is used for static behaviour adaptation, the latter for dynamic behaviour adaptation. In the present version of the framework, no effort is made toprivilege one over the other mechanism.

A more detailed discussion of the two adaptation mechanisms canbe found here.

Back to Top, Back to Aocs Framework Project Home

Delegation of Responsibility

If a certain task has to be performed by or upon an object, the responsibility for performing the task will be as far as possible delegated to the object itself. Thus, for example, rather than having a procedure that writes an object to telemetry, the object itself will be endowed with the ability to write itself to telemetry (ie. it will be given a method that, when called by an external telemetry manager, causes the object to write its state to the telemetry stream).

Delegation of responsibility to objects results in a “bottom heavy” implementation where many functionalities are implemented in the objects at the bottom of the object hierarchy. This approach ensures that the higher level objects that embody the AOCS structure are mission-independent and can be reused without changes.

Back to Top, Back to Aocs Framework Project Home

Design to Interfaces

The design of a framework is primarily the design of a set of interfaces that externally define the components of the software to be derived from the framework. Hence, wherever possible, the AOCS framework design is expressed in terms of abstract interfaces which make no assumptions about the way an interface is implemented. This means that to each functionality to be accomplished by an AOCS - telemetry management, telecommand management, failure detection, failure recovery, unit reconfiguration, unit management, etc. - one or more interfaces are associated that capture the fundamental operations associated to the functionality. Interaction between components is always performed through the interfaces, never through the concrete classes derived from them.

From an implementation point of view, and assuming a C++ implementation, an interface is a class with pure virtual methods.

Back to Top, Back to Aocs Framework Project Home

Use of Multiple Inheritance

The adoption of a truly object-oriented design technique (as opposed to merely object-based), implies a heavy use of multiple inheritance in the AOCS Framework design.

It is well known that multiple implementation inheritance presents semantic problems that advise against its use in critical applications and that its over-use can sometimes make component re-use difficult. The solution adopted in the AOCS Framework Project avoids these pitfalls by adopting a "safe" form of multiple inheritance based on the following rules:

This solution is borrowed from the Java language and it is both safe and well-tested. Its implementation in C++ is straightforward. Note that Ada95 does not directly support multiple inheritance and is therefore regarded as an unsuitable implementation vehicle for the AOCS framework.

Multiple inheritance in the AOCS Framework project is used to allow the same object to play different roles in different contexts. Click here for an illustration of this usage.

Back to Top, Back to Aocs Framework Project Home

External Interfaces

External interfaces – towards external devices and towards the underlying processor – are encapsulated in objects that, within the AOCS software, act as proxies for the external objects. This is an instance of the proxy design pattern from E. Gamma et al. (1995), Design Patterns – Elements of Reusable Object Oriented Software.

Back to Top, Back to Aocs Framework Project Home

Real-Time Constraints

AOCS systems must be demonstrably schedulable. An application is schedulable if it can meet all its deadlines under any operational conditions. The schedulability requirement derives from the hard real-time nature of the AOCS. Additionally, since AOCS systems are mission-critical, schedulability must be demonstrable in the sense that it must be possible to verify it statically by analysing the source code.

A necessary condition for the demonstrable schedulability of a software application is that the execution time of any of its code segments be statically predictable. This requirement has a repercussion at framework level insofar as some of the code in an AOCS application is inherited from the framework. The AOCS framework safeguards timing predictability primarily by avoiding constructs and operations that lead to non-predictable code. In practice, this led to the avoidance of exception handling and dynamic memory allocation.

The AOCS framework relies extensively on dynamic binding to model application adaptability. At first sight dynamic binding might seem to be incompatible with code execution predictability because of the impossibility of statically associating a definite piece of code to a particular method call. However, in embedded systems there is no dynamic class loading and hence the number of methods that might be called is finite (and often small). It is therefore always possible to determine worst-case execution times and use this estimate in the schedulability analysis.

The heavy reliance of the framework on design patterns poses a more serious problem since some design patterns have a recursive structure that makes static timing analysis impossible. In such cases, timing predictability can only be retained by adding meta-information to the source code that specifies the maximum depth of the recursion. In order to make it easy to provide this information, the framework documentation identifies all recursive design patterns that may be introduced in an AOCS application. Upper bounds on the depth of recursion can then be inferred from the design pattern semantics.

Execution time estimates are useful to verify schedulability only within the context of a specific scheduling policy. In order to preserve its generality, the AOCS framework makes the software architecture independent of the scheduling policy. It achieves this goal by confining scheduling assumptions to the application-specific components. The application-independent components are instead designed to provide entry points for an external scheduler and not to make any assumption about the timing pattern with which they are activated.

Back to Top, Back to Aocs Framework Project Home

Compatibility with HRT-HOOD

HRT-HOOD is a modification of the HOOD design methodology that ensures that a design is statically analysable for its timing properties.

HRT-HOOD was primarily conceived as a design tool to develop software architectures that are guaranteed to be statically analysable for their timing properties. As such, HRT-HOOD is not applicable to the AOCS Framework Project because the design methodology that underlies it is object-based rather than object-oriented and the AOCS Framework is developed as an object-oriented system.

Essentially, HRT-HOOD assumes a design process that starts with the identification of objects that are then progressively decomposed into hierarchies of simpler objects. The method imposes constraints on how the decomposition takes place (constraints on the include relationship) and on how the objects use each other's services (constraints on the use relationship). By contrast, the object-oriented design methodology used in the AOCS framework project starts from the identification of abstract functionalities (interfaces and abstract classes) and derives concrete objects only as the last step of the design process.

Moreover, HRT-HOOD is a design methodology to develop concrete applications whereas the AOCS Framework Project aims to develop a framework (TBL), namely an abstract architecture from which concrete applications can be derived.

For all the above reasons, the HRT-HOOD approach cannot be used to design the AOCS framework.

Both an object-based and an object-oriented design process result in a final software system that is made up of objects that expose certain operations. Given such a system, it is possible to ask whether its architecture is of a kind that would be generated by the HRT-HOOD design process. In order to assess whether this is the case, the following questions must be answered:

Used in this way, HRT-HOOD becomes an analysis tool to investigate whether the schedulability of a given software system can in principle be statically analysed.

Software systems for which the two above questions can be answered in the affirmative will be said to be HRT-HOOD compatible. Such systems look like they were designed with HRT-HOOD even if they were not actually designed using an HRT-HOOD methodology.

In the context of the AOCS Framework project, one can ask the following question: “are the concrete applications that can be potentially derived from the framework HRT-HOOD compatible?”. This is an interesting question to ask because an affirmative answer indicates that the framework generates applications whose schedulability is statically analysable. The AOCS Framework design ensures that this question can be answered in the affirmative and that AOCS applications derived from the framework are indeed HRT-HOOD compatible.

Back to Top, Back to Aocs Framework Project Home

Language Compatibility

The architectural design of the framework is language independent (it is mainly expressed in UML). The only language assumption made by the design is that the selected implementation language should be powerful enough to support full object-orientation.

An abstract architecture is the main output of the study. However, in order to demonstrate its effectiveness, a prototype framework is also being developed. This framework is being implemented in C++. C++ was chosen for reasons of practical convenience only. This choice is not intended to exclude implementations in other languages.

In particular, Ada is still the language of choice for ESA space applications and ensuring compatibility of the AOCS framework with Ada95 is therefore extremely desirable. The question of whether the AOCS framework could be implemented in Ada95 (the object-oriented version of the Ada language) was considered during the study. The answer hinges on whether the language can support the version of multiple inheritance used in the framework and required for a fully object-oriented architecture. Ada95 does not directly support multiple inheritance but it offers at least two mechanisms - mixin inheritance and multiple views - that allow the effect of multiple inheritance to be achieved (see this reference for a technical discussion).

The mixin inheritance mechanism is not adequate for the purposes of the AOCS framework (see the discussion of multiple inheritance in the Ada95 Rationale for a detailed presentation of these two mechanisms). The multiple view mechanism can instead in principle meet the requirements of the framework but only at the cost of a sharp increase in the total number of classes required by the framework and by introducing awkward code that, essentially, represents a manual implementation of constructs that in languages like C++ are automatically provided by the compiler.

Compatibility with Ada95 is thus technically guaranteed but is probably excluded in practice.

Back to Top, Back to Aocs Framework Project Home

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