Analysis method and system for accurate collaboration between Internet of Things terminals

Abstract

The invention belongs to the field of internet-of-things cooperative computing, discloses an analysis method and system for accurate cooperation between internet-of-things terminals, and is suitable for internet-of-things scenes such as smart agriculture. According to the method, a bidirectional PIM multicast protocol is operated between routers by constructing an Internet of Things cluster comprising a high-computing-power motor-pumped well and a low-computing-power motor-pumped well. The system realizes equipment state synchronization and assistant path pre-construction through an improved IGMP / PIM protocol, and when a low-computing-power motor-pumped well initiates a task request, the task request can be accurately scheduled to a high-computing-power motor-pumped well according to the pre-constructed path. A state triggering type updating mechanism is adopted, global state revocation is triggered only when all subordinate devices are busy, and network overhead is greatly reduced. The system realizes efficient computing power collaboration between devices, and significantly improves the task response speed and the resource utilization rate.

Description

Technical Field

[0001] This invention belongs to the field of IoT collaborative computing, and in particular relates to an analysis method and system for precise collaboration among IoT terminals. Background Technology

[0002] In large-scale farmland and smart agricultural parks, intelligent well equipment is widely deployed in various irrigation areas, possessing basic data collection and monitoring capabilities. However, due to limitations in computing power or cost, some well equipment only possesses basic functions such as temperature and humidity data collection, and cannot independently complete complex advanced agricultural analysis tasks such as soil moisture analysis, pest and disease identification, and irrigation decision-making. Existing systems lack an efficient cross-device computing power scheduling mechanism, making it difficult for low-computing-power wells to obtain timely and accurate assistance from idle high-computing-power wells when complex analyses are needed. This affects the real-time performance and decision-making efficiency of agricultural analysis, and frequent global requests excessively consume network and device resources. Summary of the Invention

[0003] The purpose of this invention is to provide an analysis method and system for precise collaboration among IoT terminals, so as to solve the above-mentioned technical problems.

[0004] To address the aforementioned technical problems, the specific technical solution of the analysis method and system for precise collaboration among IoT terminals of the present invention is as follows: An analytical method for precise collaboration among IoT terminals includes the following steps: Step 1: Build an IoT cluster: Deploy two types of well equipment and routers, one with high computing power and the other with low computing power, in the target area, and run a bidirectional PIM multicast protocol between the routers; Step 2: State Synchronization and Path Pre-construction: Each well device periodically sends improved IGMP messages to the directly connected router to report its status, including "idle" / "busy" for high-performance wells and "requesting help" for low-performance wells; the router forwards the status information to the aggregation point RP, and the RP generates and distributes "assist" path information based on the "requesting help" and "idle" statuses, pre-constructing the logical path from the requesting router to the idle router; Step 3: Task Request and Directed Forwarding: When a low-performance rig needs assistance, it sends a "Need Assistance Analysis" request to the directly connected router. The router selects one or more target assisting routers based on the pre-built path, generates a "Directed Assistance Request" message, forwards it to the target router via the RP, and then selects a specific high-performance rig to receive the task. Step 4: Task Execution and Dynamic Status Maintenance: The selected high-performance computing spool establishes a unicast connection with the requesting spool and executes the analysis task, and its status is updated to "busy"; if all high-performance computing spools under a router are "busy", the global status revocation mechanism is triggered to clear their assistance records. Step 5: Status Recovery: After the task is completed, the high-performance well status is restored to "idle" and the status information is updated. If its router meets the idle condition again, it will be re-registered to the assisting resource pool.

[0005] Furthermore, in step 1, the well equipment ID is identified using the format "region-field-equipment number".

[0006] Furthermore, in step 2, the IGMP message adds "Well ID" and "Status" fields; among them, high-computing-power wells fill in "Idle" or "Busy" according to their own load, and low-computing-power wells fill in "Request for Help".

