ESA Case-Study

Modeling Satellites Software Architecture, a European Space Agency research initiative

Would you develop a satellite application the same way you develop a «classic» application ?

Of course not!

When developing an application embedded in a satellite, a software engineer has to deal with many additional constraints:

1. The software platform is constrained by so many factors (energy consumption, temperature, scarce computational power and memory size, etc) that general purpose methodologies are not always applicable.

2. Computation time and duration must be highly predictable in order to satisfy the complex orchestration of actions performed by the satellite.

3. As failures may lead to loss of mission, catastrophic damages or loss of lives, the quality of the software drives the development process

In order to support these constraints, the European Space Agency (ESA) has initiated an investigation for the realization of  a software reference architecture (SRA) for on-board software. Based on solid scientific foundations and industrial feedback, the SRA aims at providing a common framework which can be reused for multiple missions in the space domain.

Marco Panunzio at the University of Padova (Italy) contributed to the investigation on the SRA during is PhD and later his post-doc. In his work, he defined the key principles, formulated a component model compliant with these principles, and developed a graphical modeling tool based on Eclipse and Obeo Designer for the development of on-board software compliant with the SRA.

The results were periodically submitted to a working group comprising space stakeholders, for assessment and refinement.

The cornerstone principle of the SRA is separation of concerns, which is used in order to separate different aspects of software design (functional and non-functional concerns, actor's area of expertise, etc) and address them with the best-fit formalisms, tools and verification techniques. Other key principles of SRA are composability, compositionality, property preservation and composition with guarantees.

These principles have driven Marco Panunzio to the definition of a component model which supports the concept of Design Views in order to decompose the global architecture of the system into more detailled constituents. Each Design View represents self-contained concerns relevant to a given stakeholder. A Design View can define its own rules (visualization and modification rights, graphical representation, constraints, verification, etc).

At the present state of the investigation, the SRA comprises six Design Views:

·      Data

·      Component

·      Behavioural

·      Hardware/Deployment

·      Non Functional

·      Implementation/Analysis

It is also complemented by domain-specific views. For example, a view has been implemented for the PUS (Packet Utilization Standard), to define the use of services which involve the transfer of telemetry and telecommand data between the ground segment and on-board applications.

 SRA Design Views

To create a satellite application according to this component model, a tool has been developed in Eclipse. It supports the seven aforementioned views via 19 kinds of diagrams and 8 kinds of tables. These views are completed by validation rules and specific actions (for intensive computations).

To develop these views, Marco Panunzio selected EMF (Eclipse Modeling Framework) and Obeo Designer. The resulting editor was later adopted and refined in subsequent ESA-funded studies.

Two strategies have been considered:

·      UML with a specific profile

·      a DSL (Domain Specific Model)

Because of the gap between the concepts of the SRA component model and those defined by UML, using UML in this context would have introduced unnecessary complexity. That's the reason why an Ecore metamodel (called SCM) implementing the component model concepts was developed. With this approach, the tool natively supports the component model of the SRA.

Then, to implement the diagrams which allow the user to edit and visualize the components, Obeo Designer was chosen.

Another alternative would have been to directly use GMF. But implementing 19 specific diagrams would have consumed most of the effort to the detriment of realizing and perfectioning the approach.

On the contrary, with Obeo Designer, the design views have been implemented much faster with a better support for extensibility and incremental adaptations. Most of all, it permitted fast iterations with stakeholders in the prototypal phase for delicate points of the methodology.

Below, you can see some examples of the diagrams created with Obeo Designer.

• Hardware diagram: declaration of the processing units, sensors, actuators, devices and the interconnections between them

Hardware diagram

Processor board diagram: declaration of the internals of a processor board in terms of processors, processor cores, cache and memory banks.

Processor board diagram

PUS component instance diagram: monitoring and reporting of on-board parameters, commanding of on-board operations from the ground segment, etc…

PUS component instance diagram

This initiative is a concrete contribution to the development of an on-board software reference architecture for future satellite systems.

Relying on a complete component model and an associated graphical editor, SRA is currently used by several ESA-funded studies which are consolidating and validating the approach and the tools.

This post is based on Marco Panunzio's document "Definition and realization of an on-board software reference architecture" available on www.obeonetwork.com (registration required).