Batch upgrading vehicle-mounted control method

Abstract

The invention provides a batch upgrading vehicle-mounted control method, which belongs to the field of vehicle-mounted Internet of Things, and is characterized in that a plurality of different control MCUs (Microprogrammed Control Unit) are issued through a gateway instead of being directly downloaded and updated through the MCUs. Passive upgrading is adopted, and current single or batch upgrading operation is carried out through the OTA platform. When upgrading is carried out, the vehicle gateway firstly obtains the current firmware version number of each control end and judges whether firmware upgrading is continued or not according to returned information. And batch or single firmware of the vehicle-mounted terminal can be updated. The efficiency of upgrading and maintaining the terminal by maintenance personnel is effectively improved, and the vehicle-mounted terminal equipment is managed more conveniently and efficiently.

Description

Technical Field

[0001] The present invention relates to the field of vehicle-mounted Internet of Things, and in particular to a method for batch upgrading vehicle-mounted control. Background Art

[0002] With the development of the Internet of Things, the number of IoT terminal accesses has increased dramatically. A few IoT terminals can directly interact with the platform to achieve OTA upgrades; most devices in applications are connected to the network platform through different gateways, and subsequent system upgrades and parameter management are relatively cumbersome. Summary of the invention

[0003] In order to solve the above technical problems, the present invention provides a batch upgrade vehicle control method to realize batch or single firmware update of vehicle terminals, improve the efficiency of terminal upgrade and maintenance, and manage vehicle terminal equipment more conveniently and efficiently.

[0004] The technical solution of the present invention is:

[0005] A method for managing vehicle terminals that can be upgraded in batches applies Bluetooth, WiFi, 5G, and other IoT technologies, and uses storage media to achieve remote upgrades and parameter management of IoT terminals.

[0006] The OTA upgrade of the present invention is the same as the serial port and USB upgrades usually used in principle, which is to operate the Flash of the MCU. The upgrade steps are roughly as follows: receiving the upgrade command -> MCU reset or jump to the Boot program area -> erase the corresponding Flash area -> obtain APP data -> write FLASH data -> verify -> return the upgrade result -> jump to the APP application area.

[0007] The difference between the present invention and other common upgrades is that the present invention is sent to multiple different control MCUs through the gateway instead of downloading and updating directly through the MCU itself. The present invention adopts passive upgrade and performs single or batch upgrade operations through the OTA platform. When the upgrade is in progress, the vehicle gateway first obtains the current firmware version number of each control terminal, and determines whether to continue the firmware upgrade based on the returned information.

[0008] The control end upgrade is allocated in different ways according to the device information of each control node. First, the FLASH storage of the control end is divided into two parts of the same size, and the startup position is 0 and the middle position. If it is started from the 0x0 address, the second half of the area will be cleared after initialization, and the operation will be performed when upgrading.

[0009] The basic upgrade process is as follows: When the APP area receives the upgrade instruction, after verifying the program version and information, it saves the upgrade flag, program version, CRC and other information to the cache area, and then starts to request the upgrade data packet. After receiving a frame of data packet, check whether it is the currently requested data packet, and determine whether the CRC is consistent. If all the checks are passed, first perform the flash erase action on the APP_BAK area, then write the data just received, and then request the next frame of data packet until the entire upgrade package is received. After a complete upgrade package is written to APP_BAK, calculate the CRC of the APP_BAK area and compare it with the information saved in the cache area to see if it is consistent. If it is consistent, report the upgrade completion information, then save the upgrade flag and program information to the USER area, and finally jump to BOOT to update the APP area. If it is inconsistent, re-execute the data packet acquisition action.

