system requirements and architecture for time & space...
TRANSCRIPT
ESA UNCLASSIFIED – Releasable to the Public
System requirements and architecture for time & space partitioning in spacecraft
K. Hjortnaes/J. Windsor
FSW-1008-12-2010
ESA-ESTEC, TEC-SW Software Systems DivisionNoordwijk, The [email protected]@esa.int
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 2
Introduction
● Trends in Spacecraft Avionics – growing complexity
● A potential solution: Integrated Modular Avionics
● Time and Space Partitioning
● Context
● Requirements and constraints
● Architectural Design
● Conclusion
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 3
Trends in Spacecraft AvionicsGrowing Complexity
● Exponential growth of system functionality in software
o Higher degree of autonomy
o Push to get software ASAP for system AIV/AIT
● Higher levels of integration
o Mass, volume & power savings
o More powerful on-board computers
o Uncorrelated functions integrated into a single application
● System Integrator responsible for
o successful co-existence of software applications on same computer
o Extensive system integration and V&V
o All SW applications have same criticality class
o Fault detection and containment is at SW level
o Combinatorial explosion in numbers of test cases
o Complete flight software must be subjected to functional validation as a single component
System
Software
Definition Integration
Development
Phase B Phase C/D
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 4
A potential Solution Integrated Modular Avionics (IMA)
● The primary objective of IMA concept in the aviation domain is to achieve an integrated system architecture, which preserves the fault containment properties and development ‘separation of concerns’ of the federated systems.
● Benefits to the aviation domain
o Saving on mass, volume and power
o Maintenance and component obsolesce
o Retaining multi vendor
o Retaining parallel development
o Retaining incremental validation
o Fault containment (retaining federated system properties)
● IMA concept has evolved since early 1990s.
o Used across most major airframe integrators e.g. Boeing (777 & 787) and Airbus (A380).
o Supported by ARINC standards ((DO-297, DO-178B, DO-248, ARINC-629, ARINC-664 (AFDX), ARINC-653 (APEX API) etc.)
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 5
Time and Space Partitioning
● The IMA architecture uses software Time and Space Partitioning to share a single computing platform between multiple applications
o Ensures safety (and security) of S/C functions
● An application is a set of cooperating tasks which together perform a coherent function e.g. Attitude and Orbit Control
● Partition defined as an allocation of resources to an application
o Memory space spatial partitioning
o CPU time temporal partitioning
o Access to I/O device and bandwidth
o CPU privilege mode (System Partitions Supervisor Mode)
o Communication via ports and channels
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 6
Time & Space Partitioning Architecture
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 7
TSP Software Architecture
a) Full Operating system provides all scheduling services. The partitions implement the application programs (in user-mode)
b) Virtualisation: the kernel is typically a µ-kernel, and Operating system services are integrated locally within the partition. The kernel provides the partition scheduling services.
Diagram taken from “Partitioning in Avionics Architectures: Requirements , Mechanism and Assurance”, John Rusby. 1999, Technical report NASA/CR-1999-209347, Computer Science Laboratory, SRI International, USA
TSP kernel
Minor frame
Major frame
TSP kernel
DM
Spar 1
AO
CS
par 3
I/O
han
dlin
gpar 4
AOCS – Attitude and Orbit Control SystemDMS – Data Management System
Payload
par 2
(b)(a)
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 8
ARINC 653 Structure - System Architecture
ApplicationSoftware
ofPartition 1
CO
RE
ENVI
RO
NM
ENT
SOFT
WAR
E
CO
RE
PRO
CES
SOR
CO
RE
APPL
ICAT
ION
SOFT
WAR
E ApplicationSoftware
ofPartition 2
System Partition(s)
EXCEPTION HANDLING
HEALTH MONITORSCHEDULERPARTITIONING
LOGICAL COMMUNICATIONS
APEX
MMU CLOCK
COMMUNICATIONSMEDIA
HARDWARE
INTERRUPT CONTROLLER BITE
HARDWARE INTERFACE SYSTEM
MEMORY MANAGEMENTPHYSICAL COMMUNICATIONSDEVICE HANDLERS
BIT
OPERATING SYSTEM
CONTEXT SWITCHING
INTERRUPT HANDLING
APEX
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 9
Communication Principles in TSP systems
Intra-partition communication:
● Communication between 2 tasks, internally in one partition
Inter-partition communication (IPC):
● Communication between 2 applications on the same computer
Communication with I/O devices to ensure interface with external systems
● To ensure a robust partitioning, IPC uses Message Passing technique:
o Physical sharing of memory is doable but not used in IPC especially because of Fault Containment violation risk.
o Message Passing technique is recommended by the ARINC653 standard (APEX standard)
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 10
Inter-partition communication
● This message passing process is based on “Ports” and “Channels”, and services provided by the SE
o Channel: A channel is a logical link between one source and one or several destinations. It also describes the characteristics of the message to be sent
o Port: Applications have access to channels via defined access points: the ports. A port provides the required memory locations that allow a specific application to either send or receive messages in a specific channel
● The ports and channels are statically defined at system configuration time via a Configuration Table. During this configuration phase, the relevant Port and Channel attributes are created (Name, Length of message…)
ESA UNCLASSIFIED – Releasable to the Public
Context
SAVOIR initiative
-Reference architecture
-SOIS communication stack
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 12Onboard Communications H/W
(e.g. MIL-STD-1553B, SpaceWire, CAN RS422)
OBC Hardware
CAN RS422
TM/TC
Sensors(Star Trackers, Sun sensors, Gyros,
Earth sensors, magnetometers)
Actuators(Reaction wheels, magneto torquers,
thrusters, etc)
MIL-1553 SpW
CPU/Multicore
EEPROM BootPROM
OB Timer
Safe GuardMemory
HWwatchdog
SecurityUnit
Payloads &Instruments
SSMM
RTUPayload Control
Computer
SOIS Layers
Legacy devices
Standardized devices
SOIS Layers
ADCs / DACsSOIS Layers
RAM Digital Sensorbus
Payload Data Processing
DSP
StorageCompressio
n
High Speed TelemetryEncryption
SOIS Layers
SOISLayers
TC decoder
TMEncoder
Standardized devices
Filing System
Compress
Encrypt
ReconfigModule
Time synch
Payload TM Link
EssentialTM
Microcontroller
EssentialTM
Execution framework
Software bus
Libraries:mathematica
l, etc.SOIS Subnetwork layer (1553, CAN, SpW)
(including HDSW) BSP
Container services
Connector servicesPUS specific
Component services
Abstract component services
PUS and MTL
services
OBCPinterpreter
Avionics Equipment
virtual devices
=SOIS DVS
PUS monitoring
Application BB (mission dependent)
Plan/ Autonomy
Framework
System mode mgmt
Central FDIR
AOCS
P/L Manager
Thermal
Power
OBT Mgmt
Satellite Confand Eqpt
Mgmt
SSMM Mgmt
ABB supported by pseudo components :
To be confirmed if ABB:
RTOS
Context Mgmt
On-board time
=SOIS TAS
Communication services
addressing physical
distribution across nodes= SOIS MTS
Conceptual Reference Architecture and Building Blocks
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 13
Time & Space Partitioning and Software Reference Architecture
Onboard Communications H/W(e.g. MIL-STD-1553B, SpaceWire, CAN RS422)
OBC Hardware
CAN RS422
TM/TC
MIL-1553 SpW
CPU/NGmP
EEPROM
BootPROM
OBTimer
SGMHW
watchdog
SecurityUnit
Solid StateMass
Memory
File/ Compres
s/Encrypt
Payloads &Instruments
SSMM
RTU/Intelligent IO
PayloadComput
erSOIS
Layers
Legacy devices
Standardized devices
Intelligent devices
SOIS Layers
ADCs / DACs
SOIS Layers
Sensorand
actuators
RAM DSPDigital
Sensorbus
SpaceLinux
TSP kernel
Execution framework
Software bus
Libraries:mathematical, etc.
SOIS Subnetwork layer (1553, CAN, SpW)(including HDSW) BSP
Containe
r services
Connector services
PUS specific
Component services
Abstract component
services
PUS and
MTL services
OBCPinterpreter
Avionics Equip
mentvirtual devices =SOIS
DVS
PUS
monitoring
Application BB (mission dependent)
Plan/ Autono
myFramew
ork
System mode mgmt
Central FDIR
AOCS
P/L Manager
Thermal
Power
OBT Mgmt
Satellite
Confand EqptMgmt
SSMM Mgmt
ABB
supported
by
pseudo
components
:
To
be
confirmed
if ABB:
RTOS
Context Mg
mt On-
board ti
me=SOIS TAS
Communication
services addressin
g physical
distribution across
nodes= SOIS
MTS
Execution framework
Software bus
Libraries:mathematical, etc.
SOIS Subnetwork layer (1553, CAN, SpW)(including HDSW) BSP
Containe
r services
Connector services
PUS specific
Component services
Abstract component
services
PUS and
MTL services
OBCPinterpreter
Avionics Equip
mentvirtual devices =SOIS
DVS
PUS
monitoring
Application BB (mission dependent)
Plan/ Autono
myFramew
ork
System mode mgmt
Central FDIR
AOCS
P/L Manager
Thermal
Power
OBT Mgmt
Satellite
Confand EqptMgmt
SSMM Mgmt
ABB
supported
by
pseudo
components
:
To
be
confirmed
if ABB:
RTOS
Context Mg
mt On-
board ti
me=SOIS TAS
Communication
services addressin
g physical
distribution across
nodes= SOIS
MTS
Execution framework
Software bus
Libraries:mathematical, etc.
SOIS Subnetwork layer (1553, CAN, SpW)(including HDSW) BSP
Containe
r services
Connector services
PUS specific
Component services
Abstract component
services
PUS and
MTL services
OBCPinterpreter
Avionics Equip
mentvirtual devices =SOIS
DVS
PUS
monitoring
Application BB (mission dependent)
Plan/ Autono
myFramew
ork
System mode mgmt
Central FDIR
AOCS
P/L Manager
Thermal
Power
OBT Mgmt
Satellite
Confand EqptMgmt
SSMM Mgmt
ABB
supported
by
pseudo
components
:
To
be
confirmed
if ABB:
RTOS
Context Mg
mt On-
board ti
me=SOIS TAS
Communication
services addressin
g physical
distribution across
nodes= SOIS
MTS
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 14
Time & Space Partitioning and Software Reference Architecture
Onboard Communications H/W(e.g. MIL-STD-1553B, SpaceWire, CAN RS422)
OBC Hardware
CAN RS422
TM/TC
MIL-1553 SpW
CPU/NGmP
EEPROM
BootPROM
OBTimer
SGMHW
watchdog
SecurityUnit
Solid StateMass
Memory
File/ Compres
s/Encrypt
Payloads &Instruments
SSMM
RTU/Intelligent IO
PayloadComput
erSOIS
Layers
Legacy devices
Standardized devices
Intelligent devices
SOIS Layers
ADCs / DACs
SOIS Layers
Sensorand
actuators
RAM DSPDigital
Sensorbus
SpaceLinux
TSP kernel
A new service in the execution platform…
Execution framework
Software bus
Libraries:mathematical, etc.
SOIS Subnetworklayer (1553, CAN,
SpW)(including HDSW)
BSP
Container services
Connector
services
PUS
specific
Component
services
Abstract
component
services
PUS and MTL services
OBCPinterpreter
Avionics Equipmentvirtual devices =SOIS DVS
PUS monitoring
Application BB (mission dependent)
Plan/ AutonomyFramewor
k
System mode mgmt
Central FDIR
AOCS
P/L Manager
ThermalPowerOB
T Mgmt
Satellite
Confand EqptMgmt
SSMM
Mgmt
ABB
supported
by
pseudo
components
:
To
be
confirmed
if
ABB:
RTOS
Context Mgmt
On-board time=SOIS TAS
Communicatio
n services
addressin
g physical
distributio
n across
nodes=
SOIS MTS
Execution framework
Software bus
Libraries:mathematical, etc.
SOIS Subnetworklayer (1553, CAN,
SpW)(including HDSW)
BSP
Container services
Connector
services
PUS
specific
Component
services
Abstract
component
services
PUS and MTL services
OBCPinterpreter
Avionics Equipmentvirtual devices =SOIS DVS
PUS monitoring
Application BB (mission dependent)
Plan/ AutonomyFramewor
k
System mode mgmt
Central FDIR
AOCS
P/L Manager
ThermalPowerOB
T Mgmt
Satellite
Confand EqptMgmt
SSMM
Mgmt
ABB
supported
by
pseudo
components
:
To
be
confirmed
if
ABB:
RTOS
Context Mgmt
On-board time=SOIS TAS
Communicatio
n services
addressin
g physical
distributio
n across
nodes=
SOIS MTS
Execution framework
Software bus
Libraries:mathematical, etc.
SOIS Subnetworklayer (1553, CAN,
SpW)(including HDSW)
BSP
Container services
Connector
services
PUS
specific
Component
services
Abstract
component
services
PUS and MTL services
OBCPinterpreter
Avionics Equipmentvirtual devices =SOIS DVS
PUS monitoring
Application BB (mission dependent)
Plan/ AutonomyFramewor
k
System mode mgmt
Central FDIR
AOCS
P/L Manager
ThermalPowerOB
T Mgmt
Satellite
Confand EqptMgmt
SSMM
Mgmt
ABB
supported
by
pseudo
components
:
To
be
confirmed
if
ABB:
RTOS
Context Mgmt
On-board time=SOIS TAS
Communicatio
n services
addressin
g physical
distributio
n across
nodes=
SOIS MTS
Execution framework
Libraries:mathematical, etc. SOIS Subnetwork layer (1553, CAN, SpW)
(including HDSW)
PUS and MTL services
OBCPinterpreter
Avionics Equipment
virtual devices =SOIS DVS
PUS monitoring RTOS
paravertualised
Context Mgmt
On-board time=SOIS TAS
Communication services addressing
physical distribution across nodes= SOIS MTS
TSP services, e.g. Inter part com, health monitoring,
Component services
Container services
Connector servicesPUS specific
Pseudo component services
services might be allocated to specific partitions, i.e.
not part of the default execution platform
configuration
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 15
PUS
Pack
ets
Application Support Layer Services
Subnetwork Services
File and packet store
Command and Data Acquisition Services
File TransferServiceMessage Transfer
Services Time Access Services
File & Packet Store Services
Flight Applications
SM&C Service 2 SM&C Service N
SOIS, PUS, AMS and SM&C –Relationships
Synchronisation service
Test Service
Device Discovery Service
Memory accessservice
Packetservice
SOIS
Onboard
sub-systemsSensors &Actuators
Payloads
Time Source
TM/TCSpacelink
PUS ServicesGround Applications
Cross Support I/F
AMS
AMS SM&C service 1A
MS
Mes
sage
s
CFDP
PUS
ESA UNCLASSIFIED – Releasable to the Public16
Example: I/O Partitions and SOIS
I/O Partition
1553 Driver
SpW Driver
Partition 2
App 2
DVS Interface
MTS Interface
TSP
TSP
SOIS Subnetwork Services
...
DAS Service
MTS Service ...
...
Partition 1
App 1
DVS Interface
MTS Interface
...
Partition 3
App 3
DVS Interface
MTS Interface
...
One or more I/O partitionsImplementations of SOIS service in I/O partitionInterfaces to services in application partitionsAllow full reuse of SOIS servicesTransparent to applications
ESA UNCLASSIFIED – Releasable to the Public
Requirements & Constraints
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 18
Constraints
● In assessing IMA for Space the following constraints are considered
o Clear role definition – who does what in the software lifecycle.
o Multi vendor support
o Shall be implementable on existing hardware platforms
– Low on computing resources
– Small memory
o Shall facilitate the emerging product philosophy as defined under the SAVOIR initiative.
o Shall be compliant to the SOIS communication philosophy
o Shall identify the differences in context between space and aeronautic applications e.g.
– Maintaining a running system
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 19
Role definition
● System integrator
o System Architect
o Component integrator
● TSP-platform supplier
o MMU/BIOS supplier
o TSP system Executive supplier
● Application supplier (functional chains)
o Hosted applications only
o Hosted applications & peripheral hardware.
Specification
ICD
Specification
ICD
Verified Module
Verifie
d Mod
ule
Verif
ied
Sys
tem
Config
Itera
tion
Config
Iteration
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 20
IMA for Space (IMA-SP) System Requirements
● Real time execution environment for applications
o Support for the CORDET Reference Architecture
● Virtualisation of the avionics platform
o Provides a safe separation of computing resources
o Support for SOIS
● Enforces separation at run-time of the resources allocated to the applications
● Supports application-to-application & application-to-spacecraft functional interfaces
● IMA paradigm enables following quantities
o Independent lifecycle for each application
o Ensures continuous operational availability of the software functions with non-propagation of faults
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 21
System RequirementsIndependent lifecycles for each applications
● Separate function lifecycle
o Limits inter-dependency of the lifecycles of the applications
o Maximum flexibility and efficiency to application stakeholders
Challenge is to allocate resources early enough to allow for decoupling of application lifecycles
● Incremental system lifecycle
o Accumulate qualification credits in independence from the integrated system
● Criticality
o Integration of applications with differing criticality levels inone computing platform.
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 22
Incremental Validation / Qualification Credits
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 23
System Requirements Operational availability of applications
● Adaption to contingent situations
o Failure in an application is detected/recovered without impacting availability of other applications
– Automated recovery (restart/switch to backup) or stop
● Operational maintenance
o Partition management: stop, unload, load, start, patch, pause
o Problems with functional couplings between application
– Architecture must allow partition ‘disconnect’
● Adaption to mission schedule
o Start/stop applications based on mission phase
ESA UNCLASSIFIED – Releasable to the Public
Architecture
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 25
Partitioning Kernel
RTEMSSystem Executive Services
PK Interface instancePK Interface instance
API
Application Support Services
Partition
Partition
System Support Services
Application
System Executive Platform
System Support Services (rely at minimum on Partitioning Kernel)
Application Software & Support Services (rely on System Executive Platform)
IMA-SP Architectural Design
● Application Support Services
• Provides application services which are not available from either the kernel or RTEMS, e.g. SOIS support
● API – provides ARINC 653 services to the application
● System Executive Services – implements API services not included in RTEMS or kernel
● System Support Services
• executes in dedicated partition(s)
• 'standardised' system support functions
• e.g. IO handling, failure detection & recovery, platform functions (power, thermal), system services requiring supervisor privileges(e.g. patch/load mgt)
● System Executive Platform
• Partition Kernel, RTEMS, System Executive, Services, & API
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 26
IMA-SP Platform Requirements (General) I
Defines requirements on the IMA-SP Platform based on needs of the applications (the user)
● Mode requirements
o Shall implement various operational modes
o Privileged applications shall be used to switch between modes
o Mode transitions shall be deterministic
● Time services
o Access to the current Spacecraft Time
o Wait until a given Spacecraft Time event occurs
o Wait for a given time period
● Access to on board data stores, e.g.
o Housekeeping parameters
o On board state vectors
o Mission Time Line
o Images for patches
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 27
IMA-SP Platform Requirements (Failure Handling) II
● Allocation of basic physical resourceso Predictable CPU resource and memory allocation schemeo Failure of an application shall have no impact on integrity and
availability of physical resources● Flight software maintenance
o Central maintenance service with memory dump and patch operations
o Application software image reprogramming (partial or full)o Kernel patching patch non volatile memory & computer reset
● Fault protection serviceo Manages system state, individual partition state, interface with
external reconfiguration HWo Partial system reconfiguration
– Failure detection & recovery at partition levelo Full system reconfiguration
– Hardware level
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 28
IMA-SP Platform Requirements (Observability) III
● System Interface
o Allows interaction with platform services or other applications through well defined interfaces
● On Board Events
o Raise and access on board operational events
o Enables synchonisation across applications
o Events can equal Alarms failure detection
● System and Software Observability
o Produces set of monitoring and control parameters for ground
– Partition state, IMA-SP platform configuration
– Operational events/alarms, reconfigurations
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 29
Conclusion
● The IMA architecture spin-in is a strategy that addresses
o Separation of concern for the development phase
o Incremental validation
o Facilitates design for re-use
o Fault containment
o Allows different criticality / security classes to coexist within the same computer.
o Management of the growth of software functionality
● A good option to handle growing software complexity
ESA UNCLASSIFIED – Releasable to the Public
IMA for Space | J. Windsor/ K. Hjortnaes | FSW-10 | 08-12-2010 | ESA/TEC-SW | Slide 30
acknowledgement
This presentation reflects ongoing R&D work done by the European Space Agency in corporation with European aerospace industries as-Astrium Satellite, -Thales-Alenia-Space, -SciSys, -Spacebel, -SysGO, -University of Valencia, -GTD, -GMV-Skysoft
THANK YOU
Kjeld Hjortnaes, James WindsorEuropean Space [email protected]@esa.int