Anti-control data routing and distributing method of multi-node fire fighting system

Abstract

The invention discloses an anti-control data routing and distribution method and system of a multi-node fire fighting system, and belongs to the technical field of fire fighting alarm control. The method comprises the following steps: a central control node generates and distributes a time slot rotation table for a plurality of remote nodes based on a preset node list and time slot parameters; the central control node receives and caches a reverse control instruction for a specific target remote node; the central control node distributes the anti-control instruction to the target remote node according to the time slot rotation table and the real-time clock when the communication time slot of the target remote node arrives; and the target remote node reports state data containing mechanical arm execution confirmation information and a visual verification result to the central control node in a subsequent communication time slot of the target remote node. By establishing a deterministic time division multiplexing communication order and a visual-mechanical double closed loop, the problems of instruction loss, uncertain delay and out-of-control action during remote mechanical arm control on an unreliable network are solved.

Description

Technical Field

[0001] This application relates to the field of fire alarm control technology, and in particular to a data routing and distribution method for multi-node fire protection systems that can be remotely reverse-controlled by a robotic arm. Background Technology

[0002] With the development of IoT technology, remote centralized monitoring and reverse control of fire alarm controllers distributed in different geographical locations has become an important trend in the field of smart fire protection. In some scenarios involving renovation of existing facilities or high security requirements, reverse control needs to be achieved by physically pressing buttons on the alarm control panel (such as reset or mute) using a robotic arm deployed on-site, in order to avoid intruding into the internal circuitry of the control panel.

[0003] The conventional technical approach typically involves building a cloud platform that connects to remote control terminals deployed at various monitoring sites via standard internet protocols such as TCP / IP or HTTP. However, this architecture contains a profound and irreconcilable inherent contradiction: it attempts to graft a mission-critical physical control application, which demands determinism and high reliability, onto a public internet infrastructure that is inherently best-effort and non-deterministic.

[0004] Existing technologies generally address this gap by adding retry or acknowledgment mechanisms at the application layer, but this does not solve the fundamental problem. The disordered and concurrent contention for central server resources by multiple remote nodes is highly susceptible to instruction loss, uncertain latency, or unknown execution status during network jitter or concurrent instruction processing. For robotic arm control, network latency jitter can lead to disordered robotic arm movement timing, while instruction loss can cause the robotic arm to remain in a pressed state and unable to reset, thus posing a risk of physical damage. Furthermore, traditional technologies lack closed-loop verification of the actual effects of the robotic arm's physical movements and do not consider the safety hazard of the robotic arm obstructing the control panel during network interruptions. Therefore, a long-standing technological bias exists in this field, namely, the belief that one can only passively cope with network uncertainties, lacking a technical solution that proactively constructs deterministic and orderly communication rules on unreliable channels at the architectural level to ensure the safe and controlled operation of physical robotic arms. Summary of the Invention

[0005] The purpose of this application is to provide a method and system for routing and distributing control data in a multi-node fire protection system. It aims to solve the technical problems in the prior art, such as command loss, uncertain action delay, unknown execution status, and concurrent conflicts caused by the fundamental defects of the communication architecture when controlling a remote robotic arm to operate a fire protection host on an unreliable public Internet.

[0006] To achieve the above objectives, in a first aspect, this application provides a method for routing and distributing counter-control data in a multi-node fire protection system, comprising: a central control node establishing a time-slot rotation table for multiple remote nodes, wherein the time-slot rotation table allocates a periodically occurring, unique communication time slot for each remote node; the central control node receiving a counter-control instruction for a target remote node, wherein the counter-control instruction instructs the target remote node to drive a robotic arm to perform a physical operation on a fire alarm controller, and buffering the counter-control instruction; the central control node determining, based on the time-slot rotation table and a real-time clock, within the communication time slot of the target remote node, encapsulating the counter-control instruction into an instruction data packet and distributing it to the target remote node; the central control node receiving a status data packet reported by the target remote node within a subsequent communication time slot of the target remote node, and confirming the status of the robotic arm performing the physical operation based on the status data packet.

