A Closed-Loop Method for Weak Network Sequence Preservation Delivery of Industrial Control Commands

Abstract

This invention discloses a closed-loop method for weak network order preservation delivery of industrial control commands, relating to the field of industrial internet technology. The method includes encapsulating industrial control commands into a shell carrying device status tickets, importing them into a logical sequence channel, and ensuring order with phase gate numbers. At the consumer end, the commands are written into an idempotent ledger, their status is verified, executed, and device echo feedback is generated. After the weak network recovers, the status of the headquarters, base, and devices is checked, and supplementary execution, supplementary feedback, or isolation processing is performed. This invention, through the cooperation of device status tickets, device-level phase gate numbers, persistent idempotent ledgers, device echo summaries, and a three-party status verification mechanism, achieves execution condition verification, device-level order preservation, idempotent execution recording, and post-recovery compensation processing for control commands under weak network conditions. This avoids command out-of-order delivery and duplicate activation of non-idempotent commands, improving command delivery reliability, execution security, and state loop consistency.

Description

Technical Field

[0001] This invention relates to the field of industrial internet technology, and in particular to a closed-loop method for weak network order preservation delivery of industrial control commands. Background Technology

[0002] In distributed industrial control scenarios such as mining areas, offshore wind power, and remote factories, headquarters typically need to issue control commands such as start / stop, parameter adjustment, reset, and upgrade to multiple base-side devices. Because these scenarios often involve unstable public network links, high transmission latency, high packet loss rates, and short-term network interruptions, traditional synchronous call methods between headquarters and base stations are prone to timeout retries, call blocking, and even cascading link failures during network fluctuations. To reduce the pressure of synchronous calls, existing systems also use message queues for asynchronous decoupling. However, general message queues usually focus more on whether messages are successfully delivered and cannot directly express the relationship between the current operating status of industrial equipment, the execution result of previous commands, and the target state of the current command. Therefore, after the control commands reach the base consumer, there may still be discrepancies between the actual state of the equipment and the conditions under which the commands are executed.

[0003] Meanwhile, in high-concurrency command issuance scenarios, multiple control commands from the same device may experience execution order misalignment due to route dispersion, partition expansion and contraction, consumer takeover switching, or network recovery resending. Existing order-preserving methods based on partition order or message offset can typically only guarantee message order within the same partition, making it difficult to guarantee the continuity of the device-level execution chain after cross-partition migration, consumer restart, or weak network recovery. On the other hand, network retries and consumer crash recovery may cause the same control command to be delivered repeatedly. For non-idempotent industrial operations such as parameter tuning and firmware upgrades, repeated execution may lead to abnormal device status or security risks. Furthermore, after network interruption recovery, there may be inconsistencies between the headquarters' issued records, the base's local execution records, and the actual device status. Existing solutions lack a closed-loop verification mechanism that can distinguish between situations such as not reaching the base, arriving but not executed, executed but not reported, and status out of bounds, resulting in a lack of clear basis for subsequent re-execution, re-reporting, or isolation handling. To address this, we propose a closed-loop method for weak network order-preserving delivery of industrial control commands. Summary of the Invention

[0004] The purpose of this invention is to provide a closed-loop method for weak network order-preserving delivery of industrial control commands, in order to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a closed-loop method for weak network order-preserving delivery of industrial control commands, comprising: S1. The industrial control command to be issued is encapsulated into a control command shell carrying a device status ticket. The device status ticket is formed by the device's valid operating condition cached on the base side, the execution result of the previous valid command, and the target status summary. S2. According to the device affiliation, the control command shell is imported into the corresponding logical sequence channel, and the device-level phase gate number is maintained in the logical sequence channel to determine the succession relationship of the control command shell in the device execution chain, so that the control command shell with the execution phase rollback cannot enter the execution segment. S3. Before executing the control command, the consumer writes the command execution intention into the persistent idempotent ledger and compares the device real-time status summary with the device status ticket. If the comparison is consistent, the control command is sent to the device. If the comparison is inconsistent, the control command is transferred to the shadow verification queue and re-compared or transferred to isolation processing after the device status is reconfirmed. S4. After the control command is executed, the consumer writes the device echo digest into the persistent idempotent ledger and generates execution feedback based on the device echo digest. S5. After the weak network is restored, the headquarters and the base consumer end perform status verification. The base consumer end sends the device execution level, idempotent ledger stage mark and device echo summary. The headquarters compares the data with the issued instruction records and performs supplementary execution, supplementary feedback or isolation for control instructions that have not been executed, have been executed but not fed back, or have exceeded the status limit.

[0006] Preferably, the process of generating the device status ticket includes: Read the device's operating status within the current control cycle, the execution result of the previous valid control command, and the target status of the current control command; The running status, execution result and target status are combined and verified to obtain a status ticket used to limit whether the current control command is allowed to be executed. If the previous valid control instruction has not produced a verifiable execution result, the current control instruction will not generate a passable status ticket.

[0007] Preferably, the logical sequence channel is provided with a device-level phase gate number, which advances with the valid execution result of the device; when the status ticket corresponding to the control command shell does not match the device-level phase gate number, the consumer suspends the execution of the control command shell and marks it as a phase pending confirmation state.

[0008] Preferably, when a logical sequence channel is migrated, a landmark relay migration method is adopted: Write migration markers for the logical sequence channels corresponding to the devices to be migrated; Control commands preceding the migration marker continue to be executed via the original logical sequence channel; Control instructions following the migration marker are temporarily stored in the shadow buffer segment of the new logical sequence channel; After the original logical sequential channel executes to the migration boundary and forms the final state, the new logical sequential channel releases the control instructions in the shadow buffer segment.

