Post on 11-Jan-2016
Space Data Systems ArchitecturesSpace Data Systems ArchitecturesRASDS and OntologiesRASDS and Ontologies
2 Mar 2015
Peter ShamesNASA Jet Propulsion Laboratory, California Institute of Technology
SC 13/SC 14 Coordination
• SC 13 and SC 14 share some common “territory” – Agreeing on shared terminology and representations, where
appropriate, should help both SC and our communities
• Material to be presented– CCSDS Reference Architecture and extensions as “common
ground” for terminology– CCSDS / SC 13 plans regarding the RASDS refresh and
adding operational and service viewpoints– CCSDS / SC 13 plans regarding ontologies and information
models– CCSDS / SC 13 plans regarding XML standards that use
defined terms
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 2
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 3
Architecting and Engineering Space Systems is Hard
• Many Stakeholders– Organizations (NASA, international partners, contractors)– Competing requirements (cost, schedule, risk, science, technology,
survivability, maintainability, buildability)
• Many different system aspects– Logical (functionality, information, control)– Physical (hardware, software, environment)– Interoperability and cross support– Science & operational capabilities– Autonomous and human mediated operations
• Long and complex system (of systems) lifecycle– Development phases
• Requirements, design, implement, I&T, V&V• Operations and sustaining
– Cradle to grave lifecycle– Mission view vs infrastructure view
…motion
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 4
What is System Architecture and …
• System architectures are complex, multi-faceted things– Hardware structures– Software elements– Functional composition– Control and data flows– Environment and interactions– Organizational interfaces & contracts– Operational procedures– End-to-end communications paths– Science, user, & operator interfaces– And don’t forget the interactions among these, electrical,
power, thermal, dynamic, etc, etc
• Where do you “stand” to get a view of all this?
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 5
… why Views?
• As with any programming or system engineering activity …– Breaking a problem into pieces makes it more manageable– Smaller pieces are easier to work with– Logical coherence within a “piece” better supports reasoning about
behavior and properties
• Viewpoints are perspectives on an architecture, intended to give us useful leverage in understanding and analyzing the system– But, we need to be clear about what is represented in any given
viewpoint, and– We also need to model the relationships among the elements
shown in different views, because …– A structural element may also act as an electrical ground plane and
a thermal shield
• So how to we arrive at a useful set of views and …– How does this relate to the current methods that are in vogue, I.e.
SysML and DoDAF?
From the IEEE-1471-2000conceptual framework…
We formalize and adapt this generic conceptualframework into one forspace data system design
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 6
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 and ISO 42010
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 7
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
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 8
Semantic Information Model Development Process
RASDS as Architectural Framework *
Connectivity Viewpoint•Connectivity
•Components & connectors
•Physics of Motion
•End to End View
•External Forces
•Performance
Physical
Viewpoint
Structure
Power
Mass
Thermal
Orbit
Propulsion
Enterprise Viewpoint
•Organizations
•People
•Use Case-Scenarios
•Contracts/Agreements
Augment to Capture:
•Mission Design & Drivers
•Requirements
•Phases
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
Mission Assurance Viewpoint
• Enterprise Risks
• Cost
• Validation & verification
• Safety
• Reliability & quality
Operational
Viewpoint
•Processes
•Procedures
•Activities, tasks, actions
•Events, scenarios
•Modes & states2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 9
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 10
System Architecture Model Objectives
• Provide clear & unambiguous views of the design• Show relationship of design to requirements and
driving scenarios• Separate design concerns in the model to maintain
degrees of freedom to do trades• Detail the model & views to the level appropriate for
further systems engineering, support evolving design• Enable concurrent design of spacecraft, ground
systems, science operations, control systems, and components
• Establish system engineering (SE) controls over the allocations and interfaces
• Provide executable models of the interactions (future)
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 11
Viewpoint Elements - Connectivity Example
• Stakeholders: system engineers, sub-system engineers, acquirers, developers, operators, users, and maintainers
• Concerns: implemented functions, allocation to the physical structures of the system, their connections, and how they interact with the environment
• Modeling Language: engineering objects (S/W or H/W), physical objects (nodes) and their connections (links), physical behavior, motion and interactions, the environment, constraints
• Consistency & Completeness Methods: every functional element maps to at least one physical element, no functional element is not mapped, no physical element is not mapped to a function, and there is structural integrity and consistency
Proposed RASDS Extensions (SC 14 Cooperation)
• Service Viewpoint– Already introduced in CCSDS SCCS-ARD/ADD– Covers system service interfaces and interface bindings
• Physical viewpoint– Extend present Connectivity Viewpoint– Add support for physical elements, structures, power,
thermal views (perhaps each their own Viewpoint)
• Operational Viewpoint– Extend present Enterprise Viewpoint– Add support for organizational processes, procedures, and
related behavior– Possibly derived from DODAF OV’s
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 12
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 13
Typical Connectivity (& Physical) Views
• Data System view – Describes instruments, computers, and data storage components, their data system attributes and the communications connectors (busses, networks, point to point links) that are used in the system.
• Telecomm view – Describes the telecomm components (antenna, transceiver), their attributes and their connectors (RF or optical links).
• Navigation view – Describes the motion of the major elements of the system (trajectory, path, orbit), including their interaction with external elements and forces that are outside of the control of the system, but that must be modeled with it to understand system behavior (planets, asteroids, solar pressure, gravity)
• Structural view – Describes the structural components in the system (s/c bus, struts, panels, articulation), their physical attributes and connectors, along with the relevant structural aspects of other components (mass, stiffness, attachment)
• Thermal view – Describes the active and passive thermal components in the system (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with the thermal properties of other components (i.e. instruments as thermal sources (or sinks), antennas or solar panels as sun shade)
• Power view – Describes the active and passive power components in the system (solar panels, batteries, RTGs) within the system and their connectors, along with the power properties of other components (data system and propulsion elements as power sinks and structural panels as grounding plane)
• Propulsion view – Describes the active and passive propulsion components in the system (thrusters, gyros, motors, wheels) within the system and their connectors, along with the propulsive properties of other components
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 14
Connectivity (& Physical) Viewpoint - Component / Connector (Node / Link)
Examples• Data System
– Components (CPU, instruments, SSR)– Connectors (network, data bus, serial lines, backplane)
• Telecomm– Components (transmitter, receiver, antenna)– Connectors (RF link, optical link, waveguide)
• Structural– Components (S/C bus, physical link, arm, struct attrib of other components)– Connectors (joint, bolt (incl explosive), weld)
• Power– Components (solar panel, battery, RTG, switches, power attrib of other
components)– Connectors (power bus)
• Thermal– Components (cooler, heater, thermal attrib of other components)– Connectors (heat pipe, duct, free space radiation)
• Propulsion– Components (motor, wheel, thruster)– Connectors (contact patch, gravity )
CCSDS / SC 13 futures
• Proposed work– Update RASDS, add viewpoints
• Consider MBSE / SysML extensions
– Re-define CCSDS Glossary in ontology form (OWL / RDF)
• Build on-line repository for human and machine access• Develop process for extending / adding domain specific
extensions
– Utilize formal terms in ontology to build future XML schema
• Revised existing schema as these docs become eligible for review
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 15
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 16
Summary
• RASDS / IEEE 1471 concepts of viewpoints and related formal methods can be directly used to support broader space data system standardization
– The terminology itself provides a formal basis for defining domain specific extensions
– Proposed extensions to the core framework should be suitable for SC 14 work
• Evolution to a more formal ontological description will make it more suitable for use and extension
– Tools will make the ontology more manageable and verifiable– On-line form will make the ontology more accessible– Links and relationships managed and verified by tools – Methods can be defined to support community and domain extensions in a
controlled way
• Next Steps: Develop the baseline ontology (already started) and the framework for extension
– Reach agreement within SC 13, and with SC 14, for use and extension of the core
– Host the ontology in an accessible location (CCSDS SANA has been discussed)
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 17
BACKUP
Introduction to Ontology
• Ontology– Formal set of definitions of terms using a limited
vocabulary– Definition of relationships among terms– Specified in a machine accessible and analyzable
form
• Ontology representations– Document, XML file, or query-able database– OWL DL (Web Ontology Language - Description
Logic) is a restricted sublanguage that retains maximum expressiveness with decidability and practical reasoning algorithms
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 18
Value of Ontology(s)
• Authoritative reference for terminology• Means for describing concepts in a machine
interpretable way• Real-time interrogation of interfaces: service
architectures, electronic data sheets
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 19
2 Mar 2015
Motivation for the CCSDS Glossary Cleanup & Ontology Project
• CCSDS currently has a Glossary of terms published at: http://sanaregistry.org/r/glossary/glossary.html
• The Glossary is a compendium of terms developed over the thirty+ years of CCSDS development, initially by the three CCSDS Panels that had totally disjoint domains
• As CCSDS has grown, added Areas, Working Groups, and topics, there are now interfaces and overlaps both in work content and in terminology, but no defined means for handling them
• This project proposes to tackle a part of this issue head on by:– Creating an Ontology from the existing CCSDS Glossary– Doing the work to regularize and formalize the use of terms – Work any issues that arise with the affected WGs– Make the resulting Ontology available on-line for human and machine reference with a
technology agnostic set of transformations– Propose a process for managing the Ontology in the future as part of WG processes
SC 13 / SC 14 RASDS & Ontologies PS 20
Ontology Value Proposition
• Makes specs more tractable, provides access to semantic meaning of terms, parameters, values– Helps users (end users, developers, & suppliers) understand the
specs & requirements– Improves semantic interoperability of all CCSDS standards– Helps spec writers to achieve consistency
• Improves readability, consistency, and comprehensibility of whole document set – Provides interactive links among normative terminology and links
to informative data– Assumes edits are done during 5 year document refresh
• Could shorten the time to develop consistent standards– Validated, accessible, source of terminology– Ability to augment / extend terminology in a consistent way
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 21
Examples of Glossary Issues
service (RASDS, 311.0-M-1)
A service is a provision of an interface of an object to support actions of another object.
service user/provider (SLE Ref Model, 910.4-B-2)
An entity that offers a service to another by means of one or more of its ports is called a service provider (provider). The other entity is called a service user (user). An entity may be a provider of some services and a user of others.
service (SM&C MORM, 520.1-M-1)
A set of capabilities that a component provides to another component via an interface. A Service is defined in terms of the set of operations that can be invoked and performed through the Service Interface. Service specifications define the capabilities, behaviour and external interfaces, but do not define the implementation.
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 22
A Sketch of “Service” ontology
2 Mar 2015
RASDS: A service is a provision of an interface of an object to support actions of another object.
SLE: An entity that offers a service to another by means of one or more of its ports is called a service provider (provider). The other entity is called a service user (user). An entity may be a provider of some services and a user of others.
Discussion: The SLE service is a specialization of RASDS service. The SLE entity looks like a specialization of RASDS object, but the SLE entity appears to be an enterprise viewpoint object related to organization rather than a system object.
SC 13 / SC 14 RASDS & Ontologies PS 23
Observations
• Existing CCSDS definitions tend to make somewhat casual use of terms like “component”, “entity”, “interface”, “port”, “code”, “software”.
• Definitions have evolved over the years even within domains. • Terms defined in different specs often are, when analyzed,
specializations of other terms or are terms that relate to different viewpoints.
• Relationships among definitions are almost always “casual” and not explicit, i.e. “A hardware component may contain other components. The contained components may be hardware or software.”
• We do not have a tradition or guidance to define consistent sets of terms across all sets of documents.
• An ontology would render all of these in a formal way.
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 24
Create a Formal Ontology• A formal ontology could be developed from the Glossary to resolve these
issues– Provide formal and correct definitions, sources, relationships and on-line lookup
of terms– Do the work to regularize and formalize the use of terms– Work any issues that arise with the affected WGs
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 25
XML and Ontologies
• XML is often proposed as a widely accepted technology for exchanging information
• XML itself, in the absence of formal, carefully constructed, definitions can become just another colloquial data set
• XML documents, constrained by a well constructed ontology, can be a safe means for machine interaction
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 26
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 27
RM-ODP & RASDS Characteristics
• The specification of a complete system in terms of viewpoints.
• The use of a common object model for the specification of the system from every viewpoint.
• The use of views to tailor user or domain specific analyses of the system.
• The definition of a modeling infrastructure that provides support services for system applications, hiding the complexity and problems of defining mission specific models.
• The definition of a set of common transformation functions that provide general services needed during the design and development of space systems.
• A framework for the evaluation of conformance of models and designs based on conformance points.
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 28
RASDSTop Level Object
Ontology
Function
• Behavior
• Interfaces
• Constraints
• Logical structure
Link
• 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
Node
• Type
• Attributes
• Ports
Calls
Environment
• Physical Environs
Affects
• Location
• Attributes
Perspective(Viewpoint)
• Defines Objects
• Defines Rules
• Exposes Concerns
• Defines Relations
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 29
Definitions of DoDAF Views
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 30
Correspondence Between RASDS and DoDAF Elements
DoDAF Elements RASDS ElementsOperational 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) Cross-support interface (CV)
System Functions (SV-4) Functional Objects (FV)
System Data (SV-6) Information Objects (IV)
Source: Takahiro Yamada, SAWG Chair
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 31
Correspondence Between RASDS and DoDAF Views (1/2)
DODAF View and Product RASDS Viewpoint
Overview and Summary Information (AV-1) None
Integrated Dictionary (AV-2) None
High-Level Operational Concept Graphic (OV-1) None
Operational Node ConnectivityDescription (OV-2) Enterprise Viewpoint
Operational Information Exchange Matrix (OV-3) Information Viewpoint
Organizational Relationships Chart (OV-4) Enterprise Viewpoint
Operational Activity Model (OV-5) Enterprise Viewpoint
Operational Rules Model, etc (OV-6) None
Logical Data Model (OV-7) Information Viewpoint
Systems Interface Description (SV-1) Connectivity Viewpoint
Systems Communications Description (SV-2) Comm. Viewpoint
Systems-Systems Matrix (SV-3) NoneSource: Takahiro Yamada, SAWG Chair
2 Mar 2015 SC 13 / SC 14 RASDS & Ontologies PS 32
Correspondence Between RASDS and DoDAF Views (2/2)
DODAF View and Product RASDS ViewSystems Functionality Description (SV-4) Functional Viewpoint
Operational Activity to Systems Functionality Traceability Matrix (SV-5)
Relationships defined
Systems Data Exchange Matrix (SV-6) Information Viewpoint
Systems Performance Parameters Matrix (SV-7) Connectivity Viewpoint
Systems Evolution Description (SV-8) None
Systems Technology Forecasts (SV-9) None
Systems Functionality and Timing Descriptions (SV-10)
None
Physical Schema (SV-11) Information View
Technical Standards Profile (TV-1) (partially, Comm. Viewpoint)
Technical Standards Forecast (TV-2) None
Source: Takahiro Yamada, SAWG Chair