SOIS Dictionary of Terms

1. SOIS Dictionary of Terms Usage in Tool Chain

2. Summary of DoT in SOIS Tool Chain The details hidden by the compression of this diagram will appear in subsequent diagrams. The main features to see in this diagram are the following. This diagram identifies the roles of the human participants. mission design team mission control team manufacturer ontology team The processes appear as beige blocks; the data artifacts appear as green blocks. Mission Control Team DoT Manufacturer Ontology Team Mission Design Team

3. Functional Roles of Ontology in SOIS Tool Chain

4. Extracting a Human-Readable Dictionary of Terms The DoT extractor reads the SOIS ontology. The DoT extractor reassembles the information in the ontology as HTML, which can be presented to be read by people. This function has been implemented as a prototype.

5. Sample OWL Class Definition <owl:NamedIndividualrdf:about="http://www.ccsds.org/.../sois.0.owl#device"> <rdf:typerdf:resource="http://www.ccsds.org/.../sois.0.owl#ReferenceFrame"/> <dc:description>…simplified…</dc:description> </owl:NamedIndividual> <tr> <td>device</td> <td>ReferenceFrame</td> <td>…simplified…</td> </tr> This example is an extract from an OWL ontology which identifies frames of reference. At the top is a fragment of an OWL ontology. The fragment describes an item named “device” in an enumeration of reference frames. At the bottom is a fragment of html generated from the OWL fragment above. This process is accomplished using an xsl transformation.

6. Procedures for Ontology Team Ratification relies upon usage to prove the expressiveness and understandability of terminology. The ontology team must listen, understand, and reconcile a variety of vocabularies and views of the subject matter, rather than to dictate a particular view of the subject matter. The manufacturer may report problems in expressions to the ontology team. The mission controllers may report ambiguities and errors to the ontology team. The designers report issues of expression and ambiguity to the ontology team. Terms that represent synonyms or alternative factorizations may be necessary. e.g., “gyrometer” and “IRU” e.g., layered single-processor architecture and distributed message-bus architecture e.g., procedural specification and specification of mission objectives

7. Building Schema for Electronic Data Sheets from Ontology The SOIS ontology provides enumeration and range information for validating discrete-valued attributes. The SOIS ontology can provide alternative formulations of schema for various applications. The EDS XSD Builder extracts information from the ontology and either generates a complete schema or fills in enumeration and range limits in a predefined schema.

8. File Structure of SOIS Electronic Data Sheet Schema The EDS XSD Builder generates a schema file that consists of type definitions, including enumerations, called a “Type Schema” here. The SOIS EDS structure schema is written by people (us) and contains a statement to include the type schema. The SOIS EDS structure schema defines the syntactic structure of electronic data sheets. The SOIS EDS structure schema contains references to the objects defined in the type schema. When a type is extended or added, the structure schema doesn’t change; only the type schema changes. This is a preliminary design, subject to change as requirements for structural schema develop.

9. Example ofGeneration of Types <owl:Classrdf:about="http://www.ccsds.org/.../sois.0.owl#ReferenceFrame"> <owl:equivalentClass> <owl:Class> <owl:oneOfrdf:parseType="Collection"> <rdf:Descriptionrdf:about="http://www.ccsds.org/.../sois.0.owl#device"/> <rdf:Descriptionrdf:about="http://www.ccsds.org/.../sois.0.owl#ECI"/> … </owl:oneOf> </owl:Class> </owl:equivalentClass> <rdfs:subClassOfrdf:resource="&owl;Thing"/> <dc:description>…simplified…</dc:description> </owl:Class> <xs:simpleType name=“referenceFrame"> <xs:annotation> <xs:documentation>…simplified…</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:enumeration value=“device"/> <xs:enumeration value=“ECI"/> … </xs:restriction> </xs:simpleType> This example is an extract from an OWL ontology which identifies frames of reference. At the top is a fragment of an OWL ontology. The fragment shows a few individuals in an enumeration of reference frames. At the bottom is a fragment of schema generated from the OWL fragment above. This process can be accomplished using an xsl transformation.

10. Authoring Electronic Data Sheets The manufacturer of a component writes a description of the component using a graphical user interface. The graphical user interface generates an electronic data sheet. The SOIS EDS schema guides the graphical user interface in generating the electronic data sheet. Optionally, the graphical user interface may publish finished electronic data sheets to a catalog of components. On request, the ontology team reviews electronic data sheets to detect errors of omission or misunderstanding. The ontology team may consult with manufacturers to improve electronic data sheets.

