COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 1 DEVELOPMENT PARTNERSHIP

Request for Information For FVI Models development partnership

Name and Function Date Signature

William Arrouy Prepared by TESCS FVI Product Owner

Romain Beteille Verified by TESCS FVI Numerical and Hybrid Team Leader

Serge Raina Approved by Head of TESCS

Yan Boulle Authorized by TESC Industrial Manager

Document type Keywords RFI FVI, Models, Development, Partnership The information disclosed in this document includes proprietary rights of AIRBUS DEFENCE & SPACE. By accepting this document, recipient agrees that neither this document nor the information disclosed herein, nor any part thereof shall be reproduced or transferred to other documents or used or disclosed to others for development, manufacture or any other purpose without formal authorization from AIRBUS DEFENCE & SPACE. The recipient shall take appropriate measures to ensure compliance with such obligation of confidentiality on the part of the recipient’s personnel.

Date : 30/06/2017 Page 1/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 2 DEVELOPMENT PARTNERSHIP

PAGE LEFT INTENTIONALLY BLANK.

Date : 30/06/2017 Page 2/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 3 DEVELOPMENT PARTNERSHIP

1 TABLE OF CONTENTS

1 Table of contents ...... 3

2 Instructions to bidders ...... 5

2.1 Acronyms ...... 5

2.2 General ...... 5

2.3 Submission ...... 6

2.4 Languages ...... 6

2.5 Price ...... 6

2.6 Limitations ...... 6

2.7 Contact Points ...... 6

2.8 Applicable documents ...... 7

3 FVI models Description ...... 8

3.1 Introduction ...... 8

3.2 All mission types and phases ...... 9

3.3 Main Features ...... 10 3.3.1 Simulation Infrastructure: SimTG Kernel ...... 10 3.3.2 Simulation Models ...... 17 3.3.3 Numerical Simulators ...... 22 3.3.4 Hybrid Simulators ...... 23 3.3.5 FVI Use Cases ...... 24

3.4 FVI Technologies ...... 25

4 FVI Model Development ...... 27

5 Management...... 28

5.1 Governance and agility ...... 28

5.2 Workload ...... 28

5.3 Competencies ...... 28

Date : 30/06/2017 Page 3/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 4 DEVELOPMENT PARTNERSHIP

6 Technical Means for Partnership ...... 30

6.1 Network ...... 30

6.2 Access to FVI models code Repository ...... 30

6.3 Access to the partner libraries repository ...... 30

6.4 Access to the partner Project Management Tool ...... 31

7 Trade Study Questions ...... 32

Date : 30/06/2017 Page 4/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 5 DEVELOPMENT PARTNERSHIP

2 INSTRUCTIONS TO BIDDERS

2.1 ACRONYMS

FVI: Functional Validation Infrastructure

COTS: Commercial Of The Shelf

GUI: Graphical User Interface

OBC: On-Board Computer unit

S/C: SpaceCraft

SMP2: Simulation Model Portability version 2

2.2 GENERAL

AIRBUS Defence and Space provides a FVI tool set to produce models for both numerical and hybrid simulators part of the Spacecraft validation strategy. In order to face an increasing demand in models and simulator usage AIRBUS Defence and Space intends to set up a long term and cooperative partnership in order to perform simulation model development.

Date : 30/06/2017 Page 5/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 6 DEVELOPMENT PARTNERSHIP

2.3 SUBMISSION

The proposal shall be sent by e-mail to the contact points listed in section 2.7 before 15/09/2017. The proposal shall state the interest of the company in this partnership proposal. Answers to the Trade Study Questions should be at least drafted in the proposal, and are to be discussed further with AIRBUS Defence and Space if the proposal is selected.

2.4 LANGUAGES

The language of the proposal shall be English. The project language shall be English.

2.5 PRICE

The financial proposal shall include all taxes and duties.

2.6 LIMITATIONS

Bidders are informed that this request for information does not bind AIRBUS Defence and Space in any way to place any contract with the bidders.

2.7 CONTACT POINTS

Proposal and any question related to this request for information shall be addressed to the following contacts by email:

Contact name Role e-mail address William Arrouy FVI models Product Owner [email protected] Romain Beteille FVI Num and Hybride team leader [email protected] Serge Raina Head of department [email protected] Yan Boulle Industrial Manager [email protected]

