Real-time updating method of process software

Abstract

A method for real-time updating of a process application comprises the following steps: executing a first process application by a first execution engine to control a process device; receiving updated software by an update manager, wherein the updated software includes an updated process application and / or an updated execution engine; wherein the update manager is a second software container deployed in a deployment unit; initializing the updated software in a second execution engine by the update manager; determining an application state of the first process application by the update manager; instructing the transfer of the application state from the first execution engine to the second execution engine via inter-process communication by the update manager; instructing the second execution engine by the update manager to execute the updated process application using the received application state; and instructing the first execution engine by the update manager to stop writing output signals for the process device and instructing the second execution engine to write output signals for the process device (300).

Description

Technical Field

[0001] The present invention relates to the field of process automation, in particular to process automation in industrial plants Background Art

[0002] In process automation, process applications, in particular control applications for calculating actuator outputs, are based on sensor data. They are executed periodically with a cycle time of, for example, 100ms, 10ms, or even as low as 1ms in extreme cases. Such applications need to be updated, in particular to optimize production efficiency, correct faults, apply security updates or comply with new standards. However, in order to avoid production stops, it is undesirable to stop the application for the update, especially in the case of minor adjustments to the control code.

[0003] The application execution engine that executes the application runs in a separate software container, such as a Docker container, a rkt container, or an LXD container, so that they can be managed by a container orchestration engine (e.g., Kubernetes, Docker Swarm, Nomad). This brings many benefits to managing and controlling the software. However, the orchestration engine may deploy each container on a different physical node, thus introducing undesirable network latency in the case of state transfer. In this case, different deployment units (e.g., Kubernetes pods, Docker Swarm's Podlike) can only communicate via network sockets, introducing latency.

[0004] Applications carry state, such as internal counters or internal timers. The updated application needs to be initialized with the exact state of the first application so that it can output the same results, or in case of logic changes, slightly different results.

[0005] State transfers must occur at a fairly fast rate (much slower than the cycle time). Specifically, state transfers need to be completed in the remaining time after the control application finishes executing and before the next execution cycle begins. State transfers require transferring internal state between applications, so transmission over a physical or virtual network is undesirable because of the added latency of the network protocol at multiple layers of the network stack. Summary of the invention

[0006] Therefore, it is an object of the invention to provide a method which allows real-time updating of process software. This object is achieved by the subject matter of the independent claims. Further preferred embodiments are evident from the dependent claims.

[0007] According to one aspect of the present invention, a method for real-time updating of process software is provided, the method comprising the following steps. In one step, a first process application is executed by a first execution engine to control a process device, wherein the first execution engine is a first software container deployed in a deployment unit, wherein the software container of the deployment unit is deployed on a single physical host node. In another step, an update manager receives updated software, wherein the updated software includes an updated process application and / or an updated execution engine, the updated process application is an updated version of the first process application, the updated execution engine is an updated version of the first execution engine, wherein the update manager is a second software container deployed in the deployment unit. In another step, the updated process application is initialized in a second execution engine by the update manager, wherein the second execution engine is a third software container deployed in the deployment unit. In another step, the application state of the first process application is determined by the update manager. In another step, the transfer of the application state from the first execution engine to the second execution engine via inter-process communication is indicated by the update manager. In another step, the second execution engine is indicated by the update manager to execute the updated process application using the received application state. In another step, the update manager instructs the first execution engine to stop writing output signals for the process device and instructs the second execution engine to write output signals for the process device.

[0008] In other words, updating the process software includes updating only the first process application and running the updated process application in a second execution engine that is identical to the first execution engine. Furthermore, updating the process software includes updating only the first execution engine and running the second process application that is identical to the first process application in the updated execution engine. Furthermore, updating the process software includes updating the first execution engine and the first process application and thereby running the updated process application in the updated execution engine.

[0009] As used herein, the term "application state" includes the values ​​of variables that have been set by the first process application. Variables include internal counters, internal timers, past executions, and / or states of PID loops, but do not include received sensor signals or sent output signals.

[0010] As used herein, the term "process equipment" refers to equipment used in industrial plants for running production processes. Process equipment is also called field equipment.

[0011] As used herein, the term "execution engine" includes a runtime environment capable of cyclically executing a process application, in particular a control logic application, for example according to IEC 61131-3. The runtime environment periodically receives input signals from process devices. The execution engine executes the process application, in particular a control algorithm, on these signals and calculates output signals, which are sent back to the process device.

[0012] As used herein, the term "process application" includes programs like control algorithms, such as a PID controller for air flow in a boiler. For example, a process application is implemented using one of the five IEC 61131-3 programming languages ​​(Structured Text, Function Block Diagram, Instruction List, Sequential Function Chart, Ladder Logic). During execution, a process application preferably carries an application state, such as the value of a counter variable, an intermediate calculation or a timer.

[0013] Preferably, the process device comprises a sensor or an actuator.

[0014] As used herein, the term "process device" is also referred to as a field device. A process device regulates an industrial process, such as temperature and flow in an oil pipeline or fill level of a chemical reactor. A process device is connected to a container deployment unit, such as via a network link, a fieldbus, or directly using analog input / output devices. A sensor periodically provides an updated sensor value, such as the temperature is 70 degrees, while an actuator continuously listens for an input signal, such as closing a valve to 20%. There is usually a gateway connecting the process device to the control software residing on a custom DCS controller or server.

[0015] Preferably, the update manager runs in the software container and is configured to coordinate the process of updating the application during runtime.

[0016] To control a process device, the execution engine receives input signals from the process device and provides output signals that are provided back to the process device.

[0017] Preferably, the process application comprises a control application for controlling a process system, in particular for a production process.

[0018] Deploying the first execution engine and the second execution engine in a single deployment unit allows inter-process communication. Therefore, other methods such as remote procedure calls or transfer of application states using a network stack, which are usually unable to meet the timing requirements required for dynamic updates of process applications, can be omitted.

[0019] In other words, using a single container deployment unit to host two application execution engines and therefore process applications enables fast state transfer via inter-process communication IPC. Only software containers in the same container deployment unit share the same IPC namespace, so inter-process communication can be achieved, such as using SystemV semaphores or POSIX shared memory. This allows relatively fast communication between software containers, especially compared to mapping each application execution engine directly to a separate deployment unit (which would prevent the use of IPC and require the use of slower (local) network communication).

[0020] Preferably, the update manager receives an updated execution engine that replaces the first execution engine, e.g., the first execution engine, in the same manner as the update manager updates the first process application. In other words, the mechanism allows for immediate updating of the execution engine itself, e.g., to upgrade to new features or apply security fixes. For example, the known Load-Evaluate-Go approach executes two versions of a process application in the same execution engine and therefore does not allow for updating the execution engine itself.

[0021] The provided methods allow fast internal application state transfer between execution engines.

[0022] Preferably, the updated process software is received by the update manager, in particular from an application engineering tool. The updated process software, in particular the updated process application, is preferably received as a text file, such as an XML file. The automation engineer uses the application engineering tool, or in other words the application engineering software, to implement the process application. The application engineering tool is preferably a desktop or web-based tool that allows uploading the process application to a runtime on a controller or server. In this case, the application engineering tool does not communicate directly with the execution engine, but transfers the updated process application to the execution engine via the update manager.

[0023] Preferably, process software, in particular process applications and / or execution engines, can be updated during runtime without interrupting the underlying process.

[0024] Therefore, a fast state transfer mechanism is provided for containerized control applications with real-time requirements.

[0025] Thus, the provided method implements a dynamic update mechanism for process applications running in a containerized environment, particularly compared to known non-containerized Load-Evaluate-Go methods.

[0026] The method thus provides for immediate updating of process software without affecting the production process of the process plant, for example by stopping the process plant during the update.

[0027] Integrating application execution into software containers and container orchestration engines can enable faster software delivery through online updates, automatically managed scalability and fault tolerance, and more efficient use of computing resources (especially compared to virtual machines).

[0028] Thus, an improved method for updating process software in real time is provided.

[0029] In a preferred embodiment, the first process application includes a predetermined cycle time, wherein the cycle time defines how often the first process application is periodically executed and output signals are written to the process device. The time for the second execution engine to transfer the application state from the first execution engine to the second execution engine, execute the updated process application, and write output signals to the process device is within the predetermined cycle time.

[0030] Thus, the first process application is updated to an updated process application within one process cycle. Similarly, the first execution engine is updated to an updated execution engine within one process cycle. Thus, the process device does not have to be paused. Furthermore, the process device does not detect any update of its process application and / or execution engine as a signal exchange between the process application and / or execution engine, whether original or updated, and the process device remains as expected within the predetermined cycle time.

[0031] Thus, an improved method for updating process software in real time is provided.

[0032] In a preferred embodiment, the predetermined cycle time is less than 100 ms.

[0033] Preferably, the predetermined cycle time is less than 10 milliseconds, more preferably less than 1 millisecond.

[0034] For some process automation applications, it is necessary to shorten the computational cycle time to 1-10 milliseconds.

[0035] Due to the inter-process communication between the original software including the first process application and the first execution engine and the updated process software, the method for updating the process software is still performed in real time without stopping the process equipment, even with extremely short cycle times.

[0036] Thus, an improved method for updating process software in real time is provided.

[0037] In a preferred embodiment, the application state includes variables set by the first process application during execution.

[0038] In order for the updated software to continue controlling the process device in the event that the first process application has left the process device under control, the updated process software needs to know the current control state of the process device. This information is selected by the application state. In other words, the application state includes a number of variables that are set or changed during the execution of the first process application. These variables are provided to the updated process software.

[0039] Thus, an improved method for updating process software in real time is provided.

[0040] In a preferred embodiment, inter-process communication between the first execution engine and the second execution engine is provided by using shared memory shared by the first execution engine and the second execution engine (e.g., POSIX shared memory using function shm_open, System V API using shmget, anonymous mapped memory in BSD systems, or POSIX memory mapped files using mmap API).

[0041] In a preferred embodiment, initializing the updated process application includes initializing a second execution engine and transferring the updated process application to the second execution engine.

[0042] In a preferred embodiment, initializing the updated process software includes enabling the second execution engine to read input signals provided by process devices controlled by the first process application.

[0043] Preferably, the updated process software is provided with input signals of the process device, so that at this stage of the updating process, the first process application and the updated process application are provided with the same input signals of the process device.

[0044] This improves the comparison of the output of the first process application and the updated process software.

[0045] Thus, an improved method for updating process software in real time is provided.

[0046] In a preferred embodiment, determining the application state includes filtering the application state to obtain retained variables, the retained variables being variables required for correct execution of the updated process application.

[0047] Preferably, the update manager uses hints from the project configuration file to identify the application state to be transferred. For example, the update manager identifies the application state by using reserved variables of the IEC 61131-3 control program.

[0048] Thus, an improved method for updating process software in real time is provided.

[0049] In a preferred embodiment, instructing the transfer of the application state from the first execution engine to the second execution engine includes pausing, by the update manager, execution of the first process application, instructing, by the update manager, the first execution engine to store the application state on a shared memory, instructing, by the update manager, the second execution engine to load the application state from the shared memory, and unpausing, by the update manager, execution of the first process application;

[0050] Preferably, the update manager pauses the execution engine, in particular the first execution engine, during the state transfer so that no value of the application state is overwritten.

[0051] Thus, an improved method for updating process software in real time is provided.

[0052] In a preferred embodiment, storing the application state on the shared memory includes compressing the application state by the first execution engine and storing the compressed application state on the shared memory. Loading the application state from the shared memory includes loading the compressed application state from the shared memory by the second execution engine and decompressing the compressed application state.

[0053] Compressing application state reduces the amount of data to be transferred, thereby reducing transfer latency.

[0054] In a typical process automation application, there are thousands of variables that make up the application state, and thus may consume hundreds of kilobytes or megabytes of memory. Compressing these variables by a factor of 3 to 5 can further reduce the required delay. Very fast compression algorithms (e.g., LZ4 or Zstandard) are better suited for this task.

[0055] Thus, an improved method for updating process software in real time is provided.

[0056] In a preferred embodiment, the method includes the following steps: verifying the output signal of the second execution engine based on the output signal of the first execution engine, and if it is determined that the output signal of the second execution engine is reliable, the update manager instructs the first execution engine to stop writing the output signal for the process device, and instructs the second execution engine to write the output signal for the process device; otherwise, the update manager deactivates the second execution engine.

[0057] Preferably, deactivating the second execution engine by the update manager comprises aborting the method and in particular providing an abort information to the user. The abort information preferably comprises a warning signal.

[0058] Thus, an improved method for updating process software in real time is provided.

[0059] In a preferred embodiment, the method is a computer implemented method.

[0060] According to another aspect of the present invention, a container deployment unit is provided, wherein the container deployment unit is configured to execute the method described herein.

[0061] According to another aspect of the present invention, a system for real-time updating of process applications includes an application engineering tool, a container deployment unit as described herein, and a process device. The application engineering tool is configured to provide updated process software to the container deployment unit. The container deployment unit is configured to control the process device. The process device is configured to be controlled by the container deployment unit.

[0062] According to another aspect of the present invention, a computer program comprises instructions which, when executed by a computer, cause the computer to perform the method as described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] The subject matter of the invention will be explained in more detail below with reference to preferred exemplary embodiments shown in the accompanying drawings, in which:

