A multi-protocol collaborative data acquisition closed-loop control method for sharing a disinfection machine

Abstract

The application provides a shared disinfection machine multi-protocol cooperative data acquisition closed-loop control method, comprising: generating a first control envelope and a second control envelope with the same target control result and different unlocking conditions, and sending them to a target shared disinfection machine through different communication protocols; the target shared disinfection machine generates a joint submission proof, and after verification by an edge computing node, sends branch disclosure information, so that the matched control envelope obtains one-time execution qualification, and generates a cancellation witness for another control envelope; an execution root node is established according to a branch execution event, multi-protocol state acquisition is triggered based on the execution root node, original sampling events, source tracking records and actual transmission paths are recorded, a causal source hypergraph is constructed and an independent source rank is calculated; when the independent source rank is insufficient, an ant colony algorithm is used to select a supplementary communication protocol path for supplementary acquisition.

Description

Technical Field

[0001] This invention relates to the field of communication control technology, and in particular to a closed-loop control method for multi-protocol collaborative data acquisition of a shared disinfection machine. Background Technology

[0002] Shared disinfection machines are typically remotely controlled and their status queried by an operation platform or equipment management platform via communication protocols such as MQTT, CoAP, and HTTP. To improve the reliability of control command delivery, existing systems can repeatedly send the same command using multiple communication protocols. However, the arrival order, retransmission count, and transmission path of messages from different protocols vary, easily leading to the repeated execution of the same control command. Current technology lacks a reliable control mechanism that binds multiple protocol messages to the same control session and allows only one control branch to execute after joint reception.

[0003] After control execution, the platform typically determines the control result based on the status data returned by the terminal. Even if multiple sets of status data are obtained through multiple communication protocols, these data may be replicated from the same message broker, gateway cache, or protocol conversion node, or directly originate from historical states prior to execution. Therefore, the independence of status data cannot be determined solely based on the number of protocols or messages. Existing technologies struggle to trace the original sampling events, caching operations, and actual transmission paths corresponding to status data, and also find it difficult to determine whether multiple sets of status data originate from the same cache object.

[0004] Therefore, this invention proposes a closed-loop control method for multi-protocol collaborative data acquisition of shared disinfection machines. The information disclosed in the background section is only for enhancing understanding of the background of this disclosure and may therefore contain prior art information that is not common knowledge to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a closed-loop control method for multi-protocol collaborative data acquisition of shared disinfection machines, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A closed-loop control method for multi-protocol collaborative data acquisition of shared disinfection machines includes the following steps: S1. Obtain a remote control request for the target shared disinfection machine, generate a first control envelope and a second control envelope with the same target control result but different unlocking conditions, and send them to the target shared disinfection machine via different communication protocols; S2. Receive the joint submission proof generated by the target shared disinfection machine based on the two control envelopes, the current session count, and the terminal random quantity. After verification, generate branch disclosure information. S3. Send the branch disclosure information to the target shared disinfection machine, so that it only grants one-time execution qualification to the matching control envelope, and generates a deregistration witness for the other control envelope. Receive the branch execution event generated after execution, and establish the execution root node based on the branch execution event and the deregistration witness. S4. Based on the execution root node, send the collection challenge through multiple communication protocols, receive the resampled state data, record the original sampling events, source tracing records and actual transmission paths, construct the causal source hypergraph and calculate the initial independent source rank; S5. When the initial independent source rank is lower than the preset closed-loop threshold, the ant colony algorithm is used to select a supplementary communication protocol path that avoids key cache nodes, and supplementary collection is performed to update the causal source hypergraph and independent source rank. When the session authenticity, unique branch execution, post-execution sampling, source independence and state consistency all meet the preset closed-loop conditions, a valid communication closed loop is confirmed to be formed.

[0007] S1 specifically includes: receiving and verifying remote control requests; reading protocol capability information based on the terminal identifier; generating a target session identifier and session epoch; determining the effective execution duration based on historical communication latency and terminal response time; forming basic session data; generating two random unlock values ​​and calculating corresponding unlock condition commitment values; establishing an effective execution time window; deriving a session authentication key; forming a first control envelope and a second control envelope with the same target control result but different branch identifiers and unlock condition commitment values; determining the first communication protocol and the second communication protocol; encapsulating and sending the two control envelopes; recording the actual transmission path; and establishing a protocol path correspondence between the control envelope digest, the communication protocol, and the actual transmission path.

[0008] S2 specifically includes: the target shared disinfection machine parses two control envelopes, verifies the consistency of the control envelope authentication code and fields, writes the valid control envelope into the control area to be unlocked and generates a branch receiving record, updates the current session count and generates a terminal random variable when both control envelopes are valid and come from different communication protocols; combines the two control envelope digests, two branch receiving records, the current session count, the terminal random variable and the session epoch in a fixed order to generate a joint commit digest and a joint commit authentication code, forms a joint commit proof and returns it to the edge computing node; the edge computing node verifies the correspondence between the session epoch, the control envelope digest and the protocol path, verifies the joint commit proof, generates a branch selection random variable to determine the branch to be executed, and generates branch disclosure information based on the corresponding random unlock value, the current session count and the joint commit digest.

[0009] S3 specifically includes: verifying the branch information and corresponding random unlock value of the target shared disinfection machine; generating a one-time execution qualification based on the branch to be executed; marking the unexecuted control envelope as deregistered and generating a deregistration witness; converting the one-time execution qualification from unused to used; executing the control envelope to be executed through the local control execution interface; reading the terminal running status before and after execution; generating a state transition summary, execution completion sequence number, and branch execution event; and edge computing nodes verifying the session data, branch identifier, control envelope summary, and authentication code in the branch execution event and deregistration witness, verifying the one-time execution qualification identifier and state transition summary, generating an execution root identifier and establishing an execution root node when the execution evidence is valid.

[0010] S4 specifically includes: generating collection challenges for communication protocols based on the execution root node and protocol capability information; after verification of the target shared disinfection machine, calling the local status collection interface to reread the terminal's operating status to form original sampling events and status data; recording source tracking records, cache operations, and data object identifiers generated when status data is forwarded through network nodes, verifying status data and source links, constructing a causal source hypergraph and identifying key cache nodes; filtering status data from the causal source hypergraph, determining data with different original sampling events that have not passed through the same key cache node as mutually independent, calculating the initial independent source rank, and generating source evidence gaps and supplementary collection constraints when the rank is below a preset closed-loop threshold.

