A PLC control method and system for direct communication of field IO devices

Abstract

The application discloses a PLC control method and system for direct communication of field IO devices, and relates to the technical field of industrial automation control. The method comprises the following steps: based on a device registration request, a system model is obtained by performing function arrangement through a control arranger according to a device agent and task control requirements; based on a preset extraction rule, a system connection relationship description is obtained by using a system model parser to extract the connection relationship between devices in the system model according to the system model; based on the system connection relationship description, device control interaction is performed by using a connection relationship mapper according to the device agent, and post-interaction device information is obtained; and based on the post-interaction device information, field devices perform current task control. The application is a PLC control method for direct communication of field IO devices, which has strong flexibility and good expansibility.

Description

Technical Field

[0001] This invention relates to the field of industrial automation control technology, and in particular to a PLC control method and system for direct communication between field I / O devices. Background Technology

[0002] In today's widely used industrial system architectures, a centralized control architecture centered on a Programmable Logic Controller (PLC) is prevalent. The PLC, as the core device in the system, connects to field I / O devices via fieldbus or industrial Ethernet and collects data, which is then aggregated to the upper layers. However, in this centralized architecture, data exchange between devices must be acquired, processed, and distributed through the central controller. The resulting transmission latency impacts data with high real-time requirements. Furthermore, its static and fixed connection architecture makes adjustments difficult and costly, hindering the refactoring of the production system.

[0003] With the deepening of Industry 4.0, industrial automation systems are facing the core challenge of transforming from small-batch rigid production to multi-variety flexible manufacturing. To better adapt to the intelligent manufacturing demands of Industry 4.0, various technical solutions dedicated to improving system flexibility have emerged in the field of industrial automation in recent years. Existing technical solutions mainly fall into two categories: the IEC 61499 standard, launched by the International Electrotechnical Commission (IEC), provides an event-driven function block architecture for distributed industrial control systems, supporting decentralized deployment of control logic and cross-device collaboration, reducing reliance on a central control unit. In addition, the Open Platform Communications Foundation (OPC) proposed a Field-Level Communication (FLC) solution, enabling PLCs to achieve controller-to-controller (C2C) communication through the unified OPC architecture. Both solutions aim to replace traditional centralized industrial automation systems with distributed communication, enhancing system flexibility and adaptability to meet the demands of flexible manufacturing.

[0004] While the solutions mentioned above aim to improve system flexibility and distributed capabilities, they still have several shortcomings. The IEC 61499 solution proposes distributed control using event-driven function block networks, but its architecture differs fundamentally from the widely adopted IEC 61131-3 ecosystem in current industrial settings, resulting in extremely poor compatibility and difficulties in implementation. Furthermore, this solution cannot achieve unified semantic interaction between devices or dynamic binding of communication relationships; system reconfiguration still heavily relies on manual intervention and offline deployment, and it does not support hot switching of connection relationships at runtime. While the FLC solution standardizes communication protocols and supports communication mechanisms between controllers, at the controller and device level, communication relationships still rely on static pre-configuration and cannot automatically establish variable-level communication channels between devices based on system tasks.

[0005] In the existing technology, there is a lack of a PLC control method that is flexible and scalable for direct communication with field I / O devices. Summary of the Invention

[0006] To address the technical problems of existing technologies, such as the lack of automatic extraction of connection relationships in system tasks and the inability to dynamically modify data interaction relationships between configured devices during operation, this invention provides a PLC control method and system for direct communication between field I / O devices. The technical solution is as follows:

[0007] On the one hand, a PLC control method for direct communication between field I / O devices is provided. This method is implemented by a PLC control device and includes:

[0008] Obtain task control requirements; the device agent initiates a device registration request;

[0009] Based on the device registration request, and according to the device agent and task control requirements, the system model is obtained by orchestrating functions through the control orchestrator.

[0010] Based on preset extraction rules, and according to the system model, the system model parser is used to extract the connection relationships between devices in the system model to obtain a description of the system connection relationships.

[0011] Based on the system connection relationship description, and according to the device agent, the connection relationship mapper is used to perform device control interaction and obtain device information after the interaction;

[0012] Based on the device information after interaction, the field device executes the current task control.

[0013] On the other hand, a PLC control system for direct communication with field I / O devices is provided. This system is applied to a PLC control method for direct communication with field I / O devices. The system includes a device agent, a control orchestrator, a system model resolver, a connection relationship mapper, and field I / O devices.

