A collaborative analysis method and system of intelligent internet-of-things equipment

Abstract

The application belongs to the technical field of agricultural Internet of Things, and discloses a kind of collaborative analysis method and system of intelligent Internet of Things equipment, the method constructs the whole network high computing power machine well dynamic resource view through improved bidirectional PIM multicast protocol.Low computing power machine well sends multicast assistance request when needing depth analysis, and router only forwards to idle interface according to resource view, and selects assistance and backup machine well through random delay and machine well ID sorting mechanism, establishes "request-assistance-backup" collaborative relationship, and sends announcement to suppress repeated response at the same time.If assistance machine well cannot execute, then the task is taken over by backup machine well or idle machine well coordinated across router through emergency assistance mechanism.Assistance machine well calls local agricultural model to complete analysis and returns result.The application realizes efficient collaboration between devices, improves resource utilization and system reliability.

Description

Technical Field

[0001] This invention belongs to the field of agricultural Internet of Things and smart irrigation technology, and particularly relates to a collaborative analysis method and system for smart IoT equipment. Background Technology

[0002] In smart agriculture scenarios, intelligent well-manipulation equipment is widely deployed in various irrigated areas to collect basic data such as soil temperature and humidity, and crop images. Due to cost or design limitations, some well-manipulation equipment only has basic data collection capabilities and cannot perform complex agricultural analysis tasks, such as soil moisture assessment, pest and disease identification, and irrigation decisions. When in-depth analysis is required, these low-computing-power devices typically rely on remote servers or cloud platforms, resulting in large response delays, high network loads, and poor real-time performance.

[0003] In existing technologies, some solutions attempt to centrally process data through edge computing nodes or local servers, but the following problems still exist:

[0004] There is a lack of effective collaboration mechanisms between devices, and high-performance computing devices cannot provide real-time analysis support to low-performance computing devices when they are idle.

[0005] Traditional request-response patterns (such as unicast or broadcast) are prone to network congestion and equipment interference;

[0006] The lack of dynamic backup and fault tolerance mechanisms means that analysis tasks are easily interrupted or dropped when the assisting equipment suddenly becomes busy.

[0007] In large-scale deployment scenarios, the system has poor scalability and low resource scheduling efficiency.

[0008] Therefore, there is an urgent need for an intelligent well collaborative analysis method and system that can achieve dynamic collaboration between devices, support real-time analysis, and have good scalability and fault tolerance. Summary of the Invention

[0009] The purpose of this invention is to provide a collaborative analysis method and system for intelligent IoT equipment to solve the above-mentioned technical problems.

[0010] To address the aforementioned technical problems, the specific technical solution of the collaborative analysis method and system for intelligent IoT equipment of the present invention is as follows:

[0011] A collaborative analysis method for intelligent IoT devices includes the following steps:

[0012] Step 1: Build a network of intelligent well equipment, including high-computing-power wells and low-computing-power wells, and connect them to routers running an improved bidirectional PIM multicast protocol through an agricultural IoT network;

[0013] Step 2: The high-performance computing machine periodically sends improved IGMP join messages carrying busy / idle status to the directly connected router. The router synchronizes status information through PIM messages to build a dynamic collaborative resource view of the entire network.

[0014] Step 3: When a low-computing-power well detects an anomaly in the data that requires in-depth analysis, it sends an assistance request multicast message carrying the request type and well ID to the preset multicast address. The router only forwards the message to the interface that is recorded as idle.

[0015] Step 4: When forwarding assistance requests, the router starts a random delay. After the delay ends, it selects the assisting well and the backup well from the local idle wells in the order of well ID, establishes a cooperation relationship, and sends a request announcement multicast message to suppress duplicate requests.

[0016] Step 5: If the assisting well cannot respond, notify the backup well via an emergency assist message or request other idle wells across routers to take over the task;

[0017] Step 6: Assist the well in receiving abnormal data and calling the preset agricultural analysis model for processing, return the results to the requester, and update the status to idle after the task is completed.