[0011] S5 specifically includes: constructing a candidate protocol path graph based on source evidence gaps, key cache node sets, and supplementary acquisition constraints; setting path edge pheromones and heuristic information; using ant colony optimization to search for a set of supplementary communication protocol paths that can increase the independent source rank; sending new acquisition challenges along the supplementary communication protocol paths; receiving supplementary state data; adding it to the causal source hypergraph; re-identifying key cache nodes; calculating the independent source rank and actual source gain; and continuing the search if the preset closed-loop threshold is not reached; performing session authenticity verification, unique branch execution verification, post-execution sampling verification, source independence verification, and state consistency verification on joint submission proofs, branch disclosure information, deregistration witness verification, branch execution events, execution root nodes, and state data; and generating a closed-loop verification record and confirming a valid communication closed loop when all verifications pass.

[0012] The beneficial effects of this invention are as follows: This invention sends two control envelopes with the same target control result but different unlocking conditions through different communication protocols. It then uses joint submission to confirm that the target shared disinfection machine has received both control branches, improving the reliability of control command delivery. By employing a joint submission followed by branch disclosure process, it grants one-time execution qualification only to matching control envelopes and prevents the other control envelope from executing by cancelling the witness, thus avoiding duplicate control caused by multiple protocol transmissions.

[0013] This invention, by binding branch execution events, deregistration witnesses, state transition summaries, and execution completion sequence numbers to the same remote control session, can verify whether the control envelope has been uniquely executed, improving the traceability and data security of the remote control process. After control execution, by triggering the target shared disinfection machine to reread the terminal's operating status through a collection challenge and generating an original sampling event identifier, it can eliminate the influence of message brokers, gateways, or protocol conversion nodes directly returning to the historical state before execution.

[0014] This invention identifies whether data from different protocol states originate from the same cache object through source tracing records, data object identification, and a causal source hypergraph, avoiding erroneous judgments of data source independence based solely on the number of protocols or messages. When the number of independent sources is insufficient, an ant colony algorithm is used to select a supplementary communication protocol path that avoids key cache nodes. This is combined with verification of session authenticity, unique branch execution, post-execution sampling, source independence, and state consistency to achieve a verifiable and effective communication loop. Attached Figure Description

[0015] Figure 1 This is a flowchart of the multi-protocol collaborative data acquisition closed-loop control method for shared disinfection machines according to the present invention. Detailed Implementation

[0016] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0017] Example: Figure 1 As shown, this embodiment provides a closed-loop control method for multi-protocol collaborative data acquisition of a shared disinfection machine, including the following steps: S1. Obtain a remote control request for the target shared disinfection machine, generate a first control envelope and a second control envelope with the same target control result but different unlocking conditions, and send them to the target shared disinfection machine via different communication protocols; S2. Receive the joint submission proof generated by the target shared disinfection machine based on the two control envelopes, the current session count, and the terminal random quantity. After verification, generate branch disclosure information. S3. Send the branch disclosure information to the target shared disinfection machine, so that it only grants one-time execution qualification to the matching control envelope, and generates a deregistration witness for the other control envelope. Receive the branch execution event generated after execution, and establish the execution root node based on the branch execution event and the deregistration witness. S4. Based on the execution root node, send the collection challenge through multiple communication protocols, receive the resampled state data, record the original sampling events, source tracing records and actual transmission paths, construct the causal source hypergraph and calculate the initial independent source rank; S5. When the initial independent source rank is lower than the preset closed-loop threshold, the ant colony algorithm is used to select a supplementary communication protocol path that avoids key cache nodes, and supplementary collection is performed to update the causal source hypergraph and independent source rank. When the session authenticity, unique branch execution, post-execution sampling, source independence and state consistency all meet the preset closed-loop conditions, a valid communication closed loop is confirmed to be formed.

[0018] S1 specifically includes the following sub-steps: S110, the edge computing node receives remote control requests sent by the shared disinfection machine operation platform, equipment management platform, or authorized remote control client. The remote control request includes the requester identifier, the terminal identifier of the target shared disinfection machine, the target control result, the request generation time, the request random number, and the request authentication information.

[0019] The target control result is a predefined operating status value from the device communication interface that can be directly parsed by the target shared disinfection machine. This operating status value is mapped to control commands for the specific physical execution components of the shared disinfection machine, including controlling the on / off state of the disinfectant pump, switching the operating mode of the ultraviolet germicidal lamp, and adjusting the power parameters of the atomizer. The edge computing node reads pre-stored authentication information from the authorization database based on the requester's identifier and verifies the requested authentication information. If verification is successful, it extracts the terminal identifier and the target control result; if verification fails, the current processing is terminated.

[0020] Edge computing nodes read communication protocol type, protocol version, protocol access address, terminal master key identifier and terminal authentication information from the device registration database based on the terminal identifier, read the most recent heartbeat reception time and access gateway from the valid heartbeat records, and read the online status of the corresponding node from the gateway management interface, message broker connection interface and protocol conversion node status interface.

[0021] A communication protocol is identified as available when it has been registered, all relevant nodes are in a serviceable state, and the difference between the current time and the most recent heartbeat reception time does not exceed three heartbeat cycles. The available communication protocol, protocol version, access gateway, and available transmission path are combined to form protocol capability information.

[0022] Edge computing nodes generate target session identifiers in a fixed order based on terminal identifier, requested random number, and request generation time:

[0023] in, Identify the target session; For terminal identification; To request a random number; The time the request was generated; Use a session identification key; Indicates byte concatenation; This indicates that 128 bits of the result have been extracted.

[0024] The edge computing node reads the most recently confirmed session epoch of the terminal identifier and increments it by 1 to obtain the current session epoch; if there is no historical record, the session epoch is set to 1. The session epoch is a monotonically increasing integer for the same target shared disinfection machine and remains unchanged within the current remote control session.

[0025] The request reception time, start time of the effective execution time window, and end time of the edge computing node are all timed using UTC millisecond timestamps.

[0026] Edge computing nodes extract network round-trip latency samples and terminal historical response duration samples for each available communication protocol from the 50 most recent successful communication records, calculate the 95th percentile value for each, and add the maximum value of the sum of the two percentile values ​​for each protocol to a preset safety margin to obtain the effective execution duration; when there are fewer than 20 effective samples, the preset statistical value of the same model terminal in the device registration database is used.

[0027] Edge computing nodes generate session foundation data consisting of terminal identifier, target control result, target session identifier, session epoch, effective execution duration, and protocol capability information. For example, if the 95th percentile values ​​of network round-trip latency for MQTT and CoAP are 420ms and 650ms respectively, the 95th percentile values ​​of historical response times are 800ms and 900ms respectively, and the safety margin is 1000ms, then the effective execution duration is 2550ms.

