Method and system for repairing automobile software defects

Abstract

The invention discloses a method and system for repairing automobile software defects, and relates to the field of vehicle-mounted computers.The method comprises the steps that when it is determined that automobile software is in a to-be-repaired state based on a software running log, a software repairing task including software version information and a repairing task ID is generated; sending the software repair task to the user terminal, so that the user terminal obtains repair resources from the remote server when the network environment meets a preset network condition; after resource acquisition completion information returned by the user terminal is received, acquiring repair resources from the user terminal; after the integrity verification of the repair resource is successful, running a software installation update program based on the repair resource; after the restoration resources are loaded, restoration feedback information and vehicle self-inspection information are collected and sent to the user terminal, so that the user terminal uploads the restoration feedback information and the vehicle self-inspection information to the remote server. By implementing the method, software defect repair can be provided when the vehicle is located in an area with unstable network connection.

Description

Technical Field

[0001] The present application relates to the field of vehicle-mounted computers, and in particular to a method and system for repairing automotive software defects. Background Art

[0002] With the development of automobile intelligence and networking technology, modern cars increasingly rely on complex software systems to achieve functions such as autonomous driving, intelligent assisted driving, and vehicle networking. These software systems have greatly improved vehicle safety and driving experience by integrating advanced sensors, communication equipment, data processing, and control algorithms. However, complex software systems also bring new challenges, especially in extreme environments or emergencies, where software defects may cause system failures and thus affect driving safety.

[0003] Among related technologies, automotive software systems are mainly updated and maintained through OTA (Over-The-Air) technology. OTA technology allows automakers to push software updates to vehicles remotely, without the need for car owners to go to 4S stores for manual upgrades. This technology transmits data through wireless networks, can promptly fix software vulnerabilities, update functions, and improve system stability and security.

[0004] However, since vehicles are often located in areas with unstable network connections such as underground parking lots, related technologies may fail or be delayed in updating due to network problems when repairing automotive software defects. Summary of the invention

[0005] The present application provides a method and system for repairing automobile software defects, which are used to provide software defect repair when the vehicle is located in an area with unstable network connection.

[0006] In the first aspect, the present application provides a method for repairing automobile software defects, which is applied to a repair system, and the method includes: when it is determined based on the software operation log that the vehicle software is in a state to be repaired, generating a software repair task including software version information and a repair task ID; sending the software repair task to a user terminal, so that the user terminal obtains repair resources from a remote server when the network environment meets preset network conditions; after receiving resource acquisition completion information returned by the user terminal, obtaining repair resources from the user terminal; after the integrity check of the repair resources is successful, running a software installation update program based on the repair resources; after the repair resources are loaded, collecting and sending repair feedback information and vehicle self-test information to the user terminal, so that the user terminal uploads the repair feedback information and vehicle self-test information to the remote server.

[0007] In the above embodiment, the repair system can automatically determine the software status based on the software operation log. When it is determined that there is a problem to be repaired, a repair task containing key information can be generated and actively sent to the car owner's terminal. At the same time, considering the unstable network environment of the car owner, the system actively obtains the complete repair resource file from the cloud based on the user terminal when conditions permit. After obtaining the resources, an integrity check is performed first to ensure that the resources are correct, and then the software installation and update program can be started to automatically repair the defects. In addition, after the repair is completed, the system immediately collects the repair effect and vehicle self-test information, encrypts and packages it and sends it to the car owner's terminal, which then uploads it to the cloud securely. In this way, the automatic discovery and repair of vehicle-mounted software problems can be achieved, and feedback on the repair effect can be obtained in a timely manner, which improves the intelligence level of the repair and user experience.

[0008] In combination with some embodiments of the first aspect, in some embodiments, a software repair task is sent to a user terminal so that the user terminal obtains repair resources from a remote server when the network environment meets preset network conditions, specifically including: sending a software repair task to the user terminal; obtaining vehicle status information and terminal positioning information and network status information returned by the user terminal; when it is determined based on the vehicle status information and terminal positioning information that the vehicle has stopped running and there is a deviation between the user terminal position and the vehicle position, or the network status information meets the preset network conditions, sending a software repair prompt to the user terminal so that the user terminal runs a repair program corresponding to the software repair task, and the repair program is used to obtain repair resources from a remote server.

[0009] In the above embodiment, the repair system will comprehensively judge multi-dimensional conditions such as vehicle status, owner location, and network quality, and select the best time to trigger repair. First, through the vehicle status information (such as speed, gear, etc.), it can be judged whether the vehicle is in a parked state. If the vehicle is driving, repair should be avoided to ensure driving safety. Secondly, by obtaining the owner's mobile phone location information and comparing it with the vehicle location, it can be judged whether the owner is currently in the car. If the owner is far away from the car, the repair acquisition can be started. In addition, a good network environment (such as WiFi, high 4G signal strength, etc.) is also a necessary condition for online repair. In the composite scenario of the car stopping, the person leaving or the network being good, automatically prompting and starting the repair program to obtain cloud resources can maximize the safety and smooth progress of the repair and improve the success rate of the repair.

[0010] In combination with some embodiments of the first aspect, in some embodiments, after the repair resources are loaded, the repair feedback information and the vehicle self-test information are collected and sent to the user terminal, so that the user terminal uploads the repair feedback information and the vehicle self-test information to the remote server, specifically including: recording the event log and user operations during the software installation and update process, and extracting the repair start and end time, resource version number and upgrade results, and generating repair feedback information; after the repair resources are loaded, collecting the operating status data and fault diagnostic codes of each electronic control unit of the vehicle, and generating vehicle self-test information; encrypting and digitally signing the repair feedback information and the vehicle self-test information, and packaging them to generate a repair result data packet; sending the repair result data packet to the user terminal, so that the user terminal uploads the repair result data packet to the remote server.

[0011] In the above embodiment, the repair system can comprehensively record key data of the software installation and update process, such as event logs, user operations, repair duration, version number, results, etc., to form a complete repair report, which is convenient for tracking and evaluating the repair quality. At the same time, the real-time operating status and fault codes of each ECU of the vehicle are collected immediately after the repair, and a vehicle self-inspection report is automatically generated to intuitively reflect the repair effect. After the system packages the repair report and the self-inspection results and takes security measures such as encryption and digital signature, it is securely uploaded through the owner's terminal to prevent data tampering and clarify responsibility.

[0012] In combination with some embodiments of the first aspect, in some embodiments, before sending a software repair task to a user terminal so that the user terminal obtains repair resources from a remote server when the network environment meets preset network conditions, the method also includes: obtaining resource integrity information returned by the remote server based on the index information of the repair resources in the software repair task; when the resource integrity information is missing data, sending a resource abnormality prompt to the user terminal and suspending the software repair task.

