[Paper] Model management to support systems engineering workflows using ontology-based knowledge graphs

Source: arXiv - 2512.09596v1

Overview

The paper presents a framework that uses ontology‑driven knowledge graphs to manage the myriad models and artifacts produced during systems‑engineering workflows—especially for complex cyber‑physical systems (CPS). By formalising workflow concepts in an ontology (OML) and wrapping them in a set of developer‑friendly tools, the authors show how engineers can store, version, query, and reason over their digital assets more efficiently.

Key Contributions

• Ontology for workflow artefacts – a rigorously defined OML schema that captures workflows, their formalism‑specific models, and associated metadata.
• Knowledge‑graph backbone – the ontology is instantiated as a graph database, enabling semantic queries and automated reasoning over engineering data.
• Toolchain for engineers – a suite of utilities (designer, executor, version‑manager, query UI) that hide graph‑DB complexities while supporting model creation, execution, and provenance capture.
• Real‑world validation – deployment on a drivetrain smart‑sensor development project, demonstrating measurable gains in storage handling, version control, and information retrieval.
• Demonstrated inference capabilities – the graph can derive new knowledge (e.g., dependency gaps, compatibility issues) that would be hard to spot manually.

Methodology

1. Formalise the domain – The authors model core workflow concepts (tasks, inputs/outputs, versions, tools) and the various modelling formalisms (SysML, MATLAB/Simulink, etc.) in an Ontology Modelling Language (OML) file.
2. Instantiate a knowledge graph – Using a triple‑store (e.g., Neo4j or Blazegraph), each workflow execution creates a set of RDF triples that populate the graph according to the OML schema.
3. Build supporting tools
   • Designer UI: lets engineers compose workflows visually; the UI translates the design into ontology instances.
   • Enactor: runs the workflow, automatically capturing artefacts (model files, simulation results) and their provenance.
   • Version manager: records each artefact’s lineage, enabling “time‑travel” queries.
   • Query & reasoning layer: SPARQL endpoints and OWL reasoners expose high‑level queries (e.g., “find all models that depend on component X”) and infer implicit relationships.
4. Case‑study execution – The framework is applied to a smart‑sensor system for a drivetrain, where multiple domain experts collaborate across different modelling tools.

The approach is deliberately tool‑centric: engineers interact with familiar GUIs, while the underlying graph and ontology handle the heavy lifting of data integration and reasoning.

Results & Findings

The authors also report that engineers felt less cognitive load when tracking artefacts, and the system’s reasoning engine could suggest missing validation steps based on model relationships.

Practical Implications

• Streamlined model‑centric development – Teams can treat every simulation, diagram, or code snippet as a first‑class citizen in a searchable graph, reducing “where‑is‑that‑model?” friction.
• Robust versioning & reproducibility – Automatic provenance means a workflow can be replayed exactly, a boon for regulatory compliance (e.g., automotive ISO‑26262) and for CI/CD pipelines in CPS development.
• Cross‑tool integration – By abstracting over specific modelling formalisms, the framework lets developers mix SysML, Simulink, Modelica, etc., without building custom adapters.
• Automated compliance checks – OWL reasoning can enforce domain rules (e.g., “all safety‑critical components must have a hazard analysis attached”), turning the knowledge graph into a lightweight rule engine.
• Foundation for AI‑assisted engineering – The semantic layer makes it straightforward to plug in machine‑learning models that predict design risks or suggest component reuse, opening a path toward smarter PLM systems.

For developers building PLM, MBSE, or digital‑twin platforms, the paper offers a blueprint for embedding ontology‑based knowledge graphs without forcing engineers to learn RDF or SPARQL directly.

Limitations & Future Work

• Scalability concerns – The case study involved a few dozen artefacts; the authors acknowledge that very large‑scale projects (thousands of models) may stress the triple‑store performance and require sharding or more aggressive indexing.
• Tooling maturity – The prototype UI and enactor are functional but lack the polish of commercial MBSE suites; integration with existing tools (e.g., Enterprise Architect, Polarion) remains manual.
• Ontology evolution – Extending the OML schema for new formalisms or domain‑specific concepts can be non‑trivial and may need governance processes.
• Future directions include benchmarking against industrial PLM systems, adding support for real‑time streaming data (e.g., sensor telemetry), and exploring hybrid reasoning that combines OWL with probabilistic models for uncertainty handling.

Authors

• Arkadiusz Ryś
• Lucas Lima
• Joeri Exelmans
• Dennis Janssens
• Hans Vangheluwe

Paper Information

• arXiv ID: 2512.09596v1
• Categories: cs.SE
• Published: December 10, 2025
• PDF: Download PDF