Vehicle cabin OTA upgrading method and device, electronic equipment, storage medium and vehicle

By distinguishing the trigger conditions of the B and A side upgrades in the vehicle cockpit OTA upgrade, first complete the B side upgrade package writing, and then perform the A side upgrade, the problem of vehicle stopping caused by too long upgrade time and failure is solved, and the problem of vehicle suspension is improved. Upgrade efficiency and user experience.

CN119127249APending Publication Date: 2024-12-13CHINA FAW CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411184103.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-08-27
Publication Date
2024-12-13

AI Technical Summary

Technical Problem

The existing smart cockpit software upgrade method requires users to manually determine the upgrade conditions, which leads to too long upgrade time, affects the user experience, and may cause the vehicle to stop when the upgrade fails.

Method used

By distinguishing the trigger conditions of the B and A side during OTA upgrade, first complete the refresh of the B side upgrade package, then upgrade the A side according to the downloaded OTA upgrade package, and send permission requests before the A side upgrade to ensure that the power supply continues Output, determine whether the upgrade is successful or not, and restore the factory status if it fails.

Benefits of technology

It shortens the time for personnel to participate in OTA upgrades, reduces the risk of vehicle suspension caused by the failure of upgrades, reduces the number and frequency of OTA upgrade permission requests, and improves upgrade efficiency and user experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119127249A_ABST
    Figure CN119127249A_ABST
Patent Text Reader

Abstract

The invention discloses a vehicle cabin OTA upgrading method and device, electronic equipment, a storage medium and a vehicle, and relates to the field of OTA upgrade.The method comprises the steps that whether an upgrading task exists or not is inquired; if not, requesting to download an OTA upgrade package from the cloud and carrying out B-side upgrade; judging whether upgrading of the B side is completed; if yes, A-side upgrading is carried out according to the downloaded OTA upgrading package; wherein an OTA upgrade permission request is sent before A-side upgrade; and performing A-side upgrading according to a received permission instruction corresponding to the OTA upgrading permission request. Through the scheme, the triggering conditions of the B side and the A side during OTA upgrading are distinguished, so that personnel participation is added when the A side flashes data, the process time of personnel participating in OTA upgrading is shortened, and the discomfort of personnel participating in OTA upgrading is reduced. By judging whether the A-side upgrade is successful or not, the A-side is restored to factory settings when the A-side upgrade is not successful, and vehicle stop caused by OTA upgrade failure is prevented.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of OTA upgrades, and in particular to a vehicle cockpit OTA upgrade method, a vehicle cockpit OTA upgrade device, an electronic device, a storage medium, and a vehicle. Background Art

[0002] With the development of intelligent and connected cars, smart cockpits have become an important part of cars. However, the existing smart cockpit software upgrade methods often require users to determine various upgrade conditions and perform vehicle status detection. The upgrade process takes at least 10 minutes to 30 minutes or even longer. Not only is the upgrade process cumbersome, but it is also easy to cause the vehicle to stop, affecting the user experience.

[0003] Therefore, a vehicle cockpit OTA upgrade solution is needed to shorten the waiting time for personnel and reduce the problem of vehicle downtime caused by upgrade failure. Summary of the invention

[0004] The purpose of the present invention is to provide a vehicle cockpit OTA upgrade method, a vehicle cockpit OTA upgrade device, an electronic device, a storage medium and a vehicle, which at least solve the problem of waiting for OTA upgrade for too long and solve one technical problem of the vehicle stopping after the upgrade fails.

[0005] The present invention provides the following scheme:

[0006] According to one aspect of the present invention, a vehicle cockpit OTA upgrade method is provided, the vehicle cockpit OTA upgrade method comprising:

[0007] Check whether the upgrade task exists;

[0008] If it does not exist, then request to download the OTA upgrade package from the cloud and perform the B-side upgrade;

[0009] Determine whether the upgrade of side B is completed;

[0010] If completed, upgrade the A side according to the downloaded OTA upgrade package;

[0011] Among them, before upgrading the A side, send an OTA upgrade permission request;

[0012] According to the permission instruction received corresponding to the OTA upgrade permission request, the A side is upgraded.

[0013] Furthermore, the A-side upgrade includes:

[0014] Confirm whether the system is in the shutdown time window;

[0015] If yes, then confirm whether the sustainable output time of the power supply is greater than the preset time threshold of the A-side upgrade;

[0016] If, is greater than, the control power supply maintains continuous output and the A side is upgraded simultaneously;

[0017] It also includes determining whether the upgrade of the A side is successful;

[0018] If,unsuccessful, restore the A side to factory status.

[0019] Further, sending the OTA upgrade permission request includes:

[0020] Get information about vehicle status;

[0021] The vehicle status information includes the vehicle being ready to be plugged in, the vehicle resuming parking, and the vehicle being parked at a preset position;

