Network-Centric Process Control With Middleware Data Decoupling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current process control systems rely on controller-centric architectures, which require extensive engineering efforts and incur performance penalties due to dependencies on hardware topology and specific implementations, making it costly and inefficient to access and manage IO and device data across different controllers.
Innovation Solution
A network-centric process control system is introduced, where each node runs separate control services in a real-time operating system, using a middleware service for publishing and subscribing process data, allowing for flexible deployment of control logic and decoupling IO and device handling from control logic execution, with signals defined in a standardized format independent of device and fieldbus protocols.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If controller-centric architecture is used with controllers executing control logic applications using IO interfaces and devices, then control logic can be implemented with direct hardware access, but engineering efforts increase and system performance deteriorates due to dependencies on hardware topology and controller-to-controller communication requirements
Solution Approach 1:
The system segments the control architecture into independent nodes that can be configured and managed separately. Each node operates autonomously with its own control logic, eliminating the need for complex controller-to-controller communication and reducing engineering efforts for system integration and configuration.
Solution Approach 2:
The patent introduces an intermediary communication mechanism that enables direct node-to-node data exchange without requiring controller mediation. This intermediary layer abstracts the hardware topology dependencies and provides a standardized interface for process data access, reducing both engineering complexity and performance overhead.
2Adaptability or versatility
If controller-to-controller communication is configured to access IO and devices connected to different controllers, then system-wide access is enabled, but performance penalty occurs due to processing capacity requirements and engineering effort
Solution Approach 1:
The system divides the control network into independent nodes that can access their own IO and devices directly. This segmentation eliminates the need for controller-to-controller communication for accessing remote IO, thereby maintaining high system performance while enabling system-wide access through the distributed node architecture.
Solution Approach 2:
The patent transitions from a hierarchical controller-centric access model to a peer-to-peer node-based access model. This dimensional change in the communication architecture allows nodes to access process data directly from the process network without routing through controllers, improving productivity while maintaining adaptability.
3Adaptability or versatility
If IO engineering changes are made in controller-centric architecture, then IO configuration can be updated, but control logic engineering is impacted and vice versa, increasing engineering complexity
Solution Approach 1:
The patent extracts the IO configuration management from the controller logic execution path. By separating IO engineering from control logic engineering through independent node architecture, changes in IO configuration no longer impact control logic engineering and vice versa, reducing engineering complexity while maintaining flexibility.
Solution Approach 2:
An intermediary configuration layer is introduced that decouples IO engineering from control logic engineering. This intermediary layer handles IO configuration changes independently, preventing ripple effects on control logic and reducing the complexity of engineering modifications while maintaining system adaptability.
4Reliability
If controllers scan IO channels and execute control logic using dedicated processing capacity, then real-time control is achieved, but system performance deteriorates due to processing capacity constraints
Solution Approach 1:
The system segments processing responsibilities across multiple independent nodes, allowing each node to handle its own IO scanning and control logic execution. This distribution of processing capacity eliminates the bottleneck of centralized controller processing, maintaining real-time control reliability while improving overall system productivity and resource utilization.
Data Source
AI summary
A method for process control in a network centric process control system. The network centric process control system includes a plurality of nodes, wherein each node includes one or more control services being a separate executable running in a separate operating system process provided by a real time operating system thereof, wherein configuration data defining a communication interface for process data between the plurality of nodes has been received from an engineering node. The method includes publishing, by one or more of the plurality of controller nodes and plurality of device nodes, process data information in a middleware service, the process data information having an identity unique in the network centric process control system, a data type for process data, and process data, wherein the middleware service being a separate executable running in a separate operating system process provided by a real time operating system thereof, and subscribing, by the one or more of the plurality of nodes, to process data information published in the middleware service. A network centric process control system, a computer program, and a computer program product thereof are also presented.