Method for handling abnormal power interruption of management system, and device and medium

Abstract

Disclosed in the present application are a method for handling an abnormal power interruption of a management system, and a device and a medium, which are applied to the technical field of power interruption protection, and are used for solving the problem of a poor protection capability of a management system in the event of an abnormal power interruption. The method specifically comprises: a processor detecting an operating state of a main power source according to a preset period, wherein the preset period is less than a backup duration of an auxiliary power source module (S210); and when it is detected that the state of the main power source is disconnected, executing a power interruption protection strategy for a BMS or an EMS within the backup duration of the auxiliary power source module (S220). In this way, a quick response is made when a main power source is disconnected, and a power interruption protection strategy is immediately started during power supply from an auxiliary power source module, such that a management system saves data and shuts down processes in an orderly manner under an abnormal disconnection state of the main power source, thereby reducing the risks of data loss and file system damage, providing data integrity protection at a hardware level, offering a strong power interruption protection capability for the management system, and effectively solving the problem of a poor protection capability in the prior art.

Description

Abnormal power failure handling methods, equipment and media for management systems

[0001] This application claims priority to Chinese Patent Application No. 202411818015.9, filed on December 10, 2024, entitled “Abnormal Power Outage Handling Method, Device and Medium for Management System”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of power outage protection technology, and more specifically, to a method, device, and medium for handling abnormal power outages in a management system. Background Technology

[0003] In BMS (Battery Management System) and EMS (Energy Management System) systems, the edge gateway acts as a bridge connecting the front-end and back-end servers, undertaking crucial tasks such as data acquisition, processing, transmission, and storage. However, in practical applications, edge gateways may experience abnormal power outages due to power failures, equipment malfunctions, or improper user operation. This can not only lead to the loss of currently processed data but also potentially affect the overall stability and reliability of the system.

[0004] Currently, existing methods for protecting against abnormal power outages have the following drawbacks: While local backups ensure data is reloaded after system recovery, frequent writes accelerate storage media wear, and the integrity of the latest data is difficult to guarantee during sudden power outages; cloud backups, while offering high fault tolerance and data recovery capabilities, are susceptible to sudden power outages and network instability, leading to incomplete or invalid backup data. Furthermore, repairing a damaged management system relies on on-site engineer maintenance, which is not only costly and time-consuming but may also negatively impact the overall system's security, stability, and user experience due to the potential for fault propagation. Therefore, providing an effective protection solution for abnormal power outages in management systems has become a pressing issue. Summary of the Invention

[0005] The purpose of this application is to provide a method, device and medium for handling abnormal power outages in a management system, so as to solve the problem that the protection capability of the management system under abnormal power outages in the prior art is poor.

[0006] In a first aspect, a method for handling abnormal power outages in a management system is provided. The management system is located in a BMS or EMS, and includes a first circuit and a second circuit. The first circuit includes a processor and an auxiliary power module. The management system is powered by a main power supply, and the auxiliary power module is used to supply power to the first circuit when the main power supply is disconnected. The method includes:

[0007] The processor detects the working status of the main power supply according to a preset cycle, which is shorter than the battery life of the auxiliary power module.

[0008] When the main power supply is detected to be disconnected, a power-off protection strategy for the BMS or EMS is executed within the auxiliary power module's runtime.

[0009] Optionally, the abnormal power failure handling method for the management system proposed in this application further includes:

[0010] After the main power supply is powered on, if it is detected in the historical log that the last main power supply was abnormally disconnected and triggered the power failure protection strategy for the BMS or EMS, then the multi-level recovery strategy for the BMS or EMS will be executed.

[0011] Among them, the multi-level recovery strategy includes recovery strategies executed for the file system and software system within the data volume in the BMS or EMS.

[0012] Optionally, recovery strategies performed on the file system within the data volume include:

[0013] After the system's operating system boots up successfully, check whether the file system within the data volume is abnormal.

[0014] When the file system within a data volume becomes abnormal, the operating system's file repair function is used to repair the file system within the data volume.

[0015] If the repair fails, the file system within the data volume will be formatted, and the data volume containing the formatted file system will be remounted by the operating system.

[0016] Optional recovery strategies for the software system include:

[0017] Read the software system version upgrade file stored in the target file system; where the target file system is the file system within the data volume;

[0018] Based on the status markers and version identifiers of the software system within the version upgrade file, version detection is performed on the software system to obtain the version detection results;

[0019] Based on the version detection results, determine the recovery strategy for the software system version.

