Method and apparatus for distributed execution of automation control and computer program product

Abstract

The invention relates to a device and a method for partially distributed execution of automation control in the cloud. A classical automation solution usually runs a device on a programmable logic controller, which is used to control or regulate a machine or a facility. With this device and method, on the one hand, a simulation running in the cloud is implemented, since here the computing power can be provided arbitrarily (as required), which is not the case in a facility ("shop floor") according to the type of device ("edge") employed. Here, the pre-calculation of the simulation several steps in advance ensures that even in the event of a short communication interruption, during which the simulation result can not arrive in time ("real-time") at the facility, a control program is provided, which enables the facility to continue working without interruption.

Description

Background Technology

[0001] Classic automation solutions typically run devices on memory programmable controllers (SPS), also known as programmable logic controllers (PLCs), which are used for open-loop or closed-loop control of machines or facilities and are programmed on a digital basis.

[0002] In its simplest form, a programmable logic controller (PLC) has inputs, outputs, an operating system, and an interface through which user programs can be loaded. The user program specifies how the outputs should switch based on the inputs or internal states. Optionally, the software connects to the hardware along with a SCADA (Supervisory Control and Data Acquisition) layer for data aggregation. SPS devices are typically implemented as standard computers, consisting of a CPU (Central Processing Unit) and various levels of storage options. Automation code is downloaded to the device and then executed locally on the SPS.

[0003] SPS typically has a cycle time, which is the time used to process a cycle including all communication tasks. The cycle time depends on the computation time allocated to the program, i.e., on the number of instructions. Higher-priority tasks interrupt the cycle and thus extend the cycle time.

[0004] If the hardware and / or software to interact with the SPS is being developed, a real SPS should be available in the development process, but this is usually not feasible.

[0005] A near-realistic simulation of SPS behavior is conceivable, or it may be necessary to build simulation environments to mimic real-world SPS. All of this incurs additional overhead and cost when a large number of developers are working remotely and in parallel on automation projects. Therefore, it is often necessary to design and maintain SPS simulations for each development workstation. However, developers should generally focus on tasks other than maintaining automation simulations.

[0006] Furthermore, this configuration makes centralized management of automated code difficult, as classic automated code and SPS simulators do not integrate well with known version control systems.

[0007] On the other hand, code security is involved: large automation projects often involve many sub-teams, and it is generally not desirable to share the automation source code with all teams. In this case, maintaining and distributing the compiled code (to avoid sharing the source code) is also laborious.

[0008] New developments have emerged to overcome the aforementioned challenges of current development standards for automation solutions.

[0009] For example, SPS's simulation system can be offered as a service, such as a cloud version, to provide a centralized solution for virtual debugging. However, this solution requires local setup on the developer's computer and remains difficult for non-experts to operate. Furthermore, cloud services are only provided for virtual debugging and training, and are not intended for executing real-world automation projects. A fast internet connection is required, capable of providing the next set of signals within the device's cycle time (typically milliseconds).

[0010] WO 2020 / 123687 proposes a system in which a controller (i.e., an SPS) can be deployed in the cloud. The controller receives state information and subsequently issues action commands. The controller is further adapted to the current situation through so-called control parameters. In the proposed solution, the control parameters are adapted using a simulation system and a reinforcement learning engine.

[0011] An action command can include one or more actions (steps).

[0012] Communication between the facility and the controller is conducted via an “appropriate communication medium”.

[0013] EP 3 467 600 also describes a cloud central module for programmable logic controllers. Here, sensor values ​​are always transmitted before the start of the next program cycle. Transmission occurs via I / O (input / output) modules and, for example, a backplane bus. Changes to the control program cannot be made while the system is running.

[0014] WO 2022 / 269020 also describes the possibility of implementing cloud-based control with various digital twins for different products or processes. Particular attention is paid here to the management of different tenants.