[0028] S120, the edge computing node generates a first control envelope and a second control envelope based on the session data. The control envelope is an application-layer control data unit formed in a fixed field order, including the terminal identifier, target session identifier, session epoch, target control result, branch identifier, unlock condition commitment value, execution validity time window, and control envelope authentication code. Except for the branch identifier and unlock condition commitment value, the other fields in the two control envelopes are identical.

[0029] The edge computing nodes generate a first random unlock value and a second random unlock value, respectively, and calculate the corresponding unlock condition commitment value:

[0030] in, The commitment value for the j-th unlock condition; The j-th random unlock value; For the session epoch; This is the identifier for the j-th branch; all H values ​​in this article represent SHA-256 hash operations.

[0031] The first unlock condition commitment value is written into the first control envelope, and the second unlock condition commitment value is written into the second control envelope. The two random unlock values ​​are only stored in the current session record of the edge computing node, so that the target shared disinfection machine cannot execute either control envelope before receiving the branch disclosure information.

[0032] When the edge computing node has completed all fields except the control envelope authentication code in the two control envelopes, it determines the completion time as the start time of the execution effective time window, adds S110 to the start time to determine the execution effective duration as the end time, and writes the execution effective time window into the two control envelopes.

[0033] The edge computing node reads the terminal master key corresponding to the terminal master key identifier from the device registration database and derives the session authentication key:

[0034] in, For session authentication key; This is the terminal master key; This is a key derivation function based on hash operations; For fixed-purpose identification.

[0035] The target shared disinfection machine reads the same terminal master key from the local secure storage area and derives the session authentication key using the same rules. The terminal master key is not transmitted with the communication message.

[0036] The edge computing node encodes the numeric fields (excluding the control envelope authentication code) according to network byte order, and the text fields according to UTF-8, writing the field length before the variable-length fields to form two control envelope byte streams to be authenticated. SHA-256 hash operations are performed on the two control envelope byte streams to obtain the first and second control envelope digests. Then, using the session authentication key, HMAC operations are performed on the control envelope digest, the target session identifier, and the session epoch to generate the corresponding control envelope authentication code.

[0037] The control envelope authentication code is appended to the corresponding control envelope byte stream to be authenticated, forming the first normalized control envelope byte stream and the second normalized control envelope byte stream. Two random unlock values, two control envelope digests, two branch identifiers, two unlock condition commitment values, the execution validity time window, and the session authentication key identifier are written into the current session record for use in subsequent joint submission proof verification and branch disclosure.

[0038] S130: The edge computing node removes communication protocols that are offline or unavailable from the protocol capability information. From the remaining communication protocols, it selects two protocols with different protocol types, different transport layer mechanisms, and fewer shared nodes along the planned transmission path. If multiple candidate combinations exist, they are sorted according to the success rate (highest to lowest), network round-trip latency (lowest to highest), and the number of shared nodes (fewest to most) in the most recent 50 transmission records to determine the first and second communication protocols. If only one available communication protocol exists, the remote control request is marked as not meeting the dual-protocol condition, and the process does not proceed to S210.

[0039] Edge computing nodes encapsulate the first normalized control envelope byte stream into a first communication protocol message, and the second normalized control envelope byte stream into a second communication protocol message. Protocol conversion nodes only convert the outer protocol header, address field, and routing field; they do not modify the normalized control envelope byte stream. The two communication protocol messages are submitted within the same transmission scheduling period, with a submission time interval not exceeding 100ms and not exceeding 10% of the effective execution time. In case of transmission failure, the original byte stream is retransmitted only within the effective execution time window; the branch identifier, unlock condition commitment value, or control envelope digest is not regenerated.

[0040] Before transmission, edge computing nodes generate planned transmission paths based on gateway routing tables, message broker subscription relationship tables, and protocol conversion configuration tables. During transmission, each forwarding node records the target session identifier, control envelope digest, node identifier, node type, reception time, forwarding time, previous node identifier, and next node identifier.

[0041] Edge computing nodes read forwarding records to form the actual transmission path and correct the planned transmission path based on the actual transmission path. They associate the control envelope digest, communication protocol type, sending gateway identifier, message broker identifier, protocol conversion node identifier, node order, and session epoch to form a protocol path correspondence, which is then used by S230 to verify the branch reception record in the joint submission proof.

[0042] S2 specifically includes the following sub-steps: S210 and the target shared disinfection machine receive the first communication protocol message and the second communication protocol message respectively through the first communication protocol adapter and the second communication protocol adapter. After removing the outer protocol encapsulation, they obtain the first normalized control envelope byte stream and the second normalized control envelope byte stream. The protocol adapter is a software component in the target shared disinfection machine responsible for parsing the corresponding communication protocol, extracting the payload, and generating the reception record.

[0043] The target shared disinfection machine reads the terminal master key from the local secure storage area, generates a session authentication key according to the key derivation rules specified in S120, and recalculates the control envelope authentication codes of the two control envelopes; when the calculation result is consistent with the control envelope authentication code carried in the message, the corresponding control envelope is determined to be a valid control envelope.

[0044] The target shared disinfection machine reads the clock deviation threshold from the device configuration area and verifies the local secure real-time clock based on the most recent authentication time. When the deviation between the local time and the edge computing node time exceeds the threshold, the current remote control session is terminated. The effective execution time window is verified by the local secure real-time clock, while the execution order and sampling order within the terminal are determined by the monotonic clock.

[0045] The target shared disinfection machine establishes a control area to be unlocked using the target session identifier as an index. The control area to be unlocked is a storage area that stores control envelopes and session data for which branch disclosure information has not yet been obtained, and has waiting, submitted, disclosed, and terminated states.

[0046] Upon receiving the first valid control envelope, its control envelope summary, branch identifier, unlock condition commitment value, session epoch, and execution effective time window are written into the control area to be unlocked, and the system remains in a waiting state. Upon receiving another valid control envelope, the system checks whether the terminal identifier, target session identifier, session epoch, target control result, and execution effective time window in the two control envelopes are consistent, and confirms that the two branch identifiers and two unlock condition commitment values ​​are different.

[0047] Each protocol adapter generates a branch reception record for a valid control envelope. The branch reception record includes a control envelope digest, communication protocol type, protocol adapter identifier, local reception sequence number, and reception completion identifier. The local reception sequence number is derived from the monotonically increasing reception counter of the corresponding protocol adapter. If control envelopes with the same branch identifier arrive repeatedly with identical digests, it is considered a protocol retransmission; the data is not rewritten, and the current session count is not incremented. If the branch identifiers are the same but the digests are different, it is considered a branch content conflict, and the control area to be unlocked is converted to a terminated state.

