Onboard software online upgrading method compatible with different bus interfaces

Abstract

The invention discloses an airborne software online upgrading method compatible with different bus interfaces, which belongs to the technical field of airborne embedded software and comprises the following steps: providing two types of bus interfaces; according to the method, the loading identifier is used as a basis for whether loading is executed or not, the loading information source is identified according to the loading source identifier, the product software preferentially responds to a loading demand from a user, and the other loading interface is shielded when loading is executed, so that the independence of the loading interface is ensured; performing consistency judgment on the CSCI ID of the loaded target code and the name of the target code to ensure the correctness of the loaded target code; and after the target code is loaded and verified successfully, the program skips to the updated application program, and the loading identifier and the loading source identifier are cleared in the application program, so that the updated application program can normally run, other product software is prevented from being mistakenly loaded, and the method has the advantages of high reliability and strong robustness.

Description

Technical Field

[0001] This application relates to the field of airborne embedded software technology, and in particular to an online upgrade method for airborne software compatible with different bus interfaces. Background Technology

[0002] Airborne products typically require frequent software updates and iterative upgrades based on user flight test needs. Traditional offline software upgrade methods require product relocation and disassembly, additional power supply, complex external maintenance processes, and low software upgrade efficiency. To improve the efficiency of airborne product software upgrades and achieve unified management and distributed upgrades for different airborne product software, users usually adopt airborne bus interfaces (such as the 1394B bus), specify a unified loading protocol, and utilize a platform to manage the system's bus network to achieve in-situ software upgrades for each airborne product. For airborne product manufacturers, to improve the efficiency of internal and external maintenance and troubleshooting of product software, they typically use low-cost bus interfaces (such as the RS-422A bus) to achieve in-situ software upgrade functionality.

[0003] Currently, commonly used online software upgrade methods are limited and can only meet the maintenance needs of airborne product manufacturers, failing to simultaneously meet the unified loading requirements of users' machines. Summary of the Invention

[0004] To address the aforementioned shortcomings in the existing technology, this application provides an online software upgrade method compatible with different bus interfaces, which solves the problem that existing online software upgrade methods can only meet the maintenance needs of airborne product manufacturers and cannot simultaneously meet the unified loading requirements of user machines.

[0005] To achieve the aforementioned objectives, the technical solution adopted in this application is as follows: This application provides an online upgrade method for airborne software compatible with different bus interfaces, including: S1: Execute the BOOT bootloader, read the online loading identifier and loading source identifier, and determine whether the synchronization header and checksum are correct. If the synchronization header and checksum are correct, proceed to S2; otherwise, proceed to S3. S2: Determine whether the online loading identifier and the loading source identifier are both valid. If invalid, proceed to S3; if valid, proceed to S5. S3: Execute the application to perform normal mode tasks, determine whether a valid online loading command has been received. If a valid online loading command has been received, set the online loading flag to AA55AA55H and proceed to S4; otherwise, continue executing S3. S4: Identify the source of the loading command. If the loading command is sent by the flight control computer via the 1394B bus, set the loading source identifier to 11H and stop receiving commands via the RS-422A bus, then proceed to S5. If the loading command is sent by the maintenance equipment via the RS-422A bus, set the loading source identifier to 22H and stop receiving loading commands via the 1394B bus, then proceed to S5. S5: Combine the online loading identifier and loading source identifier into a package, add a synchronization header and checksum, write it into the product NVM, and perform a CPU software reset; S6: Execute the online loading program to obtain the loading source identifier information from the product NVM. If the obtained data synchronization header and checksum are correct, determine whether the loading source identifier is 11H. If yes, proceed to S7; otherwise, proceed to S8. S7: Receive the execution loading command and target code information sent by the flight control computer via the 1394B bus, and determine whether the execution loading command is valid. If the execution loading command is valid, proceed to S9; otherwise, continue executing S7. S8: Receive the execution loading command and target code information sent by the ground maintenance equipment via the RS-422A bus, and determine whether the execution loading command is valid. If the execution loading command is valid, proceed to S9; otherwise, continue to execute S8. S9: Receive target code data. When receiving the first frame of target code information, determine whether the first 16 bytes of the target code are the product software configuration item CSCI ID and target code name to confirm the correctness of loading the target code. If the CSCI ID and target code name are consistent with the product information, continue to receive subsequent target code data and proceed to S10; otherwise, proceed to S6, report the target code information error, and reload. S10: Verify the complete target code information of the received product. If the target code passes the verification, report that the target code transmission was successful and proceed to S11; otherwise, return to S6, report the transmission failure, and reload. S11: Calculate the number of FLASH sectors to be erased based on the length information of the received target code, and perform FLASH sector erasure. After the FLASH sector erasure is completed, write the received target code into the FLASH. S12: Read the target code data back from FLASH and compare it with the target code received through the bus. If the target code information is consistent, the target code verification is considered to have passed. Execute the program jump instruction to jump to the updated application program and enter S13; otherwise, report the target code verification failure, return to S6, and reload. S13: The application determines whether it has received a valid instruction to clear the loading identifier and loading source identifier. If a valid instruction to clear the identifier is received, the online loading identifier and loading source identifier are cleared; otherwise, the updated application continues to execute.