[0014] The device agent is used to initiate a device registration request;

[0015] The control orchestrator is used to obtain task control requirements; based on the device registration request, and according to the device agent and task control requirements, the control orchestrator performs function orchestration to obtain a system model.

[0016] The system model parser is used to extract the connection relationships between devices in the system model based on preset extraction rules and the system model, thereby obtaining a description of the system connection relationships.

[0017] The connection relationship mapper is used to perform device control interaction based on the system connection relationship description and according to the device agent, and obtain the device information after the interaction.

[0018] The field I / O device is used to control the field device to perform the current task based on the device information after interaction.

[0019] On the other hand, a PLC control device is provided, the PLC control device comprising: a processor; a memory storing computer-readable instructions, wherein when the computer-readable instructions are executed by the processor, any one of the PLC control methods for direct communication with field I / O devices as described above is implemented.

[0020] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, the at least one instruction being loaded and executed by a processor to implement any of the above-described PLC control methods for direct communication between field I / O devices.

[0021] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following:

[0022] This invention proposes a PLC control method for direct communication between field I / O devices. Through a distributed architecture and a unified semantic information model, it drives the automatic parsing and dynamic deployment adjustment of communication relationships between devices. Without system downtime, the system automatically parses the real-time communication relationships between device variables based on programmed system tasks and dynamically modifies existing device connections to establish new data interaction channels. This integrated approach of "system task parsing - connection relationship extraction - dynamic data channel establishment" achieves a closed loop from system design to dynamic reconfiguration of data communication between devices. This method is not constrained by specific devices or configurations, effectively improving the flexibility and scalability of industrial control systems, and truly achieving real-time adaptation to equipment changes and process adjustments. This invention is a highly flexible and scalable PLC control method for direct communication between field I / O devices. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a PLC control method for direct communication between field I / O devices provided in an embodiment of the present invention;

[0025] Figure 2 This is a schematic diagram of the structure of a connection relationship mapper provided in an embodiment of the present invention;

[0026] Figure 3 This is a block diagram of a PLC control system for direct communication between field I / O devices provided in an embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram of the structure of a PLC control device provided in an embodiment of the present invention. Detailed Implementation

[0028] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0029] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0030] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0031] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0032] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0033] This invention provides a PLC control method for direct communication between field I / O devices. This method can be implemented by a PLC control device, which can be a terminal or a server. Figure 1 The flowchart shown illustrates a PLC control method for direct communication with field I / O devices. This method's processing flow may include the following steps:

[0034] S1. Obtain task control requirements; the device agent initiates a device registration request.

[0035] In one feasible implementation, the overall structural framework of the present invention can be divided into three parts: a device layer, a configuration layer, and an orchestration layer. The device layer includes field I / O devices and device agents; the configuration layer includes a system model parser and a connection mapping mapper; and the orchestration layer is a control orchestrator.

[0036] The core of the device layer consists of different types of field devices and their device agents. Unlike traditional bus models, in the current system architecture, all field devices interact with each other through device agents. The device agent contains the attributes and methods of the current device, as well as semantic information.

[0037] The orchestration layer consists of control orchestrators, namely the device registration server and the orchestrator (PLC Integrated Development Environment, PLC IDE).

[0038] The configuration layer includes a system model parser and a connection relationship mapper. Its function is to receive the system model issued by the orchestration layer, parse the connection relationship of each device function block in the system model, and map the extracted connection relationship of the function block into a publish / subscribe (Pub / Sub) connection relationship between specific variable nodes between two or more device agents, so as to realize direct communication between IO devices through agents, eliminating the centralized data collection work in traditional industrial scenarios.

[0039] The equipment agent includes an equipment information model, a UA server, PLC function programs, and a protocol adapter;

[0040] The device information model is a structured description of field I / O devices; the core nodes of the device information model include Pub-Sub Governor node, Pub Delete node, Pub Set node, Pub State node, Pub URL node, Method node, Configuration node, and State node;

[0041] The UA server uses a built-in lightweight OPC UA server; the UA server has a communication interface based on the standard OPC UA protocol.

[0042] The PLC function program is the built-in control logic of the field I / O devices;

[0043] Protocol adapters are used to standardize the data format of field I / O devices.

