Upgrading method and device of intelligent driving system and vehicle

Abstract

The invention provides an upgrading method and device of an intelligent driving system and a vehicle. The method is applied to a vehicle end, and comprises the following steps: determining the state of the intelligent driving system according to the file state of a kernel file in a bootstrap program of the intelligent driving system; when the intelligent driving system is abnormal, downloading the minimum recovery package file into a memory through first communication connection with the server in the bootstrap program; wherein the minimum recovery package file comprises a temporary kernel mirror image; starting the temporary kernel based on the temporary kernel mirror image, and downloading the OTA file package through a second communication connection with the server under the temporary kernel; using the OTA file package to upgrade the intelligent driving system; wherein the bandwidth of the first communication connection is smaller than that of the second communication connection.

Description

Technical Field

[0001] The present invention relates to the field of automobile technology, and in particular to an upgrade method, device and vehicle for an intelligent driving system. Background Art

[0002] With the rapid development of automotive intelligent technology, intelligent driving systems have become an important part of modern automobiles. In the development, testing and actual application of intelligent driving software, it is crucial to ensure the compatibility and stability of software and hardware.

[0003] The startup process of the intelligent driving system involves multiple key components, including starting BootROM, the first-level boot images BL21-BL31, the second-level boot program BootLoader, the Linux kernel Kernel, and the root file system Rootfs, etc.; if you want to complete the OTA upgrade, the intelligent driving domain must at least require the OTA service software to be able to start normally, otherwise the OTA server will not be able to establish contact with the underlying software of the intelligent driving, and it will not be able to upgrade.

[0004] However, in the actual development and application process, there are some situations that can easily cause OTA failure. For example, during the development and debugging process, the bootloader is burned to the rootfs stage image. If there is a problem with the image itself or the signature does not match, it will cause the device to be abnormal during the startup of the underlying software and unable to boot the APP normally. In the version release process, random problems and insufficient verification lead to batch upgrades of OTA to the vehicle computer. The device crashes in the kernel or rootfs stage and cannot enter the APP boot process. The OTA service is not ready. In the above two cases, the system may not be able to boot the application normally, especially the OTA service, which makes the OTA upgrade function invalid. Once the OTA service fails to start, the intelligent driving system cannot repair the underlying software problems through remote upgrades, causing the device to remain in an abnormal state.

[0005] At present, the conventional way to solve such problems is to recall the vehicle, disassemble it, and re-flash it using the serial port and burning tools. However, this method is cumbersome to operate, and in the case of large-scale deployment, the disassembly and serial port flashing of multiple devices will bring huge workload and maintenance costs. Summary of the invention

[0006] The embodiments of the present application provide an upgrade method, device and vehicle for an intelligent driving system. The following introduces various aspects involved in the embodiments of the present application.

[0007] In a first aspect, a method for upgrading an intelligent driving system is provided, which is applied to a vehicle side, and the method includes: in a boot program of the intelligent driving system, determining the status of the intelligent driving system according to the file status of a kernel file; when the intelligent driving system is abnormal, downloading a minimum recovery package file to a memory in the boot program through a first communication connection with a server side; wherein the minimum recovery package file includes a temporary kernel image; starting a temporary kernel based on the temporary kernel image, and downloading an OTA file package under the temporary kernel through a second communication connection with the server side; using the OTA file package to upgrade the intelligent driving system; wherein the bandwidth of the first communication connection is less than the bandwidth of the second communication connection.

[0008] According to the above technical means, when the intelligent driving system on the vehicle side is abnormal, the boot program uses the first communication connection to quickly download the minimum recovery package containing the temporary kernel image to the memory, which can quickly establish a temporary kernel operating environment and avoid tedious disassembly and flashing operations. Based on this temporary kernel, the complete OTA file package is downloaded through the second communication connection with a larger bandwidth for system upgrade, which greatly shortens the time from abnormality to repair and upgrade of the system, improves the repair efficiency, enables the intelligent driving system to resume normal operation faster, and reduces the vehicle downtime caused by system abnormalities.

[0009] In some embodiments, the minimum recovery package file also includes a temporary root file system initramfs, and the temporary root file system includes an OTA service program; the use of a temporary kernel image to start a temporary kernel includes: setting the kernel boot mode to initramfs boot; booting the temporary kernel image; when the temporary kernel loads the root file system, selecting the temporary root file system to start the OTA service program in the temporary kernel.

[0010] According to the above technical means, the temporary root file system initramfs provides a running environment independent of the original system for the temporary kernel. By directly selecting the temporary root file system and starting the OTA service program during the startup of the temporary kernel, the intermediate links for the system to recover in an abnormal state are reduced. The system does not need to spend extra time and resources to try to repair or verify the original root file system and OTA service, but directly uses the resources in the temporary environment for upgrade operations. This makes the entire repair process more direct and efficient, improves the success rate of the repair, and shortens the time it takes for the system to recover from abnormality to normal operation.

[0011] In some embodiments, after starting the temporary kernel based on the temporary kernel image, the method further includes: establishing a second communication connection with the server; based on the requirements of the OTA service program, sending an OTA request to the server connection through the second communication connection, so that the server sends the OTA file package in response to the OTA request.

[0012] According to the above technical means, by establishing a second communication connection and sending a request based on the OTA service program requirements, the vehicle side can interact accurately with the service side to obtain the OTA file package that best suits the current system status, avoiding blind downloading of irrelevant or inapplicable upgrade files, improving download efficiency, and reducing the waste of network resources. At the same time, since the second communication connection usually has a larger bandwidth (such as compared to the first communication connection for downloading larger OTA file packages), it can speed up the download speed of the file package and shorten the time required for system upgrades.

[0013] In some embodiments, the kernel files of the intelligent driving system include a first kernel file and a second kernel file respectively stored in a first memory partition and a second memory partition; determining the state of the intelligent driving system according to the file status of the kernel files includes: when both the first kernel file and the second kernel file cannot be loaded by the boot program, determining that the intelligent driving system is abnormal.

[0014] According to the above technical means, by detecting the loading status of the first kernel file and the second kernel file stored in the first memory partition and the second memory partition respectively, the state of the intelligent driving system can be determined comprehensively and accurately. Only when both independent kernel files cannot be loaded by the boot program, the system abnormality is determined, avoiding misjudgment of the system state due to a single kernel file problem, reducing unnecessary abnormal handling process startup, ensuring that the system only enters a complex repair and upgrade process when a serious problem really occurs, and improving the stability of system operation.

