Modeling Satellites Software
Architecture, a European Space Agency research initiative
Would you
develop a satellite application the same way you develop a
«classic» application ?
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:
·
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.
