Folie 1 Service Oriented Architecture - Prototyping study - DLR/GSOC Author: S.Gully

Folie 2 Chapter 1: SOA concept

Folie 3 Definition Here is a classic IT landscape of big companies. The operative business is done through distributed systems, that are most of the time heterogeneous (OS, programming language, environment, manufacturer) in the HW and SW areas. Most of these systems are connected to each other by a lot of interfaces. Actual State GSOC : Classic distributed system architecture Number systems = N Number interfaces <= N(N-1) Interface = point to point Each interface has to be developed / supported Current context in GSOC

Folie 4 Definition The most important systems of the company have only one interface (connector) to an ESB (Enterprise Service Bus). The architecture of the bus allows them to communicate with each other. The use of an ESB allows a better control of the IT landscape (security rules, changes, logging) and a minimisation of the number of interface to support. Enterprise Service Bus architecture Number systems = N Number interfaces = N Interface = connector For each system only one interface has to be sup- ported Future context in GSOC ?

Folie 5 Definition SOA defines a software architecture / infrastructure based on a bus system (Enterprise Service Bus) that allows communication between heterogeneous systems. In this architecture a system can deliver data (service providers) or / and receive data (service consumers) through the bus using a common abstract language: a Message Exchange Pattern (MEP). Service Oriented Architecture – Concept SOA is an architecture SOA cannot be purchased Message Exchange Pattern for inter- communication

Folie 6 Chapter 2: CCSDS SM&C service approach

Folie 7 SM&C (Spacecraft Monitor & Control) working group approach The SM&C working group from CCSDS is a group focussing in Software Monitoring and Control parameters. This group has defined a service oriented approach for exchanging TMTC between Control Center M&C systems and Satellites. The Service Providers propose data and the Service Consumers receive data. The communication is based on a Message Exchange Pattern: the MAL (Message Abstraction Layer). Services are separated in Common and Mission Operations Services. CCSDS SM&C service approach End to End service Focus on Monitor & Control Configuration of Services not defined

Folie 8 Layers The connectors in the SM&C Approach are each a particular API Implementation of the MAL based on a particular programming language and a transport protocol. The binding at the protocol level should not be restrictive, i.e. it should allow the use of different protocols. CCSDS SM&C service approach Service description Message Exchange Pattern Connector

Folie 9 Prototype A prototype has already been realised that consists of the following configuration: ESA: - Service Provider: generate parameter definition in XTCE format and data packets with a simulator (Java MAL Connector, JMS) CNES: - Service Consumer: get the packets, process the information using the XTCE definitions and display them with their M&C system (Java MAL Connector, JMS) - Service Provider: generate calibrated parameters (Java MAL Connector, JMS) BNSC: - Service Consumer: get the calibrated parameters and generate automatically procedures with a tool (Java MAL Connector, JMS) CCSDS SM&C service approach

Folie 10 Chapter 3: CCSDS SM service approach

Folie 11 SM (Service Management) working group approach The SM Service is in charge of the management information to be exchanged between a Mission Operation Data Systems consumer and a Space link service provider for the purposes of negotiating and configuring the Tracking, Telemetry, and Command (TT&C) services. The service provider is called CM (Complex Management) and the service consumer is called UM (User Management). CCSDS SM service approach Management & Configuration of Services Not in charge of executing the Data Transport Service description Message Exchange Pattern Connector

Folie 12 Context SM is intended to take care of the management, the configuration and the planning of the Data Services between agencies. SM is not intended to take care of the Data Transport. This is done using SLE (Space Link Extention). CCSDS SM service approach CM (Service provider) UM (Service consumer) Service Management Data Transports not defined as SOA services. Break in Service Architecture !!!

Folie 13 Prototype A prototype has already been realised that consists of the following configuration: JAXA: - Service Consumer: send SM Service Request per SMTP to ask support from NASA NASA/JPL: - Service Provider: get SM Service Request, check SM Service Request against SM Service Package. - Service Provider: perform tracking of Selene S/C at moon with DSN antenna and send return data as RAF (Return All Frames) CCSDS SM service approach

Folie 14 Chapter 4: Prototyping architecture

Folie 15 Prototype SM&C Prototyping Architecture

Folie 16 Prototype SM Prototyping Architecture

Folie 17 Prototype SM&C and SM together Prototyping Architecture Services can not communicate because of different MEPs

Folie 18 Chapter 4: Prototypes

Folie 19 Prototype SM&C The prototype will be probably realised for middle of Prototype between NASA (TM, TC Simulator) and DLR (M&C System SCOS). TBC. Prototype SM DLR wants also to make a SM prototype. But because of manpower ressource needed to develop totally different infrastructures, it will be possible only in 1 or 2 years. Negative Points: Not possible to develop a totally different Message Exchange Pattern Solution: CCSDS Decision use only one Message Exchange Pattern for both Service Definitions ? The actual SM definition is to much complicated for simple NE mission like those from DLR. Solution = Refactoring ? Positive Points: In the scope of a bigger ground stations automatisation project, the SM Service could be used internally to manage information needed by the automatisation applications. Prototypes