IMA for space – Status and Considerationsirt.enseeiht.fr/boniol/CiSEC/IMA_21_06_07/IMA dans...

L’IMA dans tous ces états - Toulouse 21 Juin 20071

IMA for space – Status and Considerations

Paul ARBERET – CNES DCT/SB/LV

2L’IMA dans tous ces états – Toulouse 21 Juin 2007

IMA for Space – Status and considerations

IntroductionStandardisations tentatives : platformsSatellites embedded Data-handling architectures : status and needsWhy not IMA for space ?Interesting/driving concepts for tomorrowConclusion


Introduction

Space industry industry/agency was (and is still) facing the sameproblems 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 keyissue (already identified ten years ago).


Standardisations tentatives : Platforms

Multi-missions platforms (mainly avionics + software) in order toisolate 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 ASTRIUMMYRIADE : 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 PFLessons 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 indepth.

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 criticality


Why not IMA for space : technical considerations

IMA/AFDX concept - centralisation / distribution of processing onone/several generic processors : Processors are not sufficiently powerful : today processors are

overloaded (up to 99%) - tomorrow GINA (and/or new DSP) wouldenable to concentrate SW ?

AFDX bus is not deterministic enough / compatible with real timeconstraints wrt OBDH/1553/Spacewire/Serial link – RS422

Criticality of on-board applications is always high (all is to beconsidered as critical as the electrical commands on an aircraft),

Mission specific functions / processing will remain : between LEO andGEO 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 onthe overall SW not fully mastered and assessed (design, validation…)


Why not IMA for space : organisation/processconsiderations

Mutation/rupture in organisations/responsibilities (introduce a strongcoupling 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, whenwould 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 wouldensure 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 forprograms management -> increasing role and influence.

■Satellite primes : only two (ASTRIUM, TAS) and competition is very hardbetween each other (similar as between AIRBUS and BOEING ?)

■Equipments manufacturers and software providers (several) : strongcompetition – however competition is biased by geo-return

All those actors have to reach a consensus (-very- long process) in amoving 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 ifTAS/ASTRIUM are ready to cooperate/invest together…) except ifthe 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 nofunding have been yet found (probably because the gains are notyet obviously demonstrated).


IMA for space or something else ?

■Process evolution is longer in space business than otherindustries (market size – involvement of public money – changereluctance – 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 ofefficiency step by step in order to gain the confidence of all theactors.■Investment shall be also step by step…

For all those reasons, IMA as such is probably not applicable andwill not be applied – however something else is emerging based onsimilar concepts but different technical rationale and associatedorganisation (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)



■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 standardisationprocess at European level : still computers and HW/SW interfacesremain too much specific…



■Standardisation of SW architecturesPre-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 andfunded by primes/agencies ?)

Promote independent development/reuse of Applications/services withguaranteed properties :• real time and memory• reduce the level of non-regression test effort…

ASSERT initiative/project (FP6) - first results are very fruitful (businessmodel still to be consolidated with all the actors)CNES is preparing to invest on a generic SW infrastructure forpayloads and instruments for french scientific labs



■Standardisation of SW and System processECSS similar to DO 178B and reflect the –space– European

agreement between all the actors on the SW development / validationprocess• 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 arepromoted 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 SWdevelopment process – various R&D activities are on-going to evaluateand adapt the process changes before baselining.



■Organisation and business modelSelection/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 ?

Those issues are all tough and open – and to be properly mastered(ESA started bilateral discussion with the various actors in thescope of ASSERT project)


Conclusions

■IMA as such is not directly appropriate : political, organisation,and technical –very– good reasons for that !■IMA technical background / concepts (and spirit) are relevant in

the space concepts and under evaluation…■Space agencies / industry / business are moving slowly by surely

to standardisation : from existing platforms to reusableinfrastructures and building blocks (HW + SW) + associatedprocess.

Still assessment studies (technical, process, organisation…) to beperformed in order to prepare what should be IMA for space…

IMA for space – Status and Considerationsirt.enseeiht.fr/boniol/CiSEC/IMA_21_06_07/IMA dans...

Documents

Transcript of IMA for space – Status and Considerationsirt.enseeiht.fr/boniol/CiSEC/IMA_21_06_07/IMA dans...