European Space Agency - emits.sso.esa.intemits.sso.esa.int/emits-doc/1-5320-RD7-5303SoW.pdfEuropean...

European Space Agency

Directorate of Technical and Operational Support

STATEMENT OF WORK

High Fidelity End-to-End Entry Descent and Landing Simulator

Reference: CE40

Issue: 02

Revision: 00

Date: 12 December 2006

Table of contents TABLE OF CONTENTS...................................................................................................................................... 2

1. INTRODUCTION............................................................................................................................................. 3 1.1 SCOPE OF THE DOCUMENT ............................................................................................................................. 3 1.2 APPLICABLE AND REFERENCE DOCUMENTS................................................................................................... 3

Applicable Documents (ADs) .......................................................................................................................... 3 Reference Documents (RDs) ........................................................................................................................... 3

2. BACKGROUND AND ACTIVITY OBJECTIVE ....................................................................................................... 5 2.1 BACKGROUND ............................................................................................................................................. 5

2.2 OBJECTIVES OF THE ACTIVITY............................................................................................................. 5

3. ACTIVITY DESCRIPTION............................................................................................................................ 7 3.1 WORK LOGIC ................................................................................................................................................. 7 3.2. PHASE 1 ........................................................................................................................................................ 8

Task 1: EDL System Architecture Definition and Specification...................................................................... 8 Task 2: Definition and Specification of EDL Simulator Architecture and Simulator Architectural Design... 9 Task 3: Collection of the HiFiEDL Simulator Environmental Models and Databases................................. 11 Task 4: Collection of the HiFiEDL Simulator Aero-thermodynamics, Parachute, Airbag and Landing Legs Models and Databases .................................................................................................................................. 12 Task 5: Synthesis of Phase 1 Results............................................................................................................. 13

3.3 PHASE 2A ..................................................................................................................................................... 14 Task 6: Integration and Validation of Environmental Models and Database Access Routines .................... 14 Task 7: Development, Design, Implementation and Test of EDL Subsystems and Components Models ...... 14 Task 8: Coding, and Validation of GNC Algorithms ................................................................................... 15 Task 9: Integration and Testing of the Non-Real-Time HiFiEDL Simulator ................................................ 16 Task 10: Integration and Testing of the Real-Time HiFiEDL Simulator ...................................................... 17

3.3 PHASE 2B ..................................................................................................................................................... 18 Task 11: Non Real-Time HiFiEDL Simulator Verification and Validation Campaign................................. 18 Task 12: Real-Time HiFiEDL Simulator Verification and Validation Campaign ........................................ 19 Task 13: Overall Activity Synthesis............................................................................................................... 19

TASK 14: MAINTENANCE AND UPDATE OF THE DATABASE ............................................................................... 20 4. MANAGEMENT, REPORTING, REQUIREMENTS AND DELIVERABLES ...................................... 21

6. AGENCY’S RESPONSIBILITIES AND INTERFACES ........................................................................... 26

ANNEX 1: TECHNICAL BACKGROUND & REQUIREMENTS............................................................... 27 A1.1. ACRONYMS .............................................................................................................................................. 27 A1.2 TECHNICAL BACKGROUND ........................................................................................................................ 27 A1.3. APPLICABLE TECHNICAL REQUIREMENTS................................................................................................. 33

ANNEX 2: SOFTWARE REQUIREMENTS................................................................................................... 36

1. Introduction 1.1 Scope of the Document This document describes the activity to be executed and the deliverables required by the European Space Agency (ESA) in relation to the "High Fidelity Entry Descent and Landing Simulator" (HiFiEDL) activity. This document will be part of the contract and shall serve as an applicable document throughout the execution of the work, with amendments as agreed at the Kick-Off Meeting (KoM). The list of acronyms used in this Statement Of Work (SOW) is given in Annex A1.1. Acronyms.

1.2 Applicable and Reference Documents

Applicable Documents (ADs) The following documents contain requirements applicable to the activity: [AD1] ECSS-E-40 Part1B from 28 November 2003, Space Engineering – Software (See Annex 2 for the tailored version of the ECSS-E40) http://www.ecss.nl/ [AD2] Larsen, M. A., “CDF Model Input Specification,” CDF-IFS-001, Issue 2, rev. 3

Reference Documents (RDs) The following documents can be consulted by the Contractor as they contain relevant information:

[RD1] ATPE Simulator Technical Reference, EADS Space Transportation, Technical Note, SIBRE-ATPE-STR-001, ESA Contract 12731.

[RD2] Navigation for Planetary Approach and Landing, Final Report, ESA contract 15618 [RD3] LIDAR-based GN&C for Automatic Rendezvous and Safe Landing, Summary

Report, EADS Astrium, ESA contract 17389 [RD4] S.M. Parkes, I. Martin, M. Dunstan and D. Matthews, Planet Surface Simulation

with PANGU, 8th International Conference on Space Operations, May 17-21, 2004 Montreal, Canada

[RD5] S. A. Striepe, D. W. Way, and A. M. Dwyer and J. Balaram, Mars Science Laboratory Simulations for Entry, Descent, and Landing, AIAA Journal of Spacecraft and Rockets, Vol. 43, No. 2, March–April 2006

[RD6] Mars Science Laboratory web site http://mars.jpl.nasa.gov/msl/ [RD7] Preliminary MOLA ultra-high resolution gridded data ftp://ltpftp.gsfc.nasa.gov/projects/tharsis/MOLA/GRIDS/ [RD8] Lemoine, F.G. et al. “Goddard Mars Model 2B” http://bowie.gsfc.nasa.gov/697/MARS/GMM2B.html [RD9] C. G. Justus, A. L. Duvall and D.L. Johnson, Mars Global Reference Atmospheric

Model (Mars-GRAM) and Database for Mission Design, International Workshop: Mars Atmosphere Modeling and Observations, Granada, Spain, January 13-15, 2003

[RD10] E. J. Fallon, R. Sinclair, Design and Development of the Main Parachute For the Beagle 2 Mars Lander, 17th AIAA Aerodynamic Deceleartor Systems Technology Conference and Seminar, 19-22 May 2003, Monterey, CA

http://www.ecss.nl/

http://mars.jpl.nasa.gov/msl/

ftp://ltpftp.gsfc.nasa.gov/projects/tharsis/MOLA/GRIDS/

http://bowie.gsfc.nasa.gov/697/MARS/GMM2B.html

[RD11] B. Raiszadeh, Multibody Parachute Flight Simulations for Planetary Entry Trajectories Using ‘Equilibrium Points, AAS 03-163, 13th AAS/AIAA Space Flight Mechanics Meeting, 9-13 February 2003, Ponce, Puerto Rico

[RD12] Martin Marietta Corp., Entry Data Analysis for Viking Landers 1 and 2, NASA Contractor Report 159388, Nov. 1976, NASA Tehchnical Report Server at http://ntrs.nasa.gov

[RD13] D. S. Adams, Mars Exploration Rover Airbag Landing Loads Testing and Analysis, AIAA 2004-1795, 45th AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics & Materials Conference, 19-22 April 2004, Palm Springs, CA, at http://ntrs-new.jpl.nasa.gov/dspace/bitstream/2014/8681/1/02-1223.pdf

[RD14] Interferometer Constellation Control 2 (ICC2), Alcatel Alenia Space, Technical Note, ICC2-ASP-TN-52, Contract 15843

[RD15] S.R. Lewis, M.Collins, F. Forget, Mars Climate Database, User’s Manual v3.0, April 2001 (to be provided at Kick-Off Meeting)

[RD16] Prasun N. Desai, R. A. Mitcheltree et al., Entry Dispersion Analysis for the Stardust Comet Sample Return Capsule, AIAA Paper 97-3812, 1997 AIAA GNC, AFM and MST Conferenceand Exhibit, 11-13 August 1997, New Orleans, LA – Download Link

[RD17] R. A. Mitcheltree , RG. Wilmoth et al., Aerodynamics of Stardust Sample Return Capsule, Journal of Spacecraft and Rockets. Vol 36, No 3, May-June 1999

[RD18] Robert D. Braun, R.W Powell, et al, Mars Pathfinder Six-Degree-of-Freedom Entry Analysis, Journal of Spacecraft and Rockets. Vol 32, No 6, Nov-Dec 1995

[RD19] A. A. Wolf, C. Graves, R. Powell, W. Johnson, Systems for Pinpoint Landing at Mars, AAS 04-272, NASA Technical Report Server at http://ntrs.nasa.gov

[RD20] Parachute System Design and Analysis Tool, Final Report, Daimler Benz/Dornier, ESA contract 8759

[RD21] P. Regnier, C. Koeck, R. Slade and P. Tran, Assessment of Landing Systems Concepts for the ExoMars Mission, IAC-05-A5.2.04, 56th International Astronautical Congress, Fukuoka, Japan, Oct. 17-21, 2005

[RD22] ASTOS – Aerospace Trajectory Optimization Software, Product flyer, TTI GmbH http://www.astos.de/

[RD23] E. Allouis, A. Ellery, M. Sweeting, Planetary Exploration: SPADES a New Integrated Entry Systems Design Tool, IAC-05-D1.3, 56th International Astronautical Congress, Fukuoka, Japan, Oct. 17-21, 2005

[RD24] S.A. Striepe, D.W. Way, A.M. Dwyer, and J. Balaram, Mars Smart Lander Simulations for Entry, Descent, and Landing, AIAA Atmospheric Flight Mechanics Conference and Exhibit, 5-8 August 2002, Monterey, CA – Download Link

[RD25] Aurora Use of Technology Readiness Levels, MSR-TRL-ESA(HME)-0001, Issue 1, rev 0

The documents can be found under the FTP server:

ftp://ftp.estec.esa.nl/pub/aurora/Core_Programme_Activities/High_Fidelity_End-to-End_Entry_Descent_and_Landing_Simulator/

http://ntrs.nasa.gov

http://ntrs-new.jpl.nasa.gov/dspace/bitstream/2014/8681/1/02-1223.pdf

http://ntrs.nasa.gov

http://www.astos.de/

ftp://ftp.estec.esa.nl/pub/aurora/Core_Programme_Activities/High_Fidelity_End-to-

2. Background and Activity Objective 2.1 Background Beyond Exomars, future European robotic missions to Mars will need the capability to safely land relatively close to sites assigned for the science investigations. It is foreseen that the major axis of the landing footprint ellipse will be on the order of a few kilometres or less. The Agency has started several technology development activities to investigate advanced guidance, navigation and control (GNC) techniques. The new GNC technology will reduce the inherent risks associated with a landing mission and at the same time will allow soft and safe precision landing in regions which maximize the scientific return.

2.2 Objectives of the Activity The activity has two main objectives. One objective is to develop a high-fidelity, physics-based1 suite of simulation tools that can support EDL system and mission design, analysis, and trade-offs, as well as support the project across its entire lifecycle. The other objective is to identify technologies or areas of expertise which are critical to the success of the mission. These technologies need to be developed or enhanced in order to perform the validation of the simulator modules which cannot be covered by the present activity, for instance, the aerodynamics database for the aeroshell or the parachute(s). It is expected that the technology readiness level (TRL) of the simulator reaches level 4 at the end of this activity. The term software suite includes a low, medium, and high fidelity versions of the simulator as well as the RT version and their associated databases and database access routines. To achieve the objectives of the activity the simulator shall be able to: • Perform EDL system design and analysis with rapid turnaround for preliminary mission