[0064] Figure 1 A schematic diagram of a system for real-time updating of process software is schematically shown;

[0065] Figure 2 A method for real-time updating of process software is schematically illustrated;

[0066] Figure 3 Another method for real-time updating of process software is schematically illustrated;

[0067] The reference numerals used in the drawings and their meanings are listed in summary form in the reference numeral list. In principle, identical components are provided with the same reference numerals in the figures. DETAILED DESCRIPTION

[0068] Figure 1 A system for real-time updating of process software, in this case for updating process applications, is schematically shown. The system comprises an application engineering tool 200, a container deployment unit 100 and a process device 300. The application engineering tool 200 is connected to the process device 300 via the container deployment unit 100. The application engineering tool 200 comprises application engineering software, which is used by application engineers to implement process applications. In this case, the application engineering tool 200 is used to push out an updated version of the process application that controls the process device 300. Therefore, the application engineering tool 200 provides the updated process application Au to the container deployment unit 100, in particular to the update manager 20 of the container deployment unit 100, in particular in the form of an XMLM file.

[0069] The container deployment unit 100 is configured to host at least one application execution engine, in particular in the form of a software container. Software containers hosted by the same container deployment unit 100 share the same inter-process communication namespace and therefore allow inter-process communication between software containers. In this case, the container deployment unit 100 hosts a first execution engine 10, which is configured to run a first process application Ao. The first process application Ao is provided by an input signal Si from a process device 300. The input signal Si, for example, includes sensor data from the process device 300. Using the input signal Si, the first process application Ao provides an output signal So, which is returned to the process device 300. The output signal So, for example, includes control data for adjusting a valve of the process device 300. In other words, the first process application Ao executed by the first execution engine 10 as a software container controls the process device 300.