[0010] When the program is reset or powered on, first read whether there is an upgrade mark in the USER area. If there is an upgrade mark, read the new program version and compare it with the current program version, and read the CRC of the APP_BAK area to see if it is consistent with the saved CRC. If all conditions are met, enter the APP_BAK copy step. First erase the data in the APP area, then read a frame of data from the APP_BAK area and write it to the APP area. Repeat the action until a whole package of program data is completely copied to the APP area, calculate the CRC of the APP area once, and compare it with the saved value to see if it is consistent. If it is consistent, erase the upgrade mark, reset the program and continue to run from the BOOT area. The boot program determines that there is no upgrade mark at this time, jumps to the APP area to run the new program, and the program upgrade is completed. If it is inconsistent, re-execute the copy action.

[0011] The present invention can be divided into four levels from the bottom to the upper level: BootLoader, system kernel, file system and user application. The main function of BootLoader is to initialize the stack area, global variables, establish and classify the mapping relationship of memory address space, etc., and establish the software and hardware environment for calling the operating system kernel. In the download mode, the BootLoader of the MCU obtains the file from the gateway or T-Box through serial communication or CAN bus. The file is first written into RAM by the BootLoader and then written into ROM. The communication between the controller end and the MCU is often based on the UDS diagnostic communication protocol.

[0012] When updating MCU software, communication is mainly performed between a server that manages update data, a gateway (remote communication unit), and the update target MCU.

[0013] The beneficial effects of the present invention are

[0014] It can be widely used in the field of vehicle-mounted terminal Internet of Things, and realizes the management and upgrade of terminal equipment while ensuring data security. It consists of an upgrade management terminal and a vehicle-mounted terminal to be upgraded. The management terminal and the Internet of Things terminal adopt a one-to-many relationship, which can meet the simultaneous upgrade of multiple Internet of Things terminals and reduce the workload of maintenance personnel. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is a basic upgrade process diagram;

[0016] Figure 2 This is a schematic diagram of MCU update and upgrade. DETAILED DESCRIPTION

[0017] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0018] The present invention is a remote unlimited upgrade technology that includes three parts: cloud, pipe, and end. The upgrade objects include vehicle power control systems, infotainment networking systems, safety control systems, chassis electronic systems, body control systems, automatic driving systems, etc. The on-board OTA upgrade has gone through four stages. From the initial OTA upgrade of T-BOX, car companies have begun to deploy OTA in 2021. The OTA of new energy vehicles has gone through the stages from component OTA to vehicle upgrade FOTA and enterprise-level OTA. In the future, the OTA industry will develop in the direction of coordination across the entire industry chain under stronger supervision. With the rapid development of the new energy vehicle industry, the demand and application of on-board OTA has gradually increased, and the objects of OTA upgrades have gradually expanded from single components to most automotive firmware and software. The core functional domains of automobiles have also gradually opened up to OTA upgrade technology.

[0019] The following is an implementation example of upgrading a vehicle control device:

[0020] The gateway uses i.MX 8MCPU and Bluetooth module to form a management terminal, and sets different update firmware and corresponding firmware model lists. The gateway establishes a network connection with the OTA upgrade system through 4G / 5G to realize basic communication services; after the connection is established, the network monitoring sub-process monitors the data transmission connection and working status in real time, and controls the command operation of the data transmission system through command issuance. In the event of abnormal data status, abnormal connection, MCU device failure, etc., the gateway actively reports the abnormal information, and the server performs predictive diagnosis processing according to the reported instructions, and sends the diagnostic information to the platform management end.

[0021] After entering the boot module during the upgrade, the first step is to read the stored upgrade information, obtain the network link, and establish a network connection. During this period, an error handling mechanism is included. If the upgrade fails due to reasons such as network disconnection and poor network signal quality, there are corresponding handling mechanisms to ensure the normal operation of the on-site equipment. After the network is successfully established, file transfer is executed to obtain the upgrade file, and the obtained upgrade file is verified to prevent data loss during the download process from causing incomplete files. The obtained file is stored in the local storage. After the verification is successful, the upgrade is executed, and the boot program verifies the integrity of the upgrade file again. If the file verification fails, it will not be executed. The program overwrite operation continues to execute the current version of the program and returns the upgrade result to the server; if the file verification is successful, read the file package information, record the current upgrade package version information, and execute the program overwrite. During the program overwrite process, add an exception handling mechanism and an overwrite failure recovery mechanism. The exception handling mechanism: when executing the program overwrite, an abnormal power outage causes the upgrade to fail. After powering on again, the system re-performs the program overwrite operation. After the overwrite is successful, the system automatically restarts and runs the entire system; Overwrite failure mechanism: when the overwrite fails or the local upgrade file is abnormally damaged, the program will recover the program from the recovery area and return the upgrade result to the management platform.

