Micro-grid system software OTA upgrading method based on edge computing energy management unit (EMU)

Abstract

The invention relates to the technical field of micro-grid systems, in particular to a micro-grid system software OTA upgrading method based on an edge computing energy management unit (EMU). The method comprises the steps that an EMU is deployed in a micro-grid system to serve as a field OTA upgrading center, encrypted firmware of all subsystems is stored, and Bootloader is deployed in all the subsystems. An OTA upgrade request is initiated through a cloud or a local server, a differential upgrade package is generated, an EMU receives the differential upgrade package and then carries out security authentication and decryption, and a complete upgrade package is generated and transmitted to a subsystem. And after receiving the upgrade package, the Bootloader of the subsystem executes decryption, verification and software update operations, and feeds back an upgrade result to the EMU, and then the upgrade result is uploaded to a cloud or a local server by the EMU. According to the method, differential upgrading and breakpoint resume technologies are utilized, the data transmission quantity is reduced, the upgrading efficiency is improved, the occupied storage space is reduced, and the continuity and reliability of the upgrading process are ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of microgrid systems, and in particular to an OTA upgrade method for microgrid system software based on an edge computing energy management unit (EMU). Background Art

[0002] As a critical infrastructure, microgrid systems have extremely high security requirements for OTA upgrades and need to guard against risks such as malicious attacks and data tampering. Especially when the subsystem is provided by a third party and its firmware file is encrypted, ensuring the security of OTA upgrades and protecting the technical secrets of third-party manufacturers becomes an urgent problem to be solved. Existing microgrid system software upgrades mostly rely on manual on-site operations, which are inefficient and prone to errors; there are many shortcomings in the application of OTA technology to microgrid systems, such as limited subsystem storage space and computing power, difficulty in realizing multi-version storage and complex upgrade functions, and limiting upgrade flexibility; bandwidth limitations and instability of the network environment also affect the efficiency and reliability of OTA upgrades.

[0003] As an important means of distributed energy management and optimization, microgrid systems play an increasingly important role in modern energy systems. However, with the increasing complexity of microgrid systems, the update and maintenance of their software systems have become increasingly important. Traditional software upgrade methods, such as upgrading through USB or other wired methods, have problems such as low efficiency, complex operation, and high potential risks. These problems not only increase maintenance costs, but may also affect the stability and security of microgrid systems.

[0004] The introduction of OTA (Over-the-Air) upgrade technology provides a more convenient and efficient solution for software updates of microgrid systems. OTA technology allows remote transmission and installation of update packages through wireless networks, which significantly improves upgrade efficiency, reduces maintenance costs, and enhances the scalability and flexibility of the system. However, the application of existing OTA technology in microgrid systems is not perfect. Limited by geographical location and wireless network coverage, it may be difficult to achieve stable and reliable OTA upgrades in some remote or poor signal areas; large-scale deployed microgrid systems may face problems such as uneven resource allocation and low upgrade efficiency during OTA upgrades, especially when dealing with complex compatibility issues; in addition, data security issues during OTA upgrades cannot be ignored. If the transmission of sensitive information is not properly protected, it may lead to the risk of data leakage or tampering, thereby affecting the overall security of the system.

[0005] In the microgrid system, the energy management unit EMU based on edge computing is the core component of energy management and optimization, responsible for real-time monitoring and control of the operating status of the system. However, the application of existing edge computing technology in microgrid systems is also insufficient. On the one hand, due to the lack of dynamic perception of the real-time needs and status of the equipment, EMU may not be flexible enough in resource allocation, resulting in low resource utilization and limited overall system performance. On the other hand, microgrid systems are usually deployed in complex and changeable environments. The communication between devices may be affected by various factors such as electromagnetic interference and equipment load, resulting in high communication delays, affecting the real-time and stability of the OTA upgrade process. In addition, the existing edge computing technology lacks intelligent management in the microgrid system, and cannot automatically adjust the upgrade strategy according to the real-time status and needs of the equipment, resulting in difficulty in timely response and processing when problems arise during the upgrade process. Summary of the invention