[0020] Optionally, based on the software system's status flags and version identifiers within the version upgrade file, version detection is performed on the software system to obtain version detection results, including:

[0021] If the status flag indicates that the software system is in the process of upgrading, and the current version identifier of the software system is the same as the historical version identifier, and the file system is found to be missing some updated files, then the version detection result is determined to be the first type of version upgrade failure of the software system.

[0022] If the status flag indicates that the software system is in the process of upgrading, and all updated files are missing from the file system, then the version detection result is determined to be the second type of version upgrade failure of the software system.

[0023] Optionally, based on the version detection results, determine the recovery strategy for the software system version, including:

[0024] If the version detection result indicates that the first type of software system upgrade has failed, the download program will be invoked to download the software system update package from a remote server or external device.

[0025] After the software system update package is downloaded, the update program is instructed to install the software system update package to obtain the upgraded software system.

[0026] Optionally, based on the version detection results, determine the recovery strategy for the software system version, including:

[0027] If the version detection result indicates that the second type of software system upgrade has failed, the update program is invoked to obtain the basic software environment package and install it in order to redeploy the software system's operating environment.

[0028] Invoke the download program to download software system update packages from a remote server or external device;

[0029] After the software system update package is downloaded, the update program is instructed to install the software system update package to obtain the upgraded software system.

[0030] Optionally, the management system also includes a restore button;

[0031] The system notifies the user via IoT alarm devices after the operating system fails to boot.

[0032] After receiving a user's trigger action to press the restore button, restore the partition where the operating system is located and restart the operating system.

[0033] Optionally, the power failure protection strategy includes one or more of the following:

[0034] Save process data and exit the process;

[0035] Record power outage events;

[0036] Report power outage incidents;

[0037] Notify the lower-level equipment BMS or EMS to enter power outage protection mode;

[0038] Automatically shut down.

[0039] In a second aspect, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0040] Memory, used to store computer programs;

[0041] When a processor executes a program stored in memory, it implements any of the method steps in the first aspect described above.

[0042] Thirdly, a computer-readable storage medium is provided, wherein a computer program is stored therein, and when executed by a processor, the computer program implements any of the method steps of the first aspect described above.

[0043] This application uses a processor to periodically detect the main power supply's operating status at a preset interval shorter than the auxiliary power module's runtime. This ensures a rapid response when the main power supply is disconnected and immediately activates a power failure protection strategy during auxiliary power supply operation. This allows the management system to orderly save data and shut down processes in the event of an abnormal main power failure, reducing the risk of data loss and file system corruption. It provides data integrity protection at the hardware level and offers robust power failure protection for the management system, effectively solving the problem of poor protection capabilities in existing technologies. This is of great significance for improving the reliability and stability of the management system. Attached Figure Description

[0044] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0045] Figure 1 illustrates a management system provided in an embodiment of this application.

[0046] Figure 2 is a flowchart illustrating an abnormal power outage handling method for a management system provided in an embodiment of this application;

[0047] Figure 3 is a flowchart illustrating the recovery strategy executed on the file system within a data volume according to an embodiment of this application;

[0048] Figure 4 is a flowchart illustrating the recovery strategy executed by the software system according to an embodiment of this application;

[0049] Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0050] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise defined, the technical or scientific terms used in this application should have the ordinary meaning understood by those skilled in the art. Words such as "comprising" or "including" mean that the element or object preceding the word covers the element or object listed after the word and its equivalents, but does not exclude other elements or objects. Words such as "connection," "coupled," or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0051] For ease of understanding, the terms used in the embodiments of this application are explained below:

[0052] An operating system is system software that manages computer hardware and software resources; it serves as the interface between the user and the computer hardware. The operating system is responsible for coordinating, managing, and controlling various hardware and software resources of the computer so that users can utilize these resources efficiently.

[0053] A file system is a structure used to store, organize, access, and protect files and directories.

[0054] A software system is a collection of interconnected software components deployed through a basic software environment package and software system update packages, used to provide business functions to achieve specific functions or objectives.

[0055] Journaling file system: Reduces the risk of data corruption when the file system crashes by logging file operations.

[0056] The root file system contains the core files and directory structure of the operating system.

[0057] The fsck tool, or "filesystem checker," is used to check the consistency and integrity of a file system and to repair file system errors.

[0058] The mkfs tool, which stands for "create new file system", is used to clear old data and create new file systems.

