QUEUE BLOCKS FOR FLEXIBLE AUTOMATION TECHNOLOGY

Description

BACKGROUND1. Field

[0001] Aspects of the disclosure generally relate to programmable logic controllers (PLCs) for automated industrial processes. More specifically, a system for exchanging data in an automation environment is presented. The system includes a new block type for PLC programming, a queue block, which is configured to dynamically exchange data between two PLCs or between a PLC and another application hosted in another computer system.2. Description of the Related Art

[0002] Currently, automation engineering programs are bound to a specific PLC. For example, Function Blocks (FBs), Functions (FCs) and Data Blocks (DBs) are associated with a specific PLC. In the context of PLC programming, Function Blocks utilize internal Data Blocks for data storage while Functions (FCs) only utilize temporary storage. Each PLC vendor has its own engineering environment and supports its own version of IEC 61131-3 (International Electrotechnical Commission standard for PLCs) programming languages such as Ladder Diagram (LAD), Sequential Function Chart (SFC) and Structured Control Language (SCL). A FB / FC developed for one PLC is not portable or interoperable with another FB / FC from another PLC without a very large integration effort. When two PLCs communicate values to one another, the automation program uses special FB / FCs to invoke communication through an industrial communication protocol such as Profinet. This engineering paradigm is inflexible because it prescribes a specific hardware configuration for that automation program. Any changes in the hardware, trigger a redesign of the software. Likewise, any changes in the software, trigger a validation of the hardware. Thus, this leads to additional engineering efforts that are time consuming and expensive.

[0003] Previous efforts have been made in order to make PLC programs interoperable. Such efforts include adapting the PLC program to the PLC supporting standards such as OPC UA (Open Platform Communications Unified Architecture). The data model, which are designed to store known data structures, of the PLC first has to be mapped to the data model of the standard and then be mapped to the data model of another PLC. Furthermore, the integration effort is project specific and is hardly reusable in a different project. If the PLCs do not support a common standard, then even larger integration efforts must be made based on the opening interfaces (e.g. Software Development Kit (SDK) and Open Development Kit (ODK)) provided by each PLC.

[0004] Flexibility in automation engineering programs has been traditionally achieved through software architecture best practices. The goal is to use automation software design patterns to make software redesign and maintenance easy. However, this does not solve the problem described above, i.e., any changes to the software or hardware still trigger re-engineering. Consequently, flexible automation engineering programs that can exchange data in a more efficient manner are desired. EP 3 371 665 A1 discloses a distributed embedded data and knowledge management system integrated with PLC historian. EP 2 116 913 A2 discloses a Mobile Function Block (MFB) for a PLC based distributed control system. WO 2017 / 027179 A1 discloses automation and control distributed data management systems.SUMMARY

[0005] Briefly described, aspects of the present disclosure relate to a system for exchanging data in an automation environment and a computer implemented method to exchange data between a programmable logic controller and a data consumer in an automation system.

[0006] According to a first embodiment, a system for exchanging data in an automation environment is provided as defined in the appended claims.

[0007] According to a second embodiment, a computer implemented method to exchange data between a programmable logic controller and a data consumer in an automation environment is provided as defined in the appended claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Fig. 1 illustrates a traditional PLC automation program using function blocks and data blocks. Fig. 2 illustrates a first embodiment of a PLC automation program using queue blocks. Fig. 3 illustrates a second embodiment of a PLC automation program using queue blocks. Fig. 4 illustrates a third embodiment of a PLC automation program using queue blocks. Fig. 5 illustrates a fourth embodiment of a PLC automation program using queue blocks. Fig. 6 illustrates a fifth embodiment of a PLC automation program using queue blocks. DETAILED DESCRIPTION

[0009] To facilitate an understanding of embodiments, principles, and features of the present disclosure, they are explained hereinafter with reference to implementation in illustrative embodiments. Embodiments of the present disclosure, however, are not limited to use in the described systems or methods.

[0010] The components and materials described hereinafter as making up the various embodiments are intended to be illustrative and not restrictive. Many suitable components and materials that would perform the same or a similar function as the materials described herein are intended to be embraced within the scope of embodiments of the present disclosure.

[0011] Generally, PLC programs comprise blocks that include user programs for the processing of specific automation tasks. Once programmed, these user programs may be loaded onto a controller of the PLC where they are executed cyclically. Traditionally, program blocks have been classified into various block types including organization blocks, function blocks (FBs), functions (FCs) and data blocks (DBs). This disclosure focuses primarily on the FB / FC and DB types. Functions are similar to FBs except that they do not have access to cyclic data storage. FBs contain the programming instructions while the DB provides data to the FBs as input parameters and provides storage for the output parameters. Thus, a DB may be described as an interface between different FBs / FCs.

[0012] Broadly, a system for exchanging data between programming logic controllers (PLCs) and / or another data consumer utilizing a queue block (QB) is proposed. The queue block is an interchangeable data type in a PLC to replace the traditional DB type. A specific QB may be implemented for each PLC. Once the QB is instantiated in a program, there need not be any change to the remaining PLC programs (e.g., OB, FB, FC, SFC (library System Function)) other than a configuration of a FB / FC to use the queue block instead of a DB. In programming terminology, all references to DBs may be replaced by references to QBs. The replacement may be accomplished either manually or automatically by the engineering tool.

