Abstraction of PLC communication

Abstract

Current methods of integrating industrial ecosystems, such as integrating automation functions between different programmable logic controller (PLC) suppliers, lack efficiency and capabilities. In an example aspect, a consumer, such as a PLC, can poll multiple PLCs for automation functions. In response to the polling, a first PLC including a memory defining multiple dedicated storage areas can retrieve an interface from a registry storage area that stores information about available interfaces in a provider storage area of ​​the multiple dedicated storage areas so that the consumer can discover the interface. The consumer can bind to the interface to establish a connection between the consumer and the first PLC when the automation function is running. In some cases, the multiple dedicated storage areas further define the consumer storage area. The first PLC can track available interfaces associated with the first PLC in the registry storage area of ​​the multiple dedicated storage areas.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application Serial No. 62 / 893,425, filed on August 29, 2019, the disclosure of which is incorporated herein by reference in its entirety. Technical Field Background Art

[0003] Automation systems can be used to control the operation of machines and other components in a systematic manner. Automation systems can include various automation fields, such as factory automation, process automation, building automation, energy automation, etc. Automation systems can also include devices from multiple vendors. In some cases, devices and machines in an automation system may use different mechanisms associated with their respective ecosystems, such as different operating environments, protocols, and programming languages ​​(e.g., vendor-specific programming languages). For example, automation functions are often platform-specific and / or implemented in a proprietary manner. Therefore, it can be cumbersome and time-consuming to generate automation functions that interoperate with other automation functions.

