Arrangement and method for operating an industrial application with a virtual industrial assembly

Abstract

The invention describes an arrangement and a method by means of which an industrial application (AW) on PLC hardware communicates with a virtual industrial assembly (BGR) via an application interface (RWB-IF) of a driver for a deterministic hardware interface (for example a real-time-capable industrial rear panel bus). For the AW, an adapted driver (RQB / TCP or RQB / SHM / ETH) is installed on the PLC (S-PLC / V-PLC) and translates the accesses by the AW into a real-time-capable communication method. The virtual BGR is installed on a (different) hardware unit (S-PER / VM-PER / V-PER) and there, likewise has an adapted driver, which is connected to the driver of the AW via the same real-time communication method. In this way accesses from both sides can take place bidirectionally and deterministically via the real time protocol.

Description

[0001] 202416982 Foreign version

[0002] 1

[0003] Description

[0004] Arrangement and method for operating an industrial application with a virtual industrial assembly

[0005] The invention relates to an arrangement for operating an industrial application with a virtual industrial assembly according to the preamble of claim 1, and a method for operating an industrial application with a virtual industrial assembly according to the preamble of claim 5.

[0006] In automation environments, the method of virtual commissioning is increasingly used, particularly in the area of ​​virtual or simulated programmable logic controllers (PLCs) and their applications (e.g., automation programs). However, this method can only simulate the execution of the PLC program itself, but not the central peripherals connected to the PLC, such as communication processors, through which the PLC can establish further communication connections, including additional features like a firewall, which the PLC itself cannot provide.

[0007] Central peripherals, in this context, refer to expansion modules directly connected to a controller, as opposed to peripherals connected via a fieldbus system or other data interfaces such as Ethernet (distributed peripherals). Central peripherals specifically include modules that, along with a controller (PLC), are plugged into a backplane bus of a module holder, called a rack, and communicate with all other bus participants via this bus. This also includes modules installed in a remote shelf. 1The backplane bus is used, with the first-mentioned backplane bus and the backplane bus of the extension being connected via a deterministic, high-performance data connection in such a way that a unified, real-time capable bus system results, and modules of both parts communicate with each other as if they were plugged in side by side. Such backplane bus systems are high-performance, deterministic (i.e., predictable, constant, and therefore real-time capable, especially with regard to their temporal transmission parameters), and offer further advantages such as plug-and-play capability and, through their own arbiter (bus management unit), sometimes also independent address management.

[0008] In the area of ​​virtual or simulated programmable logic controllers (PLCs) and their applications, so-called technology modules are also not available, i.e., 202416982 foreign version

[0009] 2

[0010] Expansion modules for a central peripheral or backplane bus system provide higher-level functions, ranging from fast counters to PLC neural networks. Furthermore, no I / O modules can be connected, meaning that data subsequently provided or received by the central or distributed peripheral must also be simulated using additional tools and programs.

[0011] In real-world PLC operation, the aforementioned connection partners are generally connected to a deterministic hardware interface, meaning one whose temporal behavior is defined, and in particular, a "real-time" capable interface, specifically a preferably locally connected backplane bus (system). However, such a backplane bus is not available in a simulated or virtualized environment, neither for the controller (PLC) nor for any potentially simulated or virtualized peripherals. This is desirable, however, in order to test or virtually commission virtual or simulated controllers / PLCs and / or the virtualized or simulated peripherals, even if the real devices do not yet exist or are (initially) only intended to be operated in their virtualized form in conjunction with other virtual or real components.

[0012] Therefore, the PLC configuration and possibly also the program (i.e., the application) must be adapted because the connected hardware is not available during virtual commissioning, meaning that 100% coverage of functionality for testing or similar purposes cannot be achieved. If the PLC is later commissioned on the actual plant, some parts that are essential for real-time behavior will still be untested and will delay acceptance.

[0013] The publication DE 102013 100465 A1 - Werfeli “Microprocessor-controlled control unit for an injection molding plant” shows the optional connection of real or simulated I / O modules to an industrial control unit by means of an external switching device.

