RASDS Ontology Top Level Concepts
description
Transcript of RASDS Ontology Top Level Concepts
RASDS OntologyTop Level Concepts
Peter Shames
12 April 2005
Reference Architecture for Space Data Systems
EnterpriseBusiness ConcernsOrganizational perspective
ConnectivityPhysical ConcernsNode & Link perspective
Functional Computational ConcernsFunctional composition
Information Data ConcernsRelationships and transformations
CommunicationsProtocol ConcernsCommunications stack perspective
Derived from: RM-ODP, ISO 10746Compliant with IEEE 1471
From the IEEE-1471-2000conceptual framework…
We formalize and adapt this generic conceptualframework into one forspace data system design
Space System Domain Architectural Viewpoints
EnterpriseBusiness ConcernsOrganizational perspective
PhysicalPhysical ConcernsComponent, Connector & external elements
FunctionalComputational ConcernsFunctional composition
InformationData ConcernsRelationships and transformations
TechnologyTechnology & Protocol ConcernsFramework, tools, standards perspective
Derived from: RM-ODP & CCSDS RASDS
EngineeringSystem Design ConcernsAllocation, 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/Agreements
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 10746 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
RASDSTop 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
Composed Of
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
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)
RASDSScenario Ontology
Activity
• ActivityType
• Duration
Function
• Behavior
• Interfaces
• Constraints
• Structure
Organization
• Requirements
• Objectives
• Goals
• Scenarios
• Mission
SequenceOf
Fulfills
Performs
ComposedOf
Composed Of
ProducesResults
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
Composed Of
ProducesResults
DecomposedInto
HasResult
Action
• ActionType
• FinalState
• Expected State
Timeline
• MissionPhase
• Lifecycle
Goals
• GoalType
• Element
• Expected Final State
RequestsAchievement
HasResult
Defines
• ActivitySet
identifies
• Actual Final State
ControlsComposedOf
Measurements
MDS conceptual framework appears to be an excellent approach for architecting reusable control systems
Component
• Type
• Attributes
• Ports
• Location
• Observables
• State
• State
ConnectVia
ConnectToPort
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 meansGoals here
Not Addressed
Xcalibr Ontology(inferred from doc)
S/C Bus
• Metrics
• Descriptors
• Description
Composed of
ComposedOf
provides
provides
Subsystem
• Description
• Metrics
• Descriptors
• Type / class
Component
• Description
• Metrics
• Descriptors
• Type / class
Connector
Communication
Organization
Information
Environment
Perspective
Function
Type / Class<<subsystem>>
• Structure / mechanism
• Propulsion
• Electrical Power
• Thermal Control
Described by
Type / Class<< structure / mechanism>>
• Bus Structure
• Primary Structure
• Secondary Structure
• Deployable Structure
Descriptors<< structure / mechanism>>
• Design type
• Structure type
• Primary material
• Type / class• Interface Structure
• etc, etc
• Communications
• C&DH
• GNC
Metrics<<subsystem>>
• Mass
• Power
• Other phys attrib
ComposedOf
Metrics meansAttributes here
Components havesubclasses
C&DH includes some S/W Functions
GNC does not include S/W Functions !! Components include
some Connector attributes
Not Addressed
Backup