Method and device for carrying out automation control in a distributed manner, and computer program product

Abstract

The invention relates to a device and a device for carrying out automation control in a distributed manner, partially in the cloud. Conventional automation solutions generally run on a programmable logic controller PLC, an apparatus which is used to control or regulate a machine or system. The method and the device enable a simulation which runs in the cloud, since in the cloud computing capacity can be provided as desired (as required), which is often not the case in the system ("shop floor") depending on the type of apparatuses ("edge") used. The pre-calculation of the simulation by a plurality of steps at a time ensures that a control program is still available even in the event of a short-term interruption in communication, during which a simulation result may not arrive in good time ("real time") in the system, such that the system can continue to operate without disruption.

Description

[0001] Description

[0002] Method and device for the distributed implementation of an automation control, as well as computer program product

[0003] Classic automation solutions usually run on a programmable logic controller (PLC), a device that is used to control or regulate a machine or system and is programmed digitally.

[0004] In its simplest form, a programmable logic controller has inputs, outputs, an operating system, and an interface through which the user program can be loaded. The user program specifies how the outputs are to be switched depending on the inputs or the internal state. Optionally, the software is connected to the hardware via a SCADA (Supervisory Control and Data Acquisition) layer for data aggregation. PLC devices are typically implemented like standard computers, consisting of a CPU and various layers of memory options. The automation code is downloaded to the device and then executed locally on the PLC.

[0005] The PLC typically has a cycle time, which is the time required to complete one processing cycle, including all communication tasks. This time depends on the program's computing time, i.e., the number of instructions. Higher-priority tasks interrupt the cycle, thus extending the cycle time.

[0006] If hardware and / or software is being developed that is intended to interact with a PLC, the real PLC should be available for the development process, but this is often not possible.

[0007] A realistic simulation of PLC behavior is also conceivable, or a simulation environment must be set up to emulate the real PLC. All of this causes additional effort and costs in a situation where many developers work remotely and in parallel on automation projects. Therefore, a PLC simulation must usually be set up and maintained for each developer workstation. However, developers should generally focus on tasks other than maintaining the automation simulation. Furthermore, this configuration also complicates centralized management of automation code, as classic automation code and PLC simulators are not well integrated into common version control systems.

[0008] Another aspect concerns code security: Large automation projects usually involve many sub-teams and it is often undesirable to share the automation source code with all teams. Even in this situation, maintaining and distributing compiled code (to avoid sharing the source code) is cumbersome.

[0009] There are already new developments to overcome the above-mentioned challenges of current standards for the development of automation solutions.

[0010] For example, a PLC simulation system can be provided as a service, perhaps as a cloud version, to enable a centralized solution for virtual commissioning. However, this solution still requires local setup on the developer's computer and is still not easy to use for non-experts. Furthermore, the cloud service is offered only for virtual commissioning and training, but is not intended for implementing real-world automation projects. It requires a fast internet connection capable of delivering the next set of signals within the device's cycle time (usually a few milliseconds).

[0011] WO 2020 / 123687 proposes a system in which the controller (i.e., the PLC) can be located in the cloud. The controller receives status information and sends action commands in response. The controller is further adapted to the current conditions using so-called control parameters. In the proposed solution, these control parameters are adapted using simulation systems and a reinforcement learning engine.

[0012] The action commands can include one or more actions (steps).

[0013] Communication between the system and the controller takes place via an “appropriate communication medium”.

[0014] EP 3 467 600 also describes a cloud central module for a programmable logic controller. Sensor values ​​are always transmitted before the start of the next program cycle. The transmission takes place via the IO modules and, for example, a backplane bus. No changes can be made to the control program during operation. WO 2022 / 269020 also describes a possibility for implementing a cloud-based control system with various digital twins for individual products or processes. Here, special attention is paid to the management of different tenants.

[0015] Another approach currently being pursued is so-called "software-defined control," inspired by the already well-known "software-defined networking." The development and deployment of automation code (source code) is being modified to better integrate with standard software development processes (such as CI / CD, versioning, and testing). However, the code continues to run on automation devices. Therefore, this approach still does not solve some of the aforementioned problems (such as avoiding local software maintenance and running PLC code in a central location).

[0016] It is therefore an object of the invention to provide a possibility which enables the execution of an automation control with an automation code distributed on a programmable logic controller and in the cloud.

[0017] The calculation and execution of the automation logic are divided into two separate modules, in contrast to classic controllers, where everything runs on the same device.

[0018] The object is achieved by a device according to the features of patent claim 1.

