Application of ODP for Space Development

1. Application of ODP for Space Development 17 October, 2006 Takahiro Yamada (JAXA/ISAS) Chair, Systems Architecture WG, Consultative Committee forSpace Data Systems (CCSDS)

2. Introduction • The Systems Architecture Working Group (SAWG) of the Consultative Committee for Space Data Systems (CCSDS) developed a reference architecture called the Reference Architecture for Space Data Systems (RASDS) so that the space agencies in the world (e.g., NASA, ESA, JAXA) can describe the architecture of their data systems in a compatible way. • The RASDS was developed based on RM-ODP but some modifications were made so that we can describe what we want to describe. • This presentation shows a summary of RASDS and major differences between RM-ODP and RASDS. ODP for Space

3. Systems That RASDS Should Describe • Systems that RASDS should describe are large, complex systems with a large number of diverse functions performed by different organizations at various places using a variety of things (hardware and software). • Organizations that should be described by RASDS include organizations that develop spacecraft, organizations that communicate with spacecraft, organizations that use data obtained by spacecraft, etc. • Places that should be described by RASDS include spacecraft (orbiting and landed), tracking stations, control centers, science institutes, etc. • Things (hardware and software) that should be described by RASDS include computers, computer programs, communications networks, radio equipment, hardware elements (such as cameras and robot arms), radio links, etc. ODP for Space

4. Business Concerns Organizational perspective Enterprise Physical Concerns Node & Link perspective Connectivity Computational Concerns Functional composition Functional Data Concerns Relationships and transformations Information Protocol Concerns Communications stack perspective Communications Five Viewpoints of RASDS ODP for Space

5. Enterprise Viewpoint Cross- Support Agreement Agency QRS Mars Exploration Program Federation Mission Q Agency ABC Mission A Proj R GTN B Enterprise Objects Instr S Prog S Instrument Integration Prog C Mission AX Mission BFD Development & Operations Domain GTN Y Mission BFD Proj X Service Z Operations Contract Company XYZ Organization PDQ ODP for Space

6. Monitor & Control Directive Generation Directive Management Directive Execution Mission Planning Data Repository Data Acquisition Mission Analysis LT Data Repository Orbit Determ Spacecraft Analysis Radiometric Data Collect Tracking Functional Viewpoint ODP for Space

7. 1..n 1..n Information Object Information Object Data Object Data Object Representation Information Representation Information Semantic Information Semantic Information Structure Information Structure Information Information Viewpoint S/C Event Plans Observation Plans Directive Generation Command Execution Directive Execution Operation Plans Commands Actual Data Objects S/C Commands Realization Realization Instrument Commands Command Schema & Structure Definition Operations Plan Schema & Structure Definition Data Models Information Objects are exchanged among Functional Objects Instantiation Instantiation Abstract Data Architecture Meta-models ODP for Space

8. Command & Data Handling Computer Spacecraft Transceiver S/C Bus Science Instrument ACS Computer Connectivity Viewpoint SPACECRAFT Mission Planning Computer Internet Space Link Ground Tracking Station Spacecraft Control Computer ODP for Space

9. Communications Viewpoint GROUND SYSTEM SPACECRAFT Payload Commands Command Generation Command Execution C&DH Packet Packet Packet (Relay) Packet Tracking Station TC Space Data Link TC Space Data Link (Relay) TC Space Data Link Frame SLE CLTU SLE CLTU TCP/IP TCP/IP TCP/IP TCP/IP PPP RF Generation PPP RF Generation Onboard Physical Onboard Physical ODP for Space

10. Consistency Among Viewpoints (RASDS) • In order to describe space data systems with multiple viewpoints in a consistent way, it is important to show how various elements described by various viewpoints relate to each other. • In order to do this, we have defined basic relationships among elements as shown on the next page. • Each RASDS viewpoint is used to show elements of a few kinds and the relationships between these elements. • Consistency among viewpoints can be maintained by using the basic relationships among elements shown on the next page. ODP for Space

11. RASDS Elements and Their Relationships Performs EnterpriseObject FunctionalObject Hosts Owns Interacts over Node Connects Link Generates or consumes Is exchanged over InformationObject ODP for Space

12. Consistency Among Viewpoints (RM-ODP) • In RM-ODP, there are not many specific rules to maintain consistency between different viewpoints. • Consistency between viewpoints can be maintained by correspondence between objects, but there are only two explicit rules about correspondence (i.e., between computational and engineering objects, and between engineering and technology objects). • There are no explicit rules on how the enterprise or information viewpoint constrains or affects the other viewpoints. For example, it is not clear how to determine whether the information viewpoint of a system is consistent with the other viewpoints of the same system. ODP for Space

13. Unified Treatment of Objects (RASDS ) • We tried to describe different types of objects in a unified way as much as possible (but we haven’t done this extensively yet ). Management Interfaces: How objects are configured controlled, and reported upon Object Service Interfaces: How services are requested & supplied External Interfaces: How external elements are controlled Core Functions What the object does ODP for Space

14. Unified Treatment of Objects (RM-ODP ) • There are not many general rules that are applicable to different types of objects. • (Example) Although behaviors of objects are mentioned in almost all viewpoints, there are no general rules concerning how to describe behaviors of objects across all the viewpoints. • (Example) Although the concept of roles played by objects is used in the enterprise and computational viewpoints, it is discussed only in the enterprise viewpoint. This concept is useful in other viewpoints as well, because it must be used for determining whether or not two objects can interact with each other. ODP for Space

15. RASDS vs. DoDAF • Although we did not use DoDAF for developing RASDS, we can define a close mapping between RASDS elements and DoDAF elements and between RASDS viewpoints and DoDAF views/products. ODP for Space

16. Correspondence Between RASDS Elements and DoDAF Elements ODP for Space

17. Consistency Among Viewpoints (DoDAF) • Consistency between different views/products in DoDAF can be maintained in a similar way to RASDS. • In DoDAF, relationships between elements in different views/products are clearly defined (e.g., operational activities are implemented by system functions at system nodes) and the users can specify the relationships between instances of different elements as attributes of these elements. ODP for Space

18. DoDAF Elements and Their Relationships(Partial) Operational Activity Performs Operational Node Is implemented by Owns System Function Hosts System Node Generates or consumes Is exchanged between System Data ODP for Space

19. Conclusion • We tried to use RM-ODP as much as possible when we developed RASDS, but we had to make some modifications to RM-ODP so that RASDS can be easily used by people who develop space data systems. • We found that there is some similarity between RASDS and DoDAF. • We hope to continue this dialogue with ODP experts to discuss whether we can harmonize our approaches. ODP for Space