[0007] Optionally, the central control node assigns a unique transaction ID to the counter-control instruction and includes the transaction ID in the instruction data packet for distribution; the status data packet includes the transaction ID of the counter-control instruction that the target remote node has successfully received or executed, for the central control node to confirm.

[0008] Optionally, the method further includes an event-driven dynamic time slot fission step: when the central control node receives a status data packet reported by a remote node containing a fire alarm signal, the central control node immediately triggers a time slot reconstruction process; the time slot reconstruction process includes: pausing the current time slot rotation table, generating an emergency time slot rotation table, in which the communication time slot ratio of the alarming remote node is increased to above a preset emergency threshold, while the communication time slots of other remote nodes are compressed or suspended; the central control node broadcasts the emergency time slot rotation table to all remote nodes and it takes effect immediately.

[0009] Optionally, the target remote node is also connected to an image acquisition unit. The step of confirming the status of the robotic arm performing the physical operation based on the status data packet specifically includes: before driving the robotic arm to perform the physical operation, the target remote node controls the image acquisition unit to acquire a first image of the fire alarm controller panel; after driving the robotic arm to perform the physical operation, it acquires a second image of the panel; the target remote node performs a difference comparison between the first image and the second image locally to identify changes in the optical state of the panel indicator lights; only when the physical action of the robotic arm is completed and the changes in the optical state of the panel indicator lights meet expectations, the target remote node generates a confirmed status information in the status data packet.

[0010] Optionally, it further includes: the central control node monitors whether it receives the status data packet reported by each of the remote nodes in each communication cycle; when the central control node does not receive the status data packet of a certain remote node in a preset monitoring cycle, it marks the status of the remote node as offline.

[0011] Optionally, when the central control node receives multiple counter-control instructions, it stores the multiple counter-control instructions in a priority queue for caching according to the preset priority of the counter-control instructions; the central control node obtains the highest priority counter-control instruction from the head of the priority queue and distributes it within the communication time slot of the target remote node.

[0012] Optionally, the transmission of the instruction data packet and the status data packet is encrypted using a datagram transport layer security protocol.

[0013] Optionally, both the instruction data packet and the status data packet contain a message authentication code generated based on a shared key; after receiving the data packet, both the central control node and the remote node verify the message authentication code to confirm the integrity and authenticity of the data packet's source.

[0014] Optionally, the method further includes a node registration step: a remote node to be registered initiates a registration request to a device issuing server, the registration request containing a unique device serial number of the remote node to be registered; After verifying the legitimacy of the device's unique serial number, the device issuing server assigns a unique node ID to the remote node to be registered, and sends the node ID, the network address information of the central control node, and security credentials to the remote node to be registered.

[0015] Secondly, this application also provides a counter-control data routing and distribution system for a multi-node fire protection system, including a central control node and multiple remote nodes; the central control node is configured to: establish a time slot rotation table for the multiple remote nodes, wherein the time slot rotation table allocates a periodically occurring, unique communication time slot for each remote node; receive a counter-control command for a target remote node, wherein the counter-control command is used to instruct the target remote node to drive a robotic arm to perform a physical operation on a fire alarm controller, and cache the counter-control command; and determine, based on the time slot rotation table and a real-time clock, within the communication time slot of the target remote node... The remote node encapsulates the counter-control command into a command data packet and distributes it to the target remote node; within a subsequent communication time slot of the target remote node, it receives a status data packet reported by the target remote node and confirms the status of the robotic arm performing the physical operation based on the status data packet; the remote node is configured to: receive the command data packet distributed by the central control node within its own communication time slot; parse the command data packet to generate a robotic arm control signal and drive the robotic arm connected to the remote node to perform the physical operation; and report the status data packet to the central control node within its own subsequent communication time slot.

