Embedded software remote upgrading method based on CAN bus

Abstract

The invention discloses an embedded software remote upgrading method based on a CAN bus, and relates to the technical field of computers. Comprising the steps that S1, an upper computer sends an upgrading instruction to a specified lower computer through a CAN bus, and the upgrading instruction comprises an equipment serial number of the specified lower computer; s2, if the corresponding lower computer receives the upgrading instruction, an upgrading state entering response instruction is sent back to the upper computer, an upgrading type instruction is waited, and the upgrading type instruction comprises a program upgrading instruction and a parameter upgrading instruction; and S3, if the corresponding lower computer receives the program upgrading instruction, executing a program upgrading process, and if the lower computer receives the parameter upgrading instruction, executing a parameter upgrading process. The method and the device are used for solving the core problems of low upgrading efficiency, high security risk, real-time conflict and the like of military embedded equipment in a complex battlefield environment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method for remotely upgrading embedded software based on a CAN bus. Background Technology

[0002] With the continued tension in the international situation, the application of domestically produced SOC chips in the military field has shown a significant growth trend. Currently, military computer control systems generally adopt domestically produced embedded modules such as ARM and DSP. Among them, the software update technology based on ARM architecture mainly includes three modes: ICP (In-System Programming), ISP (In-System Programming), and IAP (In-Application Programming).

[0003] Traditional update technologies have significant limitations: ICP requires an in-circuit emulator to connect to the SOC chip for programming, while ISP relies on the microcontroller's built-in BootLoader program. Both require physical contact operations, such as connecting download cables and setting jumper caps. When dealing with sealed circuit boards or devices installed in confined spaces, these mechanical operations are not only difficult to implement but may also affect system stability.

[0004] Some remote upgrade solutions rely on public Wi-Fi / 4G / 5G networks, but military scenarios often involve environments with electromagnetic shielding, no public network coverage, or severe signal interference, making public network communication prone to interruption. Furthermore, wireless signals are easily intercepted or interfered with by the enemy, posing a risk of information leakage. In complex electromagnetic environments, traditional communication protocols (such as UART and Ethernet) are susceptible to interference, leading to the loss or corruption of upgrade data packets. The lack of efficient verification and recovery mechanisms may render equipment unusable. After an upgrade failure, military equipment needs to be quickly restored to a usable state, but existing technologies often employ a single storage area design, making version rollback impossible and potentially affecting the continuity of combat missions. Poor device heterogeneity and compatibility are also issues. Military embedded devices come from different manufacturers with fragmented communication protocols (such as proprietary CAN protocols and custom instruction sets), making it difficult for existing solutions to uniformly manage multi-node upgrade processes. Summary of the Invention

[0005] The purpose of this application is to provide a remote upgrade method for embedded software based on CAN bus, in order to solve the core problems faced by military embedded equipment in complex battlefield environments, such as low upgrade efficiency, high security risks, and real-time conflicts.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] On the one hand, this application provides a method for remotely upgrading embedded software based on a CAN bus, including:

[0008] S1. The host computer sends an upgrade command to the specified slave device via the CAN bus. The upgrade command includes the device serial number of the specified slave device.

[0009] S2. If the corresponding lower-level machine receives the upgrade instruction, it sends an upgrade state response instruction back to the upper-level machine and waits for the upgrade type instruction, which includes the program upgrade instruction and the parameter upgrade instruction.

[0010] S3. If the corresponding lower-level machine receives a program upgrade instruction, it executes the program upgrade process; if the lower-level machine receives a parameter upgrade instruction, it executes the parameter upgrade process.

[0011] On the other hand, this application also provides an embedded software remote upgrade device based on a CAN bus, comprising:

[0012] The instruction sending module is used for the host computer to send an upgrade instruction to a specified slave device via the CAN bus. The upgrade instruction includes the device serial number of the specified slave device.

[0013] The instruction response module is used to send an upgrade state response instruction back to the host computer and wait for the upgrade type instruction if the corresponding lower-level machine receives an upgrade instruction. The upgrade type instruction includes a program upgrade instruction and a parameter upgrade instruction.