design and analysis including the capability to perform mission concept trade-offs. • Perform Monte-Carlo campaigns in order to analyze the end-to-end dispersion of the

landing site location. • Perform development, analysis, test, and validation of flight software:

- In a non-RT environment for rapid turnaround. - In a RT environment, including the capability to test hardware-in-the-loop

(HIL) where possible. It is foreseen that in the initial stages the RT environment includes only representative on-board processors-in-the-loop (PIL) without excluding software-in-the-loop (SIL)2. The RT simulator will be applicable only to missions which have closed loop controls in the GNC subsystem.

• Support the flight software validation and verification (V&V) process. • Support post-test analyses for end-to-end EDLS qualification testing. • Interface with other ad-hoc tools such as PANGU, PASDA, LS-dyna, etc. • Support mission operations in the pre-EDL and EDL phases. A functional diagram of the various modules of the simulator and their use during the mission life-time is presented in Figure 1. There is a preferred nomenclature for the three levels of fidelity of the simulator. The low fidelity version is called the System Concepts Simulator (SCS), the medium fidelity is called the Mission Performance Simulator (MPC), and the high fidelity simulator is called the Functional Engineering Simulator (FES). There is a one-to-one mapping between the modules of the FES and those of the RT simulator, however only a subset of the SCS modules is used to generate the RT simulator.

1 The term “physics-based” simulator is used here to emphasize the fact that the EDL system components shall be

represented by high-fidelity models obtained from experiments or numerical modeling and analysis. For example, the aerodynamics coefficients of the aeroshell can be obtained from aerodynamics tunnel tests for a certain range of Mach and Knudsen numbers and supplemented with CFD analysis outside the wind tunnel test range.

2 An example of the SIL is a GNC algorithm executable running either in a non-RT or RT environment.

In the operational phases the RT simulator will be used to perform simulations with the latest known data and assess the performance and the size of the landing footprint. It can also be employed post-landing to validate the models with the real landing data from telemetry. It is important to note that the FES can also be used for R&T activities such as the performance evaluation of advanced GNC technologies for EDL systems.

Figure 1 Functional diagram of the HiFiEDL Simulator and its intended use through the lifecycle of the mission. The conversion of the modules of the FES is performed by a cross-platform tool such as dSPACE TargetLink.

While the main goal of the simulator is the support of Mars missions it shall be possible to configure it for missions landing on the Moon and small celestial bodies, as well as for Earth re-entry. Due to the lack of an atmosphere on the Moon the descent trajectory is different from that of Mars EDL and the entire deceleration is provided by rocket engines. . The specific tasks of the activity have been identified and listed below. • Definition and detailed specification of the architecture of each of the EDL system

options presented in Table 4 of Annex 1. • Simulator (HiFiEDL Simulator) system architecture definition and specification. • Design of the architecture of the HiFiEDL Simulator. • Collection and generation of databases of the planetary environment models. • Detailed design, implementation, validation, and testing of the modeling routines or of

the access routines for the databases. • Detailed design, implementation, validation, and testing of the EDL system components

and subsystems. • Detailed design, test, and validation of the GNC equipment models and their interfaces. • Specification of a RT testbed architecture and eventual procurement plan. • Integration of the EDL models with the environmental models.

• Elaboration of the HiFiEDL Simulator test, verification, and validation plan. • Develop interfaces and access routines for support tools, such as multi-body dynamics

simulation tools and GNC design and analysis tools. • Elaboration of a technology development plan for:

- Technologies that have to be developed in order to increase the fidelity of the simulator and the technology readiness level of the European EDL systems.

- Validation of critical component models, such as the parachutes or airbags, against experimental data.

3. Activity Description 3.1 Work Logic The work breakdown structure of the proposal shall reflect the phase and task breakdown provided below. To minimize the risk the study is organized in three technical phases (1, 2a and 2b) and two contractual phases; the Contractor shall proceed with Phase 2a-b only after the release of a written authorization by the Agency. Phase 1 will last five months. During Phase 1 the contractor will define and specify several cases of EDL system (e.g. for hard or soft landing, propulsive or passive, etc.) and will perform the simulator architecture definition and specification. Once the simulator architecture is specified the architectural design of the simulator will be undertaken. Before the end of Phase 1 the contractor will perform a compilation of the environmental models and databases, e.g., gravitational, atmospheric, and terrain, and compilation of the aerodynamic models and databases, e.g., the lift, drag, and moment coefficients of the EDL system with and without an aeroshell, and the design models for the airbags (vented and non-vented) and landing legs. The preliminary design review (PDR) will be held at the end of Phase 1. The major deliverables are the simulator architectural design, environmental, aeroshell and parachute aerodynamics, and airbag dynamics design tools, and a preliminary critical technology activities development plan.

Phase 2a will last ten months. During Phase 2a the contractor will perform the detailed collection of the environmental models and databases, the detailed design, coding, and validation of EDL subsystems and components models. The contractor will organize the models in libraries. A non-exhaustive example of libraries is presented in Figure 3. The models will be integrated in five architectures. The architectures chosen are presented in more detail in Table 4 of Annex 1. Three main types of architecture are considered for a Mars mission, one for the Earth, and one for the Moon.

• Type 1: The simplest Mars architecture, with no control during the entire EDL phase. • Type 2: a Mars architecture of medium complexity which is representative of the

ExoMars mission architecture and it employs airbags to absorb the shock of the landing. This architecture has a two derivatives:

a. The lander is aerodynamically (parachute) decelerated only. b. The lander employs thrusters to decelerate during the terminal descent phase,

for the last few hundreds to few thousands of meters. • Type 3: The most complex Mars architecture, with control throughout all the EDL

sub-phases. For this configuration landing legs will be employed. • Type 4: a high-speed Earth re-entry mission architecture typical of an MSR re-entry

capsule (no control during the re-entry, descent, and landing). This architecture is also applicable to planets or planetary satellites with an atmosphere such as Venus, and some of the Jovian and Saturnian satellites.

• Type 5: a Lunar landing mission architecture (with no aerodynamic deceleration.)

Use of as much of GNC algorithm heritage shall be employed, since the purpose of the activity is simulator development and not GNC algorithm development. The GNC algorithms employed in the simulator should be at a TRL 2 at least. Once the contractor has integrated

and tested the simulator the contractor will define and specify a test and validation and verification plan for both the non-RT and RT versions of the simulator. The major deliverables at the end of Phase 2a are the integrated and tested simulator, in both non-RT and RT configurations, the consolidated critical technology activities development plan, and a simulator verification and validation plan. A combined critical design and technology readiness review will be held at the end of Phase 2a. Prior to progress meeting five (PM5) the contractor will install a beta version of the simulator suite at ESTEC. The beta version will be used to test the user interfaces and the simulator configuration routines, as well as perform preliminary runs of the simulator suite. The contractor will collect (ESTEC) user’s inputs and filter them. After Agency’s approval of the changes the contractor will proceed with their implementation in the simulator suite.

Phase 2b will last three months. During this phase the contractor will perform the non-RT and RT test campaigns and will write-up the study synthesis and conclusions. The simulator will undergo a formal acceptance review (AR) at ESTEC during the final presentation.

The major deliverables at the end of Phase 2b are the final data package, and the verified and validated simulator, in both non-RT and RT versions. The work packages proposed by the Contractor in his offer will reflect the Phases and/or Tasks breakdown provided below.

3.2. Phase 1 The objectives of Phase 1 are to perform an EDL system and EDL simulator definition and specification, to design the architecture of the simulator, and to collect the environmental and aero-thermodynamics, and structural dynamics databases for the simulator.

Task 1: EDL System Architecture Definition and Specification The objective of this task is to identify the EDL subsystems which are to be modelled and specify their role in the HiFiEDL simulator. The interfaces of the modelled EDL subsystems are also identified and specified during this task. A breakdown structure of the EDL system shall be performed down to the component level. In this context component means the smallest unit providing functionality to the EDL system for the purpose of the simulation. For example the smallest unit providing functionality to the EDL system is an inertial measurement unit (IMU) or an attitude control system (ACS) thruster. Inputs: • Open literature. • This statement of work and its annexes. • Contractor’s knowledge base. Description: • Taking as reference the EDLS cases specified in A1.3 req. 1, identify the user

requirements for the EDL system component models according to each of the phases in the lifecycle of the project: o During Phases 0 and A the simulator will be used to perform mission analysis and

concept trade-offs. As a consequence the turnaround time of a simulation has more weight than the accuracy of the simulation. Thus it is expected that during this phases a “low-fidelity” level of simulation will be employed.

o Towards the end of Phase A and during Phases B the mission design is performed. A “medium-fidelity” level of simulation is employed in these phases to aid in-depth trade studies and test the performance of GNC algorithms.

o During Phases C, D, and E the “high-fidelity” level of simulation is used in the detailed design of the mission, perform GNC tests and validation, and last but not least to provide operational mission support.

o During Phases D and E the RT version of the simulator will be also employed in the lander assembly, integration and testing (AIT) and algorithm verification and validation (V&V).

• Identify each of the sub-phases and the sequence of events during the EDL phase starting from the last trajectory correction maneuver.

• For each of the EDL sub-phases identify each of the EDL subsystems and components which contribute to the determining the EDL system performance.

• Specify the models in terms of purpose, functional description, and inputs, and outputs. • The input lists should contain at least one variable which will be used to trigger faults in

the component model. The fault might result in the component being on-line or off-line or might put the component in a degraded state.

• Specify the EDL subsystems and component models library. • Specify the User’s requirements for the simulator. • Define a preliminary critical technology activities development plan. The plan will outline

the critical EDL system components which need to be developed and tested and a rough order of magnitude (ROM) costs.

Outputs: • TN 1 “EDL System Architecture Definition and Specification” • TN 2 “Preliminary Critical Technology Activities Development Plan” • “HiFiEDL Simulator User Requirements Document (URD)”

Task 2: Definition and Specification of EDL Simulator Architecture and Simulator Architectural Design The goal of this task is to define and specify the architecture of the HiFiEDL simulator. The simulator components and their interfaces shall be identified and specified. It is expected that at least three levels of accuracy will be designed into the simulator models3. For example, low accuracy models are employed for rapid turnaround during mission analysis and EDL GNC subsystem design. For the analysis of EDL GNC algorithms or operational mission support the higher accuracy models are employed. It is expected that the HIL will consist of one (evaluation) on-board processor in the loop for the foreseeable future. It is possible that for integration and testing and operational support of the mission the engineering development sensors and actuators are connected with the simulator. Inputs: • TNs 1 and 2 and HiFiEDL Simulator URD • Open literature. Description:

3 As explained in the description of Task 1.

• Identify the type of simulation work for which the HiFiEDL simulator will be employed and determine how the simulator will be run. A non-exhaustive list of simulations for which the HiFiEDL simulator will be employed is: • Planetary landing mission definition. • EDL GNC subsystem preliminary design. • Design and analysis of GNC algorithms. • Performance robustness analysis of EDL system • Full end-to-end dispersion analysis • RT HIL simulations. • Operational mission support.

• Define the HiFiEDL simulator architecture using the EDL system architecture specified in Task 1.