Date : 30/06/2017 Page 6/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 7 DEVELOPMENT PARTNERSHIP

2.8 APPLICABLE DOCUMENTS

AD1: Equipment Model Development Guidelines RFI_FVI_PARTNERSHIP_AD1 AD2: Makefile script example RFI_FVI_PARTNERSHIP_AD2 AD3: Equipment Model Development Guidelines Appendix RFI_FVI_PARTNERSHIP_AD3

Date : 30/06/2017 Page 7/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 8 DEVELOPMENT PARTNERSHIP

3 FVI MODELS DESCRIPTION

3.1 INTRODUCTION

AIRBUS Defence and Space has been involved in the design, development and manufacturing of Validation and Operational Simulators since the early 80s with the development of SPOT family and Telecom 1/2. With the Telecom family Eurostar 2000, AIRBUS Defence and Space has delivered more than 45 operational simulators to customers and Space Agencies such as CNES, ESA, Inmarsat, Hispasat, Arabsat, Orion, Eutelsat, etc….Those simulations are functionally compliant to the satellite behavior from an operation point of view executing the real Flight Software application.

Full software simulators appears in the years 95’s with the first use of 1750 emulator for programs such as MeteoSat SG and Metopsim (EUMETSAT), Stentor (CNES) executing the real binary image of the flight Software. This has been continued up to now on most of all Spacecraft programs. Consequently, AIRBUS Defence and Space has successfully delivered more than 45 operational simulators for a wide variety of customers (National agencies for Korea, Thailand, Taiwan, Chili, CNES, DLR) or international organisation (Intelsat, Eutelsat, SES, Arabsat, Hispasat Telesat, NilSat….). As a matter of fact, for all our export, commercial or national agencies program, AIRBUS Defence and Space is in charge of delivering an operational simulator to satellites operators.

Full Software simulators also allowed the breakthrough in the early 2000 to propose simulator for Software Verification Facility to the flight software development team as additional simulation use cases (AOCS, AIT,…). This has been latter extended to simulators for Engineering analysis in the area such as Mission Analysis, Flight dynamics, Thermal and Power analysis, Image processing algorithms, Space Physics analysis (plume, radiations, contamination).

With respect to Validation aspects (C/D/E phase), our entity provides to project teams the following simulators:

• A full Numerical Software Validation Facility (SVF) with the purpose of performing Software Validation and qualification, thus requiring a high fidelity level.

• Avionics Validation and AIT, with Real Time Simulator, as main block of ground test equipment’s related to S/C interface and stimulation of the complete satellite avionics. It is complemented by the SIMAIT, a full numerical facility, allowing preparation and debugging of test procedures before execution on the Satellite.

• Operations, with the Operational Simulator allowing Flight Operational procedure preparation & validation as well as ground system integration and training.

Date : 30/06/2017 Page 8/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 9 DEVELOPMENT PARTNERSHIP

3.2 ALL MISSION TYPES AND PHASES

As presented here above, simulation provided by the Functional Validation Infrastructure (FVI) service now plays a major role in the S/C validation strategy, especially focusing on Functional Verification and Assembly, Integration and Tests aspects.

FVI contributes to the overall spacecraft development process through the usage of both fully numerical and hybrid (software/hardware) solutions.

Date : 30/06/2017 Page 9/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 10 DEVELOPMENT PARTNERSHIP

3.3 MAIN FEATURES

Functional simulators as provided by FVI team are of two types:

• Fully numerical where is required a high fidelity level and advanced failure or abnormal usage capabilities.

• Hybrid where simulation is coupled with hardware thus implying severe constraints on the model design in order to match real-time execution.

The common parts between those two kinds of simulators; as well as of all the derived benches; are the simulation infrastructure (SimTG Kernel which comes with a full set of components) and the simulation models. A SimTG simulator is indeed composed of a simulation kernel (infrastructure) and a library/set of simulations model instances.

3.3.1 Simulation Infrastructure: SimTG Kernel

SimTG Kernel is an object-oriented simulator infrastructure; developed by AIRBUS Defence And Space, which is based on a hierarchy of C++ classes. The SimTG Simulation Kernel can be defined as a process which enters in an infinite loop waiting commands to be received by the Kernel object (SimControl). The communication protocol used for commanding and monitoring the Kernel is Messaging Passing/CORBA based. SimTG supports the SMP2 standard promoted by ESA.

