Method for providing programmable logic controller with transferable application

Abstract

The invention relates to a method for providing a migrating application program for a programmable logic controller. The method comprises the following steps: converting the application program of the programmable logic controller into a universal programming language; modifying the translated application using a general programming language in order to generate at least one access module to enable the translated application to access the at least one sensor and / or the at least one actuator; compiling the modified application program into a byte code format so as to provide a transferable application program; executing the transferable application and the application so as to provide an output of the transferable application and an output of the application so as to provide a verification result; validating the transferable application based on a comparison of the output of the transferable application to the output of the application; the validated transferable application is provided on the programmable logic controller, where the provision depends on the result of the validation. The invention also relates to a computer program, a device and a storage medium therefor.

Description

Technical Field

[0001] The present invention relates to a method for providing a programmable logic controller with a portable application program, and also relates to a computer program, a device and a storage medium therefor. Background Art

[0002] Edge computing is, in particular, a distributed computing paradigm in which computing resources, so-called edge computing nodes or edge devices, can be executed on devices located at or near the edge of a network or data source rather than in a central computing center or in the cloud for data processing and storage. Edge computing can enable processing of data closer to the source, reduce latency and improve reaction time. Thus, edge computing or edge computing-based solutions can be found in Internet of Things (IoT) applications that require real-time data processing and decision-making, such as self-driving cars, or in industrial automation.

[0003] The introduction of edge computing in industrial automation enables the monitoring, analysis and control of industrial processes in real time, thereby enabling improved efficiency, productivity and safety. However, adapting existing industrial automation applications, especially in a modern, future-oriented edge computing ecosystem, can be a challenge and is therefore not a simple task.

[0004] Industrial control applications are usually written in IEC 61131-3, an international standard for programmable logic controllers (SPS) and related programming languages. This standard was developed by the International Electrotechnical Commission (IEC) and can be used in industrial automation systems. The standard defines five programming languages, such as ladder diagram (LD), function block diagram (FBD), structured text (ST), sequential function chart (SFC) and instruction list (IL).

[0005] The communication between the SPS executing such industrial control applications and the input and output (I / O) can usually be achieved through communication protocols such as MODBUS, PROFINET or EtherNet / IP. These protocols can enable the SPS to read the input values ​​of sensors and send output values ​​to actuators and other devices.

[0006] The IEC 61131-3 standard can also define a data model for I / O variables used in SPS programs. The data model has data types such as integers, floating point numbers and Boolean values, and can implement the definition of symbolic names for I / O variables. These I / O variables can usually be used as global variables within industrial control applications.

[0007] Existing SPS applications may execute in a customized industrial control runtime environment and are therefore particularly tightly coupled to the software. This may make it difficult to flexibly redeploy on more powerful devices. Existing SPS applications may also be developed on specific hardware. In addition, existing SPS applications may be written in highly domain-specific languages ​​(such as structured text, ladder diagrams, or function block diagrams) that may not be easily extended because they may be tailored for traditional single-core configurations and sequential execution. Summary of the invention

[0008] According to aspects of the invention, a method having the features of claim 1, a computer program having the features of claim 8, a data processing device having the features of claim 9 and a computer-readable storage medium having the features of claim 10 are provided. Further features and details of the invention are derived from the respective dependent claims, the description and the drawings. Features and details described in conjunction with the method according to the invention also correspond to the computer program according to the invention, the data processing device according to the invention and the computer-readable storage medium according to the invention, respectively, and vice versa.

[0009] According to one aspect of the present invention, there is provided a method for providing a programmable logic controller with a migratable application program, wherein the method comprises the following steps:

[0010] -Converting the application program of the programmable logic controller into a general programming language;

[0011] - modifying the converted application program using the general purpose programming language so as to generate at least one access module to enable the converted application program to access at least one sensor and / or at least one actuator;

[0012] -compiling the modified application into a bytecode format in order to provide a portable application;

[0013] - executing the portable application and the application so as to provide output of the portable application and output of the application;