[0014] The upgrade execution module is used to execute the program upgrade process if the corresponding lower-level machine receives a program upgrade instruction, and to execute the parameter upgrade process if the lower-level machine receives a parameter upgrade instruction.

[0015] On the other hand, this application also provides an electronic device,

[0016] A processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the steps of the method as described in any of the preceding claims.

[0017] Based on the above technical solution, this application can achieve the following technical effects:

[0018] This application utilizes the widely used CAN bus as a carrier. By optimizing the communication protocol verification mechanism and redundancy fault-tolerant design, it further enhances the reliability of the update process while retaining the advantages of IAP technology. Actual testing shows that the firmware update success rate in complex electromagnetic environments reaches 99.97%, verification time is reduced by 40%, and version rollback functionality is supported. This effectively solves the software maintenance challenges in the full lifecycle management of military equipment, significantly reducing maintenance costs while improving system security. It provides a reusable technical path for the engineering practice of domestically produced computer control systems and has significant military application value. Attached Figure Description

[0019] Figure 1This is a schematic diagram of an embedded software remote upgrade method based on a CAN bus according to an embodiment of this application;

[0020] Figure 2 This is a topology diagram of an embedded software remote upgrade system provided in an embodiment of this application;

[0021] Figure 3 This is a flowchart of the execution of a lower-level machine program provided in an embodiment of this application;

[0022] Figure 4 This is a diagram of a Flash chip data storage strategy provided in an embodiment of this application;

[0023] Figure 5 This is a flowchart of the execution of a host computer program provided in an embodiment of this application. Detailed Implementation

[0024] The present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The advantages and features of the present application will become clearer from the following description and claims. It should be noted that the drawings are all in a very simplified form and are not to scale, and are only used to facilitate and clarify the illustration of the embodiments of the present application.

[0025] It should be noted that, in order to clearly illustrate the content of this application, several embodiments are provided to further explain the different implementations of this application. These embodiments are enumerated rather than exhaustive. Furthermore, for the sake of brevity, content mentioned in the preceding embodiments is often omitted in the following embodiments. Therefore, content not mentioned in the following embodiments can be referred to in the preceding embodiments.

[0026] Example 1

[0027] like Figure 1 The diagram shown is a schematic representation of a remote software upgrade method based on a CAN bus provided in this embodiment. It includes:

[0028] S1. The host computer sends an upgrade command to the specified slave device via the CAN bus. The upgrade command includes the device serial number of the specified slave device.

[0029] S2. If the corresponding lower-level machine receives the upgrade instruction, it sends an upgrade state response instruction back to the upper-level machine and waits for the upgrade type instruction, which includes the program upgrade instruction and the parameter upgrade instruction.

[0030] S3. If the corresponding lower-level machine receives a program upgrade instruction, it executes the program upgrade process; if the lower-level machine receives a parameter upgrade instruction, it executes the parameter upgrade process.

[0031] Furthermore, following S1, the following is also included:

[0032] If the lower-level machine does not receive the upgrade command, it reads the program data from the FLASH main application partition into memory and checks whether the program verification is correct.

[0033] If correct, execute the main program.

[0034] If incorrect, read the program data from the FLASH backup application partition into memory and determine if the program verification is correct;

[0035] If correct, execute the backup procedure.

[0036] Furthermore, before reading program data from the FLASH backup application partition into memory and determining whether the program verification is correct, the process also includes:

[0037] The data in the FLASH backup application partition is only burned once at the factory as the initial state.

[0038] Based on this, the system always maintains a stable APP application and a set of normal system parameters, so that it can quickly restore the program to a normal running state after a program upgrade failure, preventing the system from becoming unusable. At the same time, the multiple redundancy backup strategy can significantly improve the product's robustness.

[0039] Furthermore, S3 includes:

[0040] During the execution of the program upgrade protocol or parameter upgrade protocol, the lower-level machine judges the upload status frame by frame;

