Software upgrading method and device and electronic equipment

Abstract

The invention discloses a software upgrading method and device, electronic equipment and a storage medium, and the method comprises the steps: determining a vehicle software upgrading strategy according to a vehicle fault of a target vehicle to be subjected to software upgrading; determining a part software upgrading strategy according to the part software upgrading fault of each fault part with the software upgrading fault in the target vehicle; the part upgrading strategy comprises a software upgrading strategy of each fault part; and based on the vehicle software upgrading strategy and the part software upgrading strategy, performing software upgrading on each fault part in the target vehicle. According to the method, the software upgrading success rate of the target vehicle is improved.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and more specifically, to a software upgrading method, device, electronic device, and storage medium. Background Art

[0002] As vehicles become more electrified, intelligent, and connected, their electronic devices are becoming increasingly versatile and intelligent. To improve the user experience and driving safety, software upgrades for various vehicle components are often necessary, such as remotely upgrading vehicles using OTA (Over-The-Air) technology. However, the success rate of vehicle software upgrades is relatively low in related technologies. Summary of the Invention

[0003] In view of this, the present application proposes a software upgrade method, device, electronic device and storage medium to solve the above problems.

[0004] In a first aspect, an embodiment of the present application provides a software upgrade method, the method comprising: determining a vehicle software upgrade strategy based on a vehicle fault of a target vehicle to be software upgraded; determining a part software upgrade strategy based on a part software upgrade fault of each faulty part in the target vehicle having a software upgrade fault; the part upgrade strategy comprises a software upgrade strategy for each faulty part; and performing a software upgrade on each faulty part in the target vehicle based on the vehicle software upgrade strategy and the part software upgrade strategy.

[0005] In a second aspect, an embodiment of the present application provides a software upgrade device, which includes: a first determination module for determining a vehicle software upgrade strategy based on a vehicle fault of a target vehicle to be software upgraded; a second determination module for determining a part software upgrade strategy based on a part software upgrade fault of each faulty part in the target vehicle having a software upgrade fault; the part upgrade strategy includes a software upgrade strategy for each faulty part; and an upgrade module for performing a software upgrade on each faulty part in the target vehicle based on the vehicle software upgrade strategy and the part software upgrade strategy.

[0006] In a third aspect, an embodiment of the present application provides an electronic device, the electronic device comprising: one or more processors; Memory; One or more applications, wherein the one or more applications are stored in a memory and configured to be executed by one or more processors, and the one or more programs are configured to execute the method of the first aspect above.

[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, characterized in that program code is stored in the computer-readable storage medium, and the program code can be called by a processor to execute the method of the above-mentioned first aspect.

[0008] The embodiments of the present application provide a software upgrade method, device, electronic device and storage medium. First, a vehicle software upgrade strategy of a target vehicle is determined according to a vehicle fault, and a parts software upgrade strategy is determined according to the parts software upgrade fault of each faulty part in the target vehicle with a software upgrade fault. Then, based on the vehicle software upgrade strategy and the parts software upgrade strategy, software upgrades are performed on each faulty part in the target vehicle. Thus, the vehicle fault in the software upgrade process of the target vehicle is resolved by the vehicle software upgrade strategy, and the parts software upgrade fault in the software upgrade process of the target vehicle is resolved by the parts software upgrade strategy. Thus, the software upgrade of the target vehicle is achieved while resolving the vehicle fault and the software upgrade fault of the faulty part, thereby reducing the occurrence of software upgrade failures of the target vehicle when there are vehicle faults and / or parts software upgrade faults, improving the success rate of the software upgrade of the target vehicle, and achieving a better software upgrade effect on the target vehicle.

[0009] These and other aspects of the present application will become more readily apparent from the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0011] Figure 1 A flow chart of a software upgrade method proposed according to an embodiment of the present application is shown.

[0012] Figure 2 A schematic diagram of a software upgrade process in an embodiment of the present application is shown.

[0013] Figure 3 Shown Figure 1 The steps before step S110 in the corresponding embodiment are a flowchart in one embodiment.

[0014] Figure 4 A schematic diagram of a fault database determination process in an embodiment of the present application is shown.