[0015] In some embodiments, the OTA file package includes a kernel image, a root file image and an intelligent driving software upgrade file of the intelligent driving system; using the OTA file package to upgrade the intelligent driving system includes: when the signature authentication of the OTA file package passes, flashing the kernel image, the root file image and the intelligent driving software upgrade file to a target memory partition, so that the intelligent driving system can be started from the target memory partition after restarting; the target memory partition is any one of the first memory partition and the second memory partition.

[0016] According to the above technical means. By signing and authenticating the OTA file package, illegal or tampered upgrade files are effectively prevented from being applied to the intelligent driving system. This ensures that the files used in the upgrade process are provided by a trusted server and have not been maliciously modified, thereby ensuring the security of the system. At the same time, the kernel image, root file image, and intelligent driving software upgrade files are completely flashed to the target memory partition to ensure the integrity of the system upgrade and avoid system instability or malfunction due to failure to update some files. Only when all key components are correctly updated can the system run in a new and stable state after restarting, improving the success rate and reliability of the upgrade.

[0017] In some embodiments, before downloading the minimum recovery package file to the memory through the first communication connection with the server, the method also includes: sending a broadcast exception message to the local area network through the vehicle-mounted communication terminal TBOX, and the exception message includes the product information of the vehicle end; receiving a handshake signal sent by the server through the TBOX, wherein the handshake signal is a signal sent by the server after scanning and parsing the exception message; and establishing the first communication connection in response to the handshake signal.

[0018] According to the above technical means, the mechanism of sending broadcast abnormal messages enables the vehicle to quickly spread abnormal information to the local area network when the system is abnormal, without knowing the specific location of the server in advance, which greatly improves the timeliness of abnormal discovery. For the server, it can actively monitor whether the abnormality exists through signal scanning and can perform batch processing. At the same time, the detailed product information in the abnormal message enables the server to provide accurate services according to the specific situation of the vehicle.

[0019] In a second aspect, an upgrade method for an intelligent driving system is provided, which is applied to a server side, and the method includes: when the intelligent driving system on the vehicle side is abnormal, sending a minimum recovery package file to the vehicle side through a first communication connection, and the minimum recovery package file includes a temporary kernel image; when the intelligent driving system starts a temporary kernel based on the temporary kernel image, sending an OTA file package to the vehicle side through a second communication connection, so that the vehicle side uses the OTA file package to upgrade the intelligent driving system.

[0020] In some embodiments, the minimum recovery package file also includes a temporary root file system initramfs, and the temporary root file system includes an OTA service program; before sending the OTA file package to the vehicle end through the second communication connection, the method also includes: receiving an OTA request sent by the vehicle end through the second communication connection; in response to the OTA request, sending the OTA file package to the vehicle end; wherein the OTA request is sent by the vehicle end based on the needs of the OTA service program.

[0021] In some embodiments, before sending the minimum recovery package file to the vehicle end through the first communication connection, the method also includes: scanning the broadcast within the local area network; after receiving the abnormal message, parsing the abnormal message, the abnormal message is sent by the on-board communication terminal TBOX of the vehicle end, and the abnormal message includes product information of the vehicle end; sending a handshake signal to the vehicle end; establishing the first communication connection.

[0022] In a third aspect, an upgrade device for an intelligent driving system is provided, which is applied to a vehicle side, and is characterized in that the upgrade device includes: a first determination unit, used to determine the status of the intelligent driving system according to the file status of a kernel file in a boot program of the intelligent driving system; a first receiving unit, used to download a minimum recovery package file to a memory in the boot program through a first communication connection with a server side when the intelligent driving system is abnormal; wherein the minimum recovery package file includes a temporary kernel image; a second receiving unit, used to start a temporary kernel based on the temporary kernel image, and download an OTA file package under the temporary kernel through a second communication connection with the server side; an upgrade unit, used to upgrade the intelligent driving system using the OTA file package; wherein the bandwidth of the first communication connection is less than the bandwidth of the second communication connection.

[0023] In a fourth aspect, an upgrade device for an intelligent driving system is provided, which is applied to a server side and is characterized in that the upgrade device includes: a first sending unit, which is used to send a minimum recovery package file to the vehicle side through a first communication connection when the intelligent driving system on the vehicle side is abnormal, and the minimum recovery package file includes a temporary kernel image; a second sending unit, which is used to send an OTA file package to the vehicle side through a second communication connection when the intelligent driving system starts a temporary kernel based on the temporary kernel image, so that the vehicle side uses the OTA file package to upgrade the intelligent driving system.

[0024] In a fifth aspect, a vehicle is provided, comprising a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the method described in the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 The startup process of the intelligent driving system in the related technology;

[0026] Figure 2 A schematic flowchart of an upgrade method of an intelligent driving system provided in an embodiment of the present application;

[0027] Figure 3 for Figure 2Step S230 in the flowchart is a method for starting a temporary kernel based on a temporary kernel image;

[0028] Figure 4 A schematic flowchart of an upgrade method of an intelligent driving system provided in another embodiment of the present application;

[0029] Figure 5 A schematic flowchart of an upgrade method of an intelligent driving system provided in yet another embodiment of the present application;

[0030] Figure 6 A schematic flowchart of an upgrade method for an intelligent driving system applied to a vehicle side provided in an embodiment of the present application;

[0031] Figure 7 A schematic flowchart of an upgrade method for an intelligent driving system applied to a server provided in an embodiment of the present application;

[0032] Figure 8 A schematic structural diagram of an upgrade device for an intelligent driving system provided in one embodiment of the present application;

[0033] Fig. 9 A schematic structural diagram of an upgrade device for an intelligent driving system provided in another embodiment of the present application;

[0034] Fig.10 A schematic structural diagram of a vehicle provided in an embodiment of the present application. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solutions and advantages of the present application clearer, the technical solutions of the present application are further elaborated in detail below in conjunction with the drawings and embodiments. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present application.

[0036] In the following description, reference is made to "some embodiments", which describe a subset of all possible embodiments, but it is understood that "some embodiments" may be the same subset or different subsets of all possible embodiments, and may be combined with each other without conflict. The terms "first / second / third" involved are merely used to distinguish similar objects and do not represent a specific order for the objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0037] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by technicians in the technical field of this application. The terms used in this article are only for the purpose of describing this application and are not intended to limit this application. Before introducing the technical solution of the embodiment of this application, the intelligent driving system of the related technology and its existing problems are first described in detail with examples.