[0048] When the effective time window expires, if only one valid control envelope is received, the control envelope already saved in the control area to be unlocked is deleted, and a dual-branch reception incomplete flag is returned to the edge computing node. For example, if the first control envelope arrives twice via MQTT with the same digest, the two receptions only form one valid branch reception record and cannot replace the second control envelope arriving via CoAP.

[0049] When both valid control envelopes pass verification and originate from different communication protocols, the target shared sterilizer atomically increments the previous committed session count in the power-off retention memory by 1 to obtain the current session count. Protocol retransmissions, joint commit proof retransmissions, or branch disclosure information retransmissions must not increment the current session count again.

[0050] The target shared disinfection machine generates a 256-bit terminal random number using a hardware random number generator. When no hardware random number generator is configured, it generates a cryptographically secure pseudo-random number using the device's internal random seed, the current session count, and the terminal's monotonic clock reading as input. Each current session count corresponds to only one terminal random number. This terminal random number is used to ensure the freshness of the joint submission proof and is not used to select the branch to be executed.

[0051] S220, the target shared disinfection machine reads two control envelope digests, two branch receive records, the current session count, the terminal random variable, and the session epoch in a fixed order, with the first branch identifier first and the second branch identifier last, and calculates the joint commit digest:

[0052] in, For joint submission of abstracts; and These are the digests of the first control envelope and the digest of the second control envelope, respectively. and These are the normalized byte streams of the first branch received record and the second branch received record, respectively. Count the current session; This is a terminal random variable. Fixed ordering is used to avoid two control envelopes generating different joint submission digests due to different arrival orders.

[0053] The target shared disinfection machine uses the session authentication key to generate a federated submission authentication code:

[0054] in, For joint submission of authentication codes; This is the session authentication key.

[0055] The joint commit proof is formed by combining the target session identifier, session epoch, current session count, terminal random variable, two control envelope digests, two branch receive records, joint commit digest, and joint commit authentication code. This joint commit proof demonstrates that the same shared disinfection machine has received and temporarily stored two unlocked control branches within the same remote control session. After the joint commit proof is generated, the control area to be unlocked is converted to a committed state.

[0056] The target shared disinfection machine returns identical joint commit proofs via both the first and second communication protocols. The edge computing node uses the target session identifier, session epoch, current session count, and joint commit digest as a deduplication key. Upon receiving subsequent joint commit proofs with the same deduplication key, only the return path record is added; no further branch selection is triggered. For example, if the joint commit proof returned by MQTT arrives first, and the identical proof returned by CoAP arrives later, only the second return path is recorded; a second branch disclosure is not generated.

[0057] S230: The edge computing node reads the current session record formed in S120 according to the target session identifier, and verifies the session epoch, execution effective time window, two control envelope digests and two branch identifiers; according to the protocol path correspondence formed in S130, it verifies whether the communication protocol types in the two branch receiving records correspond to the first communication protocol and the second communication protocol respectively; it recalculates the joint submission authentication code using the session authentication key, and checks whether the current session count is greater than the session count of the most recent completed remote control session of the target shared disinfection machine.

[0058] Once all verifications pass, the current remote control session is marked as committed; if any verification fails, branch reveal information is refused to be generated.

[0059] After successful verification, the edge computing node generates a 256-bit branch selection random number using a cryptographically secure random number generator, converts it into a non-negative integer, and determines the branch to be executed based on the least significant bit:

[0060] Where b is the branch number to be executed; V is the non-negative integer corresponding to the branch selection random variable. The first branch is selected when the result is 1, and the second branch is selected when the result is 2. The branch selection random variable is generated only after the joint submission proof has been verified.

[0061] The edge computing node reads the random unlock value corresponding to the branch to be executed from the current session record and generates branch reveal information. The branch reveal information is the authentication data that enables the target shared disinfection machine to unlock only one control branch. It includes the target session identifier, session epoch, current session count, federated commit digest, branch identifier to be executed, corresponding random unlock value, branch reveal sequence number, branch reveal generation time, branch reveal validity period, and branch reveal authentication code.

[0062] The branch reveal sequence number is set to 1 in the current remote control session; the branch reveal generation time uses the UTC millisecond-level timestamp of the edge computing node; the effective duration of the branch reveal is the smaller value between the remaining duration of the effective execution time window and the preset reveal upper limit; the branch reveal authentication code is calculated from the normalized byte stream of the aforementioned fields using the session authentication key. The branch reveal information only carries the random unlock value corresponding to the branch to be executed, and does not carry the random unlock value of the unexecuted branch, and is sent to the target shared disinfection machine.

[0063] S3 specifically includes the following sub-steps: S310 After receiving the branch disclosure information, the target shared disinfection machine reads the control area to be unlocked corresponding to the target session identifier, confirms that it is in the committed state, and verifies the target session identifier, session epoch, current session count, and joint commit summary.

[0064] The target shared disinfection machine checks if the branch disclosure sequence number is 1 and confirms that there is no used branch disclosure sequence number with the same number in the remote control session. Simultaneously, it determines whether the current time exceeds the sum of the branch disclosure generation time and the valid duration, or the termination time of the valid execution time window, based on the local security real-time clock. Then, it recalculates the branch disclosure authentication code using the session authentication key. If any verification fails, the branch disclosure information is recorded as invalid and execution qualification is not granted.

[0065] After successful verification, based on the branch identifier to be executed, the control envelope and unlock condition commitment value are read from the control area to be unlocked, and a random unlock value is extracted from the branch disclosure information to recalculate the unlock condition commitment value:

[0066] in, The recalculated unlock condition commitment value; The random unlock value corresponding to the branch to be executed; This is the identifier for the branch to be executed.

[0067] The session unlock condition is confirmed to be satisfied only when the recalculated result matches the unlock condition commitment value in the control envelope to be executed. For example, if the branch reveal information points to the first branch but carries a second random unlock value, the recalculated result cannot match the first unlock condition commitment value, and the first control envelope cannot be executed.

[0068] Generate a one-time execution eligibility identifier based on the target session identifier, session epoch, current session count, joint commit digest, pending branch identifier, and pending control envelope digest:

[0069] in, This is a one-time qualification mark; For the control envelope digest to be executed, retrieve or The corresponding value in the table. One-time execution qualification is a license that allows the control envelope to be executed only once in the current remote control session, and its qualification status includes unused and used.

