Folie 1

Service Oriented Architecture- Prototyping study -

DLR/GSOC

Author: S.Gully

Folie 2

Chapter 1: SOA concept

Folie 3

DefinitionHere 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 = NNumber interfaces <= N(N-1)

Interface = point to point

Each interface has to be developed / supported

Current context in GSOC

Folie 4

DefinitionThe 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 = NNumber interfaces = N

Interface = connector

For each system only oneinterface has to be sup-ported

Future context in GSOC ?

Folie 5

DefinitionSOA 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 approachThe 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

LayersThe 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 approachThe 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 & Configurationof Services

Not in charge of executing the Data Transport

Service description

Message Exchange

Pattern

Connector

Folie 12

ContextSM 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 2010. 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