[0015] Figure 5 Shown Figure 4 The corresponding embodiment is a flowchart of 304 in one embodiment.

[0016] Figure 6 A structural block diagram of a software upgrading device proposed in one embodiment of the present application is shown.

[0017] Figure 7 A structural block diagram of an electronic device proposed in one embodiment of the present application is shown.

[0018] Figure 8 A structural block diagram of a computer-readable storage medium provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0019] In order to enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. The components of the embodiments of the present application generally described and shown in the drawings here can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application for which protection is claimed, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work fall within the scope of protection of the present application.

[0020] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0021] Reference Figure 1 , Figure 1 A flowchart of a software upgrade method proposed according to one embodiment of the present application is shown. The method is used for an electronic device and includes: S110 : Determine a vehicle software upgrade strategy based on a vehicle fault of a target vehicle to be software upgraded.

[0022] In this application, a target vehicle refers to a vehicle to be software-upgraded, which may be a sedan, SUV, bus, truck, etc. The target vehicle includes at least one component requiring software upgrade, which may be an electronic control unit (ECU) or sensor in the vehicle.

[0023] The electronic device can be a computer or cloud server that communicates with the target vehicle. The electronic device is used to provide a software package, a vehicle software upgrade policy, and a component software upgrade policy to the target vehicle to be upgraded, thereby implementing the software upgrade for the target vehicle. The software package can include a new version of the component for the target vehicle, a current version of the component, or a historical version of the component.

[0024] In this embodiment, the vehicle failure of the target vehicle refers to a possible failure of the target vehicle. For example, the vehicle failure of the vehicle may include failure of the vehicle battery condition to be met, failure of the vehicle locking condition to be met, and network abnormality.

[0025] The battery condition is not met when the remaining charge of the vehicle's battery is less than a specified battery limit value, where the battery limit value may refer to the battery's minimum remaining SOC, such as 30%. The locking condition is not met when the vehicle is unlocked. This can include situations where the vehicle is forgotten to be locked when no one is in the vehicle, or is unlocked when someone is in the vehicle but not started.

[0026] The determined vehicle software upgrade strategy can differ for different vehicle faults. For example, if the vehicle fault can be caused by battery condition failure, vehicle lock condition failure, or network anomaly, the determined vehicle software upgrade strategy may include replacing the previously specified battery limit with a new battery limit value to loosen the limit and make it easier for the target vehicle to meet the battery condition. If the target vehicle's lock condition is not met, the determined vehicle software upgrade strategy may include ensuring that the target vehicle is unlocked, allowing the software upgrade to be performed even in this state. If the target vehicle's network is anomaly, the determined vehicle software upgrade strategy may include extending the validity period of the software upgrade task (e.g., by 2 hours) to allow more time for the target vehicle's network to return to normal, allowing the software upgrade to be performed after the network is restored. Thus, the vehicle software upgrade strategy includes at least one of the target vehicle's battery limit value (i.e., the previously specified new battery limit value), the vehicle lock condition (specifically, ensuring that the target vehicle is unlocked), and the validity period of the software upgrade task.

[0027] In some embodiments, S110 specifically includes: adjusting a preset vehicle software upgrade strategy for the vehicle fault according to the vehicle fault of the target vehicle to obtain a vehicle software upgrade strategy.

[0028] That is to say, a preset vehicle software upgrade strategy can be configured for the target vehicle. The preset vehicle software upgrade strategy can include the target vehicle's battery limit value, vehicle lock conditions, and effective duration of the software upgrade task when the target vehicle has no vehicle failure. Based on this, after determining the vehicle fault of the target vehicle, the preset vehicle software upgrade strategy can be adjusted to obtain the vehicle software upgrade strategy; for example, if the battery condition of the target vehicle is not met, the determined vehicle software upgrade strategy may include lowering the battery limit value in the preset vehicle software upgrade strategy to obtain a new battery limit value, so that the restriction becomes looser and the target vehicle can more easily meet the battery condition; if the locking condition of the target vehicle is not met, the determined vehicle software upgrade strategy may include the target vehicle being in an unlocked state, so that the target vehicle can also achieve software upgrade in the unlocked state; if the target vehicle network is abnormal, the determined vehicle software upgrade strategy may include extending the effective time of the software upgrade task in the preset vehicle software upgrade strategy, so that there is more time to wait for the target vehicle network to return to normal, and achieve software upgrade after the network returns to normal.