[0070] The target shared disinfection machine performs the following operations using atomic transactions: generating a one-time execution qualification, marking the control envelope to be executed as revealed, marking the unexecuted control envelope as unexecuted, writing the branch reveal number and used flag to the control area to be unlocked, and changing the control area to be unlocked from a committed state to a revealed state. If any data write fails, it rolls back to the committed state and does not execute the control envelope.

[0071] The target shared disinfection machine generates a deregistration witness based on the unexecuted control envelope digest, unexecuted branch identifier, pending branch identifier, current session count, federated commit digest, and branch disclosure sequence number, and generates a deregistration witness authentication code using the session authentication key. The deregistration witness is an authentication record proving that the unexecuted control envelope has permanently lost its eligibility to execute the current remote control session.

[0072] A deregistration index is established using the target session identifier, session epoch, current session count, and unexecuted control envelope digest. When an unexecuted control envelope or historical branch disclosure is received again, hitting the deregistration index returns a deregistered result without re-entering the unlocking process. For example, if a second control envelope arrives again after the first control envelope has been executed due to the message broker retention mechanism, even if its control envelope authentication code is valid, it cannot regain execution eligibility.

[0073] S320. After the atomic transaction is successfully submitted, the target shared disinfection machine reads the terminal running status before execution from the state register area of ​​the local control state machine. The terminal running status is a machine-readable status record provided by the local control state machine, including the running status code, status version number, status update time, current control source identifier, and the most recent execution result code.

[0074] Specifically, after receiving the target control result, the local control state machine outputs drive signals to the corresponding hardware execution components (such as relays and motor drive modules) through the GPIO pins or PWM channels of the main control chip, thereby driving the shared disinfection machine to complete the physical disinfection action. The local control execution interface returns the execution acceptance identifier, execution start time, execution end time, and execution result code; both times are derived from the monotonic clock of the target shared disinfection machine. The local control state machine increments the state version number by 1 each time it completes a valid state transition.

[0075] Subsequently, the terminal's running status after execution is read from the same state register. Execution is considered complete only if the one-time execution qualification is marked as used, the local control execution interface returns an execution acceptance identifier and a success code, the post-execution state version number is greater than the pre-execution state version number, and the post-execution terminal running status matches the target control result; otherwise, an execution failure record is generated, and no valid branch execution event is produced. For example, if the local control execution interface returns a success code, but the pre- and post-execution state version numbers are both 102, it indicates that the state register has not been effectively updated, and the control envelope cannot be considered to have been executed successfully.

[0076] The target shared disinfection machine is coded according to a fixed field order to represent the terminal running status before and after execution, and the corresponding summary and state transition summary are calculated.

[0077] in, A summary of the terminal's running status before execution; This is a summary of the terminal's running status after execution. and These represent the terminal running state before execution and the terminal running state after execution, respectively, after standardized encoding. This is a state transition summary. The calculation binds state changes to one-time execution eligibility and the current session count.

[0078] After execution, the target shared disinfection machine will increment the previous execution completion sequence number in its power-off retention memory by 1 to obtain the current execution completion sequence number. The execution completion sequence number must not be incremented when repeatedly receiving branch disclosure information or repeatedly sending execution results.

[0079] The target session identifier, session epoch, current session count, joint commit digest, branch to be executed identifier, control envelope digest to be executed, one-time execution eligibility identifier, terminal running status digest before execution, terminal running status digest after execution, post-execution state version number, state transition digest, execution start time, execution end time, execution completion sequence number, and execution result code are combined into a branch execution event, and a branch execution event authentication code is generated using the session authentication key. The branch execution event and the deregistration witness are returned to the edge computing node via at least one available communication protocol.

[0080] S330. After receiving the branch execution event and the deregistration witness, the edge computing node verifies the target session identifier, session epoch, current session count and joint commit digest of the two, confirms that the unexecuted branch identifier in the deregistration witness is different from the pending branch identifier in the branch execution event, and confirms that the pending branch identifier is consistent with the pending branch determined in S230.

[0081] The edge computing node checks the digest of the control envelope to be executed stored in S120, recalculates the one-time execution qualification identifier and state transition digest, verifies the branch execution event authentication code and the deregistration witness authentication code, and confirms that the execution result code is a success code and the execution completion sequence number is greater than the most recently confirmed execution completion sequence number. If any item fails, the execution root node is not established.

[0082] After successful verification, the edge computing node performs SHA-256 computation on the normalized byte stream of the target session identifier, session epoch, current session count, joint commit digest, pending branch identifier, state transition digest, and execution completion sequence number to obtain the execution root identifier. The execution root identifier, the aforementioned fields, the post-execution state version number, and the execution confirmation time are then combined to form the execution root node. The execution root node is the root data of the current remote control session that must be traced for subsequent state data.

[0083] Edge computing nodes establish a unique index for the execution root node using the target session identifier, session epoch, and current session count. When the same branch execution event is received again, only the return path record is added. If different pending branch identifiers, different execution completion sequence numbers, or different state transition summaries appear under the same current session count, it is considered an execution evidence conflict, the current remote control session is frozen, and S410 is not entered.

[0084] S4 specifically includes the following sub-steps: S410: The edge computing node reads the execution root node and protocol capability information, obtains the execution root identifier, target session identifier, session epoch, current session count, post-execution status version number, execution confirmation time and available communication protocols, and generates a collection challenge for each available communication protocol.

[0085] The collection challenge triggers the target shared disinfection machine to reread the terminal's running status after execution and bind the authentication data of the execution root node, including the execution root identifier, target session identifier, session epoch, current session count, collection challenge identifier, collection challenge random variable, collection challenge generation time, specified communication protocol, minimum status version number, collection challenge validity period, and collection challenge authentication code.

[0086] The minimum state version number is taken from the post-execution state version number in the execution root node; the random variable for the collection challenge is generated by a cryptographically secure random number generator; the collection challenge generation time uses a UTC millisecond-level timestamp; the valid duration of the collection challenge is the sum of the 95th percentile of the network round-trip delay of the most recent 50 times for the corresponding communication protocol and the preset processing margin; the collection challenge authentication code is generated from the session authentication key. Collection challenge identifiers under the execution root node must not be duplicated, the initial number of collection challenges cannot exceed 8, and the generation time must be later than the execution confirmation time.

[0087] The target shared disinfection machine verifies the collection challenge authentication code, execution root identifier, session epoch, and current session count, and checks whether the current time exceeds the sum of the collection challenge generation time and the valid duration based on the local security real-time clock. If the verification is successful, it does not read the protocol adapter cache, message broker cache, or historical state records, but instead calls the local state collection interface to reread the terminal running state from the same state register used by the S320.