[0044] In one feasible implementation, the device agent is implemented through the PLC Runtime Environment (PLC RTE) that runs the Programmable Logic Controller (PLC). The device agent (PLC runtime) consists of four parts: a device information model, an OPC Unified Architecture (UA) server, a protocol adapter, and PLC function programs.

[0045] The protocol adapter is responsible for communicating with underlying industrial equipment through various industrial protocols, such as Modbus, Process Field Bus (PROFIBUS), and Ethernet Industrial Protocol (EtherNet / IP). It collects raw data and converts device data from different protocols into a unified format, i.e., data in the PLC. This shields the differences between devices from different manufacturers and directly replaces the traditional external protocol conversion gateway.

[0046] The collected raw data can be used in conjunction with PLC function programs to control equipment and realize all its functions. In the function programs, the raw data can also be mapped into a standardized information model, which facilitates the understanding and use of upper-level systems, such as Manufacturing Execution System (MES) and Supervisory Control and Data Acquisition (SCADA).

[0047] Therefore, the construction of the equipment information model is particularly crucial. The equipment information model refers to the structured description of the functions, attributes, and status of specific equipment using a modeling language. This model endows PLC data with rich and clear semantics and interoperability, providing plug-and-play understanding capabilities for upper-level IT systems. Currently, the most commonly used modeling language internationally is OPC UA.

[0048] The device information model uses a custom "DeviceObject" object type, which inherits from the OPC UA node space. Objects instantiated from this type manage and control the entire device, and include the following core nodes:

[0049] The Pub-Sub Governor node (object) is the entry point and central manager for the publish / subscribe functionality. It is responsible for starting and stopping publish / subscribe tasks, managing connections, and summarizing status and error information. Under this object, two core objects are created: "Pub_Interface" and "Sub_Interface," which manage the global publish and subscribe functionalities respectively. Therefore, the Pub-Sub Governor object node enables command and control over the Pub-Sub lifecycle and status monitoring.

[0050] The "Pub_Interface" object contains four variable nodes: PubDelete, Pub Set, Pub State, and Pub URL.

[0051] The Pub Delete node controls the deletion of publisher resources. This variable is used to stop and destroy existing publishing tasks and their associated resources. Clients or servers can modify the value of this variable to delete all variables currently being published, thereby freeing up network bandwidth and processing resources.

[0052] The Pub Set node controls the variables used to publish publisher resources. This variable is used to create a new publishing task. Clients can modify the value of this variable, along with relevant configuration parameters on the publishing side, to dynamically establish or reconfigure a data publishing channel and publish variable data to the network.

[0053] The Pub State node displays a variable representing the status of the publisher's published features. This is a read-write state variable used to reflect the current running status of existing publishing tasks in real time. Clients monitor the current running status of the publishing feature by reading the value of this variable.

[0054] The Pub URL node contains a target address variable that explicitly specifies the network destination to which the publisher will send the encoded network message (containing dataset data). The OPC UA protocol supports both brokered and brokerless publish-subscribe modes. In brokered mode, Message Queuing Telemetry Transport (MQTT) is the most common. In this mode, the middleware, the Message Broker, is used; publishers do not communicate directly with subscribers but interact with the Message Broker. In this case, the value of this variable is the network address of the Message Broker. For brokerless publish mode, the value of this variable is a multicast group or unicast address, directly determining the scope and destination of data propagation on the network.

[0055] The content of the Sub_Interface object node is identical to that of Pub_Interface. For detailed information on its nodes, please refer to the explanation of Pub_Interface object nodes. However, it does not include Sub_URL because the data subscribed to by the current device may come from different devices, and a single Sub_URL cannot provide a unified description.

[0056] The Method node (object) contains the interfaces exposed by the device to the outside world, representing the methods or services the device exposes to the outside world. The Method-N node represents the Nth function that the device supports being invoked. Each method node also contains the necessary input and output variables for the invocation.

[0057] The values ​​of input variables can be modified directly via a client / server connection or obtained through external subscriptions. During execution, the input to this method may not be static values ​​provided directly by the caller, but rather dynamically derived from data published by subscribed other devices. The output variables generated after method execution can not only be returned to the client via a response, but can also be published to the network as new data sources through a publish-subscribe mechanism. This allows any device subscribed to the data to receive the results of the method execution in real time, significantly enhancing the system's automation capabilities and decoupling in a design geared towards modern Industry 4.0.

