Software upgrading method and device for vehicle, electronic equipment and storage medium

Abstract

The invention provides a software upgrading method and device for a vehicle, electronic equipment and a storage medium, and the method comprises the steps that a to-be-upgraded vehicle is determined from a plurality of managed vehicles, and the current version of target software of the to-be-upgraded vehicle is lower than the to-be-updated target version; and obtaining operation attribute information of each to-be-upgraded vehicle, and screening out the OTA-upgradable vehicle of which the operation attribute information meets the OTA upgrading condition from all the to-be-upgraded vehicles. And notifying an OTA upgrading service system to carry out OTA upgrading on the target software of the vehicle capable of being subjected to OTA upgrading.

Description

Technical Field

[0001] This specification relates to the field of vehicle networking technology, and in particular to a software upgrade method, device, electronic device and storage medium for a vehicle. Background Art

[0002] Vehicle OTA upgrade (Over-the-Air) refers to the remote push of software update packages to the vehicle via a wireless network. Car owners can complete the vehicle software update without going to a repair shop or using a wired connection.

[0003] After the car company releases the latest version of the vehicle software, the operation staff is basically required to regularly collect vehicle information from various departments for review, and select the vehicles that can be OTA upgraded from the produced vehicles based on the vehicle information and make an OTA upgrade list and submit it to the OTA upgrade service system, so that the software update package can be pushed to the vehicles in the list. All links of the entire review process require manual intervention, the review steps are cumbersome and difficult to adapt to the update speed of vehicle information, resulting in a huge workload for the operation staff and low review efficiency. Summary of the invention

[0004] In order to overcome the problems existing in the related art, this specification provides a software upgrade method, device, electronic device and storage medium for a vehicle.

[0005] According to a first aspect of an embodiment of this specification, a software upgrade method for a vehicle is provided, the method comprising:

[0006] Determining a vehicle to be upgraded from a plurality of managed vehicles, wherein a current version of target software of the vehicle to be upgraded is lower than a target version to be updated;

[0007] Obtain the operational attribute information of each vehicle to be upgraded, and select the OTA upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions from all vehicles to be upgraded;

[0008] The OTA upgrade service system is notified to perform OTA upgrade on the target software of the OTA-upgradeable vehicle.

[0009] According to a second aspect of an embodiment of this specification, a software upgrade device for a vehicle is provided, the device comprising:

[0010] A vehicle to be upgraded determining module, used to determine a vehicle to be upgraded from a plurality of managed vehicles, wherein the current version of the target software of the vehicle to be upgraded is lower than the target version to be updated;

[0011] The OTA upgradeable vehicle determination module is used to obtain the operational attribute information of each vehicle to be upgraded, and select the OTA upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions from all vehicles to be upgraded;

[0012] The notification module is used to notify the OTA upgrade service system to perform OTA upgrade on the target software of the OTA-upgradeable vehicle.

[0013] According to a third aspect of the embodiments of this specification, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the steps of the method described in the first aspect are implemented.

[0014] According to a fourth aspect of the embodiments of this specification, there is provided a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the steps of the method described in the first aspect.

[0015] The technical solutions provided by the embodiments of this specification may have the following beneficial effects:

[0016] In the embodiment of this specification, the OTA upgradeable vehicles that meet the OTA upgrade conditions are automatically screened out from multiple managed vehicles according to the custom screening rules. This solution reduces manual intervention, thereby reducing the workload of operators and helping to improve their review efficiency.

[0017] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present specification. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and, together with the description, serve to explain the principles of the specification.

[0019] Figure 1 The flowchart of a vehicle software upgrade method is shown in accordance with an exemplary embodiment of the present specification.

[0020] Figure 2 This is a workflow diagram of a vehicle software upgrade method according to an exemplary embodiment of the present specification.

[0021] Figure 3 This is a workflow diagram for generating a record list according to an exemplary embodiment of the present specification.

[0022] Figure 4 This is a workflow diagram for determining a vehicle that can be OTA upgraded according to an exemplary embodiment of the present specification.