[0059] The abnormal power failure handling method for the management system provided in this application embodiment can be applied to the management system shown in Figure 1, wherein the management system is located in a BMS or EMS. The management system 100 includes a first circuit 110 and a second circuit 120. The first circuit includes a processor 111 and an auxiliary power module 112. The management system 100 is powered by a main power supply, and the auxiliary power module 112 is used to supply power to the first circuit 110 when the main power supply is disconnected.

[0060] The first circuit 110, comprising a processor 111 and an auxiliary power module 112, is the core of the management system. The processor 111 is responsible for monitoring, calculation, and decision-making, while the auxiliary power module 112 serves as a backup power source, providing power when the main power supply is interrupted. The auxiliary power module 112 can be composed of a supercapacitor and / or an uninterruptible power supply. Depending on actual usage requirements, the first circuit 110 can also additionally include necessary I / O interfaces, memory, flash memory, and other core components from the core board. The second circuit 120 includes other components from the BMS or EMS besides the first circuit, such as expansion boards and expansion devices. These expansion devices can include backup interfaces, screens, keyboards, cameras, and other functional devices.

[0061] The processor 111 in the first circuit 110 is responsible for executing various control algorithms, data processing tasks, and system monitoring functions corresponding to the management system. The processor 111 in the first circuit 110 is also used to continuously detect the operating status of the main power supply according to a preset cycle, and to execute a power-off protection strategy when the main power supply is disconnected. The auxiliary power supply module 112 actively connects when the main power supply is disconnected to supply power to the processor 111. The second circuit 120 is responsible for executing functions such as security protection, data interaction, and expansion device management of the management system.

[0062] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0063] Figure 2 is a flowchart illustrating an abnormal power failure handling method for a management system according to an embodiment of this application. As shown in Figure 2, the abnormal power failure handling method for the management system, located in a BMS or EMS, includes a first circuit and a second circuit. The first circuit includes a processor and an auxiliary power module. The management system is powered by a main power supply, and the auxiliary power module supplies power to the first circuit when the main power supply is disconnected. The method may include:

[0064] Step 210: The processor detects the working status of the main power supply according to a preset cycle, which is shorter than the battery life of the auxiliary power module.

[0065] The processor checks the power status file or the signal status of a preset virtual port according to a preset detection cycle. If the power status file value is 0 or the preset virtual port signal status is normal, the main power supply is determined to be on; if the power status file value is 1 or the preset virtual port signal status is a warning, the main power supply is determined to be off. The power status file is generated by the operating system in real time by collecting the main power supply voltage and is stored in the file system. The preset virtual port is a virtual port that represents the power on / off state.

[0066] Since the auxiliary power module has a limited battery life, it is necessary to detect the main power disconnection status in time before it runs out. Setting a preset period shorter than the auxiliary power module's battery life is to ensure that the processor can detect the anomaly and start the power-down protection strategy in time when the main power is disconnected, allowing sufficient time for the power-down protection strategy to be executed, thereby protecting the data security, hardware integrity and overall stability of the management system.

[0067] Step 220: When the main power supply is detected to be disconnected, execute the power-off protection strategy for the BMS or EMS during the auxiliary power module's runtime.

[0068] In practical applications, when the main power supply is disconnected, the auxiliary power module automatically supplies power to the first circuit. When the processor determines that the main power supply is disconnected, it utilizes the power supply time from the auxiliary power module to orderly shut down the operating system, effectively preventing data loss and file system corruption. The battery life of the auxiliary power module can be predetermined based on the duration of the power outage protection strategy.

[0069] This application uses a processor to periodically detect the main power supply's operating status at a preset interval shorter than the auxiliary power module's runtime. This ensures a rapid response when the main power supply is disconnected and immediately activates a power failure protection strategy during auxiliary power supply operation. This allows the management system to orderly save data and shut down processes in the event of an abnormal main power failure, reducing the risk of data loss and file system corruption. It provides data integrity protection at the hardware level and offers robust power failure protection for the management system, effectively solving the problem of poor protection capabilities in existing technologies. This is of great significance for improving the reliability and stability of the management system.

[0070] In one possible implementation, the power failure protection strategy includes one or more of the following:

[0071] Save process data and exit the process;

[0072] Record power outage events;

[0073] Report power outage incidents;

[0074] Notify the lower-level equipment BMS or EMS to enter power outage protection mode;

[0075] Automatically shut down.