• Define and specify the simulator development, work, run-time, and maintenance environment.

• Specify the simulator configuration and initialization procedures. • Specify the simulator data input interfaces. For example:

• The aerodynamic data for the EDL system can be coded in a routine as a table and a look-up type of access to the table.

• Loading high resolution planetary surface imagery for the entire landing area in the HiFiEDL Simulator is prohibitive. A routine can be written which loads the high resolution data only in a small area around the field of view of the imaging system used for landing site selection and hazard avoidance. The remaining area is covered with low resolution surface imagery. A similar procedure can be considered for the high resolution elevation data.

• Specify the data output interfaces and the data analysis and post-processing tools. • Identify and specify the CPU time and memory requirements for each of the simulation

cases. For example: • EDL GNC subsystem preliminary analysis requires a rapid turnaround for supporting

trade-off type of studies. Assume that the GNC design engineer would like to run a few tens of cases during a work day, say 20 cases in eight hours. The consequence is that one case should run in 24min or less. Bearing in mind that the typical duration of the Mars EDL phase is between eight and ten minutes the conclusion is that the simulator should run no slower than three times compared to the real time.

• The design and analysis of the GNC algorithms requires running Monte-Carlo campaigns. Assuming that 1000 cases are performed during a full day (24hrs), the duration per case is 1.44min. This simulation is more accurate than the one needed for the preliminary design which was illustrated above, i.e., the models are more complex. As a consequence a Monte Carlo case is expected to require more CPU time than the preliminary design simulation, if ran under the same conditions (the same CPU and memory size.) As a consequence the Monte-Carlo runs should be performed on a faster platform or with a faster tool, e.g., an executable running on a high performance workstation or on a parallel computer.

• The RT HIL simulations require that the models are executed and the databases are accessed in the interval of time between the execution of the GNC algorithms. A preliminary analysis should be conducted to estimate the CPU time needed by the GNC algorithms and the time needed for the EDL and environmental models to execute, the database to be accessed and results to be returned to the environment simulation routines.

• Identify and specify the hardware requirements for a RT simulator testbed. The specification should be based on the results of the CPU time and requirements identified during this task. For example, for RT simulations an architecture which is successfully

used at ESTEC for the simulation of formation flying missions is to run the environment on a RT dSPACE computer and the GNC algorithm on a LEON2 onboard computer validation board. The dSPACE RT computer and the LEON board communicate through UDP/IP over a local Ethernet network [RD 14].

• Specify the interfaces between the RT simulator SW and HW components. • Specify a preliminary verification and validation plan. The preliminary V&V plan is

expected to include comparisons with the Viking 1 and 2, Mars Pathfinder, the Mars Exploration Rovers 1 and 2, Stardust, and ESA Atmospheric Re-entry Demonstrator (ARD) mission data.

Outputs: • “HiFiEDL Simulator Architecture Design Document (ADD)” which should include a

section on “Data Input and Access Procedures Specification” and one on “Data Output and Post-processing Procedures Specification”

• TN 3 “Preliminary HiFiEDL Simulator Verification and Validation Plan” • System Requirements Review Report and Handout • Preliminary “HiFiEDL Simulator System Configuration Item List (SCIL)” • Preliminary “HiFiEDL Simulator Software Configuration File (SCF)”

Task 3: Collection of the HiFiEDL Simulator Environmental Models and Databases The objective of this task is to compile the environmental models and databases for the HiFiEDL simulator and to understand and gain familiarity with the various data access routines. In addition the data access routines should be analyzed with respect to their suitability for performing in the non-RT and RT environments. The environmental models and databases for Mars, the Earth, and the Moon are considered a minimum. Inputs: • Open literature • Contractor’s knowledge base. • Publicly available models and databases. • TNs 1 to 3 and the HiFiEDL Simulator URD and ADD. Description: • Identification of the environmental factors which play a role in the EDL system for Mars,

Moon, and the Earth, such as the atmosphere and the planetary gravity field and topography.

• Identification of the available databases and models for the simulation environment. • Eventual download (from public sources) and compilation of the databases. • Collection of the models and development of their analytical formulation. E.g., the

expression of the atmospheric density as a function of altitude. • Identification of the methods of accessing the databases and eventual testing of the

database access tools. • Specification of interfaces to the databases access routines and analysis of the existing

interfaces with respect to RT version of the simulator. • If the database access routines are not compatible with the RT use of the simulator

solutions should be identified and specified.

• Specification of the simulator environment models and database architectures and libraries.

Outputs: • TN 4: “HiFiEDL Simulator Environmental Models and Databases Design and

Implementation” • TN 5: “HiFiEDL Simulator Environmental Models and Database Access Interfaces

Definition” • Environmental databases.

Task 4: Collection of the HiFiEDL Simulator Aero-thermodynamics, Parachute, Airbag and Landing Legs Models and Databases The objective of this task is to compile the EDL component models and databases for the purpose of modeling the aero-thermodynamics subsystem of the EDL system during the aero-shell, supersonic and subsonic parachute sub-phases. In addition the airbag and landing legs modeling is required for the study of touchdown dynamics. The EDL trajectory is part of this database. ASTOS [RD 22] is one of the tools which can be used to generate the trajectory. Inputs: • Open literature • Contractor’s knowledge base. • Publicly available models and databases. • TNs 1 to 5. Description: • Identification of the EDL system components which play a role in the aero-

thermodynamics and landing dynamics. For example (the list is not exhaustive): • Aeroshell • Supersonic parachute • Subsonic parachutes4 • Airbags, either vented or non-vented • Landing legs

• Identification of the available databases and models for the EDL system components. • Eventual download and compilation of the databases. • Collection of the models and development of their analytical formulation. E.g., the

expression of the airbag restitution coefficient as a function of the impact angle and terrain roughness.

• Identification of the methods of accessing the databases and eventual testing of the database access tools.

• Specification of interfaces to the databases access routines and analysis of the existing interfaces with respect to RT version of the simulator.

• If the database access routines are not compatible with the RT use of the simulator solutions should be identified and specified.

4 Note that there are many types of subsonic parachute designs. The contractor shall identify them and develop models for

each of the types.

• Specification of the EDL system component models and database architectures and libraries.

• Generate EDL reference trajectories for Mars, Moon, and Earth after consultation with Agency.

• Consolidate the preliminary critical technology activities development plan (TN 2 of Task 1.)

Outputs: • TN 2 (update): “Consolidated Critical Technology Activities Development Plan” • TN 6: “HiFiEDL Aero-thermodynamics Models, Databases, and Interfaces Specification” • TN 7: “HiFiEDL Parachute Aerodynamics Models, Databases, and Interfaces,

Specification” • TN 8: “HiFiEDL Airbags, Touchdown and Landing Legs Models, Databases, and

Interfaces Specification” • TN 9: “Description of the EDL Reference Trajectories” • Aero-thermodynamics, parachute aerodynamics, airbag dynamics, landing legs dynamics

and EDL reference trajectory databases.

Task 5: Synthesis of Phase 1 Results The goal of this task is to gather all the results and consolidate and update the work to be performed during Phases 2a and 2b by taking into account the results of Phase 1. The contractor will prepare a revised and updated proposal for Phases 2a and 2b based on the results of Phase 1 and inputs from the Agency. Inputs: • All Phase 1 TNs. • Inputs and comments from the Agency. Description: • Analyse all the results of Phase 1 activities to prepare for the Phase 1 review and to

critically assess the Phase 2 programme or work. • Compile the Phase 1 technical data package containing all the approved and finalized

technical notes. • Prepare an updated and revised proposal for Phases 2a and 2b. • Prepare the Phase 1 technical data package for the PDR • Prepare an updated programme of work for Phases 2a and 2b if some tasks are judged not

necessary or other tasks have to be added. • Deliver an updated and revised proposal for Phases 2a and 2b. Outputs: • Updated and revised proposal for Phases 2a and 2b. • TN 10: Detailed implementation, test, and validation plan for Phases 2a and 2b. • Phase 1 technical data package. • Phase 1 final presentation handout • Environment and EDL system components databases.

3.3 Phase 2a The objectives of Phase 2a are to perform the detailed design, development, and unit testing of the environmental models and database interfaces and EDL system components models. During Phase 2a the databases and models will be integrated in the simulator and tested. The preliminary simulator validation plan generated in Phase 1 will be refined and prepared for the validation campaign of Phase 2b. For the purpose of testing and validating the simulator the contractor will reuse and, where needed, design GNC algorithms for the five architectures mentioned in the Background section. Note that the emphasis is on the reuse of GNC algorithms and tailoring of the existing GNC algorithms so that resources are allocated to the simulator development rather than to the GNC algorithm work. A beta version of the simulator software suite will be delivered and installed at ESTEC at the end of Phase 2a. The purpose of the beta version is to familiarize ESTEC personnel with the simulator. Comments on the simulator configuration, execution, and post-processing will be collected. The comments will be analyzed and those selected for implementation, upon Agency approval, will be implemented in the simulator by the contractor. The contractor should provide a plan which will describe the process of filtering and selecting ESTEC users comments and implementing them in the software suite before proceeding with the testing and validation. The following tasks have been identified for Phase 2a.

Task 6: Integration and Validation of Environmental Models and Database Access Routines The goal of the task is to integrate and validate environmental models and the environmental database access routines needed to retrieve and provide data to the simulator. Inputs: • Phase 1 technical data package. Description: • If the database access routines exist they should be modified or at least wrapped around in

functions which satisfy the simulator requirements specified during Phase 1. • Write new routines to provide data to the simulator. • Test and validate the routines against experimental and/or mission data. • If needed, design and implement algorithms that describe the behavior of the models. • Write-up the test results. Outputs: • HiFiEDL simulator database and data access routines library • TN 11: “HiFiEDL Simulator Environmental Database Test and Validation Results.”

Task 7: Development, Design, Implementation and Test of EDL Subsystems and Components Models The goal of this task is to perform the detailed design, develop, and test the EDL component models. During this task functionality will be added to the models specified in Task 1.

Inputs: • Phase 1 data package. • Commercial software tools such as a multi-body dynamics simulator • License-free software such as PANGU, which will be delivered in object code.[According

the Contract the PANGU software can be disclosed in object code, source code can be disclosed only after the prior written consent of the University of Dundee, VHDL cannot be disclosed neither in object nor in source code- no sub-license right of the Agency]

Description: • Perform the detailed design of the EDL component and subsystem models. • Perform unitary tests of each component model and compile the test results. • Integration of component models into subsystem models. For example:

o The subsonic parachute aerodynamics model is part of a multi-body dynamics model together with the landing system.

o Separation dynamics and collision monitoring between the aeroshell and the lander. • Develop post-processing routines for analysis of the test results. The routines should be

able to compare and display graphically, where appropriate, multiple test data sets. • If needed, design and implement integration algorithms for the integration of the equations

that described the dynamics behavior of the models. • Design, implement, and test the EDL trajectory access routine. • Write-up the model test results and conclusions. • Reconsolidate the critical technology activities development plan (TN2). Outputs: • EDL Subsystem and Component Models Library • Updated/revised version of TN 2: “Reconsolidated Critical Technology Activities

Development Plan” • TN 12: “Description of the Mathematical Models of the Simulator Suite Components” • TN 13: “HiFiEDL Simulator Component and Subsystem Test and Validation Results”