[0023] Figure 5 This is another workflow diagram of a vehicle software upgrade method according to an exemplary embodiment of the present specification.

[0024] Figure 6 It is a structural schematic diagram of an electronic device according to an exemplary embodiment of the present specification.

[0025] Figure 7 It is a block diagram of a software upgrade device for a vehicle according to an exemplary embodiment of the present specification. DETAILED DESCRIPTION

[0026] After a car manufacturer releases the latest version of the in-vehicle software for a certain model, not all vehicles of that model need to perform an OTA upgrade of the in-vehicle software. Instead, operators need to screen out vehicles that need OTA upgrades from all vehicles of that model produced by the car manufacturer, and then perform OTA upgrades on the in-vehicle software of these vehicles through the OTA upgrade service system.

[0027] Since the vehicle information management systems of different departments hold different types of vehicle information, in order to ensure that the vehicle upgrade task can be completed accurately, the operation staff needs to regularly collect various relevant information of the vehicle from the vehicle information management systems of various departments, and then manually review and analyze the vehicle upgrade method based on the collected relevant information of the vehicle, and select vehicles that support OTA upgrade, vehicles that do not need to be upgraded, and vehicles that cannot be OTA upgraded from all the vehicles produced, and make the vehicles that support OTA upgrade into an OTA upgrade list and send it to the OTA upgrade service system, so that it can push the software update package. The audit steps of each link in the entire audit and analysis process are cumbersome and highly repetitive, resulting in low audit efficiency of the operation staff.

[0028] In response to the above problems, this manual proposes a software upgrade method for vehicles to change the dilemma of manual review mentioned above. By setting custom screening rules, OTA-upgradeable vehicles that meet the OTA upgrade conditions are automatically screened out from all produced vehicles, reducing manual intervention and thus improving the review efficiency of operators.

[0029] like Figure 1 As shown, Figure 1 1 is a flowchart of a method for software upgrading a vehicle according to an exemplary embodiment of the present specification, including steps 101-103:

[0030] Step 101: Determine a vehicle to be upgraded from a plurality of managed vehicles.

[0031] like Figure 2As shown, the method can be applied to the operation platform 25. The operation platform 25 can integrate multiple operation management modules. For example, the operation platform 25 can include multiple management modules such as a supply chain management module, a dealer management module, and a version management module. Figure 1 The method logic can be executed by the program of the version management module in the operation platform 25. Of course, the operation platform 25 can also have only one management function, that is, only have the ability to execute Figure 1 Version management module for method logic.

[0032] In an illustrated embodiment, the production information of all models of vehicles produced by the automobile enterprise is generally stored in the manufacturing execution system 21 (referred to as "MES"), and these vehicles may include vehicles on the production line and vehicles off the production line. Therefore, the operation platform 25 can obtain the production information of all vehicles from the manufacturing execution system 21, for example, the vehicle identification code (referred to as "VIN") can be obtained, and of course, other production information such as manufacturer, factory number, etc. can also be obtained. For the version upgrade task of the vehicle software applicable to a certain model, the operation platform 25 can obtain the vehicle identification codes of all managed vehicles under the model from the manufacturing execution system 21, so as to determine which vehicles to upgrade. When performing the vehicle software version upgrade, different models may have different version requirements. Therefore, for the version upgrade task of the vehicle software applicable to certain models, the operation platform 25 can obtain the vehicle identification codes of all managed vehicles under these models from the manufacturing execution system 21. For the version upgrade task of the vehicle software applicable to all models, the operation platform 25 can obtain the vehicle identification codes of all managed vehicles produced from the manufacturing execution system 21. In this embodiment, since the manufacturing execution system 21 stores vehicle information of vehicles throughout their entire life cycle from production to offline, the operation platform 25 can obtain the vehicle identification codes of the managed vehicles from the manufacturing execution system 21 to determine which vehicles to upgrade, and can also obtain the operation attribute information and vehicle version information of all managed vehicles from different vehicle information management systems based on the vehicle identification codes of the managed vehicles in subsequent steps.

