1. 1 Systems Architecture WG: Charter and Work Plan October 23, 2003 Takahiro Yamada, JAXA/ISAS

2. 2 Introduction  This presentation reviews:  the charter of the Systems Architecture WG, and  the current status of each work item described in the charter.

3. 3 Goals and Deliverables Defined in the Charter, Draft 4 1. Define a reference architecture that provides a framework for generation of space data systems standards and development of space data systems. 2. Document the reference architecture identifying basic elements. 3. Develop a document that provides to the other Working Groups and BoFs guidelines on how to apply the reference architecture. 4. Develop formal methods for representing space data systems architectures that will enable sharing of architectural information among engineers. 5. Develop tools that will facilitate design, modeling, and simulation of system architectural designs.

4. 4 Schedule Defined in the Charter, Draft 4 (1/2) DateMilestone 19 May 2003 WG chartered and active. 30 June 2003 Publish a revised version of the reference architecture document (Issue 0.8). July 2003 Selection of candidate languages and tools. Prototyping (phase 1) of selected languages and tools starts. October 2003 WG meeting. Reports of prototyping (phase 1). Publish a draft report (Issue 0.1).

5. 5 Schedule Defined in the Charter, Draft 4 (2/2) DateMilestone December 2003 Publish a revised reference architecture document, a draft representation method document a draft tool usage document. Prototyping (phase 2) starts. April 2004 WG meeting. Reports of prototyping (phase 2). Publish the final version of the reference architecture document, the report, the representation method document, the tool usage document.

6. 6 Schedule sorted by deliverables DeliverableMilestoneDate Reference Architecture (Standard) Develop a Reference Architecture Publish a revised draft Publish a revised draft (RB) Publish the final documents (BB) 04/02- 06/03 12/03 04/04 Report (Informational) Publish a draft document (dGB) Publish the final document (GB) 10/03 04/04 Representation Methods (Standard) with Software Tools Selection of languages and tools Prototyping (phase 1) Publish a draft document (RB) Prototyping (phase 2) Publish the final document (BB) 07/03 07/03- 10/03 12/03- 04/04

7. 7 Items added to the Charter (Draft 5) by Peter B. GOALS AND DELIVERABLES 6. Provide a consistent set of views and terminology across all of the other Areas and Working groups. Use existing CCSDS terms where they are clear and unambiguous. Resolve to develop a single agreed approach where there are ambiguous or conflicting uses of terms or definitions. C. SCHEDULE In collaboration with at least one other Working Group, develop a domain specific reference architecture and publish the resulting document.

8. 8 Status of the Reference Architecture  The current document is Issue 0.7 released in March, 2003.  In the document, the following five Views are defined, each with its basic constituents.  Enterprise View with Enterprise Objects,  Connectivity View with Nodes and Links,  Functional View with Functional Objects,  Information View with Information Objects,  Communications View with Communications Objects.

9. 9 Issues on the Reference Architecture (1/2)  The Reference Architecture defines basic Objects (e.g., Functional Objects).  However, I do not think it should define sub-classes of Objects (e.g., Mission Planning Functional Objects) because they should be defined in individual architectures. (Some examples should be shown in the Reference Architecture.)  I thought the Reference Architecture should define a set of standard terms to characterize Objects in each View.  For example, the OSI Basic Reference Model defines a set of standard terms to characterize protocols (e.g., connection, relay, multiplexing, sequencing, flow control, etc.).

10. 10 Issues on the Reference Architecture (2/2)  However, my current thinking is that we should publish the document without the definition of standard terms to characterize Objects as the first version because:  Defining such standard terms is not easy, and  The basic architecture should be exposed to CCSDS WG’s as soon as possible.

11. 11 Report (GB) on the Reference Architecture  We should publish a Green Book to show how the Reference Architecture should be used by CCSDS WGs and Agencies.  This GB will:  briefly introduce RASDS (based on the Overview section of the RASDS document),  show the relationship between the Reference Architecture and individual architectures, and  include examples of individual architectures: Architectures for standards Architectures for services Architectures for systems

12. 12 Reference Architecture and Individual Architectures 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

13. 13 Architecture for standards (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

14. 14 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

15. 15 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

16. 16 Architectures for Systems (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

17. 17 Status of the Selection of Languages and Tools  We have not been able to discuss this until now.  We will have a session on this subject tomorrow morning.  My proposal is to develop a Space (Data) System Metamodel based on MOF/UML 2.0. (But this will be a big task.)