Intelligent fusion terminal multi-stage offline self-recovery method and device

Abstract

The present application relates to the technical field of digital information transmission, and in particular to a multi-stage offline self-recovery method and device for intelligent fusion terminals. The method comprises the following steps: in a normal operating state, a terminal monitors the communication link state with a power distribution master station through a master station link detection module; after the communication link interruption is monitored and confirmed by an offline judgment module, self-recovery state information is read from a non-volatile memory; according to the self-recovery state information, a multi-stage self-recovery process is executed; in each stage of the multi-stage self-recovery process, a corresponding recovery action is executed, and after the recovery action is executed, a delay observation window is entered; in the delay observation window, the communication link state is periodically detected through an online preemption detection module. In this way, the recovery success rate of the communication module hanging is 97.3%; the average self-recovery recovery time is 247s in the first stage and 518s in the second stage in the recoverable scenario; and the self-recovery continuation accuracy after power failure is 100%.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, specifically to a multi-stage offline self-healing method and device for intelligent fusion terminals. Background Technology

[0002] Intelligent converged terminals are core edge devices in the distribution network Internet of Things (IoT), undertaking critical tasks such as electricity consumption information collection, transformer area status monitoring, and distributed energy management. These terminals typically maintain a long-term connection with the distribution master station via remote communication modules such as 4G / 5G / fiber optics. However, in actual operation, communication link interruptions (offline status) are common failures due to factors such as limited operator base station coverage, signal obstruction, or network congestion.

[0003] In existing technologies, when a terminal detects offline status, it typically employs a simple "timed restart" or "fixed-period reconnection" strategy. This crude approach has the following drawbacks:

[0004] Limited recovery methods: It is impossible to distinguish whether the problem is a terminal software deadlock, a communication module freeze, or a carrier network failure, resulting in ineffective restarts and wasted resources.

[0005] Power outage loss of progress: If a voltage fluctuation in the distribution area causes an unexpected power outage during the self-healing process, the terminal often has to start from scratch after powering on, getting stuck in a vicious cycle of "reboot-power outage-reboot", and unable to complete the long-term network recovery wait.

[0006] Lack of online preemption: During long waiting periods, if the network suddenly recovers, the terminal still needs to wait for the current sleep cycle to end before it can reconnect, resulting in delays in business reporting.

[0007] No fallback mechanism: In extremely harsh environments, the terminal may retry indefinitely, leading to rapid battery depletion or Flash wear.

[0008] Therefore, there is an urgent need for an intelligent self-healing solution with multi-stage progressive recovery, power outage interruption resume, real-time online preemption, and timeout fallback mechanisms. Summary of the Invention

[0009] In order to solve or at least partially solve the defects or deficiencies of the prior art, the present invention proposes a multi-stage offline self-healing method and device for intelligent fusion terminals.

[0010] In a first aspect of the present invention, a multi-stage offline self-healing method for an intelligent fusion terminal is provided, comprising:

[0011] Under normal operating conditions, the terminal monitors the communication link status with the power distribution master station through the master station link detection module;

[0012] Once a communication link interruption is detected and confirmed by the offline determination module, the self-healing status information is read from the non-volatile memory.

[0013] Based on the self-healing status information, a multi-stage self-healing process is executed. In each stage of the multi-stage self-healing process, the corresponding recovery action is executed, and after the recovery action is executed, a delay observation window is entered. Within the delay observation window, the communication link status is periodically detected by the online preemption detection module. If the communication link recovery is detected within the delay observation window, the self-healing status information is cleared and the system returns to normal operation. If the communication link recovery is not detected within the delay observation window, and the number of retries in the current stage has not reached the upper limit, the recovery action of the current stage is repeated. If the number of retries in the current stage has reached the upper limit, the system enters the next stage of the self-healing process. When the state transitions or the retry count changes, the current self-healing status information is persistently written to non-volatile memory.

[0014] As a preferred embodiment of the present invention, the multi-stage self-healing process includes a terminal restart stage, a communication module reset stage, and a long-cycle waiting stage; the execution of the multi-stage self-healing process specifically includes:

[0015] Terminal restart phase: Perform a full terminal restart and enter the first delay observation window after restarting; if the link is not restored and the number of restarts is less than the first threshold, increment the number of restarts and re-execute the full terminal restart; otherwise, enter the communication module reset phase.