[0022] According to the current state of the vehicle, which is the state of the vehicle preparing to be plugged in, the state of the vehicle resuming parking, or / and the state of the vehicle being parked at a preset position, an OTA upgrade permission request is sent.

[0023] Furthermore, the querying whether the upgrade task exists also includes:

[0024] Determine whether the system has received a USB upgrade or FOTA upgrade notification;

[0025] If,received, the ongoing B-side upgrade is stopped and the downloaded data is deleted;

[0026] Respond to USB upgrade or FOTA upgrade instructions and flash side B.

[0027] Furthermore, the B-side upgrade includes:

[0028] Check the OTA upgrade package to determine whether it includes parts that do not support direct copying of the A / B surface;

[0029] If, including, then determine whether the B-side upgrade is completed without supporting the part of direct copying of A / B side;

[0030] If completed, then according to the permission instruction received corresponding to the OTA upgrade permission request, the A side is upgraded; otherwise, after the B side upgrade completes the part that does not support direct copying of the A / B side, an OTA upgrade permission request is sent.

[0031] Furthermore, it also includes:

[0032] Check whether the upgrade task exists;

[0033] If yes, send an OTA upgrade permission request and determine whether a permission instruction for the OTA upgrade permission request is received;

[0034] If,received, then confirm whether the system is in the non-stop operation time window;

[0035] If yes, then download the OTA upgrade package and perform the B-side upgrade;

[0036] Determine whether the upgrade of side B is completed;

[0037] If, completed, then confirm whether the system is in the stop operation time window;

[0038] If yes, then confirm whether the sustainable output time of the power supply is greater than the preset time threshold of the A-side upgrade;

[0039] If, is greater than, the control power supply maintains continuous output and the A side is upgraded simultaneously;

[0040] It also includes determining whether the upgrade of the A side is successful;

[0041] If,unsuccessful, restore the A side to factory status.

[0042] According to two aspects of the present invention, there is provided a vehicle cockpit OTA upgrade device, the vehicle cockpit OTA upgrade device comprising:

[0043] Query module, used to query whether the upgrade task exists;

[0044] The request module is used to request the cloud to download the OTA upgrade package and perform B-side upgrade if it does not exist;

[0045] A judgment module is used to judge whether the upgrade of the B side is completed;

[0046] The upgrade module is used to, if completed, upgrade the A side according to the downloaded OTA upgrade package;

[0047] Permission module, used to send OTA upgrade permission request before upgrading the A surface;

[0048] The execution module is used to upgrade the A side according to the permission instruction received corresponding to the OTA upgrade permission request.

[0049] According to three aspects of the present invention, there is provided an electronic device, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0050] A computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the vehicle cockpit OTA upgrade method.

[0051] According to four aspects of the present invention, a computer-readable storage medium is provided, comprising: a computer program executable by an electronic device is stored therein, and when the computer program runs on the electronic device, the electronic device executes the steps of the vehicle cockpit OTA upgrade method.

[0052] According to five aspects of the present invention, there is provided a vehicle, comprising:

[0053] An electronic device, used to implement the steps of the vehicle cockpit OTA upgrade method;

[0054] A processor, the processor runs a program, and when the program runs, the steps of the vehicle cockpit OTA upgrade method are executed from the data output by the electronic device;

[0055] The storage medium is used to store a program, and when the program is running, the steps of the vehicle cockpit OTA upgrade method are executed for the data output from the electronic device.

[0056] Through the above scheme, the following beneficial technical effects are obtained:

[0057] This application distinguishes the trigger conditions of side B and side A during OTA upgrades, so that human participation is involved when flashing data on side A, reducing the process time for human participation in OTA upgrades and reducing the discomfort of human participation in OTA upgrades.

[0058] This application determines whether the upgrade of side A is successful, and restores side A to factory settings if it is unsuccessful, to prevent the vehicle from being stopped due to OTA upgrade failure.

[0059] This application completes the OTA upgrade of side A after completely flashing the OTA upgrade package of side B, preventing repeated flashing of data of side B and side A, and reducing the number and frequency of sending OTA upgrade permission requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 It is a flowchart of a vehicle cockpit OTA upgrade method provided by one or more embodiments of the present invention.

[0061] Figure 2 It is a structural diagram of a vehicle cabin OTA upgrade device provided by one or more embodiments of the present invention.

[0062] Figure 3 A schematic diagram of a cloud-downloaded OTA upgrade package upgrade according to a specific embodiment of the present invention.

[0063] Figure 4 A schematic diagram of a USB or FOTA upgrade intervention according to a specific embodiment of the present invention.

[0064] Figure 5A schematic diagram of a B-side upgrade process according to a specific embodiment of the present invention.

[0065] Figure 6 A block diagram of an electronic device structure of a vehicle cockpit OTA upgrade method provided by one or more embodiments of the present invention. DETAILED DESCRIPTION