[0076] In practical applications, saving process data and exiting processes means that when the processor detects that the main power supply is disconnected, it immediately saves the data of currently running processes. After saving the data, the system safely exits these processes, effectively preventing data loss or corruption due to sudden power outages and ensuring that processes do not terminate abnormally due to sudden power outages, thus preventing potential errors or data inconsistencies. The processor records relevant information about power outage events, such as the time of occurrence, duration, and affected devices. Recording power outage events is beneficial for subsequent analysis of the cause of the power outage, assessment of its impact on the system, and development of preventative measures. Reporting power outage events includes sending information about the power outage event to external devices in the form of messages, which helps to promptly notify relevant personnel to respond to and handle the power outage event. Notifying lower-level devices (BMS or EMS) to enter power outage protection mode involves sending a power outage protection status notification to the connected lower-level devices in the form of messages. The lower-level devices can then take appropriate protective measures based on the received notification. Active shutdown is a strategy that is typically implemented after other power outage protection policies have been executed but before the main power supply has been restored. It protects the hardware in the management system from damage caused by voltage fluctuations or current surges that may result from power outages.

[0077] In one possible implementation, to improve the recovery capability of the management system after an abnormal power outage and reduce the need for on-site maintenance by engineers, the abnormal power outage handling method of the management system further includes:

[0078] After the main power supply is powered on, if it is detected in the historical log that the last main power supply was abnormally disconnected and triggered the power failure protection strategy for the BMS or EMS, then the multi-level recovery strategy for the BMS or EMS will be executed.

[0079] Among them, the multi-level recovery strategy includes recovery strategies executed for the file system and software system within the data volume in the BMS or EMS.

[0080] In practical applications, the processor determines the status of the main power supply by detecting that the value of the power status file is 0 or the signal status of the preset virtual port is normal. When the processor determines from the historical log in the log file system that the last time the main power supply was abnormally disconnected and triggered the power failure protection policy for the BMS or EMS, it can sequentially execute the recovery policy of the file system in the data volume of the BMS or EMS and the recovery policy executed by the software system in the BMS or EMS.

[0081] This application employs automated power outage protection and multi-level recovery strategies to monitor the main power module, maintain the auxiliary power module's power supply, and restore the file system and software execution within the data volume. This reduces system damage and data loss caused by power outages, significantly decreases the need for on-site engineer maintenance, shortens system recovery time, and improves device reliability and user experience. The automated power outage protection and multi-level recovery strategies simultaneously provide multi-layered protection and automatic recovery in the event of a power outage, greatly enhancing the system's resilience.

[0082] In practical implementation, referring to Figure 3, the recovery strategy executed for the file system within the data volume includes:

[0083] Step 310: After the system's operating system boots up successfully, check if the file system in the data volume is abnormal.

[0084] In practical applications, the operating system of a management system automatically performs automatic checks on the root file system and the file systems within the data volume during the power-on boot process. This automatic check can be achieved using the fsck tool or other detection tools. If the operating system detects corruption in the data volume, it will use the fsck tool or other file repair tools to repair the file systems within the data volume. Since the operating system's detection and repair of the file systems within the data volume may fail, to avoid affecting the operating system's boot process, the data volume is mounted in asynchronous writable mode with a nofail mounting strategy. That is, when the operating system encounters a failure in checking and repairing the data volume, it will ignore this failure and continue the boot process. After the operating system successfully completes the boot process, including automatic checks and other operations, the processor again performs a check on the file systems within the data volume. The detection tool used by the processor for this check can be the same as or different from the tool used by the operating system during the automatic checks during the power-on boot process. When the processor detects anomalies in the file systems within the data volume, it can obtain error reports, which are categorized into four types: superblock errors, inode errors, data block errors, and directory structure errors.

[0085] Step 320: When the file system within the data volume is abnormal, the file system within the data volume is repaired using the operating system's file repair function.

[0086] In practical applications, when the processor receives an error report, it determines that the file system within the data volume is abnormal. The processor then invokes the operating system's file repair function to perform repairs. Specifically, the processor uses the operating system's repair tools to repair the file system within the data volume. These repair operations include repairing corrupted superblocks, recovering lost files or inodes, recovering lost directories, and repairing corrupted data blocks. The repair time depends on the size of the file system within the data volume and the severity of the error. The processor receives feedback from the operating system's repair tools, which can be either successful or failed.

[0087] Step 330: If the repair fails, format the file system within the data volume and remount the data volume containing the formatted file system through the operating system.

[0088] In practical applications, when the processor receives a repair failure result, it invokes a formatting tool to erase all existing files and data structures on the data volume and reinitializes the data volume according to a specific file system format. The formatting tool can be the mkfs utility or any other tool capable of formatting. After formatting, the processor, through the operating system, remounts the data volume containing the formatted file system, making it accessible to the operating system and applications.