[0016] Communication module reset phase: The independent power supply reset of the communication module is executed. After the reset, the second delay observation window is entered. If the link is not restored and the number of resets is less than the second threshold, the number of resets is incremented and the independent power supply reset of the communication module is executed again. Otherwise, the long-cycle waiting phase is entered.

[0017] Long-cycle waiting phase: Enters a long-cycle cyclical waiting period, with each round lasting for [duration missing]. If the link is not restored and the number of loops is less than the third threshold, the number of loops is incremented and the system enters the next round of waiting; otherwise, the self-healing is deemed to have failed and the system enters the low-power standby mode.

[0018] As a preferred embodiment of the present invention, the action of performing an independent power supply reset of the communication module specifically includes:

[0019] The dedicated power supply rail of the remote communication module is cut off by controlling the PMOS switching transistor through the GPIO port of the terminal main control chip.

[0020] Preset duration of power failure Afterwards, power supply to the dedicated power rail was restored.

[0021] As a preferred embodiment of the present invention, reading self-healing state information from non-volatile memory specifically includes:

[0022] When the terminal is powered on and initialized, it reads the self-healing state block from the non-volatile memory;

[0023] If the self-healing state block exists and passes the verification, the current stage identifier before the power outage, the number of executions, and the cumulative offline time are parsed out.

[0024] The state machine is restored to the state corresponding to the current stage identifier, and the self-healing process continues from the number of executions already completed.

[0025] As a preferred embodiment of the present invention, the current self-healing state information is persistently written to a non-volatile memory using a dual-copy plus CRC32 check mechanism:

[0026] The self-healing status information is written into the first copy area of ​​the non-volatile memory in the form of structured data blocks, and the CRC32 check value of the data block is calculated and written.

[0027] The self-healing status information is written into the second copy area of ​​the non-volatile memory in the form of structured data blocks, and the CRC32 check value of the data block is calculated and written.

[0028] The writing to the first replica area and the writing to the second replica area are performed alternately.

[0029] As a preferred embodiment of the present invention, the online preemption detection module periodically detects the communication link status, specifically including:

[0030] In any stage of the multi-stage self-healing process, with a fixed cycle Send a lightweight link probe message to the master station. The message may include an ICMP PING packet or a simplified heartbeat request.

[0031] If continuous If a valid response is received, it is determined that the online preemption was successful. The current self-healing process is immediately terminated, the self-healing status information in the non-volatile memory is cleared, and the state machine is controlled to jump to the idle state.

[0032] As a preferred embodiment of the present invention, the communication link interruption and confirmation by the offline determination module specifically includes:

[0033] Receive link anomaly events sent by the main station link detection module; the events are continuous. No response to the next heartbeat or TCP connection loss for more than [time period missing] trigger;

[0034] Start the offline confirmation delay timer;

[0035] Offline confirmation delay During this period, the link status is continuously monitored. If the link recovers, it is determined to be a transient jitter and normal operation is maintained; if offline confirmation delay occurs... If the link is still interrupted after the process ends, a multi-stage self-healing process will be formally triggered.

[0036] In a second aspect of the present invention, a multi-stage offline self-healing device for an intelligent fusion terminal is provided, comprising:

[0037] The communication link status monitoring module is configured to monitor the communication link status with the power distribution master station through the master station link detection module when the terminal is in normal operation.

[0038] The self-healing status information reading module is configured to read self-healing status information from non-volatile memory after detecting a communication link interruption and confirming it through the offline judgment module.

[0039] The multi-stage self-healing process execution module is configured to execute a multi-stage self-healing process based on self-healing status information. In each stage of the multi-stage self-healing process, a corresponding recovery action is executed, and a delay observation window is entered after the recovery action is executed. Within the delay observation window, the communication link status is periodically detected by the online preemption detection module. If communication link recovery is detected within the delay observation window, the self-healing status information is cleared and the normal operation status is returned. If communication link recovery is not detected within the delay observation window, and the number of retries in the current stage has not reached the upper limit, the recovery action of the current stage is repeated. If the number of retries in the current stage has reached the upper limit, the self-healing process of the next stage is entered. When the state transition or the retry count changes, the current self-healing status information is persistently written to non-volatile memory.

[0040] In a third aspect of the present invention, a computer program product is provided, including a computer program that, when executed by a processor, implements the method provided according to the first aspect.

[0041] In a fourth aspect of the present invention, an electronic device is provided, including one or more processors and a memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the method provided in the first aspect.