[0006] Furthermore, the determination of whether the online loading identifier and the loading source identifier are both valid includes: If the online loading identifier is AA55AA55H and the loading source identifier is 11H or 22H, both are considered valid; otherwise, they are considered invalid.

[0007] Furthermore, the determination of whether a valid online loading command has been received includes: If the received online loading command changes from invalid 0 to valid 1 and the valid 1 lasts for at least 1 second, then a valid online loading command is considered to have been received; otherwise, a valid online loading command is considered not to have been received.

[0008] Furthermore, determining whether the execution of the loading command is valid includes: If the execution of the load command changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second, then the execution of the load command is considered valid; otherwise, the execution of the load command is considered invalid.

[0009] Furthermore, the first 16 bytes of the target code information are software configuration item ID 500365H and software target code name 107.bin.

[0010] Furthermore, the verification calculation of the complete target code information of the received product includes: CRC cyclic redundancy check is used for verification calculation.

[0011] Furthermore, the method for determining the validity of the identifier clearing instruction is as follows: the received identifier clearing instruction changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second.

[0012] The beneficial effects of this application are: This application provides an online software upgrade method for airborne systems compatible with different bus interfaces. It meets both the unified loading requirements of users and the maintenance and troubleshooting needs of external product manufacturers, offering advantages such as high flexibility and efficiency in software upgrades. This method is compatible with two types of bus interfaces, providing significant practical application value and economic benefits. It uses a loading identifier as the basis for determining whether to execute a loading request, and identifies the loading information source based on the loading source identifier. The product software prioritizes responding to loading requests from users, and masks the other loading interface during loading, ensuring its independence. Simultaneously, the method performs a consistency comparison of the target code information. After successful target code loading verification, it executes the updated application via a jump instruction. The loading identifier and loading source identifier are cleared within the application to ensure the updated application runs normally, preventing accidental loading of other product software that could "brick" the system and prevent the product from starting normally. This method offers high reliability and robustness. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0014] Figure 1 This is a flowchart illustrating an online software upgrade method compatible with different bus interfaces, provided as an embodiment of this application.

[0015] Figure 2 This is a schematic diagram of a program storage partition provided in an embodiment of this application. Detailed Implementation

[0016] 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 some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0017] This application provides an online upgrade method for airborne software compatible with different bus interfaces. This method can be found in [reference needed]. Figure 1 , Figure 1 The diagram shown is a flowchart illustrating an online software upgrade method compatible with different bus interfaces provided in this application embodiment. In this method, the program storage partition can be found in... Figure 2 The method includes: S1: After the product is powered on normally, the BOOT boot program is executed. The BOOT boot program obtains the software online loading identifier and loading source identifier from the product's non-volatile memory, and determines whether the obtained data synchronization header and checksum are correct. If the synchronization header and checksum are correct, it continues to determine whether the online loading identifier and loading source identifier are valid at the same time; otherwise, the normal application program is executed.

[0018] S2: Determine whether the online loading identifier and the loading source identifier are both valid. If invalid, execute the normal application; if valid, execute the loading program. The validity determination method is as follows: if the online loading identifier is AA55AA55H and the loading source identifier is 11H or 22H, both are considered valid; otherwise, they are considered invalid.

[0019] S3: Execute the application in normal mode. Within the application, it continuously checks whether a valid online loading command has been received. If a valid online loading command is received, the online loading flag is set to AA55AA55H, and the loading source flag is checked again. If invalid, the normal application is executed. The method for determining the validity of the online loading command is as follows: if the received online loading command changes from invalid 0 to valid 1, and the valid 1 status lasts for at least 1 second, then a valid online loading command is considered received; otherwise, a valid online loading command is considered not received.