11. Catalog of Components The authoring tool for electronic data sheets can publish finished EDS’s to a catalog of components. The catalog of components contains electronic data sheets and various indexes to those EDS’s. The indexes enable a mission design team to find and to compare components suitable for a mission easily. The indexes are based on semantic content of interfaces and engineering properties of components, which are defined in SOIS ontology. For example, a designer can search for components that provide a star tracker interface and fit inside specific size and mass constraints.

12. Analysis of Interfaces The interface adapter analysis tool aids mission designers in validating a design, using the set of electronic data sheets aggregated by the mission configuration and their relationships in the configuration. The SOIS ontology provides relations among interface variables, which can be assembled into a matrix that describes a relation between components. The cells in the interface relation identify adaptations that are needed and/or available. The interface adapter analysis produces a list of adaptations that are absent the mission configuration. The mission design team treats the report of the interface adapter analysis as a list of unfinished work.

13. Example of Analysis of Interfaces ReactionWheel provides torque command interface, according to its EDS. ADCS consumes at least 3 instances of torque command interface, according to its EDS. In an instance of a mission configuration, an instance of an ADCS should be associated with at least three instances of a reaction wheel through the interfaces provided and consumed. If there are insufficient consumer-provider relations satisfied, the analysis of interfaces reports an error. (A separate constraint will likely require that the axes of torque span space.)

14. Computer Aided Packaging of Flight Software The SOIS control block extractor assists in construction of flight software. Using the electronic data sheets aggregated by the mission configuration, and relations among components in the configuration, the SOIS control block extractor builds a model of control blocks for SOIS. The SOIS control block extractor generates flight software code and configuration files that embodies the control blocks and a manifest of components for the mission. The flight software for the mission, which includes SOIS, uses the control blocks during flight and during simulated flight. The semantic tags on data that flow through interfaces defined in an EDS enable the SOIS control block extractor to map device data into flight software configuration blocks.

15. Configuration of Models for Simulation of Mission The simulation extractor uses the electronic datasheets aggregated by a mission configuration to identify simulation models for the components. The simulation extractor assembles the models and builds configuration data for a flight simulator. The models may be embedded in EDS or referenced in a library. More than one model may represent the same device in different simulation environments. The semantic tags on data that flow through interfaces enable the simulation extractor to apply parameters of a component to its simulation model.

16. Configuration of Mission Control Graphical User Interface The mission control extractor assists configuring the graphical user interface for controlling a mission. Using the electronic data sheets aggregated by a mission configuration, the mission control extractor builds a model of the data that will be visible to controllers in a set of screens. The mission control team guides the mission control extractor in selecting the data to be displayed in each screen. The mission control extractor produces xaml files, or the equivalent, and the software behind the display, which constitutes the definition of the mission control graphical user interface.

17. Simulation of Mission The mission simulation process measures the performance of a mission design. The simulation models obtained from electronic data sheets provide the detailed simulations. The flight software receives sensor signals from the simulation, and sends messages to actuators in the simulation. The mission control team monitors and commands the simulated mission. The mission control graphical user interface sends telecommands to the simulation and receives telemetry from the simulation.

18. Summaries of Human Roles

19. Mission Design Activities The following list identifies the flow of information starting at the bottom left and proceeding clockwise. The designers search a database of electronic data sheets easily to find components that are relevant to the mission. The designers may ask manufacturers for components with specific features and capabilities. The designers read electronic data sheets to incorporate components into the mission configuration. The designers consult the DoT. The designers report issues of expression and ambiguity to the ontology team. The mission design team produces a design for the mission. A tool chain process reads the mission configuration and reports to the mission designers unfinished work in the form of poor adaptation between components. A tool chain process reads the mission configuration and simulates parts of the mission, reporting performance issues to the designers. The mission control team, who participate in the simulation, report issues that they encounter.

20. Manufacturing Activities The following list identifies the flow of information starting at the bottom left and proceeding clockwise. The manufacturer uses a graphical user interface to define the features of the components that they manufacture. This action produces an electronic data sheet. The manufacturer may refer to the dictionary of terms. The manufacturer may report problems in expressions to the ontology team. The designers may ask manufacturers for components with specific features and capabilities.

21. Mission Control Activities The following list identifies the flow of information starting at the bottom left and proceeding clockwise. The mission controllers monitor and command missions, both simulated and real. The mission controllers may refer to the dictionary of terms to explain some items in their GUI. The mission controllers may report ambiguities and errors to the ontology team. The mission controllers may report design issues to the design team.

22. Ontology Maintenance Activities The following list identifies the flow of information starting at the bottom left and proceeding clockwise. The ontology team maintains the SOIS ontology in response to suggestions from people trying to use electronic data sheets. The designers report issues of expression and ambiguity to the ontology team. The manufacturer may report problems in expressions to the ontology team. The mission controllers may report ambiguities and errors to the ontology team.