ADCSS – 2010 AGASSE section Beyond the Aurora Architecture for the new challenging applications. The Enhanced Avionics Architecture for the Exploration Missions.

A. Tramutola – A. Martelli BSOOS Turin

Corporate Communications 1 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Presentation contents

Aurora Avionic Architecture as starting point EXOMARS : Aurora implementation Major requirements for exploration mission EDL, RVD and ROVER functional architecure Common elements : communication bus and CPU CDMU : processor – coprocessor configuration Avionic Test Bench to support avionic design Conclusion

Corporate Communications 2 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Aurora Avionic Architecture as starting point

RF to Ground TCS GNC EPS

Command, Control and Data Handling

RF short range Mission modules

Corporate Communications 3 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Aurora Avionic Architecture as starting point

Main functions implemented in the Aurora Architecture are :

• TM/TC Management, Storage Management and On-Board Time (OBT) Management needed for interface with ground or with other • Thermal Management, Electrical Power Supply (EPS) Management for spacecraft TCS and EPS subsystem control • Spacecraft Modes Management (SCMG), AMM/ FDIR Management, Equipment Management which are the principal Data Handling function. They handle the on-board system through the different mission phases, define the level of autonomy, execute the mission timeline, the detection of anomalies, and their recovery, maintain the equipment configuration following failure recovery execution • GNC Management: computes the actuators commands from the sensors measurement in order to control the spacecraft attitude (and position) interfacing with GNC sensor and actuator units • Payload Management: for scientific payload or additional units, • Release, Deployment and Pyrotechnic (RDP) activation Management: for solar arrays/antenna deployment, for propulsion arming sequence before firing, or for specific needs like shield jettison or space-crafts composites dispatching • Sleep/Wake-up Management: for the wake-up of a Descent Module near the atmosphere entry, or to make a Rover sleep during a Martian night,

Corporate Communications 4 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space EXOMARS: AURORA implementation

EXOMARS can be seen as the first implementation of the AURORA avionic architecture • Mission architecture require a composite S/C consisting of Carrier Module, Entry Descent Module, Rover Module. Release Deployment and Pyrotechnic mangement is needed • Each module implements an Aurora architecture because TT&C, TCS, EPS, GNC subsystems are managed in each module • Central Processing units in which SW functionalites are executed are embedded in each module of the composite spacecraft Corporate Communications 5 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space EXOMARS avionic architecture: OM and DM

Corporate Communications 6 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Major requirements for exploration

Perform safe, soft and precise landing  Safe site identification means capability to identify areas with minimal slope, acceptable hazards and taking into account illumination and environment constraints for power generation  Soft and precise landing means capability to perform accurate absolute and relative navigation toward the target site and capability to plan a correction manoeuvre at very low altitude  LIDAR, Camera, Altimeter become mandatory sensors to be added in the avionic architecture Release and control rover modules for surface exploration  Localization, navigation and experiments (i.e. terrain samples collection and analysis) require computational performance, high rate data bus link and data storage capability  Significant data volume have to be transmitted towards orbiter, data relay spacecraft needed for communication with ground  Autonomy in decision to be taken depending on contingency Recovery and re-entry on ground of samples

 Rendezvous and docking or capture is a function needed to recovery samples  Avionic has to be improved including dedicated sensors (NAC, WAC, LIDAR, RFsensor) and specific functionalities needed to optimise the propellant consumption in the different rendezvous phases.  Significant computation power is required to solve on line optimization problems

Corporate Communications 7 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space EDL functional architecture

Descent Module Composite (DMC) BACK SHELL (BSH) FRON SHIELD (FS)

Guided Entry propulsion Landing propulsion BATT TCS In SAGE study (EDL on Mars and Moon) 4 x 90N Pressure 4 x 3200N Pressure ctrl THR transducer ctrl THR transducer required landing accuracy is 200m(Moon). BRTU Guided entry is needed (Mars) and stringent PDD requirements on vision based LANDER PLATFORM (LP) SEP CONNECTOR SEP MECH navigation are applicable NAV NAV IMU-1 IMU-2 IMU-3 LIDAR Altimeter CAM CAM Absolute position estimation (Moon) X- LGA1 SSPA • from 50Km to 10 Km altitude DST • 100 m accuracy each coordinate at RFDN

X- SSPA 10Km altitude (eq. to 1% of altitude) DST LGA2 Relative position estimation • from 10Km to 10 m altitude (Moon scenario) PSU CTU UHF-1

• from 5Km (front shield jettison) to 10m SWITCH