[0018] Furthermore, in step 2, the improved IGMP join message is extended on the basis of the standard protocol format to include the ID field and the busy / idle status field of the high computing power well. The busy / idle status field records whether the well is currently processing a task, and is represented by two states: "idle" or "busy".

[0019] Furthermore, in step 2, the process of the router synchronizing state information through the improved PIM protocol specifically includes: after the leaf node router receives the improved IGMP join message of the high-performance well, it records the ID and status of the well in the interface of the corresponding multicast forwarding table, and forwards the improved PIM message carrying the same state information to the aggregation point; if the status of all interfaces of a router connected to the high-performance well is "busy", then the router sends a state summary message to the upstream, in which the well ID is empty and the status is "busy".

[0020] Furthermore, in step 4, after the delay ends, the router selects assisting and backup wells from local idle wells according to the following rules: all high-performance wells currently recorded as idle are sorted in ascending lexicographical order by their IDs, the well ranked first is selected as the assisting well, the well ranked second is selected as the backup well, and a three-way collaborative relationship is established including the requesting well, the assisting well, and the backup well; after establishing the collaborative relationship, the router immediately generates and sends a request announcement multicast message to the preset multicast address, which contains the requesting well ID and the announcement identifier; when other routers in the network receive this message, if they have cached assisting request messages from the same requesting well waiting to be forwarded, they discard them and do not forward them.

[0021] Furthermore, the emergency assistance message mentioned in step 5 includes a local backup trigger message and a cross-router assistance message; when the assisting spool receives a local task before confirming assistance, it sets the emergency assistance identifier in the received assistance request message to the first state value and forwards it to trigger the backup spool to take over; when the backup spool also fails to respond, the router sets the emergency assistance identifier to the second state value and sends a multicast message containing the added backup identifier to request idle spool resources from other routers.

[0022] Furthermore, the first status value of the emergency assistance identifier is "1", indicating that local backup takeover has been triggered; the second status value is "2", indicating that a cross-router assistance request needs to be initiated.

[0023] Furthermore, the pre-set agricultural analysis model mentioned in step 6 includes at least one analysis model used for soil moisture assessment, pest and disease identification, crop growth stage judgment, and irrigation decision-making; if the assisting well receives a local analysis task during the execution of the analysis task, it will add the local task to the waiting queue and execute it in the queue order after the current assisting analysis task is completed.

[0024] Furthermore, the well IDs within the intelligent well equipment network mentioned in step 1 adopt a hierarchical coding format of "region-field-equipment number"; the preset multicast address is a fixed IP multicast address dedicated to status synchronization and task coordination, which is uniformly configured during the network initialization phase.

[0025] Furthermore, in step 3, the assistance request multicast message, in addition to carrying the request type and well ID, also includes an assistance request identifier bit; after receiving the message, the router only forwards the message to the interfaces recorded as "idle" in the multicast forwarding table and connected to other routers, and does not forward it to the interfaces recorded as "busy".

[0026] This invention also discloses a collaborative analysis system for intelligent IoT equipment, used to implement the method, comprising:

[0027] Intelligent well equipment is divided into high-computing-power wells and low-computing-power wells;

[0028] Agricultural IoT network, including multiple routers running improved IGMP and PIM protocols;

[0029] Edge computing nodes serve as optional high-computing resources;

[0030] The collaborative scheduling module, integrated into the router, is responsible for state synchronization, request forwarding, well selection, and emergency scheduling.

[0031] The collaborative analysis method and system for intelligent IoT equipment of the present invention have the following advantages:

[0032] 1. It enables dynamic and efficient collaboration between devices, improving resource utilization and system real-time performance.