SimTG kernel provides the required services to execute a simulation: • Dynamic creation of models • Hierarchical organisation of models through a naming service. • Management of simulation times (Simulated Run Time, Epoch Time) • Control of the simulation in accordance to a state diagram.

Date : 30/06/2017 Page 10/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 11 DEVELOPMENT PARTNERSHIP

• Scheduling of model operations (failures, breakpoints, …) • Management of simulation messages through a Logbook • Storing and restoring a simulation.

3.3.1.1 Create Models A Model is a SimTG object (C++) which provides a set of methods SimTG kernel can call in order to create an instance (or several) of this model. The model is defined in a library (or set of libraries) which is dynamically loaded by SimTG Kernel. An instance of any model defined on the library can be created. As models are objects, they can be instantiated several times in the same simulation.

3.3.1.2 Organize Models

SimTG Kernel provides a Naming Service in order to organize models. Simulation models are named and can be composed of other models (sub-models). This defines a hierarchical model structure (or model tree) as shown in the following example.

Date : 30/06/2017 Page 11/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 12 DEVELOPMENT PARTNERSHIP

3.3.1.3 Time Services

As basic function of a simulator, SimTG is providing a Time Service. It is used by SimTG Kernel and Simulation Models to get various time values using one of the following definitions: • Simulator Run Time (SRT): It is a counter in nanosecond which represents the elapsed time since the simulation has started. o It is initialised to 0 when simulator starts. o When the simulation is paused, the SRT is frozen. o It is always incrementing. • Epoch Time: It is an absolute time whose reference date is 01/01/1970 00:00:00. It is maintained using a fixed offset with the SRT and hence progresses together with simulation time except when this offset is changed. o Epoch Time can be used as Spacecraft Time. o Epoch Time is defined using an offset w.r.t. to SRT time which can be defined at any time during the simulation execution. As a result it may be continuous (linear) going back to the past. o Epoch Time is frozen when the simulation is paused. o Epoch Time can automatically be set to Zulu Time when simulation is started or resumed. • Zulu Time (or wall clock time): It is not related to simulation time but typically to the computer clock. o Zulu Time progresses independently of the state of the simulation. o Zulu Time can be used to synchronize the SRT Time in order to get simulation executing at real-time speed (1 second SRT ≈1 second Zulu).

Date : 30/06/2017 Page 12/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 13 DEVELOPMENT PARTNERSHIP

The above diagram describes the relationships between those 3 kinds of time. When simulation is paused, SRT and Epoch Times are frozen unlike Zulu Time.

3.3.1.4 Simulation State Diagram

SimTG kernel allows user to control the simulation processing in accordance with a state diagram as depicted by the following figure:

The SimTG state diagram is defined as follow:

Date : 30/06/2017 Page 13/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 14 DEVELOPMENT PARTNERSHIP

• At the Initial state, the simulator is empty (i.e. does not contain model but only simulator elements such as a scheduler and a logger). Then one or several models are created (using either remote commands or XML configuration files) • Init transition is performed triggering models initialization. It is an automatic transition that can only complete if no error is encountered in order to prevent running the simulation from an erroneous state. At the end the Stopped state is reached (the SMP2 equivalent name is Standby). It is split into several sub-state in order to comply with the SMP2 state diagram: o The Publish transition is in charge of publishing models data towards the simulation infrastructure. A Publish method is called on every model. This is applied in a recursive way. o The Configure transition gives opportunity to a model to perform its configuration (reading files ...). o The Connect transition state is in charge of models (data, event or interfaces) connections. On this transition the kernel provides to each model a simulation environment which contains services like scheduler and time keeper. o The Initializing transition performs the final model initialization. It automatically calls an init function declared on all SimTG models. • From the Stopped state, user can either : o Start the simulation. The simulator (Kernel + Models) goes to the Running state and the simulation time (SRT) is increasing according to a synchronisation source. o Step/Execute the simulation as fast as possible up to the defined execution duration has been reached. In such mode, the simulation models are executed but stay in the Stopped state. It should be noticed that a time step operation is a blocking operation, that is to say the user has to wait for its completion before performing other operations. The simulation is executed as fast as possible and execution speed is only limited by the resources available on the host computer time consumption o Save the current simulation into a file (stateset/breakpoint). During the saving of the simulation no other actions is possible and the simulation goes back to the Stopped state when storing completes. o Load the simulation from a file. It first clears (call destructors) all models and services and then loads the file to restore the models and the services. The end of the file loading brings back the simulation to the Stopped state.  Models are first destroyed (call of destructors) and then re-created (call of constructors) according to information stored in the stateset file.  When restoring a simulation; the simulator goes to Reset state and then call all models constructor as it is done when reaching the “Created” state. Then all models and kernel parameters or states are set to the values at the time it was stored. o Exit from the simulation. All the models and services are cleared (destructors are called) and the simulation process exits. o Reset the simulation. All the models and services are cleared (destructors called) and the simulation goes back to the Initial state, ready for creating new models.

