1. Application of ODP for Space Development
17 October, 2006
Takahiro Yamada (JAXA/ISAS)
Chair, Systems Architecture WG,
Consultative Committee for Space 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. 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

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

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

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

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

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

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
Enterprise Object
Functional Object
Hosts
Owns
Interacts over
Node
Connects
Link
Generates or consumes
Is exchanged over
Information Object
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
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

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