[0014] The publication US 2022 / 019205 A1 - Nixon et al. “INDUSTRIAL CONTROL SYSTEM ARCHITECTURE FOR REAL-TIME SIMULATION AND PROCESS CONTROL” describes a switch called an I / O switch for switching between a virtual and a real automation environment at a control device. 202416982 Foreign version

[0015] 3

[0016] The publication EP 2 498 156 A2 - Maturana et al. “Industrial simulation using redirected I / O module configurations” mapped virtual or simulated I / O data directly into the process image of an industrial control system.

[0017] The trend towards increased information technology (IT) in operational technology (OT) has given rise to a new type of PLC: the aforementioned virtual controllers. Similar to simulated PLCs used in virtual commissioning, these operate as a purely software-based solution without dedicated hardware. However, unlike simulations, they are fully deterministic, meaning they are capable of real-time operation. Virtual PLCs also typically feature a fieldbus interface, allowing them to connect to real, distributed I / O.

[0018] However, the problem remains that there is no possibility of expansion with central peripheral components (primarily communication processors and so-called technology modules, e.g., neural coprocessors). Therefore, not all customer projects can be implemented with the virtual controller.

[0019] As a concrete example, consider a request from a specific customer project where the PLC with added communication modules is to be commissioned virtually. Currently, there is no satisfactory solution known for connecting a central peripheral (real or simulated) to a simulated or virtual controller.

[0020] In a classic simulation, the PLC's I / O area is made available as an accessible memory area, allowing external tools to write (meaningful) values ​​to it. A strict temporal correlation to the PLC program is not guaranteed.

[0021] With virtual control, even this possibility is eliminated, so that only decentralized peripherals can be used, which are usually less performantly connected to the PLC.

[0022] The use of additional communication processors to split network traffic across different lines with different content is not possible with either variant.

[0023] The current solution therefore necessarily requires adjustments to both the PLC configuration and the PLC program, because neither the connected hardware nor additional communication links are available during virtual commissioning. In some cases, the central PLC components are "simulated" during simulation, i.e., with regard to 202416982 foreign version

[0024] 4 of its interfaces are emulated, so that the peripherals are present as a so-called "dummy", but cannot provide any meaningful data during operation.

[0025] This creates additional effort, and the results of virtual commissioning only partially reflect the real system. Therefore, not all projects currently possible with a physical controller can be implemented using a virtual PLC, as the virtual PLC cannot be extended with certain central modules that cannot be meaningfully operated on a decentralized periphery, primarily additive communication modules.

[0026] A PLC, regardless of the manufacturer, basically consists of the following four logical units:

[0027] 1. Control core: In this core, the user-written program runs according to the user's specifications regarding timing behavior, e.g., a specific function is called cyclically every 10 milliseconds.

[0028] 2. Asynchronous communication: This is how the PLC exchanges data with other (non-I / O) devices or computer environments. Higher-level protocols such as HTTP or OPC UA are used. This communication has no defined timing behavior.

[0029] 3. Connection for distributed I / O: This interface, also known as a fieldbus, communicates with I / O modules. Data exchange typically occurs using a cyclic protocol (e.g., Profinet, EtherCAT). The communication has a clearly defined timing behavior.

[0030] 4. Connection for central peripherals: This interface usually does not have a general physical layer (ISO Layer 1-2, e.g., Ethernet), but rather a manufacturer-specific connector. The timing behavior is unambiguous, and data exchange is cyclical. Since the connection is at least partially located on the back of the PLC, this interface is also referred to as a backplane bus (RWB).

[0031] Figure 1 (state of the art) illustrates this. It depicts a PLC controller that initially includes communication means (COM) for non-deterministic communication, for example, HTTP, OPC UA, etc. An application or user program (AW) represents the 202416982 foreign version

[0032] 5

[0033] The control core operates with IO-D data. The PLC controller includes connections for both distributed I / O (DP) and centralized I / O (ZP).