All transitions are called recursively from top to bottom models with the result that when a model enter its transition function (Constructor, Publish, Connect …), this latter one has already been called on its sub- models. Consequently it defines a clear and deterministic order for transitions between models and sub- models.

Date : 30/06/2017 Page 14/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 15 DEVELOPMENT PARTNERSHIP

3.3.1.5 Schedule Models

The model scheduling is managed by the SimTG Scheduler. The aim of the scheduler is to receive activation (event) requested (delayed or not) from clients (such as models) and to activate them in a deterministic way. This determinism is achieved by the Scheduler object prioritising the execution order using as criteria: • The activation time • The priority level (Normal or High). If two requests have to be processed at the same time, the one with highest priority is executed first. • The posting order (first inserted, first executed). If two requests with same priority level have to be processed at the same time, the one which has been posted first is executed first. SimTG allows activation of models with argument(s). As this is not supported by SMP2 models are generally not using that capability to keep SMP2 compliance except when considerably simplifying the model design and execution. SimTG allows the usage of a special event called “Scheduler Breakpoint”, this is not supported by SMP2 but required by On-Board Computer model to support injection of breakpoint to Emulated Software Execution.

3.3.1.6 LogBook

The Logbook keeps track of all significant events taking place during a simulation run. A simulation owns a single logbook (one master logbook in multiple schedulers’ mode) where messages can be sent specifying: o The sender name (e.g. the model full name) o The event message (free text) o The time when the message was sent (SRT and Epoch Time) o The message level (Information / Warning / Error) o The message category (free text which can be used to count number of messages belonging to same category) The logbook object generates communication to all its subscriber elements:

• To the logbook interface on SimOps (real-time logbook viewer) • To a binary file (sql-lite format) allowing fast search/filtering/sorting from the offline logbook viewer. • Optionally to a text file for fast visualization with basic text editor.

3.3.1.7 Failure Manager

SimTG provides an object which handles all failures set on models. This allows reporting to user of all active failures, thus also permitting easy cancellation.

3.3.1.8 Stateset

In order to allow continuation of a simulation run based on a previous execution (goes to a specific spacecraft state), it is important to get the ability to dump all required data to a file - called stateset saving. The stateset file contains the whole context (‘snapshot’) of the simulation at a requested point in time. SimTG Kernel provides a stateset feature to save and restore simulations. The save and restore capability is based on an object serialization concept. Serializing an object consist in recording the object state in a data

Date : 30/06/2017 Page 15/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 16 DEVELOPMENT PARTNERSHIP

stream. Objects which support the appropriate interfaces and whose implementations adhere to the proper conventions can be serialized to a stream  as a result; there is no need to first re-create models (e.g. for SMP2 to reload an assembly file) before loading a stateset as the serialization stream also includes the Objects information.

Date : 30/06/2017 Page 16/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 17 DEVELOPMENT PARTNERSHIP

3.3.2 Simulation Models

A model is a representation of a real-word system or situation. It is composed of a set of states (e.g. numerical values) and a set of operations (schedulable events, invocation of model functions) which may change the model states.

3.3.2.1 Simulation Models Structure

A SimTG model is composed of the following elements (all optional): o A set of data port(s) (model data variables – which are SimTG Objects then also providing a set of services such as failure injection)

o Input Data: Model variable which can be set by other models or by the user from the test sequence.