[0033] By constructing a dynamic resource view of the entire network based on an improved bidirectional PIM multicast protocol, the idle computing power of high-performance computing wells is virtualized into a shared resource pool that can be scheduled in real time. When low-performance computing wells require complex analysis, there is no need to upload data to remote cloud or edge servers. Instead, the data is processed in real time directly within the network by nearby high-performance computing wells that are in an idle state. This fundamentally overcomes the shortcomings of traditional cloud-edge architectures, such as large response latency and high network load, and realizes localized and real-time processing of analysis tasks. It is especially suitable for agricultural scenarios with high timeliness requirements (such as sudden pest and disease identification and instant irrigation decisions).

[0034] 2. An intelligent request forwarding and scheduling mechanism was designed to avoid network congestion and equipment interference.

[0035] This invention abandons the traditional broadcast or blind unicast request mode. Based on a real-time resource view, the router forwards assistance requests only to idle devices and introduces random delay and request announcement mechanisms. Random delay disperses potential high-concurrency request surges, while request announcements quickly suppress the flooding of the same request in the network, effectively preventing network congestion and ineffective interference with busy devices, ensuring efficient control signaling and overall network stability.

[0036] 3. A comprehensive three-tiered fault-tolerant system of "primary-backup-cross" has been established, which greatly enhances the reliability of the system.

[0037] The system not only assigns a primary assisting node to each assistance request but also pre-designates a local backup node, forming the first level of fault tolerance. When the primary assisting node experiences a sudden local task, it can seamlessly switch to the backup node through an emergency assistance mechanism. If the local backup is also unavailable, the second level of fault tolerance—cross-router emergency assistance—is triggered, allocating idle resources from other areas of the network. This multi-layered backup and takeover mechanism ensures that critical analysis tasks are not interrupted or abandoned when one or more nodes experience sudden failures or become overloaded, effectively guaranteeing system service continuity.

[0038] 4. It has good scalability and deployment flexibility.

[0039] The entire collaborative mechanism is based on a standard multicast protocol and does not rely on a centralized scheduling server. Newly added high- or low-computing-power wells only need to connect to the network and follow the same state synchronization protocol to automatically integrate into the collaborative system, without the need for complex global reconfiguration. The system scale can be smoothly expanded from a single field to the entire smart agricultural park, and resource scheduling efficiency will not decrease significantly with the expansion of scale, meeting the needs of large-scale, distributed deployment of modern agricultural IoT.

[0040] 5. Reduced overall system deployment and operation costs.

[0041] By tapping into and utilizing the idle computing power of existing high-performance wells, this method reduces reliance on dedicated edge computing servers or cloud computing resources, saving on hardware investment and network bandwidth costs. Simultaneously, by improving the real-time performance and accuracy of problem-solving, it can help achieve precision irrigation and timely pest and disease control, thereby conserving agricultural resources such as water, fertilizer, and pesticides, increasing crop yield and quality, and bringing significant economic benefits.

[0042] In summary, this invention, through its innovative network layer collaborative architecture, achieves comprehensive improvements in real-time performance, reliability, scalability, and cost-effectiveness, providing a highly efficient, reliable, and scalable real-time analysis solution for smart agriculture IoT. Attached Figure Description

[0043] Figure 1 This is a schematic diagram illustrating the process of networking and synchronizing the status of intelligent well equipment in an embodiment of the present invention;

[0044] Figure 2 This is a schematic diagram of the process of a low-computing-power well initiating an assistance request in an embodiment of the present invention;

[0045] Figure 3 This is a schematic diagram illustrating the process of establishing a collaborative relationship between the router and the backup system in an embodiment of the present invention.

[0046] Figure 4This is a schematic diagram illustrating the process of the emergency backup mechanism triggering local backup takeover in an embodiment of the present invention;

[0047] Figure 5 This is a schematic diagram illustrating the process of triggering a cross-router assistance request when local backup is unavailable, as described in an embodiment of the present invention.

[0048] Figure 6 This is a schematic diagram of the process for cross-router assistance establishment and task takeover in an embodiment of the present invention. Detailed Implementation

[0049] To better understand the purpose, structure, and function of this invention, the following detailed description of a collaborative analysis method and system for intelligent IoT equipment, in conjunction with the accompanying drawings, is provided.