[0029] S120: Determine a parts software upgrade strategy based on the parts software upgrade failure of each faulty part having a software upgrade failure in the target vehicle.

[0030] Among them, the faulty parts refer to the parts in the target vehicle that have software upgrade failures, and the parts software upgrade failures are the specific software upgrade failures that exist in the faulty parts. The parts software upgrade failures may include software package transmission failures, software package installation failures, and software upgrade main control unit abnormalities, etc. Among them, when the target vehicle performs software upgrades in an OTA manner, the software upgrade main control unit may be the OTA main control unit in the target vehicle.

[0031] Usually, there are multiple faulty parts in the target vehicle, so the determined parts software upgrade strategy includes the software upgrade strategy of each faulty part.

[0032] Similarly, for any faulty component, the vehicle software upgrade strategy determined can be different depending on the component software upgrade failure. For example, if the faulty component's component software upgrade failure is a software package transmission failure, the determined software upgrade strategy includes the number of repeated software package transmissions, thereby increasing the success rate of software package transmission. If the faulty component's component software upgrade failure is a software package installation failure, the determined software upgrade strategy includes the number of repeated software package installations, thereby increasing the success rate of software package installation. If the faulty component's component software upgrade failure is a software upgrade main control unit abnormality, the determined software upgrade strategy includes first upgrading the software upgrade main control unit. Thus, for each faulty component, the faulty component's software upgrade strategy includes at least one of the following: the number of repeated software package installations, the number of repeated software package transmissions, and first upgrading the software upgrade main control unit.

[0033] In some embodiments, S120 specifically includes: adjusting a preset software upgrade strategy for each faulty part having a software upgrade failure in the target vehicle according to the part software upgrade failure of each faulty part to obtain a part software upgrade strategy.

[0034] That is, a preset software upgrade strategy can be configured for each faulty part in the target vehicle. The preset software upgrade strategy can include the initial repeated transmission times of the software package set for the faulty part, the initial repeated installation times of the software package, and whether the software upgrade main control unit is upgraded first.

[0035] Based on this, for each faulty part, after determining that the faulty part has a specific software upgrade failure, the corresponding preset software upgrade strategy can be adjusted, and based on the adjusted preset software upgrade strategy of each faulty part, a part software upgrade strategy including the software upgrade strategy of each faulty part can be obtained.

[0036] For example, if the faulty part software upgrade failure is caused by the failure of software package transmission, the initial repeated transmission times of the software package are increased to increase the repeated transmission times, thereby increasing the success rate of software package transmission; if the faulty part software upgrade failure is caused by the failure of software package installation, the initial installation times of the software package are increased to increase the repeated installation times, thereby increasing the success rate of software package installation; if the faulty part software upgrade failure is caused by the abnormality of the software upgrade main control unit, the determined software upgrade main control unit is upgraded first, so that the software upgrade main control unit can be restored to normal as much as possible, ensuring that the software upgrade of other faulty parts proceeds smoothly.

[0037] S130: Perform software upgrades on each faulty part in the target vehicle based on the vehicle software upgrade strategy and the parts software upgrade strategy.

[0038] After obtaining the vehicle software upgrade strategy and the parts software upgrade strategy, the vehicle software upgrade strategy and the parts software upgrade strategy can be sent to the target vehicle, and the software package of each faulty part can be sent to the target vehicle, so that the target vehicle can perform software upgrades on each faulty part according to the vehicle software upgrade strategy and the parts software upgrade strategy through the received software package of the faulty part.

[0039] Specifically, the target vehicle can be controlled to enter corresponding conditions based on the vehicle software upgrade strategy, and when performing software upgrade on each faulty part, the software of the faulty part can be upgraded based on the software upgrade strategy of the faulty part in the part software upgrade strategy.

[0040] Of course, there are normal parts in the target vehicle that have not failed, and these normal parts also need to be upgraded. Therefore, the electronic device can also send the software package of the normal parts to the target vehicle, so that the target vehicle can upgrade the software of each faulty part according to the vehicle software upgrade strategy and the parts software upgrade strategy through the received software package of the faulty parts, and can also upgrade the software of the normal parts that need software upgrade.