[0009] Preferably, the persistent idempotent ledger establishes a corresponding ledger for each control instruction. The ledger includes an intent column, a device echo column, and a feedback column. The intent column is used to record whether the control instruction has entered the preparation execution state. The device echo column is used to record whether the device has formed an actual state change corresponding to the control instruction. The feedback column is used to record whether the corresponding execution feedback has been formed and issued.

[0010] Preferably, when an unclosed ledger is found in the persistent idempotent ledger after the consumer restarts, the recovery type of the unclosed ledger is identified based on the combined state of the intent bar, the issued action record, the device echo bar, and the feedback bar.

[0011] Preferably, the recovery types include unreached device, sent but not responded to, executed but not responded to, and feedback sent but not closed. The consumer end performs cancellation, status query, feedback resending, or ledger closure according to the recovery type.

[0012] Preferably, when the status of the feedback bar is uncertain but the device echo bar has recorded the actual status change, the consumer generates compensation feedback. The compensation feedback carries a device echo summary, enabling the headquarters to distinguish between real execution feedback and duplicate delivery feedback.

[0013] Preferably, the status verification includes a three-way verification of the headquarters' issued records, the base's persistent idempotent ledger, and the actual status of the equipment; when the three-way verification results are inconsistent, a compensation and handling label is generated, and the compensation and handling label includes at least the following: not reached the base, arrived but not executed, executed but not fed back, and status out of bounds.

[0014] Preferably, when a takeover switch occurs at the consumer end, the exiting consumer end generates a channel handover water level sheet, which includes the last executed water level of the device, the gap waiting interval, and the idempotent ledger version; after the takeover consumer end verifies that the channel handover water level sheet is consistent with the local idempotent ledger, it continues to execute the control commands of the corresponding device.

[0015] A weak-network order-preserving delivery closed-loop system for industrial control commands, applied to any of the weak-network order-preserving delivery closed-loop methods for industrial control commands, includes: The status ticket generation module is used to generate a device status ticket based on the device's valid operating conditions cached on the base side, the execution result of the previous valid instruction, and the target status summary. The phase sequence control module is used to maintain the device-level phase gate number and prevent control commands that are discontinuous in status tickets or execute phase back-off from entering the execution segment; The marker migration module is used to generate migration markers during logical sequence channel migration and to control the instruction continuation between the original logical sequence channel and the new logical sequence channel. The idempotent ledger execution module is used to record the closed-loop execution status of control commands through the intent bar, issued action record, device echo bar, and feedback bar. The weak network echo verification module is used to perform a three-way verification of the records issued by headquarters, the idempotent ledger of the base, and the actual status of the equipment after the weak network is restored, and to generate corresponding compensation and disposal tags.

[0016] The technical effects and advantages of this invention are as follows: This invention, by combining device status tickets, device-level phase gate numbers, persistent idempotent ledgers, device echo summaries, and a three-party status verification mechanism, enables industrial control commands in weak network environments to first determine whether they meet the execution conditions based on the effective operating conditions of the device and the results of previous executions, and then to receive them in the correct order according to the device execution chain. Intent records, actual device status records, and feedback records are generated before and after execution, respectively. When network interruptions, consumer restarts, channel migrations, or feedback loss occur, the system can distinguish between states such as unreached devices, issued commands without echoes, executed commands without feedback, and out-of-bounds states based on the idempotent ledger and device echo summaries, and perform supplementary execution, supplementary feedback, or isolation measures accordingly. This avoids out-of-order execution of the same device command and duplicate activation of non-idempotent commands, improving the reliability of command delivery, execution security, and the consistency of the state loop after weak network recovery in distributed industrial control scenarios. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention, but do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram illustrating the coordinated sequence preservation of device status tickets and phase gate numbers according to the present invention; Figure 2 This is a schematic diagram of the channel handover for the consumer-side takeover switching of the present invention. Detailed Implementation

[0018] 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.