[0070] In addition, the container deployment unit 100 is configured to host an update manager 20 as a software container. The update manager 20 is configured to coordinate and execute the update process of the first process application Ao. The update manager 20 is configured to provide a trigger signal to other software containers to trigger actions for the update process.

[0071] During the update process, the update manager is further configured to initialize the second execution engine 30 as a software container. The second execution engine 30 is configured to execute the updated process application Au that has been provided to the update manager 20.

[0072] Since the first execution engine 10 and the second execution engine 30 are hosted on a single container deployment unit 100, the shared memory 40 can be used for inter-process communication between the first execution engine 10 and the second execution engine 30. In order to achieve real-time update of the first process application 10, the time-critical steps of the update process must be performed during the cycle time of the first process application 10. The cycle time is defined by the first process application 10 itself and defines the time frame in which the first process application 10 periodically receives the input signal Si from the process device 300. The cycle time may be located in a time window of less than 10 milliseconds.

[0073] The update manager 20 is therefore configured to provide a disable trigger Td to the first execution engine 10, the disable trigger Td instructing the first execution engine 10 to stop or in other words pause the execution of the first process application Ao. The update manager 20 is also configured to provide a save trigger Ts to the first execution engine. The save trigger Ts instructs the first execution engine 10 to save the application state S of the first process application Ao to the shared memory 40. The application state S includes process variables, such as counters, which are necessary for the updated process application Au to continue to control the process device 300 when the first process application Ao is eventually deactivated. The update manager 20 is also configured to provide a load trigger TI to the second execution engine 30. The load trigger TI instructs the second execution engine 30 to load the application state S from the shared memory. Due to the nature of the inter-process communication established by the shared memory 40, the steps of storing the application state S to the shared memory 40 and loading the application state S from the shared memory can be performed very quickly, in particular within a fraction of a millisecond. The update manager 20 is configured to provide an enable trigger Te to the second execution engine 30, the enable trigger Te instructing the second execution engine 30 to execute the updated process application 30. The update manager 20 is further configured to provide an output disable trigger Tod to the first execution engine 10. The output disable trigger Tod indicates that the first execution engine 10 disables writing of the output signal So to the process device 300. On the other hand, the update manager 20 is configured to provide an output enable trigger Toe to the second execution engine 30. The output enable trigger Ted indicates that the second execution engine 30 enables writing of the output signal So to the process device 300. In other words, the second execution engine 30 is configured to execute the updated process application Au using the loaded application state S and the input signal Si of the process device 300 to determine the output signal So, which is provided to the process device 300 for controlling the process device 300.