o Parameter Data: Model variable which cannot be set by other models but can be set by the user. It may only be used by model at initialization.

o State Data (Internal model status): Model variable which cannot be set by other models and should not be set by the user (except mentioned differently in model documentation, for instance to set a model failure). It is the value used by the model for its internal computation.

o Output Data: Model variable which represents the result of a computation. It can be connected to other models.

o A set of operations that can be applied to the model (a set of functions that can be called on the model)

o A set of electrical / bus interfaces (I/O bus interfaces or electrical interface components such as power, analog, digital interfaces)

o A set of methods implementing the model functionality (model algorithms). As models are C++ objects, model methods can also be defined as public, protected or private.

o A set of sub-models

o A model can be composed of a set of sub-models which are (or not) connected between each other’s.

Date : 30/06/2017 Page 17/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 18 DEVELOPMENT PARTNERSHIP

In order to operate computation, the model needs at least: • The activation of an operation (from scheduler, other models or user interaction). • Reception on an I/O bus or electrical interface. • An update of input data (from other models or user interaction). Without external interaction (from scheduler, other models or user interaction) a model does nothing.

3.3.2.2 Model Data Port

A SimTG Model Data Port is an object that holds a model state (e.g. a numerical value). • A data is an object thus providing a set of services. • A data has a name and be accessed through the naming service.  A data belongs to one and only one model.  Data are sorted in Model Containers (which are published to the naming service) . Inputs are in “In” container. The full name of the input data InputData is then Model.SubModel.In.InputData. . Outputs are in “Out” container. . States are in “State” container. . Parameters are in “Param” container. • A data can be stored and restored through the stateset process. • A data has a direction: input or output which may define its behavior (especially when connected). • A data has a base type:  Basic Types: Boolean, Byte (signed/unsigned), Short Byte (signed/unsigned), Integer Byte (signed/unsigned – 32 or 64bits), String, Floating Point Value (simple, double)  Array of basic types  A Structure is an aggregation of basic type’s and/or arrays data. • Data supports failures concept.

Date : 30/06/2017 Page 18/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 19 DEVELOPMENT PARTNERSHIP

3.3.2.3 Model Interface Port

On top of data a model can provide a set of interface ports: • Of type Activator Port (void/void) which is provided by SimTG and can be connected to other models. It represents operations of type “doIt”. • Of type Software Interface Port which is user defined. The interface is a set of functions (one or more). The software interface ports can be connected between models assuming they have the same type. It represents operation mode complex than the simple “doIt” especially when parameters have to be exchanged between models or value returned by the interface call. • Of type System Interface Port which is defining an electrical connections. It is matching the satellite harness definition. It is connected using Lines objects.

3.3.2.4 Model Operation

An Operation is a function (method) identified by its name (because declared to the naming service) which can be: • Activated by the scheduler (one shot, cyclically) • Activated by the user (e.g. SMP2 method invocation concept) However a scheduled Operation shall be compliant with scheduler constraints: • An operation cannot return a value. • An operation can have input parameters (one to n) but their types are restricted to the basic types (boolean, char, string, double, float, long, int, short). A scheduled Operation is identified by a unique identifier (Id) which allows the user to cancel it before activation.

Date : 30/06/2017 Page 19/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 20 DEVELOPMENT PARTNERSHIP

3.3.2.5 Model Connection

A model can be itself composed of sub models. These sub-models are defined as children of this model. A model can be connected to other external models: • The model input or output data are connected to some other model data. • The model interfaces (operations, electrical interfaces, I/O Bus) are connected to other models interfaces.

The connection cardinality is defined as follow: • Activator and Software Interfaces : One to One or More (Multiple connections) • Data: One or More to One or Mode (Multiple Connections) o For arrays it is possible to connect: . To subset of an array to scalar(s) or part of other arrays . From scalar or part of arrays to an array (at a selected index) o It is not recommended to have an input (scalar or same array index) connected to several outputs. • System Interfaces: One to One (Single Point Connection)

3.3.2.6 Interface Propagation

The interface port (activator, software and system interfaces) are defined by a Consumer and a Provider (from SMP2 definition of an Interface): • The interface provider implements the interface. It is the one which is called to perform the operation associated to the interface. • The interface consumer is the caller of the interface. The interface call is immediate and not buffered (that is to say a model calling an interface immediate trigs the call to the connected model(s) interface).

