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

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

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

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

Enterprise Viewpoint Agency QRS Mars Exploration Program Federation 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 Company XYZ Operations Contract Organization PDQ ODP for Space

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

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

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

Communications Viewpoint GROUND SYSTEM SPACECRAFT Payload Command Generation Commands Command Execution C&DH Packet Packet (Relay) Packet 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 PPP RF Generation RF Generation Onboard Physical Onboard Physical ODP for Space

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

RASDS Elements and Their Relationships Performs Enterprise Object Functional Object Hosts Owns Interacts over Node Connects Link Generates or consumes Is exchanged over Information Object ODP for Space

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

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

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

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

Correspondence Between RASDS Elements and DoDAF Elements Operational Nodes (OV-2) Enterprise Objects (EV) Needlines (OV-2) Enterprise Interactions (EV) Information Elements (OV-3) Information Objects (IV) Operational Activities (OV-5) Enterprise Operations (EV) Systems Nodes (SV-1) Nodes (CV) Systems (SV-1) Sub-nodes (CV) System Interfaces (SV-1) Links (CV) Key Interface (SV-1) Functional interface that crosses an enterprise boundary (CV) System Functions (SV-4) Functional Objects (FV) System Data (SV-6) ODP for Space

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

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

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