Task 8: Coding, and Validation of GNC Algorithms The main objectives of this task are to code and validate GNC algorithms for the EDL phase. The emphasis is placed on reuse and retuning of as many GNC algorithms as possible. The design and coding of the database access routine for loading the EDL trajectory is also part of this task. Inputs:

• Open literature. • Existing EDL GNC algorithms from the Contractor’s knowledge base. • Phase 1 data package. • TNs 10 to 13 Description: • Review the GNC algorithms employed for the EDL phase of the mission. • Adapt and retune any existing GNC algorithms.

• Demonstrate the controllability and stability and determine the robustness margins of the GNC algorithms.

• If needed design, after consultation with the Agency, code, and test, a set of new GNC algorithms to be implemented for testing the simulator.

• Design and code the EDL reference trajectory access routines. Outputs: • GNC algorithms library • TN 14: “HiFiEDL GNC Algorithms Coding, Test, and Validation”

Task 9: Integration and Testing of the Non-Real-Time HiFiEDL Simulator The goal of this task is to integrate the EDL subsystems and environmental models in the non-RT HiFiEDL simulator suite and to perform tests of the integrated simulator for the five test cases described in Section 3.1. During this task the non-RT part of the “Preliminary HiFiEDL Simulator Verification and Validation Plan” will be updated and finalized.

At the completion of the task a “beta” version of the non-RT simulator software suite will be delivered and installed at ESTEC. The beta version of the suite will be used to familiarize the ESTEC users with the simulator. Comments on the simulator configuration, execution, and post-processing will be collected. The comments will be analyzed and those selected for the implementation will be implemented in the simulator by the contractor. The contractor should provide a plan which will describe the process of filtering and selecting ETEC users comments and implementing them in the software suite before proceeding with the testing and validation.

Inputs: • Phase 1 data package. • All the Phase 2a outputs generated so far. Description: • Integrate the environmental models and the database access routines in the simulator. • Integrate the EDL subsystems and test them for each sub-phase of the EDL phase in non-

RT and for each of the five cases described in Section 3.1. • Fix bugs, assess performance, and identify any improvements that would be beneficial to

the simulator. • Write-up the integration and test results. • Prepare the documentation for the critical design review (CDR) and test readiness review

(TRR). • Define an installation plan for the non-RT simulator suite at ESTEC. • Deliver and install the beta version of the non-RT simulator suite at ESTEC. Outputs: • TN 3-1/25 (update): “Updated HiFiEDL Simulator Verification and Validation Plan –

Non-RT Part” 5 The 1/2 symbol identifies part one of two of the same document, in this case TN3.

• TN 15-1/2: “Plan for Filtering Selecting and Implementing User’s Comments in the Simulator Suite - Non-RT Part”

• TN 16-1/2: “HiFiEDL Integrated Simulator Suite Test Results – Non-RT Part” • TN 17-1/2: “HiFiEDL Simulator Suite Installation Plan – Non-RT Part” • Integrated HiFiEDL simulator suite (beta version) • The simulator suite configuration and initialization files for the five architectures required

in Section 3.1. • Updated “HiFiEDL Simulator Software Configuration File (SCF)” for the five cases

required. • Preliminary “HiFiEDL Simulator Software Release Document (SRD)” • Preliminary “HiFiEDL Simulator Software User Manual (SUM)”

Task 10: Integration and Testing of the Real-Time HiFiEDL Simulator The goal of this task is to integrate the EDL subsystems which are part of the EDL system architectures with closed loop control and the environmental models in the HiFiEDL simulator and to perform tests of the integrated simulator. There is a one-to-one mapping of the required high-fidelity simulator modules and the RT simulator modules shown in Figure 1. It is expected that the RT test runs will be based on the mission architectures tested in the integrated non-RT version which have at least one sub-phase controlled in closed loop. Some of the RT test runs might show that bug fixes or improvements to the non-RT are needed. The architecture of the RT testbed specified in Task 2 should be updated and refined during this task. During this task the RT part of the “Preliminary HiFiEDL Simulator Verification and Validation Plan” will be updated and finalized. The RT testbed used for the integration and testing work should employ LEON2 (or newer) boards for running the GNC algorithms. At the completion of the task a “beta” version of the RT simulator software suite will be delivered and installed at ESTEC. The beta version of the suite will be used to familiarize the ESTEC users with the simulator. Comments on the simulator configuration, execution, and post-processing will be collected. The comments will be analyzed and those selected for the implementation will be implemented in the simulator by the contractor. The contractor should provide a plan which will describe the process of filtering and selecting ETEC users comments and implementing them in the software suite before proceeding with the testing and validation. Inputs: • Phase 1 data package. • All the Phase 2 outputs generated so far. Description: • Procure all necessary Hardware for the development of the real-time HiFiEDL Simulator • Integrate the environmental models and the database access routines in the RT simulator. • Integrate the EDL subsystems and test them for each sub-phase of the EDL phase in non-

RT and RT. • Perform integration tests on the RT testbed. • Fix bugs, assess performance, and identify any improvements that would be beneficial to

the RT simulator and testbed. • Write-up the integration and test results. • Prepare the documentation for the critical design review (CDR) and test readiness review

(TRR).

• Deliver and install the beta version of the non-RT simulator suite at ESTEC. Outputs: • TN 2 (update): “Reconsolidated Critical Technology Activities Development Plan” • TN 3-2/2: “Updated HiFiEDL Simulator Verification and Validation Plan – RT Part”

(Update of TN3) • TN 15-2/2: “Plan for Filtering Selecting and Implementing User’s Comments in the

Simulator Suite - RT Part” • TN 16-2/2: “HiFiEDL Integrated Simulator Suite Test Results – RT Part” • TN 17-2/2: “HiFiEDL Simulator Suite Installation Plan – RT Part” • Integrated RT HiFiEDL Simulator (beta version) • Updated “HiFiEDL Simulator Software Configuration Item List (SCIL)” • Updated “HiFiEDL Simulator Software Configuration File (SCF)” for the five cases

required • Updated “HiFiEDL Simulator Software Release Document (SRD)” • Updated “HiFiEDL Simulator Software User Manual (SUM)” • Hardware necessary for the development of the real-time HiFiEDL Simulator

3.3 Phase 2b The goal of this phase is to validate and verify the simulator in both non-RT and RT configurations. It is envisioned that the non-RT and the RT campaigns will be conducted in an iterative process, the results of one campaign being used to update and improve the other. The first step of the iterative process is the implementation of the selected user’s comments according to the TN 15 Parts 1 and 2 (“Plan for Filtering Selecting and Implementing User’s Comments in the Software Suite – RT and Non-RT Parts.”) At the end of the phase the contractor will perform an overall study synthesis, give a final presentation of the work performed, and will go through the simulator acceptance review (AR) at ESTEC. Part of the AR is the low-fidelity version of the simulator at the ESTEC CDF laboratory.

Task 11: Non Real-Time HiFiEDL Simulator Verification and Validation Campaign The goal of this task is to verify and validate the non-RT version of the integrated HiFiEDL simulator. Test should be performed for the mission definition, and for the analysis of the five mission architectures three for Mars, one for the Moon, and one for the Earth, as specified in Section 3.1. Inputs: • Phase 1 data package. • All Phase 2a outputs. • Comments form ESA regarding the Beta version of the simulator Description: • Implement user’s comments and any other modifications resulting from the validation and

verification process of the simulator suite. • Test of the simulator for the mission definition application for each of the five EDL

system architectures described in Section 3.1.

• Based on the mission definition results analyse the GNC algorithms (where applicable) for the five architectures. The analysis shall include Monte Carlo campaigns.

• Prepare the non-RT test campaign report. • Prepare a non-RT simulator suite acceptance test plan. • Perform testing to ensure that the Agency’s comments have been implemented before

validation. Outputs: • TN 18: “Integrated Non-Real-Time HiFiEDL Simulator Suite Verification and Validation

Campaign Results” • TN 19-1/2: “HiFiEDL Simulator Suite Acceptance Test Plan – Non-RT Part”

Task 12: Real-Time HiFiEDL Simulator Verification and Validation Campaign The goal of this task is to verify and validate the RT version of the integrated HiFiEDL simulator. The test shall be performed with a representative processor-in-the-loop board, i.e., LEON2 or newer. Inputs: • Phase 1 data package. • All Phase 2a and 2b outputs generated so far. • Comments form ESA regarding the Beta version of the simulator Description: • Implement user’s comments and any other modifications resulting from the validation and

verification process of the simulator suite. • Test of the simulator for the mission definition application for the EDL architectures

tested in non-RT which have sub-phases with closed loop control. • Based on the mission definition results analyse the RT behavior of the GNC algorithms

for the architectures where closed loop control systems have been used. • Prepare the RT test campaign report. • Prepare a RT simulator suite acceptance test plan • Perform testing to ensure that the Agency’s comments have been implemented before

validation. Outputs: • TN 20: “Real-Time Integrated HiFiEDL Simulator Verification and Validation Campaign

Results” • TN 19-2/2: “HiFiEDL Simulator Suite Acceptance Test Plan – RT Part”

Task 13: Overall Activity Synthesis The goal of this task is to gather all the documentation of Phases 1 and a-b and prepare a synthesis of the overall activity. At the final presentation which will be held at ESTEC the contractor will install the simulator and go through the Acceptance Review (AR)..

The project synthesis shall cover as a minimum: design synthesis, software implementation, validation and verification process, autonomy and recovery capabilities, functional and robustness performances, operational interfaces, and last but not least technology development and evolution capability. Inputs: All Phases (1, 2a and 2b) outputs. Description: • Compile the final technical data package containing all the approved and finalized

technical notes. • Analyse all the results of Phases 1, 2a, and 2b and write-up the executive summary. • Suggest further technological developments and upgrades and evolution of the simulator

hardware or software. • Finalize the critical technology activities development plan. • Provide a simulator maintenance plan (RQ 22) • Install the HiFiEDL simulator and demonstrate it during the formal acceptance review

and final presentation at ESTEC. Outputs: • Technical data package. • Final critical technology activities development plan • Summary report, abstract and final presentation. • Installation review report and handout. • Acceptance review report and handout. • Animation of each of the five mission types. • HiFiEDL simulator software suite (including the low, medium and high fidelity versions

of the simulator as well as the RT version and their associated databases and database access routines).

• Hardware procured in the frame of the present activity

Task 14: Maintenance and Update of the Database Under this Task, the HiFiEDL simulator software suite shall be maintained and updated for a period of 1 year following the Final Acceptance of the Software by the Agency. New information and possible corrections shall be included as a minimum on quarterly basis. The outputs of this Task are quarterly maintenance reports and an updated HiFiEDL simulator software suite with its auxiliary tools. Any and all updated versions of the database shall be delivered including permanent licenses in object and source code. Output: Quarterly maintenance reports.

4. Management, Reporting, Requirements and Deliverables The standard requirements for Management, Reporting, Meetings and Deliverables (Appendix 2 to the Contract) shall apply to the present activity, taking into account the following specific requirements, which shall prevail (the numbering refers to the above mentioned Appendix 2 to the contract).The additions or modifications are numbered in accordance with the standard requirements. 1. MANAGEMENT (1.2.) All key personnel shall be available via e-mail. Within two (2) working days after the kick- off of the activity the Contractor shall provide to the Agency the communication particulars of the key personnel (name, position, telephone, fax, e-mail address).