[0019] This invention provides, for example Figures 1-2 The illustrated closed-loop method for weak network order-preserving delivery of industrial control commands includes: S1. The industrial control instructions to be issued are encapsulated into a control instruction shell carrying an equipment status ticket. The equipment status ticket is formed by the effective operating conditions of the equipment already cached on the base side, the execution result of the previous effective instruction, and the target status summary. Among them, the equipment status ticket refers to the status access information used to determine whether a control command meets the conditions for execution. It is formed by the effective operating condition of the equipment, the execution result of the previous effective command, and the target status summary. It is not a physical ticket, but execution access verification data. The control command shell refers to the business message unit after encapsulating the industrial control command. It may contain information such as control payload, status ticket, target status summary, and execution constraints. The process of generating equipment status tickets includes: Read the device's operating status within the current control cycle, the execution result of the previous valid control command, and the target status of the current control command; The running status, execution result and target status are combined and verified to obtain a status ticket used to limit whether the current control command is allowed to be executed. If the previous valid control instruction has not produced a verifiable execution result, the current control instruction will not generate a passable status ticket. In practical implementation, after generating industrial control instructions, the headquarters-side remote control and distribution platform does not directly send the control payload to the base-side equipment. Instead, it first encapsulates the industrial control instructions to be issued into a control instruction shell. The control instruction shell serves as the basic business unit for asynchronous message transmission between the headquarters and the base. It is used to carry the control payload, target equipment information, execution constraint information, and equipment status tickets for pre-execution verification. Combined with the system topology of this invention, the headquarters and the base do not establish a direct synchronous connection. Instead, the instructions are issued and feedback is returned through the asynchronous message hub. Therefore, a verifiable equipment status ticket is pre-formed before the instructions enter the message hub, which can provide a unified basis for the subsequent ordered execution, idempotent judgment, and anomaly recovery of the base-side consumer end. The device status ticket can be formed by the cached valid operating conditions of the device on the base side, the execution result of the previous valid instruction, and the target status summary of the current control instruction. The cached valid operating conditions of the device on the base side can be derived from the most recently confirmed device status in the base acquisition agent, consumer execution gateway, or local persistent ledger, such as device operating mode, current, voltage, speed, start / stop status, or a status summary after execution. The execution result of the previous valid instruction can be derived from the final state record of the previous control instruction in the idempotent ledger, such as execution successful, execution failed, rolled back, or canceled. The target status summary of the current control instruction is extracted from the target control result of this control instruction, such as target speed, target operating mode, target start / stop status, or target parameter version. By combining the above three types of information, the current control instruction can carry not only the control content of "what to execute" but also the status constraint of "under what device status is execution allowed". When generating a device status ticket, the base or headquarters side can first read the device's operating status within the current control cycle and the execution result of the previous valid control instruction. Then, it can extract the target status expected by the current control instruction. Subsequently, the operating status, the previous execution result, and the target status are combined and verified. When the current operating status of the device matches the execution conditions of the current control instruction, and the previous valid control instruction has formed a verifiable final state result, a passable device status ticket is generated. When the previous valid control instruction is still being executed, the feedback is unknown, the execution failure is unprocessed, or the device status cannot be confirmed, a passable status ticket is not generated, or a status ticket with a pending confirmation mark is generated, preventing the control instruction from directly entering the device execution stage in subsequent consumption phases. For example, in a mine ventilation equipment control scenario, the previous instruction is "start the fan", and the current instruction is "adjust the fan speed to 800 RPM". If the most recent valid operating condition cached on the base side indicates that the fan is already running, and the previous start instruction has been successfully executed in the local idempotent ledger, then the current parameter tuning instruction can generate a passable equipment status ticket. If the previous start instruction has not yet been confirmed as successful, or the operating condition cached on the base side shows that the fan is still stopped, then the current parameter tuning instruction will not generate a passable status ticket. This can avoid common sequence misalignment problems in weak network environments, such as executing parameter tuning before the equipment has started or executing the next instruction before the previous instruction has been completed. This step works in conjunction with the instruction lifecycle state machine of the present invention to control the instruction to enter the message queue, be pulled by the base consumer, complete idempotency verification and be ready to be executed. The consumer can use the device status ticket to reconfirm the current device status, thereby forming a continuous chain of state constraints from the generation, queuing, pulling, verification to execution of the instruction. Through the above implementation methods, the device status ticket binds industrial control commands to the device status context before they enter the asynchronous message hub, preventing control commands from being executed independently of the actual operating conditions of the device in scenarios with weak networks, delays, or retry. The device status ticket incorporates the execution result of the previous valid command into the execution admission conditions of the current command, enabling multiple control commands for the same device to form a sequential relationship, reducing the risk of equipment damage or safety accidents caused by the out-of-order execution of consecutive commands such as start-up, parameter adjustment, and shutdown. When the previous valid control command has not generated a verifiable result, the current command does not generate a passable status ticket, allowing abnormal states to be intercepted before command execution, rather than waiting until the device malfunctions before taking remedial action. This status ticket also provides traceable status evidence for subsequent idempotent ledgers, device echo summaries, and third-party status verification, which is beneficial for determining whether commands should continue to be executed, reissue feedback, or be isolated after weak network recovery, thereby improving the security and recoverability of the industrial control command delivery closed loop.