[0058] The input variables to be subscribed to and the output variables to be published each possess the most critical configuration information related to publish-subscribe: Pub_Parameter and Sub_Parameter. Both have nodes containing three key variable nodes: "Writer_Group_ID" (writer group identifier), "DataSet_Writer_ID" (dataset writer identifier), and "Publisher_ID" (publisher identifier). These three parameter values ​​are crucial identifiers in OPC UA's Pub-Sub communication. By configuring these three variables to the same value and combining them with a URL, direct data interaction can be achieved between the publisher and subscriber. The publisher configures these three values ​​to identify the variable data published on the network, while the subscriber configures these three values ​​and the URL of the subscription data source to subscribe to the data it needs. Therefore, the information model design including publish-subscribe related nodes plays a decisive role in direct communication between I / O devices.

[0059] Configuration node (object): Used to store, describe, and expose certain core control parameters of the control equipment. Clients can directly obtain data by browsing the nodes under it. Taking a conveyor belt as an example, the content under the Configuration object node can include key information such as the control frequency and start / stop acceleration of the conveyor belt.

[0060] State node (object): This node provides real-time updates on the device's current running state. When the device receives external calls to execute functions or when the device itself undergoes state updates, the value of this node variable is modified accordingly. Possible state values ​​are Running, Error, and Ready, representing the device in progress, encountering an error, and being ready, respectively. Clients can monitor the device's functionality by reading the pointer to this state variable.

[0061] The device agent integrates a lightweight OPC UA server. This server directly uses the internally built information model as its address space. This allows the device agent to directly and efficiently access data within the PLC in real time and to securely and reliably communicate with external components via Ethernet ports using the standard OPC UA protocol, including functions such as reading, writing, subscribing, and accessing historical data.

[0062] After obtaining the device information model, the device object can be instantiated in the OPC UA address space using the OPC UA server. The existence of the proxy provides a standard access interface for the configuration layer, allowing the configuration manager to access the device proxy through the UA client to obtain device status and invoke device functions. Furthermore, the device proxy can automatically register functions with the device registration server in the orchestration layer, which generates available function blocks for the corresponding devices. This allows the orchestrator to dynamically load function blocks based on device registration, orchestrating system-level engineering applications.

[0063] S2. Based on the device registration request, and according to the device agent and task control requirements, the system model is obtained by orchestrating functions through the control orchestrator.

[0064] Optionally, based on the device registration request, and according to the device agent and task control requirements, the system model is obtained by orchestrating functions through a control orchestrator, including:

[0065] The registration server receives the device registration request and performs control function mapping based on the device information model of the device agent to obtain the device function block;

[0066] The orchestrator receives device function blocks and dynamically orchestrates them using preset UI tools according to task control requirements to obtain the system model of the current control task.

[0067] In one feasible implementation, the device registration server dynamically acquires registration requests automatically initiated by device agents at the device layer. It then iterates through and previews the device information model content of each device agent, designed based on a custom modeling standard. The methods in the information model are mapped into function blocks conforming to the IEC 61131-3 PLC standard according to the custom standard. The generated function blocks clearly describe the detailed functions of each field device. This process completes the conversion from OPC UA semantics to PLC programming semantics, abstracting physical devices into reusable software components.

[0068] The orchestrator's role is to receive device function blocks generated from device registration and dynamically load them into its graphical user interface (GUI) programming environment. Instead of defining system control logic, users drag and drop these function blocks and connect their input / output terminals (e.g., activating certain functions of device B when a sensor in device A is triggered). This essentially defines data and control flows. After orchestration, the orchestrator exports the entire system project as a system model file. This allows users to orchestrate system tasks efficiently and concisely using existing device function blocks, eliminating the need for complex code-based program development.

[0069] The orchestrated system tasks are described in the form of a system model, which is an XML file that strictly follows the official XML exchange standard developed by PLCopen for the IEC 61131-3 project. It has good compatibility and openness, and accurately describes all functional block instances and their connections.

[0070] Optionally, when a new I / O device is connected to the system, based on the device registration request and according to the device agent and task control requirements, the system model is obtained by performing functional orchestration through the control orchestrator, and then includes:

[0071] The new equipment agent initiates a new equipment registration request;

[0072] The registration server receives a new device registration request and performs control function mapping based on the device information model represented by the new device to obtain the new device function block;

[0073] Add the new device function block to the device function block to obtain the updated device function block;