[0013] In the above embodiment, the repair system can avoid repair interruptions caused by missing cloud data. Specifically, before allowing the car owner terminal to obtain the repair resources, the system will first actively obtain the integrity information of the cloud resources based on the resource index information in the task. Once it is found that the resources are missing, the system will immediately send a resource anomaly prompt to the car owner terminal and automatically suspend the repair task. This can provide an early warning before the problem data flows to the vehicle end, avoiding the vehicle end from receiving incomplete repair data packets, resulting in repair failures or even program anomalies, affecting vehicle operation. In addition, early perception of cloud data anomalies also buys time for operation and maintenance personnel to troubleshoot problems, and resource files can be repaired as soon as possible, reducing the impact on the car owner's repair plan and improving the stability and reliability of the repair service.

[0014] In combination with some embodiments of the first aspect, in some embodiments, when the resource integrity information is missing data, a resource abnormality prompt is sent to the user terminal, and after the step of suspending the software repair task, the method also includes: determining the repair priority and repair deadline of the software repair task, and obtaining the maintenance site information within a preset distance of the current position of the vehicle; if the repair priority is higher than the preset warning value and the repair deadline is lower than the preset remaining deadline, pushing the repair warning message and maintenance site information to the user terminal; detecting the execution progress of the software repair task, if the repair deadline expires and the status of the software repair task is still incomplete, sending an overdue reminder to the user terminal, and uploading the overdue record to the remote server.

[0015] In the above embodiment, the repair system can take a variety of measures to urge users to repair the suspended high-priority tasks in a timely manner. First, the system will evaluate the priority and deadline of the repair task, and pay special attention to high-priority (such as those involving safety hazards) and tasks that are close to the deadline. Secondly, the system searches for information about repair shops within a certain range around the vehicle to facilitate nearby repair arrangements. When a high-priority task is blocked, the system will actively push a warning reminder to the owner, informing him of the urgency of the problem and guiding him to upgrade the software at a nearby repair shop as soon as possible. In addition, the system will track the progress of the task in real time. If it is overdue and not completed, the user will be reminded again, and the cloud will be reported to trigger manual intervention.

[0016] In combination with some embodiments of the first aspect, in some embodiments, after receiving the resource acquisition completion information returned by the user terminal, after the step of acquiring the repair resource from the user terminal, the method also includes: based on the software version information and the metadata of the repair resource, comparing the current software version installed in the current vehicle to obtain the version change value; when the version change value is not greater than the preset version threshold, determining that the update mode of the current software version is incremental update; extracting the differential package from the repair resource.

[0017] In the above embodiment, the repair system can adaptively select full or incremental update mode based on software version analysis. The system compares the installed version of the vehicle with the target version to obtain a numerical measure of the difference between the two. If the difference is not large (such as only 1-2 small versions), only the differential upgrade package between the two versions can be transmitted without the need for a complete new version installation package, which can significantly reduce the size of the data packet and reduce network transmission time and traffic costs. Especially in the case of unstable network, incremental upgrades can greatly improve the repair success rate and user experience. On the contrary, if the version span is large and the number of difference files is too large, it will be converted to a full upgrade. The repair system automatically selects incremental or full upgrades based on metadata and version differences, which can find the best balance between repair efficiency and cost, simplify user operations, and improve the intelligence level of repair.

[0018] In combination with some embodiments of the first aspect, in some embodiments, after the step of extracting the differential package from the repair resources, the method also includes: obtaining the start time of the incremental update set by the user; at the start time, determining whether the current power of the vehicle is higher than the safety update threshold; if not, delaying the start time and sending a delayed update prompt to the user terminal.

[0019] In the above embodiment, the repair system will intelligently judge the vehicle status to avoid upgrade abnormalities caused by insufficient power during incremental updates. After obtaining the differential upgrade package, if the user sets a scheduled upgrade plan, the system will first evaluate the vehicle's power at the beginning of the plan. If the power is too low when the upgrade is started (such as less than 20%), the system will not execute the plan temporarily and notify the user, and will automatically start again when the power returns to above the safety threshold. The power level is a key factor in whether the software upgrade can be completed smoothly. If the power is cut off in the middle, it will seriously affect the upgrade quality and even cause software failure. The repair system avoids this risk through an adaptive delay mechanism, and can intelligently adjust the upgrade plan in the background, which can not only ensure a safe and smooth upgrade, but also significantly improve the owner's upgrade experience.

[0020] In a second aspect, an embodiment of the present application provides a repair system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the repair system to perform the method described in the first aspect and any possible implementation method of the first aspect.

[0021] In a third aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when the computer program product is run on a repair system, enables the repair system to execute the method described in the first aspect and any possible implementation of the first aspect.

[0022] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a repair system, enable the repair system to execute the method described in the first aspect and any possible implementation of the first aspect.

[0023] It is understandable that the repair system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the method provided in the embodiment of the present application. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding method, which will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. Since the solution of automatically judging the software status and generating repair tasks based on the software operation log is adopted, the automatic discovery and repair of vehicle-mounted software problems can be realized, which effectively solves the problem of manual investigation and triggering of repair in the existing technology, and thus realizes the intelligent and unmanned repair process.

[0025] 2. Since the solution is adopted to comprehensively judge multi-dimensional conditions such as vehicle status, owner's location and network quality, and select the best time to trigger the repair, it can maximize the safety and smooth progress of the repair, effectively solve the safety hazards and repair failures caused by blindly triggering repairs in the existing technology, and thus realize conditional perception and intelligent scheduling of the repair process.

[0026] 3. Since the solution of adaptively selecting full or incremental update mode according to the difference in software versions is adopted, the best balance can be found between repair efficiency and cost, which effectively solves the data redundancy and upgrade delay problems caused by the unified full upgrade in the existing technology, and thus realizes differentiated intelligent distribution and precise repair. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a flow chart of a method for repairing automobile software defects in an embodiment of the present application; Figure 2 is another flowchart of the method for repairing automobile software defects in an embodiment of the present application; Figure 3 It is a schematic diagram of the structure of a physical device of the repair system in an embodiment of the present application. DETAILED DESCRIPTION

[0028] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to be used as limitations to the present application. As used in the specification of the present application, the singular expressions "one", "a kind of", "above", "the" and "this" are intended to also include plural expressions, unless there is a clear indication to the contrary in the context. It should also be understood that the term "and / or" used in the present application refers to any or all possible combinations comprising one or more of the listed items.