[0042] In summary, the present invention has the following beneficial effects:

[0043] A multi-stage, progressive self-healing strategy minimizes the scope of business interruption: recovery actions are divided into three levels based on "cost," from low to high: terminal reboot (affecting all services), independent power reset of communication modules (affecting only remote communication), and long-cycle circular waiting (no active interruption). This sequential approach avoids the crude "full reboot at the first sign of offline" strategy in existing technologies, allowing most recoverable offline scenarios to be resolved in the first two low-cost stages, thus protecting local data collection and edge computing services.

[0044] The self-healing progress is persisted to non-volatile memory to achieve power-off continuity: key information such as the current state of the state machine, retry counts for each stage, and timestamps are written to the NVM (SPI Flash or EEPROM) using dual copies and CRC32 checksum. If the terminal unexpectedly loses power during the self-healing process, it reads from the NVM and restores the self-healing breakpoint during power-on initialization, avoiding invalid repeated restarts caused by "self-healing rollback".

[0045] Full-stage online preemption detection promptly terminates unnecessary recovery actions: Lightweight link probing is performed at a high frequency of 10-second cycles within each waiting window of the self-healing process. Once the link is restored, it immediately returns to normal mode from any preemption state, avoiding the continuation of subsequent invalid actions despite the link being restored due to the communication module remaining in the waiting window after a reset.

[0046] Offline root cause classification and targeted recovery: By distinguishing between the results of "recovery after reboot" and "no recovery after reboot", as well as the results of "recovery after module reset" and "no recovery after module reset", the possible root causes of offline (main control system problem, communication module problem, or carrier network problem) can be indirectly inferred, providing valuable diagnostic information for subsequent operation and maintenance.

[0047] Parameters can be configured online and strategies can be adaptively optimized: All key parameters (retry limit for each stage, waiting time, heartbeat cycle, etc.) can be remotely configured by the main station via the 698.45 protocol; the terminal locally counts the recovery success rate of each stage, and when the success rate of a certain stage is consistently low, the strategy parameters can be adaptively adjusted (such as increasing the number of retries in that stage) to achieve continuous optimization of the self-healing strategy.

[0048] Further or more detailed beneficial effects will be described in conjunction with specific embodiments in the detailed implementation. Attached Figure Description

[0049] Figure 1 A flowchart of a multi-stage offline self-healing method for an intelligent fusion terminal according to an embodiment of the present invention is shown;

[0050] Figure 2 A block diagram of a multi-stage offline self-healing device for an intelligent fusion terminal according to an embodiment of the present invention is shown.

[0051] Figure 3 A block diagram of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0052] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0053] In the description of embodiments of the present invention, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0054] This invention proposes a multi-stage offline self-healing method for intelligent fusion terminals, such as... Figure 1 As shown, the method includes:

[0055] Under normal operating conditions, the terminal monitors the communication link status with the power distribution master station through the master station link detection module;

[0056] Once a communication link interruption is detected and confirmed by the offline determination module, the self-healing status information is read from the non-volatile memory.

[0057] Based on the self-healing status information, a multi-stage self-healing process is executed. In each stage of the multi-stage self-healing process, the corresponding recovery action is executed, and after the recovery action is executed, a delay observation window is entered. Within the delay observation window, the communication link status is periodically detected by the online preemption detection module. If the communication link recovery is detected within the delay observation window, the self-healing status information is cleared and the system returns to normal operation. If the communication link recovery is not detected within the delay observation window, and the number of retries in the current stage has not reached the upper limit, the recovery action of the current stage is repeated. If the number of retries in the current stage has reached the upper limit, the system enters the next stage of the self-healing process. When the state transitions or the retry count changes, the current self-healing status information is persistently written to non-volatile memory.

[0058] In this embodiment, the multi-stage self-healing process includes a terminal restart stage, a communication module reset stage, and a long-cycle waiting stage; the execution of the multi-stage self-healing process specifically includes:

[0059] Terminal restart phase: Perform a full terminal restart and enter the first delay observation window after restarting; if the link is not restored and the number of restarts is less than the first threshold, increment the number of restarts and re-execute the full terminal restart; otherwise, enter the communication module reset phase.

[0060] Communication module reset phase: The independent power supply reset of the communication module is executed. After the reset, the second delay observation window is entered. If the link is not restored and the number of resets is less than the second threshold, the number of resets is incremented and the independent power supply reset of the communication module is executed again. Otherwise, the long-cycle waiting phase is entered.

