1. SEA-1 20 Nov 2014 CCSDS System Engineering Area (SEA): Glossary Cleanup & Ontology Project Peter Shames, SEA AD Serge Valera, ESA Mike Amundsen, API Academy Robert Blommestijn, ESA 20 Nov 2014

2. SEA-2 20 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 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

3. 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 way 20 Nov 2014

4. 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

5. 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.

6. 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)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.arguments 20 Nov 2014

7. 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. arguments 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.

8. SEA-8 Examples of Glossary Issues, contd application (SLE, IP for Transfer Services, 913.1 ‑ B ‑ 1)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)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)872.0 ‑ M ‑ 1 Component of the onboard software that makes use of the Time Access Service. 20 Nov 2014

9. 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

10. 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

11. 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

12. 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

13. 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

14. SEA-14 Backup The following slides are from: SysML 1.4: Quantities, Units, Dimensions & Values (QUDV) & ISO 80000 Library Nicolas Rouquette Jet Propulsion Laboratory California Institute of Technology March 2014 Copyright 2013, 2014, California Institute of Technology (“Caltech”) U.S. Government sponsorship acknowledged. All rights reserved. 20 Nov 2014

15. 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

16. SEA-16 Using VIM 3 rd edition in SysML 1.4 & QUDV Normative SysMLNon-normative QUDV & ISO-80000 1Quantities 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 2Measurement (53 definitions) 3Devices for measurement (12 definitions) 4Properties of measuring devices (31 definitions) 5Measurement standards (etalons) (18 definitions) http://www.bipm.org/en/publications/guides/vim.html 20 Nov 2014

17. SEA-17 Systems of Units & Quantity Kinds Normative SysMLNon-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

18. SEA-18 Practical Considerations for Modeling Values in SysML #1: Recognize the distinct levels of modeling involved A Level depends on those above i Vi depends on Vj V4 < V5 See 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, V5 Per SysML ValueType V2 < V3 Per UML TypedElement/Type relationship V1 < V2 Per 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 Values V0 20 Nov 2014

19. 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 Values V0 UML InstanceSpecifications (classifier = SysML or QUDV Unit or QuantityKind) UML DataTypes (stereotype = SysML::ValueType & stereotype tags: quantityKind, unit) UML Properties (type = > UML DataType) UML ValueSpecifications (type = > UML DataType) Varies by methodology 20 Nov 2014

20. 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 Values V0 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 ValueSpecification to a ValueType depends on these choices! 20 Nov 2014