[0038] With the rapid development of automobile intelligent technology, intelligent driving systems have become an important part of modern automobiles. Intelligent driving systems are usually developed and run based on the Linux system as the underlying architecture. It realizes the functions of vehicle autonomous navigation, environmental perception, decision control, etc. through complex software architecture. In the development, testing and actual application of intelligent driving software, it is crucial to ensure the compatibility and stability of software and hardware.

[0039] The startup process of the intelligent driving system involves multiple key components, including boot read-only memory (BootROM), primary boot image (BL21-BL31), secondary boot program (such as uboot), Linux kernel (Kernel) and root file system (Rootfs). Figure 1 The startup process of the intelligent driving system is described. Figure 1 The startup process includes steps S110-S160.

[0040] In step S110, the device is powered on and booted from the BootROM.

[0041] In step S120 , according to the set boot mode, the primary boot image (BL21 - BL31) archived in the embedded multimedia card (eMMC) is read from the eMMC.

[0042] In step S130, the first-level boot program finds the second-level boot program BL33, usually uboot, according to the globally unique identifier partition table (GUID Partition Table, GPT) partition. At this time, the first-level boot program reads the uboot image and completes the verification. After the verification is passed, uboot will be booted to start.

[0043] In step S140, in uboot, signature verification is performed on both the linux image and the rootfs image. After the verification passes, the kernel is booted.

[0044] In step S150, the kernel guides the rootfs to start.

[0045] In step S160, rootfs will start the app business service in a service mode, including OTA service and other services.

[0046] The above process ensures the integrity and security of the system from power-on to the final application (including OTA service) startup. From the above startup process, it can be seen that if the OTA upgrade is to be completed, the OTA service software of the intelligent driving domain must be able to start normally, otherwise the OTA server will not be able to establish contact with the underlying software of the intelligent driving, and it will not be able to upgrade. In other words, at least the underlying software Linux kernel and OTA service must be started normally.

[0047] However, in the actual development and application process, there are some situations that can easily lead to OTA failure. The following are explained separately.

[0048] During the development and debugging process, when burning the bootloader to the rootfs stage image, if there is a problem with the image itself or the signature does not match, the device will be abnormal during the startup of the underlying software and cannot boot the APP normally.

[0049] In the version release process, random problems and insufficient verification, OTA batch upgrade to the car machine, the device crashes in the kernel or rootfs stage, cannot enter the APP boot process, and the OTA service is not ready. In the above two cases, the system may not be able to boot the application normally, especially the OTA service, making the OTA upgrade function invalid. Once the OTA service cannot be started, the intelligent driving system cannot repair the underlying software problems through remote upgrades, causing the device to remain in an abnormal state.

[0050] At present, the conventional way to solve such problems is to recall the vehicle, disassemble it, and re-flash it using the serial port and burning tools. However, this method is cumbersome to operate, and in the case of large-scale deployment, the disassembly and serial port flashing of multiple devices will bring huge workload and maintenance costs. Therefore, there is an urgent need for a solution that can repair the abnormal state of the intelligent driving system at the underlying software level without disassembling the device.

[0051] In view of the above problems, the embodiments of the present application provide an upgrade method, device and vehicle for an intelligent driving system. The technical solution of the application will be described in detail below in conjunction with the accompanying drawings.

[0052] Figure 2 1 is a schematic flow chart of an upgrade method of an intelligent driving system provided in an embodiment of the present application. The method is described from the perspective of interaction between the vehicle end and the service end. Figure 2 The method includes steps S210-S250.

[0053] In step S210, in the boot program of the intelligent driving system, the state of the intelligent driving system is determined according to the file state of the kernel file.

[0054] The bootloader is the key part that runs first when the intelligent driving system starts. It is responsible for performing a series of important tasks, including initializing the hardware, such as detecting and configuring hardware components such as processors, memory, and storage devices, ensuring that they are in normal working condition and ready to load the operating system kernel.

[0055] At the same time, the bootloader also bears the responsibility of loading the operating system kernel, which is the core link in the system startup process. It needs to find and correctly read the kernel file from the storage medium (such as eMMC, etc.), and then load it into the memory to lay the foundation for the subsequent system operation.

[0056] The boot program in the embodiment of the present application may be uboot, which can support command line interface, network boot, environment variable configuration, script execution, multiple file systems, etc.

[0057] The boot program can determine the status of the intelligent driving system based on whether the kernel file can be correctly booted.

[0058] There are many ways to determine whether the kernel can be correctly booted. For example, the integrity of the kernel can be checked. The boot program verifies that the kernel file is intact and has not been damaged or tampered with. This can be achieved through technical means such as checksums and digital signatures. For example, the hash value of the kernel file is calculated and compared with the pre-stored correct hash value. If the two do not match, it indicates that the kernel file may be damaged and the kernel will not be able to boot correctly.

[0059] Alternatively, the availability of kernel files can be determined by judging the compatibility of kernel versions. The boot program needs to check whether the kernel file version is compatible with other components of the intelligent driving system (such as hardware device drivers, application program interfaces, etc.). If the kernel version is too old or too new, it may not work properly with other components, thus affecting the normal operation of the system. For example, a new kernel version may introduce new system calls or interface changes, and old applications may not be able to adapt to these changes, resulting in startup failure or abnormal operation.

[0060] When the kernel file has the above-mentioned integrity problems (such as partial file loss, data errors, etc.) or version incompatibility (such as incompatibility with the hardware driver, inconsistent interfaces with other key software components, etc.), the boot program will determine that the intelligent driving system is in an abnormal state and cannot start normally.

[0061] In some embodiments, the kernel file of the intelligent driving system includes a first kernel file and a second kernel file stored in a first memory partition and a second memory partition.

[0062] The first memory partition and the second memory partition are usually two completely independent storage spaces. The first memory partition and the second memory partition can also be called a running partition and a backup partition. The aforementioned first kernel file and the second kernel file can also be called a running kernel file and a backup kernel file. By storing kernel files in the above two memory partitions, dual backup of kernel files can be achieved. When the system starts, one of the two kernels is selected for loading; when one of the kernels fails, the system can select the backup kernel to start, thereby ensuring the continuous operation of the system. The Linux kernel dual backup technology can significantly improve the reliability of the system. Even if a kernel image or key data fails, the system can still be restored from the backup, thereby avoiding system crashes or data loss.