[0019] The problem is solved by a method according to the features of independent patent claim 10 and by a computer program product having the features of patent claim 19.

[0020] Further embodiments of the invention are described in the subclaims.

[0021] The device and method for distributed automation control with automation code with execution steps for an industrial plant comprises a control level with a calculation module for calculating the next steps of the automation behavior in the form of status values. The calculation module is located outside the industrial plant, in particular in a cloud environment.

[0022] At least one functionally independent subset is identified in the automation code and for each identified functionally independent subset, several execution steps of the automation code are then calculated in advance by the calculation module and saved as a signal data set.

[0023] For each functionally independent subset of the automation code, possible subsequent configurations with the automation code are simulated in the automation control status for the next execution steps of the automation control. In this application, a subsequent configuration is understood to mean either the transmission of the actual values ​​or, in another embodiment, only the transmission of the differences, i.e., only those values ​​that actually change. A signal data set with the calculated values ​​is then sent to an execution module, which is configured and designed to receive the signal data set from the calculation module and execute it in the industrial plant.

[0024] The procedure according to the invention enables, on the one hand, a simulation which runs, for example, in the cloud, since computing capacity can be made available here as required, which is not necessarily the case in the plant (“shop floor”) depending on the type of devices used (“edge”).

[0025] Conversely, calculating the simulation several steps in advance ensures that even in the event of a brief communication interruption, during which a simulation result may not reach the system in time ("real time"), a reasonable control program is still available, allowing the system to continue operating. Clustering functionally related subsets in the code significantly simplifies simulation over several steps, as not all possible combinations need to be checked, but only those that actually make sense.

[0026] There are various ways to determine the functionally independent subsets. Information about the industrial plant can be calculated from available engineering data, or from cabling diagrams or other plant plans.

[0027] If such data is not available, which may well be the case with older systems, the functionally independent subsets can also be derived through data analysis or observation of the automation behavior of the industrial system. Empirical values ​​from similar systems can also be used as a basis.

[0028] The result of calculating the signal data set can advantageously be stored and transmitted as a decision tree in a data structure. If the functionally independent subsets each represent a branch of the tree, then the step of separating irrelevant subsets is particularly simple by simply cutting off the respective branch. The tree structure also has the advantage that each level represents a journal, which is easy to understand. This allows one level to be separated during processing.

[0029] In this case, the result of the signal data set calculation can be directly tagged with timestamps for each execution step of the automation code. This is particularly relevant for discrete automation control, since the execution of the automation code is typically carried out step by step. Additionally, after a set timestamp is reached, an event can be triggered that influences the subsequent processing of the logic.

[0030] The transmission of a signal data record can be triggered in various ways. For example, an update can always be sent after a specified period of time, regardless of how many steps have been executed in the automation control since the last update. This is very easy to implement, but can have disadvantages, particularly if the time period is poorly selected and is too short (no further processing step has yet been carried out in the system) or too long (the instruction memory has already been completely processed). In this case, the actual situation in the system could already deviate too far from the simulation. The size of the signal data record to be transmitted could also be unfavorable. In this case, it is advisable to trigger a transmission depending on the calculation depth of the signal data record or even on the size of the signal data record's data structure.

[0031] To keep the size of a signal data set small, in a further embodiment of the invention, only the difference between the newly calculated signal data set and the previous signal data set can be included in the transmission. Furthermore, an evaluation can naturally be made of how well the respective simulations have depicted the actual situation in the plant. It is further advantageous for this purpose that, after execution of at least one step of the automation code in the industrial plant, the calculation module sends a feedback signal indicating the effect of the execution step on the industrial plant and recalculates the signal data set (325) based on the data contained in the feedback signal.

[0032] If such an evaluation is available, it can also be used to calculate the next execution step, which is the operation with the highest probability, based on the probability feedback from previous executions.

[0033] This also improves the result of the previously shown calculations.

[0034] The invention is explained in more detail by the embodiments and the figures.

[0035] Figure 1 shows a comparison between a conventional and the novel architecture

[0036] Figure 2 The simulation of possible status changes

[0037] Figure 3 a flowchart of the update communication between device and cloud

[0038] Figure 4 Calculation of different options of the same step and a decision tree

[0039] Figure 5 the communication between the cloud and an industrial plant according to the state of the art

[0040] Figure 1 shows a comparison of the proposed architecture 12 with a conventional architecture 11 of an automation system, as currently available on the market. The management level 110 comprises the engineering station for centrally configuring the automation system. Below is the field level 112 with various field devices, such as motors or other field devices, which perform the actual tasks in an industrial plant, such as manufacturing goods. Intermediate is the control level 111, which also houses the interface (HMI) to the plant's operating personnel, and the controller. Everything is linked via various communication media, such as Profibus (to the field level) and Profinet (to the engineering).