[0089] This application detects file system anomalies after successful system boot. For detected anomalies, it meticulously repairs them using the operating system's file repair function, significantly improving the data recovery success rate. In cases where repair fails, it formats and remounts the data volume to thoroughly eliminate file system errors, ensuring the cleanliness and consistency of the data volume. This not only reduces manual intervention but also comprehensively enhances the recovery capabilities of the data volume's file system, providing strong support for stable system operation and data security.

[0090] In practical implementation, to further enhance the management and maintenance capabilities of the software system, referring to Figure 4, the recovery strategies implemented for the software system include:

[0091] Step 410: Read the software system version upgrade file stored in the target file system; where the target file system is the file system within the data volume.

[0092] Step 420: Based on the status flags and version identifiers of the software system in the version upgrade file, perform version detection on the software system and obtain the version detection results.

[0093] In practical applications, the version upgrade file is stored within a file system file on the data volume. This file records the current state of the software system and its version number. The status flag indicates the current state of the software system, either in the process of upgrading or not. The version identifier indicates the software system's version number. The version identifier can be identified from the flag file or the version file. When the software system begins upgrading, the flag in the flag file is changed from "not upgrading" to "upgrading," and the version number recorded in the version file is the original version number. After the software system upgrade is complete, the upgraded version number is first recorded in the version file, and then the flag in the flag file is changed from "upgrading" to "not upgrading."

[0094] In practice, based on the status markers and version identifiers of the software system within the version upgrade file, version detection is performed on the software system to obtain version detection results, which may include, but are not limited to, the following four types:

[0095] The first detection result: If the status flag indicates that the software system is in the process of upgrading, and the current version identifier of the software system is the same as the historical version identifier, and missing updated files are detected in the file system, then the version detection result is determined to be the first type of version upgrade failure of the software system. The first type of version upgrade failure corresponds to the situation where the software system's version upgrade is not completed when the main power supply fails to operate normally.

[0096] The second detection result: If the status flag indicates that the software system is in the process of upgrading, and all updated files are missing from the file system, then the version detection result is determined to be a second type of version upgrade failure. This second type of version upgrade failure corresponds to the situation where the software system is formatted during the upgrade process due to a fault or other reasons.

[0097] The third detection result: If the status flag indicates that the software system is in the process of upgrading, and the current version identifier of the software system is different from the historical version identifier, and no updated files are missing in the file system, then the version detection result is determined to be the first type of successful version upgrade of the software system. The first type of successful version upgrade corresponds to the situation where the version upgrade has been completed but the status flag has not changed when the main power supply fails abnormally.

[0098] The fourth detection result: If the status flag indicates that the software system is not in an un-upgraded state, and the current version identifier of the software system is different from the historical version identifier, or if no updated files are missing in the file system, then the version detection result is determined to be a successful second-type version upgrade of the software system. A successful second-type version upgrade corresponds to the situation where the version upgrade has already been completed when the main power supply experiences an abnormal power outage.

[0099] The fifth detection result: If the status flag indicates that the software system is not in an un-upgraded state, and the current version identifier of the software system is different from the historical version identifier, or if the updated files are detected to be missing in the file system, then the version detection result is determined to be the third type of version upgrade failure of the software system. The third type of version upgrade failure corresponds to the situation where the version upgrade has been completed when the main power supply fails abnormally, but the updated files are lost or corrupted during use due to some errors.

[0100] Step 430: Based on the version detection results, determine the recovery strategy for the software system version.

[0101] In practical applications, version detection results can determine whether to restore the software system version and the corresponding restoration strategy. A read-only custom partition in the system stores download programs, update programs, and basic software environment packages. The download program downloads software system update packages from a remote server or external device. The download program can be an OTA downloader, and the external device can be a USB flash drive, SD card, or other storage device. The update program applies the downloaded basic software environment package and software system update package to the system's software system. The update program can be an OTA updater that executes OTA update scripts. The basic software environment package deploys the most basic software system runtime environment for a new operating system. The software system update package is used to further deploy complete application software on top of the existing basic software system runtime environment, forming a complete software system.

[0102] In practice, for versions where the version detection result indicates a first-type version upgrade failure, a recovery strategy for the software system version is determined based on the version detection result. This strategy can be implemented in, but is not limited to, the following ways:

[0103] If the version detection result indicates that the first type of software system upgrade has failed, the download program will be invoked to download the software system update package from a remote server or external device.