(Mars scenario) UHF-2 • 5% of slant range in the whole operative range BATT ROVER MODULE • 1m accuracy each coordinate at 10m of altitude OBC HDA design => Hazard Maps TCS • from about 1Km to 200 m altitude RV HDRM Pressure Accelerom ABSAC Pyros 1 AC 1 AC 1 PCDE • Roughness map transducer . Airbag System PRM • Illumination map (Moon) KEY

PWR/Pyro • Detect slopes higher than 10deg Data Handl. Sys. GNC. Sensors Discrete lines PWR Sys. lines Thermal Contr. Sys. Actuators MIL-1553 bus SPACEWIRE Separ. Interfaces • Detect rock higher than 0.5 m Telecom. Sys. Propulsion Sys RS-422

Corporate Communications 8 Mars Precision Lander: EDM functional avionic architeture 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Rendezvous and Capture architecture

In ORCSAT study focus is on NAC propellant saving in the different RDV phases

TT&C WAC Model Predictive Controller Algorithms are used in all RDV phases (long range, RFS2RFS2 intermediate range and short range) to solve on EPS CDMU LIDAR line optimization Data LIDAR problems mainly related Handling to the navigation function Relative Nav STR sensors STR Significant computational capability (MFLOPS) are Absolute Nav IMUIMU required to the CDMU. sensors Each 900 seconds no Heater lines more that 30 second can Actuators be allocated to the MPC RWL RTU CSS computation SpaceWire RS422 Power line Image Processing algorithms MIL-1553B TCS THR Dedicated lines Thermistor lines THR are used for the target detection (NAC) and for the terminal RDV phase (WAC) ORCSAT : RDV and Capture functional avionic architeture

Corporate Communications 9 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Rover Module Avionic architecture

The EXOMARS Rover Vehicle is required to survive and drive autonomously on the Mars Surface (100m every Sol)

Autonomous Navigation is based on Stereo Vision (3D Map Generation and Visual Localisation), thus high data rates for images acquisition (SpaceWire) and significant computational power are required

Required Performances:

Visual Odometry >0.1Hz

3D Map Generation (16m^2, grid size <4cm) in less than 120s

Precision after 100m travel +/- 6.8m and +/-5deg in heading

Upload to Earth of the needed information to select a new target (10x compression) EXOMARS : Rover Module functional avionic architetcure

Corporate Communications 10 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Common elements

Exploration avionics needs: • specific sensors (Cameras, Lidar, Altimeters (Radar or Laser)) to be tailored to the specific mission scenario • specific algorithms (Image Processing, MPC controllers, Navigation filters) to be also tailored to specific mission scenario

Common elements in all the architecture are: • CDMU with high computational performance ( IP requires at least 1000 MIPS) • and fast communication links with units generating significant data volume (LIDAR, Cameras)

In the frame of ORCSAT, SAGE, VISNAV ESA studies the trade-off based on FPGA capability and available space qualified microprocessor has identified as the more powerful configuration: • processor-coprocessor configuration • PCI and SpaceWire bus as the most suitable parallel and serial communication link for both inter-processor link and unit I/F link

Corporate Communications 11 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Common elements

PROCESSOR In charge of all main functionalites (DH, Thermal, Electrical, TM/TC) • Currently space qualified processing units are based on LEON2 FT, its VHDL IP core can be included in dedicated SoC. • Comparison between AT697F, SCOC3(LEON3 based), COLE(LEON2 FT based) is in favour of AT697F  86MIPS & 23MFLOPS @100Mhz  I/O I/F (DSU,2UART, GPIO, PCI) to be improved with dedicated FPGA

COPROCESSOR In charge of specific algorithms computationally demanding (IP, MPC, GNC) • FPGA coprocessor  Space qualified FPGA are available from Actel and Xilinx (Virtex4 and Virtex5). Both tolerate up to 300Krad (Si) of TID and declare a Single-Event Latch-Up Immunity (SEL) to LETTH > 117 (125 Virtex) MeVcm2/mg. • PowerPC coprocessor  A flight qualified PowerPC is the RAD750 from BAE systems (Total dose: 1Mrad (Si), SEU: <1.6 E-10 errors/bit-day, Latchup-immune) with performance of 400 MIPS (Dhrystone 2.1) at 200 MHz. A more performing processor is the PowerPC750FX which has been used to design space qualified computer boards (Maxwell SCS750, MDA ESP750) with high computational performance (1650MIPS @ 733MHz).  A more powerful processor based on RISC technology is the PowerPC7448. It is manufactured on a 90nm SOI process and features 3000 MIPS (Drystone 2.1) at 1.3GHz (2.3MIPS/MHz). It has exhibited good behaviour under radiation and there is availability of up-screened versions from an European supplier: e2v COMMUNICATION BUS  Low speed communication link are MIL-1553B-STB and CAN bus (1Mbps). CAN bus can replace the MIL bus solving the relevant ITAR problems. TAS-I for the EXOMARS project is developing the CANOPEN protocol implementing the slaves in HW (IP core on FPGA) and Masters in SW.  RS422 and RS485 are medium speed bus and can be used to set up a point to point full duplex link (up to 10Mbps)  PCI parallel bus reaches 1 Gbps (32bit @33Mhz) therefore it is a candidate as inter-processor link  SpaceWire (up to 200MBps) can be used to link LIDAR or Cameras to the CDMU Corporate Communications 12 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space CDMU functional architecture: FPGA