[0013] Referring now to Fig. 1, a traditional PLC automation program 10 including FBs 40 and a DB 30 is shown. As shown, DB1 30 is the interface between FB1 40 and FB2 40 such that the data is exchanged between FB1 40 and FB 2 40 through DB1 30. This traditional approach forces the automation program 10 consisting of FB1->DB1->FB2 to be allocated to a specific hardware configuration (e.g. PLC A 20). The term programmable logic controller (PLC) as used herein refers to industrial computer control system that monitors the state of input devices and makes decisions based upon custom program instructions, typically located in a function / function block, to control the state of output devices. The PCL may include an operating system, firmware, and a processor.

[0014] With reference now to Fig. 2, an embodiment of a flexible automation program 100 using a queue block 50 is shown. The QB 50 is an explicit communication primitive (queue) that may be addressed by the automation program as if it were a DB. Thus, in the illustrated example of Fig. 2, QB1 50 replaces the DB1 30 of the automation program 10. However, in contrast to a DB, a QB can decouple the execution from the communication. So, for example, with the introduction of QB 50, the same program FB1->QB1->FB2 100 may be dynamically allocated during runtime to various hardware configurations such as to a single PLC, e.g., PLC A 20, as in the original program shown in Fig. 1 or to multiple PLCs, e.g., PLC C 20 and PLC D 20, as shown in Fig. 2. The QB exists in the runtime of the PLC. In an embodiment, the QB 50 may be implemented in the firmware of the PLC. Alternately, the QB 50 may be implemented in the operating system of the PLC.

[0015] In further embodiments, the QBs 50 enable high-availability and high redundancy configurations as shown in Fig. 3. Here, the QB 50 may dynamically allocate the automation program FB1->QB1->FB2 100 to a plurality of programmable logic controllers PLC C 20, PLC D 20, and PLC E 20 during runtime.

[0016] In an embodiment, the QBs 50 may be implemented utilizing messaging queues or message passing libraries such as ZeroMQ or RabbitMQ. Different communication patterns may be utilized by the QBs 50 depending on the source of the data to be exchanged, the configuration of PLCs, or the platforms used by the PLCs, for example. Either a programmer having knowledge of the specific application implemented or the runtime system while monitoring the state of the system may choose the communication pattern used. Additionally, depending on this state of the system / network, different communication patterns may be chosen to accomplish faster execution time, lower cycle time, etc. For example, the QBs 50 may offer the following different communication patterns: Point to Point - a single producer and a single consumer. Request-Reply - connects consumers to a producer through a communication broker. Publication-Subscription - connects a set of publishers to a set of subscribers. Map-Reduce - dataflow execution where consumers fire their computation when the receive an input from the producer. Broadcast - a producer broadcasts information to the network. While the QBs 50 may utilize any of the above-named communication patterns to exchange data between FBs 40 of different PLCs 20, other communication patterns not listed here may also be utilized by the QBs as well.

[0017] In an embodiment, the message queuing capability of the QBs enable IoT communication as shown in Fig. 4 utilizing a communication pattern such as the publish-subscribe communication pattern. The publish-subscribe communication pattern is a messaging pattern where senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers, but instead categorize published messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are. Referring now to the exemplary embodiment of Fig. 4, a sensor value from a sensor 60 in the automation environment may be published by FB 1 40 utilizing QB1 50 to data consumers, i.e., subscribers, that are authorized to read the value from the internet 70. The data consumers in this example may be non-PLC applications 80 written in different languages such as C, C++, Python, Java, etc. Thus, with QBs 50, multi-platform compatibility may be achieved. While a sensor value has been used in the exemplary embodiment, other values from further IoT devices may also be exchanged in the described manner.

[0018] In a further embodiment, the QB enables parallel and distributed computation patterns in the automation network. This will greatly benefit new applications that demand higher processing in the edge, as close to sensors 60, as possible. For example, referring Fig. 5, the function block FB 1 40 allocated to PLC C 20 needs a computation on a sensor value from sensor 60 but FB1 40 does not have the computational capacity to get a result before a deadline. In an embodiment, QB1 50 utilizes the Request-Reply communication pattern of its messaging queue to allow more powerful PLCs 20 to perform the computation on FB2 40. In the shown embodiment, QB 1 50 sends a request to a pool of PLCs 90, PLC C, PLC E, and PLC F. Because these PLCs may be performing other tasks, the first one to read the sent message and is able to execute the computation responds to the request and sends the result back to FB 1 40 before the deadline is missed.

[0019] Fig. 6 illustrates another example of the distributed and parallel processing capability of an automation system utilizing QBs 50. In this example, a complex computation is split into two PLCs, PLC D 20 and PLC E 20. using the Map-Reduce communication pattern from the messaging queue. The Map Reduce Communication Pattern includes a mapping function which performs filtering and / or sorting of the input data into tasks. Then, the reduce function performs a summary operation. In the illustrated example, a complex computation on a sensor value from sensor 60 may be split into two PLCs, PLC D 20, and PLC E 20. After the FB2 40 of PLC D 20 and PLC E 20 finishes their part of the computation, the results may be gathered for final processing in FB3 40.

