IMA-SP D08-11 - Process and role definition - 1.3

IMA-SP Process, Roles, and Tools

IMA-SP Integrated Modular Avionics for Space

(Contract ESTEC 4000100764)

Report D08-11

IMA development process, roles and tools

Reference: IMA-SP/D08 Issue: 1.3 Date: 15/04/2011

IMA-SP Process, Roles and Tools

Page intentionally left blank



Ref: IMA-SP/D08 Issue: 1.3 Date: 15/04/2011 3 of 86

Abstract:

Written by:

Name Company Signature Internal reference

Régis de Ferluc THALES ALENIA SPACE

Verified by:

Name Company Signature

IMA-SP (Integrated Modular Avionics for Space) is an ESA project (Contract ESTEC 4000100764) conducted by a consortium led by Astrium with Thalès Alenia Space, GMV-Skysoft, GTD, SciSys, Spacebel, Sysgo, UPV. For more information please contact:

James Windsor [email protected] ESTEC – Keplerlaan 1. PO Box 299 2200 AG Noordwijk ZH – The Netherlands Tel: +31 (0) 71 565 5037 – Fax: +31 (0) 71 565 5420

Luc Planche [email protected] ASTRIUM SAS – 31, avenue des cosmonautes F-31 402 Toulouse Cedex 4, France Tel: +33 (0)5 62 19 51 25 – Fax: +33 (0)5 62 19 71 58

Tobias Schoofs [email protected] GMV-SKYSOFT – Torre F. de Magalhães, Av. D. João II Lote 1.17.02, 7º Andar 1998 - 025 Lisboa Portugal Tel. +351 21 382 93 66 – Fax +351 21 386 64 93

Joaquim Sanmarti [email protected] GTD SISTEMAS DE INFORMACIÓN – Pg. Garcia Fària, 17 E-08005 Barcelona, Spain Tel.: +34 934 939 300 – Fax: +34 934 939 302

Peter Mendham [email protected] SciSys (Space and Defence) Ltd – Clothier Road Bristol, BS4 5SS, UK Tel: +44 (0)117 971 7251 – Fax: +44 (0)117 971 1125

Fernand Quartier [email protected] Spacebel – I. Vandammestraat, 7 B-1560 Hoeilaart, Belgium Tel. +32.2.658.20.11 – Fax. +32.2.658.20.90

Jose Almeida [email protected] SYSGO AG – Am Pfaffenstein 14 D-55270 Klein-Winternheim – GERMANY Tel: +49 6136 99480 – Fax: +49 6136 994810

Gérald Garcia [email protected] THALES ALENIA SPACE France – 26 avenue J-F. Champollion 31100 TOULOUSE, France Tel +33 (0)4 92 92 64 17 – Fax +33 (0)4 92 92 62 80

Dr. Alfons Crespo Lorente [email protected] UNIVERSIDAD POLITÉCNICA DE VALENCIA, Instituto ai2 de la UPV Camino de Vera, s/n – 46022 Valencia, Spain Tel: 96 387 75 76 – Fax: 96 387 75 79

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


Revision History

Version Date Paragraphs modified

Comments

0.1 2011-02-23 ALL First draft

1.0 2011-03-01 ALL First release

1.1 2011-04-04

Section 4.5

Section 5.3

Section 7

Draft

1.2 2011-04-07 Section 7 Internal draft

1.3 2011-04-15

Section 4.5.2

Section 5.2.1

Section 7.3.2

Section 8.2

Second draft before version 2.0

2.0 Second release

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Table of Contents

1 Introduction ................................................................................................................... 1114 1.1 Objective and Scope..................................................................................................... 1114 1.2 Executive Summary ..................................................................................................... 1114

2 Applicable and Reference documents............................................................................ 1215 2.1 Applicable Documents................................................................................................. 1215 2.2 Reference Documents.................................................................................................. 1215

3 Terms, Definitions and Abbreviated Terms................................................................... 1417 3.1 Definition of Terms...................................................................................................... 1417 3.2 Acronyms and Abbreviations....................................................................................... 1417 3.3 Methodology ................................................................................................................ 1417

4 Analysis of IMA in aeronautical domain........................................................................1518 4.1 Why IMA?....................................................................................................................1518 4.2 General principle .........................................................................................................1518 4.3 Development process in aeronautic ............................................................................1619 4.3.1 An IMA project example: Airbus A380 ................................................................1619 4.3.1.1 Step 1.1 - module specification....................................................................... 1720 4.3.1.2 Step 1.2 - system specification ....................................................................... 1720 4.3.1.3 Step 2.1 - system development....................................................................... 1720 4.3.1.4 Step 2.2 - system partial integration and qualification ................................. 1720 4.3.1.5 Step 2.3 - System configuration......................................................................1821 4.3.1.6 Step 3 - System integration..............................................................................1821

4.3.2 Roles and responsibilities definition. ...................................................................1821 4.3.3 Process description.............................................................................................. 1922 4.3.4 Process’ activities in detail................................................................................... 2225 4.3.5 Flexibility .............................................................................................................2629 4.3.6 Conclusion ...........................................................................................................2629

4.4 Critical review of the aeronautical process.................................................................2629 4.4.1 Need for a model of the overall system ...............................................................2629 4.4.2 Need for early system simulation ........................................................................2629 4.4.3 Need for more standardization............................................................................ 2730 4.4.4 Need for Contract based interactions..................................................................2730 4.4.5 Need to improve toolset capabilities ................................................................... 2730

4.5 Lessons learnt from the automotive domain.............................................................. 2730 4.5.1 AUTOSAR overview............................................................................................. 2730 4.5.2 Critical review of the AUTOSAR process............................................................. 2831

5 Applicability of IMA paradigm to the space domain ....................................................3033 5.1 Comparison between aeronautical and space domains..............................................3033 5.2 Adapting IMA paradigm to Space Domain.................................................................3538 5.2.1 Adapting IMA-SP product perspective................................................................3538 5.2.2 Adapting IMA-SP roles definition ....................................................................... 3841 5.2.3 Adapting IMA global approach from aeronautic domain to space one...............4043 5.2.4 Impacts of a component oriented process..........................................................4245

5.3 TSP versus Component Based System Engineering � partition allocation trade-off. 4447

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


5.4 Standards for the IMA-SP process .............................................................................4649 5.5 Conclusion ..................................................................................................................4649

6 Changes needed in Space domain to accommodate the IMA-SP paradigm................. 4750 6.1 Evolution of development process : from today’s State-of-the-Art to targeted

IMA-SP process .......................................................................................................... 4750 6.1.1 Today’s approach................................................................................................. 4750 6.1.2 Introducing TSP................................................................................................... 4851 6.1.3 Standardization and Integrated Modular Avionics. ............................................4952 6.1.4 Component based engineering. ........................................................................... 5053 6.1.5 IMA-SP study assessment ....................................................................................5154

6.2 Assessment of IMA-SP process against ECSS-E-ST-40 ............................................. 5255 6.3 Assessment of IMA-SP process against ECSS-M-ST-10............................................. 5558

7 IMA-SP Process detailed description............................................................................ 5861 7.1 Actors and roles .......................................................................................................... 5861 7.2 Interfaces between the various roles .......................................................................... 5861 7.3 Reuse process..............................................................................................................6063 7.3.1 Development of products to be reused................................................................6063 7.3.2 Reuse of existing products...................................................................................6063 7.3.2.1 Re-use of an application .................................................................................6063 7.3.2.2 Re-use of a partition (or a set of partitions) ...................................................6063 7.3.2.3 Re-use of IMA-SP platform ............................................................................ 6164 7.3.2.4 Re-use of components..................................................................................... 6164

7.3.3 Constraints........................................................................................................... 6164 7.4 Acceptance process ..................................................................................................... 6164 7.5 Tools description ........................................................................................................6366 7.5.1 Partitioning / Resource allocation/ configuration tool.......................................6366 7.5.2 System feasibility verification tool ......................................................................6366 7.5.3 Software image configuration tool ......................................................................6366 7.5.4 Cross development tools......................................................................................6366

7.6 Overall process............................................................................................................ 6467 7.7 Description of activities ..............................................................................................6568 7.7.1 Produce system specification ..............................................................................6568 7.7.2 Analysis and evaluation of partition reuse ..........................................................6568 7.7.3 Analysis and evaluation of platform reuse. .........................................................6669 7.7.4 Specify system functional requirements ............................................................. 6770 7.7.5 Specify system non-functional requirements...................................................... 6871 7.7.6 Requirements Allocation on logical entities........................................................ 6871 7.7.6.1 Description of the activity............................................................................... 6871 7.7.6.2 Description of the outputs .............................................................................. 6972

7.7.7 Analysis and evaluation of component reuse ...................................................... 6972 7.7.8 Hardware/Software Trade-off ............................................................................. 7073 7.7.9 Components specification ................................................................................... 7073 7.7.10 Partitioning and Resource Allocation.................................................................. 7073 7.7.10.1 Description of the activity................................................................................7174 7.7.10.2 Description of the outputs ...............................................................................7174

7.7.11 Assess system feasibility .......................................................................................7275 7.7.11.1 Description of the activity............................................................................... 7275

IMA-SP/D08 issue 1.3 15/04/2011 of 86


7.7.11.2 Description of the outputs .............................................................................. 7376 7.7.12 Procurement ........................................................................................................ 7376 7.7.13 Components development....................................................................................7477 7.7.14 Toolset development.............................................................................................7477 7.7.15 IMA-SP platform simulator development........................................................... 7578 7.7.16 IMA-SP Platform Integration.............................................................................. 7578 7.7.17 Platform Acceptance............................................................................................ 7578 7.7.18 Unitary Partition validation ................................................................................ 7679 7.7.19 System feasibility verification.............................................................................. 7780 7.7.20 Partition Qualification......................................................................................... 7881 7.7.21 System integration............................................................................................... 7881 7.7.22 System Acceptance .............................................................................................. 7982 7.7.23 System Integration in Spacecraft ........................................................................ 7982

8 IMA-SP Process Assessment.........................................................................................8083 8.1 Avionics Interfaces Standardisation Process (SAVOIR-FAIRE)................................8083 8.1.1 data types............................................................................................................. 8184 8.1.2 event types ........................................................................................................... 8184 8.1.3 Interfaces ............................................................................................................. 8184 8.1.4 component types.................................................................................................. 8184 8.1.5 component implementation ................................................................................ 8184 8.1.6 component instances ........................................................................................... 8184 8.1.7 component bindings definition ........................................................................... 8184 8.1.8 physical architecture definition........................................................................... 8184 8.1.9 component instances allocation ..........................................................................8285 8.1.10 containers creation ..............................................................................................8285 8.1.11 connectors creation .............................................................................................8285 8.1.12 Conclusion ...........................................................................................................8285

8.2 Tailoring IMA-SP process for study purpose. ............................................................8386 8.2.1 Role repartition for Use-Cases : ..........................................................................8487 8.2.1.1 IMA-SP platform development.......................................................................8487 8.2.1.2 IMA-SP System development .........................................................................8487

8.3 Impact of using the IMA-SP development process ....................................................8588

9 Conclusion.....................................................................................................................8689

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


LIST OF TABLES

Table 1 descritption of SPEM symboles .................................................................................. 14 Table 2 abbreviations for IMA-SP roles ..................................................................................20 Table 3 : detailed IMA development process .......................................................................... 23 Table 4: IMA-SP development process benefits from AUTOSAR ........................................... 29 Table 5 : comparison between space and aeronautical domains..............................................31 Table 6 : IMA-SP terminology ................................................................................................. 37 Table 7 : Roles and responsibilities repartition ...................................................................... 39 Table 8 : criterion for partitioning activity .............................................................................. 45 Table 9: Impact of IMA-SP process on ECSS-E-ST-40C ......................................................... 52 Table 10: Impact of IMA-SP process on ECSS-E-ST-10C........................................................ 55 Table 11 : contracts between all actors ..................................................................................... 59 Table 12 : Industrial organization for IMA-SP platforms development ..................................84 Table 13: Industrial organization for IMA-SP Systems development .....................................84

LIST OF FIGURES

Figure 1: example of IMA architecture in aeronautics.......................................................... 1516 Figure 2: the "Open IMA" Network on the A380.................................................................. 1617 Figure 3: development process for IMA in Aeronautics ...................................................... 2021 Figure 4: AUTOSAR approach (from www.autosar.org) .....................................................2829 Figure 5: representation of an IMA system......................................................................... 3536 Figure 6: IMA-SP Platform in global System Organization................................................. 3637 Figure 7: link between applications and partitions.............................................................. 3738 Figure 8 : vertical approach and horizontal approach in aeronautic IMA systems.............4243 Figure 9: association between a component oriented process and IMA-SP........................4344 Figure 10: IMA-SP process is in between TSP and CBSE....................................................4445 Figure 11: today's system organization.................................................................................4748 Figure 12: Today's System global view.................................................................................4849 Figure 13: TSP architecture in Space context.......................................................................4950 Figure 14: TSP system global view .......................................................................................4950 Figure 15: IMA-SP architecture............................................................................................ 5051 Figure 16: IMA-SP system global view................................................................................. 5051 Figure 17: Component based Engineering : Platform and components ...............................5152 Figure 18: component based engineering : system global view............................................5152 Figure 19: Roles, responsibilities, and interfaces in IMA process ....................................... 5859 Figure 20 : Overall sequencing of process activities ............................................................6465 Figure 21 System specification.............................................................................................6566 Figure 22 partition reuse analysis and evaluation............................................................... 6667 Figure 23: Platform reuse analysis and evaluation..............................................................6768 Figure 24: System functional Requirements specification ..................................................6768 Figure 25 System non-functional requirements ..................................................................6869 Figure 26 requirements allocation on logical entities..........................................................6869 Figure 27 Reuse analysis and evaluation .............................................................................6970

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 28: HW/SW trade-off ................................................................................................7071 Figure 29 Components specification.....................................................................................7071 Figure 30: Partitioning and resource allocation activity ......................................................7172 Figure 31 system feasibility assessment............................................................................... 7374 Figure 32: Procurement activity .......................................................................................... 7475 Figure 33: Components development.................................................................................. 7475 Figure 34: toolset development activity............................................................................... 7576 Figure 35: platform simulator development activity ........................................................... 7576 Figure 36: Platform Integration........................................................................................... 7576 Figure 37: Platform acceptance activity................................................................................7677 Figure 38: unitary partition validation ................................................................................ 7778 Figure 39: System feasibility verification............................................................................. 7879 Figure 40: Partition qualification ........................................................................................ 7879 Figure 41: System integration activity..................................................................................7980 Figure 42: system acceptance ..............................................................................................7980 Figure 43: System Integration in Spacecraft........................................................................7980 Figure 44: a typical Component...........................................................................................8081 Figure 45: component bindings ........................................................................................... 8182 Figure 46 : Component and its container ............................................................................8283 Figure 47 Component implementation, containers, and connectors ..................................8283 Figure 48 IMA-SP tailored Process for Use cases................................................................8384

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


