1 ROAD MAP OF THE CCSDS ARCHITECTURE WORKING GROUP (AWG) Draft, Issue 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. AOS Data Link TM Data Link TC Data Link Space Packet RF & Mod IPv4 AOS Data Link TM Data Link TC Data Link Space Packet RF & Mod IPv4 Space Packet IPv4 Space Packet 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 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 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 File Transfer Radiometric Acquisition Online Transfer TCP/UDP/IP Data Analysis Orbit Determination Tracking StationControl Center File Transfer Online Transfer 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 CCSDSIOAG

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) 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/ / / / / When? When? RASDSStudyDevelopReviseMaintain Description Methods StudyDevelopMaintain Software ToolsDevelop Standards Architectures DevelopMaintain Services Architectures DevelopMaintain Systems Architectures DevelopMaintain