[0016] Optionally, the remote node is also configured with an automatic network disconnection avoidance logic: the remote node has a built-in network watchdog timer, which is reset each time a valid instruction data packet or time slot synchronization signal is received from the central control node; when the timer expires and no network connection is detected, the remote node automatically takes over the control of the robotic arm and forcibly drives the robotic arm to move to a preset physical avoidance coordinate to expose the operation panel of the fire alarm controller for manual operation.

[0017] Optionally, the central control node includes a primary central control node and a backup central control node; a heartbeat detection mechanism is configured between the primary central control node and the backup central control node; when the backup central control node detects a failure in the primary central control node, the backup central control node automatically switches to the working state to take over all the functions of the primary central control node.

[0018] The beneficial effects of this application are as follows: This application transforms chaotic and contentious internet communication into a deterministic, conflict-free, and predictable virtual bus communication mode through a time-division multiplexing and state arbitration mechanism. This paradigm shift not only solves the technical problems of lost or delayed instructions but also provides architectural empowerment for mission-critical remote physical control over unreliable networks. Its introduced dynamic time-slot fission mechanism breaks through the real-time bottleneck of traditional time-division multiplexing; the visual-mechanical dual closed-loop verification technology addresses the unknown risks of remote physical control; and the automatic network disconnection avoidance logic eliminates the safety hazards of physical equipment to on-site manual operation, greatly improving the system's practical safety. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall architecture of a multi-node fire protection system control data routing and distribution system provided in an embodiment of this application.

[0020] Figure 2 The overall flowchart of the multi-node fire protection system reverse control data routing and distribution method provided in an embodiment of this application is shown.

[0021] Figure 3 This is a schematic diagram illustrating the principle of the time slot rotation table and time-division multiplexing communication mechanism in one embodiment of this application.

[0022] Figure 4 This is a block diagram of the internal functional modules of the central control node in one embodiment of this application.

[0023] Figure 5 This is a block diagram of the internal functional module structure of a remote node in one embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0026] This application provides a method and system for routing and distributing remote control data in a multi-node fire protection system. By pre-constructing a quantified, time-division multiplexing-based communication scheduling rule, the routing and distribution process of remote control commands (especially physical operation commands for robotic arms) is transformed from a probabilistic success dependent on unreliable networks into a scheduling execution process with deterministic timing guarantees.

[0027] Please see Figure 1 This illustration shows the overall system architecture provided by an embodiment of this application. The system architecture logically includes a central control node M100 and multiple remote control nodes M200. The central control node M100 is configured as the arbitration and command core of the system and is typically deployed on a cloud server or data center. The multiple remote control nodes M200 are configured as command receiving and execution terminals and are typically deployed at the site of the fire alarm controller equipment requiring remote control, and are physically connected to a robotic arm used to operate the fire alarm controller. Data exchange between the central control node M100 and the multiple remote control nodes M200 is conducted via a logical virtual command bus M300. The virtual command bus M300 is not a physical bus entity, but a logical data channel defined by a set of communication protocols jointly followed by the M100 nodes and all M200 nodes. This protocol enforces encrypted communication based on Datagram Transport Layer Security (DTLS) and embeds the strict timing scheduling rules described in this invention.

[0028] In a preferred embodiment, to eliminate the risk of a single point of failure for the central control node M100, the M100 node is configured in an active-standby high-availability topology. In this structure, at least two arbitrator server instances with identical hardware and software configurations are deployed, one acting as the active node to handle all service traffic, and the other as a standby node in a hot standby state. A virtual IP address (floating IP) managed by high-availability management software (e.g., Keepalived) is assigned to this active-standby cluster and always points to the current active node. All M200 remote control nodes are configured to communicate with this virtual IP address. The active and standby nodes exchange heartbeat detection signals at a high frequency (e.g., 1Hz) via an independent, low-latency internal network link. The system's core status data, including the global node status table and the queue of instructions to be distributed, is persisted in an in-memory database (e.g., Redis) configured with master-slave replication. In response to a standby node failing to receive a heartbeat signal from the primary node within a preset timeout window (e.g., three consecutive heartbeat cycles), an automated failover process is triggered: the standby node will seize ownership of the virtual IP address and simultaneously promote its connected slave database to the primary database, thereby taking over all command arbitration and distribution services. This failover process is transparent to the M200 remote control node, thus ensuring the continuity of overall system services.