[0066] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0067] Figure 1 It is a flowchart of a vehicle cockpit OTA upgrade method provided by one or more embodiments of the present invention.

[0068] like Figure 1 The vehicle cockpit OTA upgrade method shown includes:

[0069] Step S1, query whether the upgrade task exists;

[0070] Step S2: If it does not exist, then request to download the OTA upgrade package from the cloud and perform the B-side upgrade;

[0071] Step S3, determining whether the upgrade of surface B is completed;

[0072] Step S4: If completed, upgrade the A side according to the downloaded OTA upgrade package;

[0073] Step S5, sending an OTA upgrade permission request before upgrading the A surface;

[0074] Step S6: upgrading the A side according to the permission instruction received corresponding to the OTA upgrade permission request.

[0075] Specifically, in this embodiment, after the vehicle computer is turned on, it enters the Launcher. According to the preset time period, the system determines whether it is currently in USB upgrade mode or FOTA mode. If so, it does not request an upgrade task from the cloud, and waits until the next startup to determine whether it is in USB upgrade mode or FOTA mode. If it is not in USB upgrade mode or FOTA mode, it queries the cloud for new OTA download tasks.

[0076] The request sent contains parameters, including ROM version number, vehicle model, VIN, vehicle software version and other information, so as to facilitate the download of the corresponding OTA upgrade package.

[0077] When a new upgrade task appears, download the upgraded version OTA upgrade package, including the description file. Parse the description file, including verifying the vehicle model, vehicle memory, ROM / MCU version number, upgrade type and other information, and verifying whether the upgrade package is the OTA upgrade package of this system. If so, start downloading the upgrade package.

[0078] During the OTA upgrade package download process, the user will not be presented with a download interface or download exception prompts. If the download fails, it will be handled according to the preset download exception status handling strategy. After the upgrade package is downloaded, the signature and integrity checks of the upgrade package are performed. After the checks pass, the OTA upgrade package is used for B-side upgrade.

[0079] When upgrading the B side, no interface is presented to the user, and no abnormal prompts are presented. If the upgrade fails, it is handled according to the preset upgrade abnormal status handling strategy. During the upgrade of the B side, if a FOTA / USB upgrade notification is suddenly received, the B side flashing will be automatically stopped, and the downloaded content will be deleted, and the FOTA / USB upgrade will be responded to instead. If the upgrade fails during the upgrade of the B side due to power off or external reasons, the factory settings will be restored and the current OTA service will be forcibly terminated. After restarting again, the OTA service will re-check whether the system has been upgraded, continue the previously unfinished OTA upgrade package download or re-flash the B side, etc.

[0080] For example, the preset download abnormal status processing strategy includes: if the download of the OTA upgrade package fails, the current upgrade package download is stopped, and after the system is restarted again, the previously unfinished OTA upgrade package download is continued.

[0081] For example, the preset upgrade abnormal status handling strategy includes that during the B-side upgrade, if a FOTA / USB upgrade notification is suddenly received, the B-side flashing will be automatically stopped, the downloaded content will be deleted, and the FOTA / USB upgrade will be responded to instead.

[0082] For example, the preset upgrade abnormal state handling strategy also includes that if the upgrade fails during the B-side upgrade due to power failure or external reasons, the factory settings will be restored and the current OTA service will be forcibly terminated. After the system is restarted again, the B-side will be re-flashed.

[0083] For example, the preset upgrade abnormal state handling strategy also includes that during the B-side upgrade, if a FOTA / USB upgrade notification is suddenly received, the B-side will continue to be flashed until the B-side is flashed, and then respond to the FOTA / USB upgrade.

[0084] After the B-side upgrade is completed, the user will be prompted that a new OTA version is available for upgrade. The user can choose to upgrade after leaving the car or make an appointment for upgrade on the interface.

[0085] After the user authorizes the upgrade, the A side upgrade can begin. Before installing the A side upgrade, the vehicle status needs to be checked, such as whether it is in P gear, whether the speed is 0, whether the remaining power is > 20%, etc., to ensure that the vehicle will not be stopped due to the upgrade.

[0086] Before deciding to upgrade and install the A-side, the power awake status must be monitored to ensure that the A-side upgrade and installation process proceeds continuously. After the preparatory conditions for the A-side upgrade and installation are met, the A-side upgrade begins. The system pulls the power supply through the SOA interface to ensure continuous power supply during the OTA upgrade process. When the upgrade is completed, the vehicle can be restarted and the upgrade results can be reported to the cloud. After that, the vehicle automatically enters a dormant state, and can also be operated and used directly. When the user uses the car next time, the user can also be prompted that the system has been upgraded and the version number of the system.

[0087] In this embodiment, upgrading the A surface includes:

[0088] Confirm whether the system is in the shutdown time window;