[0061] Long-cycle waiting phase: Enters a long-cycle cyclical waiting period, with each round lasting for [duration missing]. If the link is not restored and the number of loops is less than the third threshold, the number of loops is incremented and the system enters the next round of waiting; otherwise, the self-healing is deemed to have failed and the system enters the low-power standby mode.

[0062] This embodiment assumes the system is deployed on a smart converged terminal (such as an ARM Cortex-A7 architecture embedded Linux device), and includes a link detection layer, a decision and control layer, a recovery execution layer, and a persistent storage layer. The specific execution steps of the system are as follows:

[0063] S1. The terminal is operating normally in IDLE state, and the main station link detection module is... It periodically sends heartbeats and monitors the response.

[0064] S2. When continuous No response to the next heartbeat or TCP connection loss for more than [time period missing] This triggers the offline judgment process.

[0065] S3. Offline determination module startup confirmation delay During this period, the link status is continuously monitored.

[0066] S4. If in If the internal link recovers, it is determined to be a transient jitter, and the terminal remains in the IDLE (idle) state.

[0067] S5. If offline is confirmed, read the self-healing state block from the non-volatile parameter database. If there are incomplete self-healing records (e.g., the terminal lost power during the CYCLE_WAIT phase of the previous self-healing round), restore the current state of the state machine and the retry count to the "breakpoint" before the power outage.

[0068] S6. If there is no history record or the history record has been completed, initialize the self-healing state to WAIT_AFTER_REBOOT (wait after terminal restart) and write the state block to NVM (non-volatile memory).

[0069] S7. Perform a full terminal reboot. After rebooting, the bootloader or initialization script reads the self-healing state block in NVM, identifies the WAIT_AFTER_REBOOT state, and enters a waiting observation window. (Typical value 120s).

[0070] S8. In During the waiting period, the online preemptive detection module will... Perform link probing periodically. If link recovery (online preemption) is detected, proceed to step S1.

[0071] S9. If the terminal remains offline after the waiting period, check the number of terminal restarts. Has the upper limit been reached? (Typical value 2). If the upper limit is not reached... Increment the value and re-execute the terminal restart; if the limit is reached, switch to the WAIT_AFTER_MODULE (wait after communication module reset) state and persist it.

[0072] S10. Perform a power reset for the communication module: Disconnect the VCC power supply to the remote communication module via a PMOS switch controlled by GPIO, maintaining power-down operation. (Typical value 5s), then power is restored, and the observation window is entered after the module initialization is complete. (Typical value 90s).

[0073] S11. In Online preemption detection will continue during the waiting period. If online access is restored, proceed to step S1.

[0074] S12. If still offline, check the number of times the communication module has been reset. Has the upper limit been reached? (Typical value 3). If the upper limit is not reached, the value is incremented and the module is reset repeatedly; if the upper limit is reached, the value is switched to CYCLE_WAIT (long-cycle wait state) and persisted.

[0075] S13. Entering a long-cycle circular waiting phase. Each round of waiting... (Typical value 600s), online preemption detection continues during the waiting period.

[0076] S14. If online recovery occurs, the preemption terminates; if the user is still offline after this round of waiting ends, check the loop count. Has the upper limit been reached? (Typical value 144, corresponding to 24 hours). If the upper limit is not reached, the value will increase and enter the next round of waiting; if the upper limit is reached, the status will switch to DONE (self-healing completed), the self-healing will be judged as failed, an alarm event will be written to the main station cache queue (to be reported after the link is restored), and the terminal will enter low power standby mode.

[0077] S15. After successful online preemption, immediately clear the self-healing state block in NVM, reset all retry counters to zero, return the state machine to IDLE, and the terminal resumes normal service operation.

[0078] Specifically, let's take the scenario of intermittent hangs of the communication module as an example:

[0079] During normal operation of a smart converged terminal in a certain distribution area, the 4G communication module entered a dead state due to an internal protocol stack anomaly (the module's AT commands did not respond, but the internal watchdog timer was not triggered). The main station link detection module experienced three consecutive heartbeat timeouts within 180 seconds, and after 30 seconds of offline confirmation, it triggered a self-healing process.

[0080] Round 1: Full terminal reboot ( =1), wait for a 120s observation window. After restarting, the 4G module also re-powers on and initializes, but because the module hang is a soft state abnormality, the entire board power-down has cleared it; the module re-registers with the network and restores its connection with the main station within 90s. Online preemption detection detects link recovery at 80s, triggers online preemption after two consecutive confirmations, clears the self-healing state, and the terminal returns to normal operation. In this scenario, the first level of recovery is successful, taking approximately 260s from offline confirmation to recovery (180s heartbeat timeout + 30s confirmation + approximately 80s restart and recovery), which is far superior to solutions that rely solely on long-cycle waiting.

[0081] Let's take another example: a scenario where a carrier base station failure causes an area to go offline.

[0082] A large number of terminals in a certain area went offline due to a fault in the operator's base station equipment. The self-healing process failed to recover after exhausting all retries in the first two execution phases: terminals restarted twice (both failed due to the base station not recovering), and communication modules were reset three times (all failed due to the base station not recovering). The state machine was upgraded to the CYCLE_WAIT phase, waiting 600 seconds (10 minutes) per round for continuous online monitoring. During the 38th round of waiting (approximately 6.3 hours), the operator repaired the base station, and online preemption detection detected link recovery in the next detection cycle. After clearing the state, the system returned to normal.

[0083] If a power outage occurs during this period (e.g., a power outage for transformer maintenance), the self-healing state block is read from the NVM after power is restored, and the system returns to the state of round 38 in the CYCLE_WAIT phase, continuing to wait. This avoids the problem in existing solutions where the self-healing count resets to zero due to a power outage, resulting in "never reaching the end."

[0084] Furthermore, in this embodiment, the action of performing the independent power reset of the communication module specifically includes:

[0085] The dedicated power supply rail of the remote communication module is cut off by controlling the PMOS switching transistor through the GPIO port of the terminal main control chip.

[0086] Preset duration of power failure Afterwards, power supply to the dedicated power rail was restored.

[0087] Suppose a roadside smart converged terminal experiences a software bug that causes its 4G communication module to freeze, preventing it from communicating with the main station, although the terminal itself continues to collect meter data normally. The terminal's self-healing program determines that a "communication module independent power reset" is needed. At this time, the level of a certain GPIO pin on the main control chip changes. This change controls a PMOS transistor to turn off, cutting off the power supply to the 4G module, and the module shuts down. The system waits for 5 seconds. After 5 seconds, the GPIO pin level recovers, the PMOS transistor turns back on, and the 4G module powers on again. The 4G module has completed a "hard reboot," clearing the frozen software state, successfully reconnecting to the network, and the terminal returns to online status. Throughout this entire process, the collection of meter data is never interrupted.

[0088] In this embodiment, reading self-healing state information from non-volatile memory specifically includes:

[0089] When the terminal is powered on and initialized, it reads the self-healing state block from the non-volatile memory;

[0090] If the self-healing state block exists and passes the verification, the current stage identifier before the power outage, the number of executions, and the cumulative offline time are parsed out.

[0091] The state machine is restored to the state corresponding to the current stage identifier, and the self-healing process continues from the number of executions already completed.

[0092] Suppose a smart converged terminal goes offline due to a base station failure and is undergoing a self-healing process called "Phase Two: Communication Module Reset". The terminal has already attempted to reset twice in this phase, but the network has not yet recovered. Just as it is preparing to perform a third reset, the terminal suddenly loses power due to unstable external power supply. A few minutes later, power is restored, and the terminal is powered on again. After restarting, the terminal immediately reads the self-healing state block in the NVM and passes the verification. The terminal parses the information: Current Phase = Phase Two, Number of Executions = 2, Cumulative Offline Time = 15 minutes. The terminal directly switches its state machine to "Phase Two" and sets its internal counter to 2. The terminal will not revert to Phase One to perform a meaningless "system reboot", but will directly continue trying from the third "communication module reset". This saves valuable recovery time and avoids unnecessary system service interruption.

[0093] In this embodiment, the current self-healing state information is persistently written to the non-volatile memory using a dual-copy plus CRC32 check mechanism:

[0094] The self-healing status information is written into the first copy area of ​​the non-volatile memory in the form of structured data blocks, and the CRC32 check value of the data block is calculated and written.

[0095] The self-healing status information is written into the second copy area of ​​the non-volatile memory in the form of structured data blocks, and the CRC32 check value of the data block is calculated and written.

[0096] The writing to the first replica area and the writing to the second replica area are performed alternately.

[0097] Suppose that the terminal's self-healing state machine has just progressed from "Phase 1 (Terminal Reboot)" to "Phase 2 (Communication Module Reset)", and at this point, the records in the NVM need to be updated.

[0098] Step 1 (Packaging Data):

[0099] The terminal generates a status data block: [Phase = Second Phase, Number = 1, Offline Duration = 3 minutes].

[0100] Calculate the CRC32 checksum of this data block, assuming it is 0xA1B2C3D4.

[0101] Step 2 (Write to the first copy):

[0102] The terminal writes [Phase = Second Phase, Number of Times = 1, Offline Duration = 3 Minutes, Checksum = 0xA1B2C3D4] to the first replica region of NVM.

[0103] (Assuming the terminal suddenly loses power at this point) – No problem, because the first copy may have been corrupted, but when the terminal powers on again and reads the second copy area, it still retains the intact record from the previous (first phase). The terminal can safely roll back to the breakpoint in the first phase and continue execution.

[0104] Step 3 (Write to the second copy):

[0105] Assuming there was no power outage, the terminal successfully wrote to the first replica. Next, it wrote the same data to the second replica area of ​​the NVM.

[0106] At this point, both identical security records have been updated.

[0107] Step 4 (Next Alternate):

[0108] When the terminal performs the next state update (for example, the second phase retried once, and the count became 2), in order to avoid repeatedly erasing and writing the same area, the terminal will reverse the operation: first write to the second copy area, and after confirming that there are no errors, write to the first copy area.

[0109] Even if a power outage occurs during the writing process, at most only the copy currently being written will be damaged, while the other copy remains intact, ensuring the state machine's "breakpoint resume" capability. By alternating writes, the number of erase / write cycles of NVM is distributed, greatly extending the lifespan of the storage chip.

[0110] In this embodiment, the online preemption detection module periodically probes the communication link status, specifically including:

[0111] In any stage of the multi-stage self-healing process, with a fixed cycle Send a lightweight link probe message to the master station. The message may include an ICMP PING packet or a simplified heartbeat request.

[0112] If continuous If a valid response is received, it is determined that the online preemption was successful. The current self-healing process is immediately terminated, the self-healing status information in the non-volatile memory is cleared, and the state machine is controlled to jump to the idle state.

[0113] Suppose a smart converged terminal goes offline due to a temporary failure of the operator's base station and is currently in "Phase Two: Communication Module Reset", waiting for 90 seconds to recover.

[0114] Step 1 (Background Detection):

[0115] During the 90-second wait, the preemption detection module sends a PING packet to the main station every 10 seconds.

[0116] 10 seconds: The main site is not responding.

[0117] 20 seconds: The main site is not responding.

[0118] 30 seconds: The main site is not responding.

[0119] Step 2 (Network recovery and preemption successful):

[0120] The base station malfunction was resolved at 35 seconds.

[0121] 40 seconds: The terminal's PING packet received a reply from the master station (successfully once in a row).

[0122] At 50 seconds: The terminal sent another PING packet and received a reply from the main station (successfully twice in a row).

[0123] System determination: Online preemption successful.

[0124] Step 3 (Immediate Stop and Cleanup):

[0125] At this point, there are 40 seconds left in the 90-second waiting period. The terminal immediately abandons the remaining waiting time, clears the "Phase Two" record in the NVM, and the state machine instantly switches back to the "Idle State".

[0126] Final result:

[0127] The terminal quickly returned to online status after being offline for 50 seconds, saving a full 40 seconds of business interruption time compared to waiting 90 seconds to recover.

[0128] In this embodiment, the communication link interruption and confirmation by the offline determination module specifically includes:

[0129] Receive link anomaly events sent by the main station link detection module; the events are continuous. No response to the next heartbeat or TCP connection loss for more than [time period missing] trigger;

[0130] Start the offline confirmation delay timer;

[0131] Offline confirmation delay During this period, the link status is continuously monitored. If the link recovers, it is determined to be a transient jitter and normal operation is maintained; if offline confirmation delay occurs... If the link is still interrupted after the process ends, a multi-stage self-healing process will be formally triggered.

[0132] Suppose a smart converged terminal deployed outdoors is currently reporting data normally to the main station.

[0133] Step 1 (Triggering an alert):

[0134] The terminal sent heartbeat packets three times consecutively, but the master station did not respond. The link detection module immediately reported to the offline judgment module: "The master station link detection module has sent a link anomaly event."

[0135] Step 2 (Startup Delay):

[0136] The offline detection module received the report and thought, "Don't rush to restart, it might be a problem with the base station signal." So it started a 30-second offline confirmation delay timer.

[0137] Step 3 (Diversion Determination):

[0138] Scenario 1 (False Alarm): At the 15-second mark, the network signal was restored, and the terminal received a response from the master station. The system determined it to be "transient jitter," canceled the timer, and the terminal continued to work normally, avoiding an unnecessary restart.

[0139] Scenario 2 (Fault Confirmation): After 30 seconds, the terminal still does not receive any response. The system determines that it is "officially offline" and immediately triggers a multi-stage self-healing process, preparing to start "Stage 1: Terminal Reboot".

[0140] This invention proposes a multi-stage offline self-healing device for intelligent fusion terminals, such as... Figure 2 As shown, the device includes:

[0141] The communication link status monitoring module is configured to monitor the communication link status with the power distribution master station through the master station link detection module when the terminal is in normal operation.

[0142] The self-healing status information reading module is configured to read self-healing status information from non-volatile memory after detecting a communication link interruption and confirming it through the offline judgment module.

[0143] The multi-stage self-healing process execution module is configured to execute a multi-stage self-healing process based on the self-healing status information. In each stage of the multi-stage self-healing process, a corresponding recovery action is executed, and a delay observation window is entered after the recovery action is executed. Within the delay observation window, the communication link status is periodically detected by the online preemption detection module. If communication link recovery is detected within the delay observation window, the self-healing status information is cleared and the normal operation status is returned. If communication link recovery is not detected within the delay observation window, and the number of retries in the current stage has not reached the upper limit, the recovery action of the current stage is repeated. If the number of retries in the current stage has reached the upper limit, the self-healing process of the next stage is entered. When the state transition or the retry count changes, the current self-healing status information is persistently written to the non-volatile memory.

[0144] Figure 3 A block diagram of an electronic device 300 according to some embodiments of the present invention is shown. The device 300 includes a processor 301, which performs various appropriate actions and processes based on computer program instructions loaded into random access memory (RAM) 303 according to computer program instructions stored in read-only memory (ROM) 302. Various programs and data required for the operation of the device 300 may also be stored in RAM 303. The processor 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0145] The various processes and procedures described above, such as method 100, can be executed by processor 301. For example, in some embodiments, method 100 may be implemented as a software program tangibly contained in a machine-readable medium. In some embodiments, part or all of the software program may be loaded and / or installed on device 300 via ROM 302. When the software program is loaded into RAM 303 and executed by processor 301, one or more actions of method 100 described above may be performed.