[0029] Please see Figure 2 It illustrates the overall flow of a method provided by an embodiment of this application, which includes the following steps: Step S-100: Perform the node issuance and registration process. This process is used to securely initialize a brand-new remote node device in its factory-shipped state and integrate it into the management system of this device.

[0030] In sub-step S-110, a remote node to be registered, whose firmware is configured to initiate a registration request to a pre-defined device issuance server after its first power-on and network connection establishment, possesses a globally unique device serial number generated based on its hardware information (e.g., the MAC address of its network interface). The registration request is encapsulated in a data packet transmitted via HTTPS to ensure confidentiality, and its payload contains the device's unique serial number. Upon receiving the registration request, the device issuance server retrieves the serial number from its internal database and creates a record for the device with a status of "pending approval" to respond to subsequent management operations.

[0031] In sub-step S-120, in response to the system administrator's approval operation on the pending record via the management interface, the device issuance server executes an automated configuration distribution workflow. This workflow assigns a unique, business-related node ID to the remote node to be registered and generates a set of security credentials for communication encryption and authentication, such as a public-private key pair or a pre-shared key (PSK) for the DTLS protocol. Subsequently, a configuration file containing the node ID, the security credentials, and the network address information of the central control node M100 (including the IP address or virtual IP address of the primary and backup nodes) is generated. This configuration file is securely distributed to the remote node via a previously established HTTPS connection. After receiving and verifying the configuration file, the remote node persistently stores it in a local encrypted non-volatile storage area and sends an acknowledgment message back to the server. The node's registration process is then complete, and it is ready to establish communication with the central control node M100.

[0032] Step S000: Execute the system initialization and calibration procedure. This procedure is used to establish a globally consistent communication order when the system starts up or the node list changes.

[0033] In sub-step S010, the central control node M100 establishes a Time Slot Table (TST) based on its maintained list containing the unique IDs of all registered remote nodes M200. The generation of this table is a deterministic algorithm, with inputs including the total number of nodes N, the duration of a single time slot Tslot, and the guard interval Tguard between time slots. Tslot defines the length of the exclusive communication time window allocated to each node, while Tguard is used to compensate for network latency jitter. The TST is implemented as a one-dimensional array, with its elements filled with the unique IDs of each node in a predetermined order. For example, for a system containing four nodes NODEA, NODEB, NODEC, and NODED, if Tslot is set to 50 milliseconds, the generated TST will be an array containing ["NODEA", "NODEB", "NODEC", "NODED"]. This TST defines a communication cycle Tcycle with a total duration of 450ms = 200ms.

[0034] In sub-step S020, to ensure consistent understanding of the communication order among all nodes in the system, the central control node M100 distributes the newly generated TST to all registered remote nodes. This distribution process is executed through a reliable transmission protocol with application-layer acknowledgment and retransmission mechanisms to ensure that each remote node receives the latest version of the TST. Upon receiving the TST, each remote node stores it in its local non-volatile storage as a time reference for its subsequent communication activities.

[0035] In step S100, the central control node receives a counter-control instruction for a target remote node and caches the counter-control instruction.

[0036] In sub-step S110, the instruction interface subunit of the central control node M100 is configured to receive counter-control instructions, typically in JSON format, from the authorized user interface (UI). The counter-control instructions include physical action parameters (e.g., reset button coordinates, pressure applied, and hold time). Upon receiving a valid instruction request, the subunit immediately assigns it a globally unique, monotonically increasing transaction ID (TID).