[0029] In the following, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as suggesting or implying relative importance or implicitly indicating the number of the indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, "plurality" means two or more.

[0030] For ease of understanding, the application scenarios of the embodiments of the present application are introduced below.

[0031] In the context of the development of intelligent and networked automobiles, in-vehicle software systems are becoming increasingly complex. In special environments or emergencies, software defects may cause system failures, and the impact on driving safety is becoming increasingly prominent. For example, due to a software bug in the perception and decision-making system of a semi-autonomous driving car, the system failed to identify obstacles ahead in a certain low-light environment. Fortunately, the driver took over in time to avoid an accident. Automakers need to establish an efficient mechanism for repairing automotive software defects, promptly repair software vulnerabilities, update system functions, and eliminate safety hazards. However, when the vehicle is driving or in parking locations such as underground parking lots, it is often located in areas with unstable or even no network signals. How to repair software defects in this situation has become a major challenge.

[0032] In related technologies, the repair of automotive software defects can be achieved by adopting OTA remote upgrade technology. Specifically, the car company pushes the software update package to the vehicle remotely through the Internet, and the vehicle system directly downloads and installs the software from the cloud to repair software vulnerabilities and update system functions. This method saves the owner the trouble of going to the 4S store for manual upgrades. The following introduces the scenario of using the method of repairing automotive software defects in related technologies.

[0033] The current mainstream solution for repairing automotive software defects is OTA remote upgrade technology. Car companies push software update packages to vehicles remotely through the Internet, and the vehicle system directly downloads and installs the software from the cloud. This solution saves car owners the trouble of going to 4S stores for manual upgrades. However, in actual use, the OTA solution has exposed some defects. For example, during an OTA upgrade of a certain brand of car, the vehicle happened to be parked in an underground garage. Due to the weak network signal of the vehicle system, the software package was particularly large, and there was a network interruption during the download, resulting in the failure of the software update. The owner found the problem when he got in the car the next day and could not start the vehicle normally, so he had to contact the after-sales staff to come to the door to deal with it.

[0034] The method for repairing automobile software defects in the embodiment of the present application uses the user's smartphone as a transfer. The user's smartphone first obtains a complete software repair resource package from the cloud in a stable network environment, and then the vehicle-mounted system obtains the software package from the smartphone over a short distance at an appropriate time and starts the upgrade, thereby realizing software repair in an unstable network situation of the vehicle. This not only improves the success rate of software repair, but also avoids the impact of the repair process on vehicle driving, ensuring driving safety. The following introduces the scenarios in which the method for repairing automobile software defects in the present application is used.

[0035] In response to the network instability faced by OTA upgrades, a vehicle manufacturer introduced the method for repairing automotive software defects in this application. The solution uses the owner's smartphone as a transit point to download the complete software repair resource package from the cloud through the user's mobile phone. When the vehicle is parked and it is detected that the vehicle system has established a stable Bluetooth or WiFi connection with the user's mobile phone, the vehicle system obtains the software package from the mobile phone and starts the upgrade. When a car owner parked his car in the underground garage at home, the vehicle system detected a software repair task. Due to the poor 4G network signal in the underground garage, the system sent a notification to the owner's mobile phone. It happened that the WiFi signal at the owner's home was good. After the owner returned home, the mobile phone completed the download of the software package at home by itself, and when the owner got in the car again, it was transmitted to the vehicle system via Bluetooth. Everything went smoothly during the upgrade process, and there was no failure encountered in the previous OTA. This software repair method that uses the user's mobile phone for distribution avoids dependence on the vehicle system network and improves the success rate of repair.

[0036] It can be seen that the method for repairing automobile software defects in the embodiment of the present application can not only realize the repair of automobile software defects, but also effectively solve the problem that the vehicle system is prone to failure when directly performing OTA upgrades in an unstable network environment, thereby achieving the purpose of improving the success rate of software repair and the convenience of vehicle use.

[0037] For ease of understanding, the following describes the process of the method provided by this implementation in combination with the above scenario. Figure 1 , which is a flow chart of a method for repairing automotive software defects in an embodiment of the present application.

[0038] S101. When it is determined based on the software operation log that the vehicle software is in a state to be repaired, a software repair task including software version information and a repair task ID is generated.

[0039] Among them, the software operation log refers to a log file that records event information, performance parameters, error records, etc. generated during the operation of the vehicle software system. It is an important basis for monitoring and analyzing the software operation status. The state to be repaired refers to the state where the vehicle software system has defects, failures, or needs to be upgraded and updated, and needs to be repaired to restore normal operation or improve performance. The software version information represents the model, version number, release date and other information that identifies the software version of the vehicle software, which is used to determine the target version that needs to be repaired. The repair task ID is an identification number used to uniquely identify a software repair task, which is convenient for managing and tracking the repair process. The software repair task refers to a complete remote repair activity formulated for a version of the vehicle software to be repaired, including a series of operation steps such as obtaining repair resources, installing and updating software, and feedback on repair results.

[0040] Specifically, when the vehicle software is detected to be in a state to be repaired, the repair system will automatically determine whether to immediately start a software repair task based on the pre-configured strategy. If the conditions are met, the software repair task will be generated, and the repair task ID will be formed based on the target software version to be repaired and the task generation time. Then the software version information and repair task ID and other contents are encapsulated as software repair task data, which is used to guide the execution of the repair process in subsequent links.

[0041] In some embodiments, the generation of software repair tasks can be achieved in a variety of ways: Optionally, the repair system regularly and automatically analyzes and summarizes the software operation logs reported by the vehicle, and compares the abnormal information with the known software defect library when an abnormality is found, and preliminarily determines whether it is in a state to be repaired; if so, the target software version is determined in combination with the vehicle configuration information, and a repair task ID is generated together with the current timestamp to form a software repair task. Optionally, the repair system receives a software fault warning reported in real time by the vehicle system, extracts the fault code in the warning, and queries the software repair knowledge base to confirm the state to be repaired; if it is confirmed that a repair is required, the software version information is extracted from the warning content, and a repair task with a task ID is generated accordingly. It is understandable that other methods can also be used to achieve the generation of software repair tasks, such as manual creation by car companies, remote distribution by software developers, etc., which are not limited here.

[0042] S102: Sending a software repair task to a user terminal so that the user terminal obtains repair resources from a remote server when a network environment meets a preset network condition.

[0043] Among them, user terminals usually refer to the owner's personal smart devices, such as smartphones, tablets, etc. Preset network conditions refer to pre-set network environment requirements based on factors such as the amount of data of the repair resources, user traffic packages, and download time, such as WiFi connection, 4G network signal strength, etc. Repair resources refer to various data files required to implement software repairs, such as software installation packages, upgrade patches, configuration files, etc. Remote servers refer to servers deployed in the background cloud to provide software repair support, which are used to centrally manage and store repair resource files, task progress, vehicle information and other data.