Page intentionally left blank

IMA-SP/D08 issue 1.3 15/04/2011 of 86


1 INTRODUCTION

1.1 Objective and Scope

This document is the deliverable number D08-11 of the ESA study “IMA for space” (contract 4000100764). This document presents the work performed by the work package 1.2.

This document aims to define the IMA-SP process, related roles, and related toolset:

It contains an analysis of the aeronautical IMA and some feedback from this domain.

It aims to identify and specify of the changes needed in the system-software engineering and hardware/software lifecycles to accommodate the IMA-SP concept and to support the incremental validation strategy for both software and hardware.

It provides identification of the re-qualification strategy for re-using software and produce a set of guidelines for which parts of the re-used software have to be re-qualified.

It defines the roles and process to be followed for implementation of the IMA-SP concept.

It includes identification and definition of tools that can improve the efficiency of the IMA-SP process and support the System Architect.

A draft version of this document is provided at SRR and final version at PDR.

1.2 Executive Summary

The first section presents the aeronautical IMA product and process, relying on the AIRBUS A380 example. This process is analyzed and the limits of the current IMA paradigm are listed. The first section also provides some background of the AUTOSAR program in automotive domain, in order to identify some aspects that can be useful for the study.

The next section aims to analyze the applicability of the IMA paradigm to the space domain. In this section, the adaptation of IMA concepts is covered, such as the product perspective, the role definition, the general approach, and the issue of standardization.

Another section identifies the changes needed in space domain – product lifecycles and software engineering – to be able to apply IMA paradigm.

The next section describes in details the adapted IMA process for space domain.

Finally, the last section of this document assesses the new IMA-SP process.

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


2 APPLICABLE AND REFERENCE DOCUMENTS

2.1 Applicable Documents

Reference Description

SOW Statement of Work, IMA for Space TEC-SWS/09-281/SOW, issue 1.4 dated 23-10-2009

PROPOSAL IMA for Space - Study proposal

2.2 Reference Documents

Reference Description

[D01] IMA-SP User needs

[RD-11] ARINC 651-1 Design Guidance for Integrated Modular Avionics

[RD-09] ARINC 653P1-2 Avionics Application Software Standard Interface, Part1, Required services

[RD-10] ARINC 653P2 Avionics Application Software Standard Interface, Part2, Extended services

[RD-01] D0-297 document

[RD-02] Final Report for Clarification of DO-178B “Software considerations in Airborne Systems and Equipment Certification”

[RD-03] Partitioning in Avionics Architectures: Requirements, Mechanisms and Assurance

[RD-04] Distributes Secure Systems: Then and now. 25th anniversary republication and retrospective of ‘A distributed Secure System’

[RD-05] Modular Verification: Testing a subset of Integrated Modular Avionics in Isolation

[RD-06] Transition from federated Avionics Architecture to Integrated Modular Avionics

[RD-07] Managing the Allocation of Shared Intersystem Resources

[RD-08] Integrated Modular Avionics: A New Role Emerges

[RD-12] Study of I/O Time and Space Partitioned Systems.

NLR-CR-2008-531, available at:

ftp://ftp.estec.esa.int/pub/tec-sws/IMA_for_Space/reference_docs/NLR/NLR-cr-2008-531-pt-1.pdf

SAVOIR-FAIRE

SAVOIR-FAIRE - On-board software reference architecture

issue 1 revision 0 - 10. June 2010

TEC-SWE/09-289/AJ

IMA-SP/D08 issue 1.3 15/04/2011 of 86


USER-NEEDS

Avionics Time and Space partitioning user needs - issue 1 revision 0 - 21. august 2009

TEC-SW/09-247/JW

OPEN-IMA Open Systems Integrated Modular Avionics – The real thing – René L.C. Eveleens National Aerospace Laboratory NLR, available at :

http://ftp.rta.nato.int/public//PubFullText/RTO/EN/RTO-EN-SCI-176///EN-SCI-176-02.pdf

IMA-STATE-OF-ART

Open Integrated Modular Avionic (IMA): State of the Art and

future Development Road Map at Airbus Deutschland

Henning Butz, available at :

http://www.aviation-conferences.com/architecture/pdf/ima-henning-butz.pdf

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


3 TERMS, DEFINITIONS AND ABBREVIATED TERMS

3.1 Definition of Terms

Term Definition

3.2 Acronyms and Abbreviations

Term Definition

ECSS European Co-ordination for Space Standardisation

ESA European Space Agency

ESTEC European Space Technology Centre

FDIR Failure Detection, Isolation and Recovery

IMA Integrated Modular Avionics

IMA-SP Integrated Modular Avionics for Space

OBSW On Board SoftWare

TSP Time & Space Partitioning

ARINC Aeronautical Radio, Incorporated

SEP System Executive Platform

AFDX ARINC Full DupleX

APEX Application Executive (A653 API)

ADCN Aircraft Data Communication Network

3.3 Methodology

In order to define formally the proposed process, the SPEM process modeling language will be used in this document. This modeling language is standardized by OMG.

Here is a short description of SPEM language:

A process artifact

A process activity

A process role

A tool

Table 1 descritption of SPEM symboles

IMA-SP/D08 issue 1.3 15/04/2011 of 86


4 ANALYSIS OF IMA IN AERONAUTICAL DOMAIN

This chapter presents the current IMA approach in the aeronautical domain.

4.1 Why IMA?

It seems important to recall the historical reasons of IMA approach in aeronautics and its impact on today airplanes’ systems. The current space domain context shall be compared with the aeronautic domain in the 90’s to identify the common points and also the differences.

Integrated Modular for Avionics (IMA) paradigm has been introduced in aeronautical domain in the early 90’s to reduce costs, without losing performance, safety, availability of the system, nor independency between function providers. This has been made possible thanks to the arrival of new powerful processors enabling to process many functions on a same node. The targeted IMA advantages were reduction of weight, volume and power consumption of the avionics (by reducing the amount of hardware), reduction of material stocks within airline maintenance centers, reduction of cost for version upgrades (core Hardware and Software), reduction of cost for functional enhancements, and reduction of cost through the emerging market of open standards.

4.2 General principle

We first give a quick view of an IMA based system in aeronautical domain, for a better understanding of the development process.

[RD-01] defines IMA as a shared set of flexible, reusable, and interoperable hardware and software resources that, when integrated, form a platform that provides services, designed and verified to a defined set of safety and performance requirements, to host applications performing aircraft functions.

The system is composed of several applications from different suppliers hosted on an unique platform (composed of several modules) that provides time and space partitioning and communicating services using a communication network.

Figure 1: example of IMA architecture in aeronautics

It seems relevant to notice that the IMA platform in aeronautical is composed of several modules as shown in the figure 1. The Document [OPEN-IMA] highlights the fact that modularity is only achieved to a certain extent. Indeed, inside the platform, each module performs a specific function (like flight management modules, or display modules). Therefore, there is a strong connection of aircraft functions to a precise module.

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


4.3 Development process in aeronautic

IMA approach introduced many changes in the global development system in aeronautical domain, as presented in [RD-06]. These changes impacted on roles and responsibilities definition [RD-08], and on the overall development process. This section first describes an example of IMA project, before analyzing more in detail the different aspects.

4.3.1 An IMA project example: Airbus A380

Document [IMA-STATE-OF-ART] describes the approach used to apply IMA in the A380 program. This approach is recalled in this section, to give a general view of the development process.

When designing the A380 aircraft, Airbus took the IMA approach that had first been used by Honeywell in 1995 for cockpit functions on the Boeing 777 aircraft. But Airbus went further in the approach, selecting the ARINC 600 norm for the avionic modules, replacing the back plane bus by a 100Mbit Full DupleX (AFDX) switched Ethernet network (open standard), and applying IMA modules to all types of aircraft functions. This new concept was called “open IMA”. In that approach, modules and communication devices are procured from third party avionics suppliers. The “open IMA” standard leads to a competition market, allowing Airbus to control the costs.

Figure 2: the "Open IMA" Network on the A380

IMA-SP/D08 issue 1.3 15/04/2011 of 86


The IMA system development and integration procedure is split between the Avionic Module supplier, the Aircraft System Manufacturer, and Airbus.

4.3.1.1 Step 1.1 - module specification

Airbus is responsible for specifying the basic features of the IMA modules, according to IMA ARINC standards 600, 615, and 653. These standards cover the module packaging, the API services, the monitoring, data loading etc. Then Airbus, as a System Architect, is responsible for collecting and merging the specific requirements of the different system functions, which shall be processed by IMA modules. This concerns special signal types, processing cycles, memory use, etc. to be added to the basic module specification. Based on this specification the avionic module manufacturer develops the respective standardized multi purpose IMA modules (CPIOM = Core Processing & I/O Module).

4.3.1.2 Step 1.2 - system specification

In parallel the system specifications are issued to the system manufacturers who are obliged to use those standard CPIOM controllers within their system design. This requires that the system suppliers have to be provided with a very detailed description of the CPIOM. This is the “Module User Guide”, a manual, which precisely explains the CPIOM design features and how it must be operated. Additional refinement iterations are executed between the system suppliers and the module manufacturer in the frame of “requirement capturing workshops” under the governance of Airbus in order to complete the module design and to promote a mutual understanding.

4.3.1.3 Step 2.1 - system development

When the system suppliers start the function development a complete tool chain is delivered to them, which supports their development process. The tool chain provides SW configuration tools, SW linkers and loaders and module emulation devices. These tools enable the system manufacturers to debug and verify the SW of their functions in the very early stage of the development cycle even if the physical CPIOMs are not yet available (desktop validation). The efficiency of this approach can be quantified from the fact that on the A380 the system function qualification on IMA modules was achieved up to one year earlier than with conventional controller design.

4.3.1.4 Step 2.2 - system partial integration and qualification

When the IMA modules are ready, Airbus provides the necessary quantity of modules to each system manufacturer who run their applications on a CPIOM. On site the different suppliers perform their local single function integration and system qualification. The modules are pre-configured by Airbus according to the final integration condition on the aircraft when several functions from different system suppliers will have to be processed on the module. This is the process of “incremental qualification” which means that each system manufacturer only gets its own function integrated to the module without being obliged to consider the presence of any function from other system vendors, which will be integrated to the same module afterwards. The incremental qualification approach is supported by the strong partitioning property of the IMA modules. The validity of the strong partitioning property of the IMA modules has to be verified by Airbus. For this purpose a specific test suite is applied to the modules, which proves that the different SW partitions on a CPIOM cannot interfere under any condition. The tests must comply with the demands of the aircraft certification process. The verification of the partitioning mechanisms is worth the effort because it enables Airbus to integrate the module with several pre-qualified functions from different system sup-pliers on the aircraft without the obligation to re-qualify the system functions after final integration – the functions will not interfere.

The open IMA concept puts Airbus into the position of the IMA system integrator. The development responsibility for the single systems and their functions remains at the system manufacturers. The avionic module supplier provides “empty” IMA modules to both, the sys-

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


tem manufacturers and to Airbus. The system manufacturer applies the CPIOM for the local function implementation and qualification. Airbus, in turn integrates the own empty CPIOM with the Aircraft Data Communication Network (ADCN) on the aircraft in order to establish the basic computing resource for different system functions.

4.3.1.5 Step 2.3 - System configuration

Before the system functions can be processed on the IMA Network Airbus has to generate appropriate configuration files for the ADCN communication and for the CPIOM operation.

The ADCN configuration mainly concerns the address tables of the Ethernet switches, the data frame size, its transmission rate and the required bandwidth of the Virtual Links (VL). The Virtual Links feature communication lines which the signals take along the network. They can be considered as virtual wires, which transmit data according the ARINC429 standard protocol across the AFDX switches and cables. Adding new or changing subscribers to the ADCN only means to establish a new VL between the transmitting and the receiving device. This makes the configuration and the modification of the avionic architecture quite flexible.

The configuration of the CPIOM concerns the allocation of memory space, signal ports and processing cycle times to the different application SW partitions. The configuration data is laid down in configuration table files, which are loaded on the CPIOM in order to get the operating system perform as required by the different SW applications, which run on the module. Application SW and configuration files always constitute a tight entity, which must not be confused or mistaken for safety reasons. This is why the application SW loads and the respective configuration files are subject to a validated version management implemented on appropriate databases and Product Data Management (PDM) tools.

4.3.1.6 Step 3 - System integration

After completion of the local system function qualification the system suppliers provide their respective application SW partitions to Airbus. Airbus assorts and collates these files according to the individual IMA system configuration, which depends on the actual serial production number (MSN) of the aircraft and adds the respective configuration tables. Application SW partitions plus configuration table files make up the final SW load that is delivered to the final assembly line where it is loaded to the empty CPIOMs on the aircraft under production. As an interface between Airbus IMA SW integration facility and the final assembly line for the hand over of the “final SW loads” a protected database – the “SW Ground Repository, SGR” is installed.

4.3.2 Roles and responsibilities definition.

Based on the A380 example presented above, we can identify four roles in a IMA based approach in the aeronautics domain:

� SYSTEM ARCHITECT: The System Architect specifies the basic features of the IMA modules, and defines the system requirements. The System Architect also chooses standards that shall be applied all along the development process.

� MODULE SUPPLIERS: Module suppliers provide the standardized pre-qualified CPIOM (Core Processing & I/O Module) offering strong partitioning properties, and composing the IMA platform. Empty Modules are provided to both System Suppliers and System Integrator. Module suppliers provide System Suppliers with a precise “Module User Guide”, and with module emulation devices to support system development.