[0104] After the software system update package is downloaded, the update program is instructed to install the software system update package to obtain the upgraded software system.

[0105] Specifically, when the first type of upgrade fails, the basic software system operating environment is not damaged; only the software environment where the software system update package is deployed is compromised. In this case, there is no need to install the basic software environment package. The software system version recovery strategy is to re-download and reinstall the software system update package. That is, the processor calls the built-in download program to attempt to download the software system update package from a remote server or external device. After the software system update package is downloaded, the processor instructs the built-in update program to begin installing the software system update package. The update program will deploy the new software version to the target system according to preset steps and logic, replacing the old version's files and configurations. At the same time, the processor will also record log information during the upgrade process for troubleshooting if problems occur.

[0106] In practice, for versions where the upgrade fails due to version detection (Category II), a recovery strategy for the software system version is determined based on the version detection results. This strategy can be implemented in, but is not limited to, the following ways:

[0107] First, if the version detection result indicates that the second type of software system upgrade has failed, the update program is called to obtain the basic software environment package and install it in order to redeploy the software system's operating environment.

[0108] Then, the download program is invoked to download the software system update package from the remote server or external device;

[0109] Finally, after the software system update package is downloaded, the update program is instructed to install the software system update package to obtain the upgraded software system.

[0110] Specifically, when the second type of upgrade fails, the basic software system operating environment has been corrupted. In this case, the software system version recovery strategy requires first installing the basic software environment package, and then re-downloading and installing the software system update package. This involves calling the update program to retrieve the stored basic software environment package and install it to redeploy the software system's operating environment. After the basic software environment package is installed, the processor calls the built-in download program to attempt to download the software system update package from a remote server or external device. Once the software system update package is downloaded, the processor instructs the built-in update program to begin installing it. The update program will deploy the new software version to the target system according to preset steps and logic, replacing the old version's files and configurations. Similarly, the processor will also record log information during the upgrade process for troubleshooting in case of problems.

[0111] Furthermore, for versions where the version detection result indicates a successful upgrade (Category 1), the status flag can be automatically updated to "not upgrading." For versions where the version detection result indicates a successful upgrade (Category 2), no additional action is required. For versions where the version detection result indicates a failed upgrade (Category 3), the update program is invoked to obtain and install the basic software environment package to redeploy the software system's runtime environment. Then, the download program is invoked to download the software system update package from a remote server or external device. Finally, after the software system update package is downloaded, the update program is instructed to install it to obtain the upgraded software system.

[0112] This application manages the system's software system recovery mechanism, which can automatically detect and complete incomplete upgrades after a power outage, ensuring software environment consistency and reducing the risk of system unavailability or data loss due to upgrade failures. Even in the event of an upgrade failure or system reset, the system can automatically restore to the latest version, enhancing system stability and reliability. Furthermore, based on a file system storing status flags and version identifiers within the data volume, and given that the judgment logic based on status flags and version identifiers is generally relatively simple, the processor can quickly obtain the current status and version information of the software system with almost no additional latency and accurately determine the version detection results. Accurate judgment of version detection results avoids blind implementation of software system version recovery strategies, improving the targeting and accuracy of the recovery strategy. Differentiated recovery strategies are adopted for different version upgrade failure scenarios; this refined processing improves recovery efficiency and reduces unnecessary operations.

[0113] In one possible implementation, after the software system update package is downloaded, the processor verifies the downloaded software system update package to ensure its integrity and correctness. Specific verification methods include at least one of the following: checking file size, using MD5 (Message Digest Algorithm 5) and SHA-1 (Secure Hash Algorithm 1) hash values.

[0114] In one possible implementation, after obtaining the upgraded software system, the processor can perform a version check on the software system again based on the status flags and version identifiers within the version upgrade file. If the version check result indicates a successful second-type version upgrade, the recovery strategy is considered successful, and the user or system administrator can be notified for further operations. If the version check result indicates a failed first-type version upgrade, a rollback mechanism is triggered, using backed-up critical data to restore the software system to its pre-upgrade state, and the reason for the failure is recorded for subsequent analysis. The backed-up critical data refers to the critical data backed up before the software system upgrade.

[0115] In one possible implementation, the management system also includes a recovery button; the operating system recovery process based on the recovery button includes, but is not limited to, the following methods:

[0116] First, after the operating system of the management system fails to boot, the user is notified via an IoT alarm device;

[0117] Then, after receiving the user's trigger action of pressing the restore button, the partition where the operating system is located is restored, and the operating system is restarted.