[0088] During this process, the invocation of the local status acquisition interface specifically includes triggering the physical sensors inside the shared disinfection machine (such as current sensors for monitoring ultraviolet lamps, level gauges or flow meters for monitoring the remaining amount of disinfectant) to perform real-time hardware sampling, and refreshing the latest sampled sensor physical readings to the status register area.

[0089] For each valid collection challenge responded to by the local status acquisition interface, the local sampling sequence number in the power-off retention storage area is incremented by 1, and the challenge reception time, status read time, and status version number are recorded. The collection challenge reception time and status read time are both derived from the same monotonic clock of the target shared disinfection machine. Only when the status read time is later than the collection challenge reception time and the status version number is not lower than the lowest status version number, is an original sampling event formed.

[0090] The original sampling event identifier is generated according to the following formula:

[0091] in, This serves as the identifier for the k-th original sampling event; To execute the root identifier; To collect challenge identifiers; This is the local sampling sequence number; This refers to the time taken to read the status.

[0092] The target shared disinfection machine will encode the root identifier, collection challenge identifier, original sampling event identifier, local sampling sequence number, status read time, communication protocol type, terminal operating status, and status version number in a fixed order, perform SHA-256 calculation to obtain a status data digest, and generate a status data authentication code using the session authentication key. The above content constitutes the status data. For example, if the message broker directly returns a historical status and cannot provide the newly added local sampling sequence number and the original sampling event identifier matching the current collection challenge, this data cannot be considered a valid new sample.

[0093] S420 When state data passes through a sending gateway, message broker, protocol conversion node, or edge forwarding node, each network node generates a source tracking record, including a state data summary, node identifier, node type, previous node identifier, next node identifier, reception time, forwarding time, buffer operation type, data object identifier, and node tracking authentication code.

[0094] Caching operation types include direct forwarding, cache write, cache hit, retained message read, mirror read, and history replay. Network node authentication keys are allocated by the key management service and stored in the node's secure storage area. Edge computing nodes verify the node tracking authentication code based on verification information in the node registration database.

[0095] When a network node first caches and writes state data, it generates a data object identifier:

[0096] in, Identify data objects; For identifying network nodes; A summary of the state data; Write the sequence number to the local monotonically increasing cache of this network node.

[0097] When this cached object is read again in subsequent cache hits, mirroring, or protocol conversions, it inherits the same data object identifier and is not regenerated. The data object identifier is used to determine whether data returned by different protocols actually references the same cached object.

[0098] Edge computing nodes verify the status data authentication code and check the execution root identifier, collection challenge identifier, original sampling event identifier, status read time, and status version number. Data with failed verification, non-existent challenges, incorrect read times, or outdated status version numbers is no longer processed. Edge computing nodes read source tracing records from the gateway log interface, message broker tracing interface, and protocol conversion node status interface, verify the node tracing authentication code, and connect the actual transmission path according to the preceding and following node identifiers. Data that cannot form a continuous path from the terminal to the edge computing node is marked as having an incomplete source link and is not included in the independent source rank calculation.

[0099] Edge computing nodes form a causal origin hypergraph, with the execution root node, collection challenge, raw sampling event, state data, and network nodes as graph nodes, and the relationship between challenge generation, triggered sampling, data generation, and transmission as associated edges. In the computer processing system, the causal origin hypergraph is specifically stored using an incidence matrix or an adjacency list data structure with attribute labels to record the complex causal mapping relationship where an associated edge connects multiple graph nodes.

[0100] The causal origin hypergraph is used to describe the causal relationship of state data from execution root triggering, terminal sampling to network transmission.

[0101] Network nodes that experience cache hits, retained message reads, mirror reads, or history replays, or that provide the same data object identifier to two or more sets of state data, are identified as critical cache nodes. Public gateways that only perform direct forwarding and do not read or write state content are not considered critical cache nodes. For example, if MQTT and HTTP state data pass through the same gateway but are both directly forwarded and have different original sampled event identifiers, this gateway is not a critical cache node; however, if HTTP data reads MQTT state objects stored on this gateway, then this gateway is a critical cache node.

[0102] S430. Edge computing nodes filter valid state data from the causal source hypergraph to form a valid state data set, based on the following conditions: the state data authentication code is verified; the collection challenge identifier is valid; the original sampling event identifier can be verified; the state reading time is later than the collection challenge reception time; the state version number is not lower than the state version number after execution; the source link is complete; and it can be traced back to the current execution root node. Duplicate data and data without original sampling events are not included in this set.

[0103] State data triggered by different acquisition challenges, possessing different original sampling event identifiers, and not having passed through the same critical cache node, are identified as mutually independent state data. The initial independent source rank is determined according to the following formula:

[0104] in, This is the currently calculated independent source rank (in this step, it is the initial independent source rank). A valid set of state data; A subset is defined as any two sets of state data that have different original sampling event identifiers and whose sets of key cache nodes have no intersection.

[0105] The initial state data does not exceed 8 copies. Edge computing nodes enumerate subsets and take the maximum number that meets the conditions. For example, if MQTT and HTTP state data have the same original sampled event identifier, and CoAP state data has a different original sampled event identifier and has not passed through a critical cache node used by both, then the initial independent source rank is 2.

[0106] Edge computing nodes read the preset closed-loop threshold from the closed-loop verification strategy table: 2 if there are 2 available communication protocols, 3 if there are at least 3, and it must not be lowered within the current remote control session. The source evidence gap is obtained by subtracting the initial independent source rank from the preset closed-loop threshold and setting the negative value to 0.

[0107] When the source evidence gap is greater than 0, supplementary collection constraints are generated, including the source evidence gap, the set of key cache nodes that are prohibited from being passed through, the set of used communication protocols, the set of used transmission paths, the set of unused communication protocols that are preferred, the maximum allowable delay of the candidate path, the maximum allowable packet loss rate, the maximum allowable number of overlapping nodes, and the maximum number of supplementary collections. These constraints are then output to S510 as path filtering conditions, heuristic information parameters, and termination conditions for the ant colony algorithm.

[0108] S5 specifically includes the following sub-steps: S510. When the source evidence gap output by S430 is greater than 0, the edge computing node establishes a candidate protocol path graph based on the current network topology, protocol capability information, and supplementary acquisition constraints. The candidate protocol path graph is a directed graph representing the acquisition challenge that can reach the target shared disinfection machine from the edge computing node via communication protocols and network nodes. The path nodes include edge computing nodes, sending gateways, message brokers, protocol conversion nodes, edge forwarding nodes, and the protocol adapter of the target shared disinfection machine. The path edges represent the currently available communication links between adjacent nodes.