[0041] If the data frames are discontinuous, out of range, or there is a total check error, write failure, or upload success during the upload process, the corresponding upload status response frame will be sent back to the host computer.

[0042] Furthermore, S3 includes:

[0043] During the execution of the program upgrade protocol or parameter upgrade protocol, the lower-level machine judges the download status frame by frame;

[0044] If reading from Flash fails or the download succeeds during the download process, a corresponding download status response frame will be sent back to the host computer.

[0045] Furthermore, S2 also includes:

[0046] After the corresponding lower-level machine is powered on, it is determined whether an upgrade command has been received within 500ms;

[0047] If no upgrade command is received within 500ms, then the lower-level device has not received an upgrade command.

[0048] Furthermore, prior to S1, it also includes:

[0049] Each lower-level machine is connected to the CAN bus via a CAN interface for the transmission of commands and responses between the upper-level machine and different lower-level machines.

[0050] Based on this, the existing CAN bus topology can be used to upgrade product software and upload and download parameters. Furthermore, the protocol stack can be designed according to the characteristics of CAN frames to improve upgrade efficiency.

[0051] In summary, this method utilizes the widely used CAN bus as a carrier and, through optimized communication protocol verification mechanisms and redundant fault-tolerant design, further enhances the reliability of the update process while retaining the advantages of IAP technology. Actual testing shows that the firmware update success rate in complex electromagnetic environments increases to 99.97%, verification time is reduced by 40%, and version rollback functionality is supported. This effectively solves the software maintenance challenges in the full lifecycle management of military equipment, significantly reducing maintenance costs while improving system security. It provides a reusable technical path for the engineering practice of domestically developed computer control systems and has significant military application value.

[0052] Example 2

[0053] This embodiment provides a specific implementation method for remote upgrade of embedded software based on CAN bus.

[0054] 1. System Overall Design

[0055] The CAN bus-based embedded software remote upgrade system consists of two parts: a host computer and a slave computer. The topology is shown below. Figure 2 Each subsystem is connected to the CAN bus via a CAN interface for transmitting commands and responses between the host computer and different slave devices. The host computer initiates the system upgrade by configuring parameters and then remotely upgrading the embedded software, monitoring the upgrade process in real time. The slave devices receive the upgrade command from the host computer and perform state transitions: command verification and upgrade implementation.

[0056] 2. Lower-level software flow design

[0057] The execution flow of the lower-level machine program is as follows: Figure 3As shown, the lower-level machine first runs the BOOTLOADER program upon initial power-up. The bootloader has two main functions: executing the program and parameter upload / download process, and the program transfer / jump function. 500ms before system power-up, the bootloader first checks if a program upgrade command has been received. If so, it executes the upload / download process; otherwise, it executes the program jump process. The program jump process includes: first, reading program data from the FLASH application partition into memory and checking if the program file verification is correct. If correct, it executes the jump; otherwise, it reads and verifies the backup program data. If the data is correct, it executes the backup application. The lower-level machine's Flash chip backup area data is only burned once at the factory as the initial state. Relying on this method, the system always has a stable running APP application and a set of normal system parameters, so that after a program upgrade failure, it can quickly restore a normally running program state and prevent the system from becoming unusable. The Flash chip data storage strategy is as follows: Figure 4 .

[0058] 3. Host computer software flowchart design

[0059] The execution flow of the host computer program is as follows Figure 5 As shown in the diagram. After the host computer is powered on, it first sends a sub-device upgrade command and waits for a response from the slave computer. If a response command is received, it then sends the corresponding upgrade command.

[0060] 4. Bus Protocol Design

[0061] The upgrade protocol uses 1MBps and defines several different types of CAN frame types for control and data transmission. Each CAN frame consists of the following parts: Identifier (ID): a 29-bit identifier indicating the type of CAN message; Data Length Code (DLC): a maximum of 8 bytes; Data Segment: the actual data transmitted; CRC and Acknowledgment: used for error detection and acknowledgment.

[0062] (1) Handshake command frame format