[0006] In order to solve the problems existing in the background technology, the present invention provides a microgrid system software OTA upgrade method based on edge computing energy management unit EMU, which includes the following steps:

[0007] S1, deploy edge computing-based energy management unit EMU devices in the microgrid system as the on-site OTA upgrade center;

[0008] S2, storing the encryption software of each subsystem of the microgrid system in the EMU;

[0009] S3, deploying a boot loader in each subsystem of the microgrid system;

[0010] S4, initiate an OTA upgrade request from the cloud or local server, specify the subsystem file to be upgraded, the target software version and the verification file, and send the upgrade request;

[0011] S5, the cloud or local server generates a differential upgrade package patch PATCH according to the target version and the current version of the subsystem; the differential upgrade package only contains the difference data between the two versions;

[0012] S6, after receiving the OTA upgrade request, EMU first performs security authentication to ensure that the request comes from a legitimate source. After the authentication is passed, EMU decrypts the target encrypted firmware and receives the differential upgrade package after confirmation, which can be continued from the breakpoint;

[0013] S7, EMU generates a complete upgrade package based on the differential upgrade package and the current version, interacts with the server, verifies the integrity of the generated complete upgrade package, and then transmits it to the subsystem;

[0014] S8, after receiving the upgrade package, the subsystem's Bootloader decrypts and verifies it, and executes the subsystem application software update operation; writes the new version of the software into the corresponding storage area, and updates the system's startup configuration. The EMU saves the subsystem's historical version for easy rollback;

[0015] S9, after the subsystem software is successfully updated, the upgrade result is fed back to EMU; EMU uploads the result to the cloud or local server; EMU saves the historical version of the subsystem for easy rollback.

[0016] In a preferred solution, the specific process of step S5 includes:

[0017] S51, preparation stage;

[0018] S511, clarify the current version and target version of the subsystem;

[0019] S512, obtaining or developing a tool for generating a differential upgrade package;

[0020] S52, file comparison and difference extraction

[0021] S521, file traversal: traverse all files in the target version file system and compare them with the current version file system;

[0022] S522, difference identification: using a difference algorithm to identify the differences in the file contents between the two versions, including the addition, deletion, and modification of files;

[0023] S523, difference packaging: packaging the identified difference data into a differential upgrade package PATCH package, which contains all the difference information required to upgrade the current version to the target version;

[0024] S53, differential packet generation and verification;

[0025] S531, differential package generation: using a differential package generation tool, input the current version file, the target version file and the differential package storage location information to generate a differential package file;

[0026] S532, verify the differential package: after generating the differential package, perform verification to ensure the correctness and integrity of the differential package; if the verification succeeds, deploy it; if the verification fails, check for errors and regenerate the differential package;

[0027] S54, deployment and notification;

[0028] S541, deploying the differential package: deploying the generated differential package to a specified storage location;

[0029] S542, notify the device: notify the EMU through the cloud or other communication methods that a new differential upgrade package is available.

[0030] In a preferred solution, the specific process of step S6 includes:

[0031] S61, preparation stage;

[0032] S611, confirm the version: ensure that the current version and the target version of the subsystem are known, so as to confirm the differential upgrade package to be transmitted;

[0033] S612, check the network: ensure that the transmission channel is stable and available to facilitate breakpoint resuming;

[0034] S613, prepare a differential upgrade package: ensure that the differential upgrade package has been correctly generated and saved in a specified storage location;

[0035] S62, establishing connection and initialization;

[0036] S621, establish connection: EMU tries to establish connection with the cloud or local to obtain the differential upgrade package;

[0037] S622, request file information: EMU sends a request to the cloud or local to obtain file information of the differential upgrade package, including file size and segment information;

[0038] S623, determine the transmission strategy: determine the transmission strategy, such as segment size and number of concurrent requests, according to the file size and network conditions;

[0039] S63, start transmission and resume transmission;

[0040] S631, sending request: EMU sends a request to the cloud or local according to the transmission strategy, specifying the file segment to be downloaded;

[0041] S632, receiving data: the cloud or local returns corresponding file segment data according to the request;