[0034] In both the simulated and the virtual PLC, the software component for the aforementioned fourth unit—essentially the driver for the backplane bus (RWB), which establishes the connection to the central peripheral modules—is deactivated because the corresponding hardware component must also be present for its operation. As already mentioned, the backplane bus is characterized primarily by its deterministic operation, thus transporting the data from the peripheral modules within a defined timeframe.

[0035] It is therefore an object of the present invention to provide an arrangement and a method by which a virtualized or simulated industrial application can be operated with a central periphery without modifications.

[0036] A key idea of ​​the inventive solution to this problem is to replace the lowest, and therefore hardware-dependent, layers of this RWB software, i.e., the driver, with a variant that relies on means for further communication that are present in the environment of the simulated or virtual PLC. These means therefore come from the IT world and not from the OT world.

[0037] The problem is solved in particular by the features of independent patent claims.

[0038] This proposal proposes an arrangement for operating an industrial application with a virtual industrial assembly. The industrial application is installed on a hardware unit and is configured to interact with an application interface of a driver for a deterministic hardware interface, specifically a real-time industrial backplane bus, and thus a backplane bus interface for accessing an industrial assembly, particularly an expansion module for the backplane bus. A customized driver with the application interface is configured on the hardware unit for the application. This customized driver is configured to translate the industrial application's access to the industrial assembly into a real-time communication method, and vice versa.For this purpose, the virtual industrial assembly is also designed to interact with a similar application interface of the driver for the deterministic hardware interface, wherein the virtual industrial assembly is installed for operation on the or another hardware unit, wherein on this hardware unit to 202416982 foreign version.

[0039] 6. The virtual industrial assembly has one or another adapted driver installed with the application interface, and this adapted driver is configured to translate the application's access to the virtual industrial assembly via its adapted driver and the real-time communication method, and vice versa. For this purpose, the adapted drivers are interconnected via a communication means according to the real-time communication method. This arrangement makes it possible to operate the virtualized or simulated application without any changes compared to direct operation with a central peripheral, particularly for testing purposes or in cases where the central peripheral is not yet physically available.

[0040] The problem is solved by a method for operating an industrial application with a virtual industrial assembly, wherein the industrial application is installed on a hardware unit for execution, and wherein the industrial application is configured to interact with an application interface of a driver for a deterministic hardware interface, in particular with a real-time capable industrial backplane bus, for accessing an industrial assembly, especially an expansion module. A customized driver with the application interface is configured on the hardware unit for the application, wherein the customized driver is configured to translate the accesses of the industrial application to the industrial assembly into a real-time capable communication method, and vice versa.The virtual industrial assembly is also designed to interact with the application interface of the driver for the deterministic hardware interface. The virtual industrial assembly is installed on the virtual or another hardware unit. On this hardware unit, a customized driver with the application interface is installed for the virtual industrial assembly. This customized driver is configured to translate application accesses to the virtual industrial assembly via its customized driver and the real-time communication method, and vice versa. The customized drivers communicate with each other via a communication medium according to the real-time communication method. This method allows the advantages already discussed in relation to the arrangement to be achieved.

[0041] Advantageous embodiments of the arrangement and method according to the invention are specified in the dependent claims. The embodiments of the method can also be applied analogously to the arrangement, and vice versa. 202416982 Foreign version

[0042] 7

[0043] The design features can be implemented individually or in meaningful combinations.

[0044] The application and the virtual industrial assembly are advantageously installed in separate virtual machines on a shared hardware unit, with shared memory of the hardware unit serving as the communication medium. This ensures secure and deterministic communication. Furthermore, the virtual machines can emulate a real-world operating environment, allowing both the application and the virtualized assembly to be tested under realistic conditions. This virtualization can also be container virtualization.

[0045] Furthermore, it is advantageous to install the application and the virtual industrial assembly on different hardware units, using a data network as the communication medium and employing a communication method with Time-Sensitive Networking (TSN) mechanisms. For this purpose, it is advantageous to define a virtual Ethernet on the local communication medium, such as shared memory, allowing all participants to be uniquely addressed. This also makes it possible to use a physical Ethernet for the "extended connection" to other computing nodes and to ensure its determinism with TSN mechanisms. Thus, for performance reasons, but also for organizational simplification, the computing load can be distributed across different nodes and even locations.