[0033] In an illustrated embodiment, the operation platform 25 can form a vehicle pool with multiple managed vehicles obtained from the manufacturing execution system 21, and the record of each vehicle in the vehicle pool includes the vehicle identification code of the vehicle and the current version of the target software of the vehicle. The operation platform 25 can filter out vehicles whose current version of the target software is lower than the target version to be updated from the vehicle pool. Among them, the target software refers to the software that needs to be upgraded on the vehicle in this upgrade task. The software can be the vehicle operating system, any installed program in the vehicle operating system, the embedded code of various control units of the vehicle, or the parameters of the artificial intelligence model. The target version is not necessarily the latest version released by the car company, but can also be any intermediate version before the latest version. For example, if the current version of the target software is too old, it may not be possible to directly update the target software from the current version to the latest version. Therefore, you can first try to update to an intermediate version that can be updated, and then continue to update to the latest version.

[0034] Specifically, Figure 2 As shown, the operation platform 25 can form a vehicle pool with the vehicle identification codes of multiple managed vehicles queried from the manufacturing execution system 21, and the record of each vehicle in the vehicle pool includes a vehicle identification code. Then, the current version of each vehicle is obtained from the OTA upgrade service system 26 according to each vehicle identification code, and the current version information is added to the record of each vehicle in the vehicle pool. Finally, the vehicles to be upgraded whose current version of the target software is lower than the target version to be updated are screened out from the vehicle pool. Specifically, assuming that the target version to be updated is 5.0 and the target software is the vehicle operating system, the operator can set the screening rules, for example, the current version is less than 5.0 and the target software is the vehicle operating system. The operation platform 25 can filter out qualified vehicles to be upgraded from the vehicle pool according to the screening rules.

[0035] Among them, Figure 2 As shown, the OTA upgrade service system 26 is responsible for pushing the updated version of the target software to the vehicle through OTA upgrade, and the OTA upgrade service system 26 can maintain the current version and upgrade progress of each software of each vehicle. The OTA upgrade service system 26 can be a functional module integrated on the operation platform 25. Of course, the OTA upgrade service system 26 can also be a system independent of the operation platform 25.

[0036] In actual operation scenarios, for the target version of the target software to be updated, the target software version of the vehicles shipped after a certain time point may have been configured as the target version. Therefore, in an illustrated embodiment, the operation platform 25 can generate a breakpoint identifier for the vehicle pool, and the breakpoint identifier is used to divide the vehicle pool into a first vehicle sub-pool and a second vehicle sub-pool, the factory version of the target software of the vehicles in the first vehicle sub-pool is not the target version, and the factory version of the target software of the vehicles in the second vehicle sub-pool is the target version. The vehicles to be upgraded whose current version of the target software is lower than the target version to be updated are screened out from the first vehicle sub-pool.

[0037] Specifically, the breakpoint identifier can be the vehicle identification code of the first vehicle that does not need to be updated and shipped after a certain time node. The factory version of the vehicle shipped before the vehicle is not the target version, and the factory version of the vehicle shipped after the vehicle is the target version. Therefore, according to the vehicle identification code of each vehicle, the vehicle whose vehicle identification code is before the breakpoint identifier can be divided into the first vehicle sub-pool, and the vehicle whose vehicle identification code is after the breakpoint identifier can be divided into the second vehicle sub-pool. The operation platform 25 can query the current version of each vehicle in the first vehicle sub-pool from the OTA upgrade service system 26 according to the vehicle identification code in the data record of each vehicle in the first vehicle sub-pool, and then add it to the corresponding data record. Finally, the vehicles to be upgraded whose current version of the target software is lower than the target version to be updated are screened out from the first vehicle sub-pool. In this embodiment, this scheme divides the vehicle pool into the first vehicle sub-pool and the second vehicle sub-pool in advance, and then screens the vehicles to be upgraded from the first vehicle sub-pool instead of the total vehicle pool. Since the screening base is reduced, the screening efficiency can be improved.

