Containerized Process Software Update With Real-Time State Transfer
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In process automation, updating control applications without interrupting production is challenging due to network latencies introduced by deploying software containers on different physical nodes, which can exceed cycle times and require state transfers that are not feasible within the available time frame.
Innovation Solution
A method for real-time updating of process software involves deploying two execution engines within a single container deployment unit, enabling inter-process communication to transfer the application state quickly, allowing for on-the-fly updates without network delays, using shared memory for fast data transfer and compression to minimize latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If software containers are deployed on different physical nodes for management benefits, then container orchestration and management are improved, but network latency increases making state transfer impossible within cycle times
Solution Approach 1:
The patent merges multiple execution engines into a single container deployment unit, allowing them to share the same memory space and communicate via inter-process communication (IPC) rather than network sockets. This combination eliminates network latency while maintaining container orchestration benefits, enabling state transfer within cycle times.
Solution Approach 2:
The patent introduces a shared memory space as an intermediary between execution engines within the same container deployment unit. This shared memory acts as a fast communication channel that mediates state transfer between engines without requiring network protocols, thus reducing latency below cycle time requirements.
2Reliability
If the application is stopped for updating to ensure consistency, then update reliability is improved, but production continuity is interrupted
Solution Approach 1:
The patent performs preliminary actions by initializing the new execution engine with the current application state before the old engine stops. The state is transferred and the new engine is prepared in advance, so when the switch occurs, the new engine is already ready to continue execution without interruption or inconsistency.
Solution Approach 2:
The patent maintains continuity of useful action by allowing the old execution engine to continue running and processing control cycles while the new engine is being initialized and loaded with the application state. The switch to the new engine occurs seamlessly without stopping the control application, ensuring continuous production operation.
3Adaptability or versatility
If network protocols are used for state transfer between containers, then communication flexibility is improved, but transfer speed decreases below required cycle times
Solution Approach 1:
The patent combines multiple execution engines within the same container deployment unit to share a common memory space, replacing network-based communication with inter-process communication. This merging eliminates network protocol overhead while maintaining the flexibility of containerized deployment, achieving transfer speeds that meet real-time cycle time requirements.
Data Source
Figure 1~2
Figure 3
AI summary
A method for real time updating of process applications, comprising the steps: executing (S10), by a first execution engine (10), a first process application (Ao) thereby controlling a process device (300), wherein the first execution engine (10) is a first software container deployed in a deployment unit (100), wherein software containers of the deployment unit (100) are deployed on a single physical host node; receiving (S20), by an update manager (20), an updated software, wherein the updated software comprises an updated process application (Au), being an updated version of the first process application (Ao), and/or an updated execution engine, being an updated version of the first execution engine (10), wherein the update manager (20) is a second software container deployed in the deployment unit (100); initializing (S30), by the update manager (20), the updated software in a second execution engine (30), wherein the second execution engine (30) is a third software container deployed in the deployment unit (100); determining (S40), by the update manager (20), an application state (S) of the first process application (Ao); instructing (S50), by the update manager (20), a transfer of the application state (S) from the first execution engine (10) to the second execution engine (30) via inter-process communication; instructing (S60), by the update manager (20), the second execution engine (30) to execute the updated process application (Au) using the received application state (S); and instructing (S70), by the update manager (20), the first execution engine (10) to stop writing output signals (So) for the process device (300), and instructing the second execution engine (30) to write output signals (So) for the process device (300).