Industrial Instance Modeling With Graph-Based Key Linking

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing technologies face challenges in efficiently linking and assigning data objects between domain and instance models due to differences in abstraction levels, leading to difficulties in identifying corresponding entities and establishing relationships, particularly in operational technology (OT) and information technology (IT) domains, which complicates data persistence and querying.

Innovation Solution

An automated method and arrangement using a graph database to automatically create industrial instance models by checking for foreign and primary keys, establishing direct connections between entities based on domain models, and iteratively storing new instance data as nodes and edges, enabling domain experts to define relationships without manual text matching.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If data objects are linked using manual text matching and abstract relationships in domain models, then flexibility in defining relationships is maintained, but the precision and reliability of entity identification deteriorates

Engineering Contradiction:
Improveflexibility in defining relationshipsVSAvoidprecision of entity identification
Core Design Contradiction:
Adaptability or versatilityVSMeasurement precision

Solution Approach 1:

The patent segments the identifier matching process into distinct components: primary key identification, foreign key identification, and automated matching. This segmentation allows systematic processing of relationships while maintaining precision through structured data objects that explicitly mark primary and foreign keys, eliminating reliance on imprecise text matching.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary mechanism in the form of structured data objects with explicit primary and foreign key markings. This intermediary layer sits between the domain model and instance data, enabling automated precise matching without requiring manual text matching, thus resolving the contradiction between flexibility and precision.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Stability of the object's composition

If rigid structured tag or asset models are used to manage domain and instance models, then data consistency is maintained, but the ease of viewing individual entities in a use-case-dependent manner deteriorates

Engineering Contradiction:
Improvedata consistencyVSAvoidease of viewing individual entities
Core Design Contradiction:
Stability of the object's compositionVSEase of operation

Solution Approach 1:

The patent applies dynamics by enabling flexible querying and viewing of individual entities based on use-case requirements while maintaining underlying data consistency through structured data objects. The system allows dynamic access to entities through the graph database structure, where relationships can be traversed and entities viewed according to specific use cases without compromising the consistent structured representation stored in the database.

Inventive Principle:
Principle #15Dynamics

3Adaptability or versatility

If identifiers are described in a customer-specific manner without systematic description, then adaptability to different customer requirements is improved, but the difficulty of automated relationship resolution increases

Engineering Contradiction:
Improveadaptability to customer requirementsVSAvoiddifficulty of automated relationship resolution
Core Design Contradiction:
Adaptability or versatilityVSDifficulty of detecting and measuring

Solution Approach 1:

The patent changes the parameters of identifier description by introducing a systematic approach that combines customer-specific identifier formats with explicit structural markings. Data objects include marked primary and foreign keys, allowing automated relationship resolution while accommodating different customer identifier conventions. This parameter change enables both adaptability to customer requirements and automated processing.

Inventive Principle:
Principle #35Parameter changes

4Quantity of substance

If data is persisted in increasingly large tables or simple lists, then the capacity to store runtime instances is improved, but the productivity of making data available meaningfully for other use cases deteriorates

Engineering Contradiction:
Improvecapacity to store instancesVSAvoidproductivity of data availability
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The patent transitions from traditional tabular or list-based data persistence to a graph database structure, adding a dimensional aspect of explicit relationships between entities. This dimensional change allows the system to store large quantities of instances while simultaneously enabling efficient meaningful access for various use cases through the structured relationship model, thus improving productivity of data availability.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

Data Source

PatentEP4621679A1Method and arrangement for the automated creation of an industrial instance model
Publication Date: 2025.09.24 SIEMENS AG
  • EP4621679A1 patent drawingFigure 1~2
  • EP4621679A1 patent drawingFigure 3
  • EP4621679A1 patent drawing

AI summary

To automatically create an instance model of an industrial plant, new instance data is received that describes an instance of an entity and is present in a data structure specified by a domain model. The new instance data is stored in a graph database. An automated check is performed to determine whether the new instance data contains a search request for a foreign key, after which the graph database is automatically searched for instance data that offers the requested foreign key as the primary key, or whether the new instance data contains a primary key offer, after which the graph database is automatically searched for instance data that searches for the offered primary key as the foreign key. For all pairs found in this way, an edge is inserted between the respective instance data in the instance model.These receiving and storing operations are repeated iteratively until the instance model is fully created. Preferred developments address the resolution of relationships between objects at the instance level using an abstract relationship that is stored in the domain model or can be derived from it. At least some embodiments enable domain-driven linking of data objects, which allows domain experts to define specific data products, assign customer-specific and general identity attributes, and pass them on to the corresponding technical infrastructure without requiring in-depth technical knowledge.