[0015] Another approach currently under development is the so-called "software-defined control," inspired by the already known "software-defined networking." The development and provision of automated code (source code) is altered to better integrate it into standard software development processes such as CI / CD, versioning, and testing. However, the code continues to execute on the automated equipment. Therefore, some of the issues mentioned (such as avoiding local software maintenance and running SPS code in a central location) remain unresolved. Summary of the Invention

[0016] Therefore, the object of the present invention is to provide the possibility of implementing automated control using automated code on a programmable logic controller and distributed in the cloud.

[0017] The calculation and execution of automation logic are separated into two separate modules, unlike the classic controller where everything runs on the same device.

[0018] This objective is achieved by a device having the features of claim 1.

[0019] This objective is achieved by a method having the features of independent patent claim 10 and by a computer program product having the features of patent claim 19.

[0020] Other embodiments of the invention are described in the dependent claims.

[0021] Devices and methods for distributed execution of automated control for industrial facilities have a control level, which has a computation module for calculating the next steps of automated behavior in the form of state values. The automated control includes automation code that has execution steps.

[0022] Here, the computing modules are located outside of industrial facilities, especially in cloud environments.

[0023] The automation code identifies at least one functionally independent subset, and then for each identified functionally independent subset, multiple execution steps of the automation code are pre-computed by a computation module and stored as a signal dataset.

[0024] For each functional subset of the automation code, under automated control conditions, feasible subsequent configurations are simulated using the automation code for the next execution steps of the automated control. Here, in this application, subsequent configurations are understood to either transmit actual values, or, in another embodiment, only transmit differences, i.e., only transmit values ​​that actually change.

[0025] Then, the signal dataset with calculated values ​​is sent to the execution module, which is configured and structured to receive the signal dataset from the calculation module and execute it in the industrial facility.

[0026] By means of processing according to the invention, on the one hand, simulation is achieved, which runs, for example, in the cloud, because computing power can be provided arbitrarily (as needed) there, whereas this is not necessarily the case in a facility (“workshop”) depending on the type of equipment (“edge”) used.

[0027] Conversely, pre-calculating the simulation step by step ensures that even during brief communication interruptions, when simulation results may not arrive at the facility in a timely ("real-time") manner, reasonable control procedures still exist to allow the facility to continue operating. By clustering functionally related subsets in the code, the simulation via steps is significantly simplified, as it is not necessary to examine all possible combinations, but only those that are useful.

[0028] Here, there are different possibilities for deriving functionally independent subsets. Information about industrial facilities can be calculated from available engineering data, or from wiring diagrams or other drawings of the facility.

[0029] If such data is unavailable, which may be the case in older facilities, then the derivation of functionally independent subsets can also be done through data analysis or observation of the automated behavior of industrial facilities. This can also be based on empirical values ​​from similar facilities.

[0030] The computation results of the signal dataset can be advantageously stored and transmitted in a data structure as a decision tree. If functionally independent subsets are the branches of the tree, then the step of separating irrelevant subsets is particularly straightforward: simply prune the corresponding branches. The tree structure also has the advantage that each layer represents a time step, which is easy to understand. Layers can be removed individually during processing.

[0031] In this scenario, the computational results of the signal dataset can directly timestamp each execution step of the automation code. This is particularly relevant in discrete automation control, as the execution of automation code is typically performed incrementally. Additionally, upon reaching the set timestamp, an event can be triggered that influences subsequent logical processing.

[0032] The transmission of signal datasets can be triggered in different ways. For example, updates can always be sent after a fixed time period, regardless of how many steps have been performed in the automation control since the last update. This is very easy to implement, but it can have drawbacks, especially when the time period is poorly chosen and is either too short (no further processing steps have been performed in the facility) or too long (the instruction memory has been fully processed). Thus, the actual situation in the facility may have deviated significantly from the simulation. The size of the signal dataset to be transmitted can also be unfavorable. Therefore, a solution is to trigger transmission based on the computational depth of the signal dataset or the size of the signal dataset's data structure.