[0041] In some embodiments, S130 may also include: for each faulty part, determining the priority of the faulty part according to the number of concurrent faulty parts corresponding to the faulty part and the failure coefficient of the faulty part; a concurrent faulty part refers to a faulty part in the target vehicle that has a concurrent fault when a software upgrade failure occurs in the faulty part; performing a software upgrade on each faulty part in the target vehicle based on the priority of each faulty part, the vehicle software upgrade strategy and the part software upgrade strategy.

[0042] The failure coefficient of a faulty part refers to the coefficient configured for the faulty part. The failure coefficient is used to indicate the severity of the software upgrade failure of the faulty part. Generally speaking, the more serious the software upgrade failure of the faulty part, the higher the failure coefficient of the faulty part, and the minor the software upgrade failure of the faulty part, the lower the failure coefficient of the faulty part.

[0043] In this application, the concurrent faulty parts of a faulty part refer to the faulty parts that have concurrent faults in the target vehicle when the faulty part has a software upgrade fault. For example, the faulty part g1 has concurrent faulty parts, which means that when the faulty part has a software upgrade fault, the faulty parts that have concurrent faults in the target vehicle are g1, g2, g3 and g4 respectively. At this time, the number of concurrent faulty parts corresponding to the faulty part is 4.

[0044] Specifically, the product of the number of concurrent faulty parts corresponding to the faulty part and the fault coefficient of the faulty part can be calculated to obtain a priority score indicating the priority of the faulty part. The higher the priority score, the higher the priority of the faulty part, and the earlier the faulty part is upgraded. Conversely, the lower the priority score, the lower the priority of the faulty part, and the later the faulty part is upgraded.

[0045] In this way, the priority of each faulty part can be determined, and then the software of each faulty part in the target vehicle can be upgraded based on the priority of each faulty part, the vehicle software upgrade strategy and the part software upgrade strategy.

[0046] Specifically, the target vehicle can be controlled to enter corresponding conditions based on the vehicle software upgrade policy. Each faulty part is sorted based on its priority to create an upgrade sequence. The higher the priority of the faulty part in the upgrade sequence, the higher its ranking. The faulty parts are then upgraded sequentially according to their order in the upgrade sequence. Subsequently, when performing a software upgrade on each faulty part, the software upgrade is performed based on the software upgrade policy for that faulty part in the part software upgrade policy.

[0047] In some embodiments, if the faulty component includes a software upgrade control unit, the software priority of the software upgrade control unit is adjusted to the highest. In other words, if the target vehicle's software upgrade control unit experiences a software upgrade fault, indicating that the software upgrade control unit is abnormal, the software upgrade control unit is the first faulty component to be upgraded.

[0048] The software upgrade main control unit is the controller that controls the software upgrade of each part. Its normal operation affects the software upgrade process of other parts in the target vehicle. Therefore, when it is determined that there is a software upgrade fault in the software upgrade main control unit, the software upgrade main control unit is upgraded first. After the software upgrade main control unit is upgraded, the software upgrade fault of the software upgrade main control unit is eliminated, thereby ensuring that other parts can also undergo software upgrades smoothly.

[0049] For example, Figure 2 As shown in the figure, the software upgrade process includes: 201. Obtain a preset vehicle software upgrade strategy and a preset software upgrade strategy for each faulty component.

[0050] 202. Determine vehicle faults and parts software upgrade failures of faulty parts.

[0051] 203. Determine the vehicle software upgrade strategy (which may include battery limit value, vehicle locking conditions, and task validity period), the parts software upgrade strategy, and the priority of each faulty part.

[0052] 204. Whether the faulty parts include the software upgrade main control unit.

[0053] 205. Set the priority of the software upgrade main control unit to the highest.

[0054] 206. Perform software upgrade based on the priority of each faulty part, the vehicle software upgrade strategy, and the part software upgrade strategy.

[0055] Among them, the specific details of each step in 201-206 here refer to the above content and are not repeated here.

