1

ROAD MAP OF THE CCSDS ARCHITECTURE WORKING

GROUP (AWG)

Draft, Issue 0.411 March 2003

Takahiro Yamada, Chair, AWG

2

Requirements

Architectures are needed for Describing CCSDS standards

• Requirements from P1 people discussed in Houston

Describing spacecraft and ground systems• XASTRO and XASTRO follow-on project

Describing services• Cross-support service architecture (IOAG)• Cross-support operations service architecture (DLR)• DSMS services catalogue (JPL)

3

New requirements

Some more requirements resulting from the restructuring of CCSDS P3 reference model needs to be revised

• Proposals for application-oriented services such as tracking services and monitor & control services

Information architecture• Study activity by P2• CCSDS XML workshops

4

What we have done so far

There are requirements for different kinds of architectures (see previous slides).

In order to develop these architectures efficiently and coherently, we need a frame work (or a reference architecture).

We developed a reference architecture called the Reference Architecture for Space Data Systems (RASDS) based on Reference Model of Open Distributed Processing (RM-ODP).

We generated a document and a storybook that specify RASDS.

5

Why we need a reference architecture

Reference Architecture

Architecture 1

We can develop multiple architectures, each for a different system or for a different purpose, in a coherent way.

Architecture 2

6

Without a reference architecture …

“How do these two architectures relate to each other?”

“I don’t know!”

7

Next steps (1)

Develop specific architectures based on RASDS. Architectures for CCSDS standards

• Space link protocol architecture, space information architecture, space applications architecture, etc.

Architectures for space data services• Onboard services architecture, ground services

architecture, information management services, etc.

Architectures for spacecraft and systems• Onboard systems architecture, ground systems

architecture, etc.

The following slides show some examples of different architectures derived from RASDS.

8

Architecture for standards (an example)

This diagram is a fragment of an architecture that shows the relationship among space link protocols.

AOSData Link

TMData Link

TCData Link

SpacePacket

RF & Mod

IPv4

AOSData Link

TMData Link

TCData Link

SpacePacket

RF & Mod

IPv4

SpacePacket

IPv4

SpacePacket

IPv4

Onboard Relay System

Ground Relay System

Ground End System

Onboard End System

9

Architecture for services (example 1)

This diagram is an example of an architecture that shows services provided by a tracking network.

TLM acquisition service

CMD radiation service

Radiometric data acquisition service

Service management

Supporting Communications Services

Tracking Network of an Agency

10

Architecture for services (example 2)

Messaging Middleware

On-Line Transfer Middleware

Store and Retrieve

Middleware

This diagram is an example of an architecture that shows services provided by middleware to applications.

Frame Receive ServiceFrame Send ServicePacket Receive ServicePacket Send Service

Publish ServiceSubscribe ServiceMessage Receive ServiceMessage Send Service

Data Store ServiceData Retrieve ServiceData Catalog ServiceData Discovery Service

Supporting Communications Services

11

Architectures for systems (an example)

This diagram is an example of an architecture that shows what functions exist at a tracking station and a control center and how they communicate.

TelemetryAcquisition

File Transfer

RadiometricAcquisition

OnlineTransfer

TCP/UDP/IP

DataAnalysis

Orbit Determination

Tracking Station Control Center

File Transfer

OnlineTransfer

TCP/UDP/IP

12

Next step (2)

In order to enable sharing and exchange of information on architectures and systems among different organizations, we need to develop formal methods for describing architectures and systems (i.e., UML profiles and XML schemas)

In order to facilitate generation and manipulation of architectures and systems, we need to develop software tools for generation and manipulation of architectures and systems. But these tools should be based on existing tools.

13

Work areas

Reference Architecture for Space

Data Systems (RASDS)

Formal Description Methods for

Architectures and Systems

Software Tools for

Manipulating Architectures and Systems

Architectures for CCSDS standards

Architectures for space data

services

Architectures for spacecraft and systems

14

Developers

Reference Architecture for Space

Data Systems (RASDS)

Formal Description Methods for

Architectures and Systems

Software Tools for

Manipulating Architectures and Systems

Architectures for CCSDS standards

Architectures for space data

services

Architectures for spacecraft and systems

XASTRO

CCSDS IOAG

15

Development Methodology

Reference Architecture

Formal Description

Methods

Software Tools

Architectures for CCSDS standards

Architectures for space data

services

Architectures for spacecraft and systems

Prototyping and Feedback (between AWG and IOAG)

Development and Feedback

(between AWG and XASTRO)

Development and Feedback

(between AWG and XASTRO)

Prototyping and Feedback (between AWG and XASTRO)

Prototyping and Feedback (between AWG and other WGs)

16

To step forward

Benefits of this work must be recognized in order to get approval from CCSDS and support from Agencies. Is this architecture (with software tools) beneficial

to:• CCSDS standards developers?• Users of CCSDS standards?• System developers of Agencies?

Collaboration with XASTRO To be discussed between AWG and XASTRO

based on the work plans of both groups.

17

Schedule (Tentative)

04/2002 -09/2002

10/2002 - 03/2002

04/2002 - When?

When?

RASDS Study Develop Revise Maintain

Description Methods

Study Develop Maintain

Software Tools Develop

Standards Architectures

Develop Maintain

Services Architectures

Develop Maintain

Systems Architectures

Develop Maintain