[0038] In an illustrated embodiment, the operation platform 25 can query the latest vehicle information produced from the manufacturing execution system 21 at a preset time interval, and then add the newly added vehicles in the manufacturing execution system 21 to the vehicle pool. Specifically, if the factory version of the target software of the newly added vehicle queried is the target version, the vehicle is divided into the second vehicle sub-pool. If the factory version of the target software of the newly added vehicle queried is not the target version, the vehicle is divided into the first vehicle pool. In this embodiment, by dividing the newly added vehicles that need to be upgraded into the first vehicle pool and the newly added vehicles that do not need to be upgraded into the second vehicle pool, the efficiency of screening the vehicles to be upgraded can be improved.

[0039] Step 102: Acquire the operational attribute information of each vehicle to be upgraded, and select the OTA upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions from all vehicles to be upgraded.

[0040] The vehicles to be upgraded determined in step 101 from multiple managed vehicles are vehicles whose current versions are lower than the target version to be updated, indicating that these vehicles meet the prerequisite for upgrading, that is, the current version should be lower than the target version to be updated. Step 102 also needs to screen out OTA-upgradeable vehicles that meet the OTA upgrade conditions from the vehicles to be updated. Among them, the definition of an OTA-upgradeable vehicle can be a vehicle with upgrade requirements and OTA upgrade capabilities. For example, if vehicle A does not have an upgrade requirement, that is, the target software of vehicle A does not need to be upgraded, then vehicle A does not belong to an OTA-upgradeable vehicle. For another example, if vehicle A has an upgrade requirement but cannot be upgraded through OTA upgrade, then vehicle A also does not belong to an OTA-upgradeable vehicle. Specifically, based on the operational attribute information of each vehicle to be upgraded, OTA-upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions can be screened out from all vehicles to be upgraded.

[0041] In one illustrated embodiment, Figure 2 As shown, the manufacturing execution system 21 manages the body information of all vehicles on the production line of the automobile enterprise, including the physical specifications of the vehicle, the assembly process, quality control information, etc. The vehicles off the production line will be divided into vehicle information management systems of different departments according to their uses for division of labor management. For example, the delivered vehicles will be diverted to the delivery management system 22, which is responsible for managing the vehicle information of the delivered vehicles. The system is used to manage operational attribute information such as the delivery status and service information of the vehicle. The vehicles used for testing will be diverted to the test vehicle management system 23, which is responsible for managing the vehicle information of all test vehicles, such as operational attribute information such as the test data of the test vehicle. Of course, the vehicle can also be diverted to other vehicle information management systems for division of labor management by other vehicle information management systems 24, such as certified used car information management systems, subscription service car information management systems, exhibition car test drive car information management systems and other vehicle information management systems 24. The operation platform 25 can obtain the operational attribute information of the vehicle to be upgraded from each vehicle information management system according to the vehicle identification code of the vehicle to be upgraded, and filter out the OTA upgradeable vehicles that meet the OTA upgrade conditions from all vehicles to be upgraded according to the operational attribute information.

[0042] Exemplarily, the operational attribute information may include a purpose category. Purpose categories include, but are not limited to, commercial vehicles, permanent test vehicles, temporary test vehicles, domestic sales vehicles, certified in-stock vehicles, etc. Each vehicle can be identified by a purpose category. For example, if the purpose category of a vehicle is a commercial vehicle, the vehicle may not be marked as other purpose categories. The operation platform 25 can set screening rules according to the purpose category, and determine whether the vehicle has an upgrade requirement by the purpose category. For example, commercial vehicles and domestic sales vehicles have upgrade requirements, so it can be determined that OTA upgrades are required, while permanent test vehicles, temporary test vehicles, and certified in-stock vehicles have no upgrade requirements, so it can be determined that OTA upgrades are not required. It should be noted that the above is only an example, and the basis for the division of the purpose category may not be the division method of the above-mentioned embodiment, and whether a vehicle of a specific purpose category needs an OTA upgrade needs to be specifically set according to the needs of the car company. For example, for test vehicles (including permanent test vehicles and temporary test vehicles), car companies can divide them into those that require OTA upgrades or those that do not require OTA upgrades according to actual upgrade requirements. It is understandable that vehicles of different use categories are managed by different vehicle information management systems. Of course, vehicles of different use categories can also be jointly managed by the same vehicle information management system. For example, permanent test vehicles and temporary test vehicles can be jointly managed by the same test vehicle management system 23. Each vehicle information management system can set identification information for the use category of the vehicles it manages. For example, the delivery management system 22 can set the use category identification of commercial vehicles for all vehicles it manages, and the test vehicle management system 23 can set the use category identification of permanent test vehicles or temporary test vehicles for all vehicles it manages. The operation platform 25 can obtain the use category identification of the vehicle to be upgraded from each vehicle management subsystem according to the vehicle identification code of the vehicle to be upgraded, and determine whether the vehicle to be upgraded meets the OTA upgrade conditions according to the use category identification.