[0033] In order to keep the size of the signal dataset small, in another embodiment of the invention, the transmission can include only the difference between the newly calculated signal dataset and the previous signal dataset.

[0034] Furthermore, it is naturally possible to evaluate how well the respective simulations map the real conditions in the facility. To this end, it is further advantageous that, after executing at least one step of the automation code in the industrial facility, the computing module sends feedback indicating the impact of the executed step on the industrial facility, and performs a recalculation of the signal dataset based on the data contained in the feedback (325).

[0035] If such an evaluation exists, it can also be used to: calculate the operation with the highest probability first, based on the probability feedback of previous executions, as the next execution step.

[0036] This also improves the results of the calculations shown above. Attached Figure Description

[0037] The present invention will be described in more detail with reference to embodiments and accompanying drawings. The drawings show: Figure 1 This illustrates a comparison between traditional and new architectures. Figure 2 The simulation shows the possible state transitions. Figure 3 This diagram illustrates the update communication process between the device and the cloud. Figure 4 This shows the calculations and decision trees for different options in the same step. Figure 5 This illustrates communication between the cloud and industrial facilities based on existing technology. Detailed Implementation

[0038] Figure 1 The proposed architecture 12 is shown in comparison to the conventional architecture 11 of currently available automation systems on the market. The management level 110 includes engineering stations for centralized planning of the automation facility. Below this is the field level 112, which contains various field devices, such as motors or other field equipment, that perform actual tasks within the industrial facility, such as manufacturing goods.

[0039] Control level 111 is connected between these levels, where HMIs and controllers for facility operators are also located. Everything is connected via various communication media, such as Profibus (process fieldbus) (at the field level) and Profinet (process field network) (at the engineering level).

[0040] The new architecture is simplified and drawn on the right side at 12. Three levels remain, with field level 122 continuing on facility side 14, which has input and output device I / O. This layer is no different from the traditional architecture on the left side of the diagram.