[0020] Queue blocks offer many advantages over the traditional inflexible data block. For example, QBs enable multi-platform implementations of automation networks wherein PLCs can freely communicate with one another and to other non-PLC applications. Programs from one PLC can be easily migrated to other PLCs because they are no longer bound to a specific hardware. In addition, the queue blocks allow for parallel and distributed processing by utilizing message queues of the QBs. New nodes may be added or removed as the computation demand arises. Automation engineering programs, by utilizing queue blocks, and now dynamically exchange data with the result that they are no longer fixed to a particular configuration but can adapt to different runtime conditions. In summary, queue blocks offer flexibility in the automation system so that data may be easily exchanged between PLCs as well as non-PLC applications.

Claims

1. A system for exchanging data between a first programmable logic controller (20) and a data consumer (20, 40, 80) in an automation environment (10), comprising: the first programmable logic controller (20); and a queue block (50) implemented for the first programmable logic controller (20), wherein the queue block (50) exists in the runtime of the first programmable logic controller (20), the queue block (50) being an interchangeable data type in the first programmable logic controller (20) to replace a data block type; wherein program instructions executable by the first programmable logic controller (20) are implemented within a first function block (40) within the first programmable logic controller (20), the function block (40) being configured to use the queue block (50) instead of a data block (30); wherein the first function block (40) is allocated to the first programmable logic controller (20) via the queue block (50) at runtime and the queue block (50) is configured to dynamically exchange data between the first function block (40) and the data consumer (20, 40, 80) during runtime; and wherein the data consumer (20, 40, 80) is an application (80) hosted in a computer system, and the queue block is configured to dynamically exchange data between the first programmable logic controller (20) and the application (80); or wherein the data consumer (20, 40, 80) is a second programmable logic controller (20) having a second function block (40) containing program instructions, the program instructions executable by the second programmable logic controller (20), and the queue block is configured to dynamically exchange data between the first programmable logic controller (20) and the second programmable logic controller (20) by exchanging the data between the first function block (40) and the second function block (40).

2. The system as claimed in claim 1, wherein the application (80) is written in a programming language being C, C++, Python or Java.

3. The system as claimed in claim 1, wherein the queue block (50) is implemented in a firmware or in an operating system of the first programmable logic controller (20).

4. The system as claimed in claim 1, wherein the queue block (50) is configured to dynamically allocate the first function block (40) to a plurality of programmable logic controllers (20) during runtime.

5. The system as claimed in claim 1, wherein the queue block (50) further comprises a messaging queue for communication between the first programmable logic controller (20) and the data consumer (20, 40, 80).

6. The system as claimed in claim 5, wherein the messaging queue is configured to support a plurality of communication patterns selected from the group consisting of point-to-point, request-reply, publication-subscription, map-reduce, broadcast, and combinations thereof.

7. The system as claimed in claim 6, wherein a data value is exchanged between the program instructions of the first programmable logic controller (20) and the data consumer (20, 40, 80) utilizing the communication pattern publication-subscription of the messaging queue over the internet (70), wherein the messaging queue is configured to publish the data value to subscribed clients that are authorized to read the data value from the internet (70).

8. The system as claimed in claim 7, wherein the first function block (40) is configured to receive the data value representing a value from an IoT device (60).

9. The system as claimed in claim 8, wherein the first function block (40) is configured to receive the data value from an IoT device (60) representing a sensor within the automation environment (10).

10. The system as claimed in claim 5, wherein queue block (50) is configured to split a complex computation for a plurality of programmable logic controllers (20) via the messaging queue to allow for parallel and distributed computation in the programmable logic controller (20).

11. A computer implemented method to exchange data between a first programmable logic controller (20) and a data consumer (20, 40, 80) in an automation environment (10), wherein program instructions executable by the first programmable logic controller (20) are implemented within a first function block (40) within the first programmable logic controller (20), the method comprising: providing a queue block (50) for dynamically exchanging data between the first function block (40) and the data consumer (20, 40, 80), the queue block (50) being implemented for the first programmable logic controller, wherein the queue block (50) exists in the runtime of the first programmable logic controller (20), the queue block (50) being an interchangeable data type in the first programmable logic controller (20) to replace a data block type, wherein the first function block (40) is configured to use the queue block (50) instead of a data block (30); allocating the first function block (40) to the first programmable logic controller (20) via the queue block (50) at runtime; and dynamically exchanging data between the first function block (40) and the data consumer (20, 40, 80) during runtime; wherein the data consumer (20, 40, 80) is an application (80) hosted in a computer system, and the queue block dynamically exchanges data between the first programmable logic controller (20) and the application (80); or wherein the data consumer (20, 40, 80) is a second programmable logic controller (20) having a second function block (40) containing program instructions, the program instructions executable by the second programmable logic controller (20), and the queue block dynamically exchanges data between the first programmable logic controller (20) and the second programmable logic controller (20) by exchanging the data between the first function block (40) and the second function block (40).