[0044] Specifically, after the software repair task is generated, the repair system sends the task-related information to the car owner's user terminal APP. After receiving the task, the APP will detect the current network status in real time until it meets the preset ideal network conditions (such as being in a WiFi environment, 4G signal is stable, etc.), and then prompt the user to start downloading the repair resource. If the user agrees, the APP will access the download interface provided by the remote server, transmit the repair task ID and other identity authentication information, and after the server verification is passed, the corresponding repair resource file will be transmitted to the user terminal.

[0045] S103: After receiving the resource acquisition completion information returned by the user terminal, obtain the repair resource from the user terminal.

[0046] The resource acquisition completion information refers to a notification message fed back to the repair system immediately after the user terminal successfully downloads the repair resource file from the remote server, indicating that the resource is ready.

[0047] Specifically, after sending the software repair task, the repair system will wait for the response of the user terminal until it receives the resource acquisition completion information from the user terminal, and then the system will start to establish a data connection with the terminal. After the connection is successful, the repair system initiates a resource transmission request. After receiving the request, the user terminal reads the locally downloaded repair resource file and transmits the resource file back to the repair system through the data connection. The repair system receives the resource file, decompresses it, verifies it, and other processes it to prepare for the next software installation and update.

[0048] In some embodiments, the acquisition of repair resources from the terminal to the vehicle-mounted system can be achieved in a variety of ways: Optionally, the repair system and the user terminal use WiFi direct connection or vehicle-mounted WiFi hotspot to establish a local area network connection, and quickly transmit the repair resources in a high-bandwidth wireless network; Optionally, the repair system is paired with the user terminal via Bluetooth, and the repair resource file is obtained using Bluetooth communication. The transmission rate is relatively slow but more stable and reliable. It is understandable that other methods can also be used to achieve the acquisition of repair resources, such as wired USB connection, etc., which are not limited here.

[0049] S104: After the integrity check of the repair resource is successful, run the software installation update program based on the repair resource.

[0050] Among them, integrity verification refers to verifying whether the resource is complete and has not been tampered with by comparing and repairing the feature values ​​of the resource file, such as size, format, and digital signature. Software installation and update programs usually exist in the form of independent apps, which are used to perform a series of installation operations such as decompression of software installation packages, overwriting updates, and configuration validation.

[0051] Specifically, after obtaining the repair resources, the repair system will first perform integrity checks on the resource files one by one to ensure that the resources are consistent with the original version on the remote server and that there are no errors during the download and transmission process. If the check passes, the repair system will start the software installation and update program and pass the repair resources as input parameters to the program. The installation and update program reads the software installation package data and starts the software upgrade according to the set installation steps until the installation is complete. Installation logs will be collected in the middle to record the upgrade progress and important nodes. The entire upgrade process is usually completed silently in the background and does not affect the normal use of the vehicle.

[0052] S105 . After the repair resource is loaded, the repair feedback information and the vehicle self-check information are collected and sent to the user terminal, so that the user terminal uploads the repair feedback information and the vehicle self-check information to the remote server.

[0053] Among them, repair feedback information refers to the summary data of the execution of each link of the software repair task, including the start and end time of the repair, the repair resource version, the upgrade results, the key event log, etc. The vehicle self-test information refers to the status data of each module of the vehicle collected by the on-board diagnostic system after the repair is completed, such as fault codes, electronic control unit working parameters, etc.

[0054] Specifically, after the vehicle software is installed and updated, the repair system will immediately collect the repair logs, owner operation records and other information generated during the upgrade process, and extract key data to form repair feedback information. At the same time, the repair system accesses each electronic unit of the vehicle through the internal communication bus, broadcasts diagnostic requests, collects the operating status data returned by each unit, and summarizes the vehicle self-inspection information. These two types of information can comprehensively evaluate the effect of this software repair and the overall condition of the vehicle after the repair. The repair system packages and encrypts the two types of collected information and sends or synchronizes them to the user terminal. After receiving the data, the user terminal automatically uploads it to the remote server through the APP, completing a complete software repair process.

[0055] In some embodiments, repair information feedback and vehicle self-inspection can be implemented in a variety of ways: Optionally, the repair system records the repair logs of key nodes in real time during the software upgrade, and after the upgrade, it actively diagnoses and collects vehicle status data on the vehicle CAN bus to obtain repair result feedback as soon as possible; Optionally, after the software upgrade is completed, the repair system starts the repair information collection service to reside in the background, passively waits for the vehicle self-inspection data regularly reported by the on-board diagnostic system, and responds to the repair information query request of the remote server, and returns the locally saved repair log. It is understandable that other methods can also be used to implement repair result feedback, such as linkage with the on-board monitoring system, active triggering of vehicle self-inspection, etc., which are not limited here.

[0056] In the above embodiment, remote repair in a weak network environment is achieved by using the user's smartphone as a transfer of software repair resources. In actual applications, the software repair strategy can be further optimized according to the characteristics of different vehicle models. For example, for models that often travel long distances, the characteristics of the vehicle's driving route can be considered, and the software package can be downloaded in advance before the trip; for models that often travel on urban roads, you can choose to repair the vehicle when it is parked at night to minimize the impact on the vehicle. Through differentiated software repair strategies, repair efficiency and user experience can be improved.

[0057] The following is a supplement to the scenario of this embodiment.

[0058] On the basis of applying this application plan, the vehicle manufacturer has further optimized the software repair strategy for the use scenarios of specific models. For example, for an SUV model that focuses on long-distance travel, the manufacturer has fully considered the situation that the vehicle often encounters unstable 4G network areas during high-speed driving, and has formulated a special repair strategy: the system prefers to push software repair tasks and complete the download of software packages when the vehicle is parked and the user's mobile phone is in a stable WiFi environment. At the same time, the system will refer to the vehicle's historical driving trajectory and parking location, predict the weak network area that may be encountered next time, and download the software package in advance. A car owner plans to drive to travel to other places. Based on his historical travel records, the system judges that he often encounters unstable 4G network sections such as mountain tunnels along the way. Therefore, when the vehicle is parked the day before departure, the repair and update of key software modules have been completed in advance.

[0059] After combining the above scenarios, the following is a more detailed description of the process of the method provided by this implementation. Figure 2 , is another flow chart of the method for repairing automobile software defects in an embodiment of the present application.

[0060] S201. When it is determined based on the software operation log that the vehicle software is in a state to be repaired, a software repair task including software version information and a repair task ID is generated.