[0041] The new architecture is shown in simplified form on the right side 12. The three levels still exist, with the field level 122 still located on the system side 14, with input and output devices (IO). This layer does not differ from the conventional architecture on the left side of the figure.

[0042] In the architecture depicted here, the management level 120 with the TIA engineering system (e.g., the "Totally Integration Automation" portal from Siemens) is located exclusively outside the physical plant, for example, in a cloud, 300. The intermediate control level 121 must connect these two worlds and includes a comprehensive controller 123, the essential parts of which run in the cloud (CPU), and a subordinate part in the plant (MEM), possibly in multiple instances. The subordinate part (MEM) does not have a fully functional arithmetic unit, but merely an instruction pointer that selects one of the precalculated subsequent states depending on the current plant status (including IO).

[0043] The control module in the cloud, CPU, is solely responsible for calculating the next steps of the control program to control the automation behavior, but does not interact with the real hardware at the field level, 122. This module can be executed centrally at a remote location (e.g., in the cloud). It calculates the next set of control signals in advance and sends it to the unit for execution, for example, in an edge device, MEM. The MEM unit is responsible for receiving the signal data set and sending it to the real hardware IO according to the schedule. Therefore, no complex calculations are performed on this device, and no calculations are required on the control module CPU (only the copying of registers to the I / O unit is time-dependent).

[0044] This approach corresponds to a "software as a service" approach, coupled with a local simulation of the hardware, or even directly on the real hardware (which is not done in practice). The challenge now lies in the need to ensure real-time capability in an industrial plant: a pure cloud approach will fail as soon as signals cannot be delivered within the controller's cycle time. The new approach must be made resilient in this regard.

[0045] This can be achieved by pre-calculating possible events on the control module CPU as a decision tree, which is repeatedly sent continuously to the edge device(s) MEM after each calculation step.

[0046] Figure 2 shows how possible status changes are simulated. The current status of the (real) I / O registers 20 of the edge unit is copied to the cloud module. This occurs after each register update. As an example, the set value shown here is 0 for "off" and 1 for "on" - in the case of IO. In an alternative embodiment, only the change is sent, which is even more efficient than transmitting all values, since often only one value changes from step to step - if at all. On the other hand, such a solution would complicate expansion to non-binary values. Modern controllers can also process int or float values.

[0047] Upon receipt, the control module CPU begins simulating all possible future configurations that could result from the received status. To prevent unnecessary combinatorial growth of the decision tree, independent subsets of the PLC status 200 are identified. This can be derived, for example, from engineering or wiring diagrams. In this example, three of the signals 200 control a robot completely independently of the feeding mechanism, which is controlled by the same PLC. The three corresponding bits in the PLC register are identified to be coupled. In addition to analyzing plans, these dependencies can also be determined through data analysis, e.g., by observing the production line for an extended period in a simulation environment for different use cases, taking randomness into account.

[0048] After identifying the relevant subsets, possible subsequent configurations 211, 212, 222, ... are simulated for each subset using the automation code (e.g., the arrival of possible input signals, the expiration of a timer, error states, etc.). An example timestamp of 12ms, 200ms, ... is then specified for each step. Starting from the identified subset, this leads to a decision tree that can be efficiently stored in a data structure (e.g., in JSON) for later transfer. Typically, this tree is not fully populated with data, as possible changes in the current situation often do not occur simultaneously. In addition to the new status of the PLC registers, the calculation module also adds a journal to enable timer functions (e.g., trigger action after 450 ms).A kind of lookup table is generated in the cloud and transferred to the edge device. On the edge device itself, nothing is then calculated; instead, the appropriate successor state is simply looked up based on the current state and IO.

[0049] Once the next depth level 222 of the decision tree is computed, it is sent to the edge unit for execution. Optionally, the decision tree computation can be stopped after reaching a certain depth or size. The complete decision tree is stored for both the edge unit and the computation unit, but updates are sent either as an absolute value or, as already indicated above, only as the difference between subsequent changes in the tree.

[0050] Once the decision tree has been sent to the MEM unit, the real hardware IO begins executing the signal data set in the transmitted tree structure. To do so, it first fetches the log of the next level in the decision tree. When the log expires, the edge unit executes the corresponding configuration in the tree. In addition to timing, a new execution can also be triggered by the arrival of a changed signal at the MEM I / O register. In this case, the edge unit selects the next state by selecting the branch in the decision tree marked by the corresponding signal change, 231, 232.