[0020] S2. According to the equipment affiliation, the control command shell is imported into the corresponding logical sequence channel, and the equipment-level phase gate number is maintained in the logical sequence channel to determine the succession relationship of the control command shell in the equipment execution chain, so that the control command shell with the execution phase back cannot enter the execution segment. The logical sequence channel is equipped with a device-level phase gate number, which advances with the valid execution result of the device. When the status ticket corresponding to the control command shell does not match the device-level phase gate number, the consumer suspends the execution of the control command shell and marks it as a phase pending confirmation state. Specifically, when a logical sequence channel is migrated, a landmark relay migration method is used: Write migration markers for the logical sequence channels corresponding to the devices to be migrated; Control commands preceding the migration marker continue to be executed via the original logical sequence channel; Control instructions following the migration marker are temporarily stored in the shadow buffer segment of the new logical sequence channel; After the original logical sequential channel executes to the migration boundary and forms the final state, the new logical sequential channel releases the control instructions in the shadow buffer segment; When a takeover switch occurs at the consumer end, the exiting consumer end generates a channel handover water level sheet, which includes the last executed water level of the equipment, the gap waiting interval, and the idempotent ledger version. After the takeover consumer end verifies that the channel handover water level sheet is consistent with the local idempotent ledger, it continues to execute the control commands of the corresponding equipment. In practical implementation, after the control command shell is generated, it is not directly distributed and written to the message hub according to the sending order of ordinary messages. Instead, the corresponding logical sequence channel is first determined according to the device affiliation of the target device. The device affiliation may include information such as device identifier, base identifier, production unit to which the device belongs, or control loop where the device is located. In the system architecture of this invention, the headquarters and the base are decoupled through an asynchronous message hub. The message hub includes channels such as instruction issuance, data transmission, and execution feedback. The base side pulls and executes control commands through the consumption execution gateway. Therefore, the logical sequence channel can be understood as a device-level instruction execution path formed by device semantic routing, message partitioning, and the base-side consumption execution gateway. It is used to ensure that the execution order of control commands for the same device will not be disordered due to multi-path transmission, multi-partition writing, or consumer switching. To further enhance the order preservation security in industrial control scenarios, a device-level phase gate number is set within the logical sequence channel. This device-level phase gate number is not simply a message sequence number, but rather an execution chain marker representing the current executable phase that the device can undertake. It can be updated based on the device's last valid execution result, the confirmed device status summary, and the execution level in the idempotent ledger. When a control instruction shell enters the logical sequence channel, the consumer first reads the device status ticket carried by the control instruction shell and compares it with the device-level phase gate number currently stored in the logical sequence channel. If they match, it means the control instruction can continue execution after the previous valid control instruction. If they do not match, it indicates that the control instruction may have anomalies such as incomplete preceding instructions, unadvanced device status, execution phase rollback, or incorrect channel assignment. The consumer then suspends the execution of the control instruction shell and marks it as a phase pending confirmation state. For example, in the control of ventilation equipment in a mine, if the same equipment has three control commands in sequence: start the fan, adjust the speed, and stop the machine, the equipment-level phase gate number will advance after the start fan achieves a valid execution result, making the speed adjustment command eligible for acceptance. If the speed adjustment command is retrieved by the consumer before the start fan reaches its final state, or if the old start fan retry message arrives again due to network jitter, the consumer can identify that it does not conform to the current equipment execution chain acceptance relationship through the phase gate number, thereby preventing it from entering the execution segment. When a logical sequence channel migrates due to message hub expansion / shrinkage, partition rearrangement, or consumer rebalancing, this invention employs a boundary relay migration method to prevent the old and new channels from simultaneously receiving control commands from the same device. Specifically, the system first writes a migration boundary for the logical sequence channel corresponding to the device to be migrated. This migration boundary corresponds to the last execution level of the device that is currently allowed to be processed by the original logical sequence channel. Control commands before the migration boundary are still executed by the original logical sequence channel, ensuring that the existing commands that have entered the original channel can be cleared and form a final state. Control commands after the migration boundary do not immediately enter the execution segment but are temporarily stored in the shadow buffer segment of the new logical sequence channel. After the original logical sequence channel executes to the migration boundary and forms a final state, the new logical sequence channel releases the control commands in the shadow buffer segment, thus forming a clear handover boundary between the old and new channels. When a takeover switch occurs on the consumer side, such as when a consumer instance crashes and restarts, consumer group rebalancing occurs, the base-side consumer execution gateway is migrated, or the exclusive partition relationship is reallocated, the exiting consumer generates a channel handover water level sheet. The channel handover water level sheet includes the device's last execution water level, the gap waiting interval, and the idempotent ledger version. The device's last execution water level indicates the latest position that the device has confirmed to have executed; the gap waiting interval indicates instruction breakpoints or pending confirmation intervals discovered during consumption but not yet filled; and the idempotent ledger version indicates the update status of the local persistent idempotent ledger. Before taking over execution, the taking over consumer needs to verify the channel handover water level sheet against the local idempotent ledger. Only when the last execution water level, the gap waiting interval, and the idempotent ledger version correspond to each other are it allowed to continue pulling and executing subsequent control instructions for the device. This can prevent the new consumer from continuing to consume based solely on the message queue offset after a consumer switch, ignoring the actual execution water level of the device and the status of the local idempotent ledger, which could lead to missed or duplicate instruction execution. Through the above implementation methods, the logical sequence channel ensures that control commands for the same device are processed within the same device execution chain, preventing the same device command from being executed by different partitions, different consumers, or different network paths in high-concurrency scenarios. The device-level phase gate elevates the order preservation judgment from a simple message arrival order to a device execution status acceptance judgment, preventing expired, phase-backed, or incomplete preceding control commands from directly entering the device execution segment. The boundary relay migration method sets clear handover boundaries during logical sequence channel migration, allowing the old channel to be responsible for the existing commands before the boundary and the new channel to be responsible for the new commands after the boundary, reducing the risk of command interleaving caused by scaling up, down, and rebalancing. The channel handover water level sheet ensures that the consumer takeover process no longer relies solely on the partition allocation results of the message hub, but simultaneously verifies the device execution water level, gap waiting interval, and idempotent ledger version, thereby improving the device-level strict order preservation capability in weak network, downtime recovery, and consumer migration scenarios.