3.3.2.7 Data Propagation

Each model is responsible of propagating its input and output states during a computation step as follow: 1. First, the model propagates all inputs data to sub-models which are connected to these inputs. 2. Then the model can perform its computation (which can be linked to Operations or triggered by the Data Propagation itself). Subs model computations can be launched if needed. At the end of this phase, the model updates its outputs. 3. At last, the model propagates all output data to models which are linked to these inputs.

Date : 30/06/2017 Page 20/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 21 DEVELOPMENT PARTNERSHIP

SimTG handles two type of data propagation depending on the model and data type: • Synchronous Model Type:

o The model is not activated when a model data input is updated by propagation. o The model requires the activation of an operation in order to control the data propagation. The operation allows the model to use the values which are set at its input at the time the operation is called. From these values it can compute internal elements and outputs. The outputs are only propagated when requested by the model. o This kind of model must be scheduled to perform computation. • Asynchronous Model Type:

o The model can be automatically activated (i.e. performs operations) following the update of an input. A model callback can then be called on input data value variation. o The data propagation is automatically managed. That is to say, at the end of the input processing (or after the processing of an operation) outputs data are automatically propagated. o This kind of model does not require to be scheduled. It can be activated by data flow.

Date : 30/06/2017 Page 21/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 22 DEVELOPMENT PARTNERSHIP

3.3.3 Numerical Simulators

Numerical simulators are first designed to perform S/C On-Board Software validation and latter extended to match Satellite Operation needs. As such, it is:

• Based on a fully representative model of the On Board Computer . Run exactly the same Flight Software (FSW) as the one used on the Satellite, taken as a binary image file • Include all satellite equipment models

. Providing High performance and excellent fidelity • Execute Faster than real-time • Software under test shows same behavior as executed on Satellite. This means that models are processing commands and returns acquisition which are functionally equivalent to the real ones (i.e. as observed on the Satellite).

. A Low cost and versatile systems, easily deployed (e.g. end user PC)

. Providing Failure injection and advanced services (tracing, breakpoints, symbolic debug, gdb interface, …) • Abnormal usage detection.

Date : 30/06/2017 Page 22/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 23 DEVELOPMENT PARTNERSHIP

3.3.4 Hybrid Simulators

Hybrids simulators are derived from Numerical one and are:

• Dedicated to tests with real equipments o Characterization test benches, with HW I/F to equipment o Large hardware test benches • Include, at least, one real OBC and its associated Ground Test Equipments (TM/TC…) o Coupled with simulations, for closed-loop (HIL) tests o Use the same models and simulation infrastructure as for numerical simulator

Real equipments Hybrid infrastructure

Equipment Real Equipment HW I/F Model#x (actuator) (acquisition) (Actuators)

TC Dynamic & environment CCS TM/TC SCOE Real OBC models TM

Equipment Real Equipment HW I/F Model#y (sensor) (stimulation) (sensors)

Date : 30/06/2017 Page 23/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 24 DEVELOPMENT PARTNERSHIP

3.3.5 FVI Use Cases

As presented in §3.2, the simulators term gathers several kind of benches and user needs. The common parts between all of them are the simulation infrastructure and the models. It has been chosen to develop a single equipment of physical environment model covering all the needs in order to simplify and rationalise its usage taking benefit of: • Same model used by all simulators facilitates its characterisation and maintenance. • Re-use of scenario (same model means same observables and way to operate them) • Reduce development and maintenance aspects. This also ensures a model and data configuration continuity which is a key element in the success of simulation usage. As a drawback, it also implies that a model cover all user’s needs; which care usually different; making a model development more complex and constrained.

Operations Preparation

AIT

Avionics Functional Validation

Onboard Software Validation

Hybrid Simulator Control Centre Functions (AOCS, ...) Analysis & Development Functional & Electrical Model Calibration Feed Back Models Ground Segment Models Numerical Simulator HW Interfaces Functional & Electrical Numerical Simulator Functional & Electrical Models Models Avionic S/C Numerical Computer Functional Models Numerical Computer Equipment Model Model Function Software Software