[0109] The node and link relationships are derived from the gateway routing table, message broker connection table, protocol conversion configuration table, and protocol capability information formed by S110, respectively; the link latency and packet loss rate are derived from the most recent 50 successful communication records, and when the sample is less than 20, the preset statistical values ​​of the same type of link are used.

[0110] Edge computing nodes remove offline nodes, nodes using protocols not supported by the target shared disinfection machine, path edges with expected latency or packet loss rates exceeding limits, and paths that must pass through critical cache nodes and cannot be proven to be directly forwarded. The initial pheromone for all admitted path edges is set to 1.

[0111] Heuristic information is calculated based on normalized link delay, normalized packet loss rate, normalized node overlap rate with used transmission paths, and expected independent source gain:

[0112] in, This provides heuristic information for the path edge i to j; For the expected independent source gain; , and These are normalized latency, packet loss rate, and node overlap rate, respectively. , and These are the control weights corresponding to these three factors, and the sum of the three weights is 1. To prevent the tiny compensation constant with a denominator of zero, we take 0.001.

[0113] When a path edge introduces a node that does not use a communication protocol or a sending gateway, and does not enter a critical cache node, The expected independent source gain is set to 1 for all others and 0 for the rest. When the candidate complete path simultaneously adopts no communication protocol, no sending gateway, and avoids critical cache nodes, its expected independent source gain is set to 1; otherwise, it is set to 0.

[0114] The probability that the m-th ant chooses node j from node i is:

[0115] in, Probability of path selection; For path edge pheromones; For pheromone weights; To heuristically assign weights to information; h represents the set of optional next nodes that have not yet been visited. Any candidate next node in the array.

[0116] If the selectable set is empty or the denominator is 0, the path construction for that ant is terminated, and filtered path edges are not selected. In this embodiment, the number of ants is 10. Take 1, The parameters are set to 2, the pheromone evaporation coefficient to 0.2, and the maximum number of iterations to 30. These parameters are derived from the path search parameter table pre-stored in the edge computing node.

[0117] Each round combines normalized latency, packet loss rate, and node overlap rate with the aforementioned corresponding control weights. , , Calculate the weighted sum, which is the total path cost of the path. ), and calculate the pheromone increment and update pheromone according to the following formula:

[0118]

[0119] Where t represents the current iteration number; Let be the pheromone increment left by the m-th ant on the path edges i to j. The expected independent source gain for the complete path obtained by the m-th ant; This represents the total cost of the path. Here, M represents the pheromone evaporation coefficient; M represents the number of ants; without using path edges... Take 0.

[0120] The search stops and a supplementary set of communication protocol paths is output when the sum of the expected independent source gains of the path set is not less than the source evidence gap, the optimal result remains unchanged for 5 consecutive rounds, the maximum number of iterations is reached, or no available path exists. For example, both the MQTT path and the HTTP path pass through the critical cache node C1, while the CoAP path via gateway G2 does not pass through C1. Although the latter has a larger latency, its expected independent source gain is 1, so it should be selected first.

[0121] S520: The edge computing node generates a new acquisition challenge for each path in the supplementary communication protocol path set. Each acquisition challenge uses a new acquisition challenge identifier and acquisition challenge randomness, and carries the execution root identifier, session epoch, current session count, and lowest state version number. The target shared disinfection machine calls the local state acquisition interface according to S410, increments the local sampling sequence number by 1, and forms a new original sampling event. The initial state data must not be retransmitted via a new path and counted as a new source; when the same original sampling event is transmitted via different paths, it is still treated as one source.

[0122] After receiving supplementary status data, the edge computing node verifies the status data authentication code, collection challenge identifier, original sampling event identifier, status read time, status version number, and source link integrity, and confirms that it can be traced back to the current execution root node. A deduplication key is formed using the execution root identifier, collection challenge identifier, and original sampling event identifier; duplicate data is only supplemented with return path records.

[0123] After verification, the new collection challenge, original sampling events, supplementary state data and source tracking records will be added to the causal source hypergraph, and key cache nodes will be re-identified. Nodes that have cache hits for more than two state data records, provide the same data object identifier, or perform mirror reading or historical replay will be identified as new key cache nodes.

[0124] Edge computing nodes recalculate the independent source rank according to S430 and calculate the actual source gain:

[0125] in, Gain from actual sources; and These are the independent source ranks before and after the supplementary data collection, respectively.

[0126] When the actual source gain is greater than 0, it is used as the expected independent source gain for the corresponding complete path in the next round; when it is equal to 0, the expected independent source gain of the path is set to 0, and pheromone evaporation is performed once more on its path edge before S510 is re-executed. For example, if the CoAP path superficially avoids C1, but the protocol conversion node reads the same data object as the MQTT path, then this node should be identified as the new critical cache node, and the actual source gain for this round is 0.

[0127] Supplementary data collection stops when the independent source rank reaches the preset closed-loop threshold; if the threshold is not reached and the maximum number of supplementary data collections is not exceeded, the search continues; if the upper limit of the number of collections is reached but the threshold is still not reached, the source verification result is marked as insufficient source evidence.

[0128] S530 and edge computing nodes determine the initial independent source rank obtained in S430 or the independent source rank updated in the most recent S520 as the final independent source rank, and perform five types of checks in sequence. Session authenticity check includes the validity of the federated commit proof authentication code, the consistency between the federated commit digest and the current session record, and the consistency between the session epoch and the current session count; unique branch execution check includes the consistency between the branch to be executed and the branch disclosure information, the cancellation of the witness corresponding to the unexecuted branch, and the absence of a second valid branch execution event in the same current session count.

[0129] Post-execution sampling verification includes that all state data involved in the judgment can be traced back to the execution root node, the state reading time is later than the execution end time, and the state version number is not lower than the post-execution state version number; source independence verification includes that the final independent source rank reaches the preset closed-loop threshold, and the data involved in the calculation do not pass through the same key cache node; state consistency verification includes that the state data of each independent source are consistent with the target control result of S110, and there is no valid independent source returning conflicting state.

[0130] A valid communication loop is confirmed only when all five types of checks pass. If two of the three independent state data are the target state and one is a conflicting state, majority voting is not used; instead, the result is determined to be a state conflict.