[0074] Figure 2A method for real-time update of process software is schematically shown. In step S10, a first process application Ao is executed by a first execution engine 10 to control a process device 300, wherein the first execution engine 10 is a first software container deployed in a deployment unit 100, wherein the software container of the deployment unit 100 is deployed on a single physical host node. In another step S20, updated software is received by an update manager 20, wherein the updated software includes an updated process application Au and / or an updated execution engine, the updated process application Au is an updated version of the first process application Ao, and the updated execution engine is an updated version of the first execution engine 10. The update manager 20 is a second software container deployed in the deployment unit 100. In another step S30, the updated software is initialized in a second execution engine 30 by the update manager 20, wherein the second execution engine 30 is a third software container deployed in the deployment unit 100. In another step S40, the application state S of the first process application Ao is determined by the update manager 20. In another step S50, the transfer of the application state S from the first execution engine 10 to the second execution engine 30 via the inter-process communication is instructed by the update manager 20. In another step S60, the second execution engine 30 is instructed by the update manager 20 to perform an update using the received application state S. In another step S70, the first execution engine 10 is instructed by the update manager to stop writing the output signal So for the process device 300, and the second execution engine 30 is instructed to write the output signal So for the process device 300.

[0075] Figure 3 Another method for real-time updating of process software, in this case a process application, is schematically shown. In step Z10, the application design tool 200 triggers the upload manager, which has the updated process application Au to be uploaded. The updated process application Au is transferred to the update manager 20, for example as a text file (such as XML) via a network connection. This step is not time-critical.

