Content uploaded by Maxime Perrotin
Author content
All content in this area was uploaded by Maxime Perrotin on Oct 06, 2016
Content may be subject to copyright.
→ Taste: towards a space system
development framework
Maxime Perrotin
Jean-Loup Terraillon
Christophe Honvault
RSP/ESWeek
8th Oct. 2015
2
Agenda
•European Space Agency in a nutshell (intro)
•Challenges in spacecraft system design
•Model-based system and software engineering at ESA
•Application use case
•Conclusions
•Question and answers
3
The European Space Agency (1)
•Purpose of ESA: To provide for and promote, for exclusively peaceful
purposes, cooperation among European states in space research and
technology and their space applications – Article 2 of ESA Convention
•Over 50 years of experience
•22 member states
•Eight sites/facilities in Europe, about 2200 staff
•4.4 billion Euro budget (2015) – 85% spent on contracts with industry
•Over 80 satellites designed, tested and operated in flight
•Over 20 scientific satellites in operation
•Six types of launcher developed
•35000 jobs in Europe
4
The European Space Agency (2)
•ESA covers a wide range of applications
–Space science
–Human spaceflight
–Exploration
–Earth observation
–Launchers
–Navigation
–Telecommunications
–Technology
–Operations
5
The European Space Agency (3)
6
Satellite operations
7
PROBA
•Proba satellites are part of ESA’s In-Orbit
Technology Demonstration Programme
•New technology products need to be
demonstrated in orbit, particularly when
users require evidence of flight heritage or
when there is a risk associated with the use
of new technology
•Proba satellites are among the smallest
spacecrafts ever to be flown by ESA, but
they are making a big impact in the field
of space technology
•Proba-1 (2001-), Proba-2 (2009-), Proba-V
(2013-), Proba-3 (2018)
8
Space systems architecture
•SPARC processor (Leon)
•50 MHz, 1 core
•Bus: Spacewire, MIL-1553, RS422
•256 Mb SDRAM + Flash memory
•Many sensors, actuators
•RF link
9
On-board functions
mode management
navigation
drivers
communication
payload management
script engine
monitoring
housekeeping
power, thermal
reaction wheels, gps,
star trackers, mass memory…
real-time operating system: RTEMS, sometimes an Ada runtime kernel
Flight software
10
Software development processes
•ECSS: the European Cooperation for Space Standardization (www.ecss.nl)
•Engineering and Quality standards for all aspects of space systems
•Software standards:
–ECSS-E-ST-40C: Space Engineering - Software
–ECSS-Q-ST-80C: Space software Quality Assurance
•Milestone-based with detailed data packages to be produced by industry
–SRR : System Requirement Review
–PDR : Preliminary Design Review
–CDR : Critical Design Review
–QAR/FAR : Qualification and Flight Acceptance Review
11
In practice…
•Traditional software development is based on
•Lists of textual requirements
•Manual coding (in C or Ada)
•Testing
•It (sort-of) works for non-critical applications where cost of bugs is low:
“The next version will correct the bugs”
•In this approach the success depends more on the skills and experience of
a few individuals rather than on the application of an engineering
approach based on well established and repeatable processes
•But for the development of expensive and complex multi-domain systems
that may contain safety requirements and heterogeneous components,
the development approach has to be better.
12
Reformulating requirments
13
Satellite systems - challenges
•Developing distributed on-board software is very different from
developing desktop software:
–Limited resources (data storage and processor speed)
–Heterogeneity everywhere
–Communication with sensors, actuators, busses: low-level
programming requires uncommon skills
–Complex behaviour: it has to be correct and robust
–Deployment and testing on embedded devices
–Documentation has to please the customer!
•SAVOIR and TASTE are introduced as a set of tools and processes
to target this complexity and to ensure consistency during the
whole development lifecycle.
14
SAVOIR and TASTE
15
Improve the way we deliver Space Systems (cost & schedule) by
–Pre-developed Products / Building Blocks based on
•well defined Specification & Interfaces based on
–an agreed Reference Architecture
Motivation for the SAVOIR
initiative
16
Reference Architecture
Reference architecture
17
test
scripts
Interface and building blocks to deal
with heterogeneity
How to put everything
together ?
SDL
MSC
Python,
Tcl
C
Ada
VHDL
Simulink,
Scade
VDM
SMP2
state
machines
control
laws
algorithms
FPGA
code
drivers, user
code
system
simulation
applicative
code
execution
trace
18
how to put everything together?
•Manually?
–Requires a lot of hacking
–Difficult maintenance in case of interface changes
–That is the most common way of doing
•Using a commercial modelling tool?
–No support for heterogeneous models
–No support for sensor/actuators interfacing
–Maintenance issues (vendor lock-in)
•Using TASTE
–ESA builds TASTE as an exploration platform putting together the
state-of-the-art in various software technologies
–Based on free, open-source software
19
What are the benefits?
•Modelling languages have to be used with a goal in mind:
–Capture the system architecture to analyse the system feasibility
–Capture data types to ensure consistency everywhere in the system
–Capture the software expected behaviour (state machines, algorithms)
and let tools explore this behaviour to verify or discover some
properties of the system
–Automate the production of code and documentation
•Unfortunately modelling is often misused and results in more troubles
than visible benefits
•Benefits come at a price:
–a solid process is just as important as good tools
–Training counts
20
How do the tools look like?
•Graphical approach to unambiguously capture the system
architecture and its real-time properties
21
State machines with SDL
22
TASTE Software factory - philosophy
•Use existing technologies – glue them together when semantics are
compatible
•Don’t reinvent the wheel, software modelling is not new: learn, use
and build on top of languages that are mature and widely used in
other industries (AADL, ASN.1, SDL, VDM)
•Don’t try to code drivers in UML!
•Automate tedious tasks
•Explore unusual or new technology
•Develop tools that make the life of developers easier – keep the
right balance between abstraction and concrete implementation
•Target software and systems, not models. Models are just a mean!
23
Use cases for a software factory
•Create software – from rapid prototyping to complete application
•Discover and develop new technology
•Support operational projects
–Understand the scope of software, the actors, the design
–Detect issues, ambiguities
–Run simulations, analyse behaviour
•Improve the quality of documentation
24
Example of ambiguous requirements
(from a real project)
•REQ_1 - If during Initialisation it is sensed that both SCs are connected
then the Stack mode shall be entered. In this mode the communication
with Ground shall be established, the SC GNC software of Satellite 1 shall
be activated with GNC SW of Satellite 2 is inactive, and most of the units
shall be commissioned.
•REQ_2 - When separation of SCs is detected (after Initialisation or in
Stack mode), then the Manual mode shall be entered. In this mode, SC
GNC of both SCs shall be activated and a default configuration and
attitude shall be set. In this mode any operation can be commanded
from the Ground segment. Those units not commissioned in Stack will be
done in Manual mode
25
Deciphering…using tools from the
factory
•Build a model, step by step – 50 % of the issues are found that way
Shouln't we
Establish
Communication
In BOTH cases ?
26
Return of experience: tools help finding
many classes of errors in specifications
•Ambiguities with data – often no shared data dictionnary.
Inconsistencies with namings, semantics, scope...
•Missing interface information (behaviour, off-nominal handling,
parameter constraints...)
•Sequencing (dynamic) issues – what is done in what order, etc
27
Software factories must have strong
basis
•TASTE relies on formal languages :
–ASN.1 and AADL to capture the software architecture and data
–SDL, VDM, Simulink, SCADE, C, Ada, VHDL, … to capture the
software behaviour
–MSC and Python to test
•Combine graphical AND textual notations
– If anything goes wrong, human can fix textual syntax
–Diagrams for easier understanding
–But some information is textual by nature
•Avoid languages with weak semantics or syntax
28
And make developers and testers’ life
easier
•Generate additional code to help users test their system (real-time
monitoring and interaction with the binary)
29
example: ESA robotic lab experiments
Communication &
State Management
(SDL/RTDS)
Control law
(Simulink)
Exoskeleton
(Sensors) Robotic arm
(Actuators)
hardware
interface (1) hardware
interface (2)
software
interface
30
interface issues
Software
Sensors
hardware
interface (1)
•Issues to address:
–Specification of the interface
(logical message description)
–Message physical
representation (binary stream)
->imposed by the hardware.
Conversion to a software data
structure
31
interface issues (2)
•Issues to address:
1) Specification of the interface
(logical message description)
2) Conversion at model level (keep
the same semantics in both
RTDS and Simulink)
3) Conversion at code level: map
each field of the interface from
one generated piece of code to
the other
RTDS
generated code
Simulink
generated code
software
interface
32
ASN.1 to describe interfaces
•A simple notation to describe software and hardware interfaces
•Our tools generate code for embedded systems (no malloc, no
system call, support for C and [Spark] Ada)
+
33
Mix languages to get the best of all worlds –
no “unified language” to rule them all!
•The robotic case study mixes C (drivers), SDL (RTDS – system overal
orchestration and logic) and Simulink (control laws)
If we replace the Simulink block
with a VHDL component, the
rest of the system remains
unchanged from the user point
of view.
34
Conclusions and future
•TASTE, SAVOIR, OSRA, SCM, COMPASS… are the names of ESA
projects that address the area of software/system development
•These projects are managed consistently, with a clear, long-term
vision
•Many tools are already available and open-source
•We are still addressing niche markets and there are still very few
users
•In the future, we want to develop a community around these
technologies
35
For more information:
http://taste.tuxfamily.org
