ROAD MAP OF THE CCSDS ARCHITECTURE WORKING GROUP (AWG)

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 Architecture 1 Reference Architecture Architecture 2 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. TelemetryAcquisition 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)