[0046] A particularly realistic system test is possible if the application is installed in a simulated programmable logic controller and if the virtual industrial assembly is designed to simulate a real assembly.

[0047] Virtual commissioning can be comprehensively tested and carried out by connecting an arrangement, in particular a computer with a simulation program, to the virtual industrial assembly to simulate an industrial production facility or an industrial process, wherein the virtual industrial assembly is set up to provide simulated input and output ports (“lOs”) and the simulation program is set up to provide and receive simulated input and output signals.

[0048] Exemplary embodiments of the arrangement according to the invention are explained below with reference to the drawings. This also serves to explain the invention (202416982 foreign version).

[0049] 8

[0050] Procedure. It is particularly pointed out that hybrid forms of the exemplary embodiments can also be realized and, in particular, that the different configurations in the exemplary embodiments can be combined with one another and thus interact.

[0051] This shows:

[0052] Figure 1 shows the relationships between the units of a classical industrial control system (state of the art) that have already been discussed.

[0053] Figure 2 shows the separation of the rear wall bus stack according to the invention,

[0054] Figure 3 shows a (virtual) network in a computer with a simulated controller and a simulated peripheral,

[0055] Figure 4 shows the coupling of a virtual controller with a virtual peripheral.

[0056] Figure 5 shows access control for multiple virtual peripheral assemblies using an arbiter, and

[0057] Figure 6 shows the extension to a continuous determinism in a computing cluster.

[0058] The following discussion assumes an architecture according to the state of the art, which is shown in Figure 1 and has already been explained previously.

[0059] Figure 2 illustrates the backplane bus stack separation according to the invention. In the following, this will also be referred to simply as "driver separation" because, according to the invention, a driver or driver software is provided which, from the perspective of a (simulated or virtualized) application or assembly, behaves and communicates like a real backplane bus or a real deterministic hardware interface at the "application API," but does not communicate at its "transport API" with a real (hardware) assembly of the same backplane bus or the same real deterministic hardware interface (generally: of transport layer 2 in the ISO / OSI model). Instead, it forwards the corresponding IO-D data (often input and output signals of industrial components, also called I / O data) to another deterministic communication (shared-memory-based communication, TSN-based communication, 202416982 foreign version).

[0060] 9

[0061] Real-time data streams or similar) and vice versa. Preferably, this "backend" is connected to a similar, split backplane bus stack with a real, simulated, or virtualized assembly, controller, or technology module. Alternatively, the "backend" can also interact directly with and exchange data with a communication partner that is not designed for the use of a backplane bus architecture, which can particularly apply to virtualized or simulated components.