Specific algorithms of the GNC (MPC Hot Red controllers or MPC solver for Cold Red Alarms ORSAT ) or IP algorithms TM TC (camera pose estimation for SAGE) could be implemented as HW solution programming a TM encoder TC decoder SGM RM dedicated FPGA.

Essential TM FPGA can interface directly the HPTM Mass Memory via a HPC/H dedicated co-processor link LC while all the other units are CPDU directly managed by the central RAM Acq/Cmd processor. PCI is proposed as PM-Co PROM I/O PM suitable interprocessor link. link Central NVM Units FPGA Processing Data bus I/F Unit FPGA internal clock can reach a RAM Units frequency of about 200MH High speed I/F nevertheless the achievable improvement in terms of PPS Output computational throughput is Test I/F OBT strongly dependent from the CDMU Synch implementation of the algorithms, in particular from the parallelism that can be EGSE Ext. Clock obtained. Corporate Communications 13 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space CDMU functional architecture : PPC

A more powerful configuration of Hot Red the CDMU is based on a Cold Red TM Alarms second processor directly TC linked to the central processor. TM encoder TC decoder SGM RM

The on-board SW can be distributed on the two Essential TM HPTM Mass Memory microprocessors leaving to the main processor the HPC/H handling of the system units LC CPDU and to the coprocessor the execution of the algorithms PROM PM-Co PROM Acq/Cmd requiring significant PM I/O link computational throughput NVM PowerPC LEON 2 NVM Units (GNC or IP) Data bus I/F

RAM RAM Units High speed I/F The selection of a general- CO-PROCESSOR CENTRAL-PROCESSOR purpose microprocessor gives less constraint to the PPS Output SW development. A PowerPC Test I/F OBT Synch RISC architecture is a suitable candidate

EGSE Ext. Clock

Corporate Communications 14 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space CDMU functional architecture: PPC+FPGA

IP algorithms require the most powerful architecture. Coprocessor consists in Co-PM IPB FPGA and PPC integrated in a dedicated IP NAV CAM Board interfacing the central computer RAM (LEON2FT) via SpaceWire router NVM RAM FEIC chain 1 PM VISNAV architecture implements in FPGA part of

the IP algorithms (FEIC) allocating to PPC SPW Companion PPC7448 LEON2FT SPW router processor (PPC7448) algorithms which FPGA cannot be efficiently implemented in the CPU FPGA.

FEIC chain 2 Navigation cameras are acquired and commanded by the IPB via SpaceWire while LIDAR main processor (LEON2 FT) acquire final RAM product of the IP algorithms needed by the NAV CAM GNC function and manage all the other GNC units. Central computer is also in charge of all the other system functions (DH, Thermal, Power, TM/TC) PM main Redundancy concept that can be applied to this Co-PM IPB main architecture can consider PM main and redundant interfacing with both IPB co- processors.

This architecture is applicable to different PM redundant Co-PM IPB Redundant mission scenarios (EDL, ROVER, RDV)

Corporate Communications 15 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Avionic Test Bench to support design

Trade-off between different configurations are feasible if flexible RT test bench is available in which communication bus, processor boards and SW algorithms can be integrated

Ground segment Flight segment cPCI rack

L RS232 e P F I/ T TM/ Ethernet o P P O M TC CAN n C G T FE A C USB 2 I/ SpW O

RS232

USB/ SpW router

Simulation Environment SW Development Env.

dSpace Env + Target link RTEMS DSPACE VXWORKS RACK XILINK MATLAB/SIMULINK

Ethernet Switch

Corporate Communications 16 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space Conclusion

TAS-I objectives to enhance the Avionics Architecture for the Exploration Missions are: • definition of a scalable avionic architecture adequate to the new demanding requirements of the exploration based on computer vision • improvement of navigation algorithms using also on line optimization techniques which reduce the propellant budget needed to accomplisch the mission • set up of a configurable and representative development and verification environment supporting trade-off and design of this scalable avionic architecture

Corporate Communications 17 3 Nov.2010 ESTEC All rights reserved © 2010, Thales Alenia Space