[0076] In step Z20, the update manager 20 starts a software container (also called application container) with a second execution engine 30. Alternatively, the update manager 20 starts an updated version of the second execution engine 30 having at least the same capabilities as the first execution engine 10. The update manager 20 waits for the second execution engine 30 to be fully initialized.

[0077] In step Z30, the update manager 20 loads the updated process application Au into the second execution engine 30. The second execution engine 30 initializes its internal data structures accordingly and is then ready for execution. This step is also not time-critical.

[0078] In step Z40, the update manager 20 enables the process devices 300, in particular sensors or actuators, to send input signals Si to the second execution engine 30, the input signals Si being signal values ​​required for the execution of the process application, and also to the first execution engine 10. This is achieved, for example, by reconfiguring the gateway that provides the input signals Si. Alternatively, the update manager establishes an Open Platform Communication Unified Architecture OPC UA Client / Server or Pub / Sub subscription to these input signals Si from the second execution engine 30. For example, the latter may involve communicating with a message broker or listening to a multicast IP address.

[0079] In step Z50, the update manager prepares the transfer of the application state S from the first execution engine 10 to the second execution engine 30. The update manager 20 filters the application state S of the first process application Ao to find variables that are automatically marked or marked by the automation engineer as reserved variables in the application engineering tool 200. These variables must be transferred to allow the correct execution of the control logic. Other variables can be omitted because they do not seriously interfere with the application logic. Filtering the list of state variables of the application state S can reduce the required memory size and thereby achieve faster state transfer. If no variables are marked as reserved variables, the update manager simply creates a list of all state variables of the loader (in this case, the first process application Ao). Alternatively, the filtering of the application state S for reserved variables can also be performed in step Z20 before downloading the updated process application Au. In this case, the filtered list can also be used for other use cases, such as redundant failover.