[0061] Referring to step S101 , the repair system generates a software repair task.

[0062] S202: Obtain resource integrity information returned by a remote server according to index information of the repair resource in the software repair task.

[0063] The software repair task contains the index information of the repair resource, which is used to uniquely identify and locate the resource file required for the repair. Resource integrity information refers to the data integrity status data about the repair resource returned by the remote server, indicating whether the resource file is complete, the size of each file, and the checksum value.

[0064] Specifically, after generating a software repair task, the repair system extracts the repair resource index information in the task data, such as the resource file name list, version number, etc. Then the repair system immediately accesses the resource management interface of the remote server, passes in the index information, and requests the server to return the integrity information of the batch of resource files. After receiving the request, the server queries the storage record of the resource according to the index, generates the actual data volume of the resource, the integrity information of each file checksum, etc., and returns it to the repair system.

[0065] In some embodiments, the cloud resource integrity information can be obtained in a variety of ways: optionally, the repair system accesses the resource query interface of the file server, inputs the index information, and obtains the storage path, compressed package size, name and checksum of each sub-file of the resource; optionally, the repair system queries the database server for the metadata record of the resource, and obtains the resource version number, storage time, original size, integrity mark and other status information. It is understandable that other methods can also be used to obtain resource integrity information, such as calling the cloud storage API, accessing the content distribution network, etc., which are not limited here.

[0066] S203: When the resource integrity information indicates data missing, a resource abnormality prompt is sent to the user terminal, and the software repair task is suspended.

[0067] Among them, the resource integrity information indicates data missing, usually because the cloud has not received the complete repair resource upload, or the resource file is lost or damaged during the migration process. Resource abnormality prompt is a notification message sent by the repair system to the user terminal APP, informing the user that the current cloud resource is abnormal and the software repair task needs to be suspended.

[0068] Specifically, after the repair system obtains the resource integrity information, it will parse it and find that the data status field is marked as "missing" or "incomplete", or the checksum value of the key file does not match the record, it is determined that there is an abnormality in the cloud resource file. At this time, the system immediately sends a resource abnormality prompt to the user terminal APP corresponding to the task, informing the user that "the repair resource is incomplete, please wait for the background to complete and update again". At the same time, the repair system automatically suspends the current software repair task and waits for manual processing of the resource problem. Until the resource integrity returns to normal, the task can be manually resumed.

[0069] In some embodiments, resource anomalies can be handled in a variety of ways: Optionally, the repair system parses resource metadata, and if it finds that key files are missing or the checksum values ​​are inconsistent, it pushes a resource anomaly prompt to the user terminal, prompting the user "Resource synchronization, please try again later"; at the same time, a pause instruction is sent to the task management module to set the task status to "blocked"; Optionally, the repair system compares the storage record of the resource with the actual file, and if it finds that the data does not match, a prompt window pops up to the terminal to inform the user of the reason and guide the user to feedback the problem; the system automatically changes the task status to "pending repair", records the resource defect and waits for manual intervention. It is understandable that other methods can also be used to handle resource anomalies, such as trying to re-acquire, prompting the user to clean up the local cache, etc., which are not limited here.

[0070] In some embodiments, the repair system determines the repair priority and repair deadline of the software repair task, and obtains the maintenance site information within a preset distance of the vehicle's current location; if the repair priority is higher than the preset warning value and the repair deadline is lower than the preset remaining deadline, the repair warning message and maintenance site information are pushed to the user terminal; the execution progress of the software repair task is detected, and if the repair deadline expires and the status of the software repair task is still incomplete, an overdue reminder is sent to the user terminal, and the overdue record is uploaded to the remote server.

[0071] Among them, the repair priority refers to the urgency of the software repair task, which is usually assessed based on factors such as the severity of the software defects and the scope of impact, and is expressed in numerical values ​​or levels. The repair deadline indicates the deadline for completing the repair task, which is generally set by the task issuer. The preset warning value is the priority judgment threshold pre-set by the repair system. A value above this value indicates that the task is very urgent. The preset remaining deadline is used to indicate an advance amount of time remaining in the repair deadline. A value below this value means that the task is approaching the deadline. The maintenance site information includes data such as the name, address, and navigation path of automobile maintenance outlets within a certain range from the vehicle's location. The repair warning message is a message notification used to prompt users to repair software problems as soon as possible, including instructions on the necessity of repair and recommended operations.

[0072] Specifically, when the repair system issues a software repair task, it will evaluate the priority of the task, such as marking critical defects involving safety as the highest level. At the same time, the task also includes completion deadline information. The system obtains the location coordinates of the vehicle in real time and searches for information about auto repair shops within a certain radius (such as 5 kilometers). When a high-priority task (such as greater than 8) appears and there is not much time left before the deadline (such as within 3 days), the system will determine it as an urgent task. At this time, on the one hand, the system will push a warning message to the car owner's terminal to prompt him to repair the software as soon as possible; on the other hand, it will also synchronize the location of nearby repair stations to guide users to upgrade nearby. For ongoing tasks, the system will continue to track their repair progress. If it is still not completed after the deadline, it will remind the user again and report the overdue information for background analysis constraints. The purpose of these measures is to ensure that high-risk software problems can be taken seriously and repaired in a timely manner to avoid long-term legacy risks.

[0073] In some embodiments, software repair supervision and reminder can be implemented in a variety of ways: Optionally, the repair system sets the priority according to the defect level, such as "level 1-4: low, level 5-7: medium, level 8-10: high"; configure the warning threshold (such as 8) and the remaining deadline threshold (such as 72 hours) at the same time, evaluate the urgency of the task in real time, and push warning reminders through the vehicle screen, the owner's APP, SMS, etc. when the threshold is exceeded, and search for auto repair shops within 3 kilometers of the current location to guide users to repair as soon as possible; if the task is overdue and not completed, the task execution log is recorded and submitted to the cloud, and voice and text reminders are used to complete the repair as soon as possible; Optionally, the repair system regularly (such as every day) polls the unfinished tasks, sorts them from high to low priority, and repeatedly reminds the owner through multiple channels for the top N (such as 3) most urgent tasks, prompting "N serious software problems have been found, please upgrade and repair immediately, the nearest repair outlets are as follows", and the overdue tasks are marked as abnormal, triggering manual follow-up processing. It can be understood that other methods can also be used to implement software repair supervision, such as calculating risk factors, intelligent recommendation strategies, etc., which are not limited here.

[0074] S204: Send the software repair task to the user terminal, so that the user terminal obtains repair resources from the remote server when the network environment meets the preset network conditions.

