An agent platform system and an agent control method applied to industrial control

Abstract

This invention relates to the field of computer technology, and in particular to an intelligent agent platform system and intelligent agent control method for industrial control. It comprises an intelligent agent design layer, an intelligent agent operation layer, and an IoT access layer connected sequentially. The intelligent agent design layer is used to create intelligent agents, orchestrate processes, configure triggering mechanisms, and compile and deploy them. The intelligent agent operation layer is used for intelligent agent instance hosting, device data-driven processing, dynamic scheduling, and issuing device control commands. The IoT access layer is used to interface with a third-party IoT platform to achieve device data uplink and control command downlink. This invention decouples the development, operation, and device communication of intelligent agents. The hybrid triggering mechanism introduced in the intelligent agent operation layer achieves high real-time performance and high energy efficiency, enabling the intelligent agent platform system of this invention to achieve efficient, economical, and large-scale application in industrial control scenarios.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an intelligent agent platform system and intelligent agent control method applied to industrial control. Background Technology

[0002] In industrial control scenarios, intelligent agent platforms, as a new system architecture integrating cutting-edge technologies such as artificial intelligence, the Internet of Things (IoT), and edge computing, are gradually being applied to key scenarios such as equipment status monitoring, fault diagnosis, and optimized control. However, existing intelligent agent platforms still face several key technical bottlenecks in actual industrial deployments, limiting their widespread application in high-real-time and high-reliability industrial control environments.

[0003] Firstly, regarding triggering mechanisms, current mainstream industrial intelligent agent platforms generally employ two operation invocation methods: manual triggering or timed polling. The former relies on the operator's experience and judgment to intervene and initiate the process, while the latter executes intelligent agent tasks periodically according to preset time intervals. Both mechanisms struggle to respond promptly to sudden changes in industrial conditions (such as equipment malfunctions or process parameter drift), exhibiting significant response lag. Given that most industrial control processes have high real-time requirements for response, such triggering mechanisms are only suitable for auxiliary decision-making or offline analysis scenarios with lower real-time requirements. They are insufficient to support closed-loop optimization of core control loops, thus hindering the deep integration of intelligent agent technology into key production processes.

[0004] Secondly, there is a significant contradiction between data-driven approaches and system operating costs. To improve response speed, an intuitive technical approach is to achieve high-frequency or even continuous data acquisition through the Industrial Internet of Things (IIoT) and use this as a trigger signal for the operation of intelligent agents. However, with the introduction of complex intelligent agent architectures such as Large Language Models (LLMs) and multimodal models into industrial scenarios, the demand for computing resources (such as GPU / TPU computing power and memory bandwidth) during the inference process has increased dramatically. If the full real-time data stream is used to continuously trigger intelligent agent calls, it will lead to a surge in server load, increased energy consumption, and increased cloud-edge collaborative communication overhead, thereby causing high computing and maintenance costs. In typical industrial environments that are cost-sensitive and resource-constrained, this "high response - high cost" model is difficult to achieve sustainable deployment, which seriously weakens the economic feasibility and scalable promotion potential of intelligent agent platforms.

[0005] In summary, existing technologies have not effectively resolved the fundamental contradiction between real-time response capability and resource utilization efficiency. Therefore, there is an urgent need to propose a new intelligent agent platform architecture for the industrial field, which can intelligently sense changes in operating conditions and activate intelligent agent services on demand while ensuring control timeliness. This will achieve a reasonable balance between performance, cost, and reliability, and drive the evolution of intelligent agent technology from auxiliary decision-making to core control. Summary of the Invention