[0074] The orchestrator receives updated device function blocks and dynamically rearranges them using preset UI tools according to task control requirements to obtain the first system model of the current control task.

[0075] The first system model is determined as the system model.

[0076] In one feasible implementation, dynamism is also a prominent advantage of the system architecture in this invention. When a new device is connected to the system, the system's industrial control tasks can be re-arranged in the orchestrator, and the data interaction relationship between different IO devices can be reconfigured according to the process. The system can be dynamically switched to the new task without stopping the system.

[0077] Optionally, when task control requirements change, based on the device registration request, and according to the device agent and task control requirements, after performing function orchestration through the control orchestrator to obtain the system model, the following is also included:

[0078] The registration server receives the device registration request and performs control function mapping based on the device information model of the device agent to obtain the device function block;

[0079] The orchestrator receives the device function blocks and dynamically rearranges them using preset UI tools according to the new task control requirements to obtain a second system model for the new control task.

[0080] The second system model is determined as the system model.

[0081] In one feasible implementation, when the requirements of on-site engineering control tasks change due to process adjustments, production line expansion, or order changes, this invention can automatically parse the communication links required for the new task and reconfigure the interaction relationships based on the established process of "system model - connection relationship mapping - publish / subscribe parameter distribution." Throughout the process, the original task remains running, and the PLC real-time kernel, fieldbus, and device agents can seamlessly switch to the new control logic and data flow topology without requiring system shutdown and restart. This invention achieves the goal of "simultaneous production and reconfiguration" in flexible industrial manufacturing, significantly reducing capacity losses and manual intervention costs caused by system downtime.

[0082] S3. Based on the preset extraction rules, according to the system model, the system model parser is used to extract the connection relationship between devices in the system model to obtain the system connection relationship description;

[0083] The system connection description includes the data source function block, output parameters, data receiving function block, and input parameters.

[0084] In one feasible implementation, the system model parser receives the system model from the orchestrator and extracts the connection relationships between various device functional blocks in the system model (an XML description file) according to certain rules and specifications. The rules for extracting these connection relationships need to be universally applicable and concise, providing an accessible interface for subsequent reuse. Table 1 (System Connection Relationship Description Table) below describes an example of connection relationships obtained through the system model (this is just one feasible solution). This method allows for accurate determination of the data flow from the sending device to the receiving device.

[0085] Table 1

[0086]

[0087] The system model parser parses the XML file and extracts the data connections between all device function blocks. The result is a list or file indicating "which device's output variable" needs to be sent to "which device's input variable".

[0088] S4. Based on the system connection relationship description, and according to the device agent, use the connection relationship mapper to perform device control interaction and obtain device information after the interaction;

[0089] Optionally, based on the system connection relationship description and according to the device agent, a connection relationship mapper is used to perform device control interaction to obtain device information after the interaction, including:

[0090] Based on the device agent-based device information model, the system connection relationship description is described, and the information is parsed by the input parser to obtain the device information and interaction variables before the interaction.

[0091] Based on the device information before interaction, and according to the interaction variables, information is retrieved through the node information retrieval device to obtain the interaction node ID;

[0092] Based on the interaction node ID and the device information model of the device agent, parameter information is written through the UA client to obtain the device information after the interaction.

[0093] In one feasible implementation, after obtaining the description of the system connection relationships, the connection relationships are handed over to a connection relationship mapper for further processing. Since the generation of functional blocks depends on the information model in each device agent, this connection relationship description can be used to reverse locate the two devices actually communicating and the two nodes exchanging data. This functionality can be achieved through the connection relationship mapper. Figure 2 The internal structure of the connection mapping module is described, which mainly includes a node information retrieval module, a user agent (UA) client, and an input parser.

[0094] The extracted connection relationships are used as input. After input parsing, the two devices that need to interact with each other in a set of connections, as well as the two variables for publish-subscribe data interaction, can be obtained. The node information retrieval tool will access the OPC UA address space of the relevant device agent and find the precise NodeID (such as the node with parameters like Publisher_ID, Writer_Group_ID, DataSet_Writer_ID, etc.) of the corresponding publish (Pub) and subscribe (Sub) parameter nodes based on the variable names.