[0056] In this embodiment, first, the vehicle software upgrade strategy of the target vehicle is determined according to the vehicle fault, and the parts software upgrade strategy is determined according to the parts software upgrade fault of each faulty part in the target vehicle with a software upgrade fault. Then, based on the vehicle software upgrade strategy and the parts software upgrade strategy, the software of each faulty part in the target vehicle is upgraded. Thus, the vehicle fault in the software upgrade process of the target vehicle is resolved by the vehicle software upgrade strategy, and the parts software upgrade fault in the software upgrade process of the target vehicle is resolved by the parts software upgrade strategy. Thus, the software upgrade of the target vehicle is achieved while resolving the vehicle fault and the software upgrade fault of the faulty part, which reduces the occurrence of software upgrade failure of the target vehicle when there is a vehicle fault and / or parts software upgrade fault, improves the success rate of the software upgrade of the target vehicle, and achieves a better software upgrade effect on the target vehicle.

[0057] Secondly, the priority of each faulty part is also determined so that each faulty part is upgraded in order of priority, thereby ensuring that faulty parts with serious faults are upgraded first, and faulty parts with minor faults are upgraded later, so that the target vehicle can quickly eliminate part faults and ensure that part faults of the target vehicle are minimized.

[0058] In some embodiments, before S110, the method further includes: S210: Acquire multiple candidate vehicles.

[0059] The candidate vehicle may be a vehicle to be software upgraded, and the plurality of candidate vehicles may include the target vehicle. The candidate vehicle may be a vehicle with a vehicle fault or a vehicle without a vehicle fault and / or without a faulty part.

[0060] In some embodiments, before S210, the method further includes: determining a fault database based on the vehicle models of the plurality of vehicles to be processed, the vehicle faults to be processed for the plurality of vehicles to be processed, and the corresponding component software upgrade faults to be processed for each vehicle to be processed; the fault database includes vehicles belonging to at least one vehicle model, the corresponding vehicle faults and component software upgrade faults for each vehicle model; accordingly, S210 includes: selecting a plurality of candidate vehicles from the vehicles included in the fault database. The vehicle fault to be processed refers to a vehicle fault occurring in the vehicle to be processed, and the component software upgrade fault to be processed refers to a component software upgrade fault for each faulty component of the vehicle to be processed that has a software upgrade fault.

[0061] The vehicle being processed can communicate with the electronic device. The vehicle being processed can send its various fault events (including vehicle faults and component faults), fault timestamps, and the vehicle identification code being processed to the electronic device. The electronic device can then identify the vehicle being processed based on the vehicle identification code and perform fault analysis based on the various fault events that occurred with the vehicle being processed. Of course, technical personnel can also incorporate various fault events that occurred during the development of the vehicle being processed based on needs and actual circumstances.

[0062] In some embodiments, the vehicle may send its various fault events, the timestamp of the fault occurrence, and the vehicle identification code to be processed to the electronic device via a software upgrade main control unit (eg, an OTA main control unit).

[0063] In this embodiment, the data reported to the electronic device regarding component failures may include the name of the faulty component, its version number, fault type, and occurrence frequency. Generally speaking, a fault frequency analysis is performed based on the faulty component and its corresponding software version. For example, if a vehicle experiences multiple failures with the same component and the same software version, the failure is counted as a single failure.

[0064] For vehicle failures, the data reported to the electronic device may include the name of the vehicle failure, the type of vehicle failure, the frequency of occurrence, etc.

[0065] After obtaining the fault events reported by various vehicles to be processed, the vehicle faults of each vehicle to be processed and the parts software upgrade faults in each vehicle to be processed can be analyzed according to the vehicle model to obtain a fault database.

[0066] For example, based on the vehicle model, multiple vehicles to be processed are divided into multiple groups, each group includes vehicles to be processed belonging to the same vehicle model, one group corresponds to one vehicle model, and the group corresponding to each vehicle model includes the vehicles to be processed belonging to the model, the vehicle faults of each vehicle to be processed belonging to the model, and the parts software upgrade faults of each vehicle to be processed. At this time, the fault database can include the groups corresponding to each of the aforementioned vehicle models.

[0067] After obtaining the fault database, all or part of the vehicles in one or more groups may be obtained as multiple candidate vehicles.

