Ontology Middleware for Heterogeneous Automation Data Integration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Integration of heterogeneous data sources in automation systems is challenging due to proprietary data models, formats, and structures, which hinder a unified understanding and communication across different devices and systems from various application areas, requiring complex data adapters and specific engineering tools.

Innovation Solution

A method utilizing an ontology engine or service to transform source data into a common data model, stored in a data abstraction layer, providing a uniform interface for client tools to access data from diverse devices and systems, regardless of their original data models or formats, through an integration middleware that includes an instance manager and ontology engine.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If proprietary data models and formats are used for each device, then device-specific data representation accuracy is improved, but system-wide data integration complexity increases

Engineering Contradiction:
Improvedata representation accuracyVSAvoidsystem integration complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent introduces an integration middleware that acts as an intermediary between heterogeneous data sources and client tools. This middleware contains an ontology engine that transforms device-specific data models into a common data model, enabling seamless integration without losing device-specific data accuracy. The middleware layer mediates the conversion process, allowing each device to maintain its proprietary format while the system achieves unified access.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system architecture is segmented into distinct layers: data source layer, integration middleware layer (with ontology engine), and client tool layer. This segmentation allows each layer to operate independently with its own data models while the middleware handles the transformation logic. The segmentation isolates the complexity of data model conversion within the middleware, preventing it from propagating to other system components.

Inventive Principle:
Principle #1Segmentation

2Manufacturing precision

If multiple device-specific engineering tools are used, then device configuration precision is improved, but operational ease deteriorates

Engineering Contradiction:
Improvedevice configuration precisionVSAvoidoperational ease
Core Design Contradiction:
Manufacturing precisionVSEase of operation

Solution Approach 1:

The integration middleware provides universal access to multiple device types through a single common interface. Client tools can access and configure various devices using one unified tool rather than multiple device-specific tools. The ontology engine enables this universality by translating between different device data models and the common data model, allowing a single tool to handle diverse device configurations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Adaptability or versatility

If data adapters are used for each device, then data compatibility is improved, but device complexity increases

Engineering Contradiction:
Improvedata compatibilityVSAvoidnumber of data adapters
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent merges multiple individual data adapter functions into a single integration middleware component. Instead of having separate adapters for each device type, the ontology engine within the middleware consolidates the adaptation logic into one unified system. This single middleware instance handles transformations for multiple devices simultaneously, reducing the overall number of adapters needed in the system.

Inventive Principle:
Principle #5Merging (Combining)

4Reliability

If proprietary protocols are used for communication, then communication reliability is improved, but system adaptability deteriorates

Engineering Contradiction:
Improvecommunication reliabilityVSAvoidsystem adaptability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The integration middleware serves as a protocol mediator that translates between proprietary communication protocols used by different devices and a common internal data model. Each device can communicate using its reliable proprietary protocol while the middleware handles the protocol conversion, maintaining both communication reliability and system adaptability. The ontology engine enables this by understanding both device-specific protocols and the common data model.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP3617823B1Method for integrating data sources and integration middleware
Publication Date: 2021.11.24 SCHNEIDER ELECTRIC IND SAS
  • EP3617823B1 patent drawingFigure 1
  • EP3617823B1 patent drawingFigure 2

AI summary

The invention relates to a method and an integration middleware for integrating heterogeneous data sources (DS1...DSn) such as field devices, groups of devices, complete plants, and/or subsystems of automation technology into an automation system (AS), wherein the heterogeneous data sources (DS1...DSn) each comprise source data (SD1...SDn) of different data models, data formats, structures, semantics, and/or syntax. To enable the integration of heterogeneous data sources, and in particular to make the proprietary data models, data formats, and structures of the heterogeneous data sources unambiguously interpretable and to enable a uniform understanding of the data, it is provided that the source data (SD1...SDn) of the heterogeneous data sources to be integrated (DS1...DSn) are transformed into semantically and syntactically corresponding target data (TD1...TDn) of a common data model (CIM) by means of an ontology engine (OE) or an ontology service (OS) through the application of mapping rules and/or data relationship rules, and that the target data (TD1...TDn) of each data source (DS1...DSn) are stored in a digital representative (DSDR1...DSDn) in a data source-independent layer (DAL) and made available to at least one client tool (CT1...CTk) via a communication-independent interface (CTI1...CTIk).