[0089] If yes, then confirm whether the sustainable output time of the power supply is greater than the preset time threshold of the A-side upgrade;

[0090] If, is greater than, the control power supply maintains continuous output and the A side is upgraded simultaneously;

[0091] It also includes determining whether the upgrade of the A side is successful;

[0092] If,unsuccessful, restore the A side to factory status.

[0093] Specifically, in this embodiment, it is confirmed whether the system is in a stop operation time window, including a vehicle stop operation time window formed when the vehicle is ready to be plugged in, the vehicle resumes parking, and the vehicle is parked at a preset position.

[0094] For example, when the vehicle is ready to be plugged in, the vehicle will not move and the power is sufficient to ensure the continuity of the A-side upgrade process.

[0095] For example, when the vehicle is in the parking state, the vehicle usually returns to the parking gear from the forward gear when it is parked for a long time. Of course, when the system senses that the vehicle has returned to the parking gear from the forward gear, it cannot directly upgrade the A side. It is necessary to send an OTA upgrade permission request to the human-machine interface first, and then perform the subsequent A side upgrade after the user confirms.

[0096] For example, when the vehicle is parked at a preset position, such as at one's own parking space or at the unit's parking space, it may be parked for a long time, and a longer stop time window is likely to be generated at this time.

[0097] Usually, the A-side upgrade has a relatively predictable time length, and a preset time threshold for the A-side upgrade can be set accordingly to determine the length of the stop operation time window.

[0098] Since upgrading the A side will also cause the vehicle to stop, in order not to affect the real-time performance when it is used again, when the A side upgrade fails, the A side will be directly restored to its factory state to ensure the basic functions of the vehicle system.

[0099] You can wait until the next time when the vehicle system is in the downtime window to complete the upgrade of side A. You can use the stored data of the upgraded side B to directly copy and complete most of the upgrade of side A, which greatly shortens the time consumed by upgrading side B.

[0100] In this embodiment, sending an OTA upgrade permission request includes:

[0101] Get information about vehicle status;

[0102] The vehicle status information includes the vehicle being ready to be plugged in, the vehicle resuming parking, and the vehicle being parked at a preset position;

[0103] According to the current state of the vehicle, which is the state of the vehicle preparing to be plugged in, the state of the vehicle resuming parking, or / and the state of the vehicle being parked at a preset position, an OTA upgrade permission request is sent.

[0104] Specifically, in this example, the state of the vehicle ready to be plugged in can be confirmed by establishing communication between the plug gun and the vehicle, and locking the plug gun and the plug port. The state of the vehicle resuming parking can be confirmed based on the user's operating action sequence (such as pushing the parking gear from the forward gear) and the historical data of the previous long driving time (such as the forward gear state for more than half an hour). The state of the vehicle parked at the preset position can be locked according to the navigation positioning information, and the location of "home" or "company" can be locked. When driving home or to work, it is likely that the vehicle will be parked for a long time and the person will leave the vehicle. At this time, an OTA upgrade permission request is issued. If the user feedback allows the instruction, it will not take up the user's time, and only take up the time for the user to authorize the instruction to allow the OTA upgrade. All subsequent upgrade work will be completed automatically.

[0105] In this embodiment, querying whether the upgrade task exists further includes:

[0106] Determine whether the system has received a USB upgrade or FOTA upgrade notification;

[0107] If,received, then continue with the ongoing B-side upgrade;

[0108] After the upgrade of side B is completed, respond to the USB upgrade or FOTA upgrade instruction and flash side B.

[0109] Specifically, in this implementation, the system can be upgraded by USB upgrade or FOTA upgrade. Usually, USB upgrade or FOTA upgrade involves hardware connection, firmware upgrade, etc. After receiving the notification of USB upgrade or FOTA upgrade, if you directly respond to the USB upgrade or FOTA upgrade instruction at this time, you need to interrupt the ongoing B-side upgrade. If the USB upgrade or FOTA upgrade is not a successful upgrade, the current B-side upgrade may not succeed and will no longer exist. In order to ensure the integrity of the B-side upgrade, you can respond to the USB upgrade or FOTA upgrade instruction after the B-side upgrade is completed.

[0110] In this embodiment, querying whether the upgrade task exists further includes:

[0111] Determine whether the system has received a USB upgrade or FOTA upgrade notification;

[0112] If,received, the ongoing B-side upgrade is stopped and the downloaded data is deleted;

[0113] Respond to USB upgrade or FOTA upgrade instructions and flash side B.

[0114] Specifically, in this embodiment, USB upgrade or FOTA upgrade belongs to the upgrade of on-site operation and has a higher priority. Upgrading the B side takes a lot of time. In order to reduce the waiting time, the ongoing B side upgrade can be stopped immediately after receiving the notification of USB upgrade or FOTA upgrade and the downloaded data can be deleted. The B side can also be upgraded in response to the USB upgrade or FOTA upgrade instruction, reducing the cumbersome data refresh and overwriting process.

