Importance of Ontology in System Development for DoT

Ontology plays a crucial role in the development of systems for DoT by facilitating the automation of tasks, improving consistency, and enhancing the efficiency of tool chains. It enables the transformation of semantic descriptions into algorithms, streamlining processes and reducing the need for manual intervention. The integration of an ontology-based dictionary of terms further enhances the management and sharing of information across different stages of development.

• Ontology
• System Development
• DoT
• Automation
• Tool Chains

mada149 Follow

Uploaded on Sep 18, 2024 | 0 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. Why have an Ontology for DoT? The difficult questions

2. The Short Answer For generating drivers with purely syntactic interfaces, we don t need it. For the other tool chain use cases, we do need it.

3. Isnt a Tool Chain Out of Scope for SOIS? SOIS defines onboard interface services, which includes description of device interfaces. Those services are difficult to use if they are purely syntactic. People have to get involved, in order to make sure the units are correct, or to transform coordinates. In traditional development of software, people read and interpret the semantic descriptions of interfaces, and then write software that is consistent with the semantics of interfaces. In the tool chain with ontology, many routine human semantic tasks are passed to algorithms by applying semantic tags to variables. Semantic properties of device data interfaces flow through generated drivers to decorate the SOIS defined interfaces, DAS and DVS. This is in scope for SOIS. Without Ontology syntax Block Compiler semantics Notes Person With Ontology syntax Tool Chain Block semantics

4. What else is in the Tool Chain? Information about components is easily available to designers. Design tasks, such as searching for candidate components, can be automated. (SEA) Integration task descriptions and criteria can be generated. Operational task descriptions, such as subscription and session establishment can be generated. (SOIS) Mission control software can be generated. (MOIMS) Documents passed between teams can be checked for consistency where they overlap. The descriptions of components remain useful across manufacturers projects tool chains generations of engineers.

5. Why not a glossary instead of an ontology? Consider model-based systems engineering. Model A detailed model is the source of design artifacts, Functional View Communications View Exported xmi instead of manually building a new picture for each design artifact. Join, merge, and share with other modelers.

6. Ontology-Based Dictionary of Terms A detailed ontology is the source of terminology documents. Ontology Instead of manually building a new file for each design artifact. OWL/RDF export for SANA DoT HTML Glossary Schema Attribute Groups Join, merge, and share with other ontologies. The SOIS ontology includes the QUDV ontology in order to define quantity kinds and units of measure. Manage a language for descriptions in an ontology. Distribute artifacts from model to tool chain functions. The SOIS ontology can contain models of operation of standard devices, which can be used to identify the subjects of variables.

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