Web Application Component Aggregation in Industrial Automation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Industrial automation systems face challenges in providing reliable, real-time communication and flexible service provisioning across distributed control units, requiring efficient communication infrastructure that supports varying client-side requirements and allows for expandability without substantial changes to the data and functional model.

Innovation Solution

The method involves providing industrial automation functions through web applications combined on the client side, using a uniform application programming interface (API) that enables cross-component interactions and metadata-driven component management, allowing for flexible integration of loosely coupled services without individual programming efforts, and enabling direct or isolated integration of application components.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If distributed services are implemented across multiple control units, then system functionality and flexibility are improved, but communication infrastructure requirements and system complexity increase

Engineering Contradiction:
Improveservice provisioning flexibilityVSAvoidcommunication infrastructure complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments services into service-specific components and non-service-specific components. Non-service-specific components (such as communication handlers, security modules, and logging services) are separated from service-specific logic, allowing them to be shared across multiple services and control units. This segmentation reduces the overall system complexity by eliminating redundancy while maintaining the ability to provision diverse services flexibly.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements universal non-service-specific components that can be reused across multiple different services and control units. These components provide common functionality (communication protocols, authentication, data formatting) that is needed by all services, eliminating the need to replicate this functionality in each service implementation. This multi-functionality approach reduces communication infrastructure complexity while enabling flexible service expansion.

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

2Reliability

If real-time communication protocols are used, then communication reliability is improved, but protocol transparency and ease of integration deteriorate

Engineering Contradiction:
Improvereal-time communication reliabilityVSAvoidprotocol transparency
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent introduces non-service-specific communication components that act as intermediaries between the service-specific components and the underlying real-time communication protocols. These intermediary components handle protocol-specific complexities (timing, synchronization, error handling) while presenting a simplified, transparent interface to services. This allows services to benefit from reliable real-time communication without being burdened by protocol complexity, improving both reliability and ease of operation.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If services are expanded with additional components, then system functionality is improved, but changes to data and functional models are required

Engineering Contradiction:
Improveservice expandabilityVSAvoiddata and functional model complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments service components into service-specific parts (which define unique service functionality) and non-service-specific parts (which provide common infrastructure). When services are expanded with additional components, only the service-specific portions need to be modified, while the non-service-specific infrastructure remains unchanged. This segmentation allows service expansion without requiring changes to the underlying data and functional models, maintaining system stability while enabling functionality growth.

Inventive Principle:
Principle #1Segmentation

4Reliability

If client-side requirements for data filtering and pre-compression are implemented, then service quality is improved, but processing overhead and system resource consumption increase

Engineering Contradiction:
Improvequality of serviceVSAvoidclient-side processing overhead
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent implements self-service mechanisms where non-service-specific components automatically handle data filtering, pre-compression, and formatting based on predefined quality of service parameters. These components operate autonomously to optimize data before it reaches service-specific processing, improving service quality without requiring additional client-side processing overhead. The system self-regulates data quality requirements, reducing the burden on clients while maintaining high service standards.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP2902857B1Method for providing functions within an industrial automation system and industrial automation system
Publication Date: 2018.12.19 SIEMENS AG
  • EP2902857B1 patent drawingFigure 1
  • EP2902857B1 patent drawingFigure 2

AI summary

To provide functions within an industrial automation system, these functions are made available through web applications. These web applications are aggregated into interconnected web applications on the client side during control program execution and presented via a client-side user interface. The web applications are provided using a unified application programming interface (API), which includes a cross-component API for initializing and unloading application components, as well as a component-specific API for event handling and providing component functions. Component instances are linked via an API to define interactions between application components.