[0115] In one embodiment, querying whether the upgrade task exists further includes:

[0116] Determine whether the system has received a USB upgrade or FOTA upgrade notification;

[0117] If,received, then continue with the ongoing B-side upgrade;

[0118] After the upgrade of side B is completed, respond to the USB upgrade or FOTA upgrade instruction and flash side B.

[0119] In this implementation, the system can be upgraded by USB upgrade or FOTA upgrade. Usually, USB upgrade or FOTA upgrade involves hardware connection, firmware upgrade, etc. After receiving the notification of USB upgrade or FOTA upgrade, if you directly respond to the USB upgrade or FOTA upgrade command at this time, you need to interrupt the ongoing B-side upgrade. If the USB upgrade or FOTA upgrade is not a successful upgrade, the current B-side upgrade may not succeed or exist. In order to ensure the integrity of the B-side upgrade, you can respond to the USB upgrade or FOTA upgrade command after the B-side upgrade is completed.

[0120] In a specific embodiment, USB upgrade or FOTA is usually a manual operation with the highest authority, and USB upgrade and OTA upgrade are conflicting and only one can be chosen. In this case, USB priority is required. USB upgrade and OTA upgrade may be the same version, so the OTA upgrade package must be deleted during USB upgrade to avoid version confusion.

[0121] It is possible that the manual operation of the equipment on site is less selective, for example, the version loaded in the USB cannot be replaced in time for a long time, and can only be used for on-site remediation. When the remote OTA upgrade is normal, the USB insertion may be a misoperation, and the current remote OTA upgrade cannot be interrupted casually. Therefore, after the B-side upgrade is completed, respond to the USB upgrade or FOTA upgrade command to flash the B-side.

[0122] In this embodiment, upgrading the B side includes:

[0123] Check the OTA upgrade package to determine whether it includes parts that do not support direct copying of the A / B surface;

[0124] If, including, then determine whether the B-side upgrade is completed without supporting the part of direct copying of A / B side;

[0125] If completed, then upgrade the A side according to the permission instruction received corresponding to the OTA upgrade permission request. Otherwise, after the B side upgrade completes the part that does not support direct copying of the A / B side, send the OTA upgrade permission request.

[0126] Specifically, in this embodiment, the OTA upgrade package may not be a complete upgrade package, and the upgrade content needs to be added multiple times. However, each time a part of the B side is upgraded, the A side is upgraded, which requires multiple permission requests, occupying a lot of human-computer interaction. The B side can be upgraded completely, that is, the part that does not support direct copying of the A / B side is also upgraded after the B side is upgraded, and then the A side can be upgraded together. At this time, only one request for the OTA upgrade permission of the A side is required, and the user only needs to grant the permission once, which simplifies the waiting and operation of the user during the OTA upgrade process.

[0127] In a specific embodiment, in an OTA upgrade of a vehicle model, the upgrade package is divided into two parts: the ROM (SOC) upgrade package and the MCU upgrade package. The ROM upgrade package must support AB flip upgrade, but the MCU upgrade package may not support AB flip upgrade. So when performing an OTA upgrade, first upgrade the B side of the ROM, and keep the MCU unchanged. After the upgrade of the B side of the ROM is completed and the user agrees to the upgrade, if the upgrade conditions are met, first upgrade the A side MCU, and then execute the ROM B side flip to the A side.

[0128] In this embodiment, it also includes:

[0129] Check whether the upgrade task exists;

[0130] If yes, send an OTA upgrade permission request and determine whether a permission instruction for the OTA upgrade permission request is received;

[0131] If,received, then confirm whether the system is in the non-stop operation time window;

[0132] If yes, then download the OTA upgrade package and perform the B-side upgrade;

[0133] Determine whether the upgrade of side B is completed;

[0134] If, completed, then confirm whether the system is in the stop operation time window;

[0135] If yes, then confirm whether the sustainable output time of the power supply is greater than the preset time threshold of the A-side upgrade;

[0136] If, is greater than, the control power supply maintains continuous output and the A side is upgraded simultaneously;

[0137] It also includes determining whether the upgrade of the A side is successful;

[0138] If,unsuccessful, restore the A side to factory status.

[0139] Specifically, in this embodiment, whether the OTA upgrade is from a remote server or a USB storage disk, it is necessary to obtain user authorization for this OTA upgrade. As long as the authorization for this OTA upgrade is completed, there is no need to bother the user to participate in other work. When the existence of the upgrade task is queried, the user's authorization can be obtained first, and then the upgrade work can be completed automatically after obtaining the authorization. For example, when the system is in a non-stop operation time window, the user is driving the vehicle. At this time, the battery is sufficient, and there will be no impact on the currently running side A, and no downtime will occur. When the upgrade of side B is completed and side A needs to be upgraded, it is selected during the system's stop operation time window. At this time, the user is not driving the vehicle, and no user authorization is required, and no harassment is caused to personnel. The next time the user starts the vehicle, the results of the OTA upgrade results can be directly presented.