2. REPORTING

(2.1) Minutes of Meeting

Minutes of meetings shall be delivered to the Agency's technical representative in 2 copies.

(2.7). Reporting-Technical Documentation

The progress reports shall be issued by the Contractor once a month and shall be delivered to the Technical Officer through e-mail as Microsoft Word files. Any graphics shall be included in the Word file as JPEG encoded images.

The maintenance reports shall be issued by the Contractor quarterly in an electronic format to be agreed at the Kick-Off Meeting.

All reporting and technical documentation produced during the course of the activity shall be delivered to ESA in electronic format, either as e-mail attachments or on CD-ROM (3 copies) in an electronic format to be agreed at the Kick-Off Meeting, in addition to the specified number of hardcopies.

During the execution of the project, the Contractor shall prepare and deliver the following reports, within the corresponding work-package, in a timely manner.

Each report shall be first delivered in an electronic draft version for the approval of the Agency and in one (1) paper copy. Once approved, for each report two (2) paper copies shall be delivered within two (2) weeks after the Agency’s review is completed or the Agency’s approval is provided according to the table below. The final reports shall be also delivered in electronic form.

In case the documentation is associated with a meeting (e.g. PM, handouts for final presentation), a draft version shall be delivered at least two (2) weeks in advance of the meeting.

The documents to be delivered in the course of the activity are the following:

Table 1. Phase 1 Technical Documentation. The document type column specifies A for “approval required from the Agency” and R for “review only.”

# Title Task Type TN 1 EDL System Architecture Definition and Specification 1 A TN 2 Preliminary Critical Technology Activities Development Plan 1 R URD HiFiEDL Simulator User Requirements Document 1 A ADD HiFiEDL Simulator Architecture Design Document 2 A TN 3 Preliminary HiFiEDL Simulator Verification and Validation Plan 2 R

- System Requirements Review Report and Handout 2 A SCIL Preliminary HiFiEDL Simulator System Configuration Item List 2 R SCF Preliminary HiFiEDL Simulator Software Configuration File 2 R TN 4 HiFiEDL Simulator Environmental Models and Databases Design and Implementation 3 R TN 5 HiFiEDL Simulator Environmental Models and Databases Access Interfaces Definition 3 R TN 2 update

Consolidated Critical Technology Activities Development Plan 4 R

TN 6 HiFiEDL Simulator Aero-thermodynamics Models, Databases and Interfaces Specification

4 R

TN 7 HiFiEDL Simulator Parachute Aerodynamics Models, Databases and Interfaces Specification

4 R

TN 8 HiFiEDL Simulator Airbags , Touchdown and Landing Legs Models, Databses and Interfaces Specification

4 R

TN 9 Description of EDL Reference Trajectories 4 A - Updated and revised proposal for Phases 2a and 2b 5 A

TN 10 Detailed Implementation, Test, and Verification and Validation plan for Phases 2 and 3 5 A - Phase 1 Technical Data Package 5 A - Phase 1 Presentation Handout 5 R

Closure of Phase 1 shall deliver a complete Phase 1 technical data package and an updated and revised proposal for Phases 2a and 2b.

Table 2. Phase 2a Technical Documentation. The document type column specifies A for “approval required from the Agency” and R for “review only.”

# Title Task Type TN 11 HiFiEDL Simulator Environmental Models and Databases Test and Validation

Results 6 R

TN 2 update

Reconsolidated Critical Technology Actitvities Development Plan 7 R

TN 12 Description of the Mathematical Models of the Simulator Suite Components 7 R TN 13 HiFiEDL Simulator Components and Subsystems Test and Validation Results 7 R TN 14 EDL GNC Algorithms Design, Coding, Test, and Validation 8 R

TN 3-1/26 update

Updated HiFiEDL Simulator Verification and Validation Plan – non-RT part 9 A

TN 15-1/2 Plan for Filtering Selecting and Implementing User’s Comments in the Simulator Suite – Non-RT Part

9 A

TN 16-1/2 HiFiEDL Integrated Simulator Suite Test Results – Non-RT Part 9 R TN 17-1/2 HiFiEDL Simulator Suite Installation Plan – Non-RT Part 9 A

SCF Updated HiFiEDL Simulator Software Configuration File 9 R SRD Preliminary HiFiEDL Simulator Software Release Document 9 A SUM Preliminary HiFiEDL Simulator Software User Manual 9 A TN 2 update

Reconsolidated Critical Technology Activities Development Plan 10 R

6 The symbol 1/2 represents part one of two of the same document, in this case TN3.

TN 3-2/2 Update

Updated HiFiEDL Simulator Verification and Validation Plan – RT Part 10 A

TN 15-2/2 Plan for Filtering Selecting and Implementing User’s Comments in the Simulator Suite – RT Part

10 A

TN 16-2/2 HiFiEDL Integrated Simulator Suite Test Results – RT Part 10 R TN 17-2/2 HiFiEDL Simulator Suite Installation Plan – RT Part 10 A

SCIL Updated HiFiEDL Simulator Software Configuration Item List 10 R SCF Updated HiFiEDL Simulator Sofware Configuration File 10 R SRD Updated HiFiEDL Simulator Software Release Document 10 R SUM Updated HiFiEDL Simulator User Manual 10 A

Closure of Phase 2 shall deliver a complete Phase 2 technical data package.

Table 3. Phase 2b Technical Documentation. The document type column specifies A for “approval required from the Agency” and R for “review only.”

# Title Task Type TN 18 Integrated Non-RT HiFiEDL Simulator Suite Verification and Validation

Campaign Results 11 R

TN 19-1/2 HiFiEDL Simulator Suite Acceptance Test Plan – Non-RT Part 11 A TN 20 Integrated RT HiFiEDL Simulator Suite Verification and Validation

Campaign Results 12 R

TN 19-2/2 HiFiEDL Simualator Suite Acceptance Test Plan – RT Part 12 A - Technical Data Package 13 A - Summary report, abstract and final presentation handout 13 R - Final Critical Technology Activities Development Plan 13 A - Acceptance Review Report and Handout 13 A

Upon the closure of Phase 2b the Contractor shall deliver the consolidated and final data package, synthesis report, and executive summary. 3. MEETINGS The Agency intends to follow up the execution of the Contract through dedicated meetings: the Kick-Off Meeting, Progress Meetings (PM) and a Final Presentation. The following meeting plan is proposed:

Name Description Location Comments Phase Time KoM Kick-Off Meeting ESTEC - - T0 PM 1 At the completion of Task 2 Contractor SRR at the same time 1 T0 + 2

PM 2 At the compeletion of Task 5 and end of Phase 1 ESTEC PDR at the same time 1 T0 + 5

PM 3 At the completion of Task 6 Contractor - 2a T0 + 8 PM 4 At the completion of Task 8 Contractor DDR at the same time 2a T0 + 11

PM 5 At the completion of Task 10 and end of Phase 2 ESTEC CDR and TRR at the

same time 2a T0 + 15

PM 6 At the completion of Task 11 Contractor QR at the same time 2b T0 + 17

Final At the completion of Task 12 and end of activity ESTEC AR at the same time 2b T0 + 18

4. DELIVERABLES

(4.1.1) Final report: shall not apply.

(4.1.2) Technical Data Package and Summary Report : shall apply with the following specific conditions:

The Technical data package shall contain the final version of all documentation (technical notes, handouts, summary report, abstract) produced during the overall duration of the contract.

Technical Data Package:

The final Technical data-package consisting of all approved Technical Notes shall be delivered in five (5) paper copies (4 bound and 1 unbound) and in two (2) CD-ROM packages standard ISO 9660, one containing all documents in protected *.pdf format (10 copies) and one containing all documents both in *.doc, *.ppt and *.pdf formats (1 copy). All documents shall be included as hyperlink in the data package table of content.

The CDs shall compile all documentation in logic order. Each CD shall contain a table of content with direct links to the respective documents as well as a printed table of content on the back of the CD cover indicating the content of the document as well as the document number. The front cover of the CD shall display the name of the project, the subtitle, the date, the volume, issue and name of the author of the CD.

Summary Report: shall apply.

Abstract: shall apply. The abstract shall be written for a highly recognized technical conference.

Summary Report and Abstract : A Summary Report shall be prepared and delivered in electronic format. An electronic version shall be delivered for publication on the ESA web page without any reservation or limitation whatsoever.

It shall be compiled in a self-contained way and shall cover all aspects of the activities carried out. The Contractor shall also present in the Summary Report conclusions and recommendations for fields of future work.

The Summary Report and the Abstract shall be first delivered in a draft version in electronic form for approval by the Agency at least four (4) weeks before the end of the Contract and shall be updated including the Agency’s comments, if any.

The final versions of the Summary Report and the Abstract shall be delivered to the Agency within four weeks after receipt of comments in five (5) CD-ROM and five (5) paper copies (4 bound and 1 unbound).

(4.3) Photographic documentation: shall apply. The photographs shall be provided in one of the electronic format: GIF, JPEG or BMP.

(4.4) Hardware: shall apply: • Hardware necessary for the development of the real-time HiFiEDL Simulator (Task 10) • Any and all hardware procured and /or manufactured under this activity is deliverable at

the end of the contract.

(4.5).Computer Programmes: shall apply. - HiFiEDL simulator software suite in object and source code(all source codes shall be provided for validation and migration pruposes) All software packages shall be delivered including permanent licenses and sub-licenses. In addition, any specially developed software shall be delivered in object and source code. Additionally, concerning mathematical models, the Contractor shall deliver, within the corresponding work packages, in a timely manner, the input/output data used in the analyses on the media and in the formats agreed with ESA. When applicable, mathematical and CAD models shall be delivered to ESA on a regular basis for assimilation and checking purposes. Proper means to identify the different versions of the models shall be provided by the Contractor.

Mathematical models shall be produced, if deemed practical, using commercially available software, e.g. for control design, multi-body dynamics, contact mechanics and structural Finite Elements Analysis/Modeling (FEA/FEM). Mathematical and CAD models shall be, if deemed practical, produced and delivered in a standard file exchange format, so that they can be read by other software, e.g. STEP, IGES or SET interfaces.

5. COMMERCIAL EVALUATION: shall not apply.

5. AGENCY’S ESPONSIBILITIES AND INTERFACES The contractor shall be responsible for managing, performing and documenting all the tasks defined in this SOW. As far as this activity is concerned the Agency will: 1. Provide the following: PANGU user sub-license (object code) 2. Act as the only interface between this contractor and the contractors of the below mentioned technology activities. The contractor is hereby informed that ESA is running or intends to run, in parallel to the present activity, the following technology activities of relevance for this activity: - Planet and Asteroid Natural Scene Generation Utility (PANGU) Enhancement (ITT 5320) - Robust EDL Guidance and Control Techniques (Planned ITT) Whenever available and if relevant, the Agency will provide the contractor with inputs from the above activities as the Agency sees it fit and to its full discretion. However, these inputs shall in no case replace the tasks required from the contractor within this SOW and have to be deemed as support material only. In no case shall results from the activities mentioned above be disclosed to third parties or be used by the Contractor for purposes other than the performance of the present activity without the prior written consent of the Agency.