[0043] Exemplarily, the operation attribute information may also include a delivery status. When the operation platform 25 determines that the delivery status of the vehicle to be upgraded is a delivered status, it may be determined that the vehicle to be upgraded meets the OTA upgrade conditions. If the operation platform 25 determines that the delivery status of the vehicle to be upgraded is an undelivered status, it may be determined that the vehicle to be upgraded does not meet the OTA upgrade conditions.

[0044] It should be noted that for some specific usage categories, the operation platform can determine whether the vehicle to be upgraded meets the OTA upgrade conditions only based on the usage category. For example, if the usage category of the vehicle to be upgraded is a commodity vehicle, it can be directly determined that the vehicle to be upgraded meets the OTA upgrade conditions. The operation platform can also determine whether the vehicle to be upgraded meets the OTA upgrade conditions only based on the delivery status. For example, if the delivery status of the vehicle to be upgraded is a delivered status, it can be directly determined that the vehicle to be upgraded meets the OTA upgrade conditions. For some vehicles to be upgraded, they may not contain the operational attribute information of the delivery status, so they can be directly judged by the usage category. For example, the vehicle to be upgraded with the usage category of a permanent test vehicle does not contain the operational attribute information of the delivery status. At this time, it can be judged that the permanent test vehicle does not meet the OTA upgrade conditions only based on the usage category. In some cases, for vehicles to be upgraded with a specific usage category, it is necessary to judge whether the vehicle to be delivered meets the OTA upgrade conditions based on both the usage category and the delivery status. For example, for a vehicle to be upgraded with the usage category of a certified second-hand car, if the delivery status is an undelivered status, it is judged that the vehicle does not meet the OTA upgrade conditions; if the delivery status is a delivered status, it is judged that the vehicle meets the OTA upgrade conditions.

[0045] In one illustrated embodiment, Figure 3 As shown, after determining the OTA upgradeable vehicle, the operation platform 25 can further determine the delivery status of each OTA upgradeable vehicle. If the delivery status is delivered, a record list for the target software and target version can be generated for the OTA upgradeable vehicle and sent to the preset control agency 27. For example, the control agency 27 can be the Ministry of Industry and Information Technology. This solution automatically screens out vehicles that need to generate a record list from OTA upgradeable vehicles according to the delivery status, which can improve the automation of generating the record list.

[0046] In an illustrated embodiment, some sold vehicles may have already been OTA-upgraded to the target version of the vehicle's target software before this OTA upgrade task, but the upgrade failed. Therefore, the current version of the vehicle has not been upgraded to the target version and is still classified as an OTA-upgradeable vehicle in this task. In order to avoid "secondary OTA upgrade" for vehicles that cannot be OTA-upgraded, such as Figure 4As shown, in response to receiving the upgrade error log about the target software sent by the sold vehicle 28, the operation platform 25 adds an offline upgrade mark to the vehicle information of the sold vehicle 28, and selects OTA upgradeable vehicles from all vehicles to be upgraded. The operation attribute information of the OTA upgradeable vehicles meets the OTA upgrade conditions and its vehicle information does not contain an offline upgrade mark. In this way, vehicles that have failed to OTA upgrade before can be further excluded from the vehicles to be upgraded, avoiding another OTA upgrade for such vehicles. In addition, for the sold vehicles 28 that failed to OTA upgrade, an upgrade failure prompt can also be sent to them, and the user is advised to go to an offline store for offline upgrade.