[0080] In step Z60, the feasibility of the state transfer is checked by the update manager 20. Alternatively, a pre-check may also be performed before starting the second execution engine 30 in step Z20.

[0081] In step Z70, if the state transfer pre-check fails, the update manager 20 aborts the update attempt, stops the container of the second execution engine 30 and notifies the user with an error message. The error message preferably contains information about the reason for the pre-check failure and what steps are needed to meet the requirements for a successful pre-check. Optionally, it can interact with the container coordination environment to determine whether non-critical deployment units running in the same node can be migrated to other nodes to free up enough resources to achieve a successful state transfer. The user can then decide whether such migrations are needed and trigger them. Afterwards, a new pre-check will be performed.

[0082] In step Z80, if the state transfer pre-check is successful, a series of time-critical steps Z80-Z11 are started. First, the update manager suspends the execution of the first execution engine 10 via a trigger signal (disable trigger Td). This prevents overwriting variables that are part of the application state S to be transferred. The second execution engine 30 has not yet started execution and therefore does not interfere with the variables of the application state S.

[0083] In step Z90, the update manager 20 triggers (in this case by a storage trigger Ts) the first execution engine 10 to retrieve the previously marked variables forming the application state S to be transferred from the update manager 20. These variables are then exposed via the shared memory 40. Preferably, the first execution engine 10 compresses the variables of the application state S before copying them to the shared memory 40. Metadata about the variables is very suitable for compression, especially when executing on fast hardware. Therefore, compression further reduces the time of state transfer. After the successful retrieval of the variables, the first execution engine 10 resumes its execution and compensates for the time it spent extracting or in other words storing the application state S. In this way, the cycle time remains correct and the external process execution does not notice any cycle time omissions. When the first execution engine 10 resumes execution, the update manager immediately instructs the second execution engine 30 to cache all incoming input values ​​until the transfer of the application state S is completed. This avoids losing input updates during the state transfer.