[0075] Referring to step S102, the repair system obtains repair resources from the remote server.

[0076] In some embodiments, the repair system sends a software repair task to the user terminal; obtains vehicle status information and terminal positioning information and network status information returned by the user terminal; and when it is determined based on the vehicle status information and terminal positioning information that the vehicle has stopped running and there is a deviation between the user terminal position and the vehicle position, or the network status information meets the preset network conditions, sends a software repair prompt to the user terminal, so that the user terminal runs the repair program corresponding to the software repair task, and the repair program is used to obtain repair resources from a remote server.

[0077] Among them, software repair tasks usually include key information such as the identification, version, and repair deadline of the target software to be repaired. Vehicle status information refers to the current operating status data of the vehicle collected by the on-board sensors, such as engine speed, vehicle speed, gear position, etc. Terminal positioning information represents the real-time positioning data of the user's mobile terminal (such as a mobile phone). Network status information is used to characterize the current network connection quality, such as signal strength, bandwidth, latency and other parameters. The repair program is a set of program codes used to execute the software repair process, which is usually sent to the user terminal in advance and started to run at the appropriate time.

[0078] Specifically, when the repair system decides to perform software repair on a certain vehicle, it will push the corresponding repair task to the owner's mobile APP. At the same time, the system obtains the vehicle's status information in real time and analyzes whether the vehicle is in a parked state. The system will also obtain the location information of the owner's mobile phone to determine whether the owner may not be in the car at present (the mobile phone and the vehicle are far apart). In addition, the system will also evaluate the current network status to see if the conditions for performing online repairs are met (such as WiFi connection, good signal strength, etc.). When one of the above conditions is met, that is, the vehicle stops and the owner gets off, or when the mobile phone network is detected to be good, the system will trigger the software repair. At this time, a repair prompt message will be pushed to the owner's mobile phone, and then the preset repair program will be automatically started on the mobile phone. The repair program will first connect to the remote server to authenticate the identity, and then download the complete repair resource file of the corresponding version to prepare for the implementation of the software repair.

[0079] S205: After receiving the resource acquisition completion information returned by the user terminal, obtain the repair resource from the user terminal.

[0080] Referring to step S103, the repair system acquires repair resources.

[0081] S206: Based on the software version information and the metadata of the repair resource, compare the current software version installed in the current vehicle to obtain a version change value.

[0082] The software version information indicates the target software version number of the repair task target. The metadata of the repair resource refers to the descriptive data provided with the resource file, including file type, compatible vehicle model, target version number, change content and other information. The version change value is used to quantify the size of the change between the current version and the target version, and is a numerical indicator for comprehensively evaluating the update amount.

[0083] Specifically, after obtaining the repair resource file, the repair system first reads the metadata of the resource to learn the target version of this update. Then it accesses the vehicle system settings to query the actual version number of the current software. The repair system compares the two version numbers and converts them into a version change value according to preset rules. For example, if the target version is V2.0 and the current version is V1.5, the change value may be 12 (larger version numbers have higher weights). The change value intuitively reflects the amount of code that needs to be changed for this repair. The larger the value, the more updated content.

[0084] In some embodiments, quantitative evaluation of version changes can be achieved in a variety of ways: Optionally, the repair system extracts the target version number from the resource metadata, subtracts it from the current version number recorded in the vehicle firmware information, and multiplies the result by a weight coefficient to obtain the version change value; Optionally, the repair system compares the resource metadata and software installation configuration, analyzes the code changes of common files, counts the number of changed code lines, functions, and modules, and weights them to obtain a comprehensive version change metric. It is understandable that other algorithms can also be used to evaluate the amount of version changes, such as semantic version analysis, code similarity comparison, etc., which are not limited here.

[0085] S207: When the version change value is not greater than a preset version threshold, determine that the update mode of the current software version is incremental update.

[0086] The preset version threshold is a pre-set judgment limit based on factors such as vehicle model and software characteristics, which is used to distinguish the difficulty of version updates. The incremental update mode refers to modifying only part of the code based on the original version. It is suitable for situations where the version changes are small and the upgrade efficiency is higher.

[0087] Specifically, the repair system compares the version change value obtained in the previous step with one or more preset version thresholds. If the change value is less than a specific threshold, such as 20, it is determined that only a small amount of code modification is required this time, and the original version framework does not need to be changed. At this time, the update mode is set to incremental update, and only the difference is updated to reduce the update risk. On the contrary, if the change value is large and exceeds the threshold, it is necessary to carefully consider a major upgrade of full replacement.

[0088] S208: Extract the differential package from the repair resource.

[0089] Among them, the differential package refers to the independent part of the repair resource used for incremental updates, which usually exists in the form of a patch file and records the code, data, configuration, etc. that have changed from the old version to the new version.

[0090] Specifically, after determining to use incremental updates, the repair system will traverse and parse the repair resource files, looking for files of specific types marked as "difference" or "patch". These differential files contain all the content that needs to be modified from the current version to the target version, and are the core of incremental updates. The repair system extracts these differential files, packages them uniformly, and passes them to subsequent update programs. Compared with the full installation package, the differential package is small in size and updates quickly, which can minimize the impact of the upgrade on the vehicle.

[0091] In some embodiments, differential packages can be extracted in a variety of ways: Optionally, the repair system traverses the metadata of the resource file, finds the differential patch marked as "Patch", reads its corresponding file path, and classifies and packages all patch files; Optionally, the repair system compares the old and new version files in the resource, extracts the changed code segments through the binary difference algorithm, and dynamically generates a differential patch set for incremental updates. It is understandable that other methods can also be used to extract incremental update files, such as directly downloading cloud differential packages, customized patching, etc., which are not limited here.

[0092] S209: Obtain the incremental update start time set by the user.

[0093] Among them, the incremental update start time set by the user is usually a time point for software repair pre-selected by the car owner through the vehicle system human-machine interface or mobile phone APP, and the system will start the repair task at this moment.

[0094] Specifically, after extracting the differential package, the repair system checks whether the user-specified repair time has been preset. If so, it directly reads the time point. If there is no preset value, the repair system will actively request the user terminal to set the update time, and guide the user to select a convenient time point through human-computer interaction, such as when parking late at night. The user can also authorize the system to automatically select the time. After the repair system obtains the start time set by the user, it will start a scheduled task and automatically start the incremental update process at the specified time.

[0095] S210: At the start time, determine whether the current power level of the vehicle is higher than the safety update threshold. S211: Delay the start time and send a delayed update prompt to the user terminal.

