RASDS Ontology Top Level Concepts Peter Shames 12 April 2005

Reference Architecture for Space Data Systems Enterprise Business Concerns Organizational perspective Connectivity Physical Concerns Node & Link perspective Functional Computational Concerns Functional composition Information Data Concerns Relationships and transformations Communications Protocol Concerns Communications stack perspective Derived from: RM-ODP, ISO Compliant with IEEE 1471

From the IEEE conceptual framework… We formalize and adapt this generic conceptual framework into one for space data system design

Space System Domain Architectural Viewpoints Enterprise Business Concerns Organizational perspective Physical Physical Concerns Component, Connector & external elements Functional Computational Concerns Functional composition Information Data Concerns Relationships and transformations Technology Technology & Protocol Concerns Framework, tools, standards perspective Derived from: RM-ODP & CCSDS RASDS Engineering System Design Concerns Allocation, methods, performance

Semantic Information Model Development Process RASDS as Architectural Framework * Physical Viewpoint Connectivity Components & connectors Physics of Motion End to End View External Forces Performance Augment to Capture: Structure Power Mass Thermal Orbit Propulsion Enterprise Viewpoint Organizations People Use Case- Scenarios Contracts/Agreeme nts Augment to Capture: Mission Design & Drivers Requirements Cost Enterprise Risks Engineering Viewpoint System Design & Construction Functional allocation Distribution of functions and trade-offs Development Validation & verification Based on RMODP** * Reference Architecture for Space Data Systems (RASDS) ** Reference Model Open Distributed Processing (RMODP, ISO spec) Functional Viewpoint Functional Structure Functional Behavior & interfaces End to End View Cross Support Service Technology Viewpoint Protocols & comm standards End to end Information Transfer Mechanisms Cross Support Services Information Viewpoint Information & information management Scenarios End to End View

RASDS Top Level Object Ontology Function Behavior Interfaces Constraints Logical structure Connector Type Attributes Communication Protocol stack Standards Organization Requirements Objectives Goals Scenarios Mission FulfilledBy Fulfills IsAllocatedTo ComposedOf ContainsInstances Produces Consumes ConnectVia ConnectToPort Uses ProvidesService AssociatedWith ImplementedOn Information Data Metadata Rules Owns/Operates Component Type Attributes Ports Calls Environment Physical Environs Affects Location Attributes Perspective (Viewpoint) Defines Objects Defines Rules Exposes Concerns Defines Relations

RASDS Ontology and Traditional (sub-)Systems View Function Behavior Interfaces Constraints Logical structure Connector Type Attributes IsAllocatedTo ComposedOf ContainsInstances Produces Consumes ConnectVia ConnectToPort Information Data Metadata Rules Component Type Attributes Ports Calls System View Contains Objects Defines Rules Exposes Concerns Location A (sub-)system is a set of connected components with allocated functionality (sometimes includes people & procedures) Could just say that RASDS describes a system from several different perspectives (Views)

RASDS Scenario Ontology Activity ActivityType Duration Function Behavior Interfaces Constraints Structure Organization Requirements Objectives Goals Scenarios Mission SequenceOf Fulfills Performs ComposedOf Produces Results SequenceOf HasResult Action ActionType Results Expected result Timeline MissionPhase Lifecycle Command Command Type Element Final State invokes HasResult Defines ActivitySet identifies Activity sets are tied to mission lifecycle timeline and to mission phases and critical events

A Notional MDS Ontology HL Goals HLGoalType Duration Function Behavior Interfaces Constraints Structure Organization Requirements Objectives Scenarios Mission SequenceOf Fulfills Performs ComposedOf Produces Results DecomposedInto HasResult Action ActionType FinalState Expected State Timeline MissionPhase Lifecycle Goals GoalType Element Expected Final State Requests Achievement HasResult Defines ActivitySet identifies Actual Final State Controls ComposedOf Measurements MDS conceptual framework appears to be an excellent approach for architecting reusable control systems Component Type Attributes Ports Location Observables State ConnectVia ConnectTo Port Affects Connector Type Attributes State Environment Physical Environs Attributes State

NexIOM Ontology (w/ RASDS Markups) Function Connector Communication Organization Information ? Component Environment Perspective Function ? Scenario ? of Component Function ? Activity? Metric means Goals here Not Addressed

Xcalibr Ontology (inferred from doc) S/C Bus Metrics Descriptors Description Composed of ComposedOf provides Subsystem Description Metrics Descriptors Type / class Component Description Metrics Descriptors Type / class Connector Communication Organization Information Environment Perspective Function Type / Class > Structure / mechanism Propulsion Electrical Power Thermal Control Described by Type / Class > Bus Structure Primary Structure Secondary Structure Deployable Structure Descriptors > Design type Structure type Primary material Type / class Interface Structure etc, etc Communications C&DH GNC Metrics > Mass Power Other phys attrib ComposedOf Metrics means Attributes here Components have subclasses C&DH includes some S/W Functions GNC does not include S/W Functions !! Components include some Connector attributes Not Addressed

Backup