� SYSTEM SUPPLIERS: The System suppliers provide the hosted application, developing and testing it using SW linkers and loaders, and module emulation devices. System Suppliers perform verification and pre-qualification activities on a sub-set of empty modules provided by Module Suppliers. The verification of the application usually follows a two step process. The first step is the verification of the direct communication

IMA-SP/D08 issue 1.3 15/04/2011 of 86


between the application and the complete IMA system (communication with other applications is simulated). The second step is to verify that the application is resilient to indirect interactions with other applications using the same shared resources. This step will ensure that any hardware or software resources unique to the hosted application will not compromise the integrity and availability requirements.

� SYSTEM INTEGRATOR: The System Integrator is in charge of verifying the partitioning mechanisms of the assembled empty IMA platform. The Integrator generates the configuration of the platform, and then perform a top-level verification to ensure that the configured platform is capable to host the applications. The allocation of the platform resources is an iterative process between the Integrator and the System Suppliers. System Integrator is also responsible for the integration of the hosted systems on the platform, and to verify the global system.

As one can notice, Airbus, in the A380 program, has both the roles of System Architect, and System Integrator.

4.3.3 Process description

As seen with the A380 example, the traditional independence between sub-systems - thus between actors - in federated architectures is impacted in IMA architectures. For example, as described above in the roles descriptions, the Module Supplier interacts with the System Supplier regarding services and performance. This interaction has to be handled by the System Integrator and the System Architect due to the concept of role separation in IMA.

In this context, it is vital to manage the system complexity through fundamental system engineering. Methodology and robust tools are needed along the development process of the IMA system [RD-12].

Preceding the development activities, there must be a clear division of responsibilities through the whole process. (Certification authority, Certification applicant, System integrator, Platform and Module suppliers, Application suppliers, Maintenance organization). Another preliminary activity is the qualification of the tools that are to be used in the development process.

The IMA development process is composed of three main steps:

- Step1 : Global System Specification including requirements for modules and sub-systems. Definition/selection of the standards to be used.

- Step2 : Development of modules and sub-systems, and partial verification and validation.

- Step3 : Integration of the platform (modules and network) followed by integration of sub-systems applications onto the platform. Verification and validation of the global system.

These steps are obviously different depending on the roles. For example, development does not concern System Architect, or System Integrator.

The development process can be illustrated as on the Figure 3Figure 3. In this diagram, arrows indicate the workflow, which is not always sequential.

The following abbreviations are used in the diagram:

Term Signification

SA System Architect

SI System Integrator

MS Module Suppliers

SS System Suppliers

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


MODULE SUPPLIERS ARCHITECT & INTEGRATOR SYSTEM SUPPLIERS

Table 2 abbreviations for IMA-SP roles

Figure 3: development process for IMA in Aeronautics

SPECIFICATION

DEVELOPMENT

INTEGRATION

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 3Figure 3 highlights the numerous dependencies that exist in the IMA development process. The two delicate points are system specification, and resource allocation.

The System Architect defines the requirements for the modules, and for the sub-systems composing the IMA system, choosing standards to be applied. Module Suppliers elaborate the module specification and User Guide, and deliver them to the System Suppliers that specify the sub-systems. These System Suppliers might have specific requirements that are not supported by defined modules. They have to inform both System Architect and Modules providers about these specific needs. System Architect defines new requirements for modules, and Module Suppliers modify both modules specification and user guide, and deliver a new version to System Supplier, that modify their specification.

Assuming there is a large number of system suppliers, with possibly different concurrent suppliers developing the same system with different implementations, this specification process becomes very complex, and must be handled using efficient tooling and methodology.

Once Modules and Systems requirements match and are well defined, the parallel development of each module, and sub-system begins.

Another delicate point in the IMA development process is the resource allocation activities.

System requirements

Bare Module Requirements

Sub-System requirements

Sub-System specific requirements

Bare Module constraints

Resource allocation and configuration table elaboration

System tests and resource negotiation

of 86 15/04/2011 IMA-SP/ D08 issue 1.3


Several independent systems may be allocated to a same module. System Integrator must verify that the shared resources won’t generate conflicts.

Once resource allocation is done, a bare module is provided to each System Supplier, with the respective configuration table. System Suppliers are responsible to check if the resource that has been allocated for their system are sufficient, and shall negotiate with the system integrator if they need a different allocation scheme. System Integrator may modify allocation, but shall verify that an allocation change for one system will not affect another system.

In Figure 3Figure 3, the dotted line coming out of the feasibility checking step has the following signification: if no allocation scheme satisfies feasibility, or if the trade-off is too expensive, the system specification could be modified.

Assuming there is a large number of system suppliers and a large number of modules, the resource allocation activity can quickly become complex, and must be handled using efficient tooling and methodology.

A flexibility parameter for the system Integrator is the number of modules in the platform. During development, the platform implementation may be modified by adding more modules to increase the platform capabilities if new aircraft functions are requested. This has to be traded-off with weight, cost, and place increase.

When all the sub-systems are pre-qualified and that partial integration has been verified, the integration begins.

4.3.4 Process’ activities in detail

The following table aims to detail all the activities performed by the different actors, using a chronological view.

The platform concept in the process described hereafter refers to several modules of different kind (CPIOM), hosting a core software (Operating System) providing resources to applications, and connected to a common network (AFDX Network). It is thus important to distinguish:

- Module specification/Platform specification: module specification is first in the process because it is deeply linked to sub-system specification, whereas platform specification may be changed until resource allocation is verified (if new sub-system are added).

- Module development/ Platform implementation: Platform implementation consist of assembling the different pre-qualified developed modules and the communication network.

- Module acceptance/ Platform acceptance: When the modules comply with their requirements, we talk about module acceptance. When all modules are integrated in the platform with the communication network, the properties of the whole platform must be also proved to obtain the platform acceptance.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Table 3 : detailed IMA development process

Development phase

System Architect System Integrator Module Suppliers System Suppliers

Definition of the high level requirements for the entire IMA aircraft system.

Selection/definition of the standards to be applied during the development process.

Definition of the platform basic features:

- definition of reusable, sharable modules and resources

- architecture definition independently of hosted applications

- definition of the integration approach

- definition of the platform acceptance approach

- definition of the system certification approach

- definition of a list of platform services provided to applications

- definition of platform capabilities (availability, integrity …)

- definition of the platform and IMA system configuration management approach.

Design

Definition of the sub-system requirements

of 86 15/04/2011 IMA-SP/Do8 issue 1.3


Redefinition of the module requirements according to sub-system specific needs.

Specification of IMA Modules 1

- deep analysis of individual hosted application needs (application’s functional requirements and data needs with rate and latency attributes).

- Characterization of the module attributes

- safety capabilities requirements

- performance capabilities requirements

- health management and fault management requirements

Specification of the sub-systems

-functional specification

-non-functional specification: definition of the platform resources needed by the sub-system applications

IMA Platform specification:

- Identify functional and non functional requirements of sub-system applications.

- Definition of the quantity, quality, and type of IMA platform modules and resources needed to provide the capabilities to meet application requirements.

(This activity is performed by the system architect and/or the System Integrator)

Mapping of sub-system application’s requirements to IMA modules capabilities:

- safety assessment

- health management

- fault management

Resource management and allocation between all hosted applications, to ensure the feasibility of the integrated system, and the optimization of each application (leading to the optimization of the global system).

Contract resource allocation with system integrator

Specification and configuration

System configuration, to configure each element of the system according to resource allocation. This step must not rely on manual configuration. A robust tool is thus needed to build the configuration tables [RD-06].

1 Theorically, IMA does not require Module Supplier to have domain expertise of the hosted application domains, because System Integrator (and System Architect for design phase) shall be the unique interface between Module Suppliers and Application Suppliers. Standardization of interface (APEX) is also done for this purpose.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Preliminary System Safety Assessment (PSSA) for each hosted application using the IMA platform’s safety requirements

Identify changes required to the allocation of IMA platform resources to correct any issues identified from the individual and combined PSSA activities.

Module Development and implementation :

- HW and SW development according to D0 178B, D0 254, ARINC 653 and AFDX standards

Application development according to ARINC 653 and AFDX standard.

Use of Module emulation for preliminary test and validation

Development

Modules delivery to System Integrator and System Suppliers.

Partial verification and validation of hosted application using bare module provided by Module Suppliers

Platform assembly with bare modules and AFDX network.

Platform verification, validation, and acceptance

Partial integration of hosted application onto the platform. Verification and validation.

Parallel applications acceptances.

Initial IMA system failure analysis

On

Sys

tem

Inte

grat

ion

benc

h:

AD

CN

, FM

/CD

S, A

larm

s…

Evaluate the combination of several IMA platform component and hosted application, and adjust allocation and/or application’s implementation as necessary.

Integrate all the IMA system

Adv

ance

d S

imul

ator

(a

ircra

ft «

zero

»)

Validation, verification and acceptance of IMA system off aircraft

Integration

fligh

t tes

t Validation, verification and acceptance of IMA system installed on the aircraft

Perform aircraft ground and flight testing to validate assumptions of SSA and requirements.

of 86 15/04/2011 IMA-SP/Do8 issue 1.3


4.3.5 Flexibility

To minimize the impact on the global system if some application or platform changes occur, the development process includes also:

• Design methods, to limit the impact on the system if a change occurs in the platform or in one or more applications. A good definition of the interfaces of the system’s elements is mandatory. Mechanisms may be employed to limit the application’s sensitivity if the timing characteristics of the platforms change (i.e. increase bus speed, upgrade processor’s clock rate …)

NOTE: tools are needed to manage the complexity of interface definition.

• Verification strategy to prove that the hosted application meets its requirements given a range of potential shared resource performance. If the IMA platform resources change within this range, non-regression tests would not be needed for the application. This is a delicate point, and efficient tools are needed.

4.3.6 Conclusion

Nowadays, the IMA paradigm has been applied to many civil and military aeronautical programs, and the benefits of using a such approach have been proved : IMA brought more flexibility (through configurability of componentized system), reduced costs (through shared computing platform and increased utilization of resources), while preserving time and space partitioning properties. IMA also allows to reduce development cycles and to preserve independence between actors. However, due to the extreme complexity of IMA systems, some aspects of the usual IMA process have limits that will make IMA evolve in the near future. These aspects are studied in the following section.

4.4 Critical review of the aeronautical process

This chapter provides a critical review of the aeronautical process presented above. IMA has been used for several years in aeronautical domain, on different projects. It seems relevant to include to the IMA adaptation for Space domain the conclusions and limits that have been already noticed, and to consider aeronautical feedback.

4.4.1 Need for a model of the overall system

During development, the system integrator requires an accurate model of the system, as well as trusted analysis methods for calculating system utilization and performance. A tool is also needed to evaluate the individual application’s contribution to the optimization of the global system.

In aeronautics, it still remains difficult to handle the complexity of the global system from the design phase to the integration phase, independently of requirement changes or hosted application modifications. The major issue is to model the interaction of the different elements of the system. Current solution is based on XML configuration tables. Tools are in charge of verifying the conformity of the system with the standard given in the XML schema. Later tools will be more robust and efficient.

4.4.2 Need for early system simulation

As presented in the presentation of the IMA development process, there are two main difficult steps: specification of modules and sub-systems, and resource allocation and global system configuration.

Aeronautic feedback proves that there exists a strong need to optimize the resource allocation and to improve configuration thanks to early simulation of the platform, and of external functionalities.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


4.4.3 Need for more standardization

Although parts of the API involved in an IMA system have been standardized, such as ARINC 653 and AFDX, it must be noted that there is no overall hardware or software standard that defines all the mandatory elements used in an IMA architecture. Instead, mostly proprietary standards are used, making the changes very expensive and introducing a supplier monopoly, as competition is not possible, according to [OPEN-IMA]. The Open IMA concept introduces open interfaces and standards for all elements of the IMA system, allowing to mix components from different suppliers which increase competitiveness, and flexibility on supplier selection. Efforts are then focusing at application level and not at the interfaces level, which gains time and money. The drawbacks of a such approach is the need for all information related to platform or modules to be public. But suppliers may want to protect their knowledge, and will not easily provide all required information. Moreover, standardization often results in solutions which are less well tailored for a given situation and hence a lower performance.

4.4.4 Need for Contract based interactions

There is currently no way to standardize contracts (functional and non functional) for the elements of the system. This explains that some problems are discovered late in development, for example only during integration and operation phases, leading to system instability and failure.

Contract concept could allow some kind of plug-and-play applications, enabling to use alternatively one application or another without need for regression tests.

4.4.5 Need to improve toolset capabilities

As the process and the system become more complex, the tools used in an IMA program are often not efficient enough. There is a strong need for greater tools for design, integration, and industrialization. The main objectives for future tools are full system virtual validation, and auto-testing platform.

The main issues are to model architecture, behaviors, functional and non-functional properties, communication, and platform elements, to be able to perform fast configuration, and feasibility verification before any implementation, and to avoid testing and re-testing the system.

This requires complex tools. A lot of investigation are currently addressing this issue.

Another family of tools to be used during all phases of the process concerns development analysis, to measure how far overall requirements are fulfilled (e.g. safety, costs .. ).

4.5 Lessons learnt from the automotive domain

This chapter presents an analysis of the automotive domain, in particular linked to the AUTOSAR specification.

4.5.1 AUTOSAR overview

The AUTOSAR high level of standardization and system architecture can bring interesting concepts to the study of IMA for Space. It uses a standard component description and a description of the system resource. These descriptions can be easily used by tools at an early stage of the development process to verify and validate the properties of the system.

To achieve the technical goals of modularity, scalability, transferability and re-usability of functions, the AUTOSAR standard provides a common software infrastructure for automotive systems based on standardized interfaces for the different layers (Applications, Operating System, Actuator Software components…) using a standard component

of 86 15/04/2011 IMA-SP/Do8 issue 1.3


description (operations and data, requirements, resource needed and information regarding specific implementation).

In AUTOSAR standard, a Virtual Functional Bus (AFB) provides at an abstract level all the communication mechanisms and interfaces, and allows virtual integration of all software components in an early development phase.

AUTOSAR also provides description formats for the system constraints, the resources and the configuration of the Electronic Control Units (ECU).

Those various description elements are put together in order to build a concrete system of ECUs. This includes especially the configuration and generation of the Runtime Environment and the Basic Software on each ECU.

Figure 4: AUTOSAR approach (from www.autosar.org)