[0007] Furthermore, in step 2, the establishment of the logical path specifically includes: Step 2.1: After receiving the IGMP message from the well device, the router records the well ID and status of the corresponding interface in its multicast forwarding table; Step 2.2: The router sends an improved PIM message to the aggregation point RP according to the status recorded in its multicast forwarding table. The PIM message carries the router ID and status identifier. Step 2.3: After receiving a PIM message with a status of "Help" and at least one PIM message with a status of "Idle", the RP generates a new "Assist" PIM message and forwards it to the router that sent the "Help" PIM message. Step 2.4: After receiving the "Assistance" PIM message, the routers along the route record it in their own multicast forwarding table, thereby completing the logical path construction from the requesting router to at least one idle router.

[0008] Furthermore, in step 3, the preset strategy by which the router selects one or more target assisting routers includes: the ID size order of the target assisting routers, the number of "idle" wells connected to them, or a load balancing strategy.

[0009] Furthermore, in step 3, the "targeted assistance request" multicast message carries the following information: the ID and source IP of the low-power well that initiated the request, the IDs of one or more target assistance routers, and the number of "connected idle wells" corresponding to each target assistance router.

[0010] Furthermore, in step 3, before forwarding the message to each target assisting router, the RP copies the "directed assistance request" multicast message, modifies the "assistance" status carried in the copied message to the "idle" status, and then forwards it to the corresponding target assisting router.

[0011] Furthermore, in step 4, the dynamic maintenance of the state specifically includes: Step 4.1: During the execution of the task, the high-performance computing well continuously sends IGMP messages with a status of "busy" to the directly connected router; Step 4.2: When the status of all high-performance machine interfaces under a router changes to "busy" in the multicast forwarding table, the router immediately sends a "cancel idle" PIM message to the RP; Step 4.3: After receiving the "Cancel Idle" PIM message, the RP generates and sends a "Cancel Assistance" PIM message to the router in the "Request for Help" or "Need Assistance for Analysis" state. Step 4.4: After receiving the "Withdraw Assistance" PIM message, the routers along the route and the target router delete all assistance records related to the router's ID from their multicast forwarding tables.

[0012] This invention also discloses an analysis system for precise collaboration among IoT terminals, used to implement the method, comprising: High-performance and low-performance wells are used for data acquisition and processing. Multiple routers form a bidirectional PIM multicast network with preset multicast addresses; The rendezvous point (RP) is used to receive status information reported by each router and to establish and maintain cooperative paths. The well equipment is configured to report its status to the directly connected router and initiate assistance requests when necessary. The router is configured to maintain status information and pre-built paths, and selects a target assisting router according to a preset policy; The RP is configured to coordinate the establishment of an assistance path based on status information, and to copy and forward messages when a task request is received.

[0013] The analysis method and system for precise collaboration among IoT terminals of the present invention have the following advantages: The system uses an improved IGMP / PIM protocol to synchronize the "idle," "busy," and "request for assistance" status of each silo in real time within the cluster, forming a global resource view. When a low-performance silo initiates an analysis request, it can quickly and accurately direct the task to the optimal idle high-performance silo based on pre-established assistance paths, significantly improving task response speed and resource utilization. A state-triggered path pre-building and update mechanism avoids frequent network-wide flooding queries. A global state cancellation announcement is only triggered when all high-performance silos under the router are in a "busy" state, significantly reducing network signaling overhead and device resource consumption. Attached Figure Description

[0014] Figure 1 This is a schematic diagram of the system structure for the state synchronization and cooperative path pre-construction process in an embodiment of the present invention; Figure 2 This is a schematic diagram of the router multicast forwarding table status record in an embodiment of the present invention; Figure 3 This is a schematic diagram of the system structure for the initiation and targeted forwarding process of precise assistance requests in an embodiment of the present invention. Detailed Implementation

[0015] To better understand the purpose, structure, and function of this invention, the following detailed description, in conjunction with the accompanying drawings, provides an analysis method and system for precise collaboration among IoT terminals.