[0063] The lower-level machine waits for the upper-level machine's upgrade command for 500ms before powering on. After receiving the upgrade command, the lower-level machine sends back a response command and enters the upload / download state, waiting for the next upgrade command from the upper-level machine.

[0064] a. The host computer sends an upgrade request frame.

[0065] Fields Word length (bytes) describe ID 4 Frame ID (0x1FFF FFFF) Data 2 Device serial number (4 bytes)

[0066] Note: The lower-level machine identifies the data load and determines whether it matches the serial number of this device. If the match is successful, it replies with an update status response frame.

[0067] b. Lower-level machine response handshake protocol

[0068] Fields Word length (bytes) describe ID 4 Frame ID (0x0000 0000) Data 2 Device serial number (4 bytes)

[0069] Note: When the lower-level machine responds, the CAN frame data payload carries the serial number of this device.

[0070] (2) Data Upload

[0071] a. Host computer data upload command frame format

[0072] Fields Word length (bytes) describe ID 4 Frame ID (0x0000 0000) Data 8 Command type

[0073] Command type:

[0074] 0x1010: Request core 0 program upload instruction, with 4 bytes of total frame count and 2 bytes of CRC data payload.

[0075] 0x1111: Request core 1 program upload instruction, with 4 bytes of total frame count and 2 bytes of CRC data payload.

[0076] 0x1212: Request core 2 program upload instruction, with 4 bytes of total frame count and 2 bytes of CRC data payload.

[0077] 0x1313: Request core 3 program upload instruction, with 4 bytes of total frame count and 2 bytes of CRC data payload.

[0078] 0x1414: Request packager upload instruction, with 4 bytes of total frame count and 2 bytes of CRC data payload.

[0079] 0x1515: Request parameter 0 upload command (maximum upload 64K) includes a 4-byte total frame count and a 2-byte CRC data payload. 0x1616: Request parameter 1 upload command (maximum upload 64K) includes a 4-byte total frame count and a 2-byte CRC data payload. 0x1717: Request parameter 2 upload command (maximum upload 64K) includes a 4-byte total frame count and a 2-byte CRC data payload. 0x1818: Request parameter 3 upload command (maximum upload 64K) includes a 4-byte total frame count and a 2-byte CRC data payload. Note: The 8-byte data consists of a 2-byte command word, a 4-byte frame length, and a 2-byte CRC checksum.

[0080] The maximum upload size is 64KB. The lower-level machine responds to the upload command frame format.

[0081] Fields Word length (bytes) describe ID 4 Command frame ID (0x1FFF FFFF) Data 4 Command response type

[0082] Command response type:

[0083] 0xC0C0: Core 0 program upload command response confirmation

[0084] 0xC1C1: Core 1 program upload instruction response confirmation

[0085] 0xC2C2: Core 2 program upload command response confirmation

[0086] 0xC3C3: Core 3 program upload command response confirmation

[0087] 0xC4C4: Confirmation of upload command response from the packaging program

[0088] 0xC5C5: Parameter 0 upload command response confirmation

[0089] 0xC6C6: Parameter 1 upload command response confirmation

[0090] 0xC7C7: Parameter 2 upload command response confirmation

[0091] 0xC8C8: Parameter 3 upload command response confirmation

[0092] 0xC9C9: Instruction error

[0093] c. Host computer data upload data frame format

[0094] Fields Word length (bytes) describe ID 4 Frame ID (0x0000 0001~0x1000 0000) Data 8 Data to be uploaded

[0095] Note: During data transmission, the data frame ID increases with the frame number, ranging from (0x0000 0001 to 0x1000 0000). Each frame carries an 8-byte data payload (the last frame is padded with 0xFF if it is less than 8 bytes).

[0096] d. Lower-level machine status response data frame format

[0097] Fields Word length (bytes) describe ID 4 Command frame ID (0x1FFF FFFF) Data 4 Status report type

[0098] Status notification type:

[0099] 0xA0A0: Upload successful

[0100] 0xA1A1: Data frames are discontinuous during upload.

[0101] 0xA2A2: Data frame out of range during upload

[0102] 0xA3A3: Overall verification error during upload process

