1. Space Data Systems Architectures RASDS and Ontologies 2 Mar 2015 Peter Shames NASA Jet Propulsion Laboratory, California Institute of Technology

2. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 2

3. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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

4. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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?

5. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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?

6. From the IEEE-1471-2000 conceptual framework… We formalize and adapt this generic conceptual framework into one for space data system design 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 6

7. Reference Architecture for Space Data Systems Enterprise Business Concerns Organizational perspective Connectivity Physical Concerns Node & Link perspective Functional Computational Concerns Functional composition Information Data Concerns Relationships and transformations Communications Protocol Concerns Communications stack perspective Derived from: RM-ODP, ISO 10746 Compliant with IEEE 1471 and ISO 42010 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 7

8. Space System Domain Architectural Viewpoints Enterprise Business Concerns Organizational perspective Physical Physical Concerns Component, Connector & external elements Functional Computational Concerns Functional composition Information Data Concerns Relationships and transformations Technology Technology & Protocol Concerns Framework, tools, standards perspective Derived from: RM-ODP & CCSDS RASDS Engineering System Design Concerns Allocation, methods, performance 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 8

9. 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 & states 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 9

10. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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)

11. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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

12. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 12

13. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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

14. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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 )

15. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 15

16. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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)

17. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 17 BACKUP

18. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 18

19. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 19

20. 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 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 & OntologiesPS 20

21. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 21

22. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 22

23. 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 & OntologiesPS 23

24. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 24

25. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 25

26. 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 2015SC 13 / SC 14 RASDS & OntologiesPS 26

27. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 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.

28. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 28 RASDS Top 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 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

29. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 29 Definitions of DoDAF Views

30. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 30 Correspondence Between RASDS and DoDAF Elements DoDAF ElementsRASDS Elements Operational 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

31. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 31 Correspondence Between RASDS and DoDAF Views (1/2) DODAF View and ProductRASDS 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)None Source: Takahiro Yamada, SAWG Chair

32. 2 Mar 2015SC 13 / SC 14 RASDS & OntologiesPS 32 Correspondence Between RASDS and DoDAF Views (2/2) DODAF View and ProductRASDS View Systems 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