Version 3 April 21, 2006 Takahiro Yamada (JAXA/ISAS) RASDS, RM-ODP and DoDAF Version 3 April 21, 2006 Takahiro Yamada (JAXA/ISAS)

Introduction This document contains the result of an analysis of the relationship between RASDS and RM-ODP (including UML4ODP) and the relationship between RASDS and DoDAF.

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 space agencies, manufacturers, (tracking and communications) service providers, users (of data produced 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), RF links, etc.

Elements and Their Relationships In order to describe space data systems, it is important to show what kinds of elements exist in the system and what kinds of relationships exist between elements. In order to do this, we have defined classes of basic elements and classes of basic relationships between 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 between different viewpoints can be maintained by using the basic relationships between different kinds of elements shown on the next page.

RASDS Elements and Their Relationships

RASDS vs. RM-ODP and UML4ODP (Consistency) In RM-ODP, there are only few 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 three viewpoints. For example, it is all up to the user to determine ways to describe how the policies of enterprise objects are implemented in the other viewpoints.

RASDS vs. RM-ODP and UML4ODP (General Rules) There are only few general rules that are applicable to all the viewpoints. (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 (and possibly in other viewpoints as well, because this concept must be used for determining whether or not two objects can interact with each other), it is discussed only in the enterprise viewpoint.

RASDS vs. RM-ODP and UML4ODP (Enterprise Viewpoint) It would be useful if there were methods for describing different types of enterprise objects such as: Enterprise objects that are almost always used as actors of actions (for example, organizations) Enterprise objects that are almost always used as artifacts in actions (for example, documents) Enterprise objects that are almost always used as resources in actions (for example, facilities) It would be useful if there were methods for describing basic relationships between different types of enterprise objects (for example, an organization owns resources).

RASDS vs. RM-ODP and UML4ODP (Information Viewpoint) We need to do some more analysis to determine whether the RM-ODP Information Viewpoint is sufficient for describing information produced by spacecraft. We also need to compare the CCSDS Information Architecture Reference Model with the RM-ODP Information Viewpoint.

RASDS vs. DoDAF (General) 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, as shown on the next three pages. A major difference between RASDS and DoDAF is that the RASDS information object maps to both the information element (OV-3) and the system data (SV-6) of DoDAF. RASDS does not have a standard way of describing behaviors (OV-6 and SV-10), performance (SV-7), evolution (SV-8), or forecast (SV-9 and TV-2).

Correspondence Between RASDS and DoDAF Elements RASDS 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) Cross-support interface (CV) System Functions (SV-4) Functional Objects (FV) System Data (SV-6)

Correspondence Between RASDS and DoDAF Views (1/2) DODAF View and Product RASDS Viewpoint Overview and Summary Information (AV-1) None Integrated Dictionary (AV-2) High-Level Operational Concept Graphic (OV-1) Operational Node ConnectivityDescription (OV-2) Enterprise Viewpoint Operational Information Exchange Matrix (OV-3) Information Viewpoint Organizational Relationships Chart (OV-4) Operational Activity Model (OV-5) Operational Rules Model, etc (OV-6) Logical Data Model (OV-7) Systems Interface Description (SV-1) Connectivity Viewpoint Systems Communications Description (SV-2) Comm. Viewpoint Systems-Systems Matrix (SV-3)

Correspondence Between RASDS and DoDAF Views (2/2) DODAF View and Product RASDS View Systems Functionality Description (SV-4) Functional Viewpoint Operational Activity to Systems Functionality Traceability Matrix (SV-5) None Systems Data Exchange Matrix (SV-6) Information Viewpoint Systems Performance Parameters Matrix (SV-7) Systems Evolution Description (SV-8) Systems Technology Forecasts (SV-9) Systems Functionality and Timing Descriptions (SV-10) Physical Schema (SV-11) Information View Technical Standards Profile (TV-1) (partially, Comm. Viewpoint) Technical Standards Forecast (TV-2)

RASDS vs. DoDAF (Consistency) Consistency between different views 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 must specify the relationships between instances of different elements. Although it is not shown in the DoDAF documents, we can draw a diagram similar to the one on page 5 (see the next page).

DoDAF Elements and Their Relationships (Partial and not Exact) Performs Operational Activity Operational Node Is Implemented By Owns Hosts System Function System Node Generates or Consumes Is Exchanged Between System Data

Things That Should (Hopefully) Be Done About RASDS-RMODP-DoDAF Extract general rules that lie under RASDS, RM-ODP and DoDAF, including Rules for describing views, Rules for describing elements, Rules for describing relationships between elements, Rules for describing behaviors of elements, Rules for describing roles played by elements, and Rules for describing information and data Define a UML profile for the above rules. Is this too difficult or too late? I hope not! But, to do this, we have to answer some theoretical questions (see the next page).

Theoretical Questions Someone must prepare answers to the following questions that can be used in any architectural technique. What are models? What is the relationship between models and things that are modeled? What are views? How should views be constructed? How should different views be related? How should consistency between views be established and checked?

ANSI/IEEE 1471-2000 ANSI/IEEE 1471-2000 “Recommended Practice for Architectural Description of Software-Intensive Systems” provides answers to many of the questions listed in the previous. However, I think we need to check whether this standard provides guidance necessary for different groups to develop different views in a consistent way. If there is a need, we should consider expanding this standard.

How Should We Proceed? I think it would be very beneficial if we could establish a forum to discuss the relationship between different architecting/modeling techniques in hope of finding common solutions.