Automation Data Model Mapping for Interoperable Component Communication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Modern automation systems face challenges in enabling interoperable communication between components with different data models, leading to communication failures when new components or standards are introduced, due to the lack of flexibility in existing solutions.

Innovation Solution

A computer-implemented method and system that uses a transformation module to translate data models between server and client components, utilizing a technical specifications database and transformation rules to ensure interoperability, even when components adhere to different technical specifications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If proprietary solutions or protocol-specific profiles are created to enable communication between automation system components with different data models, then interoperability between existing components is achieved, but flexibility to accommodate new components and standards is lost

Engineering Contradiction:
ImproveinteroperabilityVSAvoidflexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces a mediation layer that sits between data providers and data consumers with different data models. This mediator translates and adapts data between incompatible models dynamically, allowing new components to be integrated without creating new proprietary profiles. The mediator uses schema validation and transformation rules to enable communication while maintaining flexibility for future components.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system employs dynamic schema validation and transformation rather than static proprietary profiles. When new components are added, the system can dynamically generate or update translation rules based on the new component's data model, allowing the interoperability mechanism to adapt to changing requirements without manual profile creation.

Inventive Principle:
Principle #15Dynamics

2Adaptability or versatility

If multiple communication protocols and data models are supported to accommodate diverse automation system components, then versatility is improved, but system complexity increases

Engineering Contradiction:
ImprovecompatibilityVSAvoidsystem complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the communication system into distinct functional layers: data providers, a mediation layer with schema validation and transformation capabilities, and data consumers. This segmentation allows each layer to be developed and maintained independently, reducing overall system complexity while supporting multiple protocols and data models through the standardized mediation interface.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The mediation layer serves multiple functions: schema validation, data transformation, error handling, and protocol adaptation. By consolidating these diverse functions into a single universal mediation mechanism, the system avoids the complexity of implementing separate handling logic for each protocol or data model combination.

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

3Ease of manufacture

If proprietary data models are used in automation system components, then component-specific requirements are met, but interoperability with components using different data models fails

Engineering Contradiction:
Improvecomponent design freedomVSAvoidcommunication success
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The mediation layer acts as an intermediary that accepts data from proprietary data models, validates it against schemas, and transforms it into a format compatible with the consuming component. This allows components to maintain their proprietary data models for ease of design while ensuring reliable communication through the translation capability of the mediator.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system changes the parameters of data representation through schema-based transformation. Different data models with different parameters are mapped to each other through defined transformation rules, allowing components to use their native parameter structures while achieving interoperability through parameter translation in the mediation layer.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP3726810B1System and method for interoperable communication of automation system components
Publication Date: 2023.12.06 ABB (SCHWEIZ) AG
  • EP3726810B1 patent drawingFigure 1A
  • EP3726810B1 patent drawingFigure 1B
  • EP3726810B1 patent drawingFigure 2~3

AI summary

A computer-implemented method, computer program product and computer system (100) for interoperable communication between a server (110) and a client (120). At least one of the server and client is a component of an automation system. The server (110) is associated with a corresponding server data model (111), and the client (120) is associated with a corresponding client data model (121). The system (200) can access a technical specifications database (300). A reference (150) to the server (110) is obtained to establish a communication with the server (110) via the obtained reference (150). A transformer module (230) of the system has an analyzer (233) to analyze structure and output of the server (110) to derive element types associated with elements of the server data model (111). A rule set database (232) has a plurality of transformation rule sets (TR1, TR2) associated with a technical specification database (300). A particular transformation rule set (TR1) has one or more transformation rules defining, for one or more element types derived from the server data model, how instances (111-a1, 111-b1) of said element types are to be transformed from the server data model (111) associated with at least a first technical specification (310) into instances (121-a1, 121-a2) of the client data model (121) associated with at least a second technical specification (320) of said technical specification database (300). A rule engine (234) applies the particular transformation rule set (TR1) to the server data model (111) to generate a mapping (231) between the server data model (111) and the client data model (121). The mapping is used to exchange data between the server (110) and the client (120).