Table of Contents

Introduction

DEFII (Digital Engineering Framework for Integration and Interoperability) is a structured approach that enables different engineering tools and models to work together seamlessly using semantic technologies. It’s like a universal translator that helps various engineering systems understand each other’s data, making it easier to integrate complex digital models across different disciplines.

DEFII isn’t about changing your existing engineering tools—it’s about creating a common language that allows all your tools to communicate effectively. This makes it easier to analyze how changes in one part of a system affect the whole.

Overview

DEFII is a layered framework that enables semantic interoperability in digital engineering contexts. It provides a structured approach for integrating different engineering tools and models through the use of ontologies and semantic web technologies (SWT). The framework has three core layers that work together to enable seamless data exchange and reasoning across engineering domains.

DEFII is not a specific software tool, but rather a framework that can be implemented using various technologies. It’s implemented in practice through the Armaments Interoperability and Integration Framework (IoIF), which serves as a concrete example of DEFII in action.

DEFII’s three-layer architecture:

Layer

Description

Ontology-aligned data

Foundation layer where data is structured according to ontologies

Automated Reasoning

Layer that uses ontologies to infer new knowledge from existing data

Tool Proxy Interface Types

Layer that enables different tools to interact with the ontology-aligned data

Position in Knowledge Hierarchy

Broader concepts: - Part I (is-a)

Narrower concepts: - Model Interface (is-a)

Details

Ontology-Aligned Data Layer

The foundation of DEFII is data aligned to ontologies. This layer uses formal ontologies to structure engineering data in a way that is both machine-readable and semantically meaningful. The framework typically uses top-level ontologies like Basic Formal Ontology (BFO) as a foundation, and may incorporate mid-level ontologies like the Common Core Ontologies (CCO) as building blocks.

The ontology-aligned data layer provides the semantic foundation that enables interoperability across different engineering disciplines. Data is stored as linked data (RDF triples) in a triplestore repository, which allows for flexible querying and reasoning.

The key benefit of ontology-aligned data is that it provides a common language for different engineering domains. Instead of having separate data formats for mechanical, electrical, and software engineering, DEFII creates a unified semantic model that all disciplines can understand.

Automated Reasoning Layer

This layer leverages the ontology-aligned data to automatically infer new knowledge using axioms and rules defined within the ontologies. The reasoning capabilities can range from simple taxonomical reasoning (e.g., if something is a car, it’s also a vehicle) to more complex logical inferences.

The automated reasoning layer is configured to use specific reasoning profiles, which determine the level of reasoning performed. For example, using RDFS (RDF Schema) enables taxonomical reasoning, while more complex Description Logics (DL) can be used for advanced inference.

The reasoning profile must be carefully selected based on the specific needs of the engineering domain. Using overly complex reasoning can significantly slow down query performance, while using too simple reasoning may miss important inferences.

Tool Proxy Interface Types

DEFII specifies three categories of interfaces for interacting with the ontology-aligned data:

Interface Type

Description

Direct Interface

Direct invocation of semantic web technology stack (e.g., SPARQL queries)

Mapping Interface

Tool-dependent mapping that translates data from tool-specific formats to ontology-aligned data

Specified Model Interface

Tool-independent access to ontology-aligned data, exposing data through standard formats like CSV or JSON

These interface types provide flexibility for different integration scenarios, allowing DEFII to work with both modern tools with API access and legacy systems that only support file-based data exchange.

The Specified Model Interface is particularly important as it allows external tools to access ontology-aligned data without needing to understand the underlying ontologies. This is achieved through Model Interface Specification Diagrams (MISD) that define the data interfaces in a way that’s understandable to tool developers.

Practical applications and examples

Catapult Use Case

The Catapult example demonstrates DEFII in action for a simple projectile-launching system. The workflow involves:

  1. Loading a SysML model with an Assessment Flow Diagram (AFD) that defines the analysis workflow

  2. Using the AFD to configure the DEFII framework

  3. Pulling data from various engineering tools (e.g., geometry model, ballistic simulation)

  4. Processing the data through the DEFII workflow

  5. Visualizing the results in dashboards

graph TD A[SysML Model with AFD] --> B[IoIF Core] B --> C[Triplestore Repository] C --> D[Geometry Model] C --> E[Ballistic Simulation] C --> F[Decision Dashboard] D -->|CSV Export| C E -->|REST API| C F -->|SPARQL Query| C

The Catapult example shows how DEFII enables "what-if" analysis by allowing different variants (e.g., "Analysis as Designed," "Analysis as Manufactured") to be evaluated within the same framework. Each variant is represented as an instance in the SysML model, and the workflow automatically evaluates each variant against the defined objectives.

Workflow Execution

DEFII workflows typically run in environments like Jupyter Notebooks or Python scripts. The workflow steps include:

  1. Initialization with REST GET from Teamwork Cloud (TWC) to load the SysML model

  2. Pulling data from engineering tools (e.g., Creo model as CSV)

  3. Running simulations (e.g., Python for operator aiming, MATLAB for ballistic simulation)

  4. Pushing results back to the triplestore using REST PUT

  5. Visualizing results in dashboards

The workflow is designed to be flexible, allowing different SMEs (Subject Matter Experts) to work on different parts of the analysis while maintaining a consistent data model. This is particularly valuable for complex systems where multiple disciplines need to collaborate.

References

Knowledge Graph

Visualize DEFII’s relationship to other concepts in the digital engineering ecosystem

graph TD A[DEFII] --> B[Ontology-Aligned Data] A --> C[Automated Reasoning] A --> D[Tool Proxy Interfaces] B --> E[BFO] B --> F[CCO] C --> G[SPARQL] C --> H[Reasoners] D --> I[Direct Interface] D --> J[Mapping Interface] D --> K[Specified Model Interface] A --> L[Digital Engineering] L --> M[MBSE] L --> N[Digital Thread] L --> O[Model-Based Engineering] M --> P[SysML] P --> Q[Internal Block Diagram] P --> R[Parametric Diagram] N --> S[IoIF] S --> T[Catapult Use Case]

Associated Diagrams

figure_157.png
figure_115.png
figure_34.png
figure_59.png