[0042] S633, write file: EMU writes the received data to the local differential upgrade package file. Note that the append mode is used to ensure that the downloaded data will not be overwritten.

[0043] S634, record progress: During the transmission process, EMU needs to record the amount of data downloaded and the amount of data not downloaded, so that the transmission can be continued from the last breakpoint after an interruption;

[0044] S635, processing interruption: If an interruption occurs during the transmission process, the EMU saves the current transmission progress and continues the transmission after the connection is restored;

[0045] S636, repeating steps: Repeat steps S631 to S635 as needed until all differential upgrade packages are downloaded.

[0046] In a preferred solution, the specific process of step S8 includes:

[0047] S81, initializes the MCU clock, Flash controller, communication interface peripherals, initializes the registers and stacks required for program operation, detects the integrity of the application program in the main partition or backup partition, and runs the corresponding program; writes the upgrade image to the update area and sets the upgrade flag; according to the restart strategy, when the system restarts next time, the Bootloader copies the update area program to the app area and clears the upgrade flag. At the same time, as the on-site OTA center, EMU uses its rich storage resources to save the currently running software version and at least one historical version in case of rollback;

[0048] S82, Bootloader initializes the hardware of the device, which includes connecting to the universal asynchronous receiver-transmitter UART, the general-purpose input and output port GPIO, the controller area network CAN and the memory Flash interface;

[0049] S83, after initializing the hardware, the Bootloader checks whether there is an upgrade flag; the upgrade flag is usually used to indicate whether there is a new software version that needs to be installed on the device; if the upgrade flag is detected, the upgrade process is entered; if not detected, the existing application is directly run. In addition, EMU maintains a version list in the storage management, recording the currently available software versions and their status, such as currently running, to be upgraded, historical versions, etc.;

[0050] S84, if the upgrade flag is detected, the Bootloader first erases the update area, then writes the new software version into the update area, and simultaneously updates the EMU version list, marking the new software version as ready to run;

[0051] S85, after upgrading the update area, the Bootloader performs a cyclic redundancy check (CRC) to ensure that the written data is not damaged; this verification process is repeated until the data is confirmed to be correct. If the verification fails, EMU can choose to roll back to the previous stable version and mark the current upgrade as failed;

[0052] S86, run app or clear app area: If no upgrade mark is detected, or the upgrade process has been completed and the data verification is correct, the Bootloader runs the existing application; if it is detected that an upgrade is required and only the software is upgraded instead of updating hardware and software at the same time, it is necessary to clear the application area first, and then copy the updated update area to the application area;

[0053] S87, copy update to app area: After clearing the application area, the Bootloader copies the updated content of the update area to the application area so that the new software version can be executed. At the same time, the EMU updates the version list and marks the new software version as the current running status;

[0054] S88, finally, the Bootloader clears the upgrade flag to indicate that the upgrade process has been completed. The EMU also maintains an upgrade history to track the results and status of each upgrade to provide a reference for future rollback or debugging.

[0055] The beneficial effects achieved by the present invention are:

[0056] The present invention significantly improves the upgrade efficiency by deploying the edge computing energy management unit EMU as the on-site OTA upgrade center. The cloud and local servers only transmit the parts that need to be upgraded by generating differential upgrade packages, which reduces the amount of data transmission, speeds up the transmission speed, and reduces network delay and the burden on the cloud server. At the same time, the encrypted firmware of each subsystem is securely stored in the EMU, multi-version management is realized, and the firmware OTA upgrade of third-party devices is supported, protecting the technical secrets of third-party firmware. The deployment of the Bootloader enhances the flexibility and upgradeability of the subsystem, and can obtain, decrypt and execute the new version of the software from the EMU. The OTA upgrade request is securely authenticated and decrypted to ensure the security of the upgrade request and the integrity of the data. The generation of the differential upgrade package significantly reduces the amount of data transmission and improves the upgrade efficiency. The breakpoint resume function ensures the continuity and reliability of the upgrade process in the case of network instability or interruption. After receiving the upgrade package, the Bootloader of the subsystem performs decryption, verification and automatic update operations, reducing the need for manual intervention. The timely feedback of the upgrade results and the remote monitoring function improve the maintainability and management efficiency of the system. The advanced encryption algorithm and the secure decryption mechanism effectively prevent the risks of malicious attacks and data tampering. In addition, multi-version management and rollback mechanisms ensure the stability and reliability of the system, and can quickly restore to the old version when the upgrade fails or there are problems with the new version. The comprehensive application of these technical features provides a strong guarantee for the long-term stable operation of the microgrid system. The details are as follows:

[0057] First, in terms of real-time performance, by introducing edge computing nodes, data transmission and processing during OTA upgrades are closer to microgrid devices. This move significantly reduces network latency, improves upgrade efficiency and real-time performance, and enables the microgrid system to respond to upgrade requirements more quickly, ensuring the continued stable operation of the system.

[0058] Secondly, in terms of resource optimization, edge computing nodes can intelligently allocate and manage computing resources. According to the actual situation and upgrade requirements of microgrid equipment, edge computing nodes can dynamically adjust the priority and resource allocation of upgrade tasks to achieve effective resource utilization. This not only improves the execution efficiency of upgrade tasks, but also reduces the overall energy consumption of the system.

[0059] In terms of encrypted firmware storage and secure decryption, advanced encryption algorithms are used to encrypt and store the firmware, ensuring the security of the firmware during transmission and storage. At the same time, a secure decryption mechanism is designed to ensure that only authorized devices or systems can decrypt the firmware, effectively preventing the firmware from being illegally copied or tampered with. In addition, a complete key management mechanism has been established, including key generation, storage, distribution and update, to further ensure the security and effectiveness of the key.

[0060] In terms of subsystem multi-version management, the version compatibility between the various subsystems in the microgrid system is achieved, ensuring the normal operation of the upgraded system. At the same time, a version tracking mechanism is established to record the version information of each subsystem for easy management and maintenance. When the upgrade fails or there are serious problems with the new version, the designed rollback mechanism can be used to quickly restore to the old version to ensure the stability and reliability of the system.

[0061] In terms of differential upgrade and breakpoint resume, the differential upgrade function is implemented, which only transmits the changed parts of the firmware, reducing the amount of data transmission and upgrade time. At the same time, a breakpoint resume mechanism is designed. When the upgrade process is interrupted due to network or other reasons, the transmission and upgrade can be continued from the last interruption point. In addition, the upgrade task is intelligently scheduled according to the network status and device status to ensure the smooth progress of the upgrade process.

[0062] Finally, in terms of remote monitoring and management, the real-time monitoring function of the microgrid system is realized, and the operating status and performance indicators of the system can be viewed in real time. A remote management interface is provided, allowing administrators to configure, upgrade and maintain the system through the network. When the system is abnormal or fails, the alarm mechanism can be automatically triggered, and the administrator will be notified by email, SMS, etc. to ensure timely maintenance and processing of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 It is the overall flow chart of the present invention;

[0064] Figure 2 is a flow chart of differential upgrade package generation of the present invention;

[0065] Figure 3 This is the breakpoint-resume flow chart of EMU transmitting the differential upgrade package to the subsystem;

[0066] Figure 4 It is the flow chart of Bootloader program. DETAILED DESCRIPTION

[0067] The technical solution of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the present invention. In addition, the forms of the various structures recorded in the following embodiments are merely illustrative, and the present invention is not limited to the various structures recorded in the following embodiments. All other embodiments obtained by ordinary technicians in this field without making creative work belong to the scope of protection of the present invention.

[0068] First, some of the terms in this invention are explained: Bootloader, also known as boot loader, is the first code that runs when the subsystem of the microgrid system starts. Its main function is to initialize the system hardware, prepare for the execution of the operating system or application, and load the operating system or application into the memory. In the OTA upgrade scenario, the bootloader is also responsible for receiving and processing the OTA upgrade package, performing necessary decryption, verification and update operations.