[0006] This invention addresses the problems of existing technologies by providing an intelligent agent platform system and intelligent agent control method for industrial control. It decouples the development, operation, and device communication of intelligent agents, achieving modularity and scalability. Its core advantage lies in the hybrid triggering mechanism introduced at the intelligent agent runtime layer. This mechanism ensures the high real-time performance required for industrial control while significantly reducing ineffective computation frequency and system resource overhead through micro-batch scheduling, achieving high real-time performance and high energy efficiency. This enables the intelligent agent platform system of this invention to achieve efficient, economical, and large-scale application in industrial control scenarios. This invention aims to solve the problems of poor real-time performance of existing intelligent agent triggering mechanisms, which are unable to meet the real-time requirements of industrial control, as well as the high computational resource consumption and high operating costs of data-driven intelligent agents.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: This invention provides an intelligent agent platform system for industrial control, comprising an intelligent agent design layer, an intelligent agent operation layer, and an IoT access layer connected in sequence. The intelligent agent design layer is used to complete the creation, process orchestration, trigger mechanism configuration, compilation, and deployment of intelligent agents. The intelligent agent operation layer is used for intelligent agent instance hosting, device data-driven processing, dynamic scheduling, and device control command issuance. The IoT access layer is used to interface with a third-party IoT platform to realize device data uplink and control command downlink. The intelligent agent operation layer adopts a hybrid mechanism of event triggering and micro-batch scheduling, activating intelligent agent operation on demand based on device data; the intelligent agent operation layer includes: The agent runtime container is used to manage the agent instance processes; The data-driven module is used to receive device data from the IoT access layer, perform filtering, parsing, buffering, and merging, and generate micro-batch data packets. The dynamic scheduling module is used to call the corresponding agent instance based on the agent identifier in the micro-batch data packet; The device control module is used to send control commands output by the intelligent agent to the IoT access layer via RPC; The intelligent agent design layer completes the creation of intelligent agents, process orchestration, and trigger mechanism configuration, and compiles and deploys them to the intelligent agent runtime layer. The intelligent agent runtime layer starts the intelligent agent instance and waits for scheduling. The IoT access layer collects device data and pushes it to the data-driven module. The data-driven module filters, buffers, and merges the data, generates micro-batch data, and sends it to the dynamic scheduling module. The dynamic scheduling module calls the corresponding instance according to the intelligent agent identifier. The intelligent agent runs and outputs control commands. The device control module sends the commands to the IoT access layer to complete the closed-loop control of the device.

[0008] The intelligent agent design layer includes: The agent management module is used for adding, editing, deleting, and publishing agents. The workflow orchestration module is used to orchestrate intelligent agent workflow tasks based on a visual interface. The triggering mechanism module is used to configure the data-driven triggering rules of the intelligent agent, and associates the IoT platform identifier and the device identifier through the intelligent agent identifier; The compilation and deployment module is used to package the designed agent program and deploy it to the agent runtime layer.

[0009] The data-driven module includes: The data subscription and publishing module receives device uplink data pushed by the IoT platform communication module and filters the device data based on subscription relationships using a Bitmap structure. The data buffer queue module is used to maintain a data buffer queue for each intelligent agent that configures the device data triggering mechanism. Persistent storage is achieved by combining read and write events based on the queue with a timeout mechanism. The data subscription and consumption module triggers the merging and consumption of data by listening to the watermark level of the queue in the data processing state machine.

[0010] The method for filtering device data subscription relationships based on a Bitmap structure in the data subscription and publishing module is as follows: A Bitmap data structure with m rows and n columns is constructed, and all bits of the bitmap are initialized to 0; according to the agent's device subscription configuration, a hash value is calculated using the device's unique identifier (eid), and the row and column offsets in the bitmap are determined based on the hash value, with the corresponding positions set to 1; when receiving device data, the corresponding bitmap position is calculated based on the device's eid; if the bit is 0, it is filtered and discarded; if the bit is 1, it enters the downstream processing stage.

[0011] The method for calculating the hash value using the device's unique identifier (eid) is as follows: The device's row and column offsets in the bitmap are calculated using the globally unique device identifier (eid). The eid is then hashed using the MD5 algorithm to obtain the hash value of the device identifier, which is converted to a hexadecimal number. The first 8 bits of the device identifier hash value are extracted, converted to a decimal integer, and then modulo the row number m to obtain the row offset i. The last 8 bits of the device identifier hash value are extracted, converted to a decimal integer, and then modulo the row number n to obtain the row offset j. Based on the agent's device subscription configuration, the bitmap position of the device subscribed to by the agent is set to 1.

[0012] The conditions for triggering the merging and consumption of data in the data subscription and consumption module are: Watermark level ≥ Checkpoint + time window + delay time threshold; after the conditions are met, the data in the corresponding time range is pulled and packaged into micro-batch data, and the Checkpoint is updated and expired data in the buffer queue is cleaned up.

[0013] The IoT access layer includes an IoT platform communication module, which supports MQTT, CoAP, OPC, HTTP, and TCP protocols.