[0146] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0147] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0148] This invention can be a method, apparatus, system, and / or program product. The program product may include a machine-readable storage medium on which machine-readable program instructions for performing various aspects of the invention are loaded. The machine-readable program instructions described herein can be downloaded from the machine-readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the machine-readable program instructions from the network and forwards them for storage in the machine-readable storage medium of the respective computing / processing device.

[0149] Machine program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The machine-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the machine-readable program instructions. This electronic circuitry can execute the machine-readable program instructions to implement various aspects of the invention.

[0150] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Furthermore, although the operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the invention. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0151] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A multi-stage offline self-healing method for an intelligent fusion terminal, characterized in that, include: Under normal operating conditions, the terminal monitors the communication link status with the power distribution master station through the master station link detection module; Once a communication link interruption is detected and confirmed by the offline determination module, the self-healing status information is read from the non-volatile memory. Based on the self-healing status information, a multi-stage self-healing process is executed; In each stage of the multi-stage self-healing process, a corresponding recovery action is executed, and a delay observation window is entered after the recovery action is executed; within the delay observation window, the communication link status is periodically detected by the online preemption detection module; If communication link recovery is detected within the delayed observation window, the self-healing status information is cleared and the system returns to normal operation. If no communication link recovery is detected within the delay observation window, and the number of retries in the current stage has not reached the upper limit, the recovery action of the current stage is repeated; if the number of retries in the current stage has reached the upper limit, the self-healing process of the next stage is entered. Furthermore, when a state transition or retry count changes, the current self-healing state information is persistently written into the non-volatile memory.