Software Test Bench (STB) Real Time Environment (RTE) Functional Verification Bench Software Verification Facility (SVF) for EFM and PFM Satellite Simulator (SATSIM) (FVB) SimAIT SimEFM System DB & Technical Data

Date : 30/06/2017 Page 24/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 25 DEVELOPMENT PARTNERSHIP

3.4 FVI TECHNOLOGIES

FVI models are built-up on the following technologies:

. SimTG: Simulation Kernel Infrastructure . Platform = Linux or Windows . Linux for Hard Real Time - hybrid bench . Linux or Windows for numerical benches

. SimMF : Model Development Environment . Fully embedded in Eclipse workbench as a plugin. . Complete model development workbench dedicated to simulation model design and generation for SimTG/SMP2 simulation kernels. . Integrates an exhaustive set of services to build up simulators models with efficiency

. SimOPS/CSS Boy/JSynoptic: Simulator Execution and Data Display . Fully embedded in Eclipse workbench as a plugin. . Test environment that permits to easily write, settle, run validation tests (Java based) . Visualise and display 2D/3D results

Date : 30/06/2017 Page 25/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 26 DEVELOPMENT PARTNERSHIP

The main skills to develop FVI models are the use of these products and a good level in C++ and Java.

Date : 30/06/2017 Page 26/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 27 DEVELOPMENT PARTNERSHIP

4 FVI MODEL DEVELOPMENT

The typical kind of models to be developed in the frame of this partnership is first envisaged for: • S/C Payload models: o Those models are usually connected to the S/C OBC through a communication bus of type M1553, SpaceWire. The communication protocol with the OBC shall be simulated and constraints linked to this protocol shall also be. o Only the operation part of the payload is to be considered. The science data generation has not. For instance: . For a camera payload, the acquired images are not simulated but the data acquisition rate and all the operations/constraints required performing the imaging are. . For a mass memory, the memory content for science data is not simulated but the file system definition is simulated as well as the time to store/dump to memory according to input/output flow programming. o The complexity of the payload is mainly driven by: . The use case: Operation simulator required a higher simulation level on such equipment than for Software Validation purpose. . The presence of a processor/software (smart payload) which increases the complexity of the communication protocol with either ground or S/C OBC. • Ground Equipment’s light simulation models. o Those models are used to perform on ground, the interfaces with the S/C. It mainly concerns TM/TC (RF Front-end), Power Front End. o Complexity of this model is related to the amount of commands and acquisition to manage. The communication protocol has already been standardized. Most of the time, the model fidelity is limited to acceptance of commands (verification of format and validity) and generation of acquisitions based on fixed patterns. However, can be implemented functional algorithm, for instance to perform power supply regulation. • Thermal models. o Such kind of model is quite simple. The complexity comes from the number of thermal nodes (assembly of simple models) that are needed to be assembled and configured.

The model development shall follow the rules defined by the Model Development Guidelines provided with this RFI. It should be noticed that an example of model layout is provided at the end of the Guideline document.

Date : 30/06/2017 Page 27/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 28 DEVELOPMENT PARTNERSHIP

5 MANAGEMENT

5.1 GOVERNANCE AND AGILITY

This proposal aims at sharing some of our portfolio assets (starting with FVI models) with an external partner. In this frame benefits should be shared, and so costs and risks should be shared as well.

Possible benefits for the partner would be in the area of new business opportunities with alignment between AIRBUS Defence and Space and the partner on deployment of this asset towards other customers, as well as access to other AIRBUS Group entities.

The product management is also shared by both partners. A strong relationship needs to be setup between parties so that AIRBUS Defence and Space requirements and solutions evolve through a collaborative effort.

AIRBUS Defence and Space applies internally:

• Strong commitment on deliveries, on time, on cost and on quality.

• Strong reactivity on anomaly/evolution correction/implementation.

• Planning management flexibility adapted to AIRBUS Defence and Space context.

The role of product owner (PO) should remain within AIRBUS Defence and Space at first. In a second phase, if new developments have to be conducted on the product to target other industries, the sharing of PO role has to be defined between AIRBUS Defence and Space and its partner.

5.2 WORKLOAD

Workload shall be managed internally by the partner, based on the roadmap vision and exchanges with the product owner.

As a starting point for these FVI developments, a workload of 2 to 3 full time equivalents is expected on a pilot phase.

