Engineers use a variety of software tools to support system design and development. These tools help engineers encode and reason about complex requirements and designs, but they also create data silos of information related to the components and systems they are designing. We describe a self-defining ontology approach that automatically extracts an ontological representation of system design information from tool-specific design data to integrate information across tools and to validate system designs for faster error-free design and development of new systems.
Using a Web Ontology Language (OWL) ontology to capture information generated during the design
life cycle of parts and systems enables the alignment of concepts between digital engineering tools
based on meaning. An of-the-shelf reasoner, such as Pellet [
Encoding information using an ontology provides both the means to perform data integration and
the ability to use the semantic representation to reason about the information that has been encoded.
Unfortunately, a major challenge of most knowledge representation eforts involves identifying an
existing ontology or creating a new ontology that suitably captures the semantics of the domain.
Highlevel ontologies like the Basic Formal Ontology (BFO) [
Alternatively, low-level domain ontologies encode equivalent information directly as properties on the classes they are describing. This enables an automated reasoner, such as Pellet, to detect and enforce any logical inconsistencies even if they are inferred. The challenge with creating domain-level ontologies is that it is often dificult for knowledge engineers to identify upfront which domain concepts should be defined, at which level, and with what relationships. Creating a new ontology takes a significant amount of efort and the ontology must be continually updated to ensure it can encode all concepts in the domain.
We devised a novel technique for “self-defining” ontologies that uses the system design data that is being encoded to automatically drive the creation of a domain ontology that encodes the right concepts,
CEUR
ceur-ws.org at the right level, and with the right relationships to reason about the system design and to detect inconsistencies between requirements and design.
An ontology’s TBox defines the classes, properties, relationships, and constraints of the domain. A key insight is that the system requirements defined by engineers in tools like IBM’s Dynamic Object Oriented Requirements System (DOORS) provide the TBox information for the domain. The requirements define parts and systems, show how they relate, and provide constraints on properties. This naturally fits OWL’s definition of classes, properties, and property constraints (via class expressions or Shapes Constraint Language (SHACL) constraints).
Consider the following example requirement: “The backup battery shall have a runtime of greater than 60 minutes.” This information can be encoded as a class expression by defining a BackupBattery class with a runtime property that is restricted to values greater than 60 minutes. An OWL reasoner is then able to enforce this constraint and identify even indirect inconsistences where designs of diferent types of backup batteries do not meet this constraint. Figure 1 shows an example of how this information is encoded as an OWL class expression.
While the TBox provides the ontology’s “schema,” the ontology’s ABox contains the instance data that is represented using that schema. This instance data naturally maps to designs of parts/systems meant to meet the requirements. For example, the design of a “Backup Battery,” which has a default runtime associated with it, is meant to satisfy the runtime originally defined in the Backup Battery requirements in DOORS (and encoded in the TBox).
Systems engineers use tools like Dassault Systemes’ Cameo Systems Modeler (CSM) during system design. CSM uses the Systems Modeling Language (SysML) to serialize design data. Figure 2 shows an example translation of Cameo SysML data into an OWL Named Individual.
Using domain ontologies ofers several advantages over higher-level ontologies including the ability to automatically reason about consistency and perform integration of requirements and design. Our strategy for self-defining ontologies enables domain-level ontologies to automatically be created from the data they describe and enables integrated digital engineering tools to share information and enforce consistency across tools for faster error-free design and development of new systems. We have demonstrated this technique using proof-of-concept translation techniques for natural language requirements (e.g., systemic functional grammars for information extraction) and automated translation techniques based on the SysML standard.
Future work will explore the use of large language models (LLMs) for data translation using the same self-defining strategy for the target representation.
This material is based upon work supported by the Strategic Systems Programs (SSP) under Contract No. N64267-24-C-0011. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of SSP.