Online upgrading method based on embedded device
Online upgrades of avionics equipment via Ethernet solve the problems of cumbersome and potentially damaging traditional upgrade methods, enabling efficient and secure embedded device upgrades.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-24
- Publication Date
- 2026-04-03
AI Technical Summary
Traditional avionics upgrade solutions are cumbersome and may damage circuit boards, making online upgrades impossible.
Online upgrades of internal modules of embedded devices are achieved via Ethernet, including periodically acquiring software status from the host computer, selecting and verifying upgrade files, switching upgrade modes, splitting and sending upgrade file data packets, and performing FLASH erasure and hardening.
This technology enables online upgrades of internal modules of embedded devices without opening the device cover, improving upgrade efficiency and reducing the risk of device damage.
Smart Images

Figure CN121785637A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of avionics equipment upgrade technology, and more specifically, to an online upgrade method based on embedded devices. Background Technology
[0002] In the field of avionics, embedded devices consist of embedded boards and chassis. Embedded boards typically include signal processing boards (based on DSPs and FPGAs), main control boards (based on CPU modules), and AI boards (based on GPUs). Traditional upgrade solutions usually involve disassembling the chassis and then upgrading using a dedicated emulator. This method is cumbersome and may damage the boards. Summary of the Invention
[0003] The embodiments of this application provide an online upgrade method based on embedded devices. This method enables online upgrades of internal modules such as DSP, FPGA, and CPU of embedded devices via Ethernet without opening the device cover.
[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.
[0005] According to a first aspect of the embodiments of this application, an online upgrade method based on an embedded device is provided, comprising: The host computer periodically obtains the software status of the terminal device and selects the software that needs to be upgraded; The host computer selects and verifies the upgrade file based on the software that needs to be upgraded; Switch the software that needs to be upgraded to upgrade mode according to its status; The host computer sends out the description information of the upgrade file, and the terminal device performs upgrade verification based on the description information; After the upgrade verification is passed, the host computer will split the upgrade file into data packets and send them to the terminal devices; The terminal device receives the upgrade file data packet and performs cache verification; Perform FLASH erasure after successful file upgrade; After successful FLASH erasure, FLASH hardening verification is performed and then hardening is performed in blocks.
[0006] In some embodiments of this application, based on the foregoing scheme, the host computer selects and verifies the upgrade file based on the software to be upgraded, including: The host computer obtains the upgrade file name and parses the upgrade file type according to the software to be upgraded; Limit the upgrade file type and select the upgrade file; Match software based on the upgrade file name; Verify the successfully matched upgrade files and select the ones that pass the verification.
[0007] In some embodiments of this application, based on the foregoing solution, the step of switching the software that needs to be upgraded to upgrade mode according to the software status includes: The host computer sends a command to switch the upgrade mode based on the software status; The terminal device switches to upgrade mode and sends a notification to the host computer.
[0008] In some embodiments of this application, based on the foregoing scheme, the host computer sends description information of the upgrade file, and the terminal device performs upgrade verification based on the description information, including: The host computer reads the upgrade file, confirms the file description information, and sends it to the terminal device. The file description information includes: the size of the upgrade file, the number of packages split into the upgrade folder, and the data verification value of the upgrade file. The terminal device performs verification based on the file description information, including: Is the software currently in upgrade mode? If not, set the upgrade status to "upgrade failed". Does the software support online upgrades? If not, set the upgrade status to "upgrade failed". Check if the file size verification is abnormal. If so, set the upgrade status to upgrade failed. Check if the upgrade file cache failed to open. If so, set the upgrade status to "upgrade failed". When the software is in upgrade mode, supports online upgrades, and there are no errors in size verification and cache allocation has not failed, set the upgrade status to "verification passed" and return it to the host computer.
[0009] In some embodiments of this application, based on the foregoing scheme, the host computer splits the upgrade file into data packets and sends them to the terminal device, including: The host computer splits the upgrade file into multiple data packets according to the protocol. Each data packet contains a data packet sequence number and the effective data length of the data packet. After receiving the data packet, the terminal device performs the following checks: Is the software currently in upgrade mode? If not, set the upgrade status to "upgrade failed". Does the software support online upgrades? If not, set the upgrade status to "upgrade failed". If the file description information has not been received, then set the upgrade status to upgrade failed. If the data packet sequence number is not connected, then set the upgrade status to upgrade failed; Check if there is an error in the valid length of the data packet; if so, set the upgrade status to upgrade failed. Check if the length of the cached data plus the current data packet exceeds the size of the upgrade file. If so, set the upgrade status to upgrade failed. When the upgrade software is in upgrade mode, supports online upgrade, has received file description information, has connected data packet sequence numbers, has no errors in the effective length of data packets, and the length of the cached data plus the current data packet does not exceed the size of the upgrade file, set the upgrade status to "verification passed" and send feedback to the host computer.
[0010] In some embodiments of this application, based on the foregoing scheme, the terminal device receives the upgrade file data packet and performs cache verification, including: After receiving the last upgrade file data packet, the terminal device performs an upgrade file cache verification calculation and compares it with the verification information of the previously received upgrade file description information. If the comparison fails, a verification error is reported.
[0011] In some embodiments of this application, based on the aforementioned scheme, after successful FLASH erasure, FLASH hardening verification and block-by-block hardening are performed, including: After the FLASH is successfully erased on the terminal device, the FLASH hardening verification process begins. The terminal device hardens the FLASH in blocks, and reports the progress after N hardening attempts. If the hardening fails or the verification of the hardening result fails, a Flash hardening verification error is reported, where N is a positive integer greater than 1.
[0012] The technical solution of this application enables online upgrades of all modules inside an embedded device via an Ethernet bus without opening the device cover.
[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description
[0014] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings: Figure 1 A flowchart illustrating an online upgrade method based on an embedded device according to an embodiment of this application is shown. Figure 2 A flowchart of an online upgrade system according to an embodiment of this application is shown; Figure 3 A flowchart illustrating a software state acquisition process according to an embodiment of this application is shown; Figure 4 A flowchart of the upgrade file selection verification process according to one embodiment of this application is shown; Figure 5 A flowchart illustrating the upgrade mode switching process according to an embodiment of this application is shown; Figure 6 A flowchart illustrating the process of distributing upgrade document description information according to an embodiment of this application is shown; Figure 7 A flowchart illustrating the upgrade file receiving and verification process according to an embodiment of this application is shown; Figure 8 A flowchart illustrating the upgrade software FLASH erasure process according to one embodiment of this application is shown; Figure 9 The process of upgrading software FLASH firmware and verification according to one embodiment of this application is illustrated. Detailed Implementation
[0015] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.
[0016] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.
[0017] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.
[0018] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.
[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of the embodiments of this invention 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 invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.
[0020] The following detailed description of some embodiments of this application will be provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0021] See Figure 1 The diagram illustrates a flowchart of an online upgrade method based on an embedded device according to an embodiment of this application.
[0022] It should be noted that this method is implemented through an online upgrade system, which consists of four layers: a host computer, a server (DSP integrated control module), routing devices (all software supporting the online upgrade protocol), and terminal devices (all software supporting the online upgrade protocol). Data exchange is achieved through a standardized protocol, such as... Figure 2 As shown: 1) Host computer: Responsible for upgrading file verification, software status detection, upgrading mode switching, upgrading package distribution, upgrading progress display, upgrading fault reminders, etc.
[0023] 2) Routing devices: All terminal devices are routing devices. All DSP terminal devices support routing and forward data according to the parsed data receiving address. All FPGA terminal devices support routing and forward data between modules according to the DSP control of this module.
[0024] 3) Terminal devices: All DSP terminal devices support the upgrade operation and support three program storage methods: bootloader, backup program and application program; all FPGA terminal devices support the MultiBoot function, which can roll back to the Golden image (factory backup image) when the upgrade fails, and supports the DSP to erase, read and write data at specific addresses in Flash.
[0025] like Figure 1 As shown, an online upgrade method based on an embedded device is illustrated, specifically including steps S100 to S800.
[0026] refer to Figure 1 In step S100, the host computer periodically obtains the software status of the terminal device and selects the software that needs to be upgraded.
[0027] like Figure 3 As shown, the host computer reads the configuration file through the integrated control module to obtain upgrade software information; the integrated control device obtains the software status of the terminal device through the routing device and feeds it back to the host computer.
[0028] Continue to refer to Figure 1 In step S200, the host computer selects the upgrade file based on the software that needs to be upgraded and performs verification.
[0029] In some feasible embodiments, based on the foregoing scheme, such as Figure 4 As shown, the host computer selects and verifies the upgrade file based on the software that needs to be upgraded, including: The host computer obtains the upgrade file name and parses the upgrade file type according to the software to be upgraded; Limit the upgrade file type and select the upgrade file; Match software based on the upgrade file name; Verify the successfully matched upgrade files and select the ones that pass the verification.
[0030] Continue to refer to Figure 1 Step S300: Switch the software that needs to be upgraded to upgrade mode according to the software status.
[0031] In some feasible embodiments, based on the foregoing scheme, such as Figure 5 As shown, switching the software that needs to be upgraded to upgrade mode according to its software status includes: The host computer sends a command to switch the upgrade mode based on the software status; The terminal device switches to upgrade mode and sends a notification to the host computer.
[0032] Continue to refer to Figure 1 In step S400, the host computer sends the description information of the upgrade file, and the terminal device performs upgrade verification based on the description information.
[0033] In some feasible embodiments, based on the foregoing scheme, such as Figure 6 As shown, the host computer sends upgrade file description information, and the terminal device performs upgrade verification based on the description information, including: The host computer reads the upgrade file, confirms the file description information, and sends it to the terminal device. The file description information includes: the size of the upgrade file, the number of packages split into the upgrade folder, and the data verification value of the upgrade file. The terminal device performs verification based on the file description information, including: Is the software currently in upgrade mode? If not, set the upgrade status to "upgrade failed". Does the software support online upgrades? If not, set the upgrade status to "upgrade failed". Check if the file size verification is abnormal. If so, set the upgrade status to upgrade failed. Check if the upgrade file cache failed to open. If so, set the upgrade status to "upgrade failed". When the software is in upgrade mode, supports online upgrades, and there are no errors in size verification and cache allocation has not failed, set the upgrade status to "verification passed" and return it to the host computer.
[0034] Continue to refer to Figure 1 In step S500, after the upgrade verification is passed, the host computer splits the upgrade file into data packets and sends them to the terminal device.
[0035] In some feasible embodiments, based on the foregoing scheme, the host computer splits the upgrade file into data packets and sends them to the terminal device, including: The host computer splits the upgrade file into multiple data packets according to the protocol. Each data packet contains a data packet sequence number and the effective data length of the data packet. After receiving the data packet, the terminal device performs the following checks: Is the software currently in upgrade mode? If not, set the upgrade status to "upgrade failed". Does the software support online upgrades? If not, set the upgrade status to "upgrade failed". If the file description information has not been received, then set the upgrade status to upgrade failed. If the data packet sequence number is not connected, then set the upgrade status to upgrade failed; Check if there is an error in the valid length of the data packet; if so, set the upgrade status to upgrade failed. Check if the length of the cached data plus the current data packet exceeds the size of the upgrade file. If so, set the upgrade status to upgrade failed. When the upgrade software is in upgrade mode, supports online upgrade, has received file description information, has connected data packet sequence numbers, has no errors in the effective length of data packets, and the length of the cached data plus the current data packet does not exceed the size of the upgrade file, set the upgrade status to "verification passed" and send feedback to the host computer.
[0036] Continue to refer to Figure 1 In step S600, the terminal device receives the upgrade file data packet and performs cache verification.
[0037] In some feasible embodiments, based on the foregoing scheme, such as Figure 7 As shown, the terminal device receives the upgrade file data packet and performs cache verification, including: After receiving the last upgrade file data packet, the terminal device performs an upgrade file cache verification calculation and compares it with the verification information of the previously received upgrade file description information. If the comparison fails, a verification error is reported.
[0038] Continue to refer to Figure 1 Step S700: After the file upgrade is successful, perform FLASH erasure.
[0039] like Figure 8 As shown, after the terminal device successfully verifies the upgrade file, it enters the FLASH erasure process. The terminal device erases a certain amount of data and then reports the progress. If the erasure fails, a "Flash erasure failed" message is sent.
[0040] Continue to refer to Figure 1 In step S800, after the FLASH is successfully erased, the FLASH curing verification is performed and the FLASH is cured in blocks.
[0041] In some feasible embodiments, based on the foregoing scheme, such as Figure 9 As shown, after the FLASH is successfully erased, a FLASH curing verification is performed, followed by block curing, including: After the FLASH is successfully erased on the terminal device, the FLASH hardening verification process begins. The terminal device hardens the FLASH in blocks, and reports the progress after N hardening attempts. If the hardening fails or the verification of the hardening result fails, a Flash hardening verification error is reported, where N is a positive integer greater than 1.
[0042] Other embodiments of this application will readily conceive of by those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.
Claims
1. An online upgrade method based on embedded devices, characterized in that, include: The host computer periodically obtains the software status of the terminal device and selects the software that needs to be upgraded; The host computer selects and verifies the upgrade file based on the software that needs to be upgraded; Switch the software that needs to be upgraded to upgrade mode according to its status; The host computer sends out the description information of the upgrade file, and the terminal device performs upgrade verification based on the description information; After the upgrade verification is passed, the host computer will split the upgrade file into data packets and send them to the terminal devices; The terminal device receives the upgrade file data packet and performs cache verification; Perform FLASH erasure after successful file upgrade; After successful FLASH erasure, FLASH hardening verification is performed and then hardening is performed in blocks.
2. The method according to claim 1, characterized in that, The host computer selects and verifies the upgrade file based on the software that needs to be upgraded, including: The host computer obtains the upgrade file name and parses the upgrade file type according to the software to be upgraded; Limit the upgrade file type and select the upgrade file; Match software based on the upgrade file name; Verify the successfully matched upgrade files and select the ones that pass the verification.
3. The method according to claim 1, characterized in that, The step of switching the software that needs to be upgraded to upgrade mode according to its software status includes: The host computer sends a command to switch the upgrade mode based on the software status; The terminal device switches to upgrade mode and sends a notification to the host computer.
4. The method according to claim 1, characterized in that, The host computer sends an upgrade file description, and the terminal device performs upgrade verification based on the description information, including: The host computer reads the upgrade file, confirms the file description information, and sends it to the terminal device. The file description information includes: the size of the upgrade file, the number of packages split into the upgrade folder, and the data verification value of the upgrade file. The terminal device performs verification based on the file description information, including: Is the software currently in upgrade mode? If not, set the upgrade status to "upgrade failed". Does the software support online upgrades? If not, set the upgrade status to "upgrade failed". Check if the file size verification is abnormal. If so, set the upgrade status to upgrade failed. Check if the upgrade file cache failed to open. If so, set the upgrade status to "upgrade failed". When the software is in upgrade mode, supports online upgrades, and there are no errors in size verification and cache allocation has not failed, set the upgrade status to "verification passed" and return it to the host computer.
5. The method according to claim 1, characterized in that, The host computer splits the upgrade file into data packets and sends them to the terminal device, including: The host computer splits the upgrade file into multiple data packets according to the protocol. Each data packet contains a data packet sequence number and the effective data length of the data packet. After receiving the data packet, the terminal device performs the following checks: Is the software currently in upgrade mode? If not, set the upgrade status to "upgrade failed". Does the software support online upgrades? If not, set the upgrade status to "upgrade failed". If the file description information has not been received, then set the upgrade status to upgrade failed. If the data packet sequence number is not connected, then set the upgrade status to upgrade failed; Check if there is an error in the valid length of the data packet; if so, set the upgrade status to upgrade failed. Check if the length of the cached data plus the current data packet exceeds the size of the upgrade file. If so, set the upgrade status to upgrade failed. When the upgrade software is in upgrade mode, supports online upgrade, has received file description information, has connected data packet sequence numbers, has no errors in the effective length of data packets, and the length of the cached data plus the current data packet does not exceed the size of the upgrade file, set the upgrade status to "verification passed" and send feedback to the host computer.
6. The method according to claim 1, characterized in that, The terminal device receives the upgrade file data packet and performs cache verification, including: After receiving the last upgrade file data packet, the terminal device performs an upgrade file cache verification calculation and compares it with the verification information of the previously received upgrade file description information. If the comparison fails, a verification error is reported.
7. The method according to claim 1, characterized in that, After the FLASH is successfully erased, a FLASH hardening verification is performed, followed by block hardening, including: After the FLASH is successfully erased on the terminal device, the FLASH hardening verification process begins. The terminal device hardens the FLASH in blocks, and reports the progress after N hardening attempts. If the hardening fails or the verification of the hardening result fails, a Flash hardening verification error is reported, where N is a positive integer greater than 1.