[0004] Specifically, automation systems typically include programmable logic controllers from different vendors that may include various interfaces for connection. Such a large number of interfaces may cause difficulties in interoperability. For example, in an automation system, a program written in a high-level programming language (such as C, C++, C#) may not be able to interoperate with a given PLC if the developer does not understand the details of how the interface works in order to develop an application protocol on top of the program. As a further example, making a given PLC interoperable with a given program application may include writing adapters on the PLC side and the program application (e.g., C, C++, C#) side, as well as debugging and testing the corresponding communication paths. In addition, the process may have to be repeated each time the interface changes.

[0005] Therefore, this paper recognizes that the current methods of integrating industrial ecosystems, especially integrating various applications with various PLCs, lack efficiency and capabilities. For example, system integrators often need to develop special software that acts as an adapter between different applications and PLCs. In this case, the adapter is often specific to a specific set of devices or communication channels, which limits reusability and other technical shortcomings. Summary of the invention

[0006] Embodiments of the present invention address and overcome one or more disadvantages or technical problems described herein by providing methods, systems, and apparatus for establishing interoperability between programmable logic controllers (PLCs).

[0007] In an example aspect, a consumer, such as a PLC, can poll multiple PLCs for an automation function. In response to the polling, a first PLC including a memory defining multiple dedicated storage areas can retrieve an interface from a registry storage area, which stores information about available interfaces in a provider storage area of ​​multiple dedicated storage areas, so that the consumer discovers the interface. The registry storage area can cyclically poll the automation functions provided by the relevant PLC. When the PLC provides a given interface (automation function), information about the provided interface can be stored in the registry storage area. The consumer can bind to the interface so as to establish a connection between the consumer and the first PLC when the automation function is running. In some cases, multiple dedicated storage areas define a provider storage area, a registry storage area, and a consumer storage area. For example, if a given PLC consumes an interface, the PLC may include a consumer storage area. Define a consumer storage area and a registry storage area. The first PLC can track available interfaces associated with the first PLC in a registry storage area of ​​multiple dedicated storage areas. Therefore, another client can poll the data in the registry storage area to find location information associated with the provider storage area and the consumer storage area. In various examples, the first PLC stores the interface associated with the PLC running as a provider in the provider storage area, and stores the interface associated with the PLC running as a consumer in the consumer storage area. After binding, the consumer sends data to the first PLC through the interface, and the PLC sends data to the consumer through the interface.

[0008] Furthermore, after binding, a function call may be sent to the first PLC to perform the automation function. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The foregoing and other aspects of the invention will be best understood from the following detailed description when read in conjunction with the accompanying drawings. For the purpose of illustrating the invention, there are shown in the accompanying drawings presently preferred embodiments, however, it is to be understood that the invention is not limited to the specific instrumentalities disclosed. The drawings include the following figures:

[0010] Figure 1 is a block diagram illustrating an example automation system and example use cases for the automation system according to example embodiments.

[0011] Figure 2 is a block diagram illustrating another example system including an example node and a programmable logic controller (PLC) having a dedicated storage area for assuming a provider or consumer role according to an example embodiment.

[0012] Figure 3 is with Figure 2 An example function call (FC) associated state machine for a PLC is shown in FIG.

[0013] Figure 4Described are examples of Figure 2 Example FC blocks associated with a PLC are shown.

[0014] Figure 5 Example code that may be generated by a generator module for an interface associated with a given PLC according to an example embodiment is shown.

[0015] Figure 6 is a flow chart describing example operations of an automation system including one or more programmable logic controllers (PLCs) according to example embodiments.

[0016] Figure 7 An example of a computing environment is shown in which embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION

[0017] First, in the current integrated automation system, especially the method of integrating a given programmable logic controller (PLC) with a given application, developers usually need to identify the available protocols of the PLC, select a protocol suitable for the application, and understand the details of the protocol or interface defined by the PLC and the application. In some cases, a basic communication channel is built, which may involve discovering or configuring a given PLC for connection. For example, it may be necessary to study the discovered PLC to determine how to exchange data between the application and the PLC. In addition, it may be necessary to develop an application protocol and / or adapt it to the business logic implemented by the PLC. In some cases, building a communication channel may require adapters for the PLC and the application. For the adapter, the developer may need to consider marshaling and demarshaling (for example, converting calls into data in a specific layout). Then it may be necessary to test the channel and the application layer above the channel. In addition, when the requirements of the application change, the developer may need to manually change the adapter. Alternatively, or in addition, if the underlying communication layer no longer supports the requirements of the application, the developer may need to start over.

[0018] The embodiments described herein address the above-mentioned problems and others in order to effectively integrate various applications with various PLCs. Figure 1, the example automation system 100 defines multiple ecosystems or domains. Specifically, the example system 100 may include a product ecosystem 108, a production ecosystem 102, a production ecosystem 104, and a production ecosystem 106. The example industrial system 100 may define a factory or be part of a factory, such as a factory for manufacturing or assembling various products. According to this example, the production ecosystem 102 includes a gantry station 112, the production ecosystem 104 includes a robot station 114, and the production ecosystem 106 includes a transport station 116, although it will be understood that the production ecosystem may include any station as desired. It will also be understood that although four ecosystems of the example automation system 100 are shown, the automation system described herein may include any number of ecosystems, and all such systems are considered to be within the scope of the present disclosure.

[0019] Each ecosystem may include physical assets that may be controlled by automation devices configured to control the respective physical assets. Such automation devices may include one or more programmable logic controllers (PLCs) 101. For example, a gantry station may include a gantry PLC 101a, a transport station may include a transport PLC 101b, and a robotic station 114 may include a robotic PLC 101c. The PLC, and thus the automation devices, may be specific to one or more physical assets in the respective ecosystem. The automation system 100 may be configured to perform various automation functions. The automation system 100 may also define an abstraction layer 110 that abstracts (exposes) the automation functions that may be performed by the automation devices and physical assets.

[0020] Still reference Figure 1 , the abstraction layer 110 can abstract various functional features that can define automation functions from the automation device, specifically the PLC 101. The automation functions can be soft-wired together so that the abstraction layer 110 can act as an intermediary between various development environments and various automation devices. Therefore, the automation system 100, specifically the abstraction layer 110, can provide functions corresponding to physical components, such as automation devices and / or physical assets. In doing so, developers can operate in one or more development environments (e.g., the development environment of their choice) to use various automation functions via the abstraction layer 110, and the automation functions can be performed by the automation devices and physical assets. Specifically, the abstraction layer 110 can enable automation functions from different fields to interoperate with each other. The development environment can define one or more languages ​​or platforms, such as Java, C, Matlab, Python, Siemens Totally Integrated Automation (TIA) Portal, etc. Therefore, various development environments can utilize various automation devices from various fields through the abstraction layer 110.

[0021] According to various embodiments, the abstraction layer 110 may include a generator module or automation code generator 114 further described herein. The abstraction layer 110 may be executed in an operating environment to provide an interface to the automation functions. The abstraction layer 110 and thus the generator module 114 may be implemented on a server, a cloud-based computing environment, a vendor-specific operating platform environment, or other industrial computing systems such as the computer system 510.

[0022] Each production ecosystem 102, 104, and 106 of the industrial automation system 100 can present or provide various production skills to perform various industrial tasks, such as picking and placing, transporting, assembling, etc. The product ecosystem 108 can use or consume one or more of the production ecosystems 102, 104, and 106 to assemble or manufacture one or more products. Example products include various products produced in a production plant with a PLC, such as but not limited to vehicle parts (e.g., tires, doors, engine mounts), food and beverages (e.g., mixing ingredients, controlling robots for bottling plants), pharmaceutical products, etc., although it should be understood that any product requiring machine operation can be produced according to the embodiments described herein, and all such products are considered to be within the scope of the present disclosure.

[0023] Continue to refer Figure 1 In some cases, the gantry station 112, the robot station 114, and the transport station 116 may be provided by different equipment suppliers, respectively, which may generate interoperability issues and other challenges raised herein. For example, the production ecosystem 102 may include automation equipment associated with a product assembled or manufactured by the industrial automation system 100, such as a product controller 118. For example, the product controller 118 may be PC-based and may be programmed by a first programming language (e.g., C). The product controller 118 may perform various activities during the life cycle of a given product. For example, during the design state, a desired state of a given product may be established within the product controller 118. The desired state may refer to the overall condition of a product or machine during or after production. The desired state may indicate various information, such as absolute position information, position information relative to other physical assets, temperature limits, pressure level limits, etc. The desired state may be determined from inputs to the product controller 118, such as, but not limited to, a bill of process (BOP), a bill of materials (BOM), properties of materials, and a 3D model (e.g., a CAD model) or other physical model of the product.

[0024] In some cases, various aspects of the product may be manually defined based on user input. In some examples, the process is partially or fully automated. In an example embodiment, the product controller 118 includes a text processing utility for extracting relevant information from standard BOP and BOM documents. The product controller 118 may also include a processing utility for understanding the physical model or manufacturing environment of the product. In an example, after extracting relevant information from the input, the information may be used to set values ​​for the desired state of the product managed by the product controller 118. In some embodiments, these values ​​may be set based on a set of rules encoded into the product controller 118. In other examples, the product controller 118 may include one or more machine learning models trained to generate inputs based on information similar to the extracted information.

[0025] During the production state, as a further example, the product controller 118 can control the production of its products by communicating with sensors configured to monitor the products. Based on the information received from the sensors, the product controller 118 can compare the actual product state with the desired state. Based on the comparison, in some cases, the product controller 118 can identify machines or functions within the industrial automation system 100, such as via the abstraction layer 110, to achieve the desired state. For example, the product controller can call various automation devices of the gantry station 112, the robot station 114, or the transport station 116 via the abstraction layer 110 to achieve a specific desired state.

[0026] As a practical example, during the assembly of an automobile, specifically during the installation of a door onto the body of the automobile, the production ecosystem 102 may include a PC or product controller 118 corresponding to the automobile and may therefore know or determine information related to the desired state of the automobile at various steps of the assembly process. Such information may include, for example, but not limited to, the position of the door relative to the body of the automobile. As further described herein, the PC or product controller 118 of the production ecosystem 102 may communicate with the production ecosystem via the abstraction layer 110 to complete the assembly of the automobile.

[0027] The gantry station 112 may be controlled by an automation device programmed in a second programming language different from the first programming language of the product controller 118. For example, the gantry PLC 101a may define one or more programmable logic controllers from Siemens (e.g., SIMATIC S7-1517) programmed in a second programming language (e.g., IEC61131 in the TIA Portal engineering environment). Continuing with this example, the robotic station 114 may be controlled by an automation device from Kuka, such as a Kuka robotic PLC 101c programmed in a third programming language (e.g., Java-based) different from the first and second programming languages. The transport station 116 may be controlled by a transport PLC 101b, which may be from MagneMotion and provides a control node programmed in a fourth programming language (e.g., Web-based or C++-based). Thus, without limitation to a particular example, the functionality of each PLC 101a-101c and the product controller 118 may be programmed in a language and tools supported by the device vendor of its respective ecosystem. In addition, each of the PLCs 101a-101c and the PC-based product controller 118 can implement one or more functions that call each other. Therefore, in various use cases, various PLCs 101a-101c and PC-based product controllers 118 need to interact with each other.

[0028] For example, now refer to Figure 1Describe an example product assembly or production. It will be understood that this assembly is presented as an example, and various other processes requiring additional or alternative interactions between PLC and PC-based systems can be performed by automated systems, and all such automated systems are considered to be within the scope of the present disclosure. At 120, the product controller 118 can send a request to cause the gantry station 112 to perform a pick and place operation on a portion of a given product. Specifically, the request can be processed by the gantry PLC 101a. In some cases, the request at 120 can be processed by the abstraction layer 110. In addition, at 122, the product controller 118 can request the transport station 116 to move a given product to an assembly station (e.g., the gantry station 112) for assembly. Specifically, the product controller 118 can send a request to the transport PLC 101b via the abstraction layer 110. Similarly, the product controller 118 can request the transport station 116 to move a given product to another assembly station (e.g., the robot station 114) for assembly. The product controller 118 can also request the robot station 114, specifically the robot PLC 101c, to perform the desired operation. At 124, for example, when the robotic station 114 has completed the assembly operation, the robotic station 114 can request the transport station 116 to move the product to, for example, a storage location. Specifically, the robotic PLC 101c can interact with the transport PLC 101b, for example, via the abstraction layer 110. Similarly, at 126, when the gantry station 112 has completed its pick and place operation, for example, the gantry station 112 (specifically the gantry PLC 101a) can request the transport station 116 (specifically the transport PLC 101c) to move the product to, for example, a storage location.

[0029] Therefore, according to various embodiments, and as Figure 1 As illustrated, components (e.g., PCs, PLCs, etc.) can discover and utilize interfaces of other network components. For example, a PC can discover interfaces provided on a PLC. A PLC can discover and use interfaces implemented on other PLCs, PCs, or clouds or servers. As further described herein, PLCs can also discover and use interfaces provided by their own user programs using dedicated storage areas. In some examples, interfaces mapped to storage areas can also be used for machines or devices with PC operating systems and industrial PLCs. Specifically, for example, a device can include a PLC side and a PC side, and the business logic of a product can be implemented on the PC side, and automation functions (e.g., PickPlace) can be implemented on the PLC side of the device.

[0030] Also refer to Figure 2, the example system 200 includes an example PLC 202 and an example node 204. The node 204 can define a device (e.g., a PLC or PC) or an automation function associated with the abstraction layer 110. For example, the PLC 101a-PLC c can define the PLC 202, and the product controller 118 can define the node 204, although it will be understood that the embodiments are not limited thereto. In various examples, the node 204 can be executed as a consumer 206 or a provider 208. Similarly, according to various embodiments, the PLC 202 can be executed as a consumer 206 or a provider 208. For example, the node 204 can call an automation function provided by the PLC 202, so that the PLC 202 can be executed as the provider 208, and the node 204 can be executed as the consumer 206. Alternatively or additionally, the PLC 202 can call the node 204 to obtain a function or data, so that the PLC 202 acts as a consumer 206, and the node 204 acts as a provider 208.

[0031] In various examples, before using a given interface, the interface is discovered by the consumer 206. For example, the automation functions available on the PLC 202 can be accessed through their corresponding interfaces. Specifically, for example, the PLC 202 can provide pick and place automation functions accessed through the PickPlace interface. The PickPlace interface can contain operations for performing the relevant automation functions (e.g., connect, disconnect, move, pick, place, buffer pick, buffer place) (e.g., see Figure 4 ). Information about the available interface and other interfaces (e.g., the location in the provider store 214 where the interface can be accessed) can be stored in the registry store 212. To discover an interface, the consumer 206 can browse the registry store 212 to find information associated with the interface. For example, the consumer 206 can browse the registry store 212 to find a specific location or position in the provider store 214 of an available interface.

[0032] The PLC 202 may include a memory 210 that may define various dedicated areas, such as a registry storage area 212, a provider storage area 214, and a consumer storage area 216. For example, the PLC 202 may track interfaces in a dedicated storage area (e.g., the registry storage area 212) of the memory 210. In the example PLC, the registry storage area 212 defines a global data block with a constant block number. The PLC 202 may store information about interfaces that have been consumed or provided (by the PLC 202) in the registry storage area 212. For example, the PLC 202 may store location information related to consumed and provided interfaces in the registry storage area 212. Specifically, for example, the registry storage area 212 may indicate the location of the provided interface in the provider storage area 214. The registry storage area 212 may also indicate the location or interface that has been consumed by the PLC 202 in the consumer storage area 216.

[0033] Specifically, for example, PLC202 may include interface 224, and node 204 may define interface 226. Each interface between nodes, such as each interface between node 204 and PLC202, may include a stub area and a skeleton. Therefore, a given stub area and a skeleton may be collectively referred to as glue code or an interface. For example, the stub area of ​​interface 226 of node 204 may be PC-based and may include functions implemented in a dynamic link library (DLL) or a static library. Such a library may be inserted into the product ecosystem 108, for example, in some cases, the library may be stored by the product controller 118. Similarly, the framework of interface 224 of PLC202 may be based on the language of PLC202. The framework may be stored in provider storage area 214, for example, so that it can be accessed by automation devices within system 200. The framework may be implemented in a language specific to PLC202 (e.g., function blocks). The framework may be stored in the global program memory of PLC202. These functions can then work in the provider store 214, such as reading and writing data.

[0034] Continue to refer Figure 2, the system 200 may further define a communication channel 218 between the node 204 and the PLC 202. The PLC 202 may include a gateway 220 between the memory 210 and the communication channel 218. The node 204 may also include a gateway 222 between the communication channel 218 and other modules of the node 204. The gateways 220 and 222 on both sides of the communication channel 218 may be configured to convert the request into a message that can be processed. In some cases, the message is written directly to the storage area, such as the registry storage area 212, the provider storage area 214, and the consumer storage area 216. Alternatively, or in addition, the message can be passed to another gateway for processing. For example, based on the communication protocol defined by a given message, the gateway 222 can send the message to the gateway 220. In addition, based on the communication protocol defined by a specific message, the gateway 222 can send the message directly to the storage area 212, 214, or 216. Therefore, various communication protocols may require a gateway because various communication protocols may not allow direct access to the memory 210 or specific storage areas 212, 214, and 216.

[0035] In some cases, after the consumer finds the interface, the consumer binds to the interface. In some examples, the interface is found by the name of the interface (e.g., IPickPlace). In some cases, the consumer can browse the registry storage area of ​​the target PLC through the gateway. If the target PLC provides an interface that the consumer is interested in, the information about the position in the provider storage area can be returned to the consumer. The consumer can then lock this specific interface, for example, by storing its identification number in the provider storage area. Such locking can guarantee the exclusive access of this single consumer to the interface. After the consumer uses this interface, the locking can be removed and the interface can be used again for other consumers. In the example where node 204 defines consumer 206, consumer 206 can send a discovery message to gateway 222 to find interface 224 and bind to interface 224. Binding can establish a connection between consumer 206 and interface 224 at runtime. In various examples, the connection between the consumer and the interface is not specified during the compilation of the user code. For example, a PLC interface (e.g., interface 224 of PLC 202) can be registered and unregistered during operation by allocating a storage area of ​​memory 210 and recording the interface information in a registry storage area 212. After successful binding, the consumer 206 can serialize, deserialize, send data to the connected interface, and receive data from the connected interface. For example, the consumer 206 defined by the node 204 can serialize, deserialize, send data to the interface 224 via the gateway 222, and receive data from the interface 224. On the PLC 202, in some cases, various function calls (FCs) 228 are used to access the storage areas 212, 214, and 216.

[0036] Also refer to Figure 3 , an example of an example state machine 300 illustrating an example function call (FC) for a PLC (e.g., PLC204) is described. In the example, consumer 206 is node 204, and PLC202 is provider 208, although it will be understood that PLC202 may alternatively be consumer 206. In this example, consumer 206 has discovered interface 224 and is connected to interface 224. In this example, the consumer wishes to perform an operation on PLC202 by calling a function in a corresponding stub area of ​​interface 224 of PLC202. As further described below, in some cases, in order to map a function call to a given storage area, the state is stored in provider storage area 214.

[0037] Continue to refer Figure 3 At 302 (or state 0), the operation of PLC202 is free to use. In some cases, this state is a prerequisite for the stub area on the consumer 206 side to start operation. At 304 (or state 1), the stub area on the consumer side (e.g., interface 226) can control the operation of PLC202 (e.g., by changing the value of the run state flag to 1) to indicate that the operation is now reserved for the requesting consumer of the operation (e.g., node 204). The PLC can also indicate, for example, via the run state flag that the stub area is transferring the operation parameters to the provider storage area 214. At 306 (or state 2), when the transfer is complete, the framework FC of 224 can read the corresponding data area in the provider storage area 214 and perform the automation function on the PLC. In addition, the stub area can change the value of the run state flag (e.g., to 2) to signal the framework that the parameters are transferred. Such a signal can further indicate to the framework that the framework unmarshals (deserializes) the parameters. It now calls the operation on the actual provider object. Specifically, PLC202 can call objects for operations, such as pick and place operations. At 308 (or state 3), after performing the operation on the provider object, the framework can marshal (serialize) return parameters in this state to indicate that the return parameters are transmitted back to the stub area through the network, specifically, for example, through the communication channel 218. At 310 (or state 4), the stub area can return the call to the consumer (e.g., node 204) to indicate the end of the operation. In some cases, this return occurs when the stub area receives all return parameters. In some examples, at 312 (or state 5), if any error occurs during the execution of the operation, or if there is any failure during the transmission of the parameters, an error status flag is set. In this case, the stub area can return the unsuccessful call of the consumer and exit the operation.

[0038] Figure 3The state of each operation shown can be managed by an edge controller, such as gateways 220 and 222. In the example, data exchange with PLC202 is based on cyclic polling from gateway 222. Each interface associated with PLC202 (which may include stub areas and frames) can define a dedicated storage area on PLC202 for tracking the state of each operation and transmitting operating parameters. For example, a SIMATIC PLC can have a template data block as its dedicated storage area, which is described in SCL (SIMATIC Structured Language). Such a block can be generated by generator module 114.

[0039] Also refer to Figure 4 , an example FC block 400 is shown. In the example, the framework portion of the connection on PLC202 can be implemented by SIMATIC FC unmarshaling and marshaling the operating parameters associated with each operation from the provider storage area 114. The example FC block 400 can be generated for the PLC framework of the PickPlace interface. Specifically, FC 402 (Get Operation Status_"Interface Name") can be generated for each interface to evaluate the operating status flag. In addition, FC402 can trigger the execution of operations inside PLC202. Because, in various examples, the PLC user program is executed cyclically, FC402 can repeatedly, for example cyclically, check whether there is a new request.

[0040] refer to Figure 1 and Figure 5 , the generator module 114 can automatically generate stub areas and frameworks, which can be collectively referred to as glue code or interfaces. Specifically, in the example operation 500, the generator module 114 can generate stub area code and frameworks in the PLC user program at the edge controller level. In the example, the generator module 114 can generate a new interface from an input 502 (e.g., an interface description file, which can define an abstract interface). From the input 502, the generator module 114 can generate PLC-specific interface code 506 that can be imported into a PLC development environment. For example, the PLC-specific interface code 506 can include SCL and PLCopenXML files. For specific reference Figure 5 In the example, a python PEG parser-interpreter can be used to parse the interface model and store it in an abstract syntax tree 504. After the PEG parser-interpreter is completed, the interface can be stored in a python object tree, which is traversed to generate edge controller-specific code and PLC-specific code 506. In the example, the format of the PLC code 506 includes a SIMATIC Structured Language (SCL) file that can be imported in the Siemens PLC development tool TIA-Portal. Beckhoff Automation can support the import of PLCopen XML files.

[0041] Reference now Figure 6 , the example operation 600 can be performed within the system 100 or 200, for example, by more than two PLCs. At 602, a consumer, such as a PLC, can poll multiple PLCs for an automation function. At 604, in response to the polling, a first PLC including a memory defining multiple dedicated storage areas can retrieve an interface from a registry storage area, which stores information about available interfaces in a provider storage area of ​​the multiple dedicated storage areas, so that the consumer discovers the interface. At 606, the consumer can bind to the interface to establish a connection between the consumer and the first PLC when the automation function is running. In some cases, the multiple dedicated storage areas further define a consumer storage area, a provider storage area, and a registry storage area. The first PLC can track available interfaces associated with the first PLC in the registry storage area of ​​the multiple dedicated storage areas. In various examples, the first PLC stores interfaces associated with the PLC running as a provider in the provider storage area, and stores interfaces associated with the PLC running as a consumer in the consumer storage area. After binding, the consumer can send data to the first PLC through the interface, and the PLC can send data to the consumer through the interface.

[0042] In addition, at 608, after binding, a function call can be sent to the first PLC to perform the automation function. In response to the function call, the stub area of ​​the consumer PLC can change the operating state flag within the provider storage area of ​​the provider PLC to reserve the automation function for the consumer. In a further response to the function call, the PLC can transmit operating parameters associated with the automation function to the consumer through an interface. After transmitting the operating parameters, the PLC can change the operating state flag to indicate that the transmission of the operating parameters is complete. At 610, the PLC can call the automation function so that the automation function is executed by the PLC. After executing the automation function, the return parameters associated with the automation function can be returned to the consumer from the first PLC through the interface. In some cases, according to various embodiments described herein, the second PLC defines the consumer so that the PLC can perform the role of a consumer or a provider.

[0043] Figure 7 An example of a computing environment in which embodiments of the present disclosure may be implemented is shown. The computing environment 700 includes a computer system 510, which may include a communication mechanism, such as a system bus 521 or other communication mechanism for transmitting information within the computer system 510. The computer system 510 also includes one or more processors 520 coupled to the system bus 521 for processing information. The PLC described herein may include one or more processors 520, or be coupled to one or more processors 520.

[0044] The processor 520 may include one or more central processing units (CPUs), graphics processing units (GPUs), or any other processors known in the art. More generally, the processor described herein is a device for executing machine-readable instructions stored on a computer-readable medium to perform tasks, and may include any one of hardware and firmware or a combination of hardware and firmware. The processor may also include a memory storing executable machine-readable instructions for performing tasks. The processor acts on information by manipulating, analyzing, modifying, converting, or transmitting information used by an executable process or information device, and / or by routing the information to an output device. The processor may, for example, use or include the capabilities of a computer, a controller, or a microprocessor, and may be adjusted using executable instructions to perform special purpose functions that are not performed by a general-purpose computer. The processor may include any type of suitable processing unit, including but not limited to a central processing unit, a microprocessor, a reduced instruction set computer (RISC) microprocessor, a complex instruction set computer (CISC) microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a system on a chip (SoC), a digital signal processor (DSP), etc. In addition, the processor 520 can have any suitable micro-architecture design, including any number of constituent components, such as, for example, registers, multiplexers, arithmetic logic units, a cache controller for controlling read / write operations to cache memory, a branch predictor, etc. The micro-architecture design of the processor may be able to support any of a variety of instruction sets. The processor can be coupled (electrically and / or including executable components) to any other processor that can interact and / or communicate therebetween. A user interface processor or generator is a known element that includes electronic circuits or software or a combination of both for generating a display image or a portion thereof. The user interface includes one or more display images that enable a user to interact with a processor or other device.

[0045] The system bus 521 may include at least one of a system bus, a memory bus, an address bus, and a message bus, and may allow information (e.g., data (including computer executable code), signaling, etc.) to be exchanged between the various components of the computer system 510. The system bus 521 may include, but is not limited to, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, etc. The system bus 521 may be associated with any suitable bus architecture, including, but not limited to, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnect (PCI) architecture, a PCI Express architecture, an International Personal Computer Memory Card Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, etc.

[0046] Continue to refer Figure 7 , the computer system 510 may also include a system memory 530 coupled to the system bus 521 for storing information and instructions to be executed by the processor 520. The system memory 530 may include computer-readable storage media in the form of volatile and / or non-volatile memory, such as a read-only memory (ROM) 531 and / or a random access memory (RAM) 532. RAM 532 may include other dynamic storage devices (e.g., dynamic RAM, static RAM, and synchronous DRAM). ROM 531 may include other static storage devices (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory 530 may be used to store temporary variables or other intermediate information during the execution of instructions by the processor 520. A basic input / output system 533 (BIOS) may be stored in ROM 531, which contains basic routines such as helping to transfer information between elements within the computer system 510 during startup. RAM 532 may contain data and / or program modules that are immediately accessible to and / or currently being operated on by processor 520. System memory 530 may additionally include, for example, an operating system 534, application programs 535, and other program modules 536. Application programs 535 may also include a user portal for developing applications, allowing input parameters to be entered and modified as needed.

[0047] An operating system 534 may be loaded into memory 530 and may provide an interface between other application software executing on computer system 510 and the hardware resources of computer system 510. More specifically, operating system 534 may include a set of computer executable instructions for managing the hardware resources of computer system 510 and providing common services to other applications (e.g., managing memory allocations between various applications). In certain example embodiments, operating system 534 may control the execution of one or more program modules depicted as being stored in data storage device 540. Operating system 534 may include any operating system now known or that may be developed in the future, including but not limited to any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.

[0048] The computer system 510 may also include a disk / media controller 543 coupled to the system bus 521 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 541 and / or a removable media drive 542 (e.g., a floppy disk drive, an optical disk drive, a tape drive, a flash drive, and / or a solid-state drive). The storage device 540 may be added to the computer system 510 using an appropriate device interface (e.g., a small computer system interface (SCSI), an integrated circuit device (IDE), a universal serial bus (USB), or a firewire). The storage devices 541, 542 may be external to the computer system 510.

[0049] The computer system 510 may also include a field device interface 565 coupled to the system bus 521 to control field devices 566, such as devices used in a production line. The computer system 510 may include a user input interface or GUI 561, which may include one or more input devices, such as a keyboard, touch screen, tablet, and / or pointing device, for interacting with a computer user and providing information to the processor 520.

[0050] The computer system 510 may perform some or all of the processing steps of an embodiment of the present invention in response to the processor 520 executing one or more sequences of one or more instructions contained in a memory such as the system memory 530. Such instructions may be read into the system memory 530 from another computer-readable medium of the storage device 540 (e.g., a magnetic hard disk 541 or a removable media drive 542). The magnetic hard disk 541 and / or the removable media drive 542 may contain one or more data stores and data files used by embodiments of the present disclosure. The data storage device 540 may include, but is not limited to, a database (e.g., relational, object-oriented, etc.), a file system, a flat file, a distributed data storage device storing data on more than one node of a computer network, a peer-to-peer network data storage device, etc. The data storage device may store various types of data, such as skill data, sensor data, or any other data generated according to embodiments of the present disclosure. The data storage content and data files may be encrypted to improve security. The processor 520 may also be used in a multi-processing arrangement to execute one or more instruction sequences contained in the system memory 530. In alternative embodiments, hard-wired circuits may be used instead of software instructions or in combination with software instructions. Therefore, the embodiments are not limited to any specific combination of hardware circuits and software.

[0051] As described above, the computer system 510 may include at least one computer-readable medium or memory for storing instructions programmed according to embodiments of the present invention and for containing data structures, tables, records, or other data described herein. As used herein, the term "computer-readable medium" refers to any medium that participates in providing instructions to the processor 520 for execution. Computer-readable media can take many forms, including but not limited to non-temporary, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid-state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disks 541 or removable media drives 542. Non-limiting examples of volatile media include dynamic memory, such as system memory 530. Non-limiting examples of transmission media include coaxial cables, copper wires, and optical fibers, including wiring that constitutes the system bus 521. The transmission medium can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communication processes.

[0052] The computer-readable medium instructions for performing the operation of the present disclosure may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages, such as Smalltalk, C++, etc., and conventional process programming languages, such as "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer or completely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or may be connected to an external computer (e.g., by using the Internet of an Internet service provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) may be personalized by utilizing the state information of computer-readable program instructions to execute computer-readable program instructions so as to perform aspects of the present disclosure.

[0053] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart and / or block diagram and the combination of blocks in the flowchart and / or block diagram can be implemented by computer-readable medium instructions.

[0054] The computing environment 700 may also include a computer system 510 operating in a network environment using logical connections to one or more remote computers, such as remote computing devices 580. The network interface 570 may enable communication with other remote devices 580 or systems and / or storage devices 541, 542, for example, via a network 571. The remote computing device 580 may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device, or other public network node, and typically includes many or all of the elements described above with respect to the computer system 510. When used in a networked environment, the computer system 510 may include a modem 572 for establishing communications over a network 571, such as the Internet. The modem 572 may be connected to the system bus 521 via the user network interface 570 or via another appropriate mechanism.

[0055] The network 571 can be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or a series of connections, a cellular telephone network, or any other network or medium that can facilitate the communication between the computer system 510 and other computers (e.g., a remote computing device 580). The network 571 can be wired, wireless, or a combination thereof. A wired connection can be achieved using Ethernet, a universal serial bus (USB), RJ-6, or any other wired connection generally known in the art. A wireless connection can be achieved using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellites, or any other wireless connection methods generally known in the art. In addition, multiple networks can work alone or communicate with each other to facilitate communication in the network 571.

[0056] It should be understood that Figure 7 The program modules, applications, computer executable instructions, codes, etc. described as stored in system memory 530 are exemplary only and not exhaustive, and the processing described as supported by any particular module may alternatively be distributed among multiple modules or performed by different modules. In addition, various program modules, scripts, plug-ins, application programming interfaces (APIs), or any other suitable computer executable code hosted locally on computer system 510, remote devices 580, and / or hosted on other computing devices accessible via one or more networks 571 may be provided to support the processing by Figure 7The functions and / or other or alternative functions provided by the program modules, applications or computer executable codes shown. In addition, the functions can be modularized differently, so that the processing described as being jointly supported by the set of program modules shown in the figure can be performed by a smaller or larger number of modules, or the functions described as being supported by any particular module can be supported at least in part by another module. In addition, the program modules supporting the functions described herein can form part of one or more applications that can be executed on any number of systems or devices according to any suitable computing model (e.g., client-server model, peer-to-peer model, etc.). In addition, any function described as being supported by any program module depicted in the figure can be implemented at least in part in hardware and / or firmware on any number of devices.

[0057] It should be further understood that the computer system 510 may include alternative and / or additional hardware, software or firmware components beyond those described or depicted without departing from the scope of the present disclosure. More specifically, it should be understood that the software, firmware or hardware components described as forming part of the computer system 510 are merely illustrative, and in various embodiments, some components may not exist or additional components may be provided. Although various illustrative program modules have been depicted and described as software modules stored in the system memory 530, it should be understood that the functions described as supported by the program modules can be enabled by any combination of hardware, software and / or firmware. It should also be understood that in various embodiments, each of the above modules may represent a logical partition of the supported functions. The logical partition is described to facilitate explanation of the function, and the logical partition may not represent the structure of the software, hardware and / or firmware used to implement the function. Therefore, it should be understood that in various embodiments, the functions described as provided by a specific module may be provided at least in part by one or more other modules. In addition, in some embodiments, one or more of the modules shown may not exist, while in other embodiments, additional modules not shown may exist and may support at least a portion of the functions and / or additional functions. Furthermore, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments these modules may be provided as independent modules or as sub-modules of other modules.

[0058] Although specific embodiments of the present disclosure have been described, those of ordinary skill in the art will recognize that many other modifications and alternative embodiments are within the scope of the present disclosure. For example, any function and / or processing capability described with respect to a specific device or component may be performed by any other device or component. In addition, although various illustrative implementations and architectures have been described according to embodiments of the present disclosure, those of ordinary skill in the art will appreciate that many other modifications to the illustrative implementations and architectures described herein are also within the scope of the present disclosure. In addition, it should be understood that any operation, element, component, data, etc. described herein as being based on another operation, element, component, data, etc. may additionally be based on one or more other operations, elements, components, data, etc. Therefore, the term "based on" or its variants should be interpreted as "based at least in part on".

[0059] Although the embodiments have been described using language specific to structural features and / or methodological behaviors, it should be understood that the disclosure is not necessarily limited to the specific features or behaviors described. Instead, the specific features and behaviors are disclosed as illustrative forms of implementing the embodiments. Conditional language, such as, among others, "may," "can," "might," or "could," unless otherwise specifically stated or otherwise understood in the context in which it is used, is generally intended to convey that certain embodiments may include, while other embodiments do not include, certain features, elements, and / or steps. Therefore, such conditional language is generally not intended to imply that features, elements, and / or steps are in any way necessary for one or more embodiments or that one or more embodiments must include logic for determining whether these features, elements, and / or steps are included in any particular embodiment or will be performed in any particular embodiment with or without user input or prompting.

[0060] The flowchart and block diagram in the figure show the architecture, function and operation of the feasible implementation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram can represent a module, segment or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some optional implementations, the functions in the block may appear in an order other than the order in the figure. For example, in fact, depending on the functions involved, two blocks shown in succession can be executed substantially simultaneously, or these blocks can sometimes be executed in reverse order. It will also be noted that each block in the block diagram and / or flowchart illustration and the combination of blocks in the block diagram and / or flowchart illustration can be implemented by a dedicated hardware-based system that performs a specified function or behavior or performs a combination of dedicated hardware and computer instructions.

Claims

1. A method performed in an automation system, the automation system comprising a plurality of ecosystems defining respective physical assets and a plurality of programmable logic controllers (PLCs) configured to control the physical assets, the method comprising: polling the PLC by a consumer from one of the plurality of ecosystems to obtain automation functionality; In response to the polling, retrieving, by a first PLC of a plurality of PLCs including a memory defining a plurality of dedicated memory areas, an interface from a registry memory area, the registry memory area storing information about available interfaces in a provider memory area of ​​the plurality of dedicated memory areas, such that the consumer discovers the interface; as well as The consumer is bound to the interface so as to establish a connection between the consumer and the first PLC when the automation function is executed; Wherein, when the first PLC provides the interface of interest to the consumer, the location information of the interface in the provider storage area is provided to the consumer; the consumer locks the interface by storing the identification number of the interface in the provider storage area to ensure the exclusive access of the single consumer to the interface; And after the consumer uses the interface, the lock is removed and the interface is used again for other consumers.

2. The method according to claim 1, wherein: The plurality of dedicated storage areas define a consumer storage area and the registry storage area, the method further comprising: Available interfaces associated with the first PLC are tracked by the first PLC in the registry storage area of ​​the plurality of dedicated storage areas.

3. The method according to claim 2, further comprising: storing an interface associated with the PLC operating as a provider in the provider storage area; as well as An interface associated with the PLC operating as the consumer is stored in the consumer memory area.

4. The method according to claim 1, further comprising: After binding, the consumer sends data to the first PLC through the interface.

5. The method according to claim 1, further comprising: After binding, the consumer receives data from the first PLC through the interface.

6. The method according to claim 1, further comprising: After binding, sending a function call to the first PLC to execute the automation function; as well as In response to the function call, the first PLC changes an operating status flag within the provider memory area to reserve the automation function for the consumer.

7. The method according to claim 6, further comprising: Further in response to the function call, operating parameters associated with the automation function are transmitted to the consumer via the interface.

8. The method according to claim 6, further comprising: After the operating parameters are transmitted, the operating status flag is changed to indicate that the transmission of the operating parameters is completed; as well as The automation function is called so as to be executed by the first PLC.

9. The method according to claim 8, further comprising: After executing the automation function, return parameters associated with the automation function are transmitted from the consumer to the first PLC via the interface.

10. A method according to any one of the preceding claims, wherein: The plurality of PLCs include a second PLC defining the consumer.

11. A programmable logic controller (PLC), comprising: processor; as well as a memory defining a plurality of dedicated memory areas, the memory storing instructions that, when executed by the processor, configure the PLC to: In response to a poll from a consumer, retrieving an interface from a registry store storing information about available interfaces in a provider store of the plurality of private stores, such that the consumer discovers the interface; as well as using the interface to establish a connection between the consumer and the PLC when an automation function is running; Wherein, when the PLC provides the interface of interest to the consumer, the location information of the interface in the provider storage area is provided to the consumer; the consumer locks the interface by storing the identification number of the interface in the provider storage area to ensure the exclusive access of the single consumer to the interface; And after the consumer uses the interface, the lock is removed and the interface is used again for other consumers.

12. The programmable logic controller (PLC) according to claim 11, wherein: The plurality of dedicated memory areas further define a consumer memory area and the registry memory area, and the memory further stores instructions which, when executed by the processor, further configure the PLC to: Available interfaces associated with the PLC are tracked in the registry memory area of ​​the plurality of dedicated memory areas.

13. The programmable logic controller (PLC) according to claim 12, wherein the memory further stores instructions, which, when executed by the processor, further configure the PLC to: storing an interface associated with the PLC operating as a provider in the provider storage area; and An interface associated with the PLC operating as a consumer is stored in the consumer memory area.

14. The programmable logic controller (PLC) according to claim 11, wherein the memory further stores instructions, which, when executed by the processor, further configure the PLC to: After binding, receiving data from the consumer through the interface; and After binding, data is sent to the consumer through the interface.

15. The programmable logic controller (PLC) according to claim 12, wherein the memory further stores instructions, which, when executed by the processor, further configure the PLC to: After binding, receiving a function call from the consumer to execute the automation function; and In response to the function call, an operation status flag in the provider storage area is changed to reserve the automation function for the consumer.

Images