[0095] The connection mapper connects to the OPC UA servers of device agents A and B respectively via its internal UA client, using a client / server model supported by OPC UA. It writes publication parameters to the corresponding node of device agent A (the data publisher) and sets its Pub_Set variable to enable publication. Simultaneously, it writes subscription parameters (including the source Pub_URL of device A and three IDs identical to those of device A) to the corresponding node of device agent B (the data subscriber) and sets its Sub_Set variable to enable subscription. At this point, the two IO devices in the current connection relationship can directly communicate single-variable data through the publish-subscribe data interaction mode.

[0096] By traversing all the contents of the system connection relationship description and repeating the above process, standardized distributed communication can be achieved for all IO devices in the entire industrial control system that require data interaction.

[0097] S5. Based on the device information after interaction, the field device executes the current task control.

[0098] In one feasible implementation, after all configurations are complete, the system enters the running state. When the output variable value of device A changes, its device agent immediately encapsulates it in an OPC UA message and publishes it to the local area network according to the configured parameters, whether it is agentless based on User Datagram Protocol (UDP) multicast or agented based on MQTT. Device agent B subscribes to the corresponding channel, and after receiving the message, matches and filters it according to the same three IDs, directly decodes the data and writes it into the target input variable. The PLC running on device agent B then executes the control logic based on the new data, driving the local device to act, realizing the end-to-end automation from device A to device B as defined in the system orchestration logic, without the need for data relay through any central controller or gateway.

[0099] This invention proposes a PLC control method for direct communication between field I / O devices. Through a distributed architecture and a unified semantic information model, it drives the automatic parsing and dynamic deployment adjustment of communication relationships between devices. Without system downtime, the system automatically parses the real-time communication relationships between device variables based on programmed system tasks and dynamically modifies existing device connections to establish new data interaction channels. This integrated approach of "system task parsing - connection relationship extraction - dynamic data channel establishment" achieves a closed loop from system design to dynamic reconfiguration of data communication between devices. This method is not constrained by specific devices or configurations, effectively improving the flexibility and scalability of industrial control systems, and truly achieving real-time adaptation to equipment changes and process adjustments. This invention is a highly flexible and scalable PLC control method for direct communication between field I / O devices.

[0100] Figure 3 This is a block diagram of a PLC control system for direct communication between field I / O devices, provided by an embodiment of the present invention. This system is used for a PLC control method for direct communication between field I / O devices. (Refer to...) Figure 3 The system includes a device agent 310, a control orchestrator 320, a system model parser 330, a connection relationship mapper 340, and field I / O devices 350.

[0101] Device Agent 310 is used by the device agent to initiate a device registration request;

[0102] The control orchestrator 320 is used to obtain task control requirements; based on the device registration request, and according to the device agent and task control requirements, the control orchestrator performs function orchestration to obtain the system model.

[0103] The system model parser 330 is used to extract the connection relationships between devices in the system model based on preset extraction rules and the system model, thereby obtaining a description of the system connection relationships.

[0104] The connection relationship mapper 340 is used to perform device control interaction based on the system connection relationship description and the device agent, and obtain the device information after the interaction.

[0105] Field I / O device 350 is used to control the field device to perform the current task based on the device information after interaction.

[0106] The equipment agent includes an equipment information model, a UA server, PLC function programs, and a protocol adapter;

[0107] The device information model is a structured description of field I / O devices; the core nodes of the device information model include Pub-Sub Governor node, Pub Delete node, Pub Set node, Pub State node, Pub URL node, Method node, Configuration node, and State node;

[0108] The UA server uses a built-in lightweight OPC UA server; the UA server has a communication interface based on the standard OPC UA protocol.

[0109] The PLC function program is the built-in control logic of the field I / O devices;

[0110] Protocol adapters are used to standardize the data format of field I / O devices.

[0111] Optionally, the control orchestrator 320 is further used for:

[0112] The registration server receives the device registration request and performs control function mapping based on the device information model of the device agent to obtain the device function block;

[0113] The orchestrator receives device function blocks and dynamically orchestrates them using preset UI tools according to task control requirements to obtain the system model of the current control task.

[0114] The system connection description includes the data source function block, output parameters, data receiving function block, and input parameters.

[0115] Optionally, the connection relationship mapper 340 is further used for:

[0116] Based on the device agent-based device information model, the system connection relationship description is described, and the information is parsed by the input parser to obtain the device information and interaction variables before the interaction.

[0117] Based on the device information before interaction, and according to the interaction variables, information is retrieved through the node information retrieval device to obtain the interaction node ID;

