SEA-120 Nov 2014

CCSDS System EngineeringArea (SEA): Glossary Cleanup

& Ontology Project

Peter Shames, SEA ADSerge Valera, ESA

Mike Amundsen, API AcademyRobert Blommestijn, ESA

20 Nov 2014

SEA-220 Nov 2014

Motivation for this 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

SEA-3

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

way20 Nov 2014

SEA-4

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.

20 Nov 2014

SEA-5

A Sketch of “Service” ontology

20 Nov 2014

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.

SEA-6

Examples of Glossary Issues, contd

action (RASDS 311.0-M-1)An action is something that happens within an object, either with or without participation of another object. An interaction is an action performed by an object with participation of another object or with its environment.

action (SM&C 520.0‑G‑3)An atomic (non-interruptible) control directive of mission operations (equivalent to a telecommand or ground-segment directive) that can be initiated by manual or automatic control sources, via the M&C service. An action may have arguments and its evolving status can be observed. An action can typically apply pre- and post-execution checks.

20 Nov 2014

SEA-7

A Sketch of “Action” ontology

20 Nov 2014

RASDS: An action is something that happens within an object, either with or without participation of another object. An interaction is an action performed by an object.

MOSC: An atomic (non-interruptible) control directive of mission operations (equivalent to a telecommand or ground-segment directive) that can be initiated … via the M&C service. An action may have arguments …. An action can typically apply pre- and post-execution checks.

Discussion: The MOSC MCS appears to be a specialization of RASDS service. The action looks like a specialization of RASDS action, but “action” in MOSC appears to be more like a generalized directive that can be specialized. MOSC does define service interface but that does not appear in this “action” definition.

NOTE: The MOSC part of this diagram should show “Control Directive” instead of “Action”. We think Action is a specialization of Control Directive.

SEA-8

Examples of Glossary Issues, contd

application (SLE, IP for Transfer Services, 913.1‑B‑1)A software entity in an SLE user system or an SLE provider system that makes use of the ISP1 protocol, as distinguished from the software implementing the protocol layers defined in this Recommended Standard. The application is considered to implement the ‘higher layers’ defined in the architectural model in section 2.

application (AMS protocol, 735.1‑B‑1)A data system implementation, typically taking the form of a set of source code text files, that relies on AMS procedures to accomplish its purposes. Each application is identified by an application name.

application (SOIS Time Access Service, 872.0‑M‑1)Component of the onboard software that makes use of the Time Access Service.

20 Nov 2014

SEA-9

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.

20 Nov 2014

SEA-10

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

20 Nov 2014

SEA-11

Next Steps

• Develop an initial ontology from the Glossary• Create core ontology using best practice open source tools

- There are related activities and tool chains that can be leveraged• Leverage other core ontologies such as ISO-80000 & OMG QUDV

- SOIS XTEDS is doing a focused subset of this work related to electronic data sheets

• Include methods for integrating domain specific ontologies and handling domain specialization

• Review results with other WGs and with SC14• Validate the ontology and make a version available on-line for query

and review• Update it as needed

• And then …• Publish as the official CCSDS ontology• Develop processes for keeping it up to date as new standards are

developed• Propose use as an active part of defining new standards and data

exchanges• Consider evolution of ontology into a UML/SysML profile

20 Nov 2014

SEA-12

Ontology Notes

•Glossary / ontology•Use as a part of active WG processes•Require update of the Ontology as a part of

each meeting•Add other fields and capabilities to the

Ontology:- WG sources, derivation / provenance, links to

abbreviations- Cross links to other definitions- Edit access restrictions (add/mode/delete, but

only by AD & WG chairs) with expert vetting and versioning

- Sort, search, link, filter, capabilities

20 Nov 2014

SEA-13

Ontology Notes

• Add relationships to SC14 and ECSS explicitly to the charter

• Explore relationship to ECSS project to restructure documents

• Evaluate ISO common logic 42707• Adopt QUDV, directly available on-line, SOIS also

references it• Clarify distinction between entities and values• ECSS E-TM-10-23 uses ISO 10303-1:1994 (STEP) that

has the notion that a definition and the term should be replaceable and singular (Serge)

• Serge wants to approach this first from the point of view of the larger problem of semantic interoperability, related to 10-23

• ISO 9007 document on semantic how/what distinction (Serge)

20 Nov 2014

SEA-14

Backup

The following slides are from:

• SysML 1.4:Quantities, Units, Dimensions & Values (QUDV) & ISO 80000 Library

Nicolas RouquetteJet Propulsion LaboratoryCalifornia Institute of TechnologyMarch 2014

• Copyright 2013, 2014, California Institute of Technology (“Caltech”)U.S. Government sponsorship acknowledged. All rights reserved.

20 Nov 2014

SEA-15

Authority for this Effort• Quoted from ORGANIZATION AND PROCESSES FOR THE

CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS, CCSDS A02.1-Y-4, dated April 2014

