1. ROAD MAP OF THE CCSDS ARCHITECTURE WORKING GROUP (AWG)
Draft, Issue 0.4
11 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
We can develop multiple architectures, each for a different system or for a different purpose, in a coherent way.

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.
Onboard End System
Onboard Relay System
Ground Relay System
Ground End System
IPv4
IPv4
IPv4
IPv4
Space
Packet
Space
Packet
Space
Packet
Space
Packet
AOS
Data Link
AOS
Data Link TM
Data Link TM
Data Link TC
Data Link TC
Data Link
RF & Mod
RF & Mod

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
Tracking Network of an Agency
Supporting Communications Services

10. Architecture for services (example 2)
This diagram is an example of an architecture that shows services provided by middleware to applications.
Frame Receive Service
Frame Send Service
Packet Receive Service
Packet Send Service
Publish Service
Subscribe Service
Message Receive Service
Message Send Service
Data Store Service
Data Retrieve Service
Data Catalog Service
Data Discovery Service
On-Line Transfer
Middleware
Messaging
Middleware
Store and
Retrieve
Middleware
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.
Telemetry Acquisition
Data
Analysis
Radiometric
Acquisition
Orbit Determination
Online
Transfer
File
Transfer
Online
Transfer
File
Transfer
TCP/UDP/IP
TCP/UDP/IP
Tracking Station
Control Center

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 Architectures for CCSDS standards
Architectures for space data services
Architectures for spacecraft and systems
Reference Architecture for Space Data Systems (RASDS)
Formal Description Methods for Architectures and Systems
Software Tools for Manipulating Architectures and Systems

14. Developers CCSDS IOAG Architectures for space data services XASTRO
Architectures for CCSDS standards
Architectures for spacecraft and systems
Reference Architecture for Space Data Systems (RASDS)
Formal Description Methods for Architectures and Systems
Software Tools for Manipulating Architectures and Systems

15. Development Methodology
Architectures for CCSDS standards
Architectures for space data services
Architectures for spacecraft and systems
Prototyping and Feedback (between AWG and other WGs)
Prototyping and Feedback (between AWG and IOAG)
Prototyping and Feedback (between AWG and XASTRO)
Reference Architecture
Formal Description Methods
Software Tools
Development and Feedback (between AWG and XASTRO)
Development and Feedback (between AWG and XASTRO)

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/ When?
When?
RASDS
Study
Develop
Revise
Maintain
Description Methods
Software Tools
Standards Architectures
Services Architectures
Systems Architectures