2. The method according to claim 1, characterized in that, The multi-stage self-healing process includes a terminal restart stage, a communication module reset stage, and a long-cycle waiting stage; the execution of the multi-stage self-healing process specifically includes: Terminal restart phase: Perform a full terminal restart and enter the first delay observation window after restarting; if the link is not restored and the number of restarts is less than the first threshold, increment the number of restarts and re-execute the full terminal restart; otherwise, enter the communication module reset phase. Communication module reset phase: The independent power supply reset of the communication module is executed. After the reset, the second delay observation window is entered. If the link is not restored and the number of resets is less than the second threshold, the number of resets is incremented and the independent power supply reset of the communication module is executed again. Otherwise, the long-cycle waiting phase is entered. Long-cycle waiting phase: Enters a long-cycle cyclical waiting period, with each round lasting for [duration missing]. If the link is not restored and the number of loops is less than the third threshold, the number of loops is incremented and the system enters the next round of waiting; otherwise, the self-healing is deemed to have failed and the system enters the low-power standby mode.

3. The method according to claim 2, characterized in that, The action of performing an independent power reset of the communication module specifically includes: The dedicated power supply rail of the remote communication module is cut off by controlling the PMOS switching transistor through the GPIO port of the terminal main control chip. Preset duration of power failure Then, power is restored to the dedicated power rail.