2.3.2.4.3 Area Director Responsibilities An Area Director is responsible for the work done in his or her WGs, BOFs, and SIGs and is specifically responsible for the following:

c)  making recommendations to the CESG concerning approval for the chartering and formation of WGs;

3.3.2 SYSTEMS ENGINEERING AREA The Systems Engineering Area (SEA) covers system-wide engineering aspects that are so pervasive that they span both the Informatics and Telematics Domains. The AD has the prerogative to define, in alignment with the CCSDS Strategic Plan, the set of projects that this Area contains at any point in time.

20 Nov 2014

SEA-16

Using VIM 3rd edition in SysML 1.4 & QUDV

Normative SysML Non-normative QUDV & ISO-80000

1 Quantities and units (30 definitions) language concept

modeling pattern

language concept

modeling pattern

ISO-80000-1 Library

1.1 quantity ✔        1.2 kind of quantity     ✔    1.3 system of quantities     ✔    1.4 base quantity     ✔    1.5 derived quantity     ✔    1.6 International System of Quantities (ISQ)         ✔1.7 quantity dimension     ✔    1.8 quantity of dimension one     ✔    1.9 measurement unit ✔        1.10 base unit     ✔    1.11 derived unit     ✔    1.12 coherent derived unit       ✔  1.13 system of units     ✔    1.14 coherent system of units       ✔  1.15 off-system measurement unit       ✔  1.16 International System of Units (SI)         ✔1.17 multiple of a unit     ✔    1.18 submultiple of a unit     ✔    1.19 quantity value   ✔      1.20 numerical quantity value   ✔      1.21 quantity calculus       ✔  1.22 quantity equation     ✔    1.23 unit equation     ✔    1.24 conversion factor between units     ✔    1.25 numerical value equation   ✔      1.26 ordinal quantity   ✔      1.27 quantity-value scale          1.28 ordinal quantity-value scale   ✔   ✔  1.29 conventional reference scale   ✔   ✔  1.30 nominal property       ✔  

No Coverage in QUDV or SysML

2 Measurement (53 definitions)3 Devices for measurement (12 definitions)4 Properties of measuring devices (31 definitions)5 Measurement standards (etalons) (18 definitions)

http://www.bipm.org/en/publications/guides/vim.html

20 Nov 2014

SEA-17

Systems of Units & Quantity KindsNormative SysML Non-normative QUDV & ISO-80000

Def. Quantities and units (30 definitions) language concept

modeling pattern

language concept

modeling pattern

ISO-80000-1 Library

1.3 system of quantities     ✔    1.6 International System of Quantities (ISQ)         ✔1.13 system of units     ✔    1.16 International System of Units (SI)         ✔

20 Nov 2014

SEA-18

Practical Considerations for Modeling Values in SysML

#1: Recognize the distinct levels of modeling involved

• A Level depends on those abovei < j => Vi depends on Vj

• V4 < V5See VIM3 & ISO 80000-1 foreword:

This first edition of ISO 80000-1 cancels and replaces ISO 31-0:1992 and ISO 1000:1992. The major technical changes from the previous standard are the following: the structure has been changed to emphasize that quantities come first and units then follow;

• V3 < V4, V5Per SysML ValueType

• V2 < V3Per UML TypedElement/Type relationship

• V1 < V2Per UML ValueSpecification/Slot/ StructuralFeature & defaultValue relationships

QuantityKinds

Units

ValueTypes(QuantityKind, Unit)

Value Properties(typed by ValueTypes)

Value Specifications(typed by ValueTypes)

V1

V2

V3

V4

V5

Runtime ValuesV0

20 Nov 2014

SEA-19

Practical Considerations for Modeling Values in SysML

#2: Recognize the alignment with UML

QuantityKinds

Units

ValueTypes(QuantityKind, Unit)

Value Properties(typed by ValueTypes)

Value Specifications(typed by ValueTypes)

V1

V2

V3

V4

V5

Runtime ValuesV0

UML InstanceSpecifications (classifier = SysML or QUDV

Unit or QuantityKind)

UML DataTypes(stereotype = SysML::ValueType

& stereotype tags: quantityKind, unit)

UML Properties(type = <<ValueType>> UML DataType)

UML ValueSpecifications(type = <<ValueType>> UML DataType)

Varies by methodology

20 Nov 2014

SEA-20

Practical Considerations for Modeling Values in SysML

#3: Recognize the implications of DataType modeling in UML

ValueTypes(QuantityKind, Unit)

Value Properties(typed by ValueTypes)

Value Specifications(typed by ValueTypes)

V1

V2

V3

Runtime ValuesV0

UML DataTypes

UML ValueSpecifications

To Be Decided

- Scalar?- Structured?

- Literals?- Expressions?- Intervals?- Instance

Specifications?

Choices made about datatype modeling…

… have implications for modeling values…

… and type checking !

The conformance of a ValueSpecificationto a ValueType depends on these choices!

20 Nov 2014