[0068] Exemplarily, the process of determining the fault database is as follows: Figure 4 Shown, including: 301. Obtain the reported fault event and vehicle identification code.

[0069] 302. Manually add fault events.

[0070] 303. Vehicle failure frequency analysis (analyzed by faulty parts and their corresponding software versions) and faulty parts frequency analysis.

[0071] 304. Analyze parts software upgrade failures and vehicle failures based on vehicle type to obtain a failure database.

[0072] like Figure 5 As shown, 304 may include: 401. Statistics of software upgrade failures of faulty parts.

[0073] 402. Determine the priority of the faulty parts.

[0074] 403. Sort the faulty parts according to their priorities to obtain an upgrade sequence.

[0075] 404. Analysis of vehicle failure.

[0076] 405. Total number of vehicle failures in the most recent M upgrade processes.

[0077] 406. Determine the fault level (high frequency, low frequency, and medium frequency).

[0078] 407. Obtain fault data.

[0079] In other words, in this embodiment, for each vehicle in the fault database (including the target vehicle), the fault database can also include the priority of the faulty parts in the vehicle and the fault level of the vehicle, so as to directly obtain the fault level of the vehicle and select the target vehicle based on the fault level. After determining the target vehicle, the priority of the faulty parts can be directly obtained for the software upgrade process of the target vehicle.

[0080] Continue to refer Figure 5 It can be seen that the faulty parts can also be sorted based on their priorities to obtain an upgrade sequence. In this way, when the software of the target vehicle is upgraded based on the priority of the faulty parts, the software upgrade order of each faulty part in the target vehicle can be determined directly according to the upgrade sequence determined based on the priority of the faulty parts.

[0081] S220 : Determine a fault level for each candidate vehicle based on the fault frequency of the vehicle fault occurring in each candidate vehicle.

[0082] For each candidate vehicle, the total number of vehicle failures that occurred within a target period (e.g., the last month) or during the last M software upgrades (e.g., 20) is counted as the failure frequency. Based on this total number of failures, the candidate vehicle's failure level is determined. Failure levels include high frequency, medium frequency, and low frequency. Each failure level corresponds to a failure frequency range, for example, frequencies of 1-2 correspond to low frequency, frequencies of 3-4 correspond to medium frequency, and frequencies of 5 or higher correspond to high frequency. The failure level corresponding to the failure frequency range within which the candidate vehicle's total number of failures within the target period falls is then determined as the candidate vehicle's failure level. In this manner, a failure level is determined for each candidate vehicle.

[0083] S230 : Determine a target vehicle from the plurality of candidate vehicles based on the respective fault levels of the plurality of candidate vehicles.

[0084] A candidate vehicle with the highest fault level can be selected as the target vehicle. Of course, if there are multiple candidate vehicles with the highest fault level, the target vehicle can also be selected based on the fault frequency of the candidate vehicles. For example, if there are multiple candidate vehicles with the highest fault level, the candidate vehicle with the highest fault frequency can be selected as the target vehicle.

[0085] It is worth mentioning that after the target vehicle completes the software upgrade, the number of vehicle failures and / or parts software upgrade failures of the target vehicle can continue to be counted, and when the number of vehicle failures within a specified period is zero and / or the number of parts software upgrade failures within a specified period is zero, it is determined that the target vehicle failure is eliminated and it is deleted from the fault database.

[0086] In this embodiment, the vehicle faults and parts software upgrade faults of the vehicle are analyzed to obtain a fault database, which enables an overall analysis of the faulty vehicle, improves the fault analysis effect, and facilitates the determination of target vehicles that require software upgrades from the fault database, thereby improving the efficiency of selecting target vehicles.

[0087] Reference Figure 6 , Figure 6 The following is a block diagram of a software upgrade device according to an embodiment of the present application. The device 600 is used in an electronic device and includes: A first determining module 610 is configured to determine a vehicle software upgrade strategy based on a vehicle fault of a target vehicle to be software upgraded; The second determining module 620 is configured to determine a component software upgrade strategy based on the component software upgrade failure of each faulty component in the target vehicle; the component upgrade strategy includes a software upgrade strategy for each faulty component; The upgrade module 630 is used to perform software upgrades on each faulty part in the target vehicle based on the vehicle software upgrade strategy and the part software upgrade strategy.