[0103] 0xA4A4: Upload process failed to write.

[0104] Note: Status responses will only be returned if an upload error occurs or the upload is successful.

[0105] (3) Data Download

[0106] a. Host computer data download command frame format

[0107] Fields Word length (bytes) describe ID 4 Frame ID (0x0000 0000) Data 4 Command type

[0108] Command type:

[0109] 0x2020: Requesting kernel 0 program download command

[0110] 0x2121: Requesting kernel 1 program download command

[0111] 0x2222: Request for Core 2 program download command

[0112] 0x2323: Requesting command to download core 3 program.

[0113] 0x2424: Request to download the packaging program

[0114] 0x2525: Request parameter 0 for download instructions (maximum download size 64KB)

[0115] 0x2626: Request parameter 1 for download command (maximum download size 64KB)

[0116] 0x2727: Request parameter 2 for download instructions (maximum download size 64KB)

[0117] 0x2828: Request parameter 3 for download command (maximum download size 64KB)

[0118] b. Lower-level machine data transmission data frame format

[0119] Fields Word length (bytes) describe ID 4 Frame ID (0x0000 0001~0x1000 0000) Data 8 Data to be downloaded

[0120] Note: During data transmission, the data frame ID accumulates with the frame number, ranging from (0x0000 0001 to 0x1000 0000), and each frame carries an 8-byte data payload.

[0121] The format of the first data frame during download is as follows:

[0122]

[0123] c. Lower-level machine status response frame data format

[0124] Fields Word length (bytes) describe ID 4 Command frame ID (0x1FFF FFFF) Data 4 Status report type

[0125] Status notification type:

[0126] 0xB0B0: Download successful

[0127] 0xB1B1: Failed to read Flash during download.

[0128] Note: Status responses will only be returned when an error occurs during the download or when the download is successful (download complete).

[0129] In summary, this method utilizes the existing CAN bus topology to achieve product software upgrades and parameter upload / download, and the protocol stack design based on CAN frame characteristics can improve upgrade efficiency; the designed multi-redundancy backup strategy can significantly improve product robustness.

[0130] Compared with existing technologies, the advantages are as follows:

[0131] 1. Contactless remote upgrade

[0132] By reusing the existing CAN bus network of military equipment, remote upgrades can be achieved without manual intervention, avoiding the risk of physical contact in high-risk battlefield areas and improving deployment flexibility.

[0133] 2. Adaptability to harsh environments

[0134] By leveraging the high anti-interference capabilities of the CAN bus (differential signaling, automatic retransmission of erroneous frames) and military-grade electromagnetic compatibility design, the reliability of upgrade data transmission in complex electromagnetic environments is ensured.

[0135] 3. Military-grade security

[0136] The firmware package is encrypted end-to-end using the CRC-16 strong check encryption algorithm, and a two-way handshake mechanism protocol is designed to prevent unauthorized node access and data tampering.

[0137] 4. Damage resistance and rapid recovery

[0138] The system is designed with dual storage partitions (Active / Backup). If the upgrade fails, the program will automatically jump to the previous stable version to avoid system failure and affecting the mission.

[0139] 5. Unified management of equipment from multiple vendors

[0140] It supports adaptive parsing of military standard CAN protocols (such as GJB 289A) and proprietary protocols, and reduces the complexity of multi-node collaboration by centrally scheduling the upgrade process of heterogeneous devices through the master control node.

[0141] 6. Data Integrity

[0142] It achieves a data integrity rate of over 99.99% and supports version rollback.

[0143] Example 3

[0144] This embodiment provides an embedded software remote upgrade device based on a CAN bus. Specifically, it includes:

[0145] The instruction sending module is used for the host computer to send an upgrade instruction to a specified slave device via the CAN bus. The upgrade instruction includes the device serial number of the specified slave device.

[0146] The instruction response module is used to send an upgrade state response instruction back to the host computer and wait for the upgrade type instruction if the corresponding lower-level machine receives an upgrade instruction. The upgrade type instruction includes a program upgrade instruction and a parameter upgrade instruction.

