IMA for space – Status and Considerations
IMA for Space – Status and considerations
Introduction
Standardisations tentatives : platforms
Satellites embedded Data-handling architectures : status and needs
Why not IMA for space ?
Interesting/driving concepts for tomorrow
Conclusion
Introduction
Space industry industry/agency was (and is still) facing the same
problems as the aeronautics/automotive :
Cost/efficiency optimisation,
Schedule reduction,
Increasing on-board complexity/autonomy,
Organisations are evolving / concentrating.
There is a need for changing the way (technical and organisational)
to design and develop satellites/systems
: standardisation is a key
issue (already identified ten years ago).
Standardisations tentatives : Platforms
Multi-missions platforms (mainly avionics + software) in order to
isolate standard housekeeping features (TM/TC, AOCS, power,
thermal…) from mission related :
PROTEUS : funded by CNES and contracted to TAS (5 missions :
JASON1 – SMOS – CALIPSO – JASON2 – XXX)
SPOT/PLEIADE : invested internal ASTRIUM
MYRIADE : funded and designed by CNES for scientific missions (up to
8 missions : DEMETER – PARASOL – TARANIS – PICARD…)
EUROSTAR 2000/3000 (ASTRIUM), AVIONICS 4000 (TAS), ALPHABUS :
telecom PF
Lessons learned :
Effective cost-reduction
The number of missions is still -very- limited for each platform
80% of mission-dependant cost (mainly on software and validation/verification effort)
Satellites data handling architectures
Decentralised/modular on-board architectures :
■The platform implements all generic services/features
■The mission specific features are isolated inside the instruments and the
various equipments (within dedicated processors)
■However the interfaces are not fully standardised (TM/TC as well as
on-board protocols) and the generic features/services are tailored/adapted in depth.
Key design drivers :
■Processors : limited resources
radiation constraints on processors => dedicated product lines (MA3-1750, ERC32, LEON3…)
Reduced/limited power (electrical) consumption
■Bus : strong needs of determinism / efficiency – low rates (constraints
coming from ground to space link)
■Software :
optimised and redesigned on a case by case hard real time
Why not IMA for space : technical considerations
IMA/AFDX concept - centralisation / distribution of processing on
one/several generic processors :
Processors are not sufficiently powerful : today processors are
overloaded (up to 99%) - tomorrow GINA (and/or new DSP) would enable to concentrate SW ?
AFDX bus is not deterministic enough / compatible with real time
constraints wrt OBDH/1553/Spacewire/Serial link – RS422
Criticality of on-board applications is always high (all is to be
considered as critical as the electrical commands on an aircraft),
Mission specific functions / processing will remain : between LEO and
GEO SL as similar as between a helicopter and a plane…
This would lead to increase the complexity of on-board lower level SW
(implementing in particular ARINC 653) => impact on the reliability on the overall SW not fully mastered and assessed (design, validation…)
Why not IMA for space : organisation/process
considerations
Mutation/rupture in organisations/responsibilities (introduce a strong coupling between the various actors) :
■Responsibilities of contractors at delivery/acceptance step : instead of
delivering a fully validated back box => delivery of HW + SW separately
■Validation means are to be considered as CFI (outside supplier’s
responsibility)
■System validation is moved from instrument/equipment integration to
system integration : how to manage responsibilities and schedule, when would guarantee period start…
■Furthermore SW integration (SW/SW and HW/SW) is somehow moved also
during system integration : lessons learnt from aeronautic ?
■Responsibility of the SW architecture (and some building blocks) is
moved outside the application SW supplier(s) : where and who would ensure the overall SW design authority ?
Why not IMA for space : actor and strategy issues
The landscape is very different from IMA (AIRBUS = one single prime) :
■Agencies : Two major actors + various national entities
ESA (tomorrow = EU) : funding of all major European space systems (launchers, satellites…) + technical centre
CNES : also –and still– funding national programs (military, civil observation, science) + historical investment and technical knowledge (e.g. Ariane, Spot, Telecom…)
Other national agencies : mainly funding / supported by ESA/CNES for programs management -> increasing role and influence.
■Satellite primes : only two (ASTRIUM, TAS) and competition is very hard
between each other (similar as between AIRBUS and BOEING ?)
■Equipments manufacturers and software providers (several) : strong
competition – however competition is biased by geo-return
All those actors have to reach a consensus (-very- long process) in a moving landscape (European restructuring is on-going)…
Why not IMA for space : ROI
Volume/number of missions + number of on-board computers/SW
(compared to aircrafts) is not of the same order of magnitude :
■
The investment / effort of this standardisation is estimated –very–
high (?) : probably up to the same level as the IMA for spacecraft.
■
The interest / gain for equipment/software manufacturers is not
obvious (business reduction – responsibility reduction)
■
For primes, the gain is not –fully– obvious due the high
investment level it means (and would have a sense only if
TAS/ASTRIUM are ready to cooperate/invest together…) except if
the investment is made at agencies level.
■
Agencies (ESA, CNES) have not yet decided/given a clear positive
signal to IMA : technical dossier have been initialised but no
funding have been yet found (probably because the gains are not
yet obviously demonstrated).
IMA for space or something else ?
■
Process evolution is longer in space business than other
industries (market size – involvement of public money – change
reluctance – political issues at European level…)
■
It should be probably continuous evolution rather than totally in
rupture (and not imposed) : it has to provide the evidence of
efficiency step by step in order to gain the confidence of all the
actors.
■
Investment shall be also step by step…
For all those reasons, IMA as such is probably not applicable and
will not be applied – however something else is emerging based on
similar concepts but different technical rationale and associated
organisation (and funding).
Interesting/driving concepts for tomorrow
■
Segregation partitioning / distribution concept (ARINC 653 – like ?)
is needed :
Payload/instrument design (especially with laboratories for scientific
missions) :
• Fully isolate applications (missions related data processing) from the middleware/HW/real-time constraints,
• Share the responsibility of the SW development between the various actors, • Develop/validate once the core/middleware SW,
• Save processor units/board whereas possible (one single processor for several instruments ?)
New GINA (multi-core processor) under development (availability
within 5 years) :
• will offer more resource on-board,
• would need to optimise the processor usage due to distribution capabilities.
Several R&D activities already started – under evaluation process
(ESA, CNES, industry auto-invested)
Interesting/driving concepts for tomorrow
■
Standardisation of interfaces in particular :
HW/SW interfaces : processors, IT, I/Os, lower level protocols… in
order to ensure portability,
TM/TC protocols :
• space to ground : PUS (ECSS) + CCSDS + OBCPs…
• on-board : 1553, OBDH, Spacewire… and higher level protocols e.g. SOIS (CCSDS)
• satellite to satellite for constellations : to be done…
SW/SW protocols (notion of SW bus) :
• already implemented by satellite primes for their own needs (platforms),
• to be rationalised/harmonised between primes => AGATA demonstator is pilot project
Progress significantly made in the interfaces standardisation
process at European level : still computers and HW/SW interfaces
remain too much specific…
Interesting/driving concepts for tomorrow
■
Standardisation of SW architectures
Pre-develop/validate generic services (building blocks) : e.g.
payload/instruments
• Offer/provide to the labs/SW suppliers a SW architecture + existing building blocks • Share with industry / user’s community (opensource ?) the pre-developed building
blocks : detailed organisation (design authority to be explicitly mandated and funded by primes/agencies ?)
Promote independent development/reuse of Applications/services with
guaranteed properties :
• real time and memory
• reduce the level of non-regression test effort…
ASSERT initiative/project (FP6) - first results are very fruitful (business model still to be consolidated with all the actors)
CNES is preparing to invest on a generic SW infrastructure for payloads and instruments for french scientific labs
Interesting/driving concepts for tomorrow
■
Standardisation of SW and System process
ECSS similar to DO 178B and reflect the –space– European
agreement between all the actors on the SW development / validation process
• E40 (software engineering) / Q80 (software quality assurance)
• Improvement always on-going (working groups) : E40B applicable, E40C under prepare…
• Handbooks are complementing the applicable list of documents, gathering state-of-the-art practices, tools, etc…
“V” traditional life cycle is no longer adequate :
• Reuse process, MDA, autocoding, proof-based design/code techniques are promoted in order to suit to the standardised architecture…
• Optimisation of the efficiency of the SW process to be made.
ECSS working groups are adapting/improving the standard SW
development process – various R&D activities are on-going to evaluate and adapt the process changes before baselining.
Interesting/driving concepts for tomorrow
■
Organisation and business model
Selection/funding (by whom) of one/several design authority ?
Open-source model (e.g TOPCASED, RTEMS, …) : what about
maintenance and design authority funding in such a scheme ?
Scilab model (association – industrial / agencies funding) ?
Certification-like scheme ?