[0014] The present invention also provides an intelligent agent control method based on the aforementioned intelligent agent platform system, which includes the following steps: Step S1: Complete agent creation, process orchestration, and trigger mechanism configuration in the agent design layer, and compile and deploy to the agent runtime layer; Step S2: The agent running container starts the agent instance and waits for scheduling; Step S3: The IoT access layer collects device data and pushes it to the data-driven module; Step S4: The data-driven module filters, buffers, and merges the data to generate micro-batch data and sends it to the dynamic scheduling module. Step S5: The dynamic scheduling module calls the corresponding instance according to the agent identifier, and the agent runs and outputs control commands; Step S6: The device control module sends instructions to the IoT access layer to complete the closed-loop control of the device.

[0015] In step S1, the agent design layer uses the agent management module to create or modify an agent; the process orchestration module orchestrates the agent's task flow to form an agent operation flowchart; then, the trigger mechanism module configures the agent's trigger mechanism and the data subscription configuration that triggers the agent's autonomous operation; finally, the compilation and packaging module compiles the agent into an executable binary package and distributes it to the agent's runtime program.

[0016] Among them, data filtering uses Bitmap for fast screening, data buffering uses independent queues for each agent, and data consumption uses a watermark and checkpoint mechanism to achieve micro-batch scheduling.

[0017] The beneficial effects of this invention are: This invention proposes a three-layer architecture, comprising an agent design layer, an agent operation layer, and an IoT access layer. The agent design layer serves as the user interface and is responsible for the full lifecycle management of agents, including creation, process orchestration based on a visual interface, trigger rule configuration, and final compilation and deployment. The agent operation layer, as the core of the system, is responsible for hosting agent instances. It receives device data from the IoT access layer and uses a hybrid mechanism combining event triggering and micro-batch scheduling to dynamically activate the corresponding agent instances on demand and issue control commands. The IoT access layer, acting as a bridge to the physical world, is responsible for connecting to third-party IoT platforms to achieve uplink reception of device data and downlink transmission of control commands. This invention decouples the development, operation, and device communication of intelligent agents, achieving modularity and scalability. Its core advantage lies in the hybrid triggering mechanism introduced into the intelligent agent operation layer. This mechanism not only ensures the high real-time performance required for industrial control (rapid response through event triggering) but also significantly reduces the frequency of ineffective calculations and system resource overhead through micro-batch scheduling, achieving high real-time performance and high energy efficiency. This enables the intelligent agent platform system of this application embodiment to achieve efficient, economical, and large-scale application in industrial control scenarios. This invention aims to solve the problems of poor real-time performance of existing intelligent agent triggering mechanisms, which are difficult to meet the real-time requirements of industrial control, as well as the high computational resource consumption and high operating costs of data-driven intelligent agents. Attached Figure Description

[0018] Figure 1 This is a schematic diagram illustrating the principle framework of an intelligent agent platform system for industrial control according to the present invention.

[0019] Figure 2 This is a schematic diagram of the principle framework of the data-driven module of the present invention.

[0020] Figure 3 This is a flowchart of the intelligent agent control method of the present invention.

[0021] exist Figures 1 to 3 The reference numerals in the figures include: 100. Intelligent Agent Design Layer; 200. Intelligent Agent Operation Layer; 300. IoT Access Layer; 101. Intelligent Agent Management Module; 102. Process Orchestration Module; 103. Trigger Mechanism Module; 104. Compilation and Deployment Module; 201. Intelligent Agent Runtime Container; 202. Data-Driven Module; 203. Dynamic Scheduling Module; 204. Device Control Module; 301. IoT Platform Communication Module; 20201. Data Subscription and Publishing Module; 20202. Data Buffer Queue Module; 20203. Data Subscription and Consumption Module. Detailed Implementation

[0022] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to embodiments and accompanying drawings. The content mentioned in the embodiments is not intended to limit the present invention. The present invention will be described in detail below with reference to the accompanying drawings.