[0021] S3. Before executing control commands, the consumer writes the command execution intent into a persistent idempotent ledger. The persistent idempotent ledger is a local persistent execution state storage structure set up on the consumer side of the base station. It is used to save the command execution intent, issued actions, device echoes, feedback status, and ledger version at the record granularity of control commands. The consumer queries and updates the persistent idempotent ledger to determine whether the control command belongs to the first execution, repeated delivery, execution residue, executed but not fed back, or feedback sent but not closed status. Based on this, it performs device operation, status query, feedback resending, or ledger closure. It also compares the device real-time status summary with the device status ticket. If the comparison is consistent, the control command is sent to the device. If the comparison is inconsistent, the control command is transferred to the shadow verification queue and re-compared or transferred to isolation processing after the device status is reconfirmed. Among them, the shadow verification queue refers to the buffer queue used to temporarily store control instructions that are inconsistent with the real-time status of the equipment. Instructions entering this queue are not directly sent to the equipment, but are executed or isolated after the equipment status is reconfirmed. The persistent idempotent ledger establishes a corresponding ledger for each control command. The ledger includes an intent column, a device echo column, and a feedback column. The intent column records whether the control command has entered the ready-to-execute state. The device echo column records whether the device has formed an actual state change corresponding to the control command. The feedback column records whether the corresponding execution feedback has been formed and issued. Among them, when an unclosed ledger is found in the persistent idempotent ledger after the consumer restarts, the recovery type of the unclosed ledger is identified based on the combined state of the intent bar, the issued action record, the device echo bar, and the feedback bar. The recovery types include unreached devices, issued but not responded, executed but not responded to, and feedback sent but not closed. Consumers can cancel, query status, reissue feedback, or close the ledger according to the recovery type. In practice, after the consumer on the base side pulls the control instruction shell from the logical sequence channel, it does not immediately send the control load to the underlying industrial equipment. Instead, it first enters the pre-execution confirmation stage. The consumer first establishes a corresponding persistent idempotent ledger based on the control instruction shell and writes the instruction execution intent in the intent field of the persistent idempotent ledger. The intent field is used to indicate that the control instruction has entered the preparation stage, so as to avoid the system being unable to determine whether the instruction has been processed in the event of consumer downtime, network retries, or message duplication. After the intent field is written, the consumer reads the real-time status of the underlying industrial equipment and generates a real-time status summary. The real-time status summary can be extracted from operating information such as equipment operating mode, start / stop status, current, voltage, speed, parameter version, execution lock status, or communication online status. Subsequently, the consumer compares the real-time status summary with the equipment status ticket carried in the control command shell. If they match, it means that the current actual operating condition of the equipment can receive the control command, and the consumer sends the control load to the target industrial equipment. If they do not match, it means that there is a deviation between the current status of the equipment and the execution conditions when the command was generated. This may be because the previous command has not been completed, the equipment status has rolled back, the equipment has been manually intervened during a weak network period, or the status view between the headquarters and the base is not synchronized. In this case, the consumer does not execute the control command directly, but transfers it to the shadow verification queue. The shadow verification queue is used to temporarily store control commands whose state conditions have not been met or whose state consistency has not been confirmed. Control commands entering the shadow verification queue will not directly affect the underlying devices. Consumers can reconfirm the device state by re-collecting the device state, querying the local persistent idempotent ledger, requesting the headquarters to issue records, or waiting for the preceding commands to form a final state. When the reconfirmed device state summary matches the device state ticket, the control command can re-enter the pre-execution comparison process. If the reconfirmation is still inconsistent, or if it is confirmed that the control command no longer meets the conditions for safe execution, the control command is transferred to isolation. Isolation can include canceling execution, waiting for manual review, entering the anomaly list, or being uniformly processed during the third-party state verification during weak network recovery. In this way, it is possible to avoid forcibly issuing control commands to devices when the device state is unknown or inconsistent.

[0022] In the persistent idempotent ledger of each control command, the intent column, device echo column, and feedback column correspond to the three key stages in the control command execution loop. The intent column records whether the control command has entered the preparation state for execution; the device echo column records whether the device has formed an actual state change corresponding to the control command, such as the device return code, post-execution status, whether the target parameters have taken effect, and whether the device has entered the target operating mode; the feedback column records whether the execution feedback corresponding to the control command has been formed and sent. In this way, even if the consumer crashes or restarts at any stage, it can determine which execution stage the control command is currently in by reading the status of the three columns, rather than relying solely on whether the message queue has been redelivered to determine whether the device operation needs to be executed again. When the consumer restarts and finds an unclosed ledger in the persistent idempotent ledger, the consumer identifies the recovery type of the unclosed ledger based on the combined state of the intent bar, the issued action record, the device echo bar, and the feedback bar. The issued action record indicates whether the control payload has been actually sent to the underlying device, the device echo bar indicates whether the underlying device has formed a verifiable state change, and the feedback bar indicates whether the execution feedback has been returned to headquarters or written to the feedback channel. By adding the issued action record, it is possible to avoid the inability to distinguish between two situations: never reaching the device and issued but not responded to by the device, simply because the device echo bar is empty. Specifically, when the intent column contains a record but the action record does not, and both the device echo and feedback columns are empty, it can be identified as the device not being reached. The consumer can cancel the unclosed ledger or re-enter the pre-execution state comparison. When the intent column and the action record exist, but the device echo column is empty, it can be identified as the action being issued but not responded to. The consumer needs to query the underlying device for the actual operating status to determine whether the device has executed the action. When the device echo column has recorded the actual state change, but the feedback column has not recorded the feedback completion, it can be identified as the action being executed but not responded to. The consumer does not reissue the device operation but instead reissues the execution feedback based on the device echo column. When the feedback column shows that feedback has been formed but the ledger is not closed, it can be identified as feedback being sent but not closed. The consumer only completes the ledger closure or confirms the subsequent consumption progress. Through the above implementation methods, the persistent idempotent ledger ensures that each control instruction forms a recoverable execution placeholder before execution, preventing the same instruction from being repeatedly and effectively executed after network retries or consumer restarts. The comparison between the device status ticket and the device real-time status summary allows the consumer to re-verify the actual operating condition of the device before execution, preventing control instructions from acting on incorrect device states due to weak network delays, out-of-order delivery, or lag in the status view. The shadow verification queue provides a non-destructive buffer path for control instructions with inconsistent states, allowing abnormal instructions to be suspended and verified first, rather than failing or being executed incorrectly. Through the combined judgment of the intent bar, issued action record, device echo bar, and feedback bar, the consumer can distinguish between states such as unreached devices, issued but not echoed, executed but not responded to, and feedback issued but not closed after a crash recovery, and thus execute cancellation, status query, feedback re-issuance, or ledger closure respectively, ensuring that non-idempotent industrial control instructions such as parameter tuning and upgrades only generate one effective device status change in a weak network environment.

