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