AUTOSAR also provides a design methodology to build a system with this technology. The first step is the description of Components, System and Resources. These descriptions are used to generate components API and a global System Configuration Description (SCD). The API is used to implement the Software Components while all the information needed by each ECU can be extract from the SCD. All the components of the system can then be generated.

4.5.2 Critical review of the AUTOSAR process

Considering this automotive approach, the following points are really interesting for the IMA-SP development process:

- high level of standardization of the elements of the system: This leads to a coherent system, and eases the analysis of the interactions between all elements.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


- the will to standardize both functional and non functional requirements: taking into account non-functional properties of the system at an early stage of the development process (design phase) is a way to minimize integration efforts (conflicts can possibly be detected before integration).

- high level of abstraction: for complex systems, abstraction is a way to solve a lot of issues before producing any part of the system. This possibly allows virtual integration and eases feasibility analysis. Trade-off can be optimized with the results of these activities before the realization of the system.

- automated generation of component API from component description: Some part of the system (mainly the structure of the subsystems, and their interactions) can be automatically generated from the abstract point of view of the system. This saves development costs (time, … ) and allows to focus on functional implementation.

Although the purpose of IMA-SP study is not to analyze AUTOSAR development process, the previous points are taken into account in the IMA-SP development process:

Table 4: IMA-SP development process benefits from AUTOSAR

AUTOSAR characteristics How it can be taken into account by IMA-SP development process

References

High level of standardization The level of standardization will be decided by the System Architect at the beginning of the development process. The standardization of the interfaces between the system elements is the purpose of the [D10] document of the IMA-SP study.

[D10)

Consideration of non-functional (or extra-functional) requirements.

The IMA-SP development process will introduce the concept of “partition description” that will allow Application Suppliers to communicate non-functional features of their application to the system integrator. The partition description will be taken into account for the system feasibility verification activity performed by the System Integrator.

[D08] sections 7.7.11 and 7.7.19

High level of abstraction The IMA-SP development process defined in this document will be compatible and designed for Model Based Engineering. (It will still be compatible with standard system engineering).

[D08] sections 5.2.4 and 8.1

Use of Component description to ease automated generation of component API.

The IMA-SP development process will introduce the concept of “component” resulting of other studies (CORDET, …). This will ease the automated generation of component API. (However, the IMA-SP development process will still be compatible with state-of-the-art system engineering).

[D08] sections 5.2.4 and 8.1

of 86 15/04/2011 IMA-SP/Do8 issue 1.3


5 APPLICABILITY OF IMA PARADIGM TO THE SPACE DOMAIN

The applicability of IMA to the space domain must be analyzed before defining an IMA development process for Space domain. This has been already addressed in [USER NEEDS] and the major points are analyzed here.

5.1 Comparison between aeronautical and space domains

The analysis of IMA applicability to the space domain begins with a comparison between the final products. Those products has to be compared against well defined criteria. This comparison shall emphasize the major common points, and the major differences.

Table 5 provides this comparison, with some analysis.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Table 5 : comparison between space and aeronautical domains

fxghfghf

Analysis

Product family

Civil aircraft

- commercial

- business jet

- cargo

Military aircraft

Telecommunication

Positioning

Weather forecasting

Observation

Military spacecraft

…

Products in aircraft family differ on size, carried load, and comfort.

Products in spacecraft family differ on size, shape, and general mission.

Inside a product branch, products can be very similar (telecommunication) or very different (scientific missions). The concept of “product family” is stronger for telecommunication products than for observation and science products.

For that reason, IMA-SP process will need to be instantiated (tailored) for each product line.

Market conditions

Annual market: >$8 billion

Production number by product-line: 100s

Annual market: ≈ spacecraft segment sales in 2009 was approx 3.7 billion euros 2

Production number by product-line: from 1 (scientific missions) to 10s (telecommunication, constellations)

Investment in space domain results in reduced return of investment than in aeronautical domain.

Space domain can not afford to deploy an IMA process from

2 This covers the entire S/C segment while the aeronautical reference is only for the avionics. See the latest Eurospace industry report at http://www.eurospace.org/FANDF2009/ffdata2009_web.pdf

of 86 15/04/2011 IMA-SP/Do8 issue 1.3


scratch, and must rely on aeronautical technology and experience.

Main functionality(ies)

One common functionality for all aircrafts:

-> Safely carry passengers (at least a pilot) via air

Several functionalities depending on the mission:

-> Provide telecommunication services

-> Provide observation services

…

There is a big difference between aircrafts and spacecrafts main functionalities. IMA-SP process shall take into account the mission specificities of space domain.

Common functionalities between all products

Flight management

Engine management

Energy management

Fuel management

Break management

Steer management

Alarms/Warning

Cockpit Display

Cabin management

optional: entertainments …

Platform management:

- Central Flight Software (CFS):

- Data management (DMS)

- Attitude & Orbital Control (AOCS)

- System Mode Management

- Power management

- Thermal control

- Mission Management (OBCP)

- Payload Management

- Decentralized SW (star-tracker, mass memory, camera…)

In both product families there are a large number of common functionalities. This is one of the reason to adapt the IMA paradigm to space domain.

IMA-SP process shall be designed for already identified use-cases:

- Segregating OBCP from CFS

- Partitioning CFS applications and functional SW (e.g. star tracker)

- Partitioning shared libraries.

- Partitioning Payload(s).

Specific functionalities to

a kind of products

Payload:

- Command and Control Services (CCS)

- Local System Management (LSM)

- Local Hardware and Software resource management (LHS)

- Scientific Data Processing (SDP)

The big difference between aircrafts and spacecrafts is that in space domain, there exists a large kind of different payloads, very specific to dedicated missions.

Howerver, the A400M aircraft (applying IMA paradigm) is a

IMA-SP/D08 issue 1.3 15/04/2011 of 86


good counter example of the family homogeneity in aeronautics.

Applications’ criticalities

Different critical level of the applications embedded in IMA. (from A to D)

Majority of applications are of criticality B.

Other applications can be of criticality C

Even if the criticality range differs between the two domains, this is considered as an identical issue.

Independence between the different

applications providing the functionalities

Federated architectures:

Numerous independent applications executed on their respective separated nodes.

IMA architecture:

Numerous independent applications executed on a shared IMA platform (up to 80 functions)

State of the art:

Independent applications (Payload, OBCP, CFS, decentralized SW) are executed on separated nodes (e.g. star tracker), or sometimes partially integrated on a same node (DMS, AOCS, OBCP).

Although space state of art is similar to the former federated architecture of the aeronautical domain, there is a trend towards an integrated architecture, which justifies the IMA-SP study.

Applications’ lifecycle

Federated architectures:

Sub-Systems are developed by different suppliers, with their own life cycles.

IMA architecture:

Sub-Systems are developed by different suppliers, and are integrated in a unique platform.

Functional chains (e.g. DMS, AOCS, OBCP) are produced by different groups but can be integrated together in a single flight SW image.

This is a major common point for the IMA-SP analysis.

Actors

In IMA projects, roles have already been defined:

System Architect,

Current repartition of roles in Space Domain is:

Prime Contractor (in general has the roles

Introducing IMA-SP will not have any direct organizational impacts, but will probably allow more independences between suppliers.

of 86 15/04/2011 IMA-SP/Do8 issue 1.3


System Integrator,

Module Suppliers,

System Suppliers.

of system architect and system integrator)

Subcontractors (one of the subcontractors may have the responsibility for avionics platform design and integration).

Operation & maintenance of the product

Module or application replacement, or evolution can occur during the operational phase of the IMA system.

The HW nodes can not be changed during operational phase. Only application modification can occurs (patch/dump)

This is a difference between the two domains, because SW maintenance is performed on the ground for aircrafts, whereas spacecraft operations require the system to be active.

Hardware consideration

Numerous computing nodes with high computing power.

Network offering high speed communication skills (AFDX …)

Only 2 or 3 nodes (PM, PL, Star tracker) with limited resource and capacities. Current processors are: 1750, ERC32, LEON ….

Limited Networks (1553b, Space-wire, CAN…)

This is today one of the big difference.

In space domain, new more powerful processors are coming (LEON, PowerPC, …), and will allow to gather more applications on a same node.

Software configuration

Extensive use of ADA language.

Use of RTOS: VxWorks, MACS2, …

Use of ADA and C languages