[0023] S4. After the control command is executed, the consumer writes the device echo digest into the persistent idempotent ledger and generates execution feedback based on the device echo digest. Among them, when the status of the feedback bar is uncertain but the device echo bar has recorded the actual status change, the consumer generates compensation feedback. The compensation feedback carries the device echo summary, enabling the headquarters to distinguish between real execution feedback and duplicate delivery feedback. In practical implementation, after the consumer sends out the control command, it continues to wait for the underlying industrial equipment to return the execution result through the device bus, industrial gateway, or local acquisition interface. The execution result may include the device return code, execution completion flag, execution failure reason, post-execution operating mode, key operating parameters, and whether the target state has been achieved. After obtaining the above information, the consumer does not just save it as a regular log, but organizes it into a device echo summary and writes it into the device echo column of the persistent idempotent ledger corresponding to the control command. The device echo summary is used to characterize the actual state changes that the device has made in response to the control command. It can be formed by the device return code, post-execution state, target state achievement result, acquisition time, ledger version, etc. In the execution closed loop of the present invention, the device echo summary is an intermediate confirmation layer between the control command execution result and the headquarters feedback. That is, the consumer end only generates execution feedback based on the device echo summary after writing the device echo summary in the device echo column, and delivers the execution feedback to the execution feedback channel. Execution feedback can include information such as control command identifier, device identifier, execution success or failure result, device return code, device echo digest, feedback generation time, and feedback source status. Among these, the device echo digest serves as the core basis for feedback, enabling the headquarters to not only know whether the command was executed successfully after receiving feedback, but also to obtain summary information on the actual changes in the device's status. This allows the headquarters to determine whether the feedback corresponds to the actual device execution result based on the device echo digest when subsequently verifying the distribution records, the base idempotent ledger, and the actual device status, rather than simply judging the command status based on whether the message has arrived. When the feedback status is determined to be "not sent", the consumer generates normal execution feedback based on the device echo digest and submits it to the execution feedback channel. When the feedback status is determined to be "sent", the consumer does not generate normal execution feedback again, but keeps the ledger closed or waits for subsequent verification. When the feedback status is uncertain but the device echo bar has recorded the actual status change, it means that the device may have completed execution, but a network anomaly, process crash, or communication interruption occurred before the consumer submitted feedback, confirmed feedback, or committed offset. In this case, the consumer does not reissue control commands, but generates compensation feedback based on the device echo digest already saved in the device echo bar.

[0024] Both compensation feedback and normal execution feedback carry device echo summaries. However, compensation feedback is used to explain that the feedback is generated based on the actual changes in the device's state already recorded in the local idempotent ledger, rather than a new feedback generated after re-executing the device operation. For example, after a parameter adjustment command is successfully executed, the consumer has written the device speed adjustment result into the device echo column, but a crash occurs before successfully sending feedback to headquarters. After the consumer restarts and reads the ledger again, it finds that the device echo column has recorded the target state change, but the state in the feedback column is uncertain. At this time, the consumer directly generates compensation feedback and sends the original device echo summary to headquarters, instead of re-issuing the parameter adjustment command to the device. This allows headquarters to distinguish between situations where the device has indeed executed but the feedback is lost and situations where feedback is replayed due to repeated delivery.

[0025] This step can also be used in conjunction with the three-party status verification process after the weak network is restored. When the network is restored, the headquarters identifies the unconfirmed instructions based on the issued instruction records. When the base consumer queries the local idempotent ledger, if it finds that the device echo column already has a device echo summary but the feedback column is not closed, it can be determined that the instruction belongs to the type of executed but not fed back, and compensation feedback with device echo summary is directly reissued. Through the above implementation methods, the device echo summary solidifies the actual state changes of the underlying devices into a persistent idempotent ledger, so that the execution results of control commands no longer depend solely on instantaneous feedback messages, enhancing traceability in weak network environments. When the consumer end experiences a crash or network interruption after successful device execution but before feedback is sent, the system can generate compensating feedback based on the device echo column, avoiding the repeated execution of non-idempotent device operations to resend feedback. The compensating feedback carries the device echo summary, enabling headquarters to distinguish between the actual execution results, the feedback compensation results, and the duplicate delivery messages, thereby reducing the risk of repeated execution of industrial control commands such as parameter tuning and upgrades. The device echo summary provides a unified comparison basis for subsequent status verification between headquarters, bases, and devices, helping to quickly determine whether a command has been executed but not responded to, has not been executed and is awaiting compensation, or is isolated due to an abnormal state after the weak network is restored, thus improving the reliability and security of closed-loop delivery of control commands.