[0014] - based on a comparison of the output of the migratable application with the output of the application, verifying the migratable application to provide a verification result;

[0015] - providing the validated migratable application on the programmable logic controller, wherein the providing is dependent on the validation result.

[0016] Programmable logic controller (SPS) can be an industrial computer, which is suitable for controlling production processes, such as assembly lines, machines, robotic equipment or activities that require high reliability, simple programming and process fault diagnosis. The scope of SPS can include small modular devices with dozens of inputs and outputs (I / O) in a shell integrated with a processor and even large modular rack devices with thousands of I / O. The term "migratable" can refer to the possibility of migrating an application from one SPS to another SPS without having to make comprehensive specific changes, such as with respect to the hardware of the SPS for which the migratable application is intended. The application can be written according to the IEC 61131-3 standard, that is, written in one of the programming languages ​​defined therein. Universal language can be C or C++, for example. Within the scope of the present invention, access modules can also be referred to as input / output modules or I / O modules. Bytecode can be a form of instruction set designed for efficient execution by a software interpreter. Bytecode can include compact digital codes, constants and references, which encode the results of compiler analysis and semantic analysis of things such as the type, scope and nesting depth of program objects. The portable application may be executed on a programmable logic controller or, for example, on a runtime of an edge device. The latter case may be more desirable because the edge device may provide more additional computing power. The application is preferably executed on a programmable logic controller. The term "verification" may mean that an analysis is performed on the comparison of the output of the portable application with the output of the application, and the result may be the verification result. In simple terms, if the output of the portable application is the same as the output of the application or differs from each other only within a defined threshold, the verification result may be positive, which may indicate that the portable application is eligible to be provided on the programmable logic controller. Providing a verified portable application on a programmable logic controller may indicate that a verified portable application is used to replace the application and preferably has access to at least one sensor and / or at least one actuator assigned to the programmable logic controller. The statement that the provision depends on the verification result may mean that the provision can only be performed when the verification result is positive, which may be the case again when the output of the portable application and the output of the application are consistent or differ from each other only within a defined threshold. The portable application may be executed on another device, such as an edge device, after the provision. Thus, the method may be provided at least for the verification in a distributed environment having an industrial control device on which the programmable logic controller and the application may be provided and at least one edge device on which the migratable application may be executed.The above-described approach may be advantageous because the application may be modified, particularly by using a common language, and / or may be more easily migrated from one SPS to another.

[0017] In one example, the validated migratable application is provided on the programmable logic controller after an execution cycle of the programmable logic controller and within a time period that is shorter than a buffer time of the programmable logic controller. The execution cycle may consist of a time period indicating how long the application is executed and an additional buffer, the so-called buffer time. Providing within the buffer time may advantageously ensure that the functionality of the programmable logic controller is not limited or delayed by the provision.

[0018] It is possible that the at least one access module is generated to provide access to an industrial fieldbus, wherein access to the industrial fieldbus is provided by translating values ​​of the industrial fieldbus into messages for the migratable application and vice versa, so that the at least one sensor and / or the at least one actuator can be accessed by means of the industrial fieldbus. This can be advantageous because the at least one sensor and / or the at least one actuator is not accessed directly via the industrial fieldbus, but indirectly by means of messages to and from the migratable application.

[0019] In another example, the method further includes the following steps:

[0020] - generating a validator component to perform the validation, wherein the validator component is generated to read the output of the migratable application and the output of the application, wherein output suppression for the migratable application is initiated such that only the application writes values ​​to the industrial fieldbus.

[0021] If the method is implemented in a distributed environment, the verifier component can be provided on its own edge device, so as to advantageously reduce the computational requirements. The output suppression can advantageously ensure that the migratable application is verified before its actual use. Thus, in particular, the verifier component reads the output only when the output suppression is active. After verification, the output suppression can be deactivated.

[0022] In another example, the verification further includes the following steps:

[0023] - defining a threshold for a deviation of the output of the migratable application relative to the output of the application;

[0024] - comparing a current deviation of the output of the migratable application relative to the output of the application with a defined threshold value in order to provide the validation result.

[0025] If the current deviation is below a defined threshold, the verification result may be positive. The threshold may advantageously be defined according to specific requirements or implementation of the programmable logic controller. If no threshold is defined, the output of the migratable application and the output of the application may have to be the same in order for the verification result to be positive.

[0026] The method may further comprise the following steps:

[0027] - Initiating feedback, preferably to a user, wherein the feedback indicates a result of the verification.

[0028] The feedback may be output on a user interface, which may include a corresponding screen. Feedback to the user may be advantageous because the user may react accordingly to the result, for example by taking countermeasures or at least temporarily discarding the migratable application. The feedback may be provided on a user interface.

[0029] It is possible that the method further comprises the following steps:

[0030] - Initiating a state transfer between the application and the migratable application, wherein the initiation depends on the verification result, and wherein the state transfer includes: transferring at least internal variables used within the programmable logic controller and / or internal variables of at least one functional module used by the application.

[0031] If the verification result is negative, the state transfer can be initiated. This may be the case if the output of the migratable application is inconsistent with the output of the application or the deviation exceeds a defined threshold. The state transfer can indicate and advantageously ensure that the migratable application is consistent with the application. If the method is implemented in a distributed environment, the state transfer can be initiated by an orchestrator, which can be provided on the runtime of its own edge device. The orchestrator can be designed so that the orchestrator provides runtime modules or cancels the provision of these modules.

[0032] In another aspect of the invention, a computer program, in particular a computer program product, may be provided, the computer program comprising instructions which, when executed by a computer, cause the computer to perform the method according to the invention. Thus, the computer program according to the invention may have the same advantages as those described in detail with respect to the method according to the invention.

[0033] In another aspect of the invention, a data processing device can be provided, which is designed to perform the method according to the invention. As a device, for example, a computer can be provided, which executes a computer program according to the invention. The computer can have at least one processor, which can be used to execute the computer program. A non-volatile data memory can also be provided, in which the computer program can be stored and from which the computer program can be read by a processor in order to be executed.

[0034] According to another aspect of the present invention, a computer-readable storage medium may be provided, the computer-readable storage medium comprising a computer program and / or instructions according to the present invention, which instructions, when executed by a computer, cause the computer to perform the steps of the method according to the present invention. The storage medium may be designed as a data storage device, for example, as a hard disk and / or a non-volatile memory and / or a memory card and / or a solid-state drive (Solid-State-Drive). The storage medium may be integrated into the computer, for example.

[0035] Furthermore, the method according to the invention can be implemented as a computer-implemented method. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Other advantages, features and details of the present invention are apparent from the following description, in which embodiments of the present invention are described in detail with reference to the accompanying drawings. The features mentioned in the claims and in the description may reflect the essence of the invention individually or in any combination.

[0037] in:

[0038] Figure 1 Methods, computer programs, storage media and devices according to embodiments of the present invention are shown;

[0039] Figure 2 An SPS in a possible implementation environment according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0040] Figure 1 A computer program 20, a storage medium 15 and a device 10 according to an embodiment of the invention are shown.

[0041] Figure 1A method 100 for providing a programmable logic controller 1 with a portable application according to an embodiment of the present invention is also shown. In a first step 101 of the method 100, the application of the programmable logic controller 1 is converted into a general programming language. In a second step 102, the converted application is modified using the general programming language so as to generate at least one access module 11 so that the converted application can access at least one sensor 9 and / or at least one actuator 7. In a third step 103, the modified application is compiled into a bytecode format so as to provide a portable application. In a fourth step 104, the portable application and the application are executed so as to provide an output of the portable application and an output of the application. In a fifth step 105, the portable application is verified based on a comparison of the output of the portable application with the output of the application so as to provide a verification result. In a sixth step 106, the verified portable application is provided on the programmable logic controller 1, wherein the provision depends on the verification result.