[0088] Optionally, the upgrade module 630 is also used to determine the priority of each faulty part based on the number of concurrent faulty parts corresponding to the faulty part and the failure coefficient of the faulty part; a concurrent faulty part refers to a faulty part in the target vehicle that has a concurrent fault when a software upgrade failure occurs in the faulty part; based on the priority of each faulty part, the vehicle software upgrade strategy and the part software upgrade strategy, the software of each faulty part in the target vehicle is upgraded.

[0089] Optionally, the upgrade module 630 is further configured to adjust the software priority of the software upgrade main control unit to the highest if the faulty component includes a software upgrade main control unit.

[0090] Optionally, the device also includes an acquisition module for acquiring multiple candidate vehicles; determining the fault level of each candidate vehicle based on the fault frequency of the vehicle fault occurring in each candidate vehicle; and determining the target vehicle from the multiple candidate vehicles based on the fault levels of the multiple candidate vehicles.

[0091] Optionally, the acquisition module is also used to determine a fault database based on the vehicle models of multiple vehicles to be processed, the vehicle faults to be processed of multiple vehicles to be processed, and the parts software upgrade faults to be processed corresponding to each vehicle to be processed; the fault database includes vehicles belonging to at least one vehicle model, the vehicle faults and parts software upgrade faults corresponding to the vehicles under each vehicle model; accordingly, the first determination module 610 is also used to select multiple candidate vehicles from the vehicles included in the fault database.

[0092] Optionally, the first determining module 610 is further configured to adjust a preset vehicle software upgrade strategy for the vehicle fault according to the vehicle fault of the target vehicle to obtain a vehicle software upgrade strategy.

[0093] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0094] In several embodiments provided in this application, the coupling between modules may be electrical, mechanical or other forms of coupling.

[0095] Please refer to Figure 7, which shows a structural block diagram of an electronic device provided by an embodiment of the application. The electronic device 500 can be an electronic device capable of running applications, such as a smartphone, a tablet computer, an e-book, and a vehicle. The electronic device 500 in this application may include one or more of the following components: a processor 510, a memory 520, and one or more applications. The one or more applications may be stored in the memory 520 and configured to be executed by one or more processors 510, and the one or more programs are configured to execute the method described in the aforementioned method embodiment.

[0096] The processor 510 may include one or more processing cores. The processor 510 utilizes various interfaces and circuits to connect various components within the electronic device 500. It executes instructions, programs, code sets, or instruction sets stored in the memory 520, and accesses data stored in the memory 520 to perform various functions and process data within the electronic device 500. Optionally, the processor 510 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 510 may integrate one or a combination of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily processes the operating system, user interface, and application programs; the GPU is responsible for rendering and drawing display content; and the modem handles wireless communications. It is understood that the modem may also be implemented independently of the processor 510 via a separate communications chip.

[0097] The memory 520 may include random access memory (RAM) or read-only memory (ROM). The memory 520 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 520 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, a sound playback function, an image playback function, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the electronic device 500 during use (such as a phone book, audio and video data, and chat history data).

[0098] In addition, the functional modules in the various embodiments of the present application may be integrated into a processing module, or each module may exist physically separately, or two or more modules may be integrated into a single module. The above-mentioned integrated modules may be implemented in the form of hardware or software functional modules.

[0099] refer to Figure 8 , Figure 8 The computer-readable storage medium 900 is a block diagram showing a structure of a computer-readable storage medium provided in an embodiment of the present application. The computer-readable storage medium 900 stores program code, which can be called by a processor to execute the method described in the above method embodiment.

[0100] Computer-readable storage medium 900 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, a hard disk, or ROM. Alternatively, computer-readable storage medium 900 may include a non-transitory computer-readable storage medium. Computer-readable storage medium 900 has storage space for program code 910 for executing any of the method steps described above. This program code can be read from or written to one or more computer program products. Program code 910 may be compressed, for example, in a suitable format.