[0062] Figure 2 illustrates the procedure for the case of the simulated S-PLC controller. The backplane bus (RWB) of the Siemens Simatic S7-1500 is used as an example, but the principle applies analogously to any PLC from any manufacturer. An industrial application, AW, is based on the backplane bus interface RWB-IF. The architecture stack (shown here as driver TR) of the RWB software is split at the transition level to OSI Layer 2 (called "MASP-IF" in the S-1500's RWB) and the telegrams are converted into a converter that transforms the "request block" (RQB) paradigm into stream-oriented communication, which is advantageously implemented using a TCP connection. Of course, there is also a conversion in the reverse direction. For the simulated PLC, the non-deterministic TCP communication is perfectly adequate, since the simulated PLC also operates non-deterministically.

[0063] The peripheral assembly (not shown in Figure 2), as its counterpart (e.g., communication processor), also contains modified RWB software. This case is shown in Figure 3. In the case of simulated peripherals (S-PER), this counterpart can run as another (Windows) process on the same computer. Due to the TCP connection—shown here as a network (NW) or virtual network (V-NW)—offloading to a virtual machine (VM) or another computer is even possible.

[0064] This option is advantageous if the BGR module, which is to be simulated alongside the PLC controller, requires more computing power, for example to calculate a neural network.

[0065] Figure 3 shows the overall configuration in which a simulated S-PLC controller communicates with one or more BGR peripheral modules via the method provided for this purpose, namely the backplane bus, which supports the virtualized network connection NW / V-NW. The design of the controller or the AW application must be [202416982 Foreign Version].

[0066] 10 can therefore no longer be changed, as it can now be operated entirely in a virtualized or simulated environment. Furthermore, during commissioning, the S-PLC controller can load the respective sub-projects into the peripheral modules via backplane bus communication, as usual.

[0067] If the peripheral software is compatible with a general-purpose operating system (e.g., Windows), it, along with the S-PLC controller, can run as a single process within that operating system (e.g., a Windows process). If not, a virtual machine is a suitable option, allowing the peripheral software, including its own operating system (e.g., Linux), to run virtually unchanged.

[0068] In the aforementioned customer project, as an example, in addition to the simulated S-PLC control, the communication via one or more communication processors as central peripherals could also be tested unchanged during virtual commissioning.

[0069] Figure 4 illustrates the use case of a virtual or virtualized controller, V-PLC. With the virtual controller V-PLC, backplane bus communication can only be implemented to a limited extent via a TCP connection, as determinism must be maintained. However, the basic principle of separating the backplane bus software can be adopted unchanged.

[0070] The virtual controller V-PLC itself does not run as a Windows process, but as a virtual machine (VM) or as a (Docker) container in a larger computing system, which is referred to below as the host. This host, usually a correspondingly large server or even a cluster of several servers, therefore offers more options than a Windows computer.

[0071] A shared-memory SHM (Software-Based Management) is a suitable basis for deterministic communication. This is a portion of main memory that multiple instances (processes, virtual machines, containers) can access. Data transfer is therefore immediate, as this type of connection corresponds to Layer 2 in the OSI model of general communication. A shared-memory SHM thus directly replaces the modified portion of the backplane bus software, since the hardware dependency exists at Layer 2.

[0072] To simplify the handling of the SHM, it is advantageous to use the mechanism of a virtual Ethernet interface ETH (also Layer 2). Each participant of the 202416982 foreign version

[0073] 11

[0074] Communication is automatically assigned a unique address (MAC address), allowing data delivery in the form of a Request-Quick Block (RQB). This will be explained in more detail in the following section, specifically with regard to maintaining the determinism of the communication.

[0075] Figure 4 illustrates communication within a host computer / server based on shared-memory SHM or the virtual Ethernet (ETH) built upon it. The latter also increases deployment flexibility, as individual instances and the virtual PLC (V-PLC) can run as either virtual machines or containers. Both constructs generally utilize virtual Ethernet (V-ETH) for communication (see Figure 6), eliminating the need for any additional host-side measures to provide the alternative Layer 2 (L2-V) or virtual Layer 2 (V-L2-V) connections (L2-V or V-L2-V within the server).

[0076] In principle, the solution can also be used on the host via a TCP connection instead of shared memory / Ethernet SHM / ETH. While this means determinism is no longer strictly guaranteed, it allows the virtual modules to be offloaded to other host machines within the same HCI cluster (Hyperconverged Infrastructure).

[0077] Conversely, in the case of simulated S-PLC control, pure Layer 2 communication can be established on the existing virtual Ethernet instead of a TCP connection. This allows the adapter to remain identical for both described use cases. However, fully deterministic behavior cannot be achieved with simulated S-PLC control, as the systems involved themselves do not operate deterministically.

[0078] In addition to peripheral BGR modules with fixed functions and therefore known firmware, such as communication processors or technology modules, this method can also be used to create a freely programmable module in which both in-house developers and customers can run their own software with close coupling to the S-PLC controller.

[0079] The determinism of the backplane bus relies on two essential mechanisms, which the adapter or driver TR according to the invention must also implement:

[0080] 1. Request Block Mechanism (RQB): 202416982 Foreign Version

[0081] 12

[0082] This method ensures flow control for applications running on the bus. Applications must provide the bus software with dedicated data areas (request blocks) into which incoming telegrams are copied. If no block is available, the telegram is discarded and does not reach the application. This prevents overloading of the application and thus the system, as the bus software does not allocate memory, which can reach its limits under excessive load.

[0083] A standard TCP connection in the IT world does not have this mechanism, so a DoS (Denial-of-Service) attack could push a system to its (memory) limit.

[0084] 2. Access Control:

[0085] Since the backplane bus is traditionally a shared media that all connected participants can access equally, it must be ensured that conflicts are either detected and resolved or avoided from the outset.

[0086] In the case of the backplane bus, a so-called arbiter (ARB) – see Figures 5 and 6 – manages the allocation of access rights. If a module wants to send a telegram to another, it requests access from the arbiter and receives it immediately or with a delay, depending on the arbiter's strategy (grant). Simultaneously, this allows the addressed module to send a (single) reply telegram.

[0087] Since both the maximum length of the telegrams and the transmission speed are known, the time for a single data communication can be precisely determined. If the number of initiators of a communication is also taken into account, the maximum waiting time until a specific initiator gains bus access can be calculated. This results in determinism.

[0088] Shared Memory Management (SHM) is also a shared medium, so access control is necessary to minimize or even eliminate conflicts. Using a virtual Ethernet mechanism based on the SHM is advantageous in this regard. This mechanism divides the SHM into defined areas and assigns each participant a specific access level.

[0089] 13 unique addresses (MAC address, Media Access Control address) by which each participant can be specifically addressed.

[0090] This is also the case with the backplane bus, except that it dynamically assigns addresses upon power-up according to the bus sequence. The adapter must therefore offer the option of a user-configurable address, as only the user knows the sequence or can determine it from the PLC configuration.

[0091] The advantage of using virtual Ethernet is that the MAC address is assigned via software, unlike hardware Ethernet where it is hard-coded in the network card. To simplify later diagnostics, the MAC addresses are assigned such that the first five digits are fixed, while the last digit, as with the backplane bus, corresponds to the slot. This allows the RWB software to handle this last digit in exactly the same way as dynamically assigned addresses.

[0092] Furthermore, the adapter also emulates the behavior of the arbiter to implement a controlled access mechanism. Since conflicts on the shared media of the virtual Ethernet are thus eliminated, the above statement regarding determinism remains fully valid. As with the hardware arbiter of the backplane bus, various strategies are possible in the implementation according to the invention, for example, all participants have equal rights or the PLC always has priority.

[0093] Figure 5 illustrates access control for multiple virtual peripheral modules. The Request Block Interface (RQB) of the adapter to the applications (AW) ensures, firstly, that memory consumption cannot increase exorbitantly. Secondly, the entire memory can be allocated in advance, thus avoiding unplanned latencies caused by dynamic memory requests.

[0094] To achieve the determinism of the virtual backplane bus coupling, the deployment of the individual virtual modules (PLC, peripherals, ...) can be restricted insofar as all participants belonging to a system must be installed and run on one and the same host system (hereinafter also referred to as hardware unit).

[0095] However, this can also be achieved in a computer cluster (HCl - Hyper-Converged Infrastructure) by using additional technologies. This is shown in Figure 6. Between the individual hosts CLR1, CLR2 (cluster computer 1, cluster computer 2) in a cluster 202416982 Foreign version

[0096] 14. Typically, high-bandwidth physical Ethernet connections P-ETH exist. However, this alone is not sufficient, as the latency of the connection is the more relevant constraint in the described use case.

[0097] However, if the connection between the computers of a cluster is implemented with TSN (Time Sensitive Network) at Layer 2, including all network components (switches) TSN-SW ("TSN- Switch"), the latencies of the communication between two virtual machines on different host computers can be both defined and guaranteed.

[0098] This restores determinism and, similar to the simulated assemblies, allows distribution across multiple compute nodes to increase the performance of the virtual PLC system, including virtual peripherals (vPLC system). Figure 6 illustrates this concept. The left cluster computer, CLR1, runs both the virtual controller vPLC and some peripherals, while the second cluster computer, CLR2, runs only virtual peripherals VM / PER (virtual machine - virtual peripheral). Crucially, within the virtual cluster vPLC-S (virtual control system) of these virtual instances, only one arbiter (operating on the virtual controller vPLC) is active at any given time to ensure determinism.

[0099] This concept can also include more than two cluster computers per virtual control system VPLC-S, since the latency between all nodes is guaranteed via the TSN switch TSN-SW.

[0100] Furthermore, by defining multiple individual TSN channels (streams), several vPLC systems (virtual PLCs and virtual peripherals distributed across the compute nodes) can run in parallel within a cluster. This allows for arbitrary scalability within an HCI cluster.

[0101] The two versions of the invention for the simulated and virtual PLC offer several advantages:

[0102] • The virtual backplane bus replicates both the known functionality and the required and necessary determinism of the real backplane bus.

[0103] No changes to the PLC design or the PLC program are necessary to perform a virtual commissioning of the created automation solution, including all foreign versions.

[0104] to carry out 15 central assemblies.

[0105] • The coverage of the tested solution thus increases to 100% and reflects the behavior of the real solution accordingly.

[0106] • A manufacturer of industrial control systems can provide additional modules for simulation alongside the simulated PLC (e.g., virtual communication processors or neural network modules) so that customers can perform a full virtual commissioning.

[0107] • A manufacturer of industrial control systems can offer additional modules for virtual operation as purchasable products alongside the virtual PLC, enabling customers to implement their automation projects in all aspects as usual. The virtual counterparts of the real modules can even be more powerful, since the virtual representation runs on faster hardware.

[0108] • New modules, including their firmware, can be developed and tested before the corresponding hardware is available. This can initially be done purely functionally with the simulated PLC and later even including the correct timing behavior with the virtual PLC.

[0109] • For this purpose, a virtual assembly (virtual machine or container) similar to the technology modules available today as hardware (e.g., neural processors) is used. This contains a freely programmable Linux distribution and also establishes a connection to the real backplane bus.

[0110] • The system consisting of a virtual PLC and associated virtual peripherals can also be distributed across multiple computers using deterministic Ethernet (advantageously TSN) to further increase performance.

[0111] • The concept of an open ecosystem is expanded by allowing various providers to develop and offer their own virtual assemblies for different tasks as the central periphery of the virtual controller. 202416982 Foreign version

[0112] 16

[0113] The customer problem cited as an example can be solved with this invention not only for the case of a simulated PLC, but can also be implemented with a virtual PLC and corresponding virtual communication processors for subsequent operation. Both simulated and virtual controllers are already available on the market, but none of them support central expansion modules. The invention covers both the loosely coupled approach in the case of the simulated PLC and the strictly deterministic approach of the virtual PLC.

Claims

202416982 Foreign version 17 Patent claims 1. Arrangement comprising an industrial application (AW), a hardware unit (PLC), and a virtual industrial assembly (V-PLC), wherein the industrial application (AW) is installed for execution on the hardware unit (PLC), and wherein the industrial application (AW) is configured to interact with an application interface (RWB-IF) of a driver for a deterministic hardware interface of a communication processor or a technology module as a central peripheral assembly (V-PLC), in particular a neural coprocessor, characterized in that a customized driver (RQB / TCP; RQB / SHM / ETH) with the application interface (RWB-IF) is configured for the application (AW) on the hardware unit (S-PLC; V-PLC), wherein the customized driver (RQB / TCP;RQB / SHM / ETH) is configured to translate the industrial application's (AW) access to the industrial assembly (BGR) into a real-time communication method, and conversely, that the virtual industrial assembly (BGR) is also designed to interact with the application interface (RWB-IF) of the driver for the deterministic hardware interface, that the virtual industrial assembly (BGR) is installed for execution on the or another hardware unit (S-PER; VM / PER; V-PER), wherein on this hardware unit (S-PER; VM / PER; V-PER) the or another adapted driver with the application interface (RWB-IF) is installed for the virtual industrial assembly (BGR), wherein this adapted driver (RQB / TCP; RQB / SHM / ETH) is used to translate the application's (AW) access via its adapted driver (RQB / TCP; RQB / SHM / ETH) and the real-time communication method is set up for the virtual industrial assembly (BGR), and vice versa, wherein the adapted drivers (RQB / TCP; RQB / SHM / ETH) are connected to each other via a communication means according to the real-time communication method. 202416982 Foreign version 18 2. Arrangement according to claim 1, characterized in that the application (AW) and the virtual industrial assembly (BGR) are each installed in a virtual machine (VM) of a common hardware unit, wherein a shared memory (SHM) of the hardware unit is set up as the communication means.

3. Arrangement according to claim 1, characterized in that the application (AW) and the virtual industrial assembly (BGR) are installed on different hardware units, wherein a data network (NW; V-NW; TSN-SW) is provided as the communication means and wherein a communication method with Time-Sensitive Networking (TSN) mechanisms is provided as the real-time capable communication method.

4. Arrangement according to one of the preceding claims, characterized in that the application (AW) is installed in a simulated programmable logic controller (S-PLC) as the hardware unit and that the virtual industrial assembly (BGR) is designed to simulate a real assembly (BGR). 202416982 Foreign version 19 5. Method for operating an industrial application (AW) with a virtual industrial assembly, wherein the industrial application (AW) is installed for execution on a hardware unit, and wherein the industrial application (AW) is configured to interact with an application interface (RWB-IF) of a driver for a deterministic hardware interface of a communication processor or a technology module as a central peripheral assembly (CME), in particular a neural coprocessor, characterized in that a customized driver (RQB / TCP; RQB / SHM / ETH) with the application interface (RWB-IF) is configured for the application (AW) on the hardware unit, wherein the customized driver (RQB / TCP;RQB / SHM / ETH) is configured to translate the industrial application's (AW) access to the industrial assembly into a real-time communication method, and conversely, that the virtual industrial assembly is also designed to interact with the application interface (RWB-IF) of the driver for the deterministic hardware interface, that the virtual industrial assembly is installed for execution on the or another hardware unit, wherein on this hardware unit the or another adapted driver (RQB / TCP; RQB / SHM / ETH) with the application interface (RWB-IF) is installed for the virtual industrial assembly, wherein this adapted driver (RQB / TCP; RQB / SHM / ETH) is used to translate the application's (AW) access via its adapted driver (RQB / TCP; RQB / SHM / ETH) and the real-time communication method is set up for the virtual industrial assembly, and vice versa, wherein the adapted drivers (RQB / TCP; RQB / SHM / ETH) communicate with each other via a communication means according to the real-time communication method. 202416982 Foreign version 20 6. Method according to claim 6, characterized in that the application (AW) and the virtual industrial assembly (BGR) are installed in a virtual machine (VM / VPLC; VM / PER) of a common hardware unit (CLR1; CLR2), wherein a shared memory (SHM) of the hardware unit (CLR1; CLR2) is set up as the communication means.

7. Method according to claim 6, characterized in that the application (AW) and the virtual industrial assembly (BGR) are installed on different hardware units (PLC; S-PLC; V-PLC; CLR1; CLR2), wherein a data network (NW; V-NW; TSN-SW) is provided as the communication means and wherein a communication method with Time-Sensitive Networking (TSN) mechanisms is used as the real-time capable communication method.

8. Method according to one of claims 6 - 8, characterized in that the application (AW) is installed in a simulated programmable logic controller and that the virtual industrial assembly is operated to simulate a real assembly. 202416982 Foreign version 21 9. Driver software for communication between an industrial application (AW) or a virtual industrial assembly with an application-side or assembly-side application interface (RWB-IF) for emulating a local deterministic bus infrastructure, in particular an industrial backplane bus, wherein the driver software is used to implement bus communication of the industrial Application (AW) or the virtual industrial assembly is set up in a real-time capable communication protocol, in particular a shared-memory-based communication method or a TSN communication method, for use as the adapted driver (RQB / TCP; RQB / SHM / ETH) in the arrangement according to claim 1.

Images