IMA for space Status and Considerations Paul ARBERET CNES DCT/SB/LV L IMA dans tous ces états - Toulouse 21 Juin 2007 1
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 2
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). 3
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) 4
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 onboard 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 criticality 5
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 ) 6
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? 7
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) 8
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). 9
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). 10
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) 11
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 12
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 13
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 stateof-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. 14
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? Those issues are all tough and open and to be properly mastered (ESA started bilateral discussion with the various actors in the scope of ASSERT project) 15
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 reusable infrastructures and building blocks (HW + SW) + associated process. Still assessment studies (technical, process, organisation ) to be performed in order to prepare what should be IMA for space 16