4. The method according to claim 1, characterized in that, The process of reading self-healing state information from non-volatile memory specifically includes: When the terminal is powered on and initialized, it reads the self-healing state block from the non-volatile memory; If the self-healing state block exists and passes the verification, the current stage identifier before the power outage, the number of executions, and the cumulative offline time are parsed out. The state machine is restored to the state corresponding to the current stage identifier, and the self-healing process continues from the number of executions already performed.

5. The method according to claim 4, characterized in that, The current self-healing state information is persistently written to the non-volatile memory using a dual-copy plus CRC32 check mechanism: The self-healing status information is written into the first copy area of ​​the non-volatile memory in the form of structured data blocks, and the CRC32 check value of the data block is calculated and written. The self-healing status information is written into the second copy area of ​​the non-volatile memory in the form of structured data blocks, and the CRC32 check value of the data block is calculated and written. The writing to the first replica area and the writing to the second replica area are performed alternately.

6. The method according to claim 1, characterized in that, The online preemption detection module periodically probes the communication link status, specifically including: In any stage of the multi-stage self-healing process, at a fixed period Send a lightweight link probe message to the master station, the message including an ICMP PING packet or a simplified heartbeat request; If continuous If a valid response is received, it is determined that the online preemption was successful. The current self-healing process is immediately terminated, the self-healing status information in the non-volatile memory is cleared, and the state machine is controlled to jump to the idle state.

7. The method according to claim 1, characterized in that, The communication link interruption, confirmed by the offline determination module, specifically includes: Receive link anomaly events sent by the main station link detection module, the events being continuous No response to the next heartbeat or TCP connection loss for more than [time period missing] trigger; Start the offline confirmation delay timer; Offline confirmation delay During this period, the link status is continuously monitored. If the link recovers, it is determined to be a transient jitter and normal operation is maintained; if offline confirmation delay occurs... If the link is still interrupted after the process ends, a multi-stage self-healing process will be formally triggered.

8. A multi-stage offline self-healing device for an intelligent fusion terminal, characterized in that, include: The communication link status monitoring module is configured to monitor the communication link status with the power distribution master station through the master station link detection module when the terminal is in normal operation. The self-healing status information reading module is configured to read self-healing status information from non-volatile memory after detecting a communication link interruption and confirming it through the offline judgment module. The multi-stage self-healing process execution module is configured to execute a multi-stage self-healing process based on the self-healing status information; in each stage of the multi-stage self-healing process, a corresponding recovery action is executed, and a delay observation window is entered after the recovery action is executed; within the delay observation window, the communication link status is periodically detected by the online preemption detection module. If communication link recovery is detected within the delayed observation window, the self-healing status information is cleared and the system returns to normal operation. If no communication link recovery is detected within the delay observation window, and the number of retries in the current stage has not reached the upper limit, the recovery action of the current stage is repeated; if the number of retries in the current stage has reached the upper limit, the self-healing process of the next stage is entered. Furthermore, when a state transition or retry count changes, the current self-healing state information is persistently written into the non-volatile memory.

9. A computer program product, characterized in that, Includes a computer program, which, when executed by a processor, implements the steps of the method according to any one of claims 1-7.

10. An electronic device, characterized in that, It includes one or more processors and memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1-7.

Images