OTA upgrading method and related device
By setting up the upgrade strategy supported by this model in the on-board terminal and matching it with the policies issued in the cloud, the errors caused by policy mismatch in OTA upgrades are solved, and the stability and reliability of OTA upgrades are improved.
Patent Information
- Application Number
- CN202510322034.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-18
- Publication Date
- 2025-06-27
AI Technical Summary
During the OTA upgrade process, the upgrade strategy issued by the cloud may not be in line with the current model, resulting in an error in the upgrade strategy and may cause uncertain errors, affecting the stability and reliability of the OTA upgrade.
Set the second upgrade strategy supported by this model in the vehicle terminal in the vehicle model configuration file, and match it with the first upgrade strategy issued by the cloud server. Only perform OTA upgrades when the policy matches and the vehicle status meets the status.
By matching the upgrade strategy and vehicle status, errors caused by mismatch between the policies issued by the cloud server and the policies supported by the model are avoided, and the stability and reliability of OTA upgrades are improved.
Smart Images

Figure CN120215983A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technologies, and in particular, to an OTA upgrade method and related devices. Background Art
[0002] In the OTA (Over-the-Air Technology) upgrade process, first, the cloud sends a software upgrade task, and along with the software upgrade task, an upgrade policy configured in the cloud is also sent. Before performing the software upgrade task, the vehicle terminal will obtain the current vehicle information according to the upgrade policy sent by the cloud for policy check, such as determining that the current vehicle speed is less than a threshold and the battery power is greater than a threshold. Whether the vehicle can be upgraded is confirmed through the upgrade policy check.
[0003] Currently, when the cloud sends an upgrade policy, the upgrade policy is bound to the ECU, and the vehicle terminal differentiates the upgrade policy by vehicle model. In this case, the upgrade policy sent by the cloud may not conform to the current vehicle model or there may be an error in the sending, resulting in problems with the sent upgrade policy. If there is an error in the sent upgrade policy, the vehicle terminal will perform a check according to the sent upgrade policy and cannot detect that there is a problem with the upgrade policy, which may cause uncertain errors. Summary of the Invention
[0004] In view of the above problems, this application provides an OTA upgrade method and related devices to ensure the stability and reliability of OTA upgrades. The specific solutions are as follows:
[0005] A first aspect of this application provides an OTA upgrade method, including:
[0006] Obtain a first upgrade policy in an upgrade package sent by a cloud server;
[0007] Read a configuration file of the vehicle model to obtain a second upgrade policy supported by the vehicle model;
[0008] Match the first upgrade policy with the second upgrade policy;
[0009] If the first upgrade policy matches the second upgrade policy, determine whether the vehicle status conforms to the first upgrade policy;
[0010] If the vehicle status conforms to the first upgrade policy, perform an OTA upgrade.
[0011] In a possible implementation, matching the first upgrade policy with the second upgrade policy includes:
[0012] Match a first field in the first upgrade policy with a second field in the second upgrade policy;
[0013] If there is a second field in the second upgrade policy that matches the first field, determine whether the threshold range of the first field is within the threshold range of the second field that matches the first field;
[0014] If the threshold range of the first field is within the threshold range of the second field that matches the first field, determine that the first upgrade policy matches the second upgrade policy.
[0015] In a possible implementation, the OTA upgrade method further includes:
[0016] If there is no second field in the second upgrade policy that matches the first field, or the threshold range of the first field is not within the threshold range of the second field that matches the first field, determine that the first upgrade policy does not match the second upgrade policy.
[0017] In a possible implementation, the OTA upgrade method further includes:
[0018] If the first upgrade policy does not match the second upgrade policy, determine that the verification of the first upgrade policy fails, and send the first upgrade policy with the verification failure to the user terminal and the cloud server.
[0019] In a possible implementation, the OTA upgrade method further includes:
[0020] Receive a configuration file update instruction sent by the cloud server, and obtain the target configuration file of this vehicle type carried in the configuration file update instruction, where the target configuration file of this vehicle type includes the target second upgrade policy supported by this vehicle type;
[0021] Update the configuration file of this vehicle type to the target configuration file of this vehicle type.
[0022] The second aspect of this application provides an OTA upgrade device, including:
[0023] A first policy acquisition unit, configured to acquire a first upgrade policy in an upgrade package sent by a cloud server;
[0024] A second policy acquisition unit, configured to read a configuration file of this vehicle type and acquire a second upgrade policy supported by this vehicle type;
[0025] A policy verification unit, configured to match the first upgrade policy and the second upgrade policy;
[0026] An upgrade verification unit, configured to, if the first upgrade policy matches the second upgrade policy, determine whether the vehicle state conforms to the first upgrade policy;
[0027] An upgrade execution unit, configured to perform OTA upgrade if the vehicle status meets the first upgrade policy.
[0028] A third aspect of the present application provides an OTA upgrade system, including: a cloud server and multiple vehicle-mounted terminals, each of the vehicle-mounted terminals corresponding to a vehicle model;
[0029] The cloud server is configured to determine a target ECU corresponding to the OTA upgrade, set a first upgrade policy corresponding to the target ECU, and send the first upgrade policy to the vehicle-mounted terminal including the target ECU together with the upgrade package;
[0030] The vehicle-mounted terminal is configured to obtain the first upgrade policy in the upgrade package sent by the cloud server, read the configuration file of this vehicle model, obtain a second upgrade policy supported by this vehicle model, match the first upgrade policy with the second upgrade policy, if the first upgrade policy matches the second upgrade policy, determine whether the vehicle status meets the first upgrade policy, and if the vehicle status meets the first upgrade policy, perform OTA upgrade.
[0031] In a possible implementation, the cloud server is further configured to set a configuration file corresponding to each vehicle model, and send the configuration file corresponding to each vehicle model to the corresponding vehicle-mounted terminal respectively, and the configuration file corresponding to each vehicle model includes a second upgrade policy supported by the vehicle model.
[0032] A fourth aspect of the present application provides a vehicle-mounted terminal, including at least one processor and a memory connected to the processor, wherein:
[0033] The memory is configured to store a computer program;
[0034] The processor is configured to execute the computer program so that the vehicle-mounted terminal can implement the OTA upgrade method as described in the first aspect or any implementation manner of the first aspect above.
[0035] A sixth aspect of the present application provides a computer storage medium, the storage medium carrying one or more computer programs, when the one or more computer programs are executed by a vehicle-mounted terminal, capable of enabling the vehicle-mounted terminal to implement the OTA upgrade method as described in the first aspect or any implementation manner of the first aspect above.
[0036] With the above technical solution, an OTA upgrade method and related device provided by the present application set a second upgrade strategy supported by the vehicle model in the vehicle model configuration file of the in-vehicle terminal. After obtaining the upgrade package sent by the cloud server, the first upgrade strategy in the upgrade package is matched with the second upgrade strategy. When the first upgrade strategy matches the second upgrade strategy and the vehicle state meets the first upgrade strategy, OTA upgrade is executed, avoiding errors caused by upgrades when the first upgrade strategy sent by the cloud server does not match the second upgrade strategy supported by the vehicle model, and ensuring the stability and reliability of OTA upgrade. BRIEF DESCRIPTION OF THE DRAWINGS
[0037] In combination with the accompanying drawings and with reference to the following specific embodiments, the above and other features, advantages and aspects of the various embodiments of the present disclosure will become more apparent. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic and the original elements and elements are not necessarily drawn to scale.
[0038] Figure 1 FIG. [ID] is a schematic diagram of a system architecture provided by the present application;
[0039] Figure 2 FIG. [ID] is a schematic diagram of the structure of a terminal 100 provided by the present application;
[0040] Figure 3 FIG. [ID] is a schematic diagram of the structure of a server 200 provided by the present application;
[0041] Figure 4 FIG. [ID] is a flowchart of an OTA upgrade method provided by an embodiment of the present application;
[0042] Figure 5 FIG. [ID] is a flowchart of another OTA upgrade method provided by an embodiment of the present application;
[0043] Figure 6 FIG. [ID] is a schematic diagram of the transfer of upgrade strategies provided by an embodiment of the present application;
[0044] Figure 7 FIG. [ID] is a schematic diagram of the structure of an OTA upgrade device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0045] In the following description, for the purpose of ensuring the accuracy of citation and the fluency of reading, the key technical terms, abbreviations or acronyms involved in the text are summarized and explained as follows:
[0046] The following describes the embodiments of the present application in conjunction with the accompanying drawings in the embodiments of the present application. The terms used in the embodiments of the present application are only used to explain the specific embodiments of the present application and are not intended to limit the present application.
[0047] The embodiments of the present application will be described below in conjunction with the accompanying drawings. As can be known to those of ordinary skill in the art, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.
[0048] The terms "first", "second", etc. in the specification, claims and above-mentioned drawings of the present application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is only a way of distinguishing when describing objects with the same attributes in the embodiments of the present application. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device comprising a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.
[0049] See Figure 1 , Figure 1 shows a schematic diagram of a system architecture. The system may include a terminal 100 and a server 200. Among them, the server 200 may include one or more servers ( Figure 1 illustrated by taking one server as an example), and the server 200 may provide the method provided by the embodiments of the present application for one or more terminals.
[0050] Among them, an application program may be installed on the terminal 100. The above application program provides an interface. The terminal 100 may receive relevant parameters input by the user on the interface, such as an "upgrade immediately" instruction or a "reservation upgrade" instruction. When the terminal 100 receives the "upgrade immediately" instruction, it starts the upgrade process, or starts the upgrade process when the reservation upgrade condition is met. The server 200 may send data such as upgrade packages and configuration files to the terminal 100, and the terminal 100 may also feedback data such as upgrade results to the server 200.
[0051] Next, describe Figure 1 the product form of the terminal 100 in
[0052] The terminal 100 in the embodiments of the present application may be an in-vehicle terminal device, and the embodiments of the present application do not make any restrictions on this.
[0053] Figure 2 shows an optional hardware structure schematic diagram of the terminal 100.
[0054] Refer to Figure 2As shown, the terminal 100 may include components such as a radio frequency unit 110, a memory 120, an input unit 130, a display unit 140, a camera 150 (optional), an audio circuit 160 (optional), a speaker 161 (optional), a microphone 162 (optional), a headphone jack 163 (optional), a processor 170, an external interface 180, a power supply 190, etc. Those skilled in the art can understand that Figure 2 this is merely an example of the terminal 100 and does not limit the terminal 100. It may include more or fewer components than shown in the figure, or combine certain components, or have different components.
[0055] The input unit 130 can be used to receive input digital or character information and generate key signal inputs related to the user settings and function controls of the terminal 100. Specifically, the input unit 130 may include a touch screen 131 (optional) and / or other input devices 132. The touch screen 131 can collect touch operations of the user thereon or nearby (such as operations of the user using any suitable object such as a finger, a joint, a stylus, etc. on or near the touch screen), and drive the corresponding connection device according to a pre-set program. The touch screen can detect the touch actions of the user on the touch screen, convert the touch actions into touch signals and send them to the processor 170, and can receive and execute the commands sent by the processor 170; the touch signals at least include contact coordinate information. The touch screen 131 can provide an input interface and an output interface between the terminal 100 and the user. In addition, various types such as resistive, capacitive, infrared, and surface acoustic wave can be used to implement the touch screen. In addition to the touch screen 131, the input unit 130 may further include other input devices. Specifically, the other input devices 132 may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control keys, power on / off keys, etc.), a trackball, a mouse, a joystick, etc.
[0056] Among them, the input device 132 can receive input data, etc.
[0057] The display unit 140 can be used to display information input by the user or provided to the user, various menus of the terminal 100, an interaction interface, file display, and / or the playback of any multimedia file. In the embodiments of the present application, the display unit 140 can be used to display an interface for whether to download an upgrade package, an interface for selecting "upgrade immediately" or "schedule upgrade", an upgrade result, etc.
[0058] The memory 120 can be used to store instructions and data. The memory 120 mainly includes a storage instruction area and a storage data area. The storage data area can store various data, such as multimedia files, texts, etc.; the storage instruction area can store software units such as an operating system, applications, instructions required for at least one function, or their subsets or extended sets. It can also include a non-volatile random access memory; it provides the processor 170 with functions including managing the hardware, software, and data resources in the computing processing device, supporting control software and applications. It is also used for storing multimedia files, as well as storing running programs and applications.
[0059] The processor 170 is the control center of the terminal 100. It connects all parts of the entire terminal 100 through various interfaces and lines. By running or executing the instructions stored in the memory 120 and calling the data stored in the memory 120, it executes various functions of the terminal 100 and processes data, thereby exercising overall control over the terminal device. Optionally, the processor 170 may include one or more processing units; preferably, the processor 170 may integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, application programs, etc., and the modem processor mainly processes wireless communications. It can be understood that the above-mentioned modem processor may not be integrated into the processor 170 either. In some embodiments, the processor and the memory can be implemented on a single chip. In some embodiments, they can also be separately implemented on independent chips. The processor 170 can also be used to generate corresponding operation control signals, send them to corresponding components of the computing processing device, read and process the data in the software, especially read and process the data and programs in the memory 120, so that each functional module therein executes corresponding functions, thereby controlling the corresponding components to act according to the requirements of the instructions.
[0060] Among them, the memory 120 can be used to store software codes related to the OTA upgrade method. The processor 170 can execute the steps of the OTA upgrade method or can also schedule other units (such as the above-mentioned input unit 130 and display unit 140) to implement corresponding functions.
[0061] The radio frequency unit 110 (optional) can be used for receiving and transmitting information or signals during a call. For example, after receiving the downlink information from the base station, it is sent to the processor 170 for processing; in addition, the uplink data is sent to the base station. Generally, the RF circuit includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (LNA), a duplexer, etc. In addition, the radio frequency unit 110 can also communicate with network devices and other devices through wireless communication. This wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile communication (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (LTE), email, Short Messaging Service (SMS), etc.
[0062] Among them, in the embodiment of this application, the radio frequency unit 110 can send data to the server 200 and receive the data sent by the server 200.
[0063] It should be understood that the radio frequency unit 110 is optional and can be replaced by other communication interfaces, such as a network port.
[0064] The terminal 100 also includes a power supply 190 (such as a battery) for powering each component. Preferably, the power supply can be logically connected to the processor 170 through a power management system, so as to realize functions such as management of charging, discharging, and power consumption management through the power management system.
[0065] The terminal 100 also includes an external interface 180. This external interface can be a standard Micro USB interface or a multi-pin connector, and can be used to connect the terminal 100 to other devices for communication, or can be used to connect a charger to charge the terminal 100.
[0066] Although not shown, the terminal 100 may also include a flash, a wireless fidelity (WiFi) module, a Bluetooth module, sensors with different functions, etc., which will not be elaborated here. Some or all of the methods described below can be applied to the terminal 100 as Figure 2 shown.
[0067] The following describes Figure 1 the product form of the server 200 in Figure 1 . The server 200 can be a cloud server and includes at least one server.
[0068] Figure 3 A schematic structural diagram of the server 200 is provided, as Figure 3 shown. The server 200 includes a bus 201, a processor 202, a communication interface 203, and a memory 204. The processor 202, the memory 204, and the communication interface 203 communicate with each other through the bus 201.
[0069] The bus 201 can be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity in representation, Figure 3 only a thick line is used to represent it in Figure 3 , but it does not mean that there is only one bus or one type of bus.
[0070] The processor 202 can be any one or more of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Micro Processor (MP), or a Digital Signal Processor (DSP).
[0071] The memory 204 can include volatile memory, such as Random Access Memory (RAM). The memory 204 can also include non-volatile memory, such as Read-Only Memory (ROM), flash memory, a Hard Disk Drive (HDD), or a Solid State Drive (SSD).
[0072] Among them, the memory 204 can be used to store software codes related to the OTA upgrade method, and the processor 202 can execute the steps of the OTA upgrade method of the chip or can also schedule other units to implement corresponding functions.
[0073] Currently, the cloud server manages the upgrade policy in units of ECUs (electronic control units). That is, the upgrade policy is bound to the ECU. The upgrade policies corresponding to different types of ECUs may be different, while the in-vehicle terminal manages the upgrade policy in units of vehicle models, and the upgrade policies corresponding to different vehicle models may be different. The upgrade policy sent by the cloud server may not conform to the current vehicle model. For example, the upgrade policy sent by the cloud server is "vehicle speed is lower than 80", while the upgrade policy supported by the vehicle model where the in-vehicle terminal is located is "vehicle speed range 0 - 60". If the vehicle speed is between 61 - 79, it conforms to the upgrade policy sent by the cloud server, and the in-vehicle terminal will perform OTA upgrade. However, if the vehicle speed does not conform to the upgrade policy supported by the vehicle model where the in-vehicle terminal is located, errors will occur, posing problems such as potential risks to driving safety.
[0074] To solve the above problems, an OTA upgrade method provided by an embodiment of the present application is applied to the above in-vehicle terminal. The OTA upgrade method of the embodiment of the present application will be described in detail below with reference to the accompanying drawings.
[0075] Refer to Figure 4 , Figure 4 which is a schematic flowchart of an OTA upgrade method provided by an embodiment of the present application. As Figure 4 shown, an OTA upgrade method provided by an embodiment of the present application may include steps 401 to 405, and these steps will be described in detail below respectively.
[0076] 401: Obtain the first upgrade policy in the upgrade package sent by the cloud server;
[0077] After the cloud server sends the upgrade package to the in-vehicle terminal, the user needs to confirm whether to download it. If the user confirms the download, the in-vehicle terminal downloads the upgrade package.
[0078] In one possible implementation, after the upgrade package is downloaded and the user triggers the "upgrade immediately" instruction, step 401 is executed.
[0079] In another possible implementation, after the upgrade package is downloaded and the user triggers the "scheduled upgrade" instruction to set the scheduled upgrade time, when the scheduled upgrade times out, that is, when the current time reaches the scheduled upgrade time, step 401 is executed.
[0080] In some embodiments, it is also necessary to detect that the user has left the vehicle before executing step 401.
[0081] It should be noted that the cloud server manages the first upgrade policy in units of ECU types, and the first upgrade policies corresponding to different ECU types may vary. For example, the engine ECU and the transmission ECU respectively correspond to different first upgrade policies.
[0082] The number of the first upgrade strategies of the upgrade package can be 1 or more than 1. Each first upgrade strategy corresponds to a different first field, and the first field corresponds to a threshold range. For example: The first upgrade strategy A is: the vehicle speed is 0, where the vehicle speed is the first field and 0 is the threshold range; the first upgrade strategy B is: the IGN status is ON, where the IGN status is the first field and ON is the threshold range.
[0083] 402: Read the configuration file of this vehicle model to obtain the second upgrade strategies supported by this vehicle model;
[0084] Read the configuration file of this vehicle model, parse the configuration file of this vehicle model according to the format of the configuration file of this vehicle model, and obtain the second upgrade strategies supported by this vehicle model.
[0085] The second upgrade strategies supported by different vehicle models may be different. For example, the second upgrade strategy supported by vehicle model A is a vehicle speed range of 0 - 120, and the second upgrade strategy supported by vehicle model B is a vehicle speed range of 0 - 60.
[0086] The second upgrade strategies on the vehicle side are at least one of the following:
[0087] ① Gear position: P;
[0088] ② Electronic parking brake system: ON;
[0089] ③ IGN (Ignition) status: ON;
[0090] ④ Vehicle charging status: none;
[0091] ⑤ Engine ignition: none;
[0092] ⑥ Battery power is greater than the threshold;
[0093] ⑦ Battery voltage is greater than the threshold;
[0094] ⑧ Large battery pack power is greater than the threshold;
[0095] ⑨ Vehicle speed is less than the threshold;
[0096] ⑩ Engine speed is lower than the threshold.
[0097] That is to say, the number of the second upgrade strategies supported by this vehicle model can be 1 or more than 1. Each second upgrade strategy corresponds to a different second field, and the second field corresponds to a threshold range. For example: The second upgrade strategy A is: the vehicle speed range is 0 - 120, where the vehicle speed is the second field and 0 - 120 is the threshold range; the second upgrade strategy B is: the power range is 0 - 100%, where the power is the second field and 0 - 100% is the threshold range.
[0098] The format of the configuration file for this vehicle model can be XML, plain text, JSON, YAML, TOML, custom binary format, etc., which records the second upgrade strategy supported by this vehicle model. Which type of configuration file to use specifically depends on the actual application, system compatibility, and developer preferences. Each type of configuration file has its own advantages and disadvantages. For example, a plain text configuration file has good cross-platform compatibility, XML is suitable for representing complex data but has cumbersome syntax and a large file size, JSON is concise, has a small file size, and good compatibility but does not support comments. Therefore, it is necessary to make a choice based on the advantages and disadvantages of the configuration file, considering aspects such as parsing efficiency, cross-platform compatibility, requirements, readability, and file size.
[0099] For many vehicle models, the method of using a configuration file to manage the second upgrade strategy is relatively simple and convenient for parsing to obtain the second upgrade strategy.
[0100] 403: Match the first upgrade strategy with the second upgrade strategy;
[0101] Specifically, first match the first field in the first upgrade strategy with the second field in the second upgrade strategy. If there is a second field in the second upgrade strategy that matches the first field, then determine whether the threshold range of the first field is within the threshold range of the second field that the first field matches. If the threshold range of the first field is within the threshold range of the second field that the first field matches, it is determined that the first upgrade strategy matches the second upgrade strategy.
[0102] 404: If the first upgrade strategy matches the second upgrade strategy, determine whether the vehicle status conforms to the first upgrade strategy;
[0103] Exemplarily, the number of the first upgrade strategies is 2. The first upgrade strategy A is: the engine is not ignited, and the first upgrade strategy B is: the battery power is greater than 60%. Then obtain the engine status and battery power in the vehicle status, and determine whether the engine status is not ignited and the battery power is greater than 60%.
[0104] 405: If the vehicle status conforms to the first upgrade strategy, perform OTA upgrade.
[0105] If the vehicle status conforms to the first upgrade strategy, it means that the vehicle status meets the upgrade conditions. Perform OTA upgrade to upgrade the software of the target ECU.
[0106] An OTA upgrade method disclosed in this embodiment sets a second upgrade policy supported by this vehicle model in the vehicle model configuration file of the vehicle terminal. After obtaining the upgrade package sent by the cloud server, the first upgrade policy in the upgrade package is matched with the second upgrade policy. When the first upgrade policy matches the second upgrade policy and the vehicle state meets the first upgrade policy, OTA upgrade is executed, avoiding errors caused by upgrades when the first upgrade policy sent by the cloud server does not match the second upgrade policy supported by the vehicle model, and ensuring the stability and reliability of OTA upgrade.
[0107] In the above embodiment, matching the first upgrade policy with the second upgrade policy includes multiple scenarios.
[0108] Scenario 1
[0109] If the number of both the first upgrade policy and the second upgrade policy is 1, then match the first upgrade policy with the second upgrade policy. Specifically: determine whether the first field in the first upgrade policy is consistent with the second field in the second upgrade policy. If the first field in the first upgrade policy is not consistent with the second field in the second upgrade policy, then the first upgrade policy and the second upgrade policy do not match; if the first field in the first upgrade policy is consistent with the second field in the second upgrade policy, then determine whether the threshold range of the first field is within the threshold range of the second field. If the threshold range of the first field is within the threshold range of the second field, then the first upgrade policy and the second upgrade policy match; if the threshold range of the first field is not within the threshold range of the second field, then the first upgrade policy and the second upgrade policy do not match.
[0110] Scenario 2
[0111] If the number of the first upgrade policy is 1 and the number of the second upgrade policy is more than 1, then the first upgrade policy needs to be matched with multiple second policies respectively. Specifically: determine whether the first field in the first upgrade policy matches one of the second fields in the multiple second policies. If not, then the first upgrade policy and the second upgrade policy do not match; if they match, then determine whether the threshold range of the first field in the first upgrade policy is within the threshold range of the second field that the first field matches. If the threshold range of the first field is within the threshold range of the second field that the first field matches, then the first upgrade policy and the second upgrade policy match; if the threshold range of the first field is not within the threshold range of the second field that the first field matches, then the first upgrade policy and the second upgrade policy do not match.
[0112] Scenario 3
[0113] If the number of the first upgrade policy is more than 1 and the number of the second upgrade policy is 1, or the number of the first upgrade policy is greater than the number of the second upgrade policy, then there must be a second upgrade policy that cannot be matched with the first upgrade policy.
[0114] Scenario Four
[0115] If the number of the first upgrade policies is more than 1, the number of the second upgrade policies is also more than 1, and the number of the first upgrade policies is equal to or less than the number of the second upgrade policies, then match the first fields in the multiple first upgrade policies with the second fields in the multiple second upgrade policies respectively. If all the first fields in the first upgrade policies can be matched with the second fields in the second upgrade policies, then further determine whether the threshold ranges of the first fields are all within the threshold ranges of the second fields matched by the first fields respectively. If the threshold range of the first field is within the threshold range of the second field matched by the first field, then the first upgrade policy matches the second upgrade policy; if the threshold range of the first field is not within the threshold range of the second field matched by the first field, then the first upgrade policy does not match the second upgrade policy.
[0116] Please refer to Figure 5 , Figure 5 which is a schematic flow of an OTA upgrade method provided by an embodiment of the present application. As Figure 5 shown, an OTA upgrade method provided by an embodiment of the present application may include steps 501 to 507, and the following will describe these steps in detail respectively.
[0117] 501: Obtain the first upgrade policy in the upgrade package sent by the cloud server;
[0118] 502: Read the configuration file of this vehicle model and obtain the second upgrade policy supported by this vehicle model;
[0119] 503: Match the first upgrade policy with the second upgrade policy;
[0120] If the first upgrade policy does not match the second upgrade policy, execute 504: Determine that the verification of the first upgrade policy fails, and send the first upgrade policy with verification failure to the user terminal and the cloud server;
[0121] If the first upgrade policy matches the second upgrade policy, execute 505: Judge whether the vehicle status conforms to the first upgrade policy;
[0122] If the vehicle status does not conform to the first upgrade policy, execute 506: Prompt that the vehicle status does not conform to the first upgrade policy;
[0123] If the vehicle status conforms to the first upgrade policy, execute 507: Perform OTA upgrade.
[0124] For the specific implementation of the above steps 501, 502, 503, 505, 507, please refer to Figure 4 the corresponding embodiments, which will not be elaborated here.
[0125] If there is no second field in the second upgrade policy that matches the first field, or the threshold range of the first field is not within the threshold range of the second field that matches the first field, it is determined that the first upgrade policy does not match the second upgrade policy. In the case where the first upgrade policy does not match the second upgrade policy, it is determined that the verification of the first upgrade policy fails, and the first upgrade policy with verification failure is sent to the user terminal and the cloud server, so that the cloud server can repair the first upgrade policy with verification failure and then reissue the upgrade activity, enabling the in-vehicle terminal to execute again Figure 5 the steps of the OTA upgrade method shown.
[0126] Furthermore, in order to facilitate the cloud server to repair the first upgrade policy with verification failure, the reason for the verification failure can be sent to the cloud server while sending the first upgrade policy with verification failure, such as that there is no second field in the second upgrade policy that matches the first field, or the threshold range of the first field is not within the threshold range of the second field that matches the first field.
[0127] The following is illustrated by a specific example shown in Table 1.
[0128] Table 1
[0129]
[0130] Examples illustrate the first upgrade policy and the second upgrade policy corresponding to 3 different vehicle models:
[0131] For example, in the case of vehicle model 1, the second upgrade policy ① stipulates that the speed range is 0 - 120, and the first upgrade policy ① requires the speed to be 0, supports querying the speed and the speed is within the range; the second upgrade policy ② also matches the issued upgrade policy ②. Therefore, the first upgrade policy matches the second upgrade policy, and there is no problem with the first upgrade policy issued by the cloud server, and the policy check can continue;
[0132] For example, in the case of vehicle model 2, the second upgrade policy ② stipulates that the power range is 0 - 100%, and the first upgrade policy ② requires the power to be greater than 60%, supports querying the power and the power is within the range; while the first upgrade policy ① requires the engine to be in an unignited state, and there is no relevant second upgrade policy in the configuration file to support querying whether the engine is ignited. Therefore, the first upgrade policy ① issued by the cloud server is incorrect, and it can be reported to the cloud server that the verification of the first upgrade policy ① fails, and the reason for the verification failure is that there is no second field in the second upgrade policy that matches the first field.
[0133] In the case of Model 3, the first upgrade strategy ② requires the engine to be not ignited, the second upgrade strategy ② supports querying the engine, and the first upgrade strategy ② matches the second upgrade strategy ②; while the second upgrade strategy ① stipulates that the vehicle speed range is 0 - 60, and the first upgrade strategy ① requires the vehicle speed to be lower than 80. If the vehicle speed is between 61 - 79, it does not meet the requirements of the second upgrade strategy ②, that is, the first upgrade strategy ① does not match the second upgrade strategy ①. Therefore, the first upgrade strategy ① sent by the cloud server is incorrect, and it can report to the cloud server that the verification of the first upgrade strategy ① fails. The reason for the verification failure is that the threshold range of the first field is not within the threshold range of the second field that the first field matches.
[0134] As Figure 6 shown, developers write the second upgrade strategy supported by the vehicle model into a configuration file, and deploy the configuration file to the in-vehicle terminal during the function detection whole vehicle off-line process (EOL, End of Line) before the vehicle product goes off-line. The cloud server also sets the ECU upgrade strategy, that is, the above-mentioned first upgrade strategy, and then selects the type of ECU to be upgraded, and sends an upgrade task to the in-vehicle terminal. The in-vehicle terminal compares the first upgrade strategy and the second upgrade strategy for verification, and determines whether to continue the OTA upgrade process according to the verification result. In addition, the vehicle model will definitely be upgraded and iterated in the future, and there is a need to update the second upgrade strategy. The OTA upgrade method provided in this embodiment can also add methods such as calibration, and update the configuration file by the method sent by the cloud server to realize the dynamic update of the configuration file. Specifically, the in-vehicle terminal receives the configuration file update instruction sent by the cloud server, obtains the target configuration file of this vehicle model carried by the configuration file update instruction. The target configuration file of this vehicle model includes the target second upgrade strategy supported by this vehicle model, and then updates the configuration file of this vehicle model to the target configuration file of this vehicle model.
[0135] The above introduces an OTA upgrade method provided by an embodiment of the present application. The following will introduce the device for executing the above OTA upgrade method.
[0136] Please refer to Figure 7 , Figure 7 which is a schematic structural diagram of an OTA upgrade device provided by an embodiment of the present application. As Figure 7 shown, the OTA upgrade device includes:
[0137] A first strategy acquisition unit 701, configured to acquire the first upgrade strategy in the upgrade package sent by the cloud server;
[0138] A second strategy acquisition unit 702, configured to read the configuration file of this vehicle model and acquire the second upgrade strategy supported by this vehicle model;
[0139] A strategy verification unit 703, configured to match the first upgrade strategy and the second upgrade strategy;
[0140] An upgrade verification unit 704, configured to determine whether the vehicle status conforms to the first upgrade policy if the first upgrade policy matches the second upgrade policy;
[0141] An upgrade execution unit 705, configured to perform an OTA upgrade if the vehicle status conforms to the first upgrade policy.
[0142] In a possible implementation, the policy verification unit 703 is specifically configured to match a first field in the first upgrade policy with a second field in the second upgrade policy; if there is a second field in the second upgrade policy that matches the first field, determine whether the threshold range of the first field is within the threshold range of the second field that matches the first field; if the threshold range of the first field is within the threshold range of the second field that matches the first field, determine that the first upgrade policy matches the second upgrade policy.
[0143] In a possible implementation, the policy verification unit 703 is further configured to determine that the first upgrade policy does not match the second upgrade policy if there is no second field in the second upgrade policy that matches the first field, or the threshold range of the first field is not within the threshold range of the second field that matches the first field.
[0144] In a possible implementation, the OTA upgrade device further includes:
[0145] A feedback unit, configured to determine that the verification of the first upgrade policy fails if the first upgrade policy does not match the second upgrade policy, and send the first upgrade policy with the verification failure to the user terminal and the cloud server.
[0146] In a possible implementation, the OTA upgrade device further includes:
[0147] A configuration file update unit, configured to receive a configuration file update instruction sent by the cloud server, obtain a target configuration file of the current vehicle carried in the configuration file update instruction, where the target configuration file of the current vehicle includes a target second upgrade policy supported by the current vehicle; and update the configuration file of the current vehicle to the target configuration file of the current vehicle.
[0148] An OTA upgrade device disclosed in this embodiment sets a second upgrade strategy supported by the vehicle model in the vehicle model configuration file of the in-vehicle terminal. After obtaining the upgrade package sent by the cloud server, the first upgrade strategy in the upgrade package is matched with the second upgrade strategy. When the first upgrade strategy matches the second upgrade strategy and the vehicle status conforms to the first upgrade strategy, OTA upgrade is executed, avoiding errors caused by upgrades when the first upgrade strategy sent by the cloud server does not match the second upgrade strategy supported by the vehicle model, and ensuring the stability and reliability of OTA upgrade.
[0149] This application embodiment also provides a computer program product including computer-readable instructions. When the computer-readable instructions run on the in-vehicle terminal, the in-vehicle terminal is enabled to implement any OTA upgrade method provided by this application embodiment.
[0150] This application embodiment also provides a computer-readable storage medium. The storage medium carries one or more computer programs. When the one or more computer programs are executed by the in-vehicle terminal, the in-vehicle terminal can be enabled to implement any OTA upgrade method provided by this application embodiment.
[0151] In addition, it should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. In addition, in the attached drawings of the device embodiments provided in this application, the connection relationship between the modules indicates that they have a communication connection, which can be specifically implemented as one or more communication buses or signal lines.
[0152] Through the description of the above embodiments, those skilled in the art can clearly understand that the present application can be implemented by means of software plus necessary general hardware. Of course, it can also be implemented by dedicated hardware including application specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. Generally, functions completed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures for implementing the same function can also be diverse, such as analog circuits, digital circuits or dedicated circuits, etc. However, for the present application, in more cases, software program implementation is a better implementation manner. Based on such an understanding, the technical solution of the present application, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a readable storage medium, such as a floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk or optical disc of a computer, etc., and includes several instructions to enable a computer device (which can be a personal computer, training device, or network device, etc.) to execute the methods described in various embodiments of the present application.
[0153] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product.
[0154] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer can be a general computer, a dedicated computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, training device or data center to another website, computer, training device or data center by wire (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a training device or data center that includes one or more integrated available media. The available medium can be a magnetic medium (for example, floppy disk, hard disk, magnetic tape), an optical medium (for example, DVD), or a semiconductor medium (for example, solid state disk (SSD)), etc.
Claims
1. An OTA upgrade method, characterized in that: include: Obtain the first upgrade strategy in the upgrade package sent by the cloud server; Read the configuration file of this model and obtain the second upgrade strategy supported by this model; matching the first upgrade strategy with the second upgrade strategy; If the first upgrade strategy matches the second upgrade strategy, determining whether the vehicle state complies with the first upgrade strategy; If the vehicle status meets the first upgrade strategy, perform OTA upgrade.
2. The OTA upgrade method according to claim 1, characterized in that: Matching the first upgrade strategy with the second upgrade strategy includes: Matching a first field in the first upgrade strategy with a second field in the second upgrade strategy; If the second field matching the first field exists in the second upgrade policy, determining whether the threshold range of the first field is within the threshold range of the second field matching the first field; If the threshold range of the first field is within the threshold range of the second field matched by the first field, it is determined that the first upgrade policy matches the second upgrade policy.
3. The OTA upgrade method according to claim 2, characterized in that: The OTA upgrade method further includes: If the second upgrade policy does not contain the second field that matches the first field, or the threshold range of the first field is not within the threshold range of the second field that matches the first field, it is determined that the first upgrade policy does not match the second upgrade policy.
4. The OTA upgrade method according to claim 1 or 3, characterized in that: The OTA upgrade method further includes: If the first upgrade policy does not match the second upgrade policy, it is determined that the first upgrade policy verification has failed, and the first upgrade policy that has failed verification is sent to the user terminal and the cloud server.
5. The OTA upgrade method according to claim 1, characterized in that: The OTA upgrade method further includes: Receiving a configuration file update instruction issued by the cloud server, and obtaining a target configuration file of the vehicle model carried by the configuration file update instruction, wherein the target configuration file of the vehicle model includes a target second upgrade strategy supported by the vehicle model; The vehicle type configuration file is updated to the vehicle type target configuration file.
6. An OTA upgrade device, characterized in that: include: A first strategy acquisition unit, used to acquire a first upgrade strategy in an upgrade package sent by a cloud server; A second strategy acquisition unit, used to read the configuration file of the vehicle model and acquire the second upgrade strategy supported by the vehicle model; a strategy verification unit, configured to match the first upgrade strategy with the second upgrade strategy; an upgrade verification unit, configured to determine whether a vehicle state complies with the first upgrade strategy if the first upgrade strategy matches the second upgrade strategy; An upgrade execution unit is used to execute OTA upgrade if the vehicle status meets the first upgrade strategy.
7. An OTA upgrade system, characterized in that: include: A cloud server and a plurality of vehicle-mounted terminals, each of which corresponds to a vehicle model; The cloud server is used to determine the target ECU corresponding to the OTA upgrade, set a first upgrade strategy corresponding to the target ECU, and send the first upgrade strategy along with the upgrade package to the vehicle terminal including the target ECU; The vehicle-mounted terminal is used to obtain a first upgrade strategy in an upgrade package sent by a cloud server, read a configuration file of the vehicle model, obtain a second upgrade strategy supported by the vehicle model, match the first upgrade strategy with the second upgrade strategy, and if the first upgrade strategy matches the second upgrade strategy, determine whether the vehicle status complies with the first upgrade strategy; if the vehicle status complies with the first upgrade strategy, perform OTA upgrade.
8. The OTA upgrade system according to claim 7, characterized in that: The cloud server is also used to set a configuration file corresponding to each vehicle model, and send the configuration file corresponding to each vehicle model to the corresponding vehicle terminal respectively, and the configuration file corresponding to each vehicle model includes a second upgrade strategy supported by the vehicle model.
9. A vehicle-mounted terminal, characterized in that: The method comprises at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the vehicle-mounted terminal can implement the OTA upgrade method as described in any one of claims 1 to 5.
10. A computer program product, characterized in that It includes computer-readable instructions, and when the computer-readable instructions are executed on a vehicle-mounted terminal, the vehicle-mounted terminal implements the OTA upgrade method as described in any one of claims 1 to 5.