5.3 COMPETENCIES

Competencies required to manage and develop the FVI models are listed below.

Mandatory skills are:

• Software engineering and architecture skills with especially good knowledge in C/C++ for model development and basic knowledge of JAVA for model testing.

• Knowledge of Linux / Windows environments.

Strongly desirable skills are:

Date : 30/06/2017 Page 28/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 29 DEVELOPMENT PARTNERSHIP

• Spacecraft System understanding

• Equipment Spacecraft unit understanding

Date : 30/06/2017 Page 29/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 30 DEVELOPMENT PARTNERSHIP

6 TECHNICAL MEANS FOR PARTNERSHIP

6.1 NETWORK

The product is shared between the partner and AIRBUS Defence and Space. Even if the code is located on partner infrastructure, the code remains the intellectual property AIRBUS Defence and Space .

AIRBUS Defence and Space shall be able to access to the partner network but the partner is not able to access the AIRBUS Defence and Space network for security reasons. The following network scheme shall be implemented:

A solution based on an external cloud is also possible, provided that intellectual property of the product is guaranteed.

6.2 ACCESS TO FVI MODELS CODE REPOSITORY

The partner should use GIT (preferred) or SVN repositories as SCM repository according to the project type. This allows AIRBUS Defence and Spaceeasily getting new SW releases, performing code reviews and creating development branches. AIRBUS Defence and Space shall also be able to pull/ commit/ push the code from/to the partner code repository.

For example, a tool such as GitLab could be setup to easily perform code reviews from each side.

6.3 ACCESS TO THE PARTNER LIBRARIES REPOSITORY

All the libraries used / generated for the FVI models shall be accessible to AIRBUS Defence and Space.

Furthermore AIRBUS Defence and Space shall be able to upload libraries in the partner libraries repository to upgrade some common libraries that are developed within AIRBUS Defence and Space premises.

Date : 30/06/2017 Page 30/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 31 DEVELOPMENT PARTNERSHIP

6.4 ACCESS TO THE PARTNER PROJECT MANAGEMENT TOOL

AIRBUS Defence and Space shall be able to get a web access to the project management tool from its network. JIRA / Confluence could be used by the partner to be compliant with AIRBUS Defence and Space development process.

Date : 30/06/2017 Page 31/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 32 DEVELOPMENT PARTNERSHIP

7 TRADE STUDY QUESTIONS

Based on the background information above, please answer the following questions as they relate to your company. Where AIRBUS Defence and Space has not provided enough detailed information to answer the question, please clearly state your assumptions in your answers.

1) Company a) Turnover? b) Full time staff? c) Experience in Software Development and key Technologies? d) Describe your organisation and the main roles in your company? e) How many developers? Average tenure f) Do you use sub-contractors? If yes, average FTE in a year & profiles? g) How would you define your company culture and priorities? h) Who are your top 5 customers & what % of turnover do they represent? i) Experience with Space Industry or related to Simulation domain? 2) Network / System a) Please list the system architecture (PC-based, UNIX, or Linux) compatible with products you develop. b) Is your network already accessible from another external company? c) If no, do you have the ability to allow AIRBUS Defence and Space to access a limited part of your network? 3) Tools a) Please lists all the tools used by your company to develop/build software products? b) What is your Version Control System for source code? c) What are your project management tools? 4) Development practices a) What is your main development process methodology? b) Main driver in the development process? c) Code review / code quality? d) Automatic tests / tools? 5) Quality a) What are your quality standards and practices? b) How do they relate to code / products quality? 6) Competencies a) What are the detailed technical competencies available in your company? b) How do you maintain these competencies? c) How do you share these competencies? d) What external links do you have with other companies/networks? 7) Customer relationship a) Do you perform regular customer surveys? What is the template used?

Date : 30/06/2017 Page 32/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017

COMMERCIAL IN CONFIDENCE Ref: Edition: 01 Rev. : 00 RFI – FVI MODELS Date: 30/06/2017 Page: 33 DEVELOPMENT PARTNERSHIP

END OF DOCUMENT

Date : 30/06/2017 Page 33/33 Request for Information for FVI models development partnership

AIRBUS Proprietary and Confidential. © AIRBUS Defence and SPACE SAS Copyright – 2017