[0084] In step Z100, the update manager 20 triggers the second execution engine 30 to load and decompress the variables forming the application state S from the shared memory 40. This is possible only because the software containers of the first execution engine 10 and the second execution engine 30 are in the same deployment unit 100, otherwise they would only be able to communicate over the network, which would increase latency. The time used to execute steps Z90 and Z100 must be much lower than the configured cycle time, for example 20ms, so that the execution cycle required by the controlled process of the process device 300 is maintained and not missed. In particular, this time needs to be less than the cycle time reduced by the execution time of the first process application Ao. If the cycle time is 20ms and the application execution requires 5ms, the state transfer and state loading must occur within 15ms or less. When the execution of the process application is resumed, the transfer and loading times are compensated by reducing the remaining waiting time before the next execution cycle begins. In this way, the execution of both the first execution engine 10 and the second execution engine 30 are synchronized and the cycle time is maintained, so that the switching between the first execution engine 10 and the second execution engine 30 is transparent to the controlled process of the process plant 300 .

[0085] In step Z110, the update manager 20 sets the second execution engine 30 to run, for example by enabling a trigger Te, at which point the second execution engine 30 copies the input signal Si, executes the updated process application Au, and thereby calculates the output signal So. This includes the input values ​​buffered during the state transition in step Z90. The output signal So has not yet been written back to the process device 300 to first verify the correct calculation. This verification can be performed by the user or automatically based on predefined rules, which for example specify the maximum acceptable difference between the output values ​​of the first execution engine 10 and the second execution engine 30.

[0086] In step Z120, for example, the current values ​​of the selected output signal So from both the first execution engine 10 and the second execution engine 30 are displayed to the user. The user can select or deselect these values. In the case where the signal updates very quickly, the system can provide the user with an indirect measurement of the "drift" of the output signal So of the first execution engine 10 and the second execution engine 30, for example, the difference between the numerical values, or the measurement jitter of the execution engine. The value of the output signal So does not necessarily need to be equal in each cycle. The update to the process application may have changed the logic used to calculate different values ​​for the output signal So. In addition, many process automation applications will not be seriously affected by the slight cycle clock drift between the execution engines. In this step, the user can make a comparison intuitively. The user can then initiate the change of the system from the first execution engine 10 to the second execution engine 30, for example by clicking a button, or aborting and rolling back, and the entire update that is correctly calculated cannot be verified.

[0087] In step Z130 , the update manager 20 disables the first execution engine 10 from writing the output signal So. This can be achieved by changing the release data set on the first execution engine 10 .

[0088] In step Z140 , the update manager enables the second execution engine 30 to write the output signal So. This can be achieved by changing the release data set on the second execution engine 30 .

[0089] In step Z150, the update manager deactivates the first execution engine 10, since it no longer contributes to controlling the process device 300. The software container may optionally be archived to allow for subsequent rollback of the update in case an undesirable computation is encountered later.

[0090] Reference numerals list

[0091] 100: container deployment unit

[0092] 10: First Execution Engine

[0093] 20: Update Manager

[0094] 40: Shared Memory

[0095] 30: Second execution engine

[0096] Ao: First process application

[0097] Au: Updated process application

[0098] S: Application status

[0099] Si: Input signal

[0100] So: output signal

[0101] Ts: Storage trigger

[0102] Tl: Loading trigger

[0103] Te: Enable trigger

[0104] Td: Disable trigger

[0105] Tod: Output disable trigger

[0106] Ted: Output Enable Trigger

[0107] 200: Application Engineering Tools

[0108] 300: Process equipment

Claims