[0037] In sub-step S120, an internal instruction object containing the TID, target node ID, instruction content, and preset priority is created. Based on the priority value of this instruction object, it is inserted into a priority queue, which serves as an instruction buffer. This priority queue is implemented as a min-heap, ensuring that the head element of the queue is always the highest priority instruction among all pending instructions. For example, the system can define the priority of an emergency silencing instruction as 10, while the priority of a routine inspection instruction is 200. A newly arrived silencing instruction will be placed before an existing inspection instruction to await priority scheduling.

[0038] In step S200, the central control node performs precise scheduling and instruction distribution based on the time slot rotation table.

[0039] In sub-step S210, the scheduler subunit inside the central control node M100, acting as a high-precision cyclic task, continuously maps the synchronized UTC real-time clock to a specific time slot in the TST. This mapping is achieved through a mathematical operation: First, the current millisecond-level timestamp is moduloed by the total communication period Tcycle to obtain the relative time offset within the period; second, this offset is divided by the single time slot duration Tslot and rounded down to obtain the index of the current time slot in the TST array; finally, based on this index, the node ID currently possessing communication rights is retrieved from the TST array.

[0040] In sub-step S220, based on the home node ID of the current time slot determined in S210, the scheduler checks the head instruction of the priority instruction queue. If the target node ID of the head instruction matches the home node ID of the current time slot, the instruction is retrieved from the queue. Subsequently, the instruction object is serialized into the payload of a binary data packet, and metadata containing the TID is appended. This data packet is further processed by CRC32 checksum calculation and HMAC-SHA256 signature generation based on a pre-shared key. The resulting complete instruction data packet is then distributed within the communication time slot of the target remote node.

[0041] This embodiment introduces an event-driven dynamic time-slot fission mechanism to address the real-time requirements of sudden fires.

[0042] In normal inspection mode, the TST table is uniformly distributed, for example, [A, B, C, D]. However, when the M100 receives a status packet containing a Level 1 fire alarm within Node A's time slot, the M100's scheduler subunit 420 immediately interrupts the current scheduling logic and enters wartime mode. It calculates and generates a new emergency TST table in real time based on a preset emergency response strategy, for example, [A, A, A, B, A, A, A, C, A, A, A, A, D]. In this table, Node A obtains 75% of the communication bandwidth. The M100 marks this new table as a high-priority control packet and broadcasts it across the entire network. This mechanism ensures that, in the event of a fire, affected nodes can obtain millisecond-level counter-control response speeds, while unaffected nodes retain only a minimum keep-alive heartbeat, thus dynamically reconstructing the system's attention resources without changing the hardware bandwidth.

[0043] In step S300, the remote node processes the received instructions, drives the robotic arm to perform physical operations, and constructs a response.

[0044] In sub-step S310, the network listener of the M200 remote node implements a time-slot gating logic. This logic ensures that it only processes received network packets when the time window indicated by the current real-time clock belongs to its own communication time slot. For a packet received within a valid time slot, it sequentially performs CRC32 checksum and HMAC signature verification to ensure the integrity of the packet's transmission and the authenticity of its origin. Only packets that pass all security checks will have their payload deserialized to extract the instruction content.

[0045] In sub-step S320, the successfully parsed reverse control command is passed to the command execution sub-unit. This sub-unit is responsible for translating high-level, abstract commands (such as reset_panel) into a series of low-level command sequences conforming to the local connection's robotic arm controller communication protocol. This command sequence is sent to the robotic arm controller to drive it to perform corresponding physical actions, such as moving the robotic arm end effector to the coordinate position of the reset button on the fire alarm controller panel and performing a pressing operation with a specified force and duration.

[0046] To address the risk of discrepancy between the execution of robotic arm movements and their actual effectiveness, this embodiment employs a vision-mechanical dual closed-loop verification technique in this step.