[0023] Example 1 In Embodiment 1 of this application, an intelligent agent platform system applied to industrial control is described, such as... Figures 1 to 2 As shown, it includes an intelligent agent design layer 100, an intelligent agent operation layer 200, and an IoT access layer 300 connected in sequence; the intelligent agent design layer 100 is used to complete the creation of intelligent agents, process orchestration, trigger mechanism configuration, and compilation and deployment; the intelligent agent operation layer 200 is used for intelligent agent instance hosting, device data-driven processing, dynamic scheduling, and device control command issuance; the IoT access layer 300 is used to interface with third-party IoT platforms to realize device data uplink and control command downlink. The intelligent agent design layer 100 includes: an intelligent agent management module 101, which provides functions for adding, editing, deleting and publishing intelligent agents; a process orchestration module 102, which provides functions for orchestrating intelligent agent workflow tasks based on a visual interface; a trigger mechanism module 103, which configures intelligent agent data-driven trigger rules and associates IoT platform identifiers and device identifiers through intelligent agent identifiers; and a compilation and deployment module 104, which packages the designed intelligent agent program and deploys it to the intelligent agent runtime layer 200.

[0024] The intelligent agent operation layer 200 adopts a hybrid mechanism of event triggering and micro-batch scheduling, activating intelligent agent operation on demand based on device data. The intelligent agent operation layer 200 includes: an intelligent agent operation container 201 for managing intelligent agent instance processes; a data-driven module 202 for receiving device data from the IoT access layer 300, performing filtering, parsing, buffering, and merging to generate micro-batch data packets that flow into the dynamic scheduling module 203; the dynamic scheduling module 203 calls the corresponding intelligent agent instance based on the intelligent agent identifier in the micro-batch data packet; and a device control module 204 for sending control commands output by the intelligent agent to the IoT access layer 300 via RPC. Specifically, the module obtains the corresponding intelligent agent instance from the intelligent agent operation container 201 and uses the micro-batch data as input parameters for the intelligent agent call, calling the intelligent agent instance to run. After the intelligent agent instance finishes running, it outputs feedback device control commands. These device control commands are then sent to specific devices via the IoT access layer 300 through the device control module 204 using RPC remote calls, completing closed-loop device control.

[0025] Specifically, under the above configuration, this application proposes a three-layer architecture, which includes an agent design layer 100, an agent operation layer 200, and an IoT access layer 300. The agent design layer 100 serves as the user interface and is responsible for the full lifecycle management of the agent, including creation, process orchestration based on a visual interface, trigger rule configuration, and final compilation and deployment. The agent operation layer 200 serves as the core of the system and is responsible for hosting agent instances. It receives device data from the IoT access layer 300 and uses a hybrid mechanism combining event triggering and micro-batch scheduling to dynamically activate the corresponding agent instances on demand and issue control commands. The IoT access layer 300 serves as a bridge to the physical world and is responsible for connecting to third-party IoT platforms to achieve uplink reception of device data and downlink transmission of control commands. This application decouples the development, operation, and device communication of the intelligent agent, achieving modularity and scalability. Its core advantage lies in the hybrid triggering mechanism introduced in the intelligent agent operation layer 200. This mechanism not only ensures the high real-time performance required for industrial control (rapid response through event triggering) but also significantly reduces the frequency of ineffective calculations and system resource overhead through micro-batch scheduling, achieving high real-time performance and high energy efficiency. This enables the intelligent agent platform system of this application embodiment to achieve efficient, economical, and large-scale application in industrial control scenarios. This application embodiment aims to solve the problems of poor real-time performance of existing intelligent agent triggering mechanisms, which are difficult to meet the real-time requirements of industrial control, as well as the high consumption of computing resources and high operating costs of data-driven intelligent agents.

[0026] In this embodiment, the data content of the micro-batch data packet includes the agent identifier, the start time of the micro-batch data, the end time of the micro-batch data, and the corresponding device data array. Specifically, the introduction of micro-batch data packets is key to achieving efficient scheduling. It packages continuous data streams into discrete processing units, laying the foundation for subsequent batch processing and resource optimization.

[0027] In this embodiment, the data-driven module 202 includes: a data subscription and publishing module 20201, which receives device uplink data pushed by the IoT platform communication module 301 and filters the device data based on a Bitmap structure to reflect subscription relationships; a data buffer queue module 20202, which maintains a data buffer queue for each agent configured with a device data triggering mechanism and achieves persistent storage based on a combination of queue read / write events and a timeout mechanism; and a data subscription and consumption module 20203, which triggers data merging and consumption by listening to the queue's watermark level from the data processing state machine. Specifically, the data subscription and publishing module 20201 is responsible for receiving raw data and performing preliminary filtering based on the agent's subscription configuration; the data buffer queue module 20202 maintains an independent data buffer queue for each agent configured with a triggering mechanism and achieves persistent data storage using queue read / write events and a timeout mechanism; and the data subscription and consumption module 20203 intelligently determines when to trigger data consumption by listening to the queue's watermark level and packages the data that meets the conditions into micro-batch data.