[0069] Bootloader is responsible for initializing various hardware devices of the system, such as CPU, memory, storage devices, etc., to provide the necessary hardware environment for the operation of the operating system or application.

[0070] Loading the operating system or application: After completing the hardware initialization, the Bootloader will load the operating system or application code from the specified storage medium into the memory and jump to the corresponding entry point to start execution. In a system that supports OTA upgrades, the Bootloader will be responsible for receiving the upgrade package from the EMU, performing decryption, verification, and other processing, and writing the new firmware to the storage medium to complete the system software upgrade.

[0071] OTA, or "Over-the-Air", refers to the technology of remotely updating the software of a device via a wireless network. Compared with the traditional wired update method, OTA update does not require physical connection of the device, greatly improving the convenience and efficiency of the update.

[0072] OTA technology allows devices to receive update packages via wireless networks and automatically install and update them on the device side without manual intervention by the user. Since OTA updates are performed over wireless networks, the latest software or firmware can be pushed to the device in real time, ensuring that the device is always running on the latest and most secure version. OTA updates can be performed on a single device or a group of devices, providing greater flexibility. At the same time, OTA updates can also include a rollback mechanism to restore to the previous version if there is a problem with the update.

[0073] In microgrid systems, OTA technology is widely used for remote upgrades of software systems. By deploying EMU as the OTA upgrade center, each subsystem of the microgrid system can receive the upgrade package sent by EMU through the wireless network and use their own Bootloader to complete the software update and upgrade.

[0074] Reference Figure 1-Figure 4 The present invention provides a microgrid system software OTA upgrade method based on edge computing energy management unit EMU, and the specific steps are as follows:

[0075] S1, deploy edge computing-based energy management unit EMU devices in the microgrid system as the on-site OTA upgrade center;

[0076] S2, storing the encryption software of each subsystem of the microgrid system in the EMU;

[0077] S3, deploying a boot loader in each subsystem of the microgrid system;

[0078] S4, initiate an OTA upgrade request from the cloud or local server, specify the subsystem file to be upgraded, the target software version and the verification file, and send the upgrade request;

[0079] S5, the cloud or local server generates a differential upgrade package patch PATCH according to the target version and the current version of the subsystem; the differential upgrade package only contains the difference data between the two versions; the specific process of step S5 includes:

[0080] S51, preparation stage;

[0081] S511, clarify the current version and target version of the subsystem;

[0082] S512, obtaining or developing a tool for generating a differential upgrade package;

[0083] S52, file comparison and difference extraction

[0084] S521, file traversal: traverse all files in the target version file system and compare them with the current version file system;

[0085] S522, difference identification: using a difference algorithm to identify the differences in the file contents between the two versions, including the addition, deletion, and modification of files;

[0086] S523, difference packaging: packaging the identified difference data into a differential upgrade package PATCH package, which contains all the difference information required to upgrade the current version to the target version;

[0087] S53, differential packet generation and verification;

[0088] S531, differential package generation: using a differential package generation tool, input the current version file, the target version file and the differential package storage location information to generate a differential package file;

[0089] S532, verify the differential package: after generating the differential package, perform verification to ensure the correctness and integrity of the differential package; if the verification succeeds, deploy it; if the verification fails, check for errors and regenerate the differential package;

[0090] S54, deployment and notification;

[0091] S541, deploying the differential package: deploying the generated differential package to a specified storage location;

[0092] S542, notify the device: notify the EMU through the cloud or other communication methods that a new differential upgrade package is available.

[0093] S6, after receiving the OTA upgrade request, EMU first performs security authentication to ensure that the request comes from a legitimate source. After the authentication is passed, EMU decrypts the target encrypted firmware and receives the differential upgrade package after confirmation, and can resume the transmission from the breakpoint. The specific process of step S6 includes:

[0094] S61, preparation stage;

[0095] S611, confirm the version: ensure that the current version and the target version of the subsystem are known, so as to confirm the differential upgrade package to be transmitted;

[0096] S612, check the network: ensure that the transmission channel is stable and available to facilitate breakpoint resuming;