[0147] The upgrade execution module is used to execute the program upgrade process if the corresponding lower-level machine receives a program upgrade instruction, and to execute the parameter upgrade process if the lower-level machine receives a parameter upgrade instruction.

[0148] This device utilizes the existing CAN bus topology to achieve product software upgrades and parameter upload / download. Furthermore, the protocol stack design based on CAN frame characteristics improves upgrade efficiency. The designed multi-redundancy backup strategy significantly enhances product robustness.

[0149] Example 4

[0150] In another feasible embodiment, this embodiment provides a device for remotely upgrading embedded software based on a CAN bus, the device specifically including:

[0151] A processor; and a memory arranged to store computer-executable instructions, which, when executed, cause the processor to perform the steps as described in any of the above method embodiments.

[0152] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for remote upgrading of embedded software based on CAN bus, characterized in that, Comprising: S1, the host computer sends an upgrade instruction to the specified lower computer through the CAN bus, the upgrade instruction including the device serial number of the specified lower computer; S2, if the corresponding lower computer receives the upgrade instruction, it sends back an upgrade state response instruction to the host computer and waits for an upgrade type instruction, the upgrade type instruction including a program upgrade instruction and a parameter upgrade instruction; S3, if the corresponding lower computer receives the program upgrade instruction, it executes the program upgrade process, and if the lower computer receives the parameter upgrade instruction, it executes the parameter upgrade process.

2. The method of claim 1, wherein, After the S1, it further comprises: If the lower computer does not receive the upgrade instruction, it reads the program data from the FLASH main application partition to the memory and judges whether the program check is correct; If correct, it executes the main program.

3. The method of claim 2, wherein, After the reading of the program data from the FLASH main application partition to the memory and the judgment of whether the program check is correct, it further comprises: If not correct, it reads the program data from the FLASH backup application partition to the memory and judges whether the program check is correct; If correct, it executes the backup program.

4. The method of claim 3, wherein, Before the reading of the program data from the FLASH backup application partition to the memory and the judgment of whether the program check is correct, it further comprises: Only once at the factory, the data of the FLASH backup application partition is burned as the initial state.

5. The method of claim 1, wherein, The S3 comprises: In the process of executing the program upgrade protocol or the parameter upgrade protocol, the lower computer judges the upload state frame by frame; If the data frame is not continuous in the upload process / the data frame is out of range / the total check is wrong / the write fails / the upload is successful, the corresponding upload state response frame is sent back to the host computer.

6. The method of claim 5, wherein, The S3 comprises: In the process of executing the program upgrade protocol or the parameter upgrade protocol, the lower computer judges the download state frame by frame; If the Flash reading fails in the download process / the download is successful, the corresponding download state response frame is sent back to the host computer.

7. The method of claim 1, wherein, Before the S2, it further comprises: After the corresponding lower computer is powered on, it judges whether the upgrade instruction is received within 500ms; If the upgrade instruction is not received within 500ms, the lower computer does not receive the upgrade instruction.

8. The method of claim 1, wherein, Before the S1, it further comprises: The lower computers are mounted on the CAN bus through the CAN interface, for the transmission of instructions and responses between the host computer and different lower computers.

9. A CAN bus-based embedded software remote upgrading device, characterized in that, Comprising: An instruction sending module for the host computer to send an upgrade instruction to the specified lower computer through the CAN bus, the upgrade instruction including the device serial number of the specified lower computer; An instruction response module for the corresponding lower computer to send back an upgrade state response instruction to the host computer and wait for an upgrade type instruction if it receives the upgrade instruction, the upgrade type instruction including a program upgrade instruction and a parameter upgrade instruction; An upgrade execution module for the corresponding lower computer to execute the program upgrade process if it receives the program upgrade instruction, and for the lower computer to execute the parameter upgrade process if it receives the parameter upgrade instruction.

10. An electronic device, comprising: Comprising: A processor; And a memory arranged to store computer-executable instructions that, when executed, cause the processor to perform the steps of the method of any of claims 1-8.

Images