[0096] The current power level of the vehicle refers to the percentage of remaining power in the vehicle battery at the start of the update, which represents the vehicle's power supply capacity. The safety update threshold is a pre-set lower limit of power based on the vehicle model, battery characteristics, update time, etc. When the power level is lower than this value, the repair will have abnormal risks. The delayed update prompt is a push message sent to the user terminal when the repair system detects insufficient power, informing the user that the update needs to be postponed due to insufficient power, so that the user can pay attention to changes in power level.

[0097] Specifically, when the preset update start time is reached, the repair system does not directly start the update program, but first obtains the current vehicle battery power data. The system compares the actual power with a preset safety threshold, such as 30%. If the power is higher than the threshold, the update can be started safely; if it is lower than the threshold, the system will automatically decide to postpone the update, modify the start time of the scheduled task, and postpone it for a random period of time, such as 30 minutes; or modify it to after charging to the specified power. At the same time, the system will send a delayed update reminder to the user's APP, informing the user that "the power is low, the update will be randomly postponed for 30 minutes, please keep the power supply normal."

[0098] S212: After the integrity check of the repair resource is successful, run the software installation update program based on the repair resource.

[0099] Referring to step S104, the repair system is updated based on the repair resources.

[0100] S213: After the repair resource is loaded, the repair feedback information and the vehicle self-check information are collected and sent to the user terminal, so that the user terminal uploads the repair feedback information and the vehicle self-check information to the remote server.

[0101] Referring to step S105 , the repair system uploads the repair feedback information and the vehicle self-check information to the remote server.

[0102] In some embodiments, the repair system records event logs and user operations during the software installation and update process, and extracts the repair start and end time, resource version number and upgrade results to generate repair feedback information; after the repair resources are loaded, the operating status data and fault diagnostic codes of each electronic control unit of the vehicle are collected to generate vehicle self-inspection information; the repair feedback information and vehicle self-inspection information are encrypted and digitally signed, and packaged to generate a repair result data packet; the repair result data packet is sent to the user terminal, so that the user terminal uploads the repair result data packet to the remote server.

[0103] Specifically, the event log refers to the log entries of key events recorded by the system during the repair process, such as start / finish time, key nodes, etc., which are convenient for review and analysis. User operations refer to interactive operations triggered by users during the repair process, such as pause, continue, and terminate, reflecting the user's participation. Information such as the start and end time of the repair, resource version number, and upgrade results can intuitively reflect the key data indicators of this repair. The vehicle electronic control unit (ECU) refers to each programmable controller on the vehicle, which manages core components such as the engine and gearbox. Its operating status, such as CPU occupancy and memory usage, can reflect the quality of vehicle software and hardware operation. The fault diagnostic code is a standardized fault code detected by the on-board self-diagnosis system. If there is still a fault code after the repair, it means that the problem has not been solved. The repair result data packet is a structured data file used to feedback the repair effect, including repair reports and self-test logs. Digital signatures and encryption processing can ensure the confidentiality and integrity of the repair results and prevent tampering.

[0104] Specifically, during the software update process, the repair system will record event logs in detail (such as key time points such as download start, completion of verification, file copying, installation completion, etc.), and will also record user participation operations (such as user cancellation, user pause, user confirmation, etc.), and extract core data such as specific start and end time, upgrade resource version, and whether the final upgrade is successful or not. This information is summarized into a repair report to reflect the entire upgrade process. After the upgrade is completed, the system immediately inquires about the operating status data of each ECU, including key parameters such as CPU, memory, storage, and temperature, to determine whether it is working normally. The system will also actively scan the vehicle body fault code to see if there is still a fault alarm after the upgrade. The repair report and the vehicle self-test data are included in the structured repair result record. To ensure that the data is not tampered with, the system uses an encryption algorithm (such as RSA) to encrypt the result record and generate a digital signature. Finally, an encrypted repair result data packet file is formed. The data packet is securely sent to the owner's terminal through the vehicle gateway, which is forwarded to the cloud to complete the software repair closed loop and can also be used for big data statistical analysis. The purpose of this link is to comprehensively collect repair effect data, evaluate the repair quality, and provide a data basis for optimizing the upgrade strategy.

[0105] In some embodiments, the collection and reporting of repair results can be achieved in a variety of ways: Optionally, during the entire upgrade process, the repair system calls a log module (such as log4j) to record key events, and uses a tracking SDK (such as GrowingIO) to record user operations. At the same time, it samples the upgrade progress, upgrade file version number and other status data at regular intervals (such as every 30 seconds), and finally extracts and summarizes the log and tracking data to form a result report; after the upgrade is completed, the system immediately calls the API interface of the vehicle gateway to collect the status data of all ECUs, reads the OBD interface to obtain the fault code, attaches it to the report to form a result record, and then calls The encryption and signature algorithm library encrypts the result record and calculates the signature to generate an encrypted data packet file; finally, the data packet is sent to the mobile phone APP through the HTTPS secure channel, and forwarded to the cloud log analysis system through the mobile phone; optionally, the repair system reports the upgrade progress and status to the cloud in real time at regular intervals (such as 1 minute), and actively reports events at key nodes (such as download completion, installation completion, etc.). After the upgrade is completed, all ECUs are polled again to perform vehicle self-tests, and the self-test results and upgrade reports are uniformly digitally signed and reported to the cloud directly through the vehicle's 4G network. Finally, the complete result record is synchronized to the mobile phone APP for archiving. It is understandable that other methods can also be used to collect and report repair results, such as local offline records, asynchronous batch uploads, etc., which are not limited here.

[0106] In the embodiments of the present application, a series of innovative solutions are adopted, such as automatically diagnosing software defects based on software operation logs and generating repair tasks, comprehensively judging multi-dimensional conditions to select the best repair time, adaptively selecting incremental or full upgrade modes according to version differences, actively verifying the integrity of cloud resources before repair, real-time tracking of the progress of high-priority repair tasks and urging users to repair nearby, and immediately collecting repair reports and vehicle self-inspection results after repair and securely uploading them to the cloud. Therefore, the problems existing in the existing remote repair of vehicle-mounted software, such as the low level of intelligent repair, blindly triggering repairs causing safety hazards and repair failures, extended transmission data redundant upgrade time, unexpected interruption of repairs due to lack of cloud resources, failure to repair high-risk defects in time, and difficulty in quantifying and tracking repair effects, are effectively solved. The automatic discovery and repair of vehicle-mounted software defects, conditional perception and intelligent scheduling of the repair process, differentiated intelligent distribution and precise repair, resource integrity verification of end-cloud intercommunication, rapid repair response of high-risk defects, and closed-loop repair tracking and quantitative evaluation of effects are realized.