[0063] That is to say, when any one of the first kernel file and the second kernel file can be loaded by BootLoader, the intelligent driving system can operate normally.

[0064] Therefore, in the embodiment of the present application, the above-mentioned determination of the state of the intelligent driving system according to the file state of the kernel file includes:

[0065] When both the first kernel file and the second kernel file cannot be loaded by the boot program, it can be determined that the intelligent driving system is abnormal.

[0066] According to the above technical means, by detecting the loading status of the first kernel file and the second kernel file stored in the first memory partition and the second memory partition respectively, the state of the intelligent driving system can be determined comprehensively and accurately. Only when both independent kernel files cannot be loaded by the boot program, the system abnormality is determined, avoiding misjudgment of the system state due to a single kernel file problem, reducing unnecessary abnormal handling process startup, ensuring that the system only enters a complex repair and upgrade process when a serious problem really occurs, and improving the stability of system operation.

[0067] In step S220, when the intelligent driving system is abnormal, the minimum recovery package file is downloaded to the memory in the boot program through the first communication connection with the server; wherein the minimum recovery package includes a temporary kernel image.

[0068] It is understandable that when the aforementioned intelligent driving system abnormality occurs, the startup process of the intelligent driving system will remain at the boot program stage.

[0069] According to the above description, the uboot bootloader can support network functions. It can establish the above-mentioned first communication connection with the server based on a relatively basic communication protocol such as the UDP protocol, so as to send and receive signals or files through the network. The UDP protocol is simple and efficient, and is suitable for quickly establishing a connection and transmitting data in this case. Although it is connectionless and does not guarantee the reliability of data transmission, its efficiency advantage is more prominent in the scenario where the system is abnormal and urgently needs to obtain the minimum recovery package.

[0070] The minimum recovery package in the embodiment of the present application can be understood as a streamlined software package, which contains a temporary kernel image sufficient to start a temporary kernel. The temporary kernel image is a streamlined kernel version that can provide the most basic system operation functions and is sufficient to start a temporary kernel environment when the system is severely damaged. This temporary kernel environment is the basis for subsequent further recovery or upgrade operations. It can provide a temporary, executable core for the system when the original system kernel cannot work properly, so as to carry out subsequent repair work.

[0071] The above minimum recovery package file is usually small (for example, usually about 30MB), and it can be quickly transmitted without high bandwidth support. Smaller bandwidth can reduce the occupation of network resources, while also meeting the needs of fast download of the minimum recovery package, ensuring that key recovery resources can be obtained as soon as possible when the system is abnormal.

[0072] After establishing a connection with the server, the boot program will start downloading the minimum recovery package file. The minimum recovery package is usually small, and since the memory access speed is faster, in the scheme of the embodiment of the present application, the minimum recovery package file can be downloaded to the memory, and can be directly started from the memory in subsequent processes, thereby speeding up the repair and upgrade.

[0073] In step S230 , the vehicle side starts the temporary kernel based on the temporary kernel image.

[0074] When booting the temporary kernel image, the boot program will load the temporary kernel image from the memory into the processor and perform a series of initialization operations, including setting the processor's operating mode, initializing the memory management unit, and establishing kernel data structures.

[0075] In step S240, under the temporary kernel, the OTA file package is downloaded through a second communication connection with the server.

[0076] After the above-mentioned temporary kernel is started, the vehicle side will establish a second communication connection with the server side. The second communication connection is used to transmit the OTA file package, and its transmission bandwidth is greater than the first communication connection.

[0077] Since OTA file packages are usually large (for example, a normal OTA upgrade package may be around 15GB), they require high bandwidth support to be downloaded quickly. However, the bandwidth of the aforementioned communication method based on basic protocols such as UDP is only 100MBps, which obviously cannot meet the needs of rapid upgrades.

[0078] In an embodiment of the present application, the second communication connection may be, for example, a connection method based on the transmission control protocol TCP, the hypertext transfer protocol HTTP, or the file transfer protocol FTP.

[0079] Transmitting OTA files in the temporary kernel also has the following beneficial effects: first, the bandwidth of the second communication connection established in the temporary kernel is larger, and the supported network protocols are richer; second, when accessing memory in the uboot boot program, the memory space that can be used usually does not exceed 1GB, so it is not suitable for downloading a large number of upgrade files to the memory, and the temporary kernel will not be subject to this limitation; third, the image downloaded in the uboot boot program cannot perform file signature authentication, and the OTA upgrade program needs to participate in the verification of the hsm file, so uboot is not suitable for integrating this logic, and the temporary kernel will not be subject to this limitation; fourth, if the upgrade is performed after downloading the file in uboot, since uboot writes to the storage medium (flash, eMMC, etc.) as a single-core write and the drive efficiency is low, it will result in slow writing speed, while in the temporary kernel, multiple writes can be performed, which has higher efficiency; fifth, the file system under uboot does not fully support ext4 files, and the temporary kernel has better support for such files, thereby improving efficiency.

[0080] In step S250, the intelligent driving system is upgraded using the OTA file package.

[0081] After downloading the OTA file package, the temporary kernel will use these files to upgrade the intelligent driving system. This may include replacing old kernel files, updating applications, applying new configurations, etc. After the upgrade is completed, the intelligent driving system should be able to resume normal operation with the latest functions and security improvements.

[0082] According to the above technical means, when the intelligent driving system on the vehicle side is abnormal, the boot program uses the first communication connection to quickly download the minimum recovery package containing the temporary kernel image to the memory, which can quickly establish a temporary kernel operating environment and avoid tedious disassembly and flashing operations. Based on this temporary kernel, the complete OTA file package is downloaded through the second communication connection with a larger bandwidth for system upgrade, which greatly shortens the time from abnormality to repair and upgrade of the system, improves the repair efficiency, enables the intelligent driving system to resume normal operation faster, and reduces the vehicle downtime caused by system abnormalities.

[0083] In some embodiments, the aforementioned minimum recovery package file also includes a temporary root file system initramfs, and the temporary root file system includes an OTA service program.