[0020] S4: Identify the source of the loading command. If the loading command is sent by the flight control computer via the 1394B bus, set the loading source identifier to 11H and stop receiving commands via the RS-422A bus. Then proceed to step S5. If the loading command is sent by the maintenance equipment via the RS-422A bus, set the loading source identifier to 22H and stop receiving loading commands via the 1394B bus. Write the loading identifier and loading source identifier into the NVM.

[0021] S5: Package the online loading identifier and loading source identifier, add a synchronization header and checksum, write it into the product NVM, and perform a CPU software reset.

[0022] S6: Execute the online loading program to obtain the loading source identification information from the product NVM. If the obtained data synchronization header and checksum are correct, determine whether the loading source identification is 11H. If yes, proceed to step S7; otherwise, proceed to step S8.

[0023] S7: Receive the execution loading command and target code information sent by the flight control computer via the 1394B bus. If the execution loading command is valid, proceed to step S9; otherwise, proceed to step S7. The method for judging the validity of the execution loading command is: the execution loading command changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second. The first 16 bytes of the target code information are the software configuration item ID (CSCI ID) 500365H and the software target code name 107.bin.

[0024] S8: Receive the execution loading command and target code information sent by the ground maintenance equipment via RS-422A bus. If the execution loading command is valid, proceed to step S9; otherwise, proceed to step S8. The method for judging the validity of the execution loading command is: the execution loading command changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second. The first 16 bytes of the target code information are the software configuration item ID (CSCI ID) 500365H and the software target code name 107.bin.

[0025] S9: Execute target code data reception. When receiving the first frame of target code information, determine whether the first 16 bytes of the target code are the CSCI ID and target code name of this product to confirm the correctness of loading the target code. If the CSCI ID and target code name are consistent with the product information, continue to receive subsequent target code data and execute step S10. Otherwise, return to step S6, report the target code information error, and re-execute loading.

[0026] S10: Perform verification calculation on the complete target code information of the received product. The verification calculation method is CRC cyclic redundancy check. If the target code passes the verification, report that the target code transmission is successful and execute step S11. Otherwise, return to step S6, report the transmission failure, and re-execute loading.

[0027] S11: Calculate the number of FLASH sectors to be erased based on the length information of the received target code, and perform FLASH sector erasure. After the FLASH sector erasure is completed, write the received target code into the FLASH and execute step S12.

[0028] S12: Read the target code data back from FLASH and compare it with the target code received through the bus. If the target code information is consistent, the target code verification is considered to be successful. Execute the program jump instruction to jump to the updated application and execute step S13. Otherwise, report the target code verification failure and return to step S6 to reload.

[0029] S13: The application determines whether it has received a valid instruction to clear the load identifier and the load source identifier. If a valid identifier clearing instruction is received, the NVM space data storing the identifier is cleared to 0. Otherwise, the updated application continues to execute. The method for determining the validity of the identifier clearing instruction is: the received identifier clearing instruction changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second.

[0030] This application is compatible with two different bus interfaces, satisfying both the user's unified loading requirements for onboard software, facilitating unified management and distributed upgrades, and the product manufacturer's low-cost bus loading needs, simplifying external maintenance and troubleshooting. It offers advantages such as high flexibility and efficiency in software upgrades, demonstrating strong practical application value and significant economic benefits. Furthermore, it identifies the loading information source through a loading source identifier, prioritizing responses to user loading command requests. When loading via one bus, it will not respond to loading requests from another bus interface, preventing bus data conflicts and ensuring the independence of the software loading bus interface, resulting in high reliability. Simultaneously, during loading, a consistency comparison of the target code information, including the target code CSCI ID and target code name, is performed. Program solidification is only executed if the target code information matches, preventing the product from becoming unusable due to mistakenly loading other product software. Moreover, after successful target code loading verification, a jump instruction executes the updated application, clearing the loading identifier and loading source identifier within the application to ensure the updated application runs normally, preventing the product from becoming unusable due to mistakenly loading other product software, thus offering high reliability and robustness.

[0031] It should be noted that those skilled in the art will recognize that the embodiments described herein are for the purpose of helping readers understand the principles of this application, and should be understood as not limiting the scope of protection of this application to such specific statements and embodiments. Those skilled in the art can make various other specific modifications and combinations based on the technical teachings disclosed in this application without departing from the essence of this application, and these modifications and combinations are still within the scope of protection of this application.

Claims