[0050] Step 1: Establish a network for intelligent well equipment

[0051] Smart well equipment is deployed in each irrigation area of ​​the smart agriculture park. This equipment possesses basic functions such as soil temperature and humidity data acquisition, image acquisition, and communication. Some wells are equipped with high-performance processors and pre-built agricultural analysis models (capable of complex analyses such as soil moisture assessment, pest and disease identification, crop growth stage determination, and irrigation decisions), and are defined as high-computing-power wells; the rest are low-computing-power wells, supporting only basic environmental data acquisition. Each well connects to the area's aggregation gateway router via an agricultural IoT network (such as LoRa, ZigBee, or wired network). The gateway routers operate a bidirectional PIM multicast protocol, with the multicast address preset to 227.19.19.1. The well equipment ID uses the format "Area-Field-Equipment Number," such as A-03-15, representing well number 15 in field number 3 of area A.

[0052] Step 2: Multicast network status synchronization

[0053] High-performance computing rigs periodically send improved IGMP join messages to the directly connected router. These messages carry the rig ID and its busy / idle status (idle / busy). The router records the status of each rig corresponding to each interface in its multicast forwarding table and synchronizes the status information to the aggregation point via PIM messages, thus constructing a dynamic collaborative resource view of all rigs in the network.

[0054] Step 2.1: As Figure 1 As shown, each high-performance computing rig periodically (once every 60 seconds) sends an improved IGMP join message to the directly connected router. The multicast address is 227.19.19.1, and the message contains the rig ID and a status field. If the rig is not currently processing any tasks, the status field is marked as "idle"; otherwise, it is marked as "busy".

[0055] Step 2.2: If the well suddenly receives a processing task during the sending cycle, immediately send an IGMP join message and change the status field carried in the message to "busy".

[0056] Step 2.3: After receiving the IGMP message, the leaf node router directly connected to the well records the well ID and the "idle" or "busy" status on the corresponding interface of the multicast forwarding table with group address 227.19.19.1, and sends a (*, g) PIM message to the aggregation point (RP) according to the multicast processing flow. Here, * represents the source IP of the router and g represents the multicast address. The PIM message is improved here. The message needs to carry the well ID, the well source IP and the corresponding "idle" or "busy" status.

[0057] Step 2.4: If a leaf node router finds that all local member interfaces (i.e., interfaces directly connected to the well) in its multicast forwarding table for group address 227.19.19.1 are recorded as "Busy", it sends a "Busy State" (*, g) PIM message to the RP (in this PIM message, the well ID is NULL, and the status field is summarized as a unique "Busy" state). If all interfaces of the upstream router (the router facing the RP) are "Busy" except for the interface facing the RP, the router continues to forward "Busy State" PIM messages to the RP until they are sent to the RP.

[0058] Through the above mechanism, all network routers gradually synchronize the busy and idle status of their respective connected high-computing-power wells, and build a dynamic collaborative resource view.

[0059] Step 3: Assistance in initiating and forwarding requests

[0060] like Figure 2 As shown, when a low-performance well detects an anomaly in the data requiring in-depth analysis, it sends an assistance request multicast message to a preset multicast address. The message carries the request type, well ID, and assistance request identifier. Upon receiving the request, the router only forwards it to interfaces recorded as "idle" and connected to other routers to avoid interfering with busy devices.

[0061] Step 3.1: When a low-computing-power well device (such as A-03-15) detects persistent soil data anomalies or crop growth anomalies in images based on its temperature and humidity acquisition and image capture capabilities, and needs to perform in-depth analysis (such as pest and disease diagnosis, irrigation strategy formulation), and needs to submit the abnormal data for in-depth analysis, it sends a "Assistance Request" multicast message to multicast address 227.19.19.1. The multicast message should additionally include the well device ID, request type (such as "soil moisture analysis" or "pest and disease identification"), and set the "Assistance Request" tag to 1.