[0084] That is to say, the minimum recovery package file contains not only the temporary kernel image, but also the temporary root file system initramfs.

[0085] Initramfs is an initial memory file system that is loaded into the memory during the system startup process to provide a temporary root file system environment for the kernel. This temporary environment contains the most basic files and directory structures required to start the system, as well as some necessary drivers and tools, so that the kernel can run in this minimal environment and perform some basic operations.

[0086] When the system is abnormal, the original OTA service may not work properly. The OTA service program in the temporary root file system provides an OTA service capability that is independent of the original system and can run in a temporary kernel environment, ensuring that even in the case of abnormalities in the underlying software, it can still interact effectively with the server, creating conditions for system upgrades.

[0087] like Figure 3 As shown, the aforementioned step S230 further includes steps S231-S233.

[0088] In step S231, the kernel boot mode is set to initramfs boot.

[0089] By setting the kernel boot mode to initramfs boot, the system instructs the boot program to use initramfs as the root file system when loading the kernel. This allows the kernel to boot in a relatively simple and independent environment that contains the minimum configuration and tools required for booting, avoiding reliance on the original root file system that may be damaged or untrustworthy, ensuring a stable basic environment for subsequent operations.

[0090] In step S232, the temporary kernel image is booted.

[0091] The bootloader will read the temporary kernel image from the memory and load it into the processor for execution. During this process, the kernel will perform a series of initialization operations, including setting the processor's operating mode, initializing the memory management unit, and establishing kernel data structures.

[0092] In step S233, when the temporary kernel loads the root file system, the temporary root file system is selected to start the OTA service program in the temporary kernel.

[0093] When the temporary kernel loads the root file system, according to the preset boot mode (initramfs boot), the system will select the temporary root file system (initramfs) instead of the original root file system. This is because the original root file system may be in an abnormal state and cannot provide reliable services. After selecting the temporary root file system, the temporary kernel will run in this minimized environment containing the OTA service program, so that the OTA service program can be started, thereby establishing the ability to communicate with the server and obtain the OTA file package.

[0094] According to the above technical means, the temporary root file system initramfs provides a running environment independent of the original system for the temporary kernel. By directly selecting the temporary root file system and starting the OTA service program during the startup of the temporary kernel, the intermediate links for the system to recover in an abnormal state are reduced. The system does not need to spend extra time and resources to try to repair or verify the original root file system and OTA service, but directly uses the resources in the temporary environment for upgrade operations. This makes the entire repair process more direct and efficient, improves the success rate of the repair, and shortens the time it takes for the system to recover from abnormality to normal operation.

[0095] In some embodiments, Figure 4 As shown, after starting the temporary kernel based on the temporary kernel image in step S230, the method further includes steps S261-S262.

[0096] In step S261, a second communication connection is established between the vehicle end and the service end.

[0097] This process involves a series of network configuration and protocol negotiation operations. The system will first determine the available network interface and communication parameters, such as IP address, subnet mask, default gateway and other information, to ensure that a valid connection can be established in the current network environment. Then, according to the pre-set communication protocol (such as TCP and other protocols suitable for large data transmission and with reliable connection characteristics), handshake and parameter negotiation are carried out with the server.

[0098] In step S262, based on the requirements of the OTA service program, an OTA request is sent to the server connection through the second communication connection.

[0099] After the temporary kernel is started, the OTA service program running in the temporary root file system will generate an OTA request based on the current state of the system and upgrade requirements. The OTA request can contain a variety of information, such as the version number of the vehicle-side intelligent driving system, hardware configuration information, and possible errors or exceptions. By sending these detailed information, the server can accurately understand the situation on the vehicle side and provide it with the most suitable OTA file package. The OTA service program will send this request to the server through the aforementioned second communication connection and wait for the server's response.

[0100] The server executes the aforementioned step S240 in response to the OTA request and sends the OTA file package to the vehicle.

[0101] After receiving the OTA request sent by the vehicle, the server will parse and process the information in the request. Based on the system information provided by the vehicle, the server searches for a matching OTA file package in its repository. This search process may involve version matching, hardware compatibility checks, and other operations to ensure that the provided OTA file package can correctly upgrade the intelligent driving system on the vehicle side. Once a suitable OTA file package is found, the server will perform a series of preparations, such as packaging the file package, encrypting (if necessary), adding signatures, and other operations to ensure the security and integrity of the file package during transmission. The server then begins to transmit the prepared OTA file package to the vehicle through the second communication connection.

[0102] According to the above technical means, by establishing a second communication connection and sending a request based on the OTA service program requirements, the vehicle side can interact accurately with the service side to obtain the OTA file package that best suits the current system status, avoiding blind downloading of irrelevant or inapplicable upgrade files, improving download efficiency, and reducing the waste of network resources. At the same time, since the second communication connection usually has a larger bandwidth (such as compared to the first communication connection for downloading larger OTA file packages), it can speed up the download speed of the file package and shorten the time required for system upgrades.

[0103] In some embodiments, the OTA file package includes a kernel image, a root file image, and an intelligent driving software upgrade file of the intelligent driving system.

[0104] The kernel image is used to replace the kernel parts that may have problems or need to be updated in the current intelligent driving system to provide new functions, fix kernel vulnerabilities, improve kernel performance, and ensure the stability and optimization of the system core. The root file image contains the basic file system structure and configuration information required for the system to run. Updating the root file image can improve the system's file management method, optimize the storage layout, and adapt to new system function requirements. The intelligent driving software upgrade file updates applications and functions related to intelligent driving, such as improving autonomous driving algorithms to improve driving safety and accuracy, optimizing sensor data processing to enhance environmental perception, and updating the user interface to improve user experience.

[0105] The aforementioned step S250, using the OTA file package to upgrade the intelligent driving system further includes:

[0106] If the signature authentication of the OTA file package passes, the kernel image, root file image and intelligent driving software upgrade file are flashed to the target memory partition so that the intelligent driving system can be started from the target memory partition after restarting; wherein, the target memory partition is any one of the first memory partition and the second memory partition.

[0107] Signature authentication is a security mechanism based on digital certificates and encryption algorithms. For example, when the server generates an OTA file package, it will use a private key to sign the file package. This signature contains the hash value of the file package (calculated by a specific hash algorithm to ensure the integrity of the file content) and the identity information of the server. After the vehicle receives the OTA file package, it will use the pre-stored server public key to verify the signature. If the verification is successful, it means that the source of the file package is reliable and has not been tampered with during transmission; if the verification fails, the file package will be refused for upgrade to prevent malware or erroneous upgrade files from damaging the intelligent driving system.