Annex 1: Technical Background & Requirements A1.1. Acronyms

ACS Attitude Control System AIT Assembly, Integration, and Testing AoA Angle of Attack AR Acceptance Review ARD Atmospheric Re-entry Demonstrator ATP Authorization To Proceed CDR Critical Design Review CFD Computational Fluid Dynamics DDR Detailed Design Review EDL Entry, Descent, and Landing FES Functional Engineering Simulator GNC Guidance, navigation, and control HIL Hardware-In-the-Loop IMU Inertial Measurement Unit KoM Kick-off Meeting MPS Mission Performance Simulator PDR Preliminary Design Review PIL Processor-In-the-Loop PM Progress Meeting QR Qualification Review ROM Rough Order of Magnitude R&T Research and Technology RT Real-time SCS Systems Concepts Simulator (low fidelity) SIL Software-In-the-Loop SRR System Requirements Review TN Technical Note TRL Technological Readiness Level TRR Test Readiness Review V&V Verification and Validation

A1.2 Technical background The Agency has initiated several technology development activities to investigate advanced guidance navigation and control (GNC) algorithms for EDL. So far the advanced GNC algorithms have been designed in an ad-hoc manner on separate portions of a typical entry, descent and landing (EDL) profile, such as the hypersonic entry phase or the powered descent phase. The performance of the GNC algorithms has been validated on disparate simulation tools. For example, ESA’s Aero-assisted Technologies for Planetary Exploration (ATPE) activity [RD 1] is a simulator used for missions requiring aero-assist. ATPE can be used to perform mission definition analysis, design and analyze GNC algorithms, test the GNC algorithms on a real-time on-board computer test board. However it does not address a few other key aspects such as a highly detailed parachute + lander model or landing on airbags. ATPE also lacks the interfaces to other tools, such as those described below. Another tool developed for the Agency is the Parachute System Design and Analysis (PASDA) [RD 20]. PASDA is “an integrated software tool used to design and analyze

parachute systems for space related applications and to provide the environment for collecting and storing parachute related information and missions.” It consists of several modules, including trajectory simulation, parachute design and analysis, database access routines, and the ability to include user written routines. SPADES [RD 23] is an EDL systems preliminary design and analysis tool under development at the Surrey Space Centre. An example of a tool applicable to the landing sub-phase of the EDL is the vision based navigation tool (VBNAT) [RD 2]. VBNAT is used to analyse and validate vision based autonomous navigation algorithms. The capabilities of the tool has been extended so that in can use a simulated light detection and ranging (LIDAR) subsystem for navigation and hazard avoidance [RD 3]. In conjunction with VBNAT a planet/asteroid surface generation tool has been developed under an ESA contract. The tool is called the Planet and Asteroid Natural-scene Generation Utility (PANGU) [RD 4] and it is employed to generate simulated surfaces of planets/asteroids and for producing images of those surfaces from specified camera positions and orientations. For example, PANGU can provide images of the Martian surface to a LIDAR or camera based sensor model in VBNAT. Two complementary end-to-end EDL design and analysis tools have been described in the open literature at the time of this writing [RD 5]. They have been developed at the NASA Langley and JPL centers. One of the tools is based on the Program to Optimize Simulated Trajectories II (POST2). The enhanced POST2 is employed to perform simulations for a wide spectrum of uses, from mission definition studies all the way up to Monte Carlo simulations. The other tool is based on the Dynamics Simulator for Entry, Descent, and Surface landing (DSENDS). DSENDS has been adapted to perform high-fidelity real-time (RT) EDL system simulations. The simulator is capable to provide RT modeling of the flexible EDL system dynamics, as well as execute in RT models of the EDL system sensors and actuators. The lack of features in ATPE and PASDA and the "patchwork" approach in simulating the EDL phase is not sufficient for future Mars missions requiring safe precision landing where extensive closed-loop actions, throughout the EDL phase, will be required from the GNC subsystem. For proper verification and validation of the critical EDL sub-systems it is desired that the complete simulation of the autonomous operations and transitions during the EDL phase of the mission is performed with a single tool. A typical Mars EDL system configuration consists of a lander inside an aeroshell, supersonic parachute, subsonic parachute, and a landing system. The sub-phases and the typical events occurring during each of the sub-phases of the EDL are illustrated in Figure 2 and explained below. Four main sub-phases can be identified during the EDL. The first sub-phase spans the time between the last trajectory correction maneuver and the atmospheric entry. The transfer trajectory and its covariance are updated after the last TCM. Prior to entry in the atmosphere the carrier separates from the lander. After separation the ground support team has no way to update the trajectory data and compute its covariance. The main sources of errors in this sub-phase are the lander trajectory changes due to the carrier-lander separation dynamics. The second sub-phase will be called the hypersonic sub-phase and for a Martian EDL it begins at the point at atmospheric entry. This is the point where the aerodynamic effects start being felt. In Figure 2 the altitude of the atmospheric interface is about 120km as is the case for most of the studies undertaken so far. After the atmospheric entry the EDL system is decelerated using the aeroshell. During this period the dynamic pressure and heat load reach a maximum. Most of the kinetic energy of the EDL system is removed during this part of the EDL phase. The deceleration can be performed on a ballistic or non-lifting trajectory or on a lifting trajectory with a constant bank angle and angle of attack (AoA) (Viking-like) or with bank angle modulation (Apollo-like). Modulation of the AoA is also envisioned for changing the drag to lift ratio of the vehicle. Once a certain height and velocity have been reached the aeroshell is discarded and the supersonic, or drogue, parachute is deployed. The supersonic parachute improves the stability during the transonic phase and slows down the EDL system to subsonic speed. When a certain speed is reached the supersonic parachute is jettisoned and the subsonic, or main, parachute is deployed. The main sources of errors for this phase are the

navigational errors at the atmospheric interface and the vehicle aero-thermodynamics properties. The third sub-phase will be called the parachute sub-phase and its main characteristic is the aerodynamic deceleration of the EDL system with a parachute. The subsonic parachute slows the lander to the terminal velocity and curves the trajectory to become almost vertical. The deviation from a vertical parachute descent or drift is due to the winds aloft. The subsonic parachute descent can be left uncontrolled, or the drift due to the wind can be cancelled with the thrusters, sometimes referred to as transverse impulse rocket system (TIRS) thrusters, or by controlling the parachute (reefing.) The main source of errors during this sub-phase is the wind drift. It is to be noted here that the TIRS is not considered as part of a powered descent system since the lander is still connected to the parachute at the time of the TIRS activation. The fourth and last sub-phase in the EDL is the landing sub-phase. Once a certain altitude over the landing spot is reached the parachute riser line is cut. Two options have been identified for touchdown so far: the hard touchdown and the soft touchdown. For the hard touchdown a set of airbags are inflated and the lander free falls from a certain altitude after the riser line to the subsonic parachute is cut. The energy of the impact is absorbed by airbags. Two types of airbags might be used. The first type is a vented airbag which is deflated by the shock of the touchdown. The deflation is controlled by accelerometers. The other type of airbags is the non-vented. They absorb the energy of the landing by bouncing to a stop. NASA’s Mars Exploration Rovers employed a one-shot vertical velocity and separation control system. The system was made of solid rocket thrusters installed on the back cover of the aeroshell. The ignition of the thrusters was initiated at a certain altitude and the riser raiser line was cut just prior to the depletion of the thrusters. The system is not considered as part of a powered descent system since the lander was still connected to the parachute at the time of the thruster activation. The soft touchdown option employs rocket descent engines, or retro-engines, to slow the descent of the lander even further, to a (downwards) velocity of one or two meters per second. The retro engines are turned on after the lander separates from the subsonic parachute. During the powered descent, i.e. when the retro engines are operational, the lander can determine its altitude with a radar-altimeter. In addition to the radar-altimeter a Doppler velocity sensor (DVS) can be used to estimate the velocity of the lander with respect to the surface in three axes. To achieve pin-point landing a LIDAR or a camera (vision based) navigation system can be used to navigate and detect hazards. Using these sensors the lander can autonomously take decisions to change and remove as much of the errors as possible and modify the descent trajectory to avoid hazards. The retro engines are cut-off one or two meters above the surface and the lander free falls to touch down. The shock of the touchdown and any terrain variations are accommodated by the landing gear. The influence of structural vibrations due to the operations of the thrusters and to the leg deployment dynamics on sensitive navigation equipment such as a camera or LIDAR should be taken into account in this phase.

Figure 2. Example sequence of events during the Mars EDL phase. FPA stands for the flight path angle. Not to scale. The mission architectures can be derived from the EDL sub-phases and subsystems described above. Three of the many possible architectures are tabulated in Table 4. The simplest and least accurate architecture is type 1. The expected performance from a type 1 mission is on the order of tens of km for the semimajor axis of the landing ellipse. For example the Mars Pathfinder was 135km off the target and the Mars Exploration Rovers were 35km off [RD 19]. The landing accuracy of an architecture of type 2 is expected to be on the order of that of type 1. However the touchdown is performed on vented airbags. Two options (a and b) of deceleration during terminal descent can be employed. Option a is similar to that of a type 1 mission. The parachute provides all the deceleration down to the point where the riser line is cut, typically from a few tens of meters above the surface. The vented airbag has to be designed to handle any residual horizontal velocity and angular rates of the lander at the impact with the surface. Option b employs thrusters to decelerate after separation from the parachute which can take place at an altitude between of a few hundred to a few thousand meters. After separation from the parachute both the trajectory and the attitude of the lander are controlled in closed loop. The descent thrusters have the role of cancelling the horizontal velocity and the residual vertical velocity. The descent thrusters are turned off just before airbag inflation at an altitude of a few tens of meters above the surface. The most accurate architecture is that of type 3 and the accuracy goals are on the order of a few hundred meters from the target. This architecture is typical for sample return type missions where pinpoint landing accuracy is required. Pinpoint landing is need to provde access of a sample collection mission to a geographical feature designated of high interest for a sample return mission. The landing site has been studied and it has been determined that is hazard free. In the terminal descent phase, from a few km altitude, the lander employs a navigation sensor, could be either LIDAR or camera based, to compute the errors between the designated landing site and the one achievable given the lander current state vector. The GNC subsystem thrusters are employed to control the trajectory so that the error is minimized at touch down. It is most likely that an architecture of type 3 will employ landing legs, however the vented air bag option should also be included.

On the other hand a mission using hazard avoidance is designed to land in area of relatively high uncertainty. The obstacles, e.g. terrain slope or boulders over certain sizes, at the designated landing site are identified once in range of the sensor and a trajectory is planned if a certain danger level is detected. In addition to the three Mars EDL system architectures an Earth re-entry and a Lunar lander architecture are tabulated. The Earth re-entry architecture is a very simple aerodynamic deceleration only with a hard impact. This architecture is typical of a sample capsule re-entry such as NASA’s Stardust mission or ESA’s proposed Mars Sample Return (MSR). Last but not least, a Lunar landing mission is tabulated. To be noted here is that the Lunar lander is typical of a pinpoint landing mission. Due to the lack of atmosphere on the Moon the lander employs thrusters for decelerating from Lunar orbit or Lunar intercept trajectory to touchdown.

Hypersonic phase Lift and Drag