[0140] It is possible that the A-side upgrade fails and the remedial measures are being taken to restore the A-side to factory status, which will not affect the basic interface functions required by users for immediate travel. When the system is in the downtime window again, the A-side upgrade can be remedied, or the user authorization request for OTA upgrade can be initiated again, and then the A-side upgrade can be remedied and refreshed.

[0141] Figure 2 It is a structural diagram of a vehicle cabin OTA upgrade device provided by one or more embodiments of the present invention.

[0142] like Figure 2 The vehicle cockpit OTA upgrade device shown includes: a query module, a request module, a judgment module, an upgrade module, a permission module, and an execution module;

[0143] Query module, used to query whether the upgrade task exists;

[0144] The request module is used to request the cloud to download the OTA upgrade package and perform B-side upgrade if it does not exist;

[0145] A judgment module is used to judge whether the upgrade of the B side is completed;

[0146] The upgrade module is used to, if completed, upgrade the A side according to the downloaded OTA upgrade package;

[0147] Permission module, used to send OTA upgrade permission request before upgrading the A surface;

[0148] The execution module is used to upgrade the A side according to the permission instruction received corresponding to the OTA upgrade permission request.

[0149] It is worth noting that although the present system only discloses a query module, a request module, a judgment module, an upgrade module, a permission module, and an execution module, it does not mean that the present device is limited to the above-mentioned basic functional modules. Rather, what the present invention wants to express is that, based on the above-mentioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. In other words, the present system is open rather than closed. Just because the present embodiment only discloses individual basic functional modules, it cannot be considered that the scope of protection of the claims of the present invention is limited to the above-mentioned disclosed basic functional modules.

[0150] Through the above scheme, the following beneficial technical effects are obtained:

[0151] This application distinguishes the trigger conditions of side B and side A during OTA upgrades, so that human participation is involved when flashing data on side A, reducing the process time for human participation in OTA upgrades and reducing the discomfort of human participation in OTA upgrades.

[0152] This application determines whether the upgrade of side A is successful, and restores side A to factory settings if it is unsuccessful, to prevent the vehicle from being stopped due to OTA upgrade failure.

[0153] This application completes the OTA upgrade of side A after completely flashing the OTA upgrade package of side B, preventing repeated flashing of data of side B and side A, and reducing the number and frequency of sending OTA upgrade permission requests.

[0154] Figure 3 A schematic diagram of a cloud-downloaded OTA upgrade package upgrade according to a specific embodiment of the present invention.

[0155] Figure 4 A schematic diagram of a USB or FOTA upgrade intervention according to a specific embodiment of the present invention.

[0156] Figure 5 A schematic diagram of a B-side upgrade process according to a specific embodiment of the present invention.

[0157] In a specific embodiment, OTA upgrade mainly includes the steps of upgrade task query, upgrade package download, B-side upgrade, user upgrade prompt, and A-side upgrade.

[0158] like Figure 3 As shown, the car computer starts up and enters the Launcher to determine whether it is currently in USB upgrade mode or FOTA mode. If so, it will no longer request the upgrade task from the cloud and will make the judgment again at the next startup. If not, it will query the cloud for new tasks. The request parameters carry the ROM version number, vehicle model, VIN, and vehicle software version. If there is a new upgrade task, download the upgrade version description file and parse it, verify the vehicle model, car computer memory, ROM / MCU version number, and upgrade type, and start downloading the upgrade package after the verification passes.

[0159] The OTA upgrade package is downloaded silently, and the download interface will not be presented to the user, nor will there be any prompts such as download abnormalities. After the upgrade package is downloaded, the signature and integrity verification of the upgrade package are required. If the verification passes, the B-side upgrade will be performed.

[0160] In this embodiment, if Figure 4 , 5As shown, the B side is installed silently, and no interface will be presented to the user, nor will there be any abnormal prompts. During the B side upgrade, the user receives a FOTA / USB upgrade notification, stops flashing the B side, deletes the downloaded content, and responds to the FOTA / USB upgrade. If during the B side upgrade, the OTA service is forcibly terminated due to power failure or external reasons or restoring factory settings, you can only wait until the OTA service is restarted to recheck whether there is an upgrade, and then continue downloading or re-flashing the side.

[0161] The upgrade of side B is completed, and the user is prompted that a new OTA version is available for upgrade. The user can choose to upgrade after leaving the car or make an appointment for the upgrade. If the user agrees to the upgrade, the upgrade of side A will begin. Before installation, it is necessary to detect the P gear, the vehicle speed is 0, and the remaining power is > 20%, and the power awake status is monitored. When the conditions are met, the upgrade of side A will begin, and the power will be pulled through the SOA interface to ensure the power supply status during the OTA upgrade. When the upgrade is completed, the car computer will be restarted, and the upgrade results will be reported to the cloud, and the vehicle will automatically enter sleep mode. When the user uses the car next time, it will be prompted that the upgrade is complete.