[0028] The relevant terms are first explained in the embodiments of this application: IoT Platform Identifier: A unique identifier used to identify the third-party IoT platform being connected, represented by iotId.

[0029] Device Origin Identifier: This refers to the unique identifier used by a third-party IoT platform to identify a device, represented by deviceId.

[0030] Unique Device Identifier: This refers to a globally unique identifier used to identify a device within the intelligent agent platform. It is represented by EID, which is generated by combining iotId and deviceId. The generation rule is as follows: EID = iotId + ":" + deviceId. For example, if the iotId of the IoT platform is "iot_01" and the device source identifier deviceId is "device_01", then the unique device identifier EID is "iot_01:device_01".

[0031] Watermark: A UNIX millisecond timestamp used to identify the latest data in the current data buffer queue.

[0032] Checkpoint: A checkpoint is a UNIX millisecond timestamp used to identify the last piece of data that has been processed in the current data buffer queue.

[0033] Agent identifier: Used to uniquely identify an agent, denoted by aid.

[0034] In this embodiment, the method for filtering device data subscription relationships based on a Bitmap structure in the data subscription and publishing module 20201 is as follows: A Bitmap data structure with m rows and n columns is constructed, and all bits of the bitmap are initialized to 0. Based on the device subscription configuration of the intelligent agent, a hash value is calculated using the device's unique identifier (eid), and the row and column offsets in the bitmap are determined based on the hash value, with the corresponding positions set to 1. When receiving device data, the corresponding bitmap position is calculated based on the device's eid; if the bit is 0, it is filtered and discarded; if the bit is 1, it enters the downstream processing stage. Specifically, in the data subscription and publishing module 20201, device uplink data pushed by the IoT platform communication module 301 is received, realizing the functions of device data filtering, subscription relationship parsing, and data queue publishing. Specifically, a Bitmap data structure with m rows and n columns is constructed, where the values ​​of m and n can be dynamically adjusted according to the number of connected devices. The total number of bits is approximately one-tenth of the number of devices to avoid performance degradation caused by an excessively large bitmap, and all bits of the bitmap are initialized to 0.

[0035] In this embodiment, the method for calculating the hash value using the device unique identifier eid is as follows: The device's row and column offset in the bitmap is calculated using the globally unique device identifier eid; the eid is hashed using the MD5 algorithm to obtain the hash value of the device identifier; the hash value is converted into a hexadecimal value; the first 8 bits of the device identifier hash value are extracted, converted into a decimal integer value, and then modulo the row number m to obtain the row offset i; the last 8 bits of the device identifier hash value are extracted, converted into a decimal integer value, and then modulo the row number n to obtain the row offset j; according to the agent's device subscription configuration, the bitmap position of the device subscribed by the agent is set to 1. Specifically, based on the agent's device subscription configuration, the bitmap position of the device with agent subscription is set to 1. Because the number of bits in the bitmap is less than the total number of devices and there may be hash collisions in the MD5 algorithm, the same bit in the bitmap may correspond to multiple devices at the same time. When this happens, as long as one device has agent subscription configuration, the bit is set to 1. The bitmap is used to initially filter out device data without data subscription, avoiding too much data flowing into the downstream processing stage. Because there may be cases where the same bit corresponds to multiple devices, bitmap filtering may have missed detections, but it will not have false detections. That is, device data without agent subscription may flow into the downstream processing stage, but device data with agent subscription will not be filtered out, thereby achieving the purpose of filtering out most of the device data without agent subscription and reducing the load on the downstream processing stage. Compared with traditional database queries or list traversal, Bitmap filtering is a classic algorithm that trades space for time. It can achieve millisecond-level fast filtering of massive device data with extremely low CPU and memory overhead, effectively solving the performance bottleneck in high-concurrency scenarios.