1. A method for real-time updating of process software, comprising the following steps: A first process application (Ao) is executed (S10) by a first execution engine (10) to control a process device (300), wherein the first execution engine (10) is a first software container deployed in a deployment unit (100), wherein the software container of the deployment unit (100) is deployed on a single physical host node; receiving (S20) updated software by an update manager (20), wherein the updated software comprises an updated process application (Au) and / or an updated execution engine, the updated process application (Au) being an updated version of the first process application (Ao), and the 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) the updated software in a second execution engine (30) by the update manager (20), 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), wherein the application state (S) comprises values ​​of variables that have been set by the first process application; Instructing (S50) the update manager (20) to transfer the application state (S) from the first execution engine (10) to the second execution engine (30) via inter-process communication; The update manager (20) instructs (S60) the second execution engine (30) to execute the update using the received application state (S); as well as The update manager (20) instructs (S70) the first execution engine (10) to stop writing output signals (So) for the process device (300), and instructs the second execution engine (30) to write output signals (So) for the process device (300).

2. The method according to claim 1, wherein the first process application (Ao) comprises a predetermined cycle time, wherein the cycle time defines the frequency of periodically executing the first process application (Ao) and writing an output signal (So) to the process device (300); wherein The time for the second execution engine (30) to transfer the application state (S) from the first execution engine (10) to the second execution engine (30), execute the updated process application (Au), and write the output signal (So) for the process device (300) is within the predetermined cycle time.

3. The method according to claim 2, The predetermined cycle time is less than 100 ms.

4. The method according to claim 1 or 2, Wherein said application state (S) comprises variables which have been set by said first process application (Ao) during execution.

5. The method according to claim 1 or 2, The inter-process communication between the first execution engine (10) and the second execution engine (30) is provided by using a shared memory (40), and the shared memory (40) is shared by the first execution engine (10) and the second execution engine (30).

6. The method according to claim 1 or 2, Initializing (S30) the updated process application (Au) comprises: Initializing the second execution engine (30); as well as The updated process application (Au) is transferred to the second execution engine (30).

7. The method according to claim 1 or 2, Initializing (S30) the updated software includes: The second execution engine (30) is enabled to read an input signal (Si) provided by the process device (300) controlled by the first process application (Ao).

8. The method according to claim 1 or 2, Wherein determining the application state (S) comprises: The application state (S) is filtered to obtain reserved variables, the reserved variables being variables required for correct execution of the updated software.

9. The method according to claim 5, Wherein indicating (S50) the transfer of the application state (S) from the first execution engine (10) to the second execution engine (30) comprises: pausing, by said update manager (20), said execution of said first process application (Ao); The update manager (20) instructs the first execution engine (10) to store the application state (S) on the shared memory (40); The update manager (20) instructs the second execution engine (30) to load the application state (S) from the shared memory (40); The execution of the first process application (Ao) is unpaused by the update manager.

10. The method according to claim 9, wherein storing the application state (S) on the shared memory (40) comprises compressing the application state (S) by the first execution engine (10) and storing the compressed application state on the shared memory (40); The step of loading the application state (S) from the shared memory (40) comprises: The compressed application state is loaded from the shared memory (40) and decompressed by the second execution engine (30).

11. The method according to claim 1 or 2, verifying the output signal (So) of the second execution engine (30) based on the output signal (So) of the first execution engine (10); and If it is determined that the output signal (So) of the second execution engine (30) is successfully verified, the update manager (20) instructs (S70) the first execution engine (10) to stop writing the output signal (So) for the process device (300), and instructs the second execution engine (30) to write the output signal (So) for the process device (300); otherwise The second execution engine (30) is deactivated by the update manager (20).

12. The method according to claim 1 or 2, The method described herein is a computer-implemented method.

13. A container deployment unit, configured to execute the method according to any one of claims 1-12.

14. A system for real-time updating of process applications, comprising: Application Engineering Tools (200); The container deployment unit (100) according to claim 13; Process equipment (300); wherein the application engineering tool (200) is configured to provide updated software to the container deployment unit (100); wherein the container deployment unit (100) is configured to control the process equipment (300); and The process equipment (300) is configured to be controlled by the container deployment unit (100).

15. A computer program comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 12.

Images