[0026] S5. After the weak network is restored, the headquarters and the base consumer end will verify the status. The base consumer end will send the device execution level, idempotent ledger stage mark and device echo summary. The headquarters will compare the records of issued instructions and perform supplementary execution, supplementary feedback or isolation for control instructions that have not been executed, have been executed but not fed back and have exceeded the status. The equipment execution level is the latest execution progress confirmed by the base side according to the equipment dimension, which is used to compare with the records issued by the headquarters after the weak network is restored; The status verification includes a three-way verification of the headquarters' issued records, the base's persistent idempotent ledger, and the actual status of the equipment. When the three-way verification results are inconsistent, a compensation and disposal label is generated. The compensation and disposal label includes at least the following: not reached the base, arrived but not executed, executed but not fed back, and status out of bounds. In practice, when the consumer terminal on the base side detects that the network link between the headquarters and the base has recovered from an interrupted, severely packet-lossed, or bandwidth-limited state to a communicable state, the system automatically triggers the status verification process after the weak network recovery. This status verification is a closed-loop reconciliation jointly completed by the headquarters and the base consumer terminal, with the device execution status as the core, to confirm which control commands have been executed, which control commands have not been executed, which control commands have been executed but the feedback has not been sent to the headquarters, and which control commands have corresponding device statuses that have deviated from expectations. At the start of the status check, the base consumer first scans the local persistent idempotent ledger and generates device execution levels according to the device dimension. The device execution level indicates the latest position where each device has confirmed the completion of the execution loop, which can be determined by the last valid executed instruction of the device, the final state record of the idempotent ledger, and the device echo digest. At the same time, the base consumer also extracts the idempotent ledger stage marker and device echo digest corresponding to each control instruction. The idempotent ledger stage marker indicates that the control instruction is currently in the stage of intent being written, issued, device echo being generated, feedback being generated, or ledger being closed. The device echo digest characterizes whether the device has formed an actual state change in response to the control instruction. After the base consumer sends the device execution level, idempotent ledger stage marker, and device echo summary to the headquarters, the headquarters compares them with its own stored issued instruction records. The issued instruction records may include information such as the control instruction flow generated by the headquarters, issuance time, target device, target status, execution deadline, and whether the headquarters has received execution feedback. By comparing the issued instruction records with the execution level sent by the base, the headquarters identifies a list of control instructions that were issued by the headquarters but have not formed a confirmed closed loop during the weak network period. This list is then returned to the base, where the base consumer further queries the local persistent idempotent ledger and, if necessary, calls the device bus interface or the acquisition agent to read the actual status of the device, completing the three-way verification of the headquarters' issued records, the base's persistent idempotent ledger, and the actual status of the device. During the tripartite verification process, if a control instruction exists in the records issued by headquarters, but there is no corresponding intention record in the persistent idempotent ledger at the base, and the actual status of the device does not reflect the execution result of the instruction, it indicates that the control instruction may not have reached the base or has not yet been processed by the consumer. In this case, if the control instruction has not exceeded the execution deadline, it can be re-entered into the logical sequence channel for supplementary execution; if the execution deadline has been exceeded, it will be transferred to isolation or dead letter processing to prevent expired instructions from acting on the device at an inappropriate time. If a control command exists in the headquarters' issued records, and the intention column or issued action record already exists in the base's persistent idempotent ledger, but the device echo column is empty, and the actual device state has not reached the target state, it indicates that the control command has been received but not executed or has been issued but has not resulted in a valid change in device state. For such commands, the base consumer can determine whether supplementary execution is allowed based on the current device state, execution deadline conditions, and device-level phase gate number. If allowed, the command is pushed back into the execution process in sequence. If not allowed, an isolation and disposal label is generated, awaiting subsequent manual review or entering anomaly handling. If the device echo column in the persistent idempotent ledger at the base has recorded the device echo summary, or the actual status of the device has indicated that the target status change corresponding to the control command has occurred, but the headquarters has not received the corresponding execution feedback, it means that the control command has been executed but no feedback has been received. In this case, the base consumer will no longer reissue the control command, but will generate compensation feedback based on the device echo summary and deliver the compensation feedback to the execution feedback channel so that the headquarters can complete the closed loop status of the control command. If there is an inconsistency among the headquarters-issued records, the base's persistent idempotent ledger, and the actual status of the equipment that cannot be directly categorized into the aforementioned types, such as the actual status of the equipment having exceeded the target status, the equipment being manually intervened, the preceding instructions not being completed but the subsequent status having changed, or the equipment's returned status conflicting with the idempotent ledger record, then a status out-of-bounds compensation and handling label will be generated. Control instructions marked as status out of bounds will not be directly re-executed, nor will they be simply re-feeded. Instead, they will enter the isolation and handling process. Isolation and handling may include suspending subsequent control instructions for the equipment, re-collecting equipment operating conditions, triggering manual review, transferring to the dead letter queue, or executing a safety rollback strategy. Compensation and handling labels are used to categorize inconsistencies found during tripartite verification. These include at least four categories: not reached the base, arrived but not executed, executed but not responded to, and out of bounds. Through these labels, headquarters and base consumers can take different recovery actions instead of uniformly retrying all unconfirmed instructions. Specifically, control instructions that have not reached the base can be reissued or re-queued; control instructions that have arrived but not executed can be executed after meeting the equipment status ticket and phase gate requirements; control instructions that have been executed but not responded to can be reissued based on the equipment echo summary; and control instructions that have out of bounds are isolated to prevent the erroneous state from spreading to subsequent control chains. Through the above implementation methods, after the weak network is restored, the status verification between headquarters, base, and equipment can accurately identify the true state of the command during the weak network period, avoiding reliance solely on whether feedback from headquarters has been received to determine whether the command has been executed. By jointly uploading equipment execution level, idempotency ledger stage markers, and equipment echo summaries, headquarters can quickly determine which commands need to be re-executed, which commands only need to be fed back, and which commands must be isolated. Compensation and handling labels correspond different recovery paths to different abnormal states, avoiding the re-issuance of non-idempotent commands that have been executed but not fed back, reducing the risk of repeated execution of industrial control operations such as parameter tuning, upgrades, and start-ups / shutdowns. This process can reunify the headquarters' issuance records, base ledger records, and actual equipment status after the weak network is restored, forming a complete closed loop from control command issuance, execution, feedback to abnormal recovery, improving the reliability, security, and maintainability of control command delivery and execution confirmation in distributed industrial scenarios.

[0027] A closed-loop system for weak network sequence delivery of industrial control commands, applicable to any of the following methods for weak network sequence delivery of industrial control commands, includes a status ticket generation module, a phase sequence control module, a marker migration module, an idempotent ledger execution module, and a weak network echo verification module. The system generates equipment status tickets based on the cached effective operating conditions of the equipment at the base station, the execution result of the previous effective command, and the target status summary. It maintains equipment-level phase gates and prevents control commands with discontinuous status tickets or those performing phase rollback from entering the execution segment. It generates migration markers during logical sequence channel migration and controls the command continuation between the original and new logical sequence channels. It records the closed-loop execution status of control commands through the intent bar, issued action record, equipment echo bar, and feedback bar. After the weak network is restored, it performs a three-way verification of the headquarters' issued record, the base idempotent ledger, and the actual equipment status, and generates corresponding compensation and handling tags.