[0047] Step 103: Notify the OTA upgrade service system to perform OTA upgrade on the target software of the OTA-upgradeable vehicle.

[0048] In this solution, vehicles that meet the OTA upgrade conditions are automatically selected from multiple managed vehicles based on custom screening rules. This process reduces manual intervention and improves the review efficiency of operators.

[0049] In an illustrated embodiment, the operation platform 25 can prepare an upgrade list of all OTA-upgradeable vehicles and send it to the OTA upgrade service system. The upgrade list includes the vehicle identification code of the vehicle, the target software, and the target version to be updated. After receiving the upgrade list, the OTA upgrade service system pushes the corresponding software update package to each OTA-upgradeable vehicle on the upgrade list to assist in upgrading the target software of the OTA-upgradeable vehicle from the current version to the target version.

[0050] To facilitate understanding of this solution, an example is given in combination with a real scenario. Figure 5 As shown, assuming that the car manufacturer releases the OS2.0 version of the vehicle operating system of vehicle model A, the operation platform 25 receives the upgrade task of the vehicle operating system for the vehicle model A. The operation platform 25 can query all managed vehicles under the vehicle model A from the manufacturing execution system 21, and form a vehicle pool 51A with the vehicle identification codes of all managed vehicles. The vehicle pool 51A can be presented in the form of a form on the front-end page of the operation platform 25 for the operator to view.

[0051] The operation platform 25 can generate a breakpoint identifier for the vehicle pool 51A, which can be the vehicle identification code of the first vehicle that leaves the factory after a certain time point and does not need to be updated. The factory version of the vehicle that leaves the factory before this vehicle is not the target version, and the factory version of the vehicle that leaves the factory after this vehicle is the target version. According to the vehicle identification code of each vehicle, the vehicle whose vehicle identification code is before the breakpoint identifier can be divided into the first vehicle sub-pool, and the vehicle whose vehicle identification code is after the breakpoint identifier can be divided into the second vehicle sub-pool.

[0052] The operation platform 25 can read the current versions of all managed vehicles in the first vehicle pool from the OTA upgrade service system 26, and add them to the data records of the corresponding vehicles in the first vehicle pool of the vehicle pool 51A to form a vehicle pool 51B. The data records also include the target software to be upgraded for each managed vehicle and the target version of the target software. At this time, the formed vehicle pool 51B includes different data columns such as vehicle identification code, target software, current version and target version. Of course, the vehicle pool can also include other data columns, such as the manufacturing date and offline date of the vehicle.

[0053] The operation platform 25 can screen out vehicles to be upgraded whose current version of target software is lower than the target version to be updated from the vehicle pool 51B.

[0054] After determining all the vehicles to be upgraded, the operation platform 25 can query the operation attribute information of the vehicles to be upgraded from various vehicle information management systems such as the delivery management system 22, the test vehicle management system 23, and other vehicle information management systems 24 according to the vehicle identification codes of all the vehicles to be upgraded, and add them to the vehicle pool 51B to form a vehicle pool 51C. The operation attribute information may include vehicle purpose and delivery status. The operation platform 25 automatically filters out OTA upgradeable vehicles that meet the OTA upgrade conditions, offline upgrade vehicles, and vehicles that do not need to be upgraded and have no upgrade requirements from the vehicles to be upgraded according to the vehicle purpose and / or delivery status. The specific screening process can be found in the aforementioned embodiment and will not be repeated here.

[0055] Finally, the vehicles that can be OTA upgraded are made into an upgrade list and sent to the OTA upgrade service system.

[0056] Corresponding to the embodiments of the aforementioned method, this specification also provides embodiments of a device and a terminal to which it is applied.