[0062] Step 3.2: After receiving the "Assistance Request" multicast message, the router (e.g., router A) executes the following forwarding strategy: ① Forward the "Assistance Request" multicast message towards the RP; ② Simultaneously check the multicast forwarding table of the local multicast address 227.19.19.1, and forward the "Assistance Request" multicast message to the interface that is recorded as "Idle" and has a PIM neighbor (i.e., the interface connected to other routers); ③ The interface whose local multicast forwarding table is recorded as "Busy" does not forward the "Assistance Request" multicast message.

[0063] Step 4: Assist in establishing and notifying relationships

[0064] like Figure 3 As shown, when forwarding an assistance request, the router starts a random delay. After the delay ends, it selects an assisting well and a backup well from the local idle wells in order of well ID, establishes a "request-assistance-backup" cooperative relationship, and sends a request announcement multicast message to suppress duplicate requests.

[0065] Step 4.1: If the multicast forwarding table of the router's local group address 227.19.19.1 exists on the local member interface (i.e. the interface directly connected to the well) and is recorded as "idle", in order to reduce the collective interference of the assistance requests of a few low-computing wells to many high-computing wells, all routers, after receiving the "assistance request" multicast message ("assistance request" tag is 1), will cache it and then randomly delay for 0 to 5 seconds before forwarding it (if there is a router interface recorded as "idle" at the same time - i.e. PIM neighbor interface, then follow the process of the previous step, without delay, and immediately forward the "assistance request" multicast message from the router interface). The router whose delay expires (e.g., router B) processes the "Assistance Request" multicast message and forwards it from the member interface of the multicast forwarding table to the corresponding idle well. If the router has multiple local member interfaces recorded as "idle," they are sorted by well ID from smallest to largest (e.g., wells B-04-20, B-04-21, B-04-22, etc.). Router B selects the well with the smallest ID (e.g., well B-04-20) as the assisting party, and the well with the second smallest ID (e.g., well B-04-21) as the backup well (when well B...). If, during the response to an assistance request, another analysis task needs to be processed, an emergency backup is performed by well B (04-20). Router B inserts an "Emergency ID" field (filled with the second smallest well ID) and an "Emergency Assistance" tag field into the multicast message of the "Assistance Request," and sets the tag value to 0 (the tag value ranges from 0 to 2, where 0 indicates no emergency assistance was sent, 1 indicates emergency assistance occurred, and 2 indicates an emergency assistance was added). Then, it forwards the "Assistance Request" message from the interface of the well with the smallest connection ID. It also records the assistance and emergency backup relationship between "well A-03-15 – well B-04-20 – well B-04-21."