[0028] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A closed-loop method for weak network order-preserving delivery of industrial control commands, characterized in that, include: S1. The industrial control command to be issued is encapsulated into a control command shell carrying a device status ticket. The device status ticket is formed by the device's valid operating condition cached on the base side, the execution result of the previous valid command, and the target status summary. S2. According to the device affiliation, the control command shell is imported into the corresponding logical sequence channel, and the device-level phase gate number is maintained in the logical sequence channel to determine the succession relationship of the control command shell in the device execution chain, so that the control command shell with the execution phase rollback cannot enter the execution segment. S3. Before executing the control command, the consumer writes the command execution intention into the persistent idempotent ledger and compares the device real-time status summary with the device status ticket. If the comparison is consistent, the control command is sent to the device. If the comparison is inconsistent, the control command is transferred to the shadow verification queue and re-compared or transferred to isolation processing after the device status is reconfirmed. S4. After the control command is executed, the consumer writes the device echo digest into the persistent idempotent ledger and generates execution feedback based on the device echo digest. S5. After the weak network is restored, the headquarters and the base consumer end perform status verification. The base consumer end sends the device execution level, idempotent ledger stage mark and device echo summary. The headquarters compares the data with the issued instruction records and performs supplementary execution, supplementary feedback or isolation for control instructions that have not been executed, have been executed but not fed back, or have exceeded the status limit.

2. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 1, characterized in that, The process of generating the device status ticket includes: Read the device's operating status within the current control cycle, the execution result of the previous valid control command, and the target status of the current control command; The running status, execution result and target status are combined and verified to obtain a status ticket used to limit whether the current control command is allowed to be executed. If the previous valid control instruction has not produced a verifiable execution result, the current control instruction will not generate a passable status ticket.

3. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 1, characterized in that, The logical sequence channel is equipped with a device-level phase gate number, which advances with the valid execution result of the device. When the status ticket corresponding to the control command shell does not match the device-level phase gate number, the consumer suspends the execution of the control command shell and marks it as a phase pending confirmation state.

4. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 1, characterized in that, When a logical sequence path is migrated, a landmark relay migration method is used: Write migration markers for the logical sequence channels corresponding to the devices to be migrated; Control commands preceding the migration marker continue to be executed via the original logical sequence channel; Control instructions after the migration marker are temporarily stored in the shadow buffer segment of the new logical sequence channel. The shadow buffer segment refers to the buffer area in the new logical sequence channel used to temporarily store control instructions after the migration marker. It is not released before the original channel reaches the migration marker and forms the final state. After the original logical sequential channel executes to the migration boundary and forms the final state, the new logical sequential channel releases the control instructions in the shadow buffer segment.

5. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 1, characterized in that, The persistent idempotent ledger establishes a corresponding ledger for each control instruction. The ledger includes an intent column, a device echo column, and a feedback column. The intent column is used to record whether the control instruction has entered the preparation execution state. The device echo column is used to record whether the device has formed an actual state change corresponding to the control instruction. The feedback column is used to record whether the corresponding execution feedback has been formed and issued.

6. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 5, characterized in that, When the consumer restarts and finds an unclosed ledger in the persistent idempotent ledger, it identifies the recovery type of the unclosed ledger based on the combined status of the intent bar, the issued action record, the device echo bar, and the feedback bar. The recovery types include not reaching the device, issued but not echoed, executed but not responded to, and feedback issued but not closed. The consumer cancels, queries the status, reissues feedback, or closes the ledger according to the recovery type.

7. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 5, characterized in that, When the status of the feedback bar is uncertain but the device echo bar has recorded the actual status change, the consumer generates compensation feedback. The compensation feedback carries a device echo summary, enabling the headquarters to distinguish between genuine execution feedback and duplicate delivery feedback.

8. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 1, characterized in that, The status verification includes a three-way verification of the records issued by headquarters, the persistent idempotent ledger at the base, and the actual status of the equipment. When the three-way verification results are inconsistent, a compensation and handling label is generated. The compensation and handling label includes at least the following: not reached the base, arrived but not executed, executed but not fed back, and status out of bounds.

9. The closed-loop method for weak network order-preserving delivery of industrial control commands according to claim 1, characterized in that, When a takeover switch occurs at the consumer end, the exiting consumer end generates a channel handover water level sheet, which includes the last executed water level of the equipment, the gap waiting interval, and the idempotent ledger version. After the takeover consumer end verifies that the channel handover water level sheet is consistent with the local idempotent ledger, it continues to execute the control commands of the corresponding equipment.

10. A weak-network order-preserving delivery closed-loop system for industrial control commands, applied to the weak-network order-preserving delivery closed-loop method for industrial control commands as described in any one of claims 1 to 9, characterized in that, include: The status ticket generation module is used to generate a device status ticket based on the device's valid operating conditions cached on the base side, the execution result of the previous valid instruction, and the target status summary. The phase sequence control module is used to maintain the device-level phase gate number and prevent control commands that are discontinuous in status tickets or execute phase back-off from entering the execution segment; The marker migration module is used to generate migration markers during logical sequence channel migration and to control the instruction continuation between the original logical sequence channel and the new logical sequence channel. The idempotent ledger execution module is used to record the closed-loop execution status of control commands through the intent bar, issued action record, device echo bar, and feedback bar. The weak network echo verification module is used to perform a three-way verification of the records issued by headquarters, the idempotent ledger of the base, and the actual status of the equipment after the weak network is restored, and to generate corresponding compensation and disposal tags.

Images