1. A method for online airborne software upgrade compatible with different bus interfaces, characterized in that, include: S1: Execute the BOOT bootloader, read the online loading identifier and loading source identifier, and determine whether the synchronization header and checksum are correct. If the synchronization header and checksum are correct, proceed to S2; otherwise, proceed to S3. S2: Determine whether the online loading identifier and the loading source identifier are both valid. If invalid, proceed to S3; if valid, proceed to S5. S3: Execute the application to perform normal mode tasks, determine whether a valid online loading command has been received. If a valid online loading command has been received, set the online loading flag to AA55AA55H and proceed to S4; otherwise, continue executing S3. S4: Identify the source of the loading command. If the loading command is sent by the flight control computer via the 1394B bus, set the loading source identifier to 11H and stop receiving commands via the RS-422A bus, then proceed to S5. If the loading command is sent by the maintenance equipment via the RS-422A bus, set the loading source identifier to 22H and stop receiving loading commands via the 1394B bus, then proceed to S5. S5: Combine the online loading identifier and loading source identifier into a package, add a synchronization header and checksum, write it into the product NVM, and perform a CPU software reset; S6: Execute the online loading program to obtain the loading source identifier information from the product NVM. If the obtained data synchronization header and checksum are correct, determine whether the loading source identifier is 11H. If yes, proceed to S7; otherwise, proceed to S8. S7: Receive the execution loading command and target code information sent by the flight control computer via the 1394B bus, and determine whether the execution loading command is valid. If the execution loading command is valid, proceed to S9; otherwise, continue executing S7. S8: Receive the execution loading command and target code information sent by the ground maintenance equipment via the RS-422A bus, and determine whether the execution loading command is valid. If the execution loading command is valid, proceed to S9; otherwise, continue to execute S8. S9: Receive target code data. When receiving the first frame of target code information, determine whether the first 16 bytes of the target code are the product software configuration item CSCI ID and target code name to confirm the correctness of loading the target code. If the CSCI ID and target code name are consistent with the product information, continue to receive subsequent target code data and proceed to S10. Otherwise, proceed to S6, report an error in the target code information, and reload; S10: Verify the complete target code information of the received product. If the target code passes the verification, report that the target code transmission was successful and proceed to S11. Otherwise, return to S6, report the transmission failure, and reload; S11: Calculate the number of FLASH sectors to be erased based on the length information of the received target code, and perform FLASH sector erasure. After the FLASH sector erasure is completed, write the received target code into the FLASH. S12: Read the target code data back from FLASH and compare it with the target code received through the bus. If the target code information is consistent, the target code verification is considered to be successful. Execute the program jump instruction to jump to the updated application program and enter S13. Otherwise, report the target code verification failure, return to S6, and reload; S13: The application determines whether it has received a valid instruction to clear the loading identifier and loading source identifier. If a valid instruction to clear the identifier is received, the online loading identifier and loading source identifier are cleared; otherwise, the updated application continues to execute.

2. The airborne software online upgrade method compatible with different bus interfaces according to claim 1, characterized in that, The determination of whether the online loading identifier and the loading source identifier are both valid includes: If the online loading identifier is AA55AA55H and the loading source identifier is 11H or 22H, both are considered valid; otherwise, they are considered invalid.

3. The method for online airborne software upgrade compatible with different bus interfaces according to claim 1, characterized in that, The determination of whether a valid online loading command has been received includes: If the received online loading command changes from invalid 0 to valid 1 and the valid 1 lasts for at least 1 second, then a valid online loading command is considered to have been received; otherwise, a valid online loading command is considered not to have been received.

4. The airborne software online upgrade method compatible with different bus interfaces according to claim 1, characterized in that, The determination of whether the execution of the loading command is valid includes: If the execution of the load command changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second, then the execution of the load command is considered valid; otherwise, the execution of the load command is considered invalid.

5. The method for online upgrade of airborne software compatible with different bus interfaces according to claim 1, characterized in that, The first 16 bytes of the target code information are the software configuration item ID 500365H and the software target code name 107.bin.

6. The airborne software online upgrade method compatible with different bus interfaces according to claim 1, characterized in that, The verification calculation of the complete target code information of the received product includes: CRC cyclic redundancy check is used for verification calculation.

7. The method for online upgrade of airborne software compatible with different bus interfaces according to claim 1, characterized in that, The method for determining the validity of the identifier clearing instruction is as follows: the received identifier clearing instruction changes from invalid 0 to valid 1, and the valid 1 lasts for at least 1 second.

Images