[0066] Step 4.2: After establishing the assistance and emergency backup relationship between "Well A-03-15 - Well B-04-20 - Well B-04-21", Router B immediately generates a "Request Advertisement" multicast message (multicast address 227.19.19.1, source address is Router B's loopback IP address, additionally carrying the ID of the requesting well and the "Request Advertisement" tag set to 1), notifying other routers in the network that the request has found an assisting party. Upon receiving the "Request Advertisement" message with the "Request Advertisement" tag set to 1, other routers read the content, compare the requesting well ID in the message with the well ID in the "Assistance Request" multicast message. If they match, they discard any unforwarded "Assistance Request" messages and stop forwarding them to other idle wells to avoid duplicate requests.

[0067] If other requesting wells (such as well A-03-16) initiate assistance requests later, and router B happens to have multiple local member interfaces recorded as "idle", router B will select the next well (such as well B-04-22) from the remaining "idle" interfaces (excluding wells B-04-20 and B-04-21 which have established assistance and emergency backup relationships) in ascending order of well ID, and record the assistance and emergency backup relationships of "well A-03-16—well B-04-22—well B-04-23", as shown in Table 1.

[0068] Table 1: Assistance and Emergency Backup Relationship Table

[0069]

[0070] Step 5: Emergency Backup and Task Takeover

[0071] If the assisting rig is unable to respond due to a task conflict, the router notifies the backup rig to take over the task via an emergency assistance message; if there is no available backup rig locally, a cross-router emergency assistance request is initiated to ensure that the task is not interrupted.

[0072] like Figure 4As shown in step 5.1: After receiving the "Assistance Request" multicast from well A-03-15, the idle high-computing-power well (well B-04-20) sends a unicast confirmation message (carrying the "Agree to Assistance" tag set to 1) to the requesting well A-03-15, indicating that it can assist in the analysis. At the same time, it immediately sends an IGMP join message, changing the status field carried in the message to "Busy", indicating that there is a task to process. If another analysis task happens to occur before well B-04-20 confirms that it can assist in the analysis, well B-04-20 will set the "Emergency Assistance" tag field in the received "Assistance Request" multicast message to 1 (the tag value ranges from 0 to 2, where 0 indicates that no emergency assistance has been sent, 1 indicates that emergency assistance has occurred, and 2 indicates that emergency assistance has been added) and then send it out. Router B receives an "Emergency Assistance" multicast message with the "Emergency Assistance" tag set to 1. It extracts the "Emergency ID" (Emergency Backup Well ID B-04-21) from the message and forwards the "Emergency Assistance" multicast message from the outgoing interface that records this well ID. If this interface is a multicast member interface (an IGMP interface directly connected to a well), its state changes from "Idle" to "Busy." Simultaneously, the state of the multicast member interface that received the "Emergency Assistance" multicast message also changes from "Idle" to "Busy." After receiving the message, well B-04-21 takes over the assistance task and sends a unicast confirmation message (carrying the "Agree to Assistance" tag set to 1) to the requesting well A-03-15, indicating that it can assist in the analysis. See Table 2.

[0073] Table 2: Assistance and Emergency Backup Relationship Table

[0074]

[0075] like Figure 5 As shown in step 5.2: If the Emergency Backup Well ID field in the Local Assistance and Emergency Backup Relationship Table of Router B is NULL, there are two possibilities: ① Router B discovers that under the forwarding table of group address 227.19.19.1, there is only one outgoing interface recorded as "idle," and the emergency assistance tag is 0. ② In the previous step, emergency backup well B-04-21 also happens to be performing other analysis tasks. Since there are no other backup wells, well B-04-21 sets the "emergency assistance" tag value in the received "assistance request" multicast message to 2 and sends it out. After receiving it, Router B knows that well B-04-21 cannot perform assistance analysis and needs to seek help from other routers. At the same time, it changes the status of the multicast member interface that received the "emergency assistance" multicast message from "idle" to "busy," deletes the corresponding emergency backup well ID data in the Local Assistance and Emergency Backup Relationship Table, and the field value is NULL, as shown in Table 3.

[0076] Table 3: Assistance and Emergency Backup Relationship Table

[0077]

[0078] like Figure 6 As shown, Router B immediately sends an "Add Emergency Assistance Backup" multicast message (inserting the "Add Backup" tag and setting it to 1 in the "Assistance Request" multicast message, with the source address being Router B's loopback IP address). After Router C, whose delay expires next, receives this message, it queries the multicast forwarding table outgoing interface with the local group address 227.19.19.1. If an interface with a record status of "Idle" exists, it extracts the well ID (e.g., C-05-11) of the interface record, generates an acknowledgment message, and unicasts it to Router B. After receiving the message, Router B updates its local assistance and emergency backup relationship table to "Well A-03-15—Well B-04-20—Well C-05-11", and sets the emergency assistance tag to 1 (changing it from 2 to 1). At this point, router B will insert an "Emergency Assistance" tag field into the "Assistance Request" message received from well A-03-15, set the tag value to 1, and forward the "Emergency Assistance" multicast message from the outgoing interface of the recorded emergency backup well ID C-05-11 (i.e., the outgoing interface connected to router C). After receiving the message, well C-05-11 will take over this assistance task. It will send a unicast confirmation message (carrying the "Agree to Assistance" tag set to 1) to the requesting well A-03-15, indicating that it can assist in the analysis, as shown in Table 4.

[0079] Table 4: Assistance and Emergency Backup Relationship Table

[0080]

[0081] Step 5.3: Router C simultaneously sends a multicast message with a destination address of 227.19.19.1, indicating "Backup addition complete" (the message carries the requester's well ID and the "Backup addition complete" tag set to 1). The router forwards the message to the router interface that is "idle" in the forwarding table of the local group address 227.19.19.1, i.e., the PIM neighbor interface. If other routers whose delays expire subsequently receive the "Backup addition complete" multicast message, they will not process the "Add emergency backup assistance" multicast message they have already received.

[0082] Step 6: Collaborative Analysis Execution

[0083] The assisting well receives abnormal data sent by the requester, processes it using a pre-set agricultural analysis model, and returns the results to the requester. After completing the task, the assisting well's status returns to idle, and it resends a status update message.

[0084] Step 6.1: After receiving confirmation from well B-04-20, well A-03-15 sends the collected abnormal soil data sequence or crop image to well B-04-20 via unicast. Well B-04-20 calls its own agricultural analysis model (such as a pest and disease diagnosis model or irrigation strategy model) to analyze and identify the results (such as "Leaf brown spot disease detected, it is recommended to spray the corresponding agent", "Insufficient soil moisture, it is recommended to start drip irrigation for 30 minutes", or "No significant abnormality detected", etc.) and returns them to well A-03-15 via unicast. After the task is completed, the status of well B-04-20 is restored to "idle" and it resends the IGMP join message, modifying the status field carried in the message to "idle". If a local analysis task needs to be processed during the execution of an analysis task, the well equipment B-04-20 will arrange the local task in the task queue and wait for it. The notification will be displayed on the local control terminal screen or sent through the agricultural management platform: "Currently processing an auxiliary analysis task in another area, please wait." The local analysis task will be processed after the auxiliary analysis task is completed.

[0085] Step 6.2: Well A-03-15 performs the corresponding operation based on the recognition result (such as notifying property management, issuing voice reminders, recording logs, etc.).

[0086] The present invention also provides an intelligent well collaborative analysis system for implementing the above method, comprising:

[0087] Intelligent well equipment is divided into high-computing-power wells and low-computing-power wells;

[0088] Agricultural IoT network, including multiple routers running improved IGMP and PIM protocols;

[0089] Edge computing nodes serve as optional high-computing resources;

[0090] The collaborative scheduling module, integrated into the router, is responsible for state synchronization, request forwarding, well selection, and emergency scheduling.

[0091] This invention is applicable to various smart agriculture scenarios, especially suitable for deployment environments such as large-scale farmland, smart agricultural parks, and demonstration zones. It can effectively improve the real-time performance, accuracy, and system reliability of agricultural data analysis and has good prospects for promotion and application.

[0092] It is understood that the present invention has been described through some embodiments, and those skilled in the art will recognize that various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of the invention. Furthermore, under the teachings of the present invention, these features and embodiments can be modified to adapt to specific situations and materials without departing from the spirit and scope of the invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are within the protection scope of the present invention.

Claims

1. A collaborative analysis method for intelligent IoT equipment, characterized in that, Includes the following steps: Step 1: Build a smart well equipment network, including high-computing-power wells and low-computing-power wells, and connect them to routers running the improved bidirectional PIM multicast protocol through the agricultural IoT network; PIM messages need to carry the well ID, well source IP and corresponding "idle" or "busy" status; Step 2: The high-performance computing machine periodically sends improved IGMP join messages carrying busy / idle status to the directly connected router. The router synchronizes status information through improved PIM messages and builds a dynamic collaborative resource view of the entire network. The improved IGMP add message extends the standard protocol format to include the ID field and the busy / idle status field of the high-computing-power well. The busy / idle status field records whether the well is currently processing a task, and is represented by two states: "idle" or "busy". The process of routers synchronizing state information through the improved PIM protocol specifically includes: after receiving the improved IGMP join message from a high-performance computing rig, the leaf node router records the rig's ID and status in the corresponding multicast forwarding table interface, and forwards the improved PIM message carrying the same state information to the aggregation point; if all interfaces of a router connected to a high-performance computing rig are in the "busy" state, the router sends a state summary message upstream, in which the rig ID is empty and the status is "busy"; Step 3: When a low-computing-power well detects an anomaly in the data that requires in-depth analysis, it sends an assistance request multicast message carrying the request type and well ID to the preset multicast address. The router only forwards the message to the interface that is recorded as idle. Step 4: When forwarding assistance requests, the router starts a random delay. After the delay ends, it selects the assisting well and the backup well from the local idle wells in the order of well ID, establishes a cooperation relationship, and sends a request announcement multicast message to suppress duplicate requests. Step 5: If the assisting well cannot respond, notify the backup well via an emergency assist message or request other idle wells across routers to take over the task; Step 6: Assist the well in receiving abnormal data and calling the preset agricultural analysis model for processing, return the results to the requester, and update the status to idle after the task is completed.

2. The method according to claim 1, characterized in that, In step 4, after the delay ends, the router selects assisting and backup wells from the local idle wells according to the following rules: sort all high computing power wells currently recorded as idle in ascending lexicographical order by their IDs, select the well ranked first as the assisting well, select the well ranked second as the backup well, and establish a three-way collaborative relationship including the requesting well, the assisting well, and the backup well. After establishing the cooperative relationship, the router immediately generates and sends a request announcement multicast message to the preset multicast address. The message contains the requester's well ID and the announcement identifier. If other routers in the network receive the message and have cached assistance request messages from the same requester well waiting to be forwarded, they will discard the message and will not forward it.

3. The method according to claim 1, characterized in that, The emergency assistance message mentioned in step 5 includes a local backup trigger message and a cross-router assistance message; when the assisting rig receives a local task before confirming assistance, it sets the emergency assistance identifier in the received assistance request message to the first state value and forwards it to trigger the backup rig to take over. When the backup well also fails to respond, the router sets the emergency assistance flag to the second state value and sends a multicast message containing the added backup flag to request available well resources from other routers.

4. The method according to claim 3, characterized in that, The first status value of the emergency assistance identifier is "1", indicating that local backup takeover has been triggered; the second status value is "2", indicating that a cross-router assistance request needs to be initiated.

5. The method according to claim 3, characterized in that, The pre-set agricultural analysis model mentioned in step 6 includes at least one analysis model used for soil moisture assessment, pest and disease identification, crop growth stage judgment, and irrigation decision-making; if the assisting well receives a local analysis task during the execution of the analysis task, it will add the local task to the waiting queue and execute it in the queue order after the current assisting analysis task is completed.

6. The method according to claim 1, characterized in that, The well IDs in the intelligent well equipment network mentioned in step 1 adopt a hierarchical coding format of "region-field-equipment number"; the preset multicast address is a fixed IP multicast address dedicated to status synchronization and task coordination, which is uniformly configured during the network initialization phase.

7. The method according to claim 1, characterized in that, In step 3, the assistance request multicast message, in addition to carrying the request type and well ID, also includes an assistance request identifier bit; after receiving the message, the router only forwards the message to the interfaces recorded as "idle" in the multicast forwarding table and connected to other routers, and does not forward it to the interfaces recorded as "busy".

8. A collaborative analysis system for intelligent IoT equipment, used to implement the method according to any one of claims 1 to 7, characterized in that, include: Intelligent well equipment is divided into high-computing-power wells and low-computing-power wells; Agricultural IoT network, including multiple routers running improved IGMP and PIM protocols; Edge computing nodes serve as optional high-computing resources; The collaborative scheduling module, integrated into the router, is responsible for state synchronization, request forwarding, well selection, and emergency scheduling.

Images