[0108] When the signature authentication of the OTA file package is successful, the vehicle will write the kernel image, root file image and intelligent driving software upgrade file in the OTA file package to the target memory partition. This target memory partition can be either the first memory partition (running partition) or the second memory partition (backup partition), depending on the system strategy and the current partition status.

[0109] The flashing process involves accurately writing new file data to the corresponding location of the target partition, overwriting the old file data. This requires precise memory address mapping and data writing operations to ensure that the system can correctly load the new kernel, root file system and application from the target partition after restart to achieve system upgrade.

[0110] After the flash is completed, the vehicle will perform a reboot. During the reboot, the smart driving system will follow the normal boot process, but this time it will boot from the upgraded target memory partition. The system will load a new kernel, which will perform initialization operations, including initializing hardware device drivers, establishing memory management structures, etc. Then it will load a new root file system so that the system can access and manage files. Finally, the updated smart driving software will be started. At this time, the system will have new functions, performance improvements, and security improvements, and will resume normal operation.

[0111] According to the above technical means. By signing and authenticating the OTA file package, illegal or tampered upgrade files are effectively prevented from being applied to the intelligent driving system. This ensures that the files used in the upgrade process are provided by a trusted server and have not been maliciously modified, thereby ensuring the security of the system. At the same time, the kernel image, root file image, and intelligent driving software upgrade files are completely flashed to the target memory partition to ensure the integrity of the system upgrade and avoid system instability or malfunction due to failure to update some files. Only when all key components are correctly updated can the system run in a new and stable state after restarting, improving the success rate and reliability of the upgrade.

[0112] In some embodiments, Figure 5 As shown, in step S220, before downloading the minimum recovery package file into the memory through the first communication connection with the server in the boot program, the method also includes steps S271-S274.

[0113] In step S271, the vehicle sends a broadcast abnormal message to the local area network through the vehicle-mounted communication terminal TBOX.

[0114] The broadcast exception message is a data frame in a special format that contains product information on the vehicle side. Product information covers key content such as the vehicle model, intelligent driving system version, hardware configuration information, etc. For example, vehicle model information helps the server identify the vehicle type so that it can provide an adapted minimum recovery package; intelligent driving system version information allows the server to understand the baseline status of the current system and determine the appropriate upgrade strategy; hardware configuration information ensures that the recovery package and upgrade files provided by the server are compatible with the vehicle hardware. Sending by broadcast is to ensure that the server in the local area network can receive this exception information. Even if the specific address of the server is unknown, the information can be transmitted, laying the foundation for subsequent connection establishment and acquisition of repair resources.

[0115] In step S272, the server scans the broadcasts in the local area network.

[0116] In step S273, after receiving the abnormal message, the server parses the abnormal message.

[0117] The parsing process is mainly to extract the vehicle-side product information contained in the message so that the server can perform subsequent processing based on this information.

[0118] In step S274, the service end sends a handshake signal to the vehicle end.

[0119] After correctly parsing the abnormal message, the server will send a handshake signal to the vehicle. This handshake signal is the first step in establishing communication between the server and the vehicle, similar to a confirmation response, indicating that the server has received the abnormal message and is ready to proceed to the next step.

[0120] In step S275, the vehicle side establishes a first communication connection with the service side.

[0121] After receiving the handshake signal, the vehicle responds to the signal and establishes a first communication connection with the server. The first communication connection is based on a specific network protocol (such as UDP, etc.), and its establishment process involves the negotiation of network parameters, such as the determination of the port number and the setting of the communication rate, to ensure

[0122] According to the above technical means, the mechanism of sending broadcast abnormal messages enables the vehicle to quickly spread abnormal information to the local area network when the system is abnormal, without knowing the specific location of the server in advance, which greatly improves the timeliness of abnormal discovery. For the server, it can actively monitor whether the abnormality exists through signal scanning and can perform batch processing. At the same time, the detailed product information in the abnormal message enables the server to provide accurate services according to the specific situation of the vehicle.

[0123] Figure 6 It is a schematic flowchart of an upgrade method of an intelligent driving system provided in another embodiment of the present application, which is applied to the vehicle side. Figure 6 The method includes steps S610-S640.

[0124] In step S610, in the boot program of the intelligent driving system, the state of the intelligent driving system is determined according to the file state of the kernel file.

[0125] In step S620, when the intelligent driving system is abnormal, the minimum recovery package file is downloaded to the memory through the first communication connection with the server in the boot program.

[0126] Among them, the minimum recovery package file includes a temporary kernel image;

[0127] In step S630, a temporary kernel is started based on the temporary kernel image, and the OTA file package is downloaded under the temporary kernel through a second communication connection with the server.

[0128] In step S640, the intelligent driving system is upgraded using the OTA file package.

[0129] The bandwidth of the first communication connection is smaller than the bandwidth of the second communication connection.

[0130] In some embodiments, the minimum recovery package file also includes a temporary root file system initramfs, which includes an OTA service program; using the temporary kernel image to start the temporary kernel includes: setting the kernel boot mode to initramfs boot; booting the temporary kernel image; when the temporary kernel loads the root file system, selecting the temporary root file system to start the OTA service program in the temporary kernel.

[0131] In some embodiments, after starting the temporary kernel based on the temporary kernel image, the method also includes: establishing a second communication connection with the server; based on the requirements of the OTA service program, sending an OTA request to the server connection through the second communication connection, so that the server sends an OTA file package in response to the OTA request.

[0132] In some embodiments, the kernel files of the intelligent driving system include a first kernel file and a second kernel file stored in a first memory partition and a second memory partition, respectively; the state of the intelligent driving system is determined according to the file status of the kernel files, including: when both the first kernel file and the second kernel file cannot be loaded by the boot program, it is determined that the intelligent driving system is abnormal.

[0133] In some embodiments, the OTA file package includes a kernel image, a root file image and an intelligent driving software upgrade file of the intelligent driving system; the intelligent driving system is upgraded using the OTA file package, including: when the signature authentication of the OTA file package passes, the kernel image, the root file image and the intelligent driving software upgrade file are flashed to the target memory partition, so that the intelligent driving system can be started from the target memory partition after restarting; the target memory partition is any one of the first memory partition and the second memory partition.

