Upload
abraham-daniel
View
218
Download
0
Embed Size (px)
Citation preview
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