Middleware Publish-Subscribe for Network-Centric Process Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Controller-centric process control systems require extensive engineering efforts and incur performance penalties due to dependencies on hardware topology and specific IO and device 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 with a middleware service that enables nodes to publish and subscribe to process data independently, using unique identities and data types, allowing control logic to be engineered without knowledge of execution locations or IO connections, and handles signal quality issues through overriding or substituting values.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a controller centric architecture is used where controllers execute control logic applications using IO interfaces and devices, then control logic can be executed with direct access to hardware, but engineering efforts increase and system performance decreases due to dependencies on hardware topology and IO device specific implementations
Solution Approach 1:
The patent introduces an IO server as an intermediary component that runs in a separate process from the controller. The IO server handles all interactions with IO devices and fieldbuses, while controllers communicate with it through a standardized interface. This mediator layer decouples controllers from hardware-specific implementations, reducing engineering complexity while maintaining reliable control execution.
Solution Approach 2:
The system is segmented into distinct functional components: controllers for control logic execution, an IO server for hardware communication, and a process data server for data management. Each component runs in separate processes and communicates through well-defined interfaces. This segmentation allows independent development and deployment of control logic without hardware dependencies.
2Adaptability or versatility
If controllers directly access IO and device data through controller-to-controller communication, then data can be shared between controllers, but extra engineering effort and performance penalty in processing capacity are incurred
Solution Approach 1:
The IO server provides universal access to IO and device data for all controllers through a common interface. Instead of implementing separate communication channels between each pair of controllers, any controller can access any IO device through the IO server using standardized service calls. This multi-functional approach enables data sharing without the overhead of multiple dedicated communication paths.
3Manufacturing precision
If control logic engineering requires knowledge of where IOs and devices are connected and where control logic is executing, then control logic can be precisely implemented, but changes in IO engineering impact control logic engineering and vice versa
Solution Approach 1:
The IO server acts as an intermediary that abstracts the physical connection topology from control logic. Controllers interact with IO devices through the IO server's standardized interface, which handles all details about device locations, connections, and hardware-specific protocols. This allows control logic to be engineered with precision while remaining independent of physical IO engineering changes.
4Ease of operation
If controllers depend on knowledge about hardware topology and IO device specific implementations, then direct hardware control is achieved, but access to IO and device data becomes costly and inefficient
Solution Approach 1:
The IO server implements self-service mechanisms by automatically managing device configurations, handling protocol-specific details, and caching device data. When controllers request IO data, the IO server efficiently retrieves or generates the data without requiring controllers to understand hardware topology or device implementations. This self-service approach maintains ease of hardware control while dramatically improving data access efficiency.
Data Source
Figure 1~2
Figure 3
Figure 4
AI summary
Embodiments presented herein relate to a method for process control in a network centric process control system. The network centric process control system (100) comprises a plurality of nodes (300), wherein each node comprises one or more control services (310) 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 comprises publishing (S100), by one or more of the plurality of controller nodes and plurality of device nodes, process data information in a middleware service (320), the process data information comprising 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 (S110), 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.