Bank Angle

Angle of attack

Subsonic parachute Touchdown

Airbags Typ

e

Bal

listic

Con

stan

t

Mod

ulat

ed

Con

stan

t

Mod

ulat

ed

Unc

ontr

olle

d

Con

trol

led

Non

-ve

nted

Ven

ted Leg

s

Prec

isio

n la

ndin

g an

d ha

zard

avo

idan

ce

Pow

ered

term

inal

des

cent

Mis

sion

type

M1 Yes No No No No Yes No Yes No No No No MER

a Yes No No No No Yes No No Yesa No No No ExoMars M2

b Yes No No No No Yes No No Yesb No No Yes ExoMars

M3 No No Yes No Yes No Yes No No Yes Yes Yes MSR@Mars

E1 Yes No No No No No Yes No No No No No MSR@EarthL1 N/A N/A N/A N/A N/A N/A N/A N/A N/A Yes Yes Yes Lunar

Landing

Table 4 Definitions of some EDL system architectures for various lander missions. Architectures types 1 to 3 are for Mars landers. Architecture type 1 is the simplest and least

accurate Mars lander and has been used successfully by NASA for the Mars Exploration Rovers. Architecture type 2 with its two subtypes is typical of ESA’s ExoMars mission. The

vented airbags option descends on parachutes only (2a) or can employ thrusters to slow down after separation from the parachute (2b). Architecture type 3 is the most complex and

accurate and it is typical of a mission such as ESA’s Mars Sample Return (MSR). The purely ballistic Earth re-entry architecture (E1) is typical of the MSR sample return capsule. The

Lunar lander architecture (L1) is typical for a precision landing mission. In this case all the deceleration is provided by thrusters.

The supersonic parachute phase has been left out from Table 4 for the sake of brevity. The supersonic parachute is employed to improve the stability during the high supersonic regime. The supersonic parachute is not employed if the EDL system employs AoA or bank angle modulation. All the building blocks of the architectures described in Table 4 will be developed during this activity. It is expected that the EDL component and subsystem and the environmental models are grouped in libraries which will provide the user the possibility to configure the HiFiEDL

Simulator as required by the mission to be studied. A preliminary HiFiEDL Simulator library structure is given in Figure 3. The models are linked together in the simulator and the integration of the equations of motion (EoM) describing the EDL system dynamics will be performed. Attention has to be paid to the numerical integration routines used to integrate the EoM and to preserve EDL system model integrity during transitions between EDL sub-phases. Most of the transitions are actually structural changes of the EDL system, such as the heat shield jettisoning and the parachute deployment. It is expected that a combination of analytical models and databases will be used to simulate the planetary environment which influences the EDL system. For example the density of the Martian atmosphere can be expressed analytically as a function of the altitude. The terrain elevation data is available as a set of binary data files with a resolution of 128x128 pixel per degree of longitude and latitude [RD 7]. The Goddard Mars gravitational model (GMM-2B) can be expressed as a spherical harmonic function with 80x80 terms [RD 8]. Last but not least atmospheric profiles, circulation models at global and meso-scales can be employed to obtain wind profiles on the entry trajectory. The Mars Global Reference Atmospheric Model (Mars-GRAM) is discussed in [RD 9] for example. The European Mars Climate Database can also be used to extract similar data as shown in [RD 15]. The term database is used here in a broad sense and should be understood as collection of data sets. For example the Mars Observatory Laser Altimeter (MOLA) surface elevation data are organized in binary data files of a certain format [RD 7]. Another example is the set of aerodynamic force and moment coefficients for the EDL system in the aeroshell configuration. The forces and moments will most likely be measured in wind-tunnel and drop-test experiments or computed with computational fluid dynamics (CFD) codes at discrete values of the angle of attack (AoA) with respect to the mainstream. The aerodynamics database thus compiled can be provided as a routine which uses a lookup table and performs interpolation between the data points. Another approach would be to perform the interpolation off-line, using polynomials or splines, and provide the routine with the coefficients of the interpolant. The wind profiles along the entry trajectory will be obtained from CFD simulations at global and meso-scales. The direction and magnitude of the velocity vectors are computed at a discrete number of points in a region containing the entry trajectory. The magnitude and direction of the wind velocity on the trajectory are provided by a routine which performs a three-dimensional lookup and interpolation. Another example is the airbag dynamics at contact with the surface. The acceleration as a function of the surface properties, and the impact parameters such as velocity, atittude, and attitude rate, should be estimated, tabulated, and provided to the simulator either as a database or an interpolation function. Some data, such as the aerodynamics coefficients vs. AoA, or the airbag restitution coefficient as a function of the surface properties, might not yet be available. In this case the contractor should use data from missions already flown or which are currently in development and propose a technology development plan for obtaining numerical and experimental data. The contractor can use some of the modules or components of ESA tools such as PASDA or ATPE. PASDA was programmed in FORTRAN under the Sun Solaris system and uses SQL for the database administration. Interfaces are required to use either the modules or the databases of PASDA7. ATPE on the other hand was developed in MATLAB/Simulink.. The selection of development/run-time environment is left at the latitude of the contractor. However the contractor shall prove to the Agency the portability of the environment, and its capability to satisfy the requirements listed below. The Agency requires the set-up of a toolchain which will generate “production quality” C code. For exaample, from Simulink, with tools such as dSPACE TargetLink. The (clean) C code will be a mirror of the Simulink library modules and will be used to perform RT simulations. In addition the C-code generated from Simulink can be used as software in the 7 Once intellectual property rights (IPR) have been clarified with the PASDA contractor and the Agency.

loop (SIL) to speed-up the execution of the Simulink models. Another advantage is that it allows various contractors to deliver binary object code to protect their copyrights and intellectual property. Critical to the development process is the use of a version control tool such as Concurrent Versioning System (CVS) or any other tool at the choice of the contractor.

Figure 3.Preliminary organization of the HiFiEDL simulator libraries. The contractor has

the freedom to organize libraries as seen fit and propose a different organization.

A1.3. Applicable technical requirements The following requirements have been identified for the HiFiEDL Simulator: RQ 1: The HiFiEDL Simulator software architecture shall be modular in order to be able to

support various landing mission architectures, as those shown in Table 4, throughout the lifecycle of the mission.

RQ 2: The low fidelity (low accuracy) version of HiFiEDL Simulator should have a data interface compatible to the ESTEC Concurrent Design Facility (CDF) Data Exchange formats [AD2].

RQ 3: The programming language used in the simulator shall be standard ANSI C. RQ 4: The HiFiEDL Simulator software architecture shall be open in order to allow running

on various operating system and platforms, such as Microsoft Windows, UNIX, and Mac OSX.

RQ 5: The HiFiEDL Simulator real-time testbed architecture shall be open in order to allow interfacing with various EDL system components for HIL tests.

RQ 6: The processor board employed to run the GNC algorithms of the architectures with closed loop shall be based on the LEON2 or newer processor.

RQ 7: All EDL system component models shall have at least three levels of accuracy. The less accurate models are expected to be executed fast so they can be used for preliminary mission definition and design. The more accurate models will be used in applications which require high accuracy and are employed to analyze the GNC subsystem.

RQ 8: All simulator software components shall be extendable and maintainable. RQ 9: Both the non-real-time and the real-time of the simulator shall be validated against the

Viking 1 and 2, Mars Pathfinder, Mars Exploration Rovers 1 and 2, Stardust, and ARD mission data.

RQ 10: In case of landing system based on non-vented airbags, all bounces from first impact to rest shall be simulated.

RQ 11: In case of landing system based on non-vented airbags or legs shall include a model of a horizontal velocity control system.

RQ 12: Data exchange interfaces between the simulator and ad-hoc tools such as PASDA shall be defined.

RQ 13: Data post-processing, visualization, and animation routines should be provided with the simulator.

RQ 14: Have the capability to perform batch mode processing for Monte-Carlo simulations to aid in the end-to-end dispersion analysis.

RQ 15: Have the capability to perform worst-case analysis. RQ 16: Have the capability to support hybrid discrete/continuous models. RQ 17: Have the capability for failures injection, signal or performance degradation errors. RQ 18: XML shall be used for delivering data dictionaries for auto-code generation. RQ 19: The assessment of the RT routines for both the environmental and EDL component

models in terms of schedulability and performance. RQ 20: Allow dynamic reconfiguration of the S/C and correctly propagate the system state

during transitions with structural changes. E.g. heat shield jettisoning or parachute deployment.

RQ 21: The simulator suite delivered to the Agency shall include the simulators at all levels of fidelity, including the RT version of the high fidelity simulator, their respective databases and the associated database access routines.

RQ 22: The simulation environment shall be platform independent. RQ 23: The simulator suite maintenance plan shall include a detailed description of the

processes needed to perform unit and integrated tests to ensure compatibility with future upgrades of the any commercial development, simulation, and analysis tools employed. E.g., MATLAB and Simulink.

Explanations to the requirements: E_RQ 1: The simulator is a suite of tools and its uses extend from the preliminary mission

definition work to real-time validation of GNC algorithms to operational mission support. As such it has to have the flexibility needed to provide perform all these functions. The flexibility comes from a modular software design.

E_RQ 2: Support for the CDF studies at ESTEC is part of the Phase 0 mission definition and system trades study. Thus the low fidelity version of the simulator is required to have an interface which exports data in a format compatible with the CDF data exchange format. The CDF data exchange format is specified in [AD 2].

E_RQ 3: Standard C is specified here as the programming language of choice for the simulator. This does not exclude the use of, say, MATLAB scripts for data plotting and analysis.

E_RQ 4: The openness of the simulator software architecture implies well defined function structures and interfaces. Together with the standard C programming language this will allow the simulator to be flexible, portable between various platforms, and to be easily modifiable and upgradeable.

E_RQ 5: The simulator will be used to provide operational support for missions. Thus it is required that the real-time testbed architecture allows interfacing with various EDL hardware engineering model sensors and actuators. The exact architecture of the EDL systems such as ExoMars is not well defined at the time of this writing. As details will become available they will provided to the contractor. The contractor is required to design “hooks” into the simulator where interface routines can be easily attached.

E_RQ 6: Fulfillment of this requirement will help with keeping the RT simulator in synch with the developments in the spacecraft on-board processors. It will also help define interfaces both at the HW or SW level that might need to be implemented for the lander application of LEON2.

E_RQ 7: This requirement is derived from the requirement that the simulator is used on a wide range of tasks. A mission definition task requires less accuracy than a GNC algorithm analysis task. For example during the mission definition study the subsonic parachute descent of the lander can be modeled as a pendulum, i.e., with low accuracy. For a GNC analysis task the subsonic parachute shall be modeled as a multi-body system which takes into account the flexibility of the parachute lines and harness.

E_RQ 8: The extendibility and maintainability are required in order to provide a growth path for the simulator. This requirement will ensure that as new data become available, either from mission or from experiments and numerical analysis the models used in the simulator can be upgraded.

E_RQ 9: Validation against mission data provides the highest confidence level in the models and databases used in the simulator.

E_RQ 10: For the non-vented airbags architectures the size of the landing ellipse is determined by the size, direction, and number of bounces.

E_RQ 11: Vented airbag are less robust than the non-vented airbags to horizontal movement at impact. Thus a lateral horizontal velocity control system should be modeled. In the case of the final descent performed with thrusters the closed loop commanding of the descent and attitude control thrusters shall cancel the horizontal velocity.