[0097] S613, prepare a differential upgrade package: ensure that the differential upgrade package has been correctly generated and saved in a specified storage location;

[0098] S62, establishing connection and initialization;

[0099] S621, establish connection: EMU tries to establish connection with the cloud or local to obtain the differential upgrade package;

[0100] S622, request file information: EMU sends a request to the cloud or local to obtain file information of the differential upgrade package, including file size and segment information;

[0101] S623, determine the transmission strategy: determine the transmission strategy, such as segment size and number of concurrent requests, according to the file size and network conditions;

[0102] S63, start transmission and resume transmission;

[0103] S631, sending request: EMU sends a request to the cloud or local according to the transmission strategy, specifying the file segment to be downloaded;

[0104] S632, receiving data: the cloud or local returns corresponding file segment data according to the request;

[0105] S633, write file: EMU writes the received data to the local differential upgrade package file. Note that the append mode is used to ensure that the downloaded data will not be overwritten.

[0106] S634, record progress: During the transmission process, EMU needs to record the amount of data downloaded and the amount of data not downloaded, so that the transmission can be continued from the last breakpoint after an interruption;

[0107] S635, processing interruption: If an interruption occurs during the transmission process, the EMU saves the current transmission progress and continues the transmission after the connection is restored;

[0108] S636, repeating steps: Repeat steps S631 to S635 as needed until all differential upgrade packages are downloaded.

[0109] S7, EMU generates a complete upgrade package based on the differential upgrade package and the current version, interacts with the server, verifies the integrity of the generated complete upgrade package, and then transmits it to the subsystem;

[0110] S8, after receiving the upgrade package, the subsystem's Bootloader performs decryption and verification, and executes the subsystem application software update operation; writes the new version of the software into the corresponding storage area, and updates the system's startup configuration, and the EMU saves the subsystem's historical version for easy rollback; the specific process of step S8 includes:

[0111] S81, initializes the MCU clock, Flash controller, communication interface peripherals, initializes the registers and stacks required for program operation, detects the integrity of the application program in the main partition or backup partition, and runs the corresponding program; writes the upgrade image to the update area and sets the upgrade flag; according to the restart strategy, when the system restarts next time, the Bootloader copies the update area program to the app area and clears the upgrade flag. At the same time, as the on-site OTA center, EMU uses its rich storage resources to save the currently running software version and at least one historical version in case of rollback;

[0112] S82, Bootloader initializes the hardware of the device, which includes connecting to the universal asynchronous receiver-transmitter UART, the general-purpose input and output port GPIO, the controller area network CAN and the memory Flash interface;

[0113] S83, after initializing the hardware, the Bootloader checks whether there is an upgrade flag; the upgrade flag is usually used to indicate whether there is a new software version that needs to be installed on the device; if the upgrade flag is detected, the upgrade process is entered; if not detected, the existing application is directly run. In addition, EMU maintains a version list in the storage management,

[0114] Record currently available software versions and their status, such as currently running, to be upgraded, historical versions, etc.;

[0115] S84, if the upgrade mark is detected, the subsystem first stops the application software and enters the Bootloader, the Bootloader first erases the update area, then writes the new software version into the update area, and updates the EMU version list at the same time, marking the new software version as a waiting state;

[0116] S85, after upgrading the update area, the Bootloader performs a cyclic redundancy check (CRC) to ensure that the written data is not damaged; this verification process is repeated until the data is confirmed to be correct. If the verification fails, EMU can choose to roll back to the previous stable version and mark the current upgrade as failed;

[0117] S86, run app or clear app area: If no upgrade mark is detected, or the upgrade process has been completed and the data verification is correct, the Bootloader runs the existing application; if it is detected that an upgrade is required and only the software is upgraded instead of updating hardware and software at the same time, it is necessary to clear the application area first, and then copy the updated update area to the application area;

[0118] S87, copy update to app area: After clearing the application area, the Bootloader copies the contents of the updated update area to the application area so that the new software version can be executed. At the same time, the EMU updates the version list.

[0119] Mark the new software version as currently running;