[0057] like Figure 6 As shown, Figure 6It is a structural diagram of an electronic device shown in this specification according to an exemplary embodiment. At the hardware level, the electronic device 600 includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610, and of course may also include hardware required for other services. One or more embodiments of this specification can be implemented based on software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into the memory 608 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each logic module, but can also be hardware or logic devices.

[0058] like Figure 7 As shown, Figure 7 This is a block diagram of a vehicle software upgrade device according to an exemplary embodiment of the present specification. The device can be applied to Figure 6 In the electronic device 600 shown in the figure, the technical solution of this specification is implemented. The device includes:

[0059] A vehicle to be upgraded determining module, used to determine a vehicle to be upgraded from a plurality of managed vehicles, wherein the current version of the target software of the vehicle to be upgraded is lower than the target version to be updated;

[0060] The OTA upgradeable vehicle determination module is used to obtain the operational attribute information of each vehicle to be upgraded, and select the OTA upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions from all vehicles to be upgraded;

[0061] The notification module is used to notify the OTA upgrade service system to perform OTA upgrade on the target software of the OTA-upgradeable vehicle.

[0062] Optionally, the vehicle to be upgraded determination module 702 is specifically used to determine the current version of the target software of the vehicles in the vehicle pool, and the vehicle pool is used to manage the vehicle information of multiple managed vehicles; and filter out the vehicles to be upgraded whose current version of the target software is lower than the target version to be updated from the vehicle pool.

[0063] Optionally, the vehicle determination module 702 for upgrading is specifically used to generate a breakpoint identifier for the vehicle pool, and the breakpoint identifier is used to divide the vehicle pool into a first vehicle sub-pool and a second vehicle sub-pool, the factory version of the target software of the vehicles in the first vehicle sub-pool is not the target version, and the factory version of the target software of the vehicles in the second vehicle sub-pool is the target version; and the vehicles for upgrading whose current version of the target software is lower than the target version to be updated are screened out from the first vehicle sub-pool.

[0064] Optionally, the device also includes a new vehicle module 708, which is used to classify the vehicle into the second vehicle sub-pool if the factory version of the target software of the newly added vehicle in the vehicle pool is the target version; if not, the vehicle is classified into the first vehicle sub-pool.

[0065] Optionally, the OTA upgradeable vehicle determination module 704 is specifically used for the operational attribute information including a usage category, and the screening out of all vehicles to be upgraded vehicles that can be upgraded and whose operational attribute information meets the OTA upgrade conditions includes: if the usage category of any vehicle to be upgraded is a preset usage category, then determining that the vehicle to be upgraded meets the OTA upgrade conditions; and / or, the operational attribute information includes a delivery status, and the screening out of all vehicles to be upgraded vehicles that can be upgraded and whose operational attribute information meets the OTA upgrade conditions includes: if the delivery status of any vehicle to be upgraded is a delivered status, then determining that the vehicle to be upgraded meets the OTA upgrade conditions.

[0066] Optionally, the device further includes a filing module 712, which is used to generate a filing list for the target software and the target version for the upgradeable vehicle and send it to a preset control agency if the delivery status of the OTA upgradeable vehicle is a delivered status.

[0067] Optionally, the device further includes an upgrade feedback module 710, which is specifically used to add an offline upgrade identifier to the vehicle information of the sold vehicle in response to receiving an upgrade error log about the target software sent by the sold vehicle. The OTA upgradeable vehicle determination module 704 is specifically used to filter out OTA upgradeable vehicles whose operating attribute information meets the OTA upgrade conditions from all vehicles to be upgraded, including: filtering out OTA upgradeable vehicles from all vehicles to be upgraded, the operating attribute information of the OTA upgradeable vehicles meeting the OTA upgrade conditions and the vehicle information does not contain an offline upgrade identifier.

[0068] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, which will not be repeated here.

[0069] For the device embodiment, since it basically corresponds to the method embodiment, the relevant parts can refer to the partial description of the method embodiment. The device embodiment described above is only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or they may be distributed on multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.

[0070] The present specification also provides a computer-readable storage medium having a computer program stored thereon, and when the program is executed by a processor, the steps of any of the aforementioned vehicle software upgrade methods provided in the present application are implemented.