[0016] Step 1: Building a Smart Well Equipment Network Within a target management area (such as an entire smart agriculture park), all smart well equipment and network routers are deployed, forming a unified IoT processing cluster. The smart well equipment is divided into two categories based on computing power: high-computing-power wells equipped with high-performance processors and agricultural analysis models (capable of complex analyses such as soil moisture assessment, pest and disease identification, crop growth stage determination, and irrigation decisions), and low-computing-power wells with only basic data collection functions. All well equipment within the cluster connects to the routers within the cluster via an agricultural IoT network (such as LoRa, ZigBee, or a wired network). These routers operate a bidirectional PIM multicast protocol (preset multicast address 227.18.18.1), forming an internal multicast distribution network. The well equipment ID uses the format "region-field-equipment number," such as A-03-15, representing well number 15 in field number 3 of region A.

[0017] Step 2: State Synchronization and Cooperative Path Pre-construction All IoT terminals (well equipment) periodically send improved IGMP join messages to the directly connected router. These messages carry the device ID and status identifier: high-performance terminals report "idle" or "busy" based on their load, while low-performance terminals consistently report "help". The router records the status of each interface in its multicast forwarding table and forwards PIM messages carrying status information to the rendezvous point (RP). Based on the "help" and "idle" status information, the RP proactively generates "assist" PIM messages and sends them towards the requesting router. Routers along the path record assistance path information in their multicast forwarding tables, thus pre-establishing one or more logical paths from the requesting router to potential assisting routers.

[0018] Step 2.1: Each well device periodically sends an improved IGMP join message (multicast address 227.18.18.1) to the directly connected router. In addition to the regular fields, the message includes two new fields: "Well ID" and "Status": high-performance wells fill in "Idle" or "Busy" based on their load; low-performance wells always fill in "Help". If a high-performance well changes from idle to busy during a transmission interval, it immediately sends an IGMP message update with a "Busy" status.

[0019] Step 2.2: After receiving the IGMP message, the leaf routers directly connected to the well (such as routers A, B, and C) record the well ID and status ("idle", "busy", or "help") on the corresponding output interface of the forwarding table of multicast group 227.18.18.1: The status of the interfaces of router A connected to well A-03-15 and A-03-16 is "help"; the status of the interface of router B connected to well B-05-11 is "idle" and the status of the interface connected to well B-05-12 is "busy"; the status of the interfaces of router C connected to well C-06-01 and C-06-02 is "idle".

[0020] Step 2.3: As Figure 1 As shown: A router (such as router A) with a forwarding table interface status of "Help" in multicast group 227.18.18.1 sends an improved (*, g) PIM join message towards the aggregation point (RP), where * represents the source IP of the router and g represents the multicast address. This PIM message carries the ID of router A and adds a "Status" field filled with "Help". Routers along the way and the RP record the ID of router A with a status of "Help" on the ingress interface corresponding to this upstream direction in the (*, 227.18.18.1) multicast forwarding table. Routers (such as routers B and C) with a forwarding table interface status of "Idle" in multicast group 227.18.18.1 also send improved (*, g) PIM join messages towards the aggregation point (RP). The PIM message carries the ID of router B or C, the number of "connection idle wells", and adds a "status" field filled with "idle". Routers along the way and RP record the ID of router B or C, the number of "connection idle wells", and the status "idle" on the ingress interface corresponding to this upstream direction in the multicast forwarding table of (*,227.18.18.1).