[0036] This application provides an example illustrating the steps involved in implementing a device that subscribes to Bitmap updates: Assuming we construct a Bitmap structure with 128 rows by 128 columns to determine if a smart agent subscribes to a device, the unique identifier of the subscribed device to be calculated is: iot_platform_01:device_01; The device's unique identifier is hashed using the MD5 algorithm and converted into a hexadecimal value, resulting in the hash value of the device's unique identifier: 5e0d6a9294d09ed8ebccc1bbcd10c56a. The first 8 bits of the device's unique identifier hash value are extracted to calculate the row offset. The first 8 bits are: 5e0d6a92; converted to decimal value: 1577937554; then the row offset is obtained by taking the modulo of the total number of rows: rowOffset=1577937554%128=18; The last 8 bits of the device's unique identifier hash value are extracted to calculate the column offset. The last 8 bits are: cd10c56a; converted to decimal value: 3440428394; then the column offset is obtained by taking the modulo of the total number of columns: columnOffset=3440428394%128=106; Based on the row and column offsets (18, 106) calculated above, since the array offsets start from 0, the positions of the 19th row and 107th column in the Bitmap are set to 1.

[0037] In this embodiment, in the data buffer queue module 20202, a data buffer queue is maintained for each agent that configures the device data triggering mechanism. The agent identifier aid is used as the unique identifier of the queue. The data buffer queue achieves persistent storage based on a combination of queue read / write events and a timeout mechanism: when the data subscription and publishing module 20201 pushes data to the data buffer queue, the queue is triggered to persist when the number of writes exceeds the preset trigger number; when the data subscription and consumption module 20203 processes the data and triggers data clearing, the queue is triggered to persist; when the difference between the last time the persistent storage was triggered and the current time is greater than the persistence timeout threshold, the queue is triggered to persist.

[0038] In this embodiment, the conditions for triggering the merging and consumption of data in the data subscription and consumption module 20203 are: Watermark level ≥ Checkpoint + Time window + Delay time threshold; after the conditions are met, data within the corresponding time range is pulled, packaged into micro-batch data, and the Checkpoint is updated and expired data in the buffer queue is cleaned up. Specifically, the determination of whether the triggering conditions are met is based on the following rule: Watermark level ≥ Checkpoint + Time window + Delay time threshold; where the time window is the time span of a batch of data processed in the micro-batch, in milliseconds, used to control the data volume of the micro-batch data; the delay time threshold is the acceptable data delay time, in milliseconds, used to avoid the problem of out-of-order arrival time of time-series data caused by the distributed system, and is dynamically configured according to the acceptable delay time of the application scenario; When the triggering condition is met in the previous step, a batch of device data is pulled from the corresponding queue. The time range for pulling device data is: the data time is greater than the checkpoint timestamp, and the data time is less than or equal to the checkpoint timestamp plus the time window of the device data. This batch of data is packaged into micro-batch data and pushed to the dynamic scheduling module 203. The data structure of the micro-batch data includes: agent identifier, micro-batch data start time, micro-batch data end time, device data array, etc. Finally, the transaction for committing data subscription consumption is committed. The transaction commit includes two steps: First, update the checkpoint timestamp of the current queue in the data processing state machine. The new checkpoint timestamp is equal to the old checkpoint timestamp plus the time window millisecond value. Second, trigger the clearing of all device data in the corresponding data buffer queue that lags behind the new checkpoint timestamp.

[0039] In this embodiment of the application, the IoT access layer 300 includes an IoT platform communication module 301, which supports MQTT, CoAP, OPC, HTTP, and TCP protocols.

[0040] Specifically, the embodiments of this application have the following technical effects: 1. The data-driven module 202 uses a Bitmap structure to quickly filter massive amounts of device data based on subscription relationships, greatly reducing the data processing pressure in subsequent stages and significantly improving the platform's data processing performance.

[0041] 2. A device data subscription relationship cache is constructed by using B+ trees and adjacency matrices. By leveraging the search performance advantage of the B+ tree data structure, the time complexity of traversing and searching for the corresponding subscription agent when reporting device data is reduced from O(n) to O(log n), thereby improving the efficiency of data parsing and flow.

[0042] 3. A micro-batch data processing mechanism is built based on buffer queues, watermark levels, and checkpoints to process data in batches. While ensuring high real-time performance, this reduces the number of agent wake-up calls, lowers system load, and reduces the demand for computing resources.