[0071] Specifically, computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including, for example, semiconductor memory devices (such as EPROM, EEPROM and flash memory devices), magnetic disks (such as internal hard disks or removable disks), magneto-optical disks, and CD ROM and DVD-ROM disks.

Claims

1. A software upgrade method for a vehicle, characterized in that: The method comprises: Determining a vehicle to be upgraded from a plurality of managed vehicles, wherein a current version of target software of the vehicle to be upgraded is lower than a target version to be updated; Obtain the operational attribute information of each vehicle to be upgraded, and select the OTA upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions from all vehicles to be upgraded; The OTA upgrade service system is notified to perform OTA upgrade on the target software of the OTA-upgradeable vehicle.

2. The method according to claim 1, characterized in that The step of determining a vehicle to be upgraded from a plurality of managed vehicles includes: Determining a current version of target software of a vehicle in a vehicle pool, wherein the vehicle pool is used to manage vehicle information of a plurality of managed vehicles; Vehicles to be upgraded whose current versions of target software are lower than the target version to be updated are screened out from the vehicle pool.

3. The method according to claim 2, characterized in that The step of screening out vehicles to be upgraded whose current version of target software is lower than the target version to be updated from the vehicle pool includes: Generate a breakpoint identifier for the vehicle pool, the breakpoint identifier is used to divide the vehicle pool into a first vehicle sub-pool and a second vehicle sub-pool, the factory version of the target software of the vehicles in the first vehicle sub-pool is not the target version, and the factory version of the target software of the vehicles in the second vehicle sub-pool is the target version; Vehicles to be upgraded whose current version of target software is lower than the target version to be updated are screened out from the first vehicle sub-pool.

4. The method according to claim 3, characterized in that The method further comprises: If the factory version of the target software of the newly added vehicle in the vehicle pool is the target version, the vehicle is classified into the second vehicle sub-pool; If not, the vehicle is assigned to the first vehicle sub-pool.

5. The method according to claim 1, characterized in that: The operation attribute information includes a usage category, and the step of selecting OTA-upgradeable vehicles whose operation attribute information satisfies the OTA upgrade condition from all vehicles to be upgraded includes: if the usage category of any vehicle to be upgraded is a preset usage category, determining that the vehicle to be upgraded satisfies the OTA upgrade condition; and / or, The operational attribute information includes a delivery status, and the step of screening out OTA-upgradeable vehicles whose operational attribute information satisfies OTA upgrade conditions from all vehicles to be upgraded includes: if the delivery status of any vehicle to be upgraded is a delivered status, determining that the vehicle to be upgraded meets the OTA upgrade conditions.

6. The method according to claim 5, characterized in that The method further comprises: If the delivery status of the OTA-upgradeable vehicle is delivered, a filing list for the target software and the target version is generated for the upgradeable vehicle and sent to a preset control agency.

7. The method according to claim 1, characterized in that The method further includes: in response to receiving an upgrade error log regarding the target software sent by the sold vehicle, adding an offline upgrade identifier to the vehicle information of the sold vehicle; Filtering out OTA-upgradeable vehicles whose operating attribute information meets OTA upgrade conditions from all vehicles to be upgraded, including: filtering out OTA-upgradeable vehicles from all vehicles to be upgraded, wherein the operating attribute information of the OTA-upgradeable vehicles meets the OTA upgrade conditions and the vehicle information does not contain an offline upgrade identifier.

8. A software upgrade device for a vehicle, characterized in that: The device comprises: A vehicle to be upgraded determining module, used to determine a vehicle to be upgraded from a plurality of managed vehicles, wherein the current version of the target software of the vehicle to be upgraded is lower than the target version to be updated; The OTA upgradeable vehicle determination module is used to obtain the operational attribute information of each vehicle to be upgraded, and select the OTA upgradeable vehicles whose operational attribute information meets the OTA upgrade conditions from all vehicles to be upgraded; The notification module is used to notify the OTA upgrade service system to perform OTA upgrade on the target software of the OTA-upgradeable vehicle.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images