[0041] The management level 120, along with the engineering system TIA (such as Siemens' "Total Integrated Automation" portal), resides only outside the actual facility in this architecture, i.e., in the cloud 300, for example. The intermediate access control level 121 must connect these two worlds and includes the upper-level controller 123, whose core (CPU) runs in the cloud, and whose lower-level components (MEM) run in the facility, sometimes as multiple instances. The lower-level components (MEM) do not have fully functional computing mechanisms, but only instruction pointers that select one of the pre-calculated subsequent states based on the current facility state (including I / O).

[0042] The control module CPU in the cloud is only responsible for calculating the next steps of the control program to control automated behavior, but does not interact with the actual hardware in the field level 122. This module can be executed centrally at a remote location (e.g., in the cloud). The module pre-calculates the control signals for the next signal dataset and sends them to the unit for execution, such as in the edge device MEM. The MEM is responsible for receiving the signal dataset and sending it to the actual hardware I / O according to the time step. Therefore, no complex calculations are performed on this device, and no calculations are needed on the control module CPU (only time-dependent copying of registers to the input or output unit I / O is required).

[0043] This approach corresponds to a "Software as a Service" approach, coupled with local hardware simulation or directly integrated with real hardware (which is not implemented in practice). The challenge now lies in ensuring real-time capabilities in industrial facilities; a pure cloud solution will fail if the signal cannot be provided within the controller's cycle time. The new approach is resilient in this regard.

[0044] This can be achieved by pre-compiling possible events as a decision tree on the control module CPU, and then repeatedly sending the decision tree to one or more edge devices MEM after each calculation step.

[0045] exist Figure 2 The diagram illustrates how possible state changes are simulated. The current state of register 20 of the edge unit's (real) I / O is copied to the cloud module. This is done after each register update. In the case of I / O, this example shows setting the value 0 to "off" and 1 to "on". In an alternative design, only the change is sent, which is more efficient than transmitting all values ​​because, if it occurs, typically only one value changes from one step to the next. On the other hand, such a scheme makes it difficult to extend to non-binary values. Therefore, modern controllers are also capable of handling integer or floating-point types.

[0046] Upon receiving the data, the control module CPU begins simulating all possible future configurations, which can be derived from the received states. To prevent unnecessary combinatorial growth of the decision tree, independent subsets 200 of the SPS states are identified. This can be derived, for example, from engineering diagrams or wiring diagrams. In the example described, three signals control the robot completely independently of the feeding mechanism, which is controlled by the same SPS. Three relevant bits in the SPS register are identified, and these bits should be coupled. Besides the analysis graph, correlations can also be confirmed through data analysis, for example, by observing the production line for different usage scenarios over a longer period in a simulated environment, including randomness.

[0047] After identifying relevant subsets, feasible subsequent configurations 211, 212, 222… are simulated using automated code for each subset (e.g., possible arrival of input signals, timer expiration, fault states, etc.). Exemplary timestamps of 12ms, 200ms… are illustrated in these steps. Starting from the identified subsets, this generates a decision tree, which can be efficiently stored in a data structure (e.g., JSON) for subsequent transmission. Typically, the tree is not fully occupied by data, as possible changes do not usually occur simultaneously in the current situation. In addition to the new state of the SPS register, the computation module adds a time step to implement timer functionality (e.g., triggering an action after 450ms). A lookup table is generated in the cloud and transmitted to the edge device, where computation is no longer performed; instead, only the appropriate subsequent state is looked up based on the current state and I / O.

[0048] Once the next depth level 222 of the decision tree is computed, it is sent to the edge unit for execution. Optionally, the computation of the decision tree can stop after reaching a certain depth or size. The complete decision tree is stored in both the edge unit and the computation unit, but updates are sent either as absolute values ​​or, as already noted above, only as differences between subsequent changes in the tree.

[0049] Once the decision tree is sent to the MEM, the actual hardware I / O begins executing the signal dataset according to the transmitted tree structure. To do this, it first obtains the time step for the next level in the decision tree. When the time step expires, the edge unit executes the corresponding configuration in the tree. Besides timing, new execution can also be triggered by the appearance of changing signals at the I / O registers or the MEM. In this case, the edge unit selects the subsequent states 231 and 232 by choosing the branch in the decision tree that has been marked by the corresponding signal change.

[0050] Once a new state is set in the edge unit, it sends an update to the computation unit (once every n steps if necessary). The computation unit then invalidates all branches except the selected one, thus compressing the decision tree before further computation. For the system to work, the connectivity must be fast enough to achieve faster decision tree transfer than consuming data through the edge units (averaging over longer time periods, but not necessarily in every cycle). As connectivity continues to improve over the next few years, this condition will be met in an increasing number of use cases.

[0051] Figure 3 A detailed flowchart illustrates the aforementioned data exchange between industrial facility 301 (also referred to as the workshop) and the computing module in cloud 300. To initialize the process, edge device 301 sends the initial state 310 of factory asset 317 to the cloud. In addition to signals and settings, this also includes a so-called digital twin—a digital mapping or representation of the actual factory objects or processes—including the associated communication streams for further on-site simulation. However, most of the relevant assets may already be known from the outset, and the digital twin already exists on the cloud side, making only additional state updates (e.g., sending robot joint angles) necessary. Once the cloud-side activity data and requests for automation are received, the cloud begins simulating possible subsequent steps on the facility side and stores them in a tree-like data structure as described above. For this purpose, automation code is pre-reserved in codebase 320. Steps 321, 322, and 323 simulate the calculation of decision trees 430, 431, and 432 for steps 1 through 3. Once the decision tree is calculated, it is sent to edge devices 311, 312, and 313. Due to communication between the cloud and the edge, there is a time delay of 318 when it arrives at the edge device. If the computation of a step is very complex or contains many branches, the most likely next operation is calculated first based on the probabilistic feedback of previous executions.

[0052] exist Figure 3 The following example shows that the new versions of decision trees 430, 431, and 432 are sent before the first action 314 is actually executed.

[0053] After the first step is executed, the current state is reported to the automation controller (report 319). The new state is now analyzed, and all unused branches of decision tree 434 are declared invalid and no longer used for subsequent calculations. Subsequently, calculations (325, 326, 327) are performed on the subsequent values ​​of steps n+1, n+2, and n+3. In the illustrated case, the result of the next calculation is transmitted, and subsequent step 316 is executed after update 315. This again causes an update to the decision tree, which is reported to the controller (report 328).

[0054] Furthermore, after each feedback of a decision tree with invalid branches, it is possible to provide feedback to codebase 320 with a statement about probabilistic feedback to improve computation.

[0055] Figure 4 The situation is illustrated in decision tree 33, where the current state 41 is marked. After receiving the "robot run" signal 42 on the IO module, the edge device searches for the next action in the decision tree based on the state change. Another branch 43 of the decision tree handles, for example, the signal "emergency shutdown". Timestamps of 20ms and 55ms are also provided for each execution step.

[0056] In this scenario, the signal could, for example, trigger the activation of all robots and conveyors. The state change in the actual factory is immediately sent to the cloud. All other branches in this decision tree (except the one being used) are declared invalid, i.e., at nodes 43, 45, 46, 48, and 49. Only the branch under the removed node 42 is continued for calculation (or sent to the edge device), branches 44 and 47 in the example shown.

[0057] The above shows how the decision tree is further computed in steps 3a, 3b, and 3c, 431, 432, and 433.

[0058] The computation of parallel branches and actions can be well parallelized in cloud environments (such as multi-GPU environments), while the possibility of parallelization on devices in industrial environments is often limited.

[0059] The proposed method is compared to, for example Figure 5 Another advantage of the prior art shown is its improved resilience to network connectivity issues. While existing technologies rely on reliable and sufficiently fast connections to transmit new signals directly between the cloud and edge units, the proposed method is based only on a specific average speed, but allows for interruptions and jitter in the connection by pre-compiling the state. In the event of a delayed transmission, it is possible to fall back to the pre-computed state.

[0060] exist Figure 5 The diagram illustrates a layout based on existing technology. Here, the cloud-based automation control solution provides the next decision solely through step-by-step communication: Following requests 317, 52, and 54, calculations 51, 53, and 55 are performed for the corresponding subsequent steps. These calculations are returned to the facility as 311 and 312, and then subsequent step 314 is executed. Decisions are made as responses to state changes.

[0061] In this scenario, if communication between the cloud and the edge is delayed excessively, the entire system fails,56 for example, when materials have already been unloaded from the conveyor belt and the robot can no longer pick them up. As mentioned earlier, existing solutions are not intended for automating real factories but only for simulation purposes, as they currently cannot meet the real-time capabilities required by real facilities. However, based on the proposed solution, by introducing a cache, a solution can be implemented for real industrial facilities, wherein the cache is resistant to network latency and reserves possible execution steps of automation code at any time.

Claims

1. A device (12) for distributed execution of automated control for an industrial facility (IO, 301), the automated control including automated code (320) having execution steps. in, The device has a control level (121), the control level having: - The computing module (CPU) is used to calculate the next steps for automated behavior in the form of state values. The computing module is located outside the industrial facility, in a cloud environment, and is designed and configured for... Identify functionally independent subsets (200) in the automation code, and By using the automation code to simulate feasible subsequent configurations (211, 212, 222, ...) for each functionally independent subset of the automation code in the automated control state, feasible subsequent configurations are simulated for the next execution steps of the automation control. For each identified functionally independent subset of the automation code, multiple execution steps (321, 322, 323) are pre-calculated and stored as a signal dataset (40). - The computing module is designed and configured to send the signal dataset (40) (318) to the execution module (MEM), which is configured and designed to receive the signal dataset (40) from the computing module and execute it in the industrial facility (IO, 301).

2. The device according to claim 1, characterized in that, The functionally independent subset (200) is derived from the available engineering data (TIA) or wiring diagrams of the industrial facility (IO) using information about the industrial facility (IO).

3. The device according to claim 1, characterized in that, The functionally independent subset (200) is derived by data analysis or observation of the automated behavior of the industrial facility (IO).

4. The device according to any one of the preceding claims, characterized in that, The results of the calculation of the signal dataset (40) can be stored, transmitted and processed in the data structure as a decision tree.

5. The device according to any one of the preceding claims, characterized in that, The result of the calculation of the signal dataset (40) contains a timestamp for each execution step of the automation code (320).

6. The device according to any one of the preceding claims, characterized in that, The transmission of the signal dataset (40) is triggered by a time point, or by the computational depth of the signal dataset (40), or by the size of the data structure of the signal dataset (40).

7. The device according to any one of the preceding claims, characterized in that, The transmission (315) of the newly calculated signal dataset (40) contains only the differences between the newly calculated signal dataset (434) and the previous signal dataset (432).

8. The device according to any one of the preceding claims, characterized in that, After at least one step of the automation code is executed in the industrial facility (IO, 301), the computing module (CPU) receives feedback (319, 329) indicating the impact of the execution step on the industrial facility, and performs a recalculation (325) of the signal dataset based on the data contained in the feedback.

9. The device according to any one of the preceding claims, characterized in that, As the next execution step, the operation with the highest probability is calculated first based on the probability feedback of the previous execution.

10. A method for distributively executing computer-implemented automation control for an industrial facility (IO, 301) in a cloud environment, the automation control including automation code (320) having execution steps. in, -A subset (200) independent of the aforementioned automated code recognition function, and - By simulating feasible subsequent configurations (211, 212, 222, ...) for each functionally independent subset of the automation code in the automated control state, multiple execution steps (321, 322, 323) are pre-calculated for each identified functionally independent subset of the automation code and stored as a signal dataset (40). - and send (318) the signal dataset (40) to the execution module (MEM) to execute the signal dataset (40) through the computing module in the industrial facility (IO, 301).

11. The computer-implemented method according to claim 10, characterized in that, The functionally independent subset (200) is determined from the available engineering data (TIA) or wiring diagrams of the industrial facility (IO) using information about the industrial facility (IO).

12. The computer-implemented method according to claim 10, characterized in that, The functionally independent subset (200) is determined by data analysis or observation of the automated behavior of the industrial facility (IO).

13. The computer-implemented method according to any one of claims 10 to 12, characterized in that, The results of the calculation of the signal dataset (40) are stored and transmitted in the data structure as a decision tree.

14. The computer-implemented method according to any one of claims 10 to 13, characterized in that, The result of the calculation of the signal dataset (40) contains a timestamp for each execution step of the automation code (320).

15. The computer-implemented method according to any one of claims 10 to 14, characterized in that, The transmission of the signal dataset (40) is triggered by a time point, or by the computational depth of the signal dataset (40), or by the size of the data structure of the signal dataset (40).

16. The computer-implemented method according to any one of claims 10 to 15, characterized in that, The transmission (315) of the newly calculated signal dataset (40) contains only the differences between the newly calculated signal dataset (434) and the previous signal dataset (432).

17. The computer-implemented method according to any one of claims 10 to 16, characterized in that, After at least one step of the automation code is executed in the industrial facility (IO, 301), the computing module (CPU) receives feedback (319, 329) indicating the impact of the execution step on the industrial facility, and performs a recalculation (325) of the signal dataset based on the data contained in the feedback.

18. The computer-implemented method according to any one of claims 10 to 17, characterized in that, As the next execution step, the operation with the highest probability is calculated first based on the probability feedback of the previous execution.

19. A computer-implemented computer program product for performing the steps of the method according to any one of claims 10 to 18.

Images