[0051] As soon as a new status has been set in the edge unit, it sends an update to the calculation unit (possibly only every n steps), which then invalidates all branches except the selected one and can thus condense the decision tree before further calculation. For the system to function, the connection speed must be high enough to allow faster transfer of the decision tree than the data consumption by the edge unit (on average over a longer period of time, but not necessarily in every cycle). As connectivity will continue to improve in the coming years, this condition can be met in more and more use cases. Figure 3 shows in detail in a flowchart the data exchange outlined above between the industrial plant 301 (also called the shop floor) and the calculation module in the cloud 300.To initialize the process, the edge device 301 sends the initial status 310 of the factory assets 317 to the cloud. In addition to signals and settings, this could also include a so-called digital twin, i.e., a digital image or representation of a real object or process in the factory, including the associated communication flows, for further on-site simulation. However, it may be that most of the relevant assets are known from the outset and a digital twin already exists on the cloud side, so that only an additional status update is required (e.g., sending joint angles of a robot). As soon as the cloud side receives this data and a request for automation, it begins to simulate the possible next steps on the plant side and stores them in a tree-like data structure as explained above. For this purpose, the automation code is stored in a code repository 320.Steps 321, 322, and 323 simulate the computation of the decision tree 430, 431, 432 for steps 1 to 3. The decision tree is sent to the edge device 311, 312, 313 as soon as it is computed. It arrives at the edge device with a time delay 318 due to the communication between the cloud and the edge. If the computation of a step is very complex or involves many branches, the most likely next operation is computed first, based on the probability feedback from previous executions.

[0052] In Figure 3 we see an example in which a new version of the decision tree 430, 431, 432 is sent before the first action 314 is actually executed.

[0053] After executing the first step, the current status is reported back to the automation controller, 319. The new status is now analyzed, and all unused branches of the decision tree 434 are declared invalid and no longer used for subsequent calculations. The next values ​​for steps n+1, n+2, and n+3 are then calculated, 325, 326, 327. In the illustrated case, the next calculated result is transmitted, and after an update 315, the next step 316 is executed. This, in turn, leads to an update of the decision tree, which is reported back to the controller, 328. Furthermore, after each feedback from decision trees with invalid branches, feedback can be sent to the code repository 320, containing a statement regarding probability feedback to improve the calculations.

[0054] Figure 4 shows this situation in a decision tree 33, in which the current status 41 is marked. After receiving the "Robot on" signal 42 on the IO module, the edge device searches for the next action in the decision tree based on the status change. The other branch 43 of the decision tree deals with, for example, an "Emergency off" signal. Here, too, time stamps (20 ms, 55 ms) are provided for each execution step.

[0055] In this case, the signal could, for example, trigger the start of all robots and conveyor belts. This status change in the actual factory is immediately sent to the cloud. Here, all other branches in the decision tree (except the one used) become invalid, i.e., nodes 43, 45, 46, 48, and 49. Only branches below the removed node 42 continue to be calculated (or sent to the edge device), in the example shown, 44 and 47.

[0056] Above it is shown how the decision tree is further calculated in steps 3a, 3b and 3c 431 , 432, 433.

[0057] The calculation of parallel branches and actions can be easily parallelized in the cloud environment (e.g., in a multi-GPU environment), whereas parallelization options on devices in the industrial environment are usually limited.

[0058] Another advantage of the proposed method compared to the state of the art, as shown in Figure 5, is increased resilience to network connectivity issues. While the state of the art relies on a connection that is reliable and fast enough to send new signals directly between the cloud and the edge unit, the proposed method relies only on a certain average speed but allows for interruptions and jitter in the connection by calculating states in advance. As soon as a delayed transmission occurs, pre-calculated states can be used.

[0059] Figure 5 shows a state-of-the-art arrangement. Here, the automation control solution in the cloud would provide the next decision only through step-by-step communication: After the request 317, 52, 54, a calculation of the next step 51, 53, 55 is performed. This is returned to the plant 311, 312, then the next step is executed 314. A decision is made in response to a status change. In this case, the entire system fails if the communication between the cloud and the edge is delayed for too long 56, for example, if the material has already been unloaded from the conveyor belt and the robot can no longer pick it up. As already mentioned, the intention of previous solutions is not to automate real factories, but rather to serve simulation purposes, since they cannot currently meet the real-time capability requirements of a real plant.However, based on the proposed solution, solutions could be implemented for a real industrial plant by introducing a cache that is resilient to network delays and in which possible execution steps of the automation code are kept at all times.

Claims