[0162] In another specific embodiment, after the cockpit upgrade package is made, the operator will transmit it to the OTA cloud platform, configure the version description file and the encryption file at the same time, and select the model to which the upgrade package is to be released after the configuration is completed, and release the task. After the vehicle is powered on, a new task is detected, the version description file is downloaded, and the task verification is performed after the file is parsed locally. After the verification passes, the upgrade package is silently downloaded; after the download is completed, the integrity of the upgrade package is verified, and the B side is silently upgraded after the verification passes. After the B side is upgraded, the upgrade icon is displayed in the status bar of the vehicle interface, and the upgrade application has a small red dot, and the message center will prompt that there is a new version. The user can click to view the upgrade version description and choose whether to upgrade after leaving the car or make an appointment for the upgrade. The user chooses to upgrade and can still use the vehicle normally. When the user finishes using the car and leaves the car and locks the car, the OTA service determines that the user has agreed to this upgrade and starts to monitor the power status. When it enters the awake state, it starts to upgrade and restarts. After the upgrade is completed, the vehicle enters the dormant state. The next time the user uses the car, it prompts that the upgrade is successful and the latest ROM version number, and the status bar upgrade icon and the upgrade application small red dot are eliminated on the interface, and the upgrade is completed.

[0163] Figure 6 A block diagram of an electronic device structure of a vehicle cockpit OTA upgrade method provided by one or more embodiments of the present invention.

[0164] like Figure 6 As shown, the present application provides an electronic device, including: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus;

[0165] A computer program is stored in the memory. When the computer program is executed by the processor, the processor executes the steps of a vehicle cockpit OTA upgrade method.

[0166] The present application also provides a computer-readable storage medium storing a computer program executable by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of a vehicle cabin OTA upgrade method.

[0167] The present application also provides a vehicle, comprising:

[0168] An electronic device, used to implement the steps of the vehicle cockpit OTA upgrade method;

[0169] A processor, wherein the processor runs a program, and when the program runs, the steps of the vehicle cockpit OTA upgrade method are executed based on the data output by the electronic device;

[0170] The storage medium is used to store a program, and when the program is running, it executes the steps of the vehicle cockpit OTA upgrade method for the data output from the electronic device.

[0171] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0172] The electronic device includes a hardware layer, an operating system layer running on the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and a memory. The operating system can be any one or more computer operating systems that implement electronic device control through a process, such as a Linux operating system, a Unix operating system, an Android operating system, an iOS operating system, or a Windows operating system. In addition, in an embodiment of the present invention, the electronic device can be a handheld device such as a smart phone or a tablet computer, or can be an electronic device such as a desktop computer or a portable computer, which is not particularly limited in the embodiment of the present invention.

[0173] The execution subject of the electronic device control in the embodiment of the present invention may be an electronic device, or a functional module in the electronic device that can call and execute a program. The electronic device may obtain the firmware corresponding to the storage medium. The firmware corresponding to the storage medium is provided by the supplier. The firmware corresponding to different storage media may be the same or different, which is not limited here. After the electronic device obtains the firmware corresponding to the storage medium, the firmware corresponding to the storage medium may be written into the storage medium, specifically, the firmware corresponding to the storage medium may be burned into the storage medium. The process of burning the firmware into the storage medium may be implemented using existing technology, which will not be described in detail in the embodiment of the present invention.

[0174] The electronic device may also obtain a reset command corresponding to the storage medium. The reset command corresponding to the storage medium is provided by the supplier. The reset commands corresponding to different storage media may be the same or different, and are not limited here.

[0175] At this time, the storage medium of the electronic device is a storage medium in which the corresponding firmware is written, and the electronic device can respond to the reset command corresponding to the storage medium in the storage medium in which the corresponding firmware is written, so that the electronic device resets the storage medium in which the corresponding firmware is written according to the reset command corresponding to the storage medium. The process of resetting the storage medium according to the reset command can be implemented by the existing technology and will not be described in detail in the embodiments of the present invention.

[0176] For the convenience of description, the above devices are described in terms of functions and are divided into various units and modules. Of course, when implementing the present application, the functions of each unit and module can be implemented in the same or multiple software and / or hardware.

[0177] Those skilled in the art will appreciate that, unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as those generally understood by those skilled in the art in the art to which the present invention belongs. It should also be understood that terms such as those defined in general dictionaries should be understood to have meanings consistent with the meanings in the context of the prior art, and will not be interpreted with idealized or overly formal meanings unless specifically defined.