[0043] Example 2 Example 2 of this application is as follows Figure 3 As shown, an intelligent agent control method based on the aforementioned intelligent agent platform system is provided, which includes the following steps: Step S1: In the agent design layer 100, agent creation, process orchestration, and trigger mechanism configuration are completed, and the agent is compiled and deployed to the agent runtime layer 200. Specifically, in the agent design layer 100, the agent management module 101 creates or modifies the agent; the process orchestration module 102 orchestrates the agent's task flow to form an agent runtime flowchart; then, under the trigger mechanism module 103, the data subscription configuration for triggering the agent's autonomous operation is configured; finally, the agent is compiled into a runnable binary package by the compilation and packaging module and deployed to the agent runtime program. Step S2: The agent runtime container 201 starts agent instances and waits for scheduling; specifically, all agent instances are deployed and run in the agent runtime container 201, waiting for scheduling and execution by the dynamic scheduling module 203. Step S3: The IoT access layer 300 collects device data and pushes it to the data driving module 202; Step S4: The data-driven module 202 filters, buffers, and merges the data to generate micro-batch data and sends it to the dynamic scheduling module 203. Specifically, the IoT access layer 300 connects to different types of third-party IoT platforms through the IoT platform communication module 301, and pushes the device uplink data to the data driving module 202 in real time through RPC calls. After the data driving module 202 performs data filtering, parsing, buffering, merging and other processing, it forms micro-batch data, which then flows into the dynamic scheduling module 203. Step S5: The dynamic scheduling module 203 calls the corresponding instance according to the agent identifier, and the agent runs and outputs control commands. Specifically, the scheduling module obtains the corresponding agent instance through the agent running container 201 module according to the agent identifier in the micro-batch data, uses the micro-batch data as the input of the agent to trigger the agent to run, and the agent runs and outputs device control commands. The device control commands are sent to the IoT platform communication module 301 through the device control module 204. The IoT platform communication module 301 converts the device control commands into the corresponding IoT platform communication messages and sends them to the corresponding IoT platform. Step S6: The device control module 204 sends the instruction to the IoT access layer 300 to complete the closed-loop control of the device. Specifically, the IoT platform receives the corresponding device control command, triggers the actual device control, and realizes the complete closed loop of data-driven intelligent body platform device control.

[0044] In Embodiment 2 of this application, data filtering uses Bitmap for fast screening, data buffering uses independent queues for each agent, and data consumption uses a watermark and checkpoint mechanism to achieve micro-batch scheduling.

[0045] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0046] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0047] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0048] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0049] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0050] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. An intelligent agent platform system for industrial control, characterized in that: It includes an agent design layer, an agent operation layer, and an IoT access layer connected in sequence; the agent design layer is used to complete the creation of agents, process orchestration, trigger mechanism configuration, and compilation and deployment. The intelligent agent operation layer is used for intelligent agent instance hosting, device data-driven processing, dynamic scheduling, and device control command issuance; the IoT access layer is used to interface with third-party IoT platforms to realize device data uplink and control command downlink. The intelligent agent operation layer adopts a hybrid mechanism of event triggering and micro-batch scheduling, activating intelligent agent operation on demand based on device data; the intelligent agent operation layer includes: The agent runtime container is used to manage the agent instance processes; The data-driven module is used to receive device data from the IoT access layer, perform filtering, parsing, buffering, and merging, and generate micro-batch data packets. The dynamic scheduling module is used to call the corresponding agent instance based on the agent identifier in the micro-batch data packet; The device control module is used to send control commands output by the intelligent agent to the IoT access layer via RPC; The intelligent agent design layer completes the creation of intelligent agents, process orchestration, and trigger mechanism configuration, and compiles and deploys them to the intelligent agent runtime layer. The intelligent agent runtime layer starts the intelligent agent instance and waits for scheduling. The IoT access layer collects device data and pushes it to the data-driven module. The data-driven module filters, buffers, and merges the data, generates micro-batch data, and sends it to the dynamic scheduling module. The dynamic scheduling module calls the corresponding instance according to the intelligent agent identifier. The intelligent agent runs and outputs control commands. The device control module sends the commands to the IoT access layer to complete the closed-loop control of the device.