E_RQ 12: The interfaces will provide a way to exchange data with specialized tools which will allow further detailed investigation of the various EDL subsystems.

E_RQ 13: Large amounts of data are expected to be generated from the simulations. The contractor should provide routines which read the data and plot and visualize them. In addition animation routines are required so that the engineers using the simulator can get a visual, three-dimensional feed-back of the events during the EDL.

E_RQ 14: The batch processing is intended for Monte-Carlos simulations. E_RQ 15: The simulator suite should be able to perform worst case analysis in order to

identify the parameter space which produces the largest errors. The parameter space can then be used to guide the Monte-Carlo simulations.

E_RQ 16: The requirement for support for both continuous and discrete models is driven by the fact that the physics part of the simulation is modeled as a continuous system and some of the sensors and actuators of the EDL system operate in a discrete mode.

E_RQ 17: This requirement allows the users to inject errors in the EDL system in order to assess the robustness of the architecture and of the algorithms.

E_RQ 18: Use of data dictionaries simplifies the design and maintenance of interfaces between simulator modules. Use of XML allows the structuring of the data dictionaries in a natural and intuitive way.

E_RQ 19: This requirement is derived from the need to assess the schedulability of the routines which model the environment and EDL system components or access the databases. It is of paramount importance to test the ability of the models to run in RT.1

E_RQ 20: This requirement is coupled with the RQ 14: and emphasizes the need for the simulator to be able to perform discrete and continuous modeling of the EDL system dynamics.

E_RQ 21: This requirement clarifies and emphasizes the fact that the Agency requires all the versions of the simulator. As mentioned in the SoW various versions of the simulator will be used throughout the mission life-time.

E_RQ 22: Platform independence is required in order to ensure the usability of the simulator throughout the Agency and its subcontractors. It is also intended to facilitate the simulator maintenance process.

E_RQ 23: If the contractor employs any commercial development, simulation, and analysis tools then the contractor should define a strategy and plan for upgrades of the simulator to ensure compatibility of the simulator suite with upgrades of such tools.

Annex 2: Software Requirements List of ECSS-E40 applicable requirements ECSS-E-40 part 1B from 28 November 2003 5.2 System Engineering Processes related to software 5.2.2.1 System requirements specification 5.2.2.4 MMI general requirements and guidelines 5.2.3.1a System design 5.2.3.2a Software-hardware interface requirements 5.2.3.2c System partition with definition of items (HW, SW, human operation) 5.2.3.2d System configuration items list 5.2.4.2 qualification engineering requirements (verification & validation process requirements) 5.2.4.4 requirement baseline verification 5.2.4.5 SRR 5.2.5.1 Identification of observability requirements 5.2.5.2 Control and data interfaces for system level integration 5.2.5.3 Data medium requirements for integration 5.2.5.4 System database specification (content and use) 5.2.5.5 Identification of development constraints (to support the software integration into the system) 5.2.5.6 Definition of constraints for software to be reused 5.2.7.1 Software maintenance requirements 5.3 Software Management Process 5.3.2.8 PDR (Preliminary Design Review) 5.3.2.9 DDR (Detailed Design Review) 5.3.2.10 CDR (Critical Design Review) 5.3.2.11 software verification and validation process 5.3.2.12 QR (Qualification Review) 5.3.2.13 AR (Acceptance Review) 5.3.2.14 Validation activities phasing wrt AR 5.3.2.15 Software procurement process implementation 5.3.3.2 Support to software reviews 5.3.3.3 Technical reviews 5.3.4.1 Interface definition 5.3.5.1 Technical budget and margin philosophy 5.3.5.2 Technical budget and margin status at each milestone 5.4 Software requirements and architecture engineering process 5.4.2.1 Establishment and documentation of software requirements / software requirements specification: 5.4.2.1-a software requirements – functional and performance 5.4.2.1-b software requirements – software product quality requirements 5.4.2.1-e software requirements – data definition and Database requirements 5.4.2.1-f software requirements – Interfaces external to the software item 5.4.2.3 Identification of requirements unique identifier 5.4.3.1 Transformation of software requirements into a software architecture 5.4.3.2 Software design description 5.4.3.6 Selection of a computational model for real time software

ECSS-E-40 part 1B from 28 November 2003 5.4.3.7 Description of software dynamic behaviour 5.4.3.8 Development and documentation of the software interfaces 5.4.3.13 Definition and documentation of the software integration requirements and plan 5.4.3.14 Conducting a preliminary Design Review (PDR) 5.5 Software design & implementation engineering process 5.5.2.1 Detailed design of each software components 5.5.2.2 Development and documentation of the software interface detailed design 5.5.2.5 Description of the software dynamic aspects of physical model for real-time software 5.5.2.8 Development and documentation of the software user manual 5.5.2.10 Updating of the software integration requirements and plan 5.5.2.11 Conducting a Detailed Design Review (DDR) 5.5.3.1 Development and documentation of the software units, test procedures and test data 5.5.3.3 software user manual updating 5.5.3.4 Updating of the software integration test requirements and plan 5.5.4.1 Software integration test plan development 5.5.4.2 Software units and software components integration and testing 5.5.4.3 Software user manual updating 5.6 Software validation process 5.6.3.1 Development and documentation of a software validation testing specification (SVTS) wrt TS 5.6.3.2 Conducting the validation wrt TS 5.6.3.3 Updating the software user manual 5.6.3.4 Test readiness review 5.6.3.2 Conducting a Critical Design Review (CDR) 5.6.4.1 Development and documentation of a software validation testing specification (SVTS) wrt RB 5.6.4.2 Conducting the validation wrt RB 5.6.4.3 Updating the software user manual 5.6.4.5 Conducting a Qualification Review (QR) 5.7 Software delivery and acceptance 5.7.2.1 Preparation of the software product 5.7.2.4 Installation activities reporting 5.7.3.1 Acceptance test planning 5.7.3.2 Acceptance test execution 5.7.3.3 Executable code generation and installation 5.7.3.4a Supplier’s support to customer’s acceptance 5.7.3.4c Acceptance testing documentation 5.7.3.5 Evaluation of acceptance testing 5.7.3.6 Conducting an Acceptance Review (AR) 5.8 Software verification process 5.8.3.1 Verification of software requirements 5.8.3.7 Verification of test specifications 5.8.3.11a /as support for verification of software requirements & architectural design 5.8.3.11c /as support for verification of software coding and testing 5.8.3.12a / as support for verification of software requirements & architectural design

ECSS-E-40 part 1B from 28 November 2003 / sizing (memory) and timing (CPU load) estimation 5.8.3.12c/ as support for verification of software coding and testing / sizing (memory) and timing (CPU utilization in WCET) calculation 5.9 Software Operation Process 5.10 Software Maintenance Process 5.10.2.3 problem reporting and handling 5.10.3.1 Problem analysis 5.10.3.2 Problem verification 5.10.3.3 Development of options for modifications 5.10.3.4 Documentation of problem, analysis and implementation 5.10.3.5 Customer approval of selected modifications options 5.10.4.1 Analysis and documentation of product modification 5.10.4.2 Documentation of software product changes 5.10.4.3 Invoking of software engineering process for modification implementation 5.10.5 Conducting maintenance review Mapping between the Document Requirement List, as specified in ECSS-E-40 part 2B (15 November 2004), and the Technical Notes (TN) of this Sow

The ECSS software standards are completed with some DRDs, describing the most important software documents. The DRD list is a subset of the exhaustive list of documents to be produced in order to cover all the work output required by the standards. The expected output of the requirements resulting of this tailoring can be placed either in the hereunder-designated DRDs, either in other document items (not having DRD).

Document item Acronym

in DRD Folder

(Software) System Specification SSS Software Interface Requirements Document - System partition with definition of items

TN1, URD, TN5, TN6, TN7, TN8,

ADD System Configuration Item List

RB

SCIL Software Requirements Specification SRS Software Interface Control Document -

TS TN5, TN6, TN7, TN8,

TN9 Software Design Document: Software static and/ordynamic architecture

SDD ADD

Software Design Document (including Software Components Design): Detailed design

TN4, TN12, TN14

Software Source Code Part of simulator suite deliverable

Software Configuration File SCF SCF Software Release Document SRD SRD Software Delivery - Training Material

DDF

N/A

Software User Manual SUM SUM Software Verification Plan SverP TN3 Software Validation Plan SValP TN3 ISVV Plan - N/A Software Units Test Plan SUITP TN13 Software Integration Test Plan SUITP TN3 Software Validation Testing Specification wrt TS SVTS N/A Software Validation Testing Specification wrt RB SVTS N/A Acceptance Test Plan - TN19 Installation Plan - TN17 Software Units Test Report - N/A Software Integration Test Report - TN16 Software Validation Test Report wrt TS - TN12, TN13,

TN16 Software Validation Test Report wrt RB - TN18, TN19 Acceptance Testing Documentation - TN3, TN16,

TN17 Acceptance Test Report - TN16, TN18,

TN19 Installation Report - (Analyses, Inspection & RoD) verification report wrt TS

-

(Analyses, Inspection & RoD) verification report wrt RB

-

Software Traceability Matrices -

Implicitly included in

test documents

Traceability to system partitioning - N/A Independent Software Validation & Verification Report

- N/A

Software Reuse File SRF If reuse of GNC

algorithms Software Budget Report - TN16, TN18,

TN19 Numerical Accuracy Analysis Report - N/A Schedulability Analysis Report - TN16, TN18,

TN19 Software Behavior Verification Report - N/A Software Requirements Verification Report - N/A Software Arch. Design and Interface Verification Report

- N/A

Software Detailed Design verification Report - N/A Software Code Verification Report - N/A Software Documentation Verification Report - N/A Software Integration Verification Report - N/A Validation Report Evaluation wrt TS - N/A Validation Evaluation Report wrt RB - N/A Software Design and Test Evaluation Report - N/A Testing Feasibility Report -

DJF

DJF

N/A

Problems and Nonconformance Report - N/A Milestones & Technical Reviews Report - SRR, PDR,

DDR,CDR, TRR, QR, AR

Software Acceptance Data Package - - Procured Software Component Lists - If applicable Maintenance Plan - N/A Maintenance Records N/A Migration Plan - N/A Retirement Plan

MF

N/A Software Operational Plan - N/A Operational testing results

OP N/A

Software Development Plan SDP TN2 Software Configuration Management Plan N/A Training Plan N/A Customer Approval of Documents

MGT

N/A

Software Product Assurance Plan SPAP N/A Records of Training and Experience N/A Compliance Matrix to the Applicable Software Product Assurance Requirements

N/A

Software Product Assurance Requirements for Suppliers

N/A

Software Criticality Analysis Report N/A List of Critical Software Components N/A Software Product Assurance Report N/A Audit Plan N/A Software Process Assessment Plan N/A Software Process Assessment Records

PAF

N/A

European Space Agency - emits.sso.esa.intemits.sso.esa.int/emits-doc/1-5320-RD7-5303SoW.pdfEuropean...

Documents

Transcript of European Space Agency - emits.sso.esa.intemits.sso.esa.int/emits-doc/1-5320-RD7-5303SoW.pdfEuropean...