[0118] Based on the interaction node ID and the device information model of the device agent, parameter information is written through the UA client to obtain the device information after the interaction.

[0119] Optionally, the control orchestrator 320 is also used for:

[0120] The new equipment agent initiates a new equipment registration request;

[0121] The registration server receives a new device registration request and performs control function mapping based on the device information model represented by the new device to obtain the new device function block;

[0122] Add the new device function block to the device function block to obtain the updated device function block;

[0123] The orchestrator receives updated device function blocks and dynamically rearranges them using preset UI tools according to task control requirements to obtain the first system model of the current control task.

[0124] The first system model is determined as the system model.

[0125] Optionally, the control orchestrator 320 is also used for:

[0126] The registration server receives the device registration request and performs control function mapping based on the device information model of the device agent to obtain the device function block;

[0127] The orchestrator receives the device function blocks and dynamically rearranges them using preset UI tools according to the new task control requirements to obtain a second system model for the new control task.

[0128] The second system model is determined as the system model.

[0129] This invention proposes a PLC control method for direct communication between field I / O devices. Through a distributed architecture and a unified semantic information model, it drives the automatic parsing and dynamic deployment adjustment of communication relationships between devices. Without system downtime, the system automatically parses the real-time communication relationships between device variables based on programmed system tasks and dynamically modifies existing device connections to establish new data interaction channels. This integrated approach of "system task parsing - connection relationship extraction - dynamic data channel establishment" achieves a closed loop from system design to dynamic reconfiguration of data communication between devices. This method is not constrained by specific devices or configurations, effectively improving the flexibility and scalability of industrial control systems, and truly achieving real-time adaptation to equipment changes and process adjustments. This invention is a highly flexible and scalable PLC control method for direct communication between field I / O devices.

[0130] Figure 4 This is a schematic diagram of the structure of a PLC control device provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the PLC control device may include the above-mentioned Figure 3 The illustrated PLC control system communicates directly with field I / O devices. Optionally, the PLC control device 410 may include a first processor 2001.

[0131] Optionally, the PLC control device 410 may also include a memory 2002 and a transceiver 2003.

[0132] The first processor 2001, memory 2002, and transceiver 2003 can be connected via a communication bus.

[0133] The following is combined Figure 4 A detailed introduction to each component of the PLC control device 410:

[0134] The first processor 2001 is the control center of the PLC control device 410. It can be a single processor or a collective term for multiple processing elements. For example, the first processor 2001 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0135] Optionally, the first processor 2001 can execute various functions of the PLC control device 410 by running or executing software programs stored in the memory 2002 and calling data stored in the memory 2002.

[0136] In a specific implementation, as one example, the first processor 2001 may include one or more CPUs, for example... Figure 4 CPU0 and CPU1 are shown in the diagram.

[0137] In a specific implementation, as one example, the PLC control device 410 may also include multiple processors, for example... Figure 4 The first processor 2001 and the second processor 2004 are shown in the diagram. Each of these processors can be a single-core processor or a multi-core processor. Here, a processor can refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0138] The memory 2002 is used to store the software program that executes the present invention, and is controlled by the first processor 2001 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0139] Optionally, the memory 2002 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 2002 may be integrated with the first processor 2001 or exist independently, and may be controlled via the interface circuit of the PLC control device 410. Figure 4 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0140] The transceiver 2003 is used to communicate with network devices or with terminal devices.

[0141] Alternatively, transceiver 2003 may include a receiver and a transmitter. Figure 4 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0142] Optionally, the transceiver 2003 can be integrated with the first processor 2001, or it can exist independently and be controlled via the interface circuit of the PLC control device 410. Figure 4 (Not shown in the image) is coupled to the first processor 2001, and this embodiment of the invention does not specifically limit this.

[0143] It should be noted that, Figure 4 The structure of the PLC control device 410 shown does not constitute a limitation on the router. Actual PLC control devices may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0144] Furthermore, the technical effects of the PLC control device 410 can be referenced from the technical effects of the PLC control method for direct communication between field I / O devices described in the above method embodiments, and will not be repeated here.

[0145] It should be understood that the first processor 2001 in the embodiments of the present invention may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor, or it may be any conventional processor, etc.