Use of RTOS (RTEMS, OSTRALES

Aeronautical (RTOS ..) products are not compatible with space micro-processors. New products and tooling will be needed in the IMA-SP process.

Level of re-use

High level of application re-use from one product-line to another, due to the common architecture between all aircrafts

The level of re-use is limited within a product family (telecommunication), when there is a strong inheritance between products. It is very limited for products of specific domains (science).

This is a major difference between space an aeronautical domain. But with an IMA-SP process, re-use could become an issue, especially a platform reuse.

Re-use shall be taken into account in the IMA-SP process.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


5.2 Adapting IMA paradigm to Space Domain

IMA paradigm has been found applicable for the space domain. The resulting IMA development process for Space domain – IMA-SP process – can be directly derived from aeronautical IMA development process, presented in the previous section. However, IMA-SP process shall take into account the feedback from aeronautic, and the differences existing between aeronautical and space domains.

5.2.1 Adapting IMA-SP product perspective

As seen in Table 5, aircrafts and spacecrafts are very different products. However, system architectures present similarities, with a major difference which is the size of the system.

The IMA concept defines a platform that provides services to execute software functions. The time and space partitioning feature is obtained by isolating the functions in several independent partitions.

Figure 5: representation of an IMA system

The IMA platform in aeronautical domain is composed of several modules (up to 30 in A380) of different types (8 in A380), connected to an AFDX network, and hosting many avionics functions (21 functions in A380) developed by many suppliers (10 function suppliers for A380). On the platform, a Core Software is responsible to offer basic services to applications, according to A653 standard.

In Space domain, the IMA architecture will have less computing nodes (only one node at short term – On Board Computer - , maybe several nodes in medium term), connected to a less powerful network (based on Space-wire or MIL-STD 1553b), and hosting less functions developed by less suppliers.

The “Module” concept does not really apply to Space domain. For this purpose, we propose to map this concept to the concept of “hardware node”, or “IMA unit”. A hardware node is a computing unit, based on a single processor (such as LEON …), or multi-processor core (future). It is connected to decentralized units (which are not part of the platform), and possibly (in the future), to other hardware nodes, using one or several network (based on MIL-STD, or Space-wire technologies). The aeronautical concept of “platform” will be called IMA-SP Platform in the IMA-SP context.

When the platform is composed of a unique hardware node, the associated network is not a part of the IMA-SP Platform, but only provides I/O transfer. If the platform is composed of several hardware nodes, the network they use to communicate is part of the IMA-SP

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Platform. Other networks used to connect decentralized units are not constituting the IMA-SP Platform.

Each hardware node (possibly one) is hosting a software component that will be responsible to offer Time and Space Partitioning services to independent Partitions. This software core is called System Executive Platform software (SEP), or On Board Computer software (OBC software) in case of a unique hardware node.

This SEP contains a kernel that schedules the execution of partitions, and provides the partitioning mechanisms. Inside a partition, a local scheduler (guest OS) may be used to execute concurrently several independent processes.

Besides the SEP, the IMA-SP Platform also contains support services needed by applications or used from the ground. These services will be detailed in [D10].The IMA-SP platform is thus considered to be composed of :

• Hardware node(s).

• System Executive Platform (SEP):

o IMA separation kernel

o Execution framework:

� TSP Abstraction Layer (equivalent to APEX)

� Technical services (initialization, inter-partition communication, persistence, software maintenance, …)

o Guest OS (optional) inside partition-s.

• System support services [common services in support to hosted software functions e.g. I/O handling function] inside dedicated partition-s.

• Application support services [mediation code implementing standard protocols e.g. TM/TC interface]

This organization is illustrated in Figure 6Figure 6:

Figure 6: IMA-SP Platform in global System Organization

IMA-SP/D08 issue 1.3 15/04/2011 of 86


This IMA-SP platform is the ground on which application developers will execute their applications.

In aeronautical domain, a sub-system (e.g. Flight management) provide the global system with functionalities. These functionalities are supported by elementary functions. A set of functions providing a functionality is called an application.

In a similar approach, in Space domain, system functionalities are divided in functional chains. Distinction is made between Avionics functions, and Payload functions. The concept of application is the same as in aeronautic.

In this document, Application refers either to a software function, or to a set of software functions implementing a functionality. An application made of several complementary functions can possibly be dispatched in several independent partitions. This is illustrated in the following figure :

Figure 7: link between applications and partitions.

Additionally to the software functions, an application may need a decentralized unit to provide the functionalities to the system. For instance, an integrated Star Tracker application relies on one or more decentralized optical heads. These are not part of the IMA-SP system, but shall be taken into account for the IMA-SP platform development.

The following table summarizes the terminology:

Table 6 : IMA-SP terminology

Aeronautic Item

naming

(DO-297)

Space Naming Description (space context)

Module Hardware Node or Unit A module may be hardware, or a combination of hardware and software, which provides resources to the hosted applications.

Platform IMA-SP Platform System which provides the resources to

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


support at least one application. The HW resources and core software are designed and configured in a way to provide suitable computational, communication, and interface capabilities to the application(s).

The IMA-SP Platform on its own does not provide any spacecraft functionality. The IMA-SP Platform establishes a computing environment, support services, and platform-related capabilities, such as health monitoring and fault management. The IMA-SP Platform may be accepted independently of hosted applications

Core software

OBC software or SEP software

OS and support SW that manage resources to provide an environment in which applications can execute

This product perspective has impacts on the role definition. These impacts are detailed in the following paragraph.

5.2.2 Adapting IMA-SP roles definition

In the aeronautic domain, the roles have already be defined (see section 4.3.2) : Modules constituting the platform are produced by Module Suppliers. Independent Applications providing the functionalities of the sub-systems are produced by System Suppliers, and the global system is integrated by the System Integrator.

From the IMA-SP product perspective, we can see that IMA paradigm can be implemented in very different systems and architecture (several nodes, different kind of SEP, …). The system architecture and organization shall be decided at the beginning of the development process, by a System Architect.

As already seen, the platform is independent from the hosted application, and can then be provided by an independent actor (IMA-SP Platform Supplier).

Within this IMA-SP Platform, we can divide responsibilities:

- The IMA Separation Kernel (SEP) (providing standard API) and (eventually) the RTOS personalities within partitions shall be provided by competent entities (could be COTS) with associated support.

- The hardware node(s) will be provided by an other actor, also (possibly) responsible for low level drivers, BIOS component, and network issues.

- The System/Application Support Services, that are space specific services, may be provided by another actor with high experience in Space activities. In case the specification of these services are well defined and common to many programs, this part could be developed by the Separation Kernel supplier.

The whole IMA-SP Platform (hardware nodes, SEP, and support services), will be qualified independently of applications.

The independent applications that have been identified during the design of the system could be developed by independent actors (or teams), the Application Suppliers. These developed applications are segregated in partitions (partitions can communicate), and have their own lifecycles.

All these applications, when pre-qualified, will be integrated in the qualified IMA-SP Platform. This action will be performed by a System Integrator.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


All this role repartition is flexible, and shall be defined by the System Architect at the design phase.

The roles identified for the IMA-SP development process are :

� System Architect

� IMA-SP Platform Supplier

� Application Suppliers

� System Integrator

This roles repartition differs from the aeronautical repartition. Indeed, Platform product in aeronautics is a qualified assembly of pre-qualified modules. As IMA-SP does not have module concept, the IMA-SP Platform qualification is to be performed by the IMA-SP Platform supplier. This IMA-SP Platform supplier rely on pre-qualified components (SEP, Hardware node, System/Application Support Services), possibly developed by sub-contractors (SEP suppliers …).

In a Space program, the Prime contractor could be either the System architect, or the System Integrator, or both. But this IMA-SP role separation allows independent teams to work concurrently, even in a same entity, and should be kept all along the development process.

The following table summarizes the roles and responsibilities repartition in both aeronautical and space domains.

Table 7 : Roles and responsibilities repartition

Roles & Responsibilities

In Aeronautical domain

Roles & Responsibilities

In Space domain

System Architect:

- Define role repartition

- Define system requirements

- Specify the basic features of IMA Modules

- Select/define standards to be used.

System Architect:

- Define role repartition

- Define system requirements (including choice of the platform and constraints on applications).

- Select/define standards to be used.

- perform HW/Software trade-off.

System Suppliers (or Application Suppliers):

- specify the hosted applications.

- negotiate resource allocation with System Integrator.

- develop and test applications by simulation, and on bare modules.

- verify and pre-qualify applications. (communications, system interactions, …)

Application Suppliers:

- specify the hosted applications.

- negotiate resource allocation with System Integrator.

- develop and test applications by simulation, and on real IMA-SP platform.

- verify and pre-qualify applications. (communications, system interactions, …)

competences:

Application expertise (Thermal, DHS, Power, AOCS, Payload …).

Embedded software expertise.

Module Suppliers:

- specify modules

IMA-SP Platform Supplier:

- design IMA-SP Platform

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


- provide System Suppliers with modules’ User-Guide and development and configuration tools.

- develop and test modules

- provide System Integrator and System Suppliers with pre-qualified modules.

- develop and integrate IMA-SP Platform including hardware node(s), SEP kernel, and Application/System Support Services .

- Verification and Validation of the IMA-SP Platform

- Provide IMA-SP Platform representative simulator and RTOS support.

- Provide SDE & toolset

- Provide configuration tools.

- Provide System Integrator and Application Suppliers with a pre-qualified IMA-SP Platform.

System Integrator:

- negotiate the platform allocation. Perform a top-level verification to ensure that the configured platform is capable to host the applications.

- verify the platform independently from the hosted applications.

- integrate hosted application in the platform

- verification and validation

System Integrator:

- is responsible for coordination3 between application suppliers and IMA-SP Platform supplier

- negotiate the IMA-SP Platform resource allocation with application suppliers.

- verify system feasibility.

- integrate hosted applications in the IMA-SP Platform

- verify and validate the integrated system

competences:

Software system engineering

This role repartition have many impacts on the whole process, and the feedback from aeronautical domain has revealed some limitations. These limitations are analyzed in the next paragraph.

5.2.3 Adapting IMA global approach from aeronautic domain to space one

Section 4.4 details the current known limitations of applying the IMA paradigm in aeronautic. Main issues are to have a global view of the system, from the design to the integration phases, and to verify the feasibility of the system earlier in the development process. This, to avoid discovering problems at integration or operation phases.

There is a obvious correlation between role repartition and IMA process limitation. Indeed, as each element of the global system has its own lifecycle, the interferences between all elements are only tested at integration time. The Platform Time and Space partitioning properties prevent for failure propagation, but does-not protect against error in resource allocation (time and communication issues). And as already seen, this step remains a complex issue.

3 In a context of high standardization and exact specification, IMA-SP Platform Supplier and Application Providers shall not interact. But feedback from aeronautics reveals that this is never the case, because some problems may occur (new needs, interface definition, tool implementation …). The document [IMA-STATE-OF-ART] explains how Airbus managed these problems organizing “requirement capturing workshops” to coordinate specification activities. It can be possibly a responsibility of the System Architect.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


The main objective to improve this aspect of IMA is to keep a strong independence of each element (to have independent life cycles in order to reduce development time), while having an global view of the whole IMA system at any time.

For this reason, the “vertical approach” used in aeronautic has to be modified, and should be completed by what is called an “horizontal approach”.

The Vertical Approach usually followed in aeronautical domain consists of developing all independent functions separately. The system integrator verifies that the resource requirements of each hosted application is respected and allocates resources of the IMA platform for the hosted applications.

Introducing an Horizontal Approach would consist of designing the system as a unique block composed of functions, without considering independencies, but only considering interactions between the different functions. In a second step, the system architect would perform a deep analysis to identify really independent group of functions, and would divide the system into independent partitions. Each application would be developed with its own life cycle, but the interactions with other applications could be taken into account since the beginning of the development.

One can say that this approach would lead to the same result as the strict vertical approach. It may be right for the major part of the system’s functionalities. But for some very precise cases, it should give very different results : an application could have several functions in different partitions, instead of having all its functions segregated in a unique partition. This flexibility could give an optimized partitioned system, reducing the risk of discovering errors at integration time.

For example, in Space domain, the vertical approach can be followed for some independent hosted applications (star-tracker, payload …) but would be difficult to apply as is for the OBSW. Indeed, some of the OBSW’s functions (TM/TC management, AOCS, Heat regulation, Battery management, FDIR, OBT, Data Handling System …) are deeply linked and dependent. An horizontal approach may be necessary to apply IMA paradigm to these applications. As well, I/O best strategy could be found with the horizontal approach.

Figure 8Figure 7 below illustrates the differences between a vertical and a horizontal approach.

In the vertical approach, each supplier develops a sub-system, composed of several functions. The resulting application (implementing the sub-system) is segregated into a dedicated partition, using a set of platform resource. Each partition is pre-qualified and integrated in the global system, besides other partitions.

In the horizontal approach, as in the vertical approach, each supplier develops a sub-system, composed of several functions. However, the resulting application (implementing the sub-system) is not segregated into one partition, but divided in software functions dispatched into several partitions according to an optimized configuration (scheduling, communication…). Partitions are independently pre-qualified (using stubs to simulate other partitions), and integrated to the platform to constitute the system.

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Figure 87 : vertical approach and horizontal approach in aeronautic IMA systems

A such horizontal approach strongly depends on the tools and methods used to have a global view of the system.

From this perspective, a system is not a set of partitions executing onto a platform, but a set of components, providing functionalities, and interacting. Even the platform can be seen as a component providing services. Each component can be divided in sub-component. For safety reasons, and to protect the system against failure propagation in the system, those components (except the ones of the platform) are segregated into several partitions. Two components inside a partition can interact (intra-partition communication), but two components belonging to two different partitions can interact as well (inter-partition communication).

This horizontal approach is seen as the future of the IMA paradigm in the aeronautical domain, and a lot of work is done in this way.

5.2.4 Impacts of a component oriented process

In this context, a component is a self contained element, that offers services to outside components, and that uses services of other components. A component is defined by its interface, that is a contract it shall respect. This interface is public and accessible by other components.

As one can see, this component oriented process applies the same philosophy as the Open-IMA paradigm presented in section 4.4.3 , which seems to be the logical evolution of the IMA paradigm: public interfaces and standards to allow to replace one component by another one having the same contract.

Moreover, such a component oriented process is already clearly defined for the space domain. Section 8.1 provides an overview of this process according to [SAVOIR-FAIRE].

The following figure illustrates what could be the association between the component oriented process and the IMA-SP process:

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 98: association between a component oriented process and IMA-SP

In this figure, the system is composed of a platform and of 12 components (C0 to C11) providing the system functionalities. Components have interconnections and provide one-another with services. In the figure, the components of the same color compose an application, developed by an application supplier independently of other applications. All the components are dispatched into several partitions (Pi), and each partition is mapped on a hardware node (Units 1 and 2). Hardware nodes can also be considered as components, offering services to the partitions they host.

In IMA process, the platform and all partitions have to be qualified before being integrated to constitute the global system. However, the component oriented process does not introduce a new acceptance step (at component level). Each component only goes through a verification and validation process, performed by its supplier.

As a partition is possibly composed of several components provided by several application suppliers, the partition acceptance process could become more complex. In order to keep a clear separation of responsibilities in a IMA-SP project, a partition hosting components from different suppliers has to remains of the responsibility of a unique Application Supplier (the application supplier who provides the major part of the component of a partition).

As a conclusion of this analysis, it appears that a component oriented process could comply with the IMA-SP process:

• it would allow to better manage the numerous dependences existing between the On Board Software functions.

• it would allow to improve the aeronautical IMA weak points described in this document.

• it would make the IMA-SP process compatible with [SAVOIR-FAIRE] (see section 8.1).

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


5.3 TSP versus Component Based System Engineering �� partition allocation trade-off.

Section 04 has presented a pure TSP approach as it has been applied in Aeronautical domain until today. It also briefly presented a pure component based approach with the AUTOSAR example. This two approaches of managing a complex system have both advantages, and disadvantages: TSP as in aeronautical IMA ensures strong partitioning, and strong independence between sub systems, but the global view of the system is hard to obtain. In the other hand, AUTOSAR process allows to have a good view of the global system (seen as interacting components), but it seems some timing issues are hard to manage during implementation.

The IMA-SP process we defined in section 5.2 aims to be derived from the aeronautical IMA process. However, it has been seen in 5.2.3 and 5.2.4 that integrating solutions from Component Based System Engineering (CBSE) could allow to handle the limitation of pure TSP presented in section 4.4. The resulting IMA-SP process that is being defined in this document is compatible with both pure TSP, and CBSE approach (vertical, or horizontal approach). The IMA-SP product may benefit from both approaches, and for that reason, it inherits from both approaches. This inheritance can be of different kind: for instance, a project where the major part of the system comply with TSP and a minor part comply with CBSE will be on the left hand of the scale. And a project where TSP is applied for Payload and where CBSE is applied for OBSW would be in the middle of the scale. This is illustrated in the Figure 10Figure 9:

Figure 109: IMA-SP process is in between TSP and CBSE

It is interesting to see that not only the process is compatible with both approaches, but also that only one activity in the IMA-SP process has impact on the nature of the approach: the partition allocation activity.

This activity consists in a trade-off where components of the system are allocated to partitions. This allocation is performed with a large number of criteria. Some of those criteria have opposite effects, and will result in a different approach.

In all cases, the Partitioning Activity which consist in making groups of components to compose partition shall ensure that:

� inside one partition, all software components have the same criticality.

� inside one partition, there is no confidentiality issue.

� the partition remains under the responsibility of one Application Supplier (for qualification purpose). See section 7.4

� if there is no coupling between applications then applications do not need to co-exit in the same partition.

Note: For pure Component Based System Engineering, refer to the CORDET study.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Here is a non-exhaustive list of criteria that can be invoked in the partitioning activity:

Table 8 : criterion for partitioning activity

Criteria Description Impact on the System

Reusability If an application is designed to be reused alone, all its component shall be segregated into a set of partitions. Those partitions shall not host components from other suppliers.

This leads to a TSP system

Separation of concerns If it is required (contractually) that an application supplier do will not interact with other suppliers, all its applications shall be segregated into a dedicated set of partitions.


Integration effort In order to minimize the integration efforts, each partition shall be qualified by a unique Application supplier.


Managerial issue In a schema with Application suppliers and third-part suppliers, all components provided by third-part suppliers shall be allocated into Application suppliers partitions.

Undefined.

Scheduling optimization In order to optimize scheduling, and reduce cost of switching context between two partitions, components with compatible timing requirements4 or needing synchronization should be allocated in the same partition

This leads to a CBSE system.

Communication optimization In order to reduce the number of communication channels in the IMA-SP system (thus to minimize configuration efforts, and communication timings), different applications that need to communicate could be allocated into the same set of partitions.

This leads to a CBSE system.

The trade-off between all these criterions will give the nature of the system: either a pure TSP system, either a pure CBSE system, or a mixed between both.

4 Compatible timing requirements can be identical periods (no need for partition switch), or hard deadlines (shall be handled at a MIF (or MAF) start to avoid offset in partition scheduling).

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


5.4 Standards for the IMA-SP process

The IMA-SP process will be deployed in a domain where many standards are already used and should logically be compliant with those standards.

The European Cooperation for Space Standardization (ECSS) has the mission of defining a set of coherent standards applying to the space domain, in order to keep homogeneity across Space Organizations (Agencies, Industry). These standards address space project management (ECSS-M-00), space product assurance (ECSS-Q-00), and space engineering (ECSS-E-00).

The Space Engineering standard is a series of standards covering all the essential areas of engineering within space projects. The system engineering standard applies for the overall system engineering process (ECSS-E-10), while specialised standards address specific engineering disciplines such as Electrical and Electronic (ECSS-E-20), Mechanical (ECSS-E-30), Software (ECSS-E-40), Communication (ECSS-E-50), Control Systems (ECSS-E-60), and Ground Segment (ECSS-E-70).

Additionally to these standards, the IMA paradigm comes with its own standards from aeronautical domain. The Aeronautical Radio, Incorporated (ARINC) is in charge of publishing a series of standards used in the aeronautical domain.

A set of standard covers some aspects of the Integrated Modular Avionic, such as Design Guidance for IMA (A651-1), IMA Packaging and Interfaces (A650), Avionics Software Management (A652), Avionics Application Software Interface (A653 P1-P2-P3), Backplane Data Bus (A659), …

Complementarily to ARINC standards (which are specification for products), other documents consider certification issues, such as the DO-178B and DO-297.

DO-178B, published by RTCA Inc. covers Software Considerations in Airborne Systems and Equipment Certification, and D0-297 covers IMA Development Guidance and Certification Considerations. It defines the roles and responsibilities within the IMA process, and the incremental acceptance of IMA systems in the certification process.

As already said before, space domain can not afford to deploy an IMA process from scratch, and must rely on aeronautical technology and experience.

5.5 Conclusion

The comparison of the aeronautical and space domains, and the adaptation of the IMA paradigm to spacecraft development have shown that an IMA-SP process could be defined to apply partitioning philosophy in the space domain.

In this document, we proposed to adapt the IMA process on the following aspects:

• Product perspective: main differences are in the number of elements and their respective capabilities.

• Role repartition: modules providers would be replace by a unique IMA-SP Platform supplier. This one can rely on third part suppliers (SEP suppliers …).

• Global approach: vertical approach will be replaced by an horizontal approach, and a component oriented process will be introduced.

• Acceptance process: Although a partition may host components from different suppliers, partition acceptance remains of the responsibility of a unique Application Supplier.

To accommodate the resulting IMA-SP process to the space domain, some changes will be needed, mainly in current state-of-the-art of system-software engineering, and in hardware and software lifecycles.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


6 CHANGES NEEDED IN SPACE DOMAIN TO

ACCOMMODATE THE IMA-SP PARADIGM.

This section briefly analyses the foreseen evolution of development process in space domain, if an IMA-SP paradigm is applied, and the impact on current standards.

6.1 Evolution of development process : from today’s State-of-the-Art to targeted IMA-SP process

6.1.1 Today’s approach

Space context nowadays is very similar to aeronautical domain in the mid-90’s with the federated architecture of aircraft systems. The current approach being used is illustrated in Figure 11Figure 10:

Figure 1110: today's system organization

Spacecraft functionalities are implemented by several actors on independent modules. Those modules communicate through a physical Network. The different module types can be:

• Central Software Module

• Payload Module

• Equipment Modules (Star Tracker, …)

The global system has Time and Space Partitioning characteristics (due to physical isolation of the modules), and the interaction between functionalities are physical buses, and standardized protocols, as illustrated in Figure 12Figure 11

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Figure 1211: Today's System global view

This approach has two major limitations:

• It is not possible to apply Time and Space partitioning inside a module. This means that there is no mean to protect an application from other applications failures on a same Unit.

• Each unit possibly hosts some identical functions with different implementation, such as drivers, communication component (PUS services), FDIR strategy, ….

These two limitations reveal a need for applying a Time and Space Partitioning approach.

6.1.2 Introducing TSP.

The scope of this study is to define a development process to apply Time and Space Partitioning paradigm to Space domain. As it has been already widely discussed in previous sections, the architecture of a TSP system aims to gather several independent functionalities within a same module, preserving isolation properties, and protecting against fault propagation. This is illustrated by Figure 13Figure 12. In this figure, the dotted red line represents the separation between the TSP platform, and the Applications.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 1312: TSP architecture in Space context

With this architecture, the global system view becomes different: TSP properties are not architectural any more, but are provided by the platform to several applications hosted in independent partitions. Figure 14Figure 13 illustrates this point of view.

Figure 1413: TSP system global view

6.1.3 Standardization and Integrated Modular Avionics.

Going further in abstraction, IMA paradigm requires that the IMA-SP Platform on its own do not provide any spacecraft functionality. This means that the platform shall include all System and Application Support Services. Figure 15Figure 14 illustrates this concept

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Figure 1514: IMA-SP architecture

With this IMA-SP platform, the IMA-SP System can be seen as several Applications communicating to one-another, independently of the platform. In this case, the partition concept is still visible from a functional point of view, since applications are still isolated in independent partitions. This IMA-SP Platform requires to standardize all Support Services as well. Figure 16Figure 15 illustrates this point of view:

Figure 1615: IMA-SP system global view

6.1.4 Component based engineering.

The last step into abstraction is performed when the functional part of the system is completely separated from the platform. The difference between this step and the previous

IMA-SP/D08 issue 1.3 15/04/2011 of 86


one (IMA-SP Platform) consists in the fact that partition level is included within the platform itself.

Figure 1716: Component based Engineering : Platform and components

This gives a high level of abstraction, and allows to consider the system with the simplest view: functional applications communicating one-another. The system is not seen as a platform separated from partitions, but it is seen as simple applications. All TSP properties, intercommunication capabilities and non-functional properties (as well as FDIR, I/Os …) are handled by the platform.

Figure 1817: component based engineering : system global view

This approach, obviously, can only be managed with robust tools, and very high level of standardization of all parts of the system.

6.1.5 IMA-SP study assessment

The previous sections aimed to show the evolution of the avionics in Space domain. Today’s architecture (6.1.1) can be improved by introducing Time and Space Partitioning (6.1.2).

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Another improvement is a deeper integration of avionics applications into the system. This is the targeted IMA-SP study (6.1.3). In near future, the integration will be done up to component level (6.1.4), with an associated toolset, and with a high level of standardization.

In the scope of this IMA-SP study, the objective is to define an approach that could produce a system compatible with component based approach.

As such a system would require a complex set of tools, and a high level of standardization, the IMA-SP development process in this document deals with a simple IMA-SP system that refers to the one discussed in section 6.1.3.

As [D01] indicates, the IMA-SP platform in this context includes Support Services, that are space specific services, as well as system partition-s. Although this is a general architecture, it seems hard to define a standardized IMA-SP platform that will meet the needs of all spacecrafts of all space product families. For instance, an IMA-SP platform for telecommunication spacecrafts would be certainly very different from an IMA-SP platform for observation or scientific spacecrafts.

From this point of view, the part of an IMA-SP system that could be common to several product lines is reduced to the TSP platform as it is defined in section 6.1.2. This element of the targeted IMA-SP system will be standardized in the scope of IMA-SP study. (by [D10] ).

6.2 Assessment of IMA-SP process against ECSS-E-ST-40

The ECSS-E-ST-40 Standard defines the principles and requirements applicable to space software engineering, and is applicable to all the elements of a space system, including the space segment, the launch service segment and the ground segment.

The IMA-SP process may have an impact on several aspects of this standard. For example, the incremental process, or the independent qualification of partitions may need new reviews which have to be defined.

The following table describes the impacts of the IMA-SP process on all the points covered by this standard:

Table 9: Impact of IMA-SP process on ECSS-E-ST-40C

ECSS-E-ST-40C SPACE ENGINEERING SOFTWARE

Section Item Impact of the IMA-SP process

4.2.2 Software related requirements process

No impact

4.2.3 Software management process No impact

4.2.4 Software requirements and architecture engineering process

No impact

4.2.5 Software design and implementation engineering process

No impact

4.2.6 Software validation process No impact

Overview of space system software engineering processes

4.2.7 Software delivery and acceptance process

No impact

IMA-SP/D08 issue 1.3 15/04/2011 of 86


4.2.8 Software verification process No impact

4.2.9 Software operation process No impact

4.2.10 Software maintenance process No impact

5.2.2 Software related system requirements

analysis

No impact

5.2.3 Software related system verification No impact

5.2.4 Software related system integration and

control

No impact

Software related requirements process

5.2.5 System requirements review No impact

5.3.2 Software life cycle management The software life cycle defined and followed by the supplier shall be compliant with IMA-SP process

5.3.3 Joint review process No impact

5.3.4 Software project reviews description IMA-SP may impact on the sequential approach, introducing an incremental approach.

5.3.5 Software technical reviews description

No impact

5.3.6 Review phasing No impact

5.3.7 Interface management No impact

5.3.8 Technical budget and margin management

This is linked to IMA-SP resource allocation.

Software management process

5.3.9 Compliance to this Standard No impact

5.4.2 Software requirements analysis No impact

5.4.3 Software architectural design No impact

Software requirements and architecture engineering process

5.4.4 Conducting a preliminary design review

No impact

5.5.2 Design of software items This activity is linked to IMA-SP resource allocation. New reviews may be introduced.

If needed, this activity also produces component stubs.

Software design and implementation engineering process

5.5.3 Coding and testing No impact

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


5.5.4 Integration This activity may require external component stubs.

5.6.2 Validation process implementation No impact

5.6.3 Validation activities with respect to the

technical specification

No impact

Software validation process

5.6.4 Validation activities with respect to the

requirements baseline

No impact

5.7.2 Software delivery and installation No impact

Software delivery and acceptance process

5.7.3 Software acceptance Section 5.7.3.3 may be modified (for IMA-SP partitions, is executable code generation from source code always done at customer level?)

5.8.2 Verification process implementation No impact

Software verification process

5.8.3 Verification activities IMA-SP process may use configuration tables (5.8.3.1)

5.9.2 Process implementation No impact

5.9.3 Operational testing No impact

5.9.4 Software operation support No impact

Software operation process

5.9.5 User support No impact

5.10.2 Process implementation No impact

5.10.3 Problem and modification analysis No impact

5.10.4 Modification implementation No impact

5.10.5 Conducting maintenance reviews No impact

5.10.6 Software migration No impact

Software maintenance process

5.10.7 Software retirement No impact

This section will also provide an analysis of the impact of IMA-SP process on DRD documents.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


6.3 Assessment of IMA-SP process against ECSS-M-ST-10

The project organization is defined in ECSS-M-ST-10

Here again, the IMA-SP process may introduce some changes in the project organization (initial repartition, …). This is described in the following table.

Table 10: Impact of IMA-SP process on ECSS-E-ST-10C

ECSS-M-ST-10C SPACE PROJECT MANAGEMENT

Project planning and implementation

Section Item Impact of the IMA-SP process

4.1.3 Availability of and need to develop new technologies

no impact

4.1.4 Availability of and need to reuse existing equipments/products

compatible

4.1.5 Availability of and need for human resources, skills, and technical facilities

no impact

4.1.6 Risk assessment no impact

4.1.7 Development approach no impact

4.1.8 Project deliverables no impact

4.1.9 Customer requirements and constraints, Invitation To Tender (ITT)

no impact

4.1.10 Project Requirements Documents (PRD)

no impact

Project planning:

4.1.11 Project management Plan no impact

4.2.2 Organizational structure no impact

4.2.3 Communication and reporting no impact

Project organization :

4.2.4 Audits no impact

4.3.2 function tree no impact

4.3.3 specification tree no impact

4.3.4 product tree no impact

4.3.5 Work Breakdown structure (WBS) no impact

4.3.6 Work package (WP) no impact

Project breakdown structures

4.3.7 Organization breakdown structure (OBS)

no impact

Project phasing

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


4.4.2 Relationship between business agreements and project phases

?

4.4.3 Project phases

4.4.3.2 Phase 0 (mission analysis and needs identification) and Mission Definition Review (MDR)

no impact

4.4.3.3 Phase A (Feasibility) and Preliminary requirements review (PRR)

no impact

4.4.3.4 phase B (preliminary definition), System Requirements Review (SRR), and Preliminary design review (PDR)

no impact

4.4.3.5 Phase C (detailed definition) and Critical design review (CDR)

System Integrator, IMA-SP platform supplier, and application suppliers; May have impacts! Parallel activities in IMA-SP, and not sequential.

4.4.3.6 Phase D (Qualification and production), qualification review (QR), acceptance review (AR), and operational readiness review (ORR)

System Integrator, IMA-SP platform supplier, and application suppliers; May have impacts! Parallel activities in IMA-SP, and not sequential.

4.4.3.7 Phase E (Operation/utilization), Flight readiness review (FRR), launch readiness review (LRR), Commissioning result review (CRR), and end of life Review (ELR)

System Integrator, IMA-SP platform supplier, and application suppliers; No impact?

4.4.3.8 Phase F (Disposal), with mission close-out review (MCR)

no impact.

4.4.4 project specific reviews no impact.

5.1.2 Requirements on customers no impact.

5.1.3 Requirements on suppliers no impact.

5.2.1 organizational structure no impact.

5.2.2 Communication and reporting no impact.

Project planning

5.2.3 Audits no impact.

Project breakdown structures

no impact.

Project phasing sequential may be replaced by incremental

IMA-SP/D08 issue 1.3 15/04/2011 of 86


of 86 15/04/20111 IMA-SP/Do8 issue 1.3


7 IMA-SP PROCESS DETAILED DESCRIPTION

This section defines the IMA-SP development process. This process involves different actors, performing many concurrent activities, and using many tools. All these elements are presented in details in the following paragraphs.

7.1 Actors and roles

The role definition for the IMA-SP process is based on the ones defined in the aeronautic domain but tailored to the specific space constraints (see section 4.3.2). To be more specific, the envisaged sharing of roles for the space industry is the following:

� System Integrator: Responsibility of the satellite prime integrator.

� System Architect: Currently and in the near future the satellite prime integrator will also have this responsibility.

� IMA-SP Platform Supplier: Currently and in the near future, the IMA-SP Platform will be under the responsibility of the satellite prime integrator with a SEP supplier as subcontractor.

� Application Suppliers: Role shared across different subcontractors and the satellite prime according to the application and the project.

7.2 Interfaces between the various roles

To manage the complexity of an IMA system, where many actors share the same resources, it is essential to clearly define the interfaces between the different roles in the development process.

Figure 19Figure 18 illustrates the dependences between the roles:

Figure 1918: Roles, responsibilities, and interfaces in IMA process

IMA-SP/D08 issue 1.3 15/04/2011 of 86


The System Architect defines the responsibilities of the different actors, and defines the high level system requirements, deciding the type of architecture.

The System Integrator has a key role in the IMA-SP process: he shall assist the System Architect to define the system, and to elaborate the requirements for the IMA-SP Platform and for Applications, coordinating Applications needs and IMA-SP Platform definition. The System Integrator is responsible to configure the system, and to negotiate with Application Suppliers the resource allocation. He also has the responsibility of verifying the feasibility of the system all along the development process. This verification can be virtual validation of the global system at the design phase (using models and efficient tools), validation of part of the system during integration, and validation of the entire IMA system at the end of the integration.

The IMA-SP Platform Supplier interacts with System Architect and System Integrator to specify, develop, configure, and verify the IMA-SP Platform. It may interacts as well with a SEP Supplier, and with Lower Tier Suppliers who provide Hardware nodes, and System/Application Services.

Several Application Suppliers interact with System Architect and System Integrator to specify, configure, and verify the different Applications. These applications can be developed by Application Suppliers or by Lower Tier Suppliers.

Each actor is bounded to the general organization with a contract. This contract defines what will be provided to an actor, and what this actor will have to produce.

Table 11 : contracts between all actors

System Architect

System Integrator (phase 1)

IMA-SP Platform supplier

Application Suppliers

System Integrator (phase 2)

is provided with …

- Customer needs.

- High level requirements

- Standards

- General architecture design

- IMA-SP Platform requirements

- Configuration of the IMA-SP Platform

- Standards

- Applications requirements

- Resource allocation for the application

- Toolset and IMA-SP Platform Simulator

- other application-s partition-s emulator-s if needed.

- Pre-qualified configured IMA-SP Platform

- Standards


- Pre-qualified Applications

has to provide

…

- High level requirements

- Selection of standards for the process.

- General architecture design

- Verified requirements

- IMA-SP Platform requirements

- Configuration of the IMA-SP Platform

- Applications


- Toolset and IMA-SP Platform Simulator

- Pre-qualified Application

- partition-s emulator-s, for qualification of Applications dependent on this one.

- Integrated qualified System

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


requirements

- Resource allocation for each application

In order to preserve confidentiality between parties (except with System Integrator), each actor only receives the inputs needed for its activity. The main issue is in the configuration data: the System Integrator is responsible for configuring the system, and to allocate resource, but shall only deliver to each part (IMA-SP Platform supplier and Application suppliers) the information they need. The System Integrator shall use efficient tool to keep configuration data consistent between all the applications.

7.3 Reuse process

It is an evidence that IMA-SP enhances the possibility of reusing blocks, due to the separation of functionalities into independent partitions. In IMA-SP development process, re-use can be applied at component, partition, and platform levels.

Re-use can refer to :

• The development of products that may be re-used in other projects.

• The re-use of already developed products.

7.3.1 Development of products to be reused

The development of products to be reused concerns only the system elements that can be qualified : either the IMA-SP platform, or a partition. But from a system point of view, the reuse of an application is a more relevant issue.

If it is identified at the beginning of the IMA-SP development process that an application shall be developed in order to be reused in an other project, this application shall be put in an independent partition (or divided in functions put in a set of partition). The partition acceptance process will allow the reuse of the partition(s), thus the re-use of the application.

This has to be a high level requirement, to be taken into account during resource allocation and system feasibility analysis.

7.3.2 Reuse of existing products

Regarding the second aspect, a full partition or platform re-use shall be decided at the very beginning of the development process, whereas a component reuse may be decided later. This steps are included in the development process activities descriptions.

7.3.2.1 Re-use of an application

As seen in 7.3.1, speaking of “application re-use” is not relevant, since an application is implemented in a qualified partition, or in a set of qualified partitions. To re-use an application thus means to re-use all the qualified partitions implementing this application. Another way of “re-using” an application is given in 7.3.2.4.

7.3.2.2 Re-use of a partition (or a set of partitions)

It must be understood that the decision to re-use a full partition has large impacts on the global architecture and on system requirements. Partition re-use shall be defined as a high level requirement, as it will bring many other constraints such as the resource allocation. Indeed, a qualified partition shall be re-used only if the resource allocated to this partition (CPU, scheduling, memory, communication…) in the new system are in the ranges allowed by qualification.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


It shall be noticed that reusing a partition (belonging to an application) brings a lot of constraints for the system and shall be defined as a high level requirement : the partition can only be re-used for the same environment it has been qualified for. A partition is qualified for a given IMA-SP platform (hardware nodes, SEP, …), with a given configuration (scheduling, communication …), The reuse of a qualified partition forces the reuse of the platform it has been qualified on, and forces also a part of the system configuration: a qualified partition shall be re-used only if the resource allocated to this partition (CPU, scheduling, memory, communication…) in the new system are in the ranges allowed by qualification. This is the reason for analyzing partition re-use at the very beginning of the development process.

7.3.2.3 Re-use of IMA-SP platform

The re-use of the IMA-SP platform is an obligation if the re-use of a partition has been decide. But the platform can also be a reused element of the system even if there is no partition reuse ( this is why the partition reuse analysis is performed before platform reuse analysis).

The IMA-SP Platform elements might be the easiest product to re-use inside a spacecraft family. This has to be considered during IMA-SP Platform development.

7.3.2.4 Re-use of components

An application being composed of component, another level of re-use is at component level.

Component re-use have no impact on the resource allocation and would be easier to apply during an IMA-SP development process. Components are not qualified during the IMA-SP development process, but are validated with regard to some specification. If a part of an application specification can be fulfilled by a Component Of The Shelf (COTS), the application development would be faster.

An extended reuse of components can lead to what can be called “application re-use”. If an application is implemented using only validated COTS, there is no more development to perform. However, those components have to be dispatched into partitions by the Partitioning activity, and the resulting partition-s hosting those components has (have) to be to be configured (Resource allocation activity) before being qualified.

7.3.3 Constraints

Re-use process is strongly linked to the standardization issue, applying to applications (interfaces), platform (capabilities, interfaces), and tools (development tools or validation tools).

Re-use constraints are also very different if we refer to TM/TC management, AOCS, Heat regulation, and battery management or to FDIR and data handling system.

7.4 Acceptance process

IMA-SP concept allow to reduce the effort for system integration, as it relies on preliminary independent verification of all system’s elements. Verification of the integrated system only applies to interactions between pre-qualified products, what considerably decrease the number of verification tests.

Following the incremental acceptance process defined in [RD-01], the IMA-SP acceptance process consist of six tasks as illustrated in the following figure:

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Tasks 1 and 2 are performed in parallel, due to the iteration between IMA-SP Platform and SW/HW development. The qualification credits resulting of these two activities are inputs of task 3 which qualifies the integration of the pre-qualified products. The resulting qualified IMA system is then integrated into the Spacecraft during AIT. This Integration shall be qualified as well, and is the purpose of task 4.

If a change is needed in the IMA-SP Platform (during development) or in an application (during development or during operation) – task 5 – the qualification of the impacted product has to be performed again (and only the impacted product).

In case a system element is reused (IMA-SP Platform or Applications), the applicability of previous qualification shall be verified for the current system. This is done in task 6.

Detailed description of tasks:

Task 1: IMA-SP Platform qualification consist of the validation of every part of the platform (hardware nodes, SEP Kernel and guest O/Ss, Application/System support services ….), and of the qualification of the integrated IMA-SP platform.

Task 2: Application qualification consists of the qualification of all partitions that host a part of the application. If one of the application’s partitions hosts also a component that is not produced by the application supplier, this component becomes of the responsibility of the partition owner. This case has to be properly managed during Partitioning Activity.

The product that is qualified is a partition software image. This software image shall be integrated as is in the global system, without need for compilation. A qualified partition can be considered as a black box.

Task 3: IMA-SP system acceptance consists of the integration of all qualified partition onto the qualified IMA-SP platform. The integration effort may be reduced: in theory, no tests are needed to prove that the system prevent for fault propagation, since this is a property of the IMA-SP platform. However, some functional verifications shall be performed for dependent Applications. At this stage of the qualification process, the test environment is simulated on avionics test benches.

Task 1 : IMA-SP Platform acceptance

Task 2 : Application acceptance (HW & SW)

Task 3 : IMA system acceptance

Task 4 : Spacecraft acceptance.

Task 5 : Change in Platform or Application.

Task 6 : re-use of IMA Platform or Applications

Hardware nodes

SEP Kernel

RTOS personalities.

Support services

App. software Specific HW

IMA system Spacecraft Integration

Parallel Activities

ACCEPTANCE CREDIT

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Task 4: The qualified IMA-SP system shall be integrated in the real spacecraft. The spacecraft goes through a test process, and IMA-SP system shall be verified at the end of this process. Note that this activity is nor performed or required when the spacecraft is already launched.

Task 5: This activity is performed when a change is needed in the IMA-SP platform, or in an hosted Application. The modification is performed off-board, tested and qualified (task 1 or 2) before being re-integrated in the system. If the spacecraft is in its operating phase, the re-integration of the modification shall be performed following On-Board Software Maintenance strategy.

Task 6: The re-use of an element of the system is covered by section 7.3.

7.5 Tools description

To handle the complexity of the IMA-SP development process, a set of efficient tools is required. This chapter briefly presents the tools introduced in the process. [D011] details the toolset of the IMA-SP process, and define tools specification.

7.5.1 Partitioning / Resource allocation/ configuration tool

This tool will allow the System Integrator to define the partitions (i.e. to dispatch the functions and responsibilities into the different partitions to obtain a set of independent partitions with their respective requirements). This tool will also help to allocate IMA-SP Platform resources to each partitions, and to define the configuration of the system.

7.5.2 System feasibility verification tool

This tool is needed to verify the feasibility of the system from the design step to the integration step. It determines the feasibility of the system using the requirements of the individual partitions (description of resource needs, communication needs, functional and non-functional requirements), the configuration of the platform (architecture, capabilities, characteristics), and the output of the Hardware/ Software mapping.

7.5.3 Software image configuration tool

This tools is used by the system integrator. It takes the different software elements (partition software and platform core software) and produce the software image to be integrated on the hardware. It can be used at different levels:

• To integrate one single partition on the platform to test, validate and verify it.

• To integrate several partitions sharing communication resource to test, validate, and verify their coupling.

• To integrate the global system, and to verify it.

7.5.4 Cross development tools

During development activities, IMA-SP platform supplier and Application Suppliers will use cross development tools (compiler, linker, debugger, simulators, monitoring tools …).

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


7.6 Overall process5

Figure 2019 : Overall sequencing of process activities

5 This diagram emphasis the parallelism of development activities (Platform, Applications …). However, it shall be noticed that a change in Platform specification may impact Partition specification as well . This dependence is handled and managed by System Integrator, so there is no direct interaction between those activities.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


7.7 Description of activities

This chapter presents the different activities, by dependency order with regard to the process workflow. In the following, “component” refers either to a hardware component (of an application or of the platform), or to a software component (within a partition, or within the IMA-SP Platform : SEP kernel, execution framework …).

7.7.1 Produce system specification

This activity is producing the high level system specifications.

Figure 2120 System specification

This activity possibly includes standard requirements.

7.7.2 Analysis and evaluation of partition reuse

Once the system is specified at a high level, partition reuse shall be analyzed. The first step is to identify one or more already qualified partitions that fulfill part of the system requirements6 (see section 7.3).

These partitions have to be evaluated against criteria such as qualification level, documentation, tools and support …

If one or more partition is selected to be reused in the system, the system high level specifications are split into two packages: specifications covered by reused partitions, and other specifications.

6 Application Suppliers are part of the RFQ and RFI process and in a way present during the trade-off.

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Figure 2221 partition reuse analysis and evaluation

7.7.3 Analysis and evaluation of platform reuse.

Once the system is specified at a high level, and partition reuse analyzed, the platform reuse is analyzed as well7.

If at least one partition reuse has been decided during the previous activity, platform reuse is mandatory. In case reused partitions are qualified for more than one platform, a platform analysis and evaluation is performed. If the reused partitions are qualified for only one (unique) platform, this platform shall be selected for the project.

If no partition reuse has been decided, a Platform reuse can be performed only with regard to the system high level specification.

In case a platform analysis is performed, the first step is to identify one or more already qualified platform that fulfill part of the system requirements (see section 7.3).

These platforms have to be evaluated against criteria such as qualification level, documentation, tools and support …

If a platform is selected to be reused in the system, the system high level specifications are split into two packages: specification related to reused platform, and remaining specification.

7 Platform Suppliers are part of the RFQ and RFI process and in a way present during the trade-off

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 2322: Platform reuse analysis and evaluation

7.7.4 Specify system functional requirements

This activity is not performed for reused partitions, or for reused platform. It consists in specifying the functional requirements independently of the system architecture.

Using the system specifications, the system Integrator performs a functional breakdown, and elaborates the functional requirements of the system.

Figure 2423: System functional Requirements specification

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


7.7.5 Specify system non-functional requirements

This activity consists in specifying the non-functional requirements of the system, independently of the system architecture. Using the system specification, the System Integrator elaborates the non-functional requirements of the system.

Figure 2524 System non-functional requirements

7.7.6 Requirements Allocation on logical entities

7.7.6.1 Description of the activity

In order to be allocated on different components (HW or SW, either for Applications, IMA-SP Platform, or equipments), the functional requirements has to be allocated to different logical entities. For example gathering all the GNC related requirement into a GNC logical component. A logical component can be seen as a “major function” of the system.

This will permit first to explicit the exchanges between these components (for example between the GNC and the mode management).

Logical components do not induce any particular implementation, there are abstract components that realize a logical groups of related requirements.

Figure 2625 requirements allocation on logical entities

IMA-SP/D08 issue 1.3 15/04/2011 of 86


7.7.6.2 Description of the outputs

This activity produce a set of RB documents split into different logical components. These components are Applications, IMA-SP Platform or decentralized units. Applications will later be dispatched within different partitions.

7.7.7 Analysis and evaluation of component reuse

Once functional and non-functional requirements are defined (for elements of the system which are to be developed), component reuse shall be analyzed.

Component level does not exist in aeronautical IMA paradigm. Thus, this activity is not present in the aeronautical IMA process. But it is required here in order to keep the IMA-SP development process compatible with a component based approach. As presented in section 5.2, this is the only way to have a global view of the system from the design phase to the integration phase.

The first step is to identify one or more components that fulfill part of the system requirements. For instance, if the IMA-SP platform has to be developed, the Platform Supplier along with the System Integrator will identify and select some components of the platform (SEP, hardware nodes …) that match with functional and non-functional requirements allocated to the IMA-SP platform, and that could be reused. And if an application has to be developed, the Application Supplier, along with the System Integrator, will identify and select some components (HW or SW components) that match with functional and non-functional requirements allocated to this Application, and that could be reused.

Components have to be evaluated against criteria such as maturity, integration effort (API …), documentation, tools and support …

If one or more component is selected to be reused in the system, the functional and non-functional requirements are split into two packages: requirements related to reused components, and remaining requirements.

Figure 2726 Reuse analysis and evaluation

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


7.7.8 Hardware/Software Trade-off

This activity does not apply for reused components. For parts of Applications or of the IMA-SP platform that has to be developed, requirements allocated to each element shall be divided into two packages: requirements applying to software, and requirements applying to hardware. Application Suppliers (fro Applications) and Platform Supplier (for IMA-SP platform) will perform a HW/SW trade-off to determine for each requirement if it will be implemented in software or hardware.

Figure 2827: HW/SW trade-off

7.7.9 Components specification

This activity does not apply to reused partitions or reused components. Each component implementing one or more functions in the system has to be specified independently of other components, but strictly respecting the functional and non-functional requirements allocated to it (including standards).

Figure 2928 Components specification

7.7.10 Partitioning and Resource Allocation

This step will permit to perform the HW/SW mapping, the partitioning activity, and the configuration of the system. Indeed in this step the logical components are mapped on

IMA-SP/D08 issue 1.3 15/04/2011 of 86


physical entities (Applications on IMA-SP platform or decentralized units), and the system is partitioned before being configured.


This activity is central in the IMA-SP process and consists in linking the hardware architecture with the logical software components. The different logical software components (including reused components and components of reused partitions) will be mapped on physical nodes. The exchanges between components are taken into account during this activity. Depending on this mapping, a preliminary sizing, and timing budget is deduced.

Based on this, the Partitioning activity will consist in allocating the components into partitions. This activity is described in section 5.3. The resulting software is divided in partitions. This activity produces a very detailed description of each partition, with the related requirements, and the sizing and timing budgets of the component of that partition.

Next, The resource allocation activity makes explicit the exchanges between the partitions, based on the exchanges between the components. Then, the IMA-SP communication ports will be deduced. This activity will allocate CPU time and Memory to the partitions, and will configure the whole IMA-SP system.

Figure 3029: Partitioning and resource allocation activity


� HW/SW mapping: this artifact (possibly a model) will map the logical software components onto physical nodes. Detailing also the interactions between the physical components.

� Sizing and timing budget : this document will produce the initial allocation for each software components in terms of memory and CPU allocation. This will also provide for

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


each components required by a given component assumption on these figures to be taken into account during the development of the component.

� Partition description: this artifact (possibly a model) will define partitions, with the associated requirements, so it can be an entry for the resource allocation activity. This definition is independent of the final partitioning kernel selected.

� Global System Configuration : This artifact (possibly a file of xml format), will define the whole system configuration. These document is only accessible to the System Integrator for confidentialities issues.

� Partial System Configuration : These artifacts (possibly one xml file for each application supplier), will define a part of the system configuration, related to a specific application. A partial system configuration is an extract of the global system configuration that is provided to Application Supplier for the configuration of the platform during application development and unitary validation.

7.7.11 Assess system feasibility


Once the partitioning and resource allocation has been performed, this activity will check by static analysis or simulation that the foreseen system configuration is fulfilling all the non-functional constraints of the system.

The activity will permit to check in particular the following non-functional properties :

� Timing requirements (the proposed scheduling definition fulfill the non-functional timing properties)

� Isolation of failure

� Communication requirements (both in terms of capabilities and in terms of performances) are fulfilled by the partitioning and the hardware schemes selected.

� Bandwidth of physical networks

� Memory allocation between all the partitions

� …

But also project management oriented properties like :

� Validity of the foreseen sub-contracting scheme

� Isolation of variations (to limit impact if a change occurs in the system)

� Incremental delivery requirements

� Maintainability of the system

� …

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 3130 system feasibility assessment


The verification results include:

• Timing analysis: WCET, CPU availability,

• Communication analysis:

• Bandwidth margins

• Memory margins

• Feasibility results (OK or NOK)

At this stage of the process, if the system is not feasible, different actions are to be done:

• Re-configure the system

• Reallocate software components in partitions. Another set of partition may optimize the system.

• Revisit the hardware/software trade-off.

• Re-specify the IMA-SP platform to comply with Application needs (increase hardware resources, network, …).

• Re-specify the whole system.

Once the system is feasible, and margins are sufficient to accept small software requirement changes and expected evolution of some elements of the system, the development of each element can be started.

7.7.12 Procurement

The development process also include the procurement activity, at different levels. Application Supplier, or IMA-SP Platform supplier can need to procure a full qualified partition, a full qualified platform, or already existing components (hardware or software). This is done during the procurement activity.

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Figure 3231: Procurement activity

7.7.13 Components development

This activity is not performed for reused components, reused application, or reused platform. For other elements, this activity is common to all elements of the system (applications and platform). A component can be a hardware or software component belonging to an application or to the IMA-SP platform. Note that an application is generally composed of several components. Application development is done when all components of this application are developed, and when their integration is completed. IMA-SP platform is also composed of several components ( SEP, hardware modules …). The IMA-SP development is completed when all components of the platform are developed, and when they are integrated together.

The component development activity in this process include the validation of components. This validation ensure that a component implementation is conform with its specification.

It can be required that an Application Supplier also provides an emulator of its application partition-s (an application may come within one ore more partitions), if this is needed for other application qualification.

Figure 3332: Components development

7.7.14 Toolset development

IMA-SP Platform Supplier is also responsible for providing Application Suppliers some tools needed for developing and testing applications.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 3433: toolset development activity

7.7.15 IMA-SP platform simulator development

In addition to the toolset, and to the real platform, IMA-SP Platform Supplier has also to develop a simulator to be provided to Application Suppliers for development and test activities.

Figure 3534: platform simulator development activity

7.7.16 IMA-SP Platform Integration

When all components (hardware and software) of the platform are ready (both developed and reused components), the IMA-SP Platform Supplier integrate the IMA-SP platform.

Figure 3635: Platform Integration

7.7.17 Platform Acceptance

The IMA-SP platform supplier is responsible to verify the properties of the IMA-SP Platform, composed of the following elements:

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


- The System Executive Platform (providing standard API with the TSP Abstraction Layer) and (eventually) the RTOS personalities within partitions (could be COTS).

- The hardware node(s), low level drivers, BIOS component, and network issues.

- The System/Application Support Services, that are space specific services.

Figure 3736: Platform acceptance activity

The IMA-SP supplier will deliver to each Application Supplier a Qualified Platform to allow application qualification.

The IMA-SP supplier will also deliver to the System Integrator a Qualified Platform for the Integration activities.

7.7.18 Unitary Partition validation

This activity does not apply to reused partitions, since they are assumed to be already validated.

Each (not reused) partition composed of one or more components (included reused components) is tested and validated separately, possibly using a simulator of the platform., and emulators of dependent partitions. The partition is valid when all functional requirements and non-functional requirements are completed.

When the platform supplier is able to provide the SW developer a real platform (HW and SW core), the integration of the SW partition is performed on this real platform. If the partition needs to communicate with other partition or element of the system, these communications are simulated.

The partition unitary validation is performed by both the SW developer and the system integrator that provides support and tools for the integration of the partition onto the platform.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 3837: unitary partition validation

7.7.19 System feasibility verification

This activity also apply to reused partitions. The feasibility of the system composed of one partition and the platform is verified (timing and sizing budgets opposed to non-functional requirements). If it is feasible, it is assumed that there is no need to perform non-regression tests when the other partitions are added to the system.

If the system is found non feasible, the development process is stopped, and a new (optimized) HW/SW mapping is defined. If this new mapping is feasible, the partitions are modified, and the process is resumed. Else, the process has to restart from the HW and software specification.

It is clear that the system feasibility verification has to be done all along the development process, as soon as a requirement change occurs.

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


Figure 3938: System feasibility verification

7.7.20 Partition Qualification

All partitions that are not already qualified for the IMA-SP platform which is being used have to go through the partition qualification activity. This activity is detailed in section 7.4. This activity outputs a binary file which is the qualified partition. This Partition is ready for integration activity.

Note: a re-used partition already qualified for the IMA-SP platform that is being used does not need to be re-qualified.

Figure 4039: Partition qualification

7.7.21 System integration

Once the global system is feasible, the integration of all the elements of the system starts. The system integrator produces the software image from all software elements. This global software is then integrated on the platform.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


Figure 4140: System integration activity

7.7.22 System Acceptance

The integrated system is then tested and validated. At the end of the development process, the IMA-SP system is ready for being integrated in the spacecraft.

Figure 4241: system acceptance

7.7.23 System Integration in Spacecraft

The qualified system is then integrated into the spacecraft.

Figure 4342: System Integration in Spacecraft

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


8 IMA-SP PROCESS ASSESSMENT

8.1 Avionics Interfaces Standardisation Process (SAVOIR-FAIRE)

The SAVOIR-FAIRE document on reference architectures [SAVOIR-FAIRE] defines several steps of a component oriented process. A component is a self-contained software element consisting of its own data and logic, with well-defined connections or interfaces exposed for communication. A component is responsible for one or more functionality of the system.

The component is composed of:

• Facets which provide operation to client8 (application functionality);

• Receptacles which receive operation needed by the component;

• Event sink into which events consumed by the component may arrived ;

• Event sources which are for event production;

• Component attributes, which are configurable properties of the component.

Hereafter is a diagram of such a component (following the CORBA Component Model representation):

Figure 44: a typical Component

The steps of a component oriented process are detailed in the following sections:

� Definition of data types, event types and interfaces

� Definition of component types

� Definition of component implementations

� Definition of component instances

� Definition of component bindings

� Definition of physical architecture

� Allocation of component instances

� Creation of containers

� Creation of connectors

8 A client is the contractual user of the operations provided by the component.

IMA-SP/D08 issue 1.3 15/04/2011 of 86


8.1.1 data types

Data types are needed to type the data handled by components of the system. These types can be enumerated, alias, or basic types such as integer, double, string ….

8.1.2 event types

An event is a mean of communication between components. It is defined in a structure.

8.1.3 Interfaces

An interface is a contract that a component will have to provide, or that a component will need. It contains attributes, and operations:

- Operations are defined in interfaces. They have a name, take some parameters, and can return a value. Operations are defined using data types.

- Attributes: An interface can contain attributes, which are a data of a specified type. This data can be “read only”, or “read write”.

8.1.4 component types

Defining component types consist of defining interfaces, events, and attributes of the different components of the model

8.1.5 component implementation

The component implementation is the internal mechanisms (core code) that offer the functionality of the component. It produces the contract of the component type (providing or needing operations, and producing or consuming events).

There may be several component implementation of a single component type for different run-time environments (e.g. OS/hardware platforms, languages, etc.) or implementing different algorithms. But all component implementations should behave consistently.

8.1.6 component instances

Component instances are the component implementation used in a model of the system. There can be many instances of the same component implementation in the model.

8.1.7 component bindings definition

The different component of the model (component instances) have to be linked to one-another, and to external components. These links have to be defined in the model, as shown below:

Figure 45: component bindings

A link between two components is possible only if one produces what the other consumes (events), of if one provides what the other needs (operations).

That means that components are only bound to components with opposed contracts.

8.1.8 physical architecture definition

Software components will be integrated to a physical architecture. The physical architecture can be composed of several nodes (i.e. processing units).

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


8.1.9 component instances allocation

The different component instances are allocated onto the physical nodes of the architecture.

8.1.10 containers creation

The deployment consist of realizing the instantiation of the model. For each component instance, a container is generated, providing API to the component implementation. This container offers the synchronous or asynchronous communication means, and instantiate the component as a cyclic task if needed.

Thus, for each component instance in the model corresponds a component instance realization in the deployment, composed of the component implementation and its container.

Figure 462 : Component and its container

8.1.11 connectors creation

The connectors creation consists of implementing the links between the components.

Operation and event API called from the component implementation code are connected to the actual component realization in the component instance files.

Figure 473 Component implementation, containers, and connectors

8.1.12 Conclusion

The process to be defined for the IMA-SP has to be either derived or compatible with this one. This is very important to have a consistent process covering both software aspects (SAVOIR-FAIRE) and software partitioning aspects (IMA-SP).

IMA-SP/D08 issue 1.3 15/04/2011 of 86


8.2 Tailoring IMA-SP process for study purpose.

The proposed IMA-SP process is tailored for the study purpose.

During Phase 2 of IMA-SP study, two IMA-SP platforms have to be developed. These platforms are simple, as there is only one physical node. The main part of the platform to be developed is the System Executive Platform, composed of the Partitioning Kernel and the Guest Operating System. The SEP specification for use-cases are given in [D10].

At the end of phase 2, during phase 3, two parallel development processes (Use Case A and Use Case B) will adapt already existing applications on top of the provided IMA-SP platforms (resulting of Phase 2). Those applications are already specified and implemented, so they will need to be adapted to the IMA-SP context: major part of the applications can be re-used, and some other parts will need to be adapted, modified, and redesigned. The partitioning and resource allocation will be performed as explained in 7.7.10, and using the tools provided by IMA-SP platform suppliers.

The proposed development processes for phase 2 and phase 3 (Use-Cases) of IMA-SP study is presented below:

Figure 484 IMA-SP tailored Process for Use cases

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


8.2.1 Role repartition for Use-Cases :

8.2.1.1 IMA-SP platform development

Table 12 : Industrial organization for IMA-SP platforms development

IMA-SP Platform supplier

Processor Device Partitioning Kernel

Guest O/S

Platform 1 UPV/GTD TBD TBD XtratuM

hypervisor RTEMS

Platform 2 SYSGO TBD TBD PikeOS

microkernel RTEMS

Platform 3 GMV TBD TBD AIR RTEMS

8.2.1.2 IMA-SP System development

For the IMA-SP study Use-Cases, the role repartition will be the following:

Table 13: Industrial organization for IMA-SP Systems development

System Architect

System Integrator

IMA-SP Platform

Application Suppliers

ASTRIUM: (Central Software)

Use

Case A ASL ASL

Platform 1

GMV: I/O solution

TAS – F: (Central Software)

Use Case B

TAS - F TAS - F

Platform 2

SCISYS: (Payload

Software)

IMA-SP/D08 issue 1.3 15/04/2011 of 86


8.3 Impact of using the IMA-SP development process

*** TBW ***

This section will be written based on the experience of the use cases.

of 86 15/04/20111 IMA-SP/Do8 issue 1.3


9 CONCLUSION

*** TBW ***

This section will be written at the end of the study.

IMA-SP D08-11 - Process and role definition - 1.3

Documents

Transcript of IMA-SP D08-11 - Process and role definition - 1.3