Post on 26-Dec-2015
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