[0101] In summary, the present application provides a calibration pattern generation method, calibration pattern registration method, device, and electronic device. After acquiring a calibration scene, a pseudo-random array corresponding to the calibration scene is obtained. A calibration pattern is generated based on the pseudo-random array and multiple graphic primitives. The pseudo-random array is used to determine the position of the graphic primitives in the calibration pattern. This method enables the generation of different pseudo-random arrays based on different calibration scenarios, and thus different calibration patterns based on different pseudo-random arrays, thereby improving the accuracy of sensor calibration in different calibration scenarios.

[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application 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 make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A software upgrade method, characterized in that: The method comprises: Determine a vehicle software upgrade strategy based on vehicle faults of the target vehicle to be upgraded; Determining a parts software upgrade strategy based on the parts software upgrade failure of each faulty part having a software upgrade failure in the target vehicle; the parts upgrade strategy includes a software upgrade strategy for each of the faulty parts; Based on the vehicle software upgrade strategy and the part software upgrade strategy, software upgrade is performed on each of the faulty parts in the target vehicle.

2. The method according to claim 1, characterized in that The step of performing software upgrade on each of the faulty parts in the target vehicle based on the vehicle software upgrade strategy and the parts software upgrade strategy includes: For each of the faulty parts, the priority of the faulty part is determined according to the number of concurrent faulty parts corresponding to the faulty part and the fault coefficient of the faulty part; the concurrent faulty part refers to a faulty part in the target vehicle that has a concurrent fault when the faulty part has a software upgrade fault; Based on the priority of each faulty part, the vehicle software upgrade strategy and the part software upgrade strategy, software upgrade is performed on each faulty part in the target vehicle.

3. The method according to claim 2, characterized in that Before performing software upgrade on each of the faulty parts in the target vehicle based on the priority of each of the faulty parts, the vehicle software upgrade strategy, and the part software upgrade strategy, the method further includes: If the faulty component includes a software upgrade main control unit, the software priority of the software upgrade main control unit is adjusted to the highest.

4. The method according to claim 1, wherein Before determining the vehicle software upgrade strategy based on the vehicle fault of the target vehicle to be software upgraded, the method further includes: Obtain multiple candidate vehicles; determining a fault level of each candidate vehicle based on a fault frequency of a vehicle fault occurring in each candidate vehicle; The target vehicle is determined from among the plurality of candidate vehicles based on the respective failure levels of the plurality of candidate vehicles.

5. The method according to claim 4, characterized in that Before obtaining a plurality of candidate vehicles, the method further includes: Determining a fault database based on the respective models of a plurality of to-be-processed vehicles, the respective to-be-processed vehicle faults, and the to-be-processed parts software upgrade faults corresponding to each of the to-be-processed vehicles; the fault database including vehicles belonging to at least one model, the respective to-be-processed vehicle faults, and the parts software upgrade faults corresponding to each of the vehicles of the model; The obtaining of multiple candidate vehicles includes: The plurality of candidate vehicles are selected from vehicles included in the fault database.

6. The method according to claim 1, characterized in that The determining of a vehicle software upgrade strategy based on a vehicle fault of a target vehicle to be software upgraded includes: According to the vehicle fault of the target vehicle, a preset vehicle software upgrade strategy for the vehicle fault is adjusted to obtain the vehicle software upgrade strategy.

7. The method according to claim 1, characterized in that The vehicle software upgrade strategy includes at least one of the target vehicle's battery limit value, vehicle locking conditions, and the effective duration of the software upgrade task; for each faulty part, the faulty part's software upgrade strategy includes at least one of the number of repeated installations of the faulty part's software package, the number of repeated transmissions of the software package, and whether the software upgrade main control unit is upgraded first.

8. A software upgrade device, characterized in that: The device comprises: A first determining module is used to determine a vehicle software upgrade strategy according to a vehicle fault of a target vehicle to be software upgraded; A second determining module is configured to determine a parts software upgrade strategy based on the parts software upgrade failure of each faulty part having a software upgrade failure in the target vehicle; the parts upgrade strategy includes a software upgrade strategy for each faulty part; An upgrade module is used to perform software upgrade on each of the faulty parts in the target vehicle based on the vehicle software upgrade strategy and the part software upgrade strategy.

9. An electronic device, characterized in that: The electronic device comprises: one or more processors; Memory; One or more application programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program code, which can be called by a processor to execute the method according to any one of claims 1 to 7.

Images