[0107] The following describes the repair system in the embodiment of the present invention from the perspective of hardware processing. Figure 3 , which is a schematic diagram of a physical device structure of a repair system in an embodiment of the present application.

[0108] It should be noted that Figure 3The structure of the repair system shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0109] like Figure 3 As shown, the repair system includes a central processing unit (CPU) 301, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 302 or the program loaded from the storage part 308 to the random access memory (RAM) 303, such as executing the method described in the above embodiment. In the RAM 303, various programs and data required for system operation are also stored. The CPU 301, the ROM 302 and the RAM 303 are connected to each other through the bus 304. The input / output (I / O) interface 305 is also connected to the bus 304.

[0110] The following components are connected to the I / O interface 305: an input section 306 including an audio input device, a button switch, etc.; an output section 307 including a liquid crystal display (LCD) and an audio output device, an indicator light, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to the I / O interface 305 as needed. A removable medium 311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 310 as needed so that a computer program read therefrom is installed into the storage section 308 as needed.

[0111] In particular, according to an embodiment of the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present invention includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a computer program for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 309, and / or installed from a removable medium 311. When the computer program is executed by the central processing unit (CPU) 301, various functions defined in the present invention are performed.

[0112] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, apparatus, or device.

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present invention. Each box in the flowchart or block diagram may represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box may also occur in an order different from that marked in the accompanying drawings.

[0114] Specifically, the repair system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, the method for repairing automobile software defects provided in the above embodiment is implemented.

[0115] As another aspect, the present invention further provides a computer-readable storage medium, which may be included in the repair system described in the above embodiment; or may exist independently without being assembled into the repair system. The above storage medium carries one or more computer programs, and when the above one or more computer programs are executed by a processor of the repair system, the repair system implements the method for repairing automobile software defects provided in the above embodiment.

[0116] As described above, 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 scope of the technical solutions of the embodiments of the present application.

[0117] As used in the above embodiments, the term "when..." may be interpreted to mean "if..." or "after..." or "in response to determining..." or "in response to detecting...", depending on the context. Similarly, the phrases "upon determining..." or "if (the stated condition or event) is detected" may be interpreted to mean "if determining..." or "in response to determining..." or "upon detecting (the stated condition or event)" or "in response to detecting (the stated condition or event)", depending on the context.

[0118] Those skilled in the art can understand that to implement all or part of the processes in the above-mentioned embodiments, the processes can be completed by computer programs to instruct related hardware, and the programs can be stored in computer-readable storage media. When the programs are executed, they can include the processes of the above-mentioned method embodiments. The aforementioned storage media include: ROM or random access memory RAM, magnetic disk or optical disk and other media that can store program codes.

Claims

1. A method for repairing automobile software defects, characterized in that: Applied to a repair system, the method comprises: When it is determined based on the software operation log that the vehicle software is in a state to be repaired, a software repair task including software version information and a repair task ID is generated; Sending a software repair task to a user terminal so that the user terminal obtains repair resources from a remote server when the network environment meets a preset network condition; After receiving the resource acquisition completion information returned by the user terminal, acquiring the repair resource from the user terminal; After the integrity check of the repair resource is successful, running a software installation and update program based on the repair resource; After the repair resource is loaded, the repair feedback information and the vehicle self-check information are collected and sent to the user terminal, so that the user terminal uploads the repair feedback information and the vehicle self-check information to the remote server.

2. The method according to claim 1, characterized in that The sending of the software repair task to the user terminal so that the user terminal obtains the repair resource from the remote server when the network environment meets the preset network condition specifically includes: Send software repair tasks to user terminals; Acquiring vehicle status information and terminal location information and network status information returned by the user terminal; When it is determined based on the vehicle status information and the terminal positioning information that the vehicle has stopped running and there is a deviation between the user terminal position and the vehicle position, or the network status information meets the preset network conditions, a software repair prompt is sent to the user terminal, so that the user terminal runs the repair program corresponding to the software repair task, and the repair program is used to obtain repair resources from a remote server.

3. The method according to claim 1, characterized in that After the repair resource is loaded, collecting and sending the repair feedback information and the vehicle self-check information to the user terminal, so that the user terminal uploads the repair feedback information and the vehicle self-check information to the remote server, specifically includes: Record event logs and user operations during software installation and update, extract repair start and end time, resource version number and upgrade results, and generate repair feedback information; After the repair resource is loaded, the operating status data and fault diagnosis codes of each electronic control unit of the vehicle are collected to generate vehicle self-check information; Encrypting and digitally signing the repair feedback information and the vehicle self-check information, and packaging them to generate a repair result data packet; The repair result data packet is sent to the user terminal, so that the user terminal uploads the repair result data packet to the remote server.

4. The method according to claim 1, characterized in that: Before the step of sending the software repair task to the user terminal so that the user terminal obtains the repair resource from the remote server when the network environment meets the preset network conditions, the method further includes: Acquire resource integrity information returned by the remote server according to index information of the repair resource in the software repair task; When the resource integrity information is missing data, a resource abnormality prompt is sent to the user terminal, and the software repair task is suspended.

5. The method according to claim 4, characterized in that When the resource integrity information is missing data, after the step of sending a resource abnormality prompt to the user terminal and suspending the software repair task, the method further includes: Determine the repair priority and repair deadline of the software repair task, and obtain maintenance station information within a preset distance of the current location of the vehicle; If the repair priority is higher than a preset warning value and the repair period is lower than a preset remaining period, a repair warning message and the maintenance site information are pushed to the user terminal; The execution progress of the software repair task is detected. If the repair deadline expires and the status of the software repair task is still incomplete, an overdue reminder is sent to the user terminal, and the overdue record is uploaded to the remote server.

6. The method according to claim 1, characterized in that After receiving the resource acquisition completion information returned by the user terminal, after the step of acquiring the repair resource from the user terminal, the method further includes: Based on the software version information and the metadata of the repair resource, compare the current software version installed in the current vehicle to obtain a version change value; When the version change value is not greater than a preset version threshold, determining that the update mode of the current software version is incremental update; A differential package is extracted from the repair resource.

7. The method according to claim 6, characterized in that After the step of extracting the differential package from the repair resource, the method further includes: Obtaining the incremental update start time set by the user; At the start time, determining whether the current charge of the vehicle is above a safety update threshold; If not, the start time is delayed and a delayed update prompt is sent to the user terminal.

8. A repair system, characterized in that: The repair system comprises: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code comprises computer instructions, and the one or more processors call the computer instructions so that the repair system executes the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on a repair system, the repair system is caused to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that When the computer program product is run on a repair system, the repair system is caused to execute the method according to any one of claims 1 to 7.

Images