Patent claims 1. A device (12) for the distributed implementation of automation control, comprising an automation code (320) with execution steps, for an industrial plant (IO, 301), wherein the device has a control level (121) with a calculation module (CPU) for calculating the next steps of the automation behavior in the form of status values, wherein the calculation module is arranged outside the industrial plant, in a cloud environment, and is designed and configured to identify a functionally independent subset (200) in the automation code and, for each identified functionally independent subset, to calculate the automation code several execution steps in advance (321, 322, 323) and to store them as a signal data set (40) by identifying possible subsequent configurations (211, 212, 222, ...) for each functionally independent subset of the automation code in the automation control status.) are simulated with the automation code for the next execution steps of the automation control, and is designed and configured to send (318) the signal data set to (40) an execution module (MEM) which is designed and configured to receive the signal data set (40) from the calculation module and to execute it in the industrial plant (IO, 301).

2. Device according to claim 1, characterized in that the derivation of the functionally independent subset (200) is carried out using information about the industrial plant (IO) from available engineering data (TIA) or cabling plans for the industrial plant (IO).

3. Device according to claim 1, characterized in that the derivation of the functionally independent subset (200) is carried out by data analysis or observation of the automation behavior of the industrial plant (IO).

4. Device according to one of the preceding claims, characterized in that the result of the calculation of the signal data set (40) can be stored, transferred and processed as a decision tree in a data structure.

5. Device according to one of the preceding claims, characterized in that the result of the calculation of the signal data set (40) contains time stamps for each execution step of the automation code (320).

6. Device according to one of the preceding claims, characterized in that the transmission of a signal data set (40) is triggered by a time or by the calculation depth of the signal data set (40) or by the size of the data structure of the signal data set (40).

7. Device according to one of the preceding claims, characterized in that a transmission (315) of a newly calculated signal data set (40) contains only the difference between the newly calculated signal data set (434) and the previous signal data set (432).

8. Device according to one of the preceding claims, characterized in that after execution of at least one step of the automation code in the industrial plant (IO, 301), the calculation module (CPU) receives a feedback (319, 329) which shows the effect of the execution step on the industrial plant, and carries out a recalculation of the signal data set (325) based on the data contained in the feedback.

9. Device according to one of the preceding claims, characterized in that the next execution step calculates the operation which has the highest probability based on the probability feedback of previous executions.

10. Computer-implemented method for the distributed implementation of an automation control in a cloud environment, comprising an automation code (320) with execution steps for an industrial plant (IO, 301), wherein a functionally independent subset (200) is identified in the automation code and, for each identified functionally independent subset, several execution steps of the automation code are calculated in advance (321, 322, 323) and stored as a signal data record (40) by simulating possible subsequent configurations (211, 212, 222, ...) with the automation code for the next execution steps of the automation control for each functionally independent subset of the automation code in the automation control status, and the signal data record (40) is sent (318) to an execution module (MEM) for execution of the signal data record (40) by a calculation module in the industrial plant (IO, 301).

11. Computer-implemented method according to claim 10, characterized in that the functionally independent subset (200) is determined using information about the industrial plant (IO) from available engineering data (TIA) or cabling plans for the industrial plant (IO).

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

13. Computer-implemented method according to one of the preceding claims 10 to 12, characterized in that the result of the calculation of the signal data set (40) is stored and transmitted as a decision tree in a data structure.

14. Computer-implemented method according to one of the preceding claims 10 to 13, characterized in that the result of the calculation of the signal data set (40) contains time stamps for each execution step of the automation code (320).

15. Computer-implemented method according to one of the preceding claims 10 to 14, characterized in that the transmission of a signal data set (40) is triggered by a point in time or by the calculation depth of the signal data set (40) or by the size of the data structure of the signal data set (40).

16. Computer-implemented method according to one of the preceding claims 10 to 15, characterized in that the transmission (315) of a newly calculated signal data set (40) contains only the difference between the newly calculated signal data set (434) and the previous signal data set (432).

17. Computer-implemented method according to one of the preceding claims 10 to 16, characterized in that after execution of at least one step of the automation code in the industrial plant (IO, 301), the calculation module (CPU) receives a feedback (319, 329) which indicates the effect of the execution step on the industrial plant and carries out a recalculation of the signal data set (325) based on the data contained in the feedback.

18. Computer-implemented method according to one of the preceding claims 10 to 17, characterized in that the next execution step is to calculate the operation which has the highest probability based on the probability feedback of previous executions.

19. Computer-implemented computer program product for carrying out the steps of a method according to the features of any of claims 10 to 18.

Images