[0134] In some embodiments, before downloading the minimum recovery package file to the memory through the first communication connection with the server, the method also includes: sending a broadcast exception message to the local area network through the vehicle-mounted communication terminal TBOX, and the exception message includes product information of the vehicle end; receiving a handshake signal sent by the server through TBOX, wherein the handshake signal is a signal sent by the server after scanning and parsing the exception message; and establishing a first communication connection in response to the handshake signal.

[0135] Figure 7 is a schematic flow chart of an upgrade method of an intelligent driving system provided by another embodiment of the present application, Figure 7 The method is applied to the server, and the method includes steps S710-S720.

[0136] In step S710, when the intelligent driving system of the vehicle side is abnormal, a minimum recovery package file is sent to the vehicle side through the first communication connection. The minimum recovery package file includes a temporary kernel image.

[0137] In step S720, when the intelligent driving system starts the temporary kernel based on the temporary kernel image, the OTA file package is sent to the vehicle end through the second communication connection, so that the vehicle end upgrades the intelligent driving system using the OTA file package.

[0138] In some embodiments, the minimum recovery package file also includes a temporary root file system initramfs, and the temporary root file system includes an OTA service program; before sending the OTA file package to the vehicle end through the second communication connection, the method also includes: receiving an OTA request sent by the vehicle end through the second communication connection; in response to the OTA request, sending the OTA file package to the vehicle end; wherein the OTA request is sent by the vehicle end based on the needs of the OTA service program.

[0139] In some embodiments, before sending the minimum recovery package file to the vehicle end through the first communication connection, the method also includes: scanning the broadcast within the local area network; after receiving the abnormal message, parsing the abnormal message, the abnormal message is sent by the on-board communication terminal TBOX on the vehicle end, and the abnormal message includes product information on the vehicle end; sending a handshake signal to the vehicle end; establishing a first communication connection.

[0140] Combination of the above Figure 1-Figure 7 , the method embodiment of the present application is described in detail, and the device embodiment of the present application will be described in detail in conjunction with the accompanying drawings. It should be understood that the description of the device embodiment corresponds to the method embodiment, so the part not described in detail can refer to the device embodiment above.

[0141] Figure 8 is a schematic structural diagram of an upgrade device for an intelligent driving system provided in an embodiment of the present application, Figure 8 The device 800 is applied to a vehicle end, and includes:

[0142] The first determining unit 810 is used to determine the state of the intelligent driving system according to the file state of the kernel file in the boot program of the intelligent driving system.

[0143] The first receiving unit 820 is used to download the minimum recovery package file to the memory through the first communication connection with the server in the boot program when the intelligent driving system is abnormal; wherein the minimum recovery package file includes a temporary kernel image.

[0144] The second receiving unit 830 is used to start the temporary kernel based on the temporary kernel image, and download the OTA file package through the second communication connection with the server under the temporary kernel.

[0145] The upgrading unit 840 is used to upgrade the intelligent driving system using the OTA file package.

[0146] The bandwidth of the first communication connection is smaller than the bandwidth of the second communication connection.

[0147] Fig. 9 is a schematic structural diagram of an upgrade device for an intelligent driving system provided in another embodiment of the present application, Fig. 9 The device 900 is applied to the server, and includes:

[0148] A first sending unit 910 is used to send a minimum recovery package file to the vehicle end through a first communication connection when the intelligent driving system of the vehicle end is abnormal, where the minimum recovery package file includes a temporary kernel image;

[0149] The second sending unit 920 is used to send an OTA file package to the vehicle end through a second communication connection when the intelligent driving system starts the temporary kernel based on the temporary kernel image, so that the vehicle end uses the OTA file package to upgrade the intelligent driving system.

[0150] Based on the upgrade method of the intelligent driving system provided in the above embodiment, the embodiment of the present application also provides a vehicle, such as Fig.10 The vehicle 1000 includes a processor 1010 and a memory 1020. The memory 1020 stores a computer program that can be executed by the processor 1010, so that the processor 1010 executes the method described in the above method embodiment. The memory 1020 can be independent of the processor 1010 or integrated in the processor 1010.

[0151] The vehicle 1000 may further include a transceiver 1030. The processor 1010 may communicate with other devices or chips through the transceiver 1030. For example, the processor 1010 may transmit and receive data with other devices or chips through the transceiver 1030.

[0152] The processor may be at least one of an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a Digital Signal Processing Device (DSPD), a Programmable Logic Device (PLD), a Field Programmable Gate Array (FPGA), a Central Processing Unit (CPU), a controller, a microcontroller, and a microprocessor. It is understandable that the electronic device that implements the functions of the processor may also be other, and the embodiments of the present application are not specifically limited.

[0153] The embodiment of the present application provides a storage medium, which stores one or more computer programs, and the one or more computer programs can be executed by one or more processors to implement some or all of the steps in the above method. The storage medium can be transient or non-transient.

[0154] An embodiment of the present application provides a computer program, including a computer-readable code. When the computer-readable code is run in a computer device, a processor in the computer device executes some or all of the steps for implementing the above method.

[0155] The embodiment of the present application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program, and when the computer program is read and executed by a computer, some or all of the steps in the above method are implemented. The computer program product can be implemented specifically by hardware, software or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium, and in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

[0156] It should be noted here that the description of the various embodiments above tends to emphasize the differences between the various embodiments, and the same or similar aspects can be referenced to each other. The description of the above device, storage medium, computer program and computer program product embodiments is similar to the description of the above method embodiment, and has similar beneficial effects as the method embodiment. For technical details not disclosed in the embodiments of the device, storage medium, computer program and computer program product of this application, please refer to the description of the method embodiment of this application for understanding.

[0157] It should be noted here that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments, and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0158] The above-mentioned computer storage medium / memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic random access memory (FRAM), a flash memory (Flash Memory), a magnetic surface memory, an optical disk, or a compact disc read-only memory (CD-ROM) and the like; it can also be various terminals including one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0159] It should be understood that "one embodiment" or "an embodiment" mentioned throughout the specification means that specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in various embodiments of the present application, the size of the serial number of each step / process mentioned above does not mean the order of execution, and the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. The serial numbers of the embodiments of the present application mentioned above are for description only and do not represent the advantages and disadvantages of the embodiments.