[0118] In practical applications, when the management system's operating system fails to boot, the system's processor immediately triggers an IoT alarm device, notifying the user of the fault information via SMS, email, or app push notifications. The user's triggering of the recovery button generates a recovery command. Upon receiving the user's recovery command, the management system enters an automatic recovery process. The partition containing the operating system includes all the core files and directories required for its operation, as well as the kernel image and bootloader needed for the operating system's startup. Specifically, the operating system partition includes the kernel partition, the root file system partition, and several other operating system-related partitions. Different recovery methods are used depending on the access permissions of the operating system partition. If the operating system partition is writable, the processor can use a formatting tool to format it. If it is read-only, the processor can use a disk imaging tool to create a complete image of the read-only partition, use an image processing tool to analyze the image file's contents, generate a recovery image file, and then use the disk imaging tool to write the image file's contents to the read-only partition, replacing the original data in the read-only partition. After recovery is complete, the operating system will automatically restart.

[0119] This application introduces a recovery button to the operating system recovery process. When the management system encounters an operating system boot failure, the system immediately sends a fault notification to the user via an IoT alarm device. This ensures that the user is quickly informed and can take action, achieving rapid response in fault detection and recovery, effectively shortening system downtime and ensuring the continuous and stable operation of the management system. Users simply need to trigger the recovery button to start the automated recovery process. This process includes formatting the partition where the operating system is located to thoroughly remove potential errors and damage, providing a clean environment for system reinstallation. Subsequently, the system automatically restarts and attempts to reload the operating system, eliminating the need for complex manual operations by the user. This simplifies the operating system recovery process, reduces the difficulty of operation for users, and significantly improves recovery efficiency and accuracy.

[0120] Furthermore, operations such as abnormal power supply disconnection, system emergency shutdown, main power supply status update from abnormal disconnection to normal operation, data volume formatting, data volume repair, and software system recovery are all recorded by the log file system and reported to the cloud platform and user terminal when appropriate. These logs help maintenance personnel quickly locate and resolve faults. The management system can also collaborate with the BMS and EMS in a timely manner through parallel or downstream links to rapidly adjust the management system's status, such as cutting off the primary power supply and activating the backup power supply, preventing further escalation of the fault. The management system's external network typically uses a mobile wireless network; parallel and downstream communication typically uses RS485, CAN, and Ethernet. The management system's abnormal power outage protection function allows the software system to send control commands to the battery pack in the event of an anomaly, enabling adjustments to battery pack strategies or control of charging and discharging.

[0121] In one possible implementation, the root file system partition adopts an overlayfs hierarchical file system; wherein, the read-only partition is used to store the original data of the operating system in the system at the factory state, and the writable partition is used to store the dynamic data generated by the operating system in the system during runtime.

[0122] In practical applications, storing raw data in a read-only partition prevents accidental modification or deletion of this data during system operation, thus protecting the integrity of the root file system partition. A writable partition is used to store dynamic data generated by the operating system within the system, such as configuration changes and temporary files. When the system needs to be updated or restored, simply replacing or resetting the data in the writable partition facilitates system upgrades and rollbacks. This support makes the system easier to maintain and manage, reducing operational costs. Furthermore, in the event of a system failure or anomaly, resetting or replacing the data in the writable partition can quickly restore normal system operation. This rapid recovery capability reduces system downtime and maintenance costs, improving system availability and stability.

[0123] Furthermore, the data volume uses the ext4 journaling file system. The software system employs caching and transaction mechanisms when writing data to the data volume and reduces the number of write operations through periodic synchronization. In this way, the combined application of the overlay file system and the ext4 journaling file system achieves file system self-protection and transaction management, reducing the wear and tear on the storage media caused by frequent write operations.

[0124] This application embodiment also provides an electronic device, as shown in FIG5, including a processor 510, a communication interface 520, a memory 530 and a communication bus 540, wherein the processor 510, the communication interface 520 and the memory 530 communicate with each other through the communication bus 540.

[0125] Memory 530 is used to store computer programs;

[0126] When the processor 510 executes the program stored in the memory 530, it performs the following steps:

[0127] The processor detects the working status of the main power supply according to a preset cycle, which is shorter than the battery life of the auxiliary power module.

[0128] When the main power supply is detected to be disconnected, a power-off protection strategy for the BMS or EMS is executed within the auxiliary power module's runtime.

[0129] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0130] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0131] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0132] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0133] Since the implementation methods and beneficial effects of the various devices in the above embodiments of the electronic device can be achieved by referring to the steps in the embodiments shown in Figure 2, the specific working process and beneficial effects of the electronic device provided in this application embodiment will not be repeated here.

