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

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

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

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

5. RASDS Elements and Their Relationships

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

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

8. 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).

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

10. 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).

11. 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)

12. 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)

13. 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)

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

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

16. 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).

17. 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?

18. ANSI/IEEE
ANSI/IEEE “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.

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