[0178] For the method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should know that the embodiments of the present invention are not limited by the order of the actions described, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present invention.

[0179] It can be known from the description of the above implementation modes that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solution of the present application can be essentially or partly contributed to the prior art in the form of a software product, which can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute the methods described in the various implementation modes of the present application or certain parts of the implementation modes.

[0180] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A vehicle cockpit OTA upgrade method, characterized in that: The vehicle cockpit OTA upgrade method comprises: Check whether the upgrade task exists; If it does not exist, then request to download the OTA upgrade package from the cloud and perform the B-side upgrade; Determine whether the upgrade of side B is completed; If completed, upgrade the A side according to the downloaded OTA upgrade package; Among them, before upgrading the A side, send an OTA upgrade permission request; According to the permission instruction received corresponding to the OTA upgrade permission request, the A side is upgraded.

2. The vehicle cockpit OTA upgrade method according to claim 1, characterized in that: The A-side upgrade includes: Confirm whether the system is in the shutdown time window; If yes, then confirm whether the sustainable output time of the power supply is greater than the preset time threshold of the A-side upgrade; If, is greater than, the control power supply maintains continuous output and the A side is upgraded simultaneously; It also includes determining whether the upgrade of the A side is successful; If,unsuccessful, restore the A side to factory status.

3. The vehicle cockpit OTA upgrade method according to claim 2, characterized in that: The sending of the OTA upgrade permission request includes: Get information about vehicle status; The vehicle status information includes the vehicle being ready to be plugged in, the vehicle resuming parking, and the vehicle being parked at a preset position; According to the current state of the vehicle, which is the state of the vehicle preparing to be plugged in, the state of the vehicle resuming parking, or / and the state of the vehicle being parked at a preset position, an OTA upgrade permission request is sent.

4. The vehicle cockpit OTA upgrade method according to claim 3, characterized in that: The querying whether the upgrade task exists also includes: Determine whether the system has received a USB upgrade or FOTA upgrade notification; If,received, the ongoing B-side upgrade is stopped and the downloaded data is deleted; Respond to USB upgrade or FOTA upgrade instructions and flash side B.

5. The vehicle cockpit OTA upgrade method according to claim 4, characterized in that: The B-side upgrade includes: Check the OTA upgrade package to determine whether it includes parts that do not support direct copying of the A / B surface; If, including, then determine whether the B-side upgrade is completed without supporting the part of direct copying of A / B side; If completed, then according to the permission instruction received corresponding to the OTA upgrade permission request, the A side is upgraded; otherwise, after the B side upgrade completes the part that does not support direct copying of the A / B side, an OTA upgrade permission request is sent.

6. The vehicle cockpit OTA upgrade method according to claim 5, characterized in that: Also includes: Check whether the upgrade task exists; If yes, send an OTA upgrade permission request and determine whether a permission instruction for the OTA upgrade permission request is received; If,received, then confirm whether the system is in the non-stop operation time window; If yes, then download the OTA upgrade package and perform the B-side upgrade; Determine whether the upgrade of side B is completed; If, completed, then confirm whether the system is in the stop operation time window; If yes, then confirm whether the sustainable output time of the power supply is greater than the preset time threshold of the A-side upgrade; If, is greater than, the control power supply maintains continuous output and the A side is upgraded simultaneously; It also includes determining whether the upgrade of the A side is successful; If,unsuccessful, restore the A side to factory status.

7. A vehicle cockpit OTA upgrade device, characterized in that: The vehicle cockpit OTA upgrade device comprises: Query module, used to query whether the upgrade task exists; The request module is used to request the cloud to download the OTA upgrade package and perform B-side upgrade if it does not exist; A judgment module is used to judge whether the upgrade of the B side is completed; The upgrade module is used to, if completed, upgrade the A side according to the downloaded OTA upgrade package; Permission module, used to send OTA upgrade permission request before upgrading the A surface; The execution module is used to upgrade the A side according to the permission instruction received corresponding to the OTA upgrade permission request.

8. An electronic device, characterized in that: include: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus; A computer program is stored in the memory. When the computer program is executed by the processor, the processor executes the steps of the vehicle cabin OTA upgrade method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: include: It stores a computer program that can be executed by an electronic device. When the computer program runs on the electronic device, the electronic device executes the steps of the vehicle cabin OTA upgrade method described in any one of claims 1 to 6.

10. A vehicle, characterized in that: include: An electronic device, used to implement the steps of the vehicle cockpit OTA upgrade method according to any one of claims 1 to 6; A processor, wherein the processor runs a program, and when the program runs, data output from the electronic device executes the steps of the vehicle cockpit OTA upgrade method according to any one of claims 1 to 6; A storage medium for storing a program, wherein when the program is running, the program executes the steps of the vehicle cabin OTA upgrade method according to any one of claims 1 to 6 for data output from an electronic device.