[0146] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0147] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable system. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0148] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0149] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0150] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0151] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0152] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, systems, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0153] In the embodiments provided by this invention, it should be understood that the disclosed devices, systems, and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or units may be electrical, mechanical, or other forms.

[0154] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0155] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0156] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0157] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A PLC control method for direct communication with field I / O devices, characterized in that, The method includes: Obtain task control requirements; the device agent initiates a device registration request; Based on the device registration request, and according to the device agent and task control requirements, the system model is obtained by orchestrating functions through the control orchestrator. The process of obtaining a system model by arranging functions through a control orchestrator based on device registration requests, device agent requirements, and task control needs, includes: The registration server receives the device registration request and performs control function mapping based on the device information model of the device agent to obtain the device function block; The orchestrator receives the device function blocks and, based on the task control requirements, uses a preset UI tool to dynamically orchestrate them to obtain the system model of the current control task. When a new I / O device is connected to the system, after the process of obtaining the system model by performing functional orchestration through a control orchestrator based on the device registration request, device agent, and task control requirements, the system model further includes: The new equipment agent initiates a new equipment registration request; The registration server receives a new device registration request and performs control function mapping based on the device information model represented by the new device to obtain the new device function block; Add the new device function block to the device function block to obtain the updated device function block; The orchestrator receives updated device function blocks and dynamically rearranges them using preset UI tools according to task control requirements to obtain the first system model of the current control task. The first system model is determined as the system model; When task control requirements change, the process of orchestrating functions through a control orchestrator based on device registration requests, device agents, and task control requirements to obtain a system model further includes: The registration server receives the device registration request and performs control function mapping based on the device information model of the device agent to obtain the device function block; The orchestrator receives the device function blocks and dynamically rearranges them using preset UI tools according to the new task control requirements to obtain a second system model for the new control task. The second system model is determined as the system model; Based on preset extraction rules, and according to the system model, the system model parser is used to extract the connection relationships between devices in the system model to obtain a description of the system connection relationships. Based on the system connection relationship description, and according to the device agent, the connection relationship mapper is used to perform device control interaction and obtain device information after the interaction; The step of using a connection relationship mapper to perform device control interaction based on the system connection relationship description and according to the device agent to obtain the device information after the interaction includes: Based on the device agent-based device information model, the system connection relationship description is described, and the information is parsed by the input parser to obtain the device information and interaction variables before the interaction. Based on the device information before interaction, and according to the interaction variables, information is retrieved through the node information retrieval device to obtain the interaction node ID; Based on the interaction node ID, and according to the device information model of the device agent, parameter information is written through the UA client to obtain the device information after the interaction; Based on the device information after interaction, the field device executes the current task control.

2. The PLC control method for direct communication between field I / O devices according to claim 1, characterized in that, The device agent includes a device information model, a UA server, a PLC function program, and a protocol adapter; The device information model is a structured information description of field I / O devices; the core nodes of the device information model include Pub-Sub Governor node, Pub Delete node, Pub Set node, Pub State node, Pub URL node, Method node, Configuration node, and State node; The UA server uses a built-in lightweight OPC UA server; the UA server has a communication interface based on the standard OPC UA protocol. The PLC function program is the built-in control logic of the field I / O device; The protocol adapter is used to unify the data format of field I / O devices.

3. The PLC control method for direct communication between field I / O devices according to claim 1, characterized in that, The system connection description includes the data source function block, output parameters, data receiving function block, and input parameters.

4. A PLC control system for direct communication with field I / O devices, wherein the PLC control system for direct communication with field I / O devices is used to implement the PLC control method for direct communication with field I / O devices as described in any one of claims 1-3, characterized in that, The system includes a device agent, a control orchestrator, a system model parser, a connection mapping module, and field I / O devices. The device agent is used to initiate a device registration request; The control orchestrator is used to obtain task control requirements; based on the device registration request, and according to the device agent and task control requirements, the control orchestrator performs function orchestration to obtain a system model. The system model parser is used to extract the connection relationships between devices in the system model based on preset extraction rules and the system model, thereby obtaining a description of the system connection relationships. The connection relationship mapper is used to perform device control interaction based on the system connection relationship description and according to the device agent, and obtain the device information after the interaction. The field I / O device is used to control the field device to perform the current task based on the device information after interaction.

5. A PLC control device, characterized in that, The PLC control device includes: processor; A memory storing computer-readable instructions that, when executed by the processor, implement the method as described in any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1 to 3.

Images