[0131] Edge computing nodes generate closed-loop verification records, including the target session identifier, session epoch, current session count, joint commit digest, pending branch identifier, execution root identifier, state transition digest, final independent source rank, original sampled event identifier set, key cache node set, closed-loop result code, and closed-loop verification authentication code. The closed-loop result code includes valid communication closed loop, insufficient source evidence, no available independent path, invalid execution evidence, state conflict, and inconsistent session data.

[0132] The closed-loop verification authentication code is generated by the edge computing node using the closed-loop record authentication key. The closed-loop record authentication key is allocated by the key management service and stored in the secure storage area of ​​the edge computing node, and is not mixed with the session authentication key. A valid communication closed-loop record is written to the session database and serves as the basis for the target shared disinfection machine to accept the next remote control request; if a valid communication closed loop is not formed, the current remote control session remains in an unconfirmed state, and related state data is prohibited from being used as the initial state for subsequent automatic control.

[0133] All the above formulas are performed using dimensionless numerical calculations; the relevant formulas are based on empirical models that approximate the real situation, obtained through extensive data collection and software simulation fitting. The preset parameters and thresholds involved in the formulas can be conventionally set and adjusted by those skilled in the art according to the physical constraints of the actual application scenario.

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

[0135] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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.

[0136] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A closed-loop control method for multi-protocol collaborative data acquisition of a shared disinfection machine, characterized in that, Includes the following steps: S1. Obtain a remote control request for the target shared disinfection machine, generate a first control envelope and a second control envelope with the same target control result but different unlocking conditions, and send them to the target shared disinfection machine via different communication protocols; S2. Receive the joint submission proof generated by the target shared disinfection machine based on the two control envelopes, the current session count, and the terminal random quantity. After verification, generate branch disclosure information. S3. Send the branch disclosure information to the target shared disinfection machine, so that it only grants one-time execution qualification to the matching control envelope, and generates a deregistration witness for the other control envelope. Receive the branch execution event generated after execution, and establish the execution root node based on the branch execution event and the deregistration witness. S4. Based on the execution root node, send the collection challenge through multiple communication protocols, receive the resampled state data, record the original sampling events, source tracing records and actual transmission paths, construct the causal source hypergraph and calculate the initial independent source rank.

2. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 1, characterized in that, Also includes: S5. When the initial independent source rank is lower than the preset closed-loop threshold, the ant colony algorithm is used to select a supplementary communication protocol path that avoids key cache nodes, and supplementary collection is performed to update the causal source hypergraph and independent source rank. When the session authenticity, unique branch execution, post-execution sampling, source independence and state consistency all meet the preset closed-loop conditions, a valid communication closed loop is confirmed to be formed.

3. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 1, characterized in that, S1 specifically includes: Receive and verify remote control requests, read protocol capability information based on terminal identifier, generate target session identifier and session epoch, and determine the effective execution duration based on historical communication latency and terminal response duration to form basic session data; Two random unlock values ​​are generated and the corresponding unlock condition commitment values ​​are calculated. An effective execution time window is established, a session authentication key is derived, and a first control envelope and a second control envelope with the same target control result but different branch identifiers and unlock condition commitment values ​​are formed. Determine the first and second communication protocols, encapsulate and send the two control envelopes, record the actual transmission path, and establish the protocol path correspondence between the control envelope digest, the communication protocol, and the actual transmission path.

4. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 1, characterized in that, S2 specifically includes: The target shared disinfection machine parses two control envelopes, verifies the consistency of the control envelope authentication code and fields, writes the valid control envelope into the control area to be unlocked and generates a branch receiving record, and updates the current session count and generates a terminal random quantity when both control envelopes are valid and come from different communication protocols. By combining the two control envelope digests, two branch receive records, the current session count, the terminal random variable, and the session epoch in a fixed order, a joint commit digest and a joint commit authentication code are generated, forming a joint commit proof and returning it to the edge computing node.

5. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 4, characterized in that, Also includes: Edge computing nodes verify the correspondence between session epochs, control envelope digests, and protocol paths, validate joint commit proofs, generate branch selection random variables to determine the branch to be executed, and generate branch disclosure information based on the corresponding random unlock value, current session count, and joint commit digest.

6. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 1, characterized in that, S3 specifically includes: The target shared disinfection machine verification branch reveals information and corresponding random unlock values. Based on the branch to be executed, a one-time execution qualification is generated. Unexecuted control envelopes are marked as deregistered and deregistration witnesses are generated. The one-time execution qualification is changed from unused to used. The execution of the control envelope to be executed is carried out through the local control execution interface. The terminal running status before and after execution is read, and the state transition summary, execution completion sequence number and branch execution event are generated. Edge computing nodes verify session data, branch identifiers, control envelope digests, and authentication codes in branch execution events and deregistration witnesses, verify one-time execution eligibility identifiers and state transition digests, and generate execution root identifiers and establish execution root nodes when execution evidence is valid.

7. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 1, characterized in that, S4 specifically includes: Based on the execution root node and protocol capability information, a collection challenge is generated for the communication protocol; after the target shared disinfection machine is verified, the local status collection interface is called to reread the terminal running status, forming the original sampling events and status data. Record source tracking records, caching operations, and data object identifiers generated when state data is forwarded through network nodes, verify state data and source links, construct a causal source hypergraph, and identify key caching nodes.

8. The method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 7, characterized in that, Also includes: State data is filtered from the causal source hypergraph. Data with different original sampling events and that have not passed through the same key cache node are identified as independent. The initial independent source rank is calculated, and source evidence gaps and supplementary collection constraints are generated when the rank is below the preset closed-loop threshold.

9. A method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 2, characterized in that, S5 specifically includes: Based on the source evidence gap, key cache node set and supplementary collection constraints, a candidate protocol path graph is constructed, path edge pheromones and heuristic information are set, and the ant colony algorithm is used to search for a set of supplementary communication protocol paths that can increase the independent source rank. New acquisition challenges are sent along the supplementary communication protocol path, supplementary state data is received, added to the causal source hypergraph, key cache nodes are re-identified, independent source rank and actual source gain are calculated, and the search continues if the preset closed-loop threshold is not reached.

10. A method for closed-loop control of multi-protocol collaborative data acquisition for a shared disinfection machine according to claim 9, characterized in that, Also includes: The system verifies the authenticity of joint submissions, branch disclosure information, deregistration witnesses, branch execution events, execution root nodes, and status data, as well as the uniqueness of branch execution, post-execution sampling, source independence, and status consistency. When all of these verifications pass, a closed-loop verification record is generated, and a valid communication loop is confirmed.

Images