[0022] The management terminal of the present invention and the IoT terminal can be connected via 4G, Bluetooth, WiFi, etc. OTA upgrade can be performed by transmitting all firmware sub-packets; or by transmitting firmware differential upgrade.

[0023] The vehicle-mounted upgrade terminal divides the storage area into the front half area and the back half area. When starting up, it reads the codes of different areas according to the startup flag to implement alternating updates.

[0024] The above description is only a preferred embodiment of the present invention, which is only used to illustrate the technical solution of the present invention, and is not used to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A method for batch upgrading vehicle control, characterized in that: Single or batch upgrade operations are performed through the OTA platform. When the upgrade is in progress, the vehicle gateway first obtains the current firmware version number of each control terminal, and determines whether to continue the firmware upgrade based on the returned information.

2. The method according to claim 1, characterized in that: The control end upgrade is allocated differently according to the device information of each control node. First, the FLASH storage of the control end is divided into two parts of the same size, and the startup position is 0 and the middle position. If it is started from address 0x0, the second half of the area will be cleared after initialization and the operation will be performed when upgrading.

3. The method according to claim 2, characterized in that When the APP area receives the upgrade instruction, after verifying the program version and information, it saves the upgrade flag, program version, and CRC information to the cache area, and then starts to request the upgrade data packet; After receiving a frame of data packet, check whether it is the currently requested data packet and determine whether the CRC is consistent.

4. The method according to claim 3, characterized in that: If all the checks are passed, the APP_BAK area is erased first, then the received data is written, and then the next frame of data packet is requested until the entire upgrade package is received.

5. The method according to claim 4, characterized in that After a complete upgrade package is written to APP_BAK, the CRC of the APP_BAK area is calculated and compared with the information saved in the cache area to see if they are consistent. If they are consistent, the upgrade completion information is reported, and then the upgrade flag and program information are saved in the USER area. Finally, jump to BOOT to update the APP area. If they are inconsistent, re-execute the data packet acquisition action.

6. The method according to claim 5, characterized in that When the program is reset or powered on, first read whether there is an upgrade mark in the USER area. If there is an upgrade mark, read the new program version and compare it with the current program version, and read whether the CRC of the APP_BAK area is consistent with the saved CRC. If all conditions are met, enter the APP_BAK copy step.

7. The method according to claim 6, characterized in that First, erase the data in the APP area, then read a frame of data from the APP_BAK area and write it into the APP area. Repeat the action until a whole package of program data is completely copied to the APP area. Calculate the CRC of the APP area and compare it with the saved value to see if they are consistent. If they are consistent, erase the upgrade flag, reset the program and continue to run from the BOOT area. The boot program determines that there is no upgrade flag at this time, jumps to the APP area to run the new program, and the program upgrade is completed. If they are inconsistent, re-execute the copy action.

8. The method according to claim 7, characterized in that From the bottom to the top, it is divided into four layers: BootLoader, system kernel, file system and user application; The function of BootLoader is to initialize the stack area, global variables, establish and classify the mapping relationship of memory address space, and establish the hardware and software environment for calling the operating system kernel; In download mode, the MCU's BootLoader obtains files from the gateway or T-Box through serial communication or CAN bus. The files are first written into RAM by the BootLoader and then into ROM. The communication between the controller and the MCU is based on the UDS diagnostic communication protocol.

9. The method according to claim 8, characterized in that When the MCU software is updated, communication is performed between the server that manages the update data, the gateway, and the update target MCU.

Images