[0160] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0161] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0162] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units; they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0163] In addition, all functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the above-mentioned integrated units may be implemented in the form of hardware or in the form of hardware plus software functional units.

[0164] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, etc., various media that can store program codes.

[0165] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a vehicle-mounted terminal (which can be a personal computer, server, or network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0166] The methods disclosed in several method embodiments provided in the embodiments of the present application can be arbitrarily combined without conflict to obtain new method embodiments.

[0167] The features disclosed in several product embodiments provided in the embodiments of the present application can be arbitrarily combined without conflict to obtain new product embodiments.

[0168] The features disclosed in several method or device embodiments provided in the embodiments of the present application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0169] The above is only an implementation method of the embodiment of the present application, but the protection scope of the embodiment of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the embodiment of the present application. Therefore, the protection scope of the embodiment of the present application should be based on the protection scope of the claims.

Claims

1. A method for upgrading an intelligent driving system, applied to a vehicle, characterized in that: The method comprises: In a boot program of the intelligent driving system, determining a state of the intelligent driving system according to a file state of a kernel file; When the intelligent driving system is abnormal, in the boot program, a minimum recovery package file is downloaded to the memory through a first communication connection with the server; wherein the minimum recovery package file includes a temporary kernel image; Starting a temporary kernel based on the temporary kernel image, and downloading an over-the-air upgrade OTA file package under the temporary kernel through a second communication connection with the server; Using the OTA file package, upgrading the intelligent driving system; The bandwidth of the first communication connection is smaller than the bandwidth of the second communication connection.

2. The method according to claim 1, characterized in that The minimum recovery package file also includes a temporary root file system initramfs, and the temporary root file system includes an OTA service program; The method of starting the temporary kernel using the temporary kernel image includes: Set the kernel boot mode to initramfs boot; Booting the temporary kernel image; When the temporary kernel loads the root file system, the temporary root file system is selected to start the OTA service program in the temporary kernel.

3. The method according to claim 2, characterized in that After starting the temporary kernel based on the temporary kernel image, the method further includes: Establishing a second communication connection with the server; Based on the requirements of the OTA service program, an OTA request is sent to the server connection through the second communication connection, so that the server sends the OTA file package in response to the OTA request.

4. The method according to claim 1, characterized in that: The kernel file of the intelligent driving system includes a first kernel file and a second kernel file respectively stored in a first memory partition and a second memory partition; The determining the state of the intelligent driving system according to the file state of the kernel file includes: When both the first kernel file and the second kernel file cannot be loaded by the boot program, it is determined that the intelligent driving system is abnormal.

5. The method according to claim 4, characterized in that The OTA file package includes the kernel image, root file image and intelligent driving software upgrade file of the intelligent driving system; The step of upgrading the intelligent driving system by using the OTA file package includes: If the signature authentication of the OTA file package passes, the kernel image, the root file image, and the intelligent driving software upgrade file are flashed to the target memory partition, so that the intelligent driving system can be started from the target memory partition after restarting; The target memory partition is any one of the first memory partition and the second memory partition.

6. The method according to any one of claims 1 to 5, characterized in that Before downloading the minimum recovery package file to the memory through the first communication connection with the server, the method further includes: Sending a broadcast abnormal message to the local area network through the vehicle-mounted communication terminal TBOX, wherein the abnormal message includes product information of the vehicle end; Receiving, through the TBOX, a handshake signal sent by the server, wherein the handshake signal is a signal sent by the server after scanning and parsing the abnormal message; In response to the handshake signal, the first communication connection is established.

7. An upgrade method of an intelligent driving system, applied to a server, characterized in that: The method comprises: When the intelligent driving system of the vehicle side is abnormal, a minimum recovery package file is sent to the vehicle side through the first communication connection, wherein the minimum recovery package file includes a temporary kernel image; When the intelligent driving system starts the temporary kernel based on the temporary kernel image, an OTA file package is sent to the vehicle end through a second communication connection, so that the vehicle end uses the OTA file package to upgrade the intelligent driving system.

8. The method according to claim 7, characterized in that The minimum recovery package file also includes a temporary root file system initramfs, and the temporary root file system includes an OTA service program; Before sending the OTA file package to the vehicle end through the second communication connection, the method further includes: Receiving an OTA request sent by the vehicle end through a second communication connection; In response to the OTA request, sending the OTA file package to the vehicle end; Among them, the OTA request is sent by the vehicle side based on the needs of the OTA service program.

9. The method according to claim 7 or 8, characterized in that: Before sending the minimum recovery package file to the vehicle end through the first communication connection, the method further includes: Scan broadcasts within the LAN; After receiving the abnormal message, parsing the abnormal message, wherein the abnormal message is sent by the vehicle-mounted communication terminal TBOX of the vehicle end, and the abnormal message includes product information of the vehicle end; Sending a handshake signal to the vehicle end; The first communication connection is established.

10. An upgrade device for an intelligent driving system, applied to a vehicle, characterized in that: The upgrading device comprises: A first determining unit is used to determine the state of the intelligent driving system according to the file state of the kernel file in the boot program of the intelligent driving system; A first receiving unit is used to download a minimum recovery package file to a memory in the boot program through a first communication connection with a server when the intelligent driving system is abnormal; wherein the minimum recovery package file includes a temporary kernel image; A second receiving unit is used to start a temporary kernel based on the temporary kernel image, and download an OTA file package under the temporary kernel through a second communication connection with the server; An upgrading unit, used to upgrade the intelligent driving system using the OTA file package; The bandwidth of the first communication connection is smaller than the bandwidth of the second communication connection.

11. An upgrade device for an intelligent driving system, applied to a server, characterized in that: The upgrading device comprises: A first sending unit, configured to send a minimum recovery package file to the vehicle end through a first communication connection when the intelligent driving system of the vehicle end is abnormal, wherein the minimum recovery package file includes a temporary kernel image; The second sending unit is used to send an OTA file package to the vehicle end through a second communication connection when the intelligent driving system starts a temporary kernel based on the temporary kernel image, so that the vehicle end uses the OTA file package to upgrade the intelligent driving system.

12. A vehicle, characterized in that: The vehicle comprises a memory and a processor, wherein the memory is used to store a computer program, and the processor is used to execute the computer program to implement the method according to any one of claims 1 to 7.

Images