[0021] Step 2.4: After receiving a "Help" PIM message from router A (carrying router A's ID and "Help" status field) and a "Free" PIM message from router B or C (carrying router B or C's ID, the number of "free connection wells," and the "Free" status field), the RP begins establishing logical paths for the "Help" end and the "Free" end. Taking routers B and C as examples of "Free" ends, the RP generates a new PIM message (carrying router B and C's IDs, the number of "free connection wells," and modifies the "Free" status field to "Help"), queries its own forwarding table (*, 227.18.18.1), and forwards this "Help" PIM message from the interface GigabitEthernet (abbreviated as G in the attached diagram) 0 / 1 that records the "Help" status. After receiving a "Help" PIM message, the routers along the path query their local forwarding table (*, 227.18.18.1). They find the message originates from the upstream interface in the RP direction and carries a "Help" status field, the IDs of routers B and C, and the number of "connection idle wells." They then record the "Help" status field, the IDs of routers B and C, and the number of "connection idle wells" on the receiving interface. They also generate a PIM message with the same "Help" status field and the IDs of routers B and C, and send it out from the interface whose forwarding table (*, 227.18.18.1) records the "Help" status. Other routers along the path perform the same operation until router A receives the "Help" PIM message. Figure 2 As shown: Router A received a "Assist" PIM message from interface GigabitEthernet0 / 1 and recorded the "Assist" status field carried in the message, the IDs of routers B and C, and the number of "connection idle wells" (2 for router B and 3 for router C) on the GigabitEthernet0 / 1 forwarding table (*, 227.18.18.1).

[0022] Through the above process, one or more known "help-assist" logical paths pointing to potential assisting routers (routers B and C) are pre-constructed within the cluster for each router (such as router A) that issues a "help" PIM, and are recorded in the (*, 227.18.18.1) multicast forwarding table of each router on the path.

[0023] Step 3: Initiating and Directing Assistance Requests When a low-performance terminal detects a task requiring in-depth analysis, it sends an IGMP request message with a "Need Assistance for Analysis" status to the directly connected router. Based on pre-built path information, the router selects one or more target assisting routers from the list of interfaces with the "Assistance" status and determines the number of idle devices each router connects to according to preset policies (such as the number of idle devices, load balancing, etc.). The router generates a "Directed Assistance Request" multicast message, carrying the target router ID and the number of connected idle devices, and forwards it to the RP along the pre-built path. The RP replicates the message and forwards it to each target assisting router, ultimately allowing each assisting router to select a specific high-performance terminal to receive the task request.

[0024] Step 3.1: As Figure 3 As shown: When a low-computing-power well (such as well A-03-15, connected to router A) detects continuous abnormalities in soil data or abnormal crop growth in images based on its temperature and humidity acquisition and image capture capabilities, it needs to perform in-depth analysis (such as disease and pest diagnosis, irrigation strategy formulation) and needs to submit the abnormal data for in-depth analysis. At this time, it sends an IGMP join message with the multicast address 227.18.18.1 to its directly connected router A, which carries the ID of well A-03-15, the source IP of well A-03-15, and sets the status field to "needs assistance for analysis". At the same time, the IGMP message carries the specific request type (such as "soil moisture analysis" or "disease and pest identification"). It should be noted that the status field of the IGMP message sent by well A-03-15 has changed from "help" to "needs assistance for analysis". In step (4) of the first section, the router that sent the "help" PIM message will also send this PIM message out from the interface with the status field "needs assistance for analysis" in the forwarding table (*, 227.18.18.1).

[0025] Step 3.2: After receiving this "Assistance Required for Analysis" IGMP message, Router A records the ID of well A-03-15 and the source IP of well A-03-15 in the message on the corresponding interface GigabitEthernet0 / 2 of the (*,227.18.18.1) multicast forwarding table entry. At the same time, it selects one or more target assisting routers from the list of outgoing interfaces recorded in the forwarding table that have the "Assistance" status field, router ID, and number of "connected idle wells" according to the preset strategy (such as minimum router ID, number of "idle" wells, or load balancing). For example, if router B is selected first based on router ID, but when the number of "Assistance Required for Analysis" wells connected to router A exceeds the number of "idle" wells connected to router B, router C is selected to handle the remaining "Assistance" requests. It also specifies the number of "connected idle wells" corresponding to each router ID. The "number of connected idle wells" here refers to the number of "idle" wells that the target router is connected to by router A. For example, if router A has two wells that have initiated "need assistance analysis", namely wells A-03-15 and A-03-16, and router A queries the forwarding table and finds that router B has 1 "idle" well and router C has 2 "idle" wells, but router B has a smaller ID, router A selects router B as the target assist router. However, since router B is only connected to 1 "idle" well, the number of "connected idle wells" is 1. Router A also needs to select router C as the target assist router because the 1 "need assistance analysis" well connected to router A is already connected to a "idle" well of router B, so the number of "connected idle wells" of router C is 2-1=1.

[0026] Step 3.3: Router A generates a "Directed Assistance Request" multicast message with a destination address of 227.18.18.1. This message carries the ID of the assisting router A-03-15, the source IP of A-03-15, and the "Assistance Request" field set to 1. It also explicitly carries the IDs of the target routers B and C and the corresponding number of "connected idle routers". Note: When multiple target "assisting" routers (such as routers B and C) are selected, router A will aggregate multiple router IDs and other relevant information into a single "Directed Assistance Request" multicast message for forwarding. Router A queries its local (*, 227.18.18.1) forwarding table and forwards this message from the outgoing interface GigabitEthernet0 / 4, which records the IDs of routers B and C and the "assistance" flag. Routers along the route, based on the target routers B and C's IDs and "Assistance" status flags in the "Directed Assistance Request" multicast message, query their local (*, 227.18.18.1) multicast forwarding table to find interfaces recording the same router IDs and status flags for matching and forwarding, until the message reaches the RP (due to the bidirectional PIM network environment, according to the protocol, multicast messages must first be sent to the aggregation node RP before being forwarded to the target node). Upon receiving the "Directed Assistance Request" multicast message, the RP finds that the message carries target router IDs as routers B and C. The RP queries its local (*, 227.18.18.1) forwarding table and finds that interface GigabitEthernet0 / 2 records router B's ID, "Idle" status, and "Idle" well count as 1; interface GigabitEthernet0 / 3 records router C's ID, "Idle" status, and "Idle" well count as 2. At this point, the RP intercepts the "Directed Assistance Request" multicast message and copies it. One copy changes the "Assistance" state to "Idle," retains the target router ID as only B, and includes a "Connecting Idle Wells" count of 1. This copy is then forwarded from the outgoing interface GigabitEthernet0 / 2. The other copy changes the "Assistance" state to "Idle," retains the target router ID as only C, and includes a "Connecting Idle Wells" count of 1. This copy is then forwarded from the outgoing interface GigabitEthernet0 / 3. Routers along the route, based on the target router B or C ID and the "Idle" state flag in the "Directed Assistance Request" multicast message, query their local (*, 227.18.18.1) multicast forwarding table to find interfaces with the same router ID and state flag, and forward the message until it reaches routers B and C.

[0027] Step 3.4: After receiving the "Directed Assistance Request," Router B selects one high-performance machine (e.g., machine B-05-11) from its local (*, 227.18.18.1) multicast forwarding table members with a status of "idle" based on the number of "connected idle machines" in the message, according to a strategy (e.g., ID order), and forwards the "Directed Assistance Request" message to it. After receiving the "Directed Assistance Request," Router C selects one high-performance machine (e.g., machine C-06-01) from its local (*, 227.18.18.1) multicast forwarding table members with a status of "idle" based on the number of "connected idle machines" in the message, according to a strategy (e.g., ID order), and forwards the "Directed Assistance Request" message to it.

[0028] Step 4: Collaborative Analysis Execution and Dynamic Status Maintenance After receiving a "directed assistance request," the selected high-computing-power terminal directly establishes a unicast connection with the requesting low-computing-power terminal, receives the data to be analyzed, processes it using its local model, and returns the results via unicast. During task execution, the high-computing-power terminal's status is updated to "busy." If all high-computing-power terminals under a router are in a "busy" state, the router immediately sends a "cancel idle" PIM message to the RP, triggering the RP to send a "cancel assistance" message, clearing the router's assistance record along the original path and preventing subsequent invalid scheduling.

[0029] Step 4.1: Taking router B as an example, the high-performance machine (machine B-05-11) that receives the "Directed Assistance Request" message extracts the source IP of machine A-03-15 in the message and sends a unicast confirmation to the requesting machine (machine A-03-15). Then, it receives the analysis data (such as images and sensor data) sent by machine A-03-15, calls the local model for processing, and returns the result via unicast.

[0030] Step 4.2: After router B assigns the task (i.e., forwards the "Directed Assistance Request" message) to well B-05-11, the interface status of well B-05-11 in the multicast forwarding table of group address 227.18.18.1 changes from "Idle" to "Busy," and well B-05-11 subsequently starts sending IGMP messages carrying the "Busy" status field. If the status of all interfaces connected to high-performance wells in router B's (*, 227.18.18.1) multicast forwarding table becomes "Busy" (i.e., the number of interfaces carrying the "Idle" status drops to 0), then the condition for sending "Idle" messages is no longer met. Router B must immediately send a "Cancel Idle" PIM message to the RP direction, carrying the "Cancel Idle" tag set to 1, and also carrying router B's ID. Upon receiving this "Cancel Idle" PIM message, the routers along the route delete the entire record related to Router B's ID on the interface in the (*, 227.18.18.1) forwarding table that received this message, and generate a new "Cancel Idle" PIM message, continuing to send it towards the RP. If the RP receives this message, deletes the entire record related to Router B's ID on the interface in the (*, 227.18.18.1) forwarding table that received this message, and generates a new "Cancel Assistance" PIM message carrying a "Cancel Assistance" tag set to 1, and carrying Router B's ID, it sends this PIM message out from the upstream interface in the (*, 227.18.18.1) forwarding table with a status field of "Help" or "Assistance Required for Analysis," that is, it sends this "Cancel Assistance" PIM message towards Router A connected to the "Help" or "Assistance Required for Analysis" silo. Upon receiving a "Withdraw Assistance" PIM message, routers along the route delete the entire record related to router B's ID on the interface in the forwarding table (*, 227.18.18.1) that received this message, and generate a new "Withdraw Assistance" PIM message, continuing to send it towards router A. Upon receiving this "Withdraw Assistance" PIM message, router A deletes the entire record related to router B's ID on the interface in the forwarding table (*, 227.18.18.1) that received this message, ensuring that subsequent requests are no longer forwarded to B, which has no available resources.

[0031] Step 4.3: As long as router B still has at least one "idle" interface in the multicast forwarding table of group address 227.18.18.1, it still meets the condition of "having a directly connected idle member". Therefore, there is no need to immediately send a "withdraw assistance" PIM message to the RP direction. This avoids frequent global signaling caused by changes in the state of a single router.

[0032] Step 5: Task Completion and Status Restoration After a high-performance terminal completes its task, its state returns to "idle" and it sends an IGMP message to update the interface state. If this state restoration allows its router to once again meet the condition of "having a directly connected idle terminal," the router resends an "idle" state PIM message to the RP to regain its eligibility in the global cooperative resource pool. This mechanism ensures that changes in resource state can be synchronized to the entire system in a timely and low-overhead manner.

[0033] After assisting well B-05-11 in completing its analysis task, its status returns to "idle," and it sends an IGMP message to update the interface status. If this recovery causes router B to once again meet the "existence of a directly connected idle member" condition, it will resend an IGMP join message with the status field set to "idle" to reconnect to the assistance resource pool.

[0034] The present invention provides an analysis system for precise collaboration among IoT terminals, comprising: High-performance and low-performance wells are used for data acquisition and processing. Multiple routers form a bidirectional PIM multicast network with preset multicast addresses; The rendezvous point (RP) is used to receive status information reported by each router and to establish and maintain cooperative paths. The well equipment is configured to report its status to the directly connected router and initiate assistance requests when necessary. The router is configured to maintain status information and pre-built paths, and selects a target assisting router according to a preset policy; The RP is configured to coordinate the establishment of an assistance path based on status information, and to copy and forward messages when a task request is received.

[0035] 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. An analytical method for precise collaboration among IoT terminals, characterized in that, Includes the following steps: Step 1: Build an IoT cluster: Deploy two types of well equipment and routers, one with high computing power and the other with low computing power, in the target area, and run a bidirectional PIM multicast protocol between the routers; Step 2: State Synchronization and Path Pre-construction: Each well device periodically sends an improved IGMP message to the directly connected router to report its status, including "idle" / "busy" for high-performance wells and "help" for low-performance wells; the router forwards the status information to the aggregation point RP, and the RP generates and distributes "assist" path information based on the "help" and "idle" status, pre-constructing the logical path from the help router to the idle router; Step 3: Task Request and Directed Forwarding: When a low-performance rig needs assistance, it sends a "Need Assistance Analysis" request to the directly connected router. The router selects one or more target assisting routers based on the pre-built path, generates a "Directed Assistance Request" message, forwards it to the target router via the RP, and then selects a specific high-performance rig to receive the task. Step 4: Task Execution and Dynamic Status Maintenance: The selected high-performance computing spool establishes a unicast connection with the requesting spool and executes the analysis task, and its status is updated to "busy"; if all high-performance computing spools under a router are "busy", the global status revocation mechanism is triggered to clear their assistance records; Step 5: Status Recovery: After the task is completed, the high-performance well status is restored to "idle" and the status information is updated. If its router meets the idle condition again, it will be re-registered to the assisting resource pool.

2. The method according to claim 1, characterized in that, In step 1, the well equipment ID is identified using the format "region-field-equipment number".

3. The method according to claim 1, characterized in that, In step 2, the IGMP message adds "Well ID" and "Status" fields; among them, high-computing-power wells fill in "Idle" or "Busy" according to their own load, and low-computing-power wells fill in "Help".

4. The method according to claim 1, characterized in that, Step 2, the establishment of the logical path specifically includes: Step 2.1: After receiving the IGMP message from the well device, the router records the well ID and status of the corresponding interface in its multicast forwarding table; Step 2.2: The router sends an improved PIM message to the aggregation point RP according to the status recorded in its multicast forwarding table. The PIM message carries the router ID and status identifier. Step 2.3: After receiving a PIM message with a status of "Help" and at least one PIM message with a status of "Idle", the RP generates a new "Assist" PIM message and forwards it to the router that sent the "Help" PIM message. Step 2.4: After receiving the "Assistance" PIM message, the routers along the route record it in their own multicast forwarding table, thereby completing the logical path construction from the requesting router to at least one idle router.

5. The method according to claim 1, characterized in that, In step 3, the preset strategies by which the router selects one or more target assisting routers include: the ID size order of the target assisting routers, the number of "idle" wells connected to them, or a load balancing strategy.

6. The method according to claim 1, characterized in that, In step 3, the "targeted assistance request" multicast message carries the following information: the ID and source IP of the low-power well that initiated the request, the IDs of one or more target assisting routers, and the number of "connected idle wells" corresponding to each target assisting router.

7. The method according to claim 1, characterized in that, In step 3, before forwarding the message to each target assisting router, the RP copies the "Directed Assistance Request" multicast message, modifies the "Assistance" status carried in the copied message to the "Idle" status, and then forwards it to the corresponding target assisting router.

8. The method according to claim 1, characterized in that, Step 4, the dynamic maintenance of the state specifically includes: Step 4.1: During the execution of the task, the high-performance computing well continuously sends IGMP messages with a status of "busy" to the directly connected router; Step 4.2: When the status of all high-performance machine interfaces under a router changes to "busy" in the multicast forwarding table, the router immediately sends a "cancel idle" PIM message to the RP; Step 4.3: After receiving the "Cancel Idle" PIM message, the RP generates and sends a "Cancel Assistance" PIM message to the router in the "Request for Help" or "Need Assistance for Analysis" state. Step 4.4: After receiving the "Withdraw Assistance" PIM message, the routers along the route and the target router delete all assistance records related to the router's ID from their multicast forwarding tables.

9. An analysis system for precise collaboration among IoT terminals, used to implement the method according to any one of claims 1 to 8, characterized in that, include: High-performance and low-performance wells are used for data acquisition and processing. Multiple routers form a bidirectional PIM multicast network with preset multicast addresses; The rendezvous point (RP) is used to receive status information reported by each router and to establish and maintain cooperative paths. The well equipment is configured to report its status to the directly connected router and initiate assistance requests when necessary. The router is configured to maintain status information and pre-built paths, and selects a target assisting router according to a preset policy; The RP is configured to coordinate the establishment of an assistance path based on status information, and to copy and forward messages when a task request is received.

Images