1 / 12

Comprehensive Framework for Space Data Systems Design: RASDS Architecture Overview

The Reference Architecture for Space Data Systems (RASDS) provides a formalized framework to address various concerns in space system design. It encompasses organizational, physical, computational, and communication perspectives, adhering to standards like RM-ODP and IEEE 1471. RASDS outlines the relationships between components, functionality, and processes, facilitating effective integration and interoperability. This architecture supports mission design, risk assessment, and the development of reusable systems through a structured approach to information management, validation, and verification in the context of space operations.

erica
Télécharger la présentation

Comprehensive Framework for Space Data Systems Design: RASDS Architecture Overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RASDS OntologyTop Level Concepts Peter Shames 12 April 2005

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

  3. We formalize and adapt this generic conceptual framework into one for space data system design From the IEEE-1471-2000conceptual framework…

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

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

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

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

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

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

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

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

  12. Backup

More Related