[0047] Specifically, the M200 node not only connects to the robotic arm but also connects to a high-definition industrial camera aligned with the alarm control panel via a USB interface. After parsing the reset command, the command execution subunit 520 first triggers the camera to take a snapshot before the operation and uses a lightweight CV algorithm (such as OpenCV's HSV color thresholding) to lock the fire alarm indicator area, confirming that it is in a lit (red) state. Subsequently, it drives the robotic arm to press the reset button. After the action is completed, it takes another snapshot after the operation and analyzes the same area. If the algorithm detects that the indicator light has turned off or is in a normal (green) state, the system determines that the operation is successful in business logic. If the robotic arm moves but the light does not turn off (possibly due to insufficient pressure), the M200 will automatically trigger a retry with increasing pressure or report a Physical Actuation Failure error code to the cloud, rather than falsely reporting success.

[0048] In sub-step S330, in response to the completion of the physical action of the robotic arm (whether successful or not), a response packet is constructed in the memory of the remote node. This packet is essentially a standard status packet, but its lastacktid field is explicitly set to the TID of the instruction that was just executed. This response packet is temporarily stored in preparation for reporting in the next communication slot belonging to that node.

[0049] In addition, considering the special safety requirements of fire-fighting scenarios, the M200 node has an automatic fail-safe retraction function.

[0050] The remote node maintains an independent watchdog process, separate from the main communication thread. If the M200 fails to resolve a valid timeslot signal for K consecutive cycles (e.g., 30 seconds) (meaning an internet outage or cloud failure), the watchdog will trigger an interrupt, directly sending a GOTO_HOME command to the robotic arm controller. This HOME location is preset in an unobstructed area on the side or above the alarm host. This design overcomes the technical bias in existing technologies where the robotic arm becomes stuck in front of the host control panel due to network outages, hindering on-site firefighters from providing manual emergency intervention, significantly improving the system's practical safety.

[0051] Step S400: Execute the periodic synchronization of the state and heartbeat.

[0052] In sub-step S410, each M200 remote node is mandated by the protocol to report a status data packet to the central control node M100 within each of its dedicated communication time slots. If the node executed a robotic arm command in the previous cycle, this data packet is a response packet containing TID confirmation constructed in S330; otherwise, this data packet is a heartbeat packet.

[0053] In sub-step S420, the central control node M100 receives and verifies the status data packet reported by the remote node in its arbitrator module. Based on the nodeid field in the data packet, it updates the last heartbeat timestamp of the corresponding node in the global node status table. Subsequently, it parses the lastack_tid field. If the TID in this field exists in a list of distributed but unconfirmed instructions, the system updates the status of the instruction to successful execution and removes it from the list, thereby completing a closed-loop confirmation of the instruction.

[0054] Please see Figure 4 The central control node M100 (400) is embodied as a system containing multiple functionally coupled modules, including: an instruction interface subunit 410 for receiving external instructions; a clock and scheduler subunit 420 for scheduling according to timing rules; an instruction queue and status manager subunit 430 for caching instructions and managing node status; and a security and network transceiver subunit 440 for performing encryption and signature verification.

[0055] Please see Figure 5 The M200 remote node 500 is embodied as an embedded system, which includes: a communication scheduling subunit 510 for controlling its own communication timing; an instruction parsing and execution subunit 520 for executing specific instructions; a hardware driver subunit 530 for interacting with the robotic arm controller; and a heartbeat and status packaging subunit 540 for constructing reported data.

[0056] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0057] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit described above can be implemented in hardware.

[0058] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for routing and distributing control data in a multi-node fire protection system, characterized in that, include: A central control node establishes a time slot rotation table for multiple remote nodes, wherein the time slot rotation table allocates a unique, periodically occurring communication time slot to each of the remote nodes; The central control node receives a counter-control instruction for a target remote node, wherein the counter-control instruction is used to instruct the target remote node to drive a robotic arm to perform physical operations on a fire alarm controller, and the counter-control instruction is cached. The central control node makes a judgment based on the time slot rotation table and a real-time clock, and encapsulates the anti-control command into an instruction data packet and distributes it to the target remote node within the communication time slot of the target remote node. The central control node receives a status data packet reported by the target remote node in a subsequent communication time slot, and confirms the status of the robotic arm performing the physical operation based on the status data packet.