2. The intelligent agent platform system for industrial control according to claim 1, characterized in that, The agent design layer includes: The agent management module is used for adding, editing, deleting, and publishing agents. The workflow orchestration module is used to orchestrate intelligent agent workflow tasks based on a visual interface. The triggering mechanism module is used to configure the data-driven triggering rules of the intelligent agent, and associates the IoT platform identifier and the device identifier through the intelligent agent identifier; The compilation and deployment module is used to package the designed agent program and deploy it to the agent runtime layer.

3. The intelligent agent platform system for industrial control according to claim 1, characterized in that, The data-driven module includes: The data subscription and publishing module receives device uplink data pushed by the IoT platform communication module and filters the device data based on subscription relationships using a Bitmap structure. The data buffer queue module is used to maintain a data buffer queue for each intelligent agent that configures the device data triggering mechanism. Persistent storage is achieved by combining read and write events based on the queue with a timeout mechanism. The data subscription and consumption module triggers the merging and consumption of data by listening to the watermark level of the queue in the data processing state machine.

4. The intelligent agent platform system for industrial control according to claim 3, characterized in that, The method for filtering device data subscription relationships based on the Bitmap structure in the data subscription and publishing module is as follows: Construct an m-row by n-column Bitmap data structure, initialize all bits of the bitmap to 0; calculate the hash value using the device's unique identifier eid according to the agent's device subscription configuration, determine the row and column offsets in the bitmap based on the hash value, and set the corresponding positions to 1. When receiving device data, the corresponding bitmap position is calculated based on the device's EID. If the bit is 0, the data is filtered out and discarded; if the bit is 1, the data is entered into the downstream processing stage.

5. The intelligent agent platform system for industrial control according to claim 4, characterized in that, The method for calculating the hash value using the device's unique identifier (eid) is as follows: The device's row and column offsets in the bitmap are calculated using the globally unique device identifier (eid). The eid is then hashed using the MD5 algorithm to obtain the hash value of the device identifier. This hash value is converted to a hexadecimal number. The first 8 bits of the device identifier hash value are extracted, converted to a decimal integer, and then modulo the row number m to obtain the row offset i. The last 8 bits of the device identifier hash value are extracted, converted to a decimal integer, and then modulo the row number n to obtain the row offset j. Based on the agent's device subscription configuration, the bitmap position of the device subscribed to by the agent is set to 1.

6. The intelligent agent platform system for industrial control according to claim 3, characterized in that, The conditions for triggering the merging and consumption of data in the data subscription and consumption module are: Watermark level ≥ Checkpoint + time window + delay time threshold; after the conditions are met, the data in the corresponding time range is pulled and packaged into micro-batch data, and the Checkpoint is updated and expired data in the buffer queue is cleaned up.

7. The intelligent agent platform system for industrial control according to claim 3, characterized in that: The IoT access layer includes an IoT platform communication module, which supports MQTT, CoAP, OPC, HTTP, and TCP protocols.

8. An intelligent agent control method based on the intelligent agent platform system according to any one of claims 1-7, characterized in that, Includes the following steps: Step S1: Complete agent creation, process orchestration, and trigger mechanism configuration in the agent design layer, and compile and deploy to the agent runtime layer; Step S2: The agent running container starts the agent instance and waits for scheduling; Step S3: The IoT access layer collects device data and pushes it to the data-driven module; Step S4: The data-driven module filters, buffers, and merges the data to generate micro-batch data and sends it to the dynamic scheduling module. Step S5: The dynamic scheduling module calls the corresponding instance according to the agent identifier, and the agent runs and outputs control commands; Step S6: The device control module sends instructions to the IoT access layer to complete the closed-loop control of the device.

9. The intelligent agent control method according to claim 8, characterized in that: In step S1, the agent design layer uses the agent management module to create or modify an agent; the process orchestration module orchestrates the agent's task flow to form an agent operation flowchart; then, the trigger mechanism module configures the agent's trigger mechanism and the data subscription configuration that triggers the agent's autonomous operation; finally, the compilation and packaging module compiles the agent into an executable binary package and distributes it to the agent's runtime program.

10. The intelligent agent control method according to claim 8, characterized in that: Data filtering uses Bitmap for fast selection, data buffering uses independent queues for each agent, and data consumption uses a watermark and checkpoint mechanism to achieve micro-batch scheduling.

Images