[0134] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when executed on a computer, cause the computer to perform any of the abnormal power failure handling methods of the management system in the above embodiments.

[0135] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the abnormal power failure handling methods of the management system in the above embodiments.

[0136] Those skilled in the art will understand that the embodiments in this application can be provided as methods, systems, or computer program products. Therefore, the embodiments in this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments in this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0137] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0138] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0139] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0140] Although preferred embodiments have been described in this application, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of this application.

[0141] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims in this application and their equivalents, then this application also intends to include these modifications and variations.

Claims

1. A method of managing an abnormal power-off process of a system, characterized by, The management system is located in a BMS or EMS, and comprises a first circuit and a second circuit. The first circuit comprises a processor and an auxiliary power module. The management system is powered by a main power supply, and the auxiliary power module is used to power the first circuit when the main power supply is disconnected. The method comprises: The processor detects the working state of the main power supply at a preset period, and the preset period is less than the endurance time of the auxiliary power module. When it is detected that the state of the main power supply is disconnected, a power-off protection strategy for the BMS or EMS is executed within the endurance time of the auxiliary power module.

2. The method of claim 1, wherein, The method further comprises: After the main power supply is powered on, if it is detected that the last main power supply was abnormally disconnected and triggered a power-off protection strategy for the BMS or EMS in the historical log, a multi-level recovery strategy for the BMS or EMS is executed. The multi-level recovery strategy comprises a recovery strategy for a file system and a software system in a data volume in the BMS or EMS.

3. The method of claim 2, wherein, The recovery strategy for the file system in the data volume comprises: After the operating system of the management system is successfully started, it is detected whether the file system in the data volume is abnormal. When the file system in the data volume is abnormal, the file system in the data volume is repaired through a file repair function of the operating system. When the repair fails, the file system in the data volume is formatted, and the data volume in which the formatted file system is located is re-mounted through the operating system.

4. The method of claim 2, wherein, The recovery strategy for the software system comprises: A version upgrade file of the software system stored in a target file system is read, wherein the target file system is the file system in the data volume. Based on the state mark and version identifier of the software system in the version upgrade file, a version detection result of the software system is obtained. Based on the version detection result, a recovery strategy for the version of the software system is determined.

5. The method of claim 4, wherein, Based on the state mark and version identifier of the software system in the version upgrade file, a version detection result of the software system is obtained, comprising: If the state mark represents that the software system is in an upgrading state, and the current version identifier of the software system is the same as the historical version identifier, and it is detected that some updated files are missing in the file system, it is determined that the version detection result is a first type of version upgrade failure of the software system. If the state mark represents that the software system is in an upgrading state, and it is detected that all updated files are missing in the file system, it is determined that the version detection result is a second type of version upgrade failure of the software system.

6. The method of claim 5, wherein, Based on the version detection result, a recovery strategy for the version of the software system is executed, comprising: If the version detection result is the first type of version upgrade failure of the software system, a download program is called to download a software system update package from a remote server or an external device. After the software system update package is downloaded, an update program is instructed to install the software system update package to obtain the software system after version upgrade.

7. The method of claim 5, wherein, Based on the version detection result, a recovery strategy for the version of the software system is performed, comprising: If the version detection result is that the second type of version upgrade of the software system fails, an updating program is called to obtain and install a basic software environment package to redeploy a running environment of the software system; A downloading program is called to download a software system update package from a remote server or an external device; After the software system update package is downloaded, an updating program is instructed to install the software system update package to obtain a software system after version upgrade.

8. The method of claim 1, wherein, The management system further comprises a recovery button; After the operating system of the management system fails to start, an Internet of Things alarm device is used to inform a user; After receiving a trigger operation of the user triggering the recovery button, a partition where the operating system is located is recovered, and the operating system is restarted.

9. The method of claim 1, wherein, The power-off protection strategy comprises one or more of the following: Saving process data and exiting the process; Recording a power-off event; Reporting the power-off event; Notifying a lower-layer device BMS or EMS of a power-off protection state; Proactively shutting down.

10. An electronic device, comprising: The electronic device comprises a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete communication with each other through the communication bus; The memory is used to store a computer program; The processor is used to execute the program stored on the memory to implement the method of any one of claims 1-9.

11. A computer readable storage medium characterized by, The computer program is stored in the computer readable storage medium, and the computer program is executed by the processor to implement the method of any one of claims 1-9.

Images