[0042] Figure 2 The schematic diagram shows how SPS1 can be implemented in a distributed environment with edge devices 3 and industrial control devices 4. Figure 2 Implementation in .

[0043] One aspect of the present invention may be a method for converting SPS programs into virtualized SPS programs (vSPS1') that can be flexibly provided on edge devices 3 and use the computing power of edge devices 3. The motivation may be that SPS programs are closely tied to specific hardware and software by design, and it may not be easy to expand the functionality of these SPS programs given the limitations of current hardware and software.

[0044] In order to migrate control applications and the installed base available at customers into the ecosystem, and to provide existing customers with the advantages of a reliable distributed edge computing ecosystem, such as flexibility, modularity, reliability, and the use of COTS hardware, it may be important to provide a method for converting IEC 61131-3 applications into a general programming language and a method for executing these portable applications in a hardware- and operating system-independent manner. The method can achieve seamless migration of industrial control applications without rewriting IEC 61131-3 applications in a general programming language. In addition, the method can embed the transformed industrial control application into a runtime execution module 2 that is independent of the hardware and operating system by abstracting the I / O variables into general I / O communication concepts. The abstraction can achieve: eliminating the use of global I / O variables as the communication interface between I / O and IEC 61131-3 applications, and using more flexible communication paradigms, such as message transmission. Thus, the transformed and abstracted control application can be more flexibly and easily maintained and modularized and / or distributed on different edge devices 3.

[0045] The following method can be embedded in a distributed edge computing ecosystem. The ecosystem can include: edge devices 3, which are connected via TSN network switches / conventional Ethernet; and industrial automation devices 4, which can establish connections with sensors 9 and actuators 7.

[0046] A Runtime or runtime 2 can be installed on each of these edge devices 3, which can provide a secure, isolated sandbox execution environment, especially with integrated security checks, which can also manage the internal resource reservation of the edge device 3 and provide an abstraction of the operating system and hardware. In addition, channel probabilities can be provided to decouple the communication between runtime modules 2 from the underlying implementation. In addition, the runtime 2 can control whether the module is allowed to be published externally through the output suppression mode, which can provide the possibility of creating a passive hot standby module that receives inputs, processes these inputs but does not issue manipulation instructions. The runtime 2 itself may have the ability to execute modules compiled into bytecode, such as WebAssembly.

[0047] An orchestrator 12 may be required to provision and manage real-time execution modules (e.g., virtual SPS modules, i.e., migratable applications) on various runtimes 2 according to application requirements. In addition, the orchestrator may orchestrate the state transfer in such a way that the orchestrator triggers state extraction and state injection to ensure that no data loss occurs during the process of taking over control.

[0048] A verifier component 5 may be used in order to compare the output generated by the virtualized SPS module 1' and the original SPS module 1. This component may be generated during the translation process, as the component may depend on specific translated SPS control codes and their virtual translation.

[0049] In order to decouple access to the values ​​of sensors 9 and actuators 7 from the underlying industrial fieldbus 6, an access module 11 can be generated during the transformation process, which can also be called an I / O module 11. The access module 11 can implement access to I / O values ​​in runtime 2 communication.

[0050] In order to achieve stateful migration of the SPS application / SPS program to the virtual SPS1' on the edge device 3, the SPS1 may need to be equipped with an API that enables read access to the internal memory of the SPS runtime 2 used here. If such an API is not available and the SPS program has internal state (stateful application), the transformation can be performed, but the user 8 may need to accept the delta between the control values ​​generated by the SPS and the migrated virtual SPS1'. Stateless SPS programs can be transformed without the SPS memory access API.

[0051] This state transfer can be achieved through method calls to the memory access API. The memory access API can aggregate the internal memory state into a binary blob and then transmit the binary blob over TCP (client (orchestrator 12) / server (SPS1)) using protocol buffers or similar underlying messaging / RPC implementations.

[0052] The method is based, for example, on using available compilers to compile industrial control codes written, for example, in IEC 61131-3 into modern programming languages, such as C, C++ or Rust. The compiled or transformed industrial control code may include global variables based on primitive I / O variables that are used to read input values ​​and to send output values ​​to actuators 7 and other devices. These global variables can then be abstracted by generic communication concepts, for example by modifying the transformed industrial control code with function calls, callbacks, etc. An idea might be to convert the communication paradigm from shared-memory communication to a message-based mechanism that can be distributed for applications.

[0053] Once the industrial control application has been migrated in the manner described, the industrial control application can be embedded in a HW / OS-independent runtime execution module, called a vSPS1' module. The vSPS1' module can include glue code that implements the runtime model of the original SPS1 (task scheduling, etc.) and functions that may be important for implementing such a module in a reliable distributed edge ecosystem. These modules can then be compiled into a low-level binary instruction format for a stack-based virtual machine 7, such as WebAssembly. The use of this concept enables the execution of industrial control applications on arbitrary hardware (edge ​​device 3) isolated from the operating system.

[0054] The next step may be to compare the vSPS1' application (ie, the migratable application) with the original SPS program (ie, the application) for equivalence. For complex industrial control applications, the current state of the application may be extracted and added to the vSPS1' module, ie, the migratable application.

[0055] This can be done after starting the vSPS1' module, ie the migratable application, and initially runs in parallel with the original SPS program, ie the application.

[0056] Once the original SPS program (i.e., application) and the vSPS1' module (i.e., the migratable application) generate the same output, the orchestrator 3 can initiate a switch from the industrial control device 4 (e.g., SPS) to the vSPS1' module, which is executed in a reliable distributed edge computing ecosystem. To support this process, the method can have a validator component 5 that compares the outputs, I / O variables, and channel outputs and highlights possible differences to the operator.

[0057] In a first step, the industrial control application can be converted into a modern programming language, ie a general-purpose programming language such as C, C++ or Rust.

[0058] In the next step, access to inputs and outputs defined in header and C files may be replaced with a generic channel concept. In short, the channel concept may provide an abstraction for reading in sensor 9 inputs and writing actuator 7 outputs using the underlying message passing paradigm. Thus, the read-in and read-out values ​​of real sensors 9 and actuators 7 may be translated into the channel concept, which may be used between various runtime modules 2 and the virtual SPS module (vSPS1').

[0059] To achieve this, the method can generate a so-called access module 11 or I / O module 11, which can access the industrial fieldbus 6 (e.g. EtherCAT, PROFINET, ModBus) and translate the I / O values ​​into messages that can be sent via the channel. This module can be used on the edge device 3 that directly accesses the sensor 9 and the actuator 7. In order to achieve: the method can provide an API that can access the industrial fieldbus 6 that provides these values. Thus, the access to the I / O values ​​can be abstracted from the active query mechanism in that the values ​​are read in at the beginning of each control cycle of the push communication concept, i.e. channel read and channel write. In this way, the channel can receive any changes in the value and store the value so that the control application can be executed with the latest value.

[0060] Behind the channel concept, various communication methods can be used, such as publishing and subscribing communication stacks, so that the sender and the receiver are fully decoupled. However, if the vSPS1' module is directly executed on the node of the accessible sensor / actuator 7, the same concept may also be realized by utilizing the client-server communication protocol or shared memory. The second stage translator can use the translated C file and header file as input, and generate glue code for each IN, OUT and IN_OUT variable, so as to generate a theme and a corresponding channel in the I / O module 11. Once these modifications are realized about the header file and the I / O module 11 is generated, the translator can change the variable call in the C file to a corresponding channel call. The channel concept may need to be specific to the ID of each input and output variable, so that the input and output values ​​are correctly packaged and unpacked. Additionally, it may be necessary to replace the access to the variable (I / O variable) with channel access.

[0061] Once the I / O module 11 is generated and the vSPS1' module is modified using channel access, the method can generate a specific verifier component 5. Thus, the method can generate C code, which reads these channels from the I / O module 11, and the I / O module will write the output value / control value to the industrial field bus 6. In the first step, these channels can be marked using output suppression so that only the original SPS module writes the output value / control value to the industrial field bus 6. The generated verifier component 5 can be equipped with user-defined increments of different control values ​​so that the comparison part of the verifier component 5 can accept small differences in the control values ​​generated by the vSPS1' module compared to the original code. If the user 8 does not provide such increments for the control value / output value, the verifier component 5 can compare whether the outputs are the same, and only when the output / control values ​​of the two components are the same, these outputs are marked as "ok". The verifier component 5 can be equipped with a simple user interface (such as a screen output), which can give feedback to the user 8 once the vSPS1' module generates the same output or the difference in these outputs is less than a given increment.

[0062] Once the modification and translation of the C code is completed, the portable application, I / O module 11 and / or validator component 5 can be compiled into a low-level binary instruction format for a stack-based virtual machine, such as WebAssembly. By using this bytecode virtualization, it may be possible to achieve fast execution of the module and at the same time be independent of specific hardware and specific operating system.

[0063] In a next step, the compiled vSPS1' bytecode module may be provided via the orchestrator 12 on an available edge device 3 or on a different edge device 3, depending on the availability of the available edge nodes, the load, etc. The orchestrator 12 may ensure that the vSPS1' module is provided in a so-called non-write mode, i.e. with output suppression. This mode may prevent the output generated by the vSPS1' module from being written to the executors 7 via the I / O module 11. This non-write mode may be important, since otherwise the portable application may modify these executors 7 while the application may still be executing on the SPS.

[0064] Once the portable application is provided and the output (O VSPS ), the generated validator component 5 can start to output O VSPS With the application O SPSAs described above, the user 8 may optionally define increments for different control values / output values ​​generated by the vSPS1' module (i.e., the migratable application). Thus, the validator component 5 may define a difference less than the increment as positive, and the validation may pass. Based on the result of the validation, the solution for the next step can be implemented.

[0065] If there is a difference (if an increment is provided, the difference is greater than the indicated increment), this can indicate that there may be different internal states of the functions and modules used between the SPS module (i.e., application) and the virtualized SPS module (i.e., migratable application). In order to solve the increment in the output, the verifier component 5 can initiate the state transfer between the original SPS program (i.e., application) and the virtualized SPS module (i.e., migratable application). Extracting the state, transmitting the value and writing these values ​​to the bytecode virtualized memory may need to be performed within an execution cycle of the original SPS module, such as 2ms or longer, depending on the execution cycle. The state can have not only the internal variables used in the SPS module but also the internal variables of the functional modules used. In the case of an internal PID (proportional integral differential) control loop, this can be, for example, an integral, a derivative or a process variable. Such internal variables can be extracted by the available memory access API provided by the SPS. The transfer can be performed via the arranger 12 and with the highest priority in the network.

[0066] Then, these values ​​can be written back to the low-level binary format memory. Depending on the technology used, if WebAssembly is used to implement the runtime 2 and the execution module, the exported function can be implemented by WebAssembly or a special Web-API. However, the orchestrator 12 must ensure that the state transfer can be realized within the cycle buffer time in any case. The execution cycle can be 10ms. The SPS program, i.e., the time required for the application to execute the logic and calculate these outputs can be 5ms. Then, the cycle buffer time can be calculated. If there are more CPU reservations, available memory, etc. for the runtime 2 involved, the orchestrator 12 can make the state transfer priority by temporarily modifying the resource allocation. In any case, only when the time to extract the state, the transmission time between the SPS and the vSPS1' (i.e., between the application and the migratable application) and the time to write the value to the vSPS1' module are less than the execution cycle or the cycle buffer time, the state transfer can be initiated.

[0067] If there are no differences between the results generated by the vSPS1' module and the original SPS, i.e., there are no differences between the application and the migratable application, or the incremental comparison between the results is within specified limits, the orchestrator 12 can trigger the last step, i.e., step 8. If there are still differences in the output, the validator component 5 can trigger an error message that triggers further diagnosis by the user 8 regarding other inconsistencies in the vSPS1' module.

[0068] The validator component 5 can highlight through a small user interface that the two modules generate the same output / control value. The user 8 can initiate or approve the switch by interacting with the validator component 5. Based on this input, the validator component can send a switch instruction to the orchestrator 12. The orchestrator 12 can wait until the end of the execution cycle, and then initiate the shutdown of the SPS, and at the same time switch the execution runtime 2 module to write mode, thereby deactivating the suppression mode. This may mean that the output generated by the execution runtime 2 module is now published to the executor 7 via a channel. The translation of the classic SPS program to the virtualized vSPS1 execution runtime environment 2 module that is independent of the operating system and HW has been performed.

[0069] The above description of the embodiments describes the present invention based on examples. Of course, as long as it is technically reasonable, the various features of these embodiments can be freely combined with each other without departing from the protection scope of the present invention.

Claims

1. A method (100) for providing a programmable logic controller (1) with a portable application, the method comprising the following steps: - converting (101) the application program of the programmable logic controller (1) into a universal programming language; - modifying (102) the converted application program using the universal programming language in order to generate at least one access module (11) so that the converted application program can access at least one sensor (9) and / or at least one actuator (7); - compiling (103) the modified application into a bytecode format so as to provide the portable application; - executing (104) the migratable application and the application so as to provide an output of the migratable application and an output of the application; - validating (105) the migratable application based on a comparison of the output of the migratable application with the output of the application so as to provide a validation result; - providing (106) the verified migratable application on the programmable logic controller (1), wherein the providing is dependent on the verification result.

2. The method (100) according to claim 1, characterized in that: The provision of the verified migratable application on the programmable logic controller (1) is performed after an execution cycle of the programmable logic controller (1) and within a time period shorter than a buffer time of the programmable logic controller (1).

3. The method (100) according to any one of the preceding claims, characterized in that The at least one access module is generated to provide access to an industrial field bus (6), wherein access to the industrial field bus (6) is provided by translating values ​​of the industrial field bus (6) into messages for the migratable application and vice versa, so that the at least one sensor and / or the at least one actuator can be accessed with the aid of the industrial field bus (6).

4. The method (100) according to claim 3, characterized in that: The method (100) further comprises the following steps: - generating a validator component (5) to perform the validation, wherein the validator component (5) is generated to read the output of the migratable application and the output of the application, wherein output suppression for the migratable application is initiated so that only the application writes values ​​to the industrial fieldbus (6).

5. The method (100) according to any one of the preceding claims, characterized in that The migration (105) further comprises the following steps: - defining a threshold value for a deviation of the output of the migratable application relative to the output of the application; - comparing a current deviation of the output of the migratable application relative to the output of the application with a defined threshold value in order to provide the validation result.

6. The method (100) according to any one of the preceding claims, characterized in that The method (100) further comprises the following steps: - initiating feedback, wherein the feedback indicates a result of the verification.

7. The method (100) according to any one of the preceding claims, characterized in that The method (100) further comprises the following steps: - Initiating a state transfer between the application and the migratable application, wherein the initiation depends on the verification result, and wherein the state transfer includes: transferring at least variables used internally within the programmable logic controller (1) and / or internal variables of at least one functional module used by the application.

8. A computer program (20) comprising instructions which, when the computer program (20) is executed by a computer (10), cause the computer (10) to perform the method (100) according to any one of the preceding claims.

9. A data processing device (10) comprising means for executing the method (100) according to any one of claims 1 to 7.

10. A computer-readable storage medium (15), comprising instructions which, when executed by a computer (10), cause the computer (10) to perform the steps of the method (100) according to any one of claims 1 to 7.

Images