2. The method according to claim 1, characterized in that, The central control node assigns a unique transaction ID to the counter-control instruction and includes the transaction ID in the instruction data packet for distribution; the status data packet contains the transaction ID of the counter-control instruction that the target remote node has successfully received or executed, which is used by the central control node for confirmation.

3. The method according to claim 1, characterized in that, The method also includes an event-driven dynamic time-slot fission step: When the central control node receives a status data packet from a remote node that contains a fire alarm signal, the central control node immediately triggers a time-slot reconstruction process. The time slot reconstruction process includes: pausing the current time slot rotation table, generating an emergency time slot rotation table, in which the communication time slot ratio of the alarming remote node is increased to above a preset emergency threshold, while the communication time slots of other remote nodes are compressed or suspended. The central control node broadcasts the emergency time slot rotation table to all remote nodes, and it takes effect immediately.

4. The method according to claim 1, characterized in that, The target remote node is also connected to an image acquisition unit, and the step of confirming the status of the robotic arm performing the physical operation based on the status data packet includes: Before driving the robotic arm to perform physical operations, the target remote node controls the image acquisition unit to acquire the first image of the fire alarm controller panel. After driving the robotic arm to perform a physical operation, a second image of the panel is acquired; The target remote node performs a difference comparison between the first image and the second image locally to identify changes in the optical state of the panel indicator lights; The target remote node generates a confirmation status information in the status data packet only when the physical action of the robotic arm is completed and the optical status change of the panel indicator light meets expectations.

5. The method according to claim 1, characterized in that, Also includes: In each communication cycle, the central control node monitors whether it has received the status data packets reported by each of the remote nodes. When the central control node does not receive the status data packet of a certain remote node within a preset monitoring period, the status of the remote node is marked as offline.

6. The method according to claim 1, characterized in that, When the central control node receives multiple counter-control commands, it stores the multiple counter-control commands in a priority queue for caching according to the preset priority of the counter-control commands; The central control node, within the communication time slot of the target remote node, obtains the highest priority anti-control instruction from the head of the priority queue and distributes it.

7. The method according to claim 1, characterized in that, Both the instruction data packet and the status data packet contain a message authentication code generated based on a shared key; after receiving the data packet, both the central control node and the remote node verify the message authentication code to confirm the integrity and authenticity of the data packet's origin.

8. The method according to claim 1, characterized in that, The method also includes a node registration step: A remote node to be registered initiates a registration request to a device issuing server, the registration request containing a unique device serial number of the remote node to be registered; After verifying the legitimacy of the device's unique serial number, the device issuing server assigns a unique node ID to the remote node to be registered, and sends the node ID, the network address information of the central control node, and security credentials to the remote node to be registered.

9. A reverse control data routing and distribution system for a multi-node fire protection system, characterized in that, It includes a central control node and multiple remote nodes; The central control node is configured as follows: A time-slot rotation table is established for the plurality of remote nodes, wherein the time-slot rotation table allocates a unique, periodically occurring communication time slot to each of the remote nodes; Receive a counter-control instruction for a target remote node, wherein the counter-control instruction is used to instruct the target remote node to drive a robotic arm to perform a physical operation on a fire alarm controller, and cache the counter-control instruction; Based on the time slot rotation table and a real-time clock, the counter-control command is encapsulated into a command data packet and distributed to the target remote node within the communication time slot of the target remote node. In a subsequent communication time slot of the target remote node, a status data packet reported by the target remote node is received, and the status of the robotic arm performing the physical operation is confirmed based on the status data packet; The remote node is configured as follows: Receives instruction data packets distributed by the central control node within its own communication time slot; The instruction data packet is parsed to generate robotic arm control signals, and the robotic arm connected to the remote node is driven to perform the physical operation; During its subsequent communication time slot, it reports the status data packet to the central control node.

Images