[0120] S88, finally, the Bootloader clears the upgrade flag to indicate that the upgrade process has been completed. The EMU also maintains an upgrade history to track the results and status of each upgrade to provide a reference for future rollback or debugging.

[0121] S9, after the subsystem software is successfully updated, the upgrade result is fed back to EMU; EMU uploads the result to the cloud or local server.

[0122] The microgrid system software OTA upgrade method based on edge computing EMU of the present invention is an innovative technical solution, which significantly improves the upgrade efficiency and security of the microgrid system. By utilizing the ability of EMU to directly process data, the method effectively reduces the need to transmit data to the cloud, thereby reducing the burden on the cloud server and achieving efficient execution of OTA upgrades. At the same time, the use of mechanisms such as encrypted firmware storage, security authentication and decryption ensures the protection of data security and technical secrets during the upgrade process, effectively preventing the risk of malicious attacks and data tampering.

[0123] The multi-version storage capability of the edge computing energy management unit EMU of the present invention combined with the Bootloader mechanism of the subsystem provides a flexible OTA upgrade strategy for the microgrid system, including version selection and rollback functions to adapt to different scenarios and needs. The application of differential upgrade and breakpoint resume technology ensures the reliability of the upgrade process, and the upgrade can be successfully completed even in an unstable network environment. These advantages together constitute the core competitiveness of the microgrid system software OTA upgrade method based on the edge computing energy management unit EMU, giving it a significant advantage in the field of software upgrades for microgrid systems.

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

Claims

1. A microgrid system software OTA upgrade method based on edge computing energy management unit EMU, characterized in that: It includes the following steps: S1, deploy edge computing-based energy management unit EMU devices in the microgrid system as the on-site OTA upgrade center; S2, storing the encryption software of each subsystem of the microgrid system in the EMU; S3, deploying a boot loader in each subsystem of the microgrid system; S4, initiate an OTA upgrade request from the cloud or local server, specify the subsystem file to be upgraded, the target software version and the verification file, and send the upgrade request; S5, the cloud or local server generates a differential upgrade package patch PATCH according to the target version and the current version of the subsystem; the differential upgrade package only contains the difference data between the two versions; S6, after receiving the OTA upgrade request, EMU first performs security authentication to ensure that the request comes from a legitimate source. After the authentication is passed, EMU decrypts the target encrypted firmware and receives the differential upgrade package after confirmation, which can be continued from the breakpoint; S7, EMU generates a complete upgrade package based on the differential upgrade package and the current version, interacts with the server, verifies the integrity of the generated complete upgrade package, and then transmits it to the subsystem; S8, after receiving the upgrade package, the subsystem's Bootloader decrypts and verifies it, and executes the subsystem application software update operation; writes the new version of the software into the corresponding storage area, and updates the system's startup configuration. The EMU saves the subsystem's historical version for easy rollback; S9, after the subsystem software is successfully updated, the upgrade result is fed back to EMU; EMU uploads the result to the cloud or local server.

2. The microgrid system software OTA upgrade method based on edge computing energy management unit EMU according to claim 1 is characterized in that: The specific process of step S5 includes: S51, preparation stage; S511, clarify the current version and target version of the subsystem; S512, obtaining or developing a tool for generating a differential upgrade package; S52, file comparison and difference extraction S521, file traversal: traverse all files in the target version file system and compare them with the current version file system; S522, difference identification: using a difference algorithm to identify the differences in the file contents between the two versions, including the addition, deletion, and modification of files; S523, difference packaging: packaging the identified difference data into a differential upgrade package PATCH package, which contains all the difference information required to upgrade the current version to the target version; S53, differential packet generation and verification; S531, differential package generation: using a differential package generation tool, input the current version file, the target version file and the differential package storage location information to generate a differential package file; S532, verify the differential package: after generating the differential package, perform verification to ensure the correctness and integrity of the differential package; if the verification succeeds, deploy it; if the verification fails, check for errors and regenerate the differential package; S54, deployment and notification; S541, deploying the differential package: deploying the generated differential package to a specified storage location; S542, notify the device: notify the EMU through the cloud or other communication methods that a new differential upgrade package is available.

3. The microgrid system software OTA upgrade method based on edge computing energy management unit EMU according to claim 1 is characterized in that: The specific process of step S6 includes: S61, preparation stage; S611, confirm the version: ensure that the current version and the target version of the subsystem are known, so as to confirm the differential upgrade package to be transmitted; S612, check the network: ensure that the transmission channel is stable and available to facilitate breakpoint resuming; S613, prepare a differential upgrade package: ensure that the differential upgrade package has been correctly generated and saved in a specified storage location; S62, establishing connection and initialization; S621, establish connection: EMU tries to establish connection with the cloud or local to obtain the differential upgrade package; S622, request file information: EMU sends a request to the cloud or local to obtain file information of the differential upgrade package, including file size and segment information; S623, determine the transmission strategy: determine the transmission strategy, such as segment size and number of concurrent requests, according to the file size and network conditions; S63, start transmission and resume transmission; S631, sending request: EMU sends a request to the cloud or local according to the transmission strategy, specifying the file segment to be downloaded; S632, receiving data: the cloud or local returns corresponding file segment data according to the request; S633, write file: EMU writes the received data to the local differential upgrade package file. Note that the append mode is used to ensure that the downloaded data will not be overwritten. S634, record progress: During the transmission process, EMU needs to record the amount of data downloaded and the amount of data not downloaded, so that the transmission can be continued from the last breakpoint after an interruption; S635, processing interruption: If an interruption occurs during the transmission process, the EMU saves the current transmission progress and continues the transmission after the connection is restored; S636, repeating steps: Repeat steps S631 to S635 as needed until all differential upgrade packages are downloaded.

4. The microgrid system software OTA upgrade method based on edge computing energy management unit EMU according to claim 1 is characterized in that: The specific process of step S8 includes: S81, initializes the MCU clock, Flash controller, communication interface peripherals, initializes the registers and stacks required for program operation, detects the integrity of the application program in the main partition or backup partition, and runs the corresponding program; writes the upgrade image to the update area and sets the upgrade flag; according to the restart strategy, when the system restarts next time, the Bootloader copies the update area program to the app area and clears the upgrade flag. At the same time, as the on-site OTA center, the EMU saves the currently running software version and at least one historical version in case of rollback; S82, Bootloader initializes the hardware of the device, which includes connecting to the universal asynchronous receiver-transmitter UART, the general-purpose input and output port GPIO, the controller area network CAN and the memory Flash interface; S83, after initializing the hardware, the Bootloader checks whether there is an upgrade flag; the upgrade flag is usually used to indicate whether there is a new software version that needs to be installed on the device; if the upgrade flag is detected, the upgrade process is entered; if not detected, the existing application is directly run. In addition, EMU maintains a version list in the storage management, recording the currently available software versions and their status, such as currently running, to be upgraded, historical versions, etc.; S84, if the upgrade mark is detected, the subsystem first stops the application software and enters the Bootloader, the Bootloader first erases the update area, then writes the new software version into the update area, and updates the EMU version list at the same time, marking the new software version as a waiting state; S85, after upgrading the update area, the Bootloader performs a cyclic redundancy check (CRC) to ensure that the written data is not damaged; this verification process is repeated until the data is confirmed to be correct. If the verification fails, EMU can choose to roll back to the previous stable version and mark the current upgrade as failed; S86, run app or clear app area: If no upgrade mark is detected, or the upgrade process has been completed and the data verification is correct, the Bootloader runs the existing application; if it is detected that an upgrade is required and only the software is upgraded instead of updating hardware and software at the same time, it is necessary to clear the application area first, and then copy the updated update area to the application area; S87, copy update to app area: After clearing the application area, the Bootloader copies the updated content of the update area to the application area so that the new software version can be executed. At the same time, the EMU updates the version list and marks the new software version as the current running status; S88, finally, the Bootloader clears the upgrade flag to indicate that the upgrade process has been completed. The EMU also maintains an upgrade history to track the results and status of each upgrade to provide a reference for future rollback or debugging.

Images