Method and system for monitoring over-the-air (OTA) upgrade problem of vehicle

Abstract

The invention provides a method and a system for monitoring an over-the-air (OTA) upgrade problem of a vehicle, and electronic equipment. The vehicle OTA upgrading problem monitoring method comprises the steps that S1, based on error codes of burying points monitored in an OTA server, first information associated with the monitored error codes is received from the OTA server, and the OTA server comprises the burying points of a plurality of error codes used for monitoring the vehicle OTA upgrading problem; and S2, according to the first information received from the OTA server, an OTA work order is generated, and the OTA work order at least comprises the identifier of the vehicle corresponding to the monitored error code and second information associated with the vehicle OTA upgrading problem corresponding to the monitored error code.

Description

Technical Field

[0001] This disclosure relates to the field of vehicles, and in particular to methods, systems, and electronic devices for monitoring over-the-air (OTA) upgrade issues in vehicles. Background Technology

[0002] In the automotive field, Over-The-Air (OTA) technology is used for vehicle hardware and software upgrades and vulnerability patching. However, for issues arising during OTA updates (such as upgrade failures), relying on maintenance personnel periodically checking the OTA server for problems and related information for further processing suffers from drawbacks such as slow OTA-related problem handling and untimely information synchronization. Furthermore, the information provided for handling vehicle OTA upgrade issues is often untimely, insufficient, or inaccurate. Summary of the Invention

[0003] In view of the above problems, this disclosure aims to provide a method, system, and electronic equipment for monitoring over-the-air (OTA) upgrade issues in vehicles.

[0004] The method for monitoring vehicle OTA upgrade issues according to the first aspect of this disclosure includes step S1, receiving first information associated with the monitored error codes from the OTA server based on error codes monitored in the OTA server, wherein the OTA server includes multiple error codes for monitoring vehicle OTA upgrade issues; and step S2, generating an OTA work order based on the first information received from the OTA server, wherein the OTA work order includes at least: an identifier of the vehicle corresponding to the monitored error code, and second information associated with the vehicle OTA upgrade issue corresponding to the monitored error code.

[0005] According to the vehicle OTA upgrade problem monitoring method according to some embodiments of the present disclosure, the second information may optionally include one or more of the following: the time when the error code was detected, the current version of the vehicle's OTA upgrade software, the vehicle model, and an OTA upgrade problem description corresponding to the detected error code.

[0006] According to some embodiments of the vehicle OTA upgrade problem monitoring method disclosed herein, the method may optionally further include: acquiring log data corresponding to the monitored error code; and adding the acquired log data to an OTA work order.

[0007] According to some embodiments of the vehicle OTA upgrade problem monitoring method disclosed herein, optionally, acquiring log data corresponding to the monitored error code further includes: determining log acquisition logic corresponding to the monitored error code based on the monitored error code; acquiring log data corresponding to the monitored error code based on the log acquisition logic; and adding the acquired log data to the OTA work order.

[0008] According to some embodiments of the vehicle OTA upgrade problem monitoring method disclosed herein, optionally, the determination of the log acquisition logic includes determining the time point for starting to acquire the packaged log data based on the ECU log packaging method corresponding to the monitored error code: if the ECU log packaging method is immediate packaging, then the acquisition of the packaged log data begins after a first time period following the detection of the error code; if the ECU log packaging method is fixed-size packaging, then the acquisition of the packaged log data begins after a second time period following the detection of the error code, wherein the second time period is longer than the first time period.

[0009] According to the vehicle OTA upgrade problem monitoring method of some embodiments of the present disclosure, optionally, the determination of the log acquisition logic includes determining the start time point of the acquired log data based on the occurrence stage of the vehicle OTA upgrade problem corresponding to the monitored error code: if the occurrence stage is the ECU flashing stage, then log data starting from the third time period before the time point when the error code is monitored is acquired; if the occurrence stage is not the ECU flashing stage, then log data starting from the fourth time period before the time point when the error code is monitored is acquired, wherein the third time period is longer than the fourth time period.

[0010] According to some embodiments of the vehicle OTA upgrade problem monitoring method disclosed herein, optionally, the method further includes: determining a problem model matching an OTA work order in an OTA upgrade problem library; adding information from the determined problem model to the OTA work order, wherein the OTA upgrade problem library includes multiple problem models corresponding to multiple vehicle OTA upgrade problems, each problem model includes an identifier of the corresponding vehicle OTA upgrade problem, one or more log keywords, and a recommended solution, different problem models are distinguished based on one or more log keywords, and wherein if the obtained log data includes one or more log keywords of one of the multiple problem models, then the OTA work order corresponding to the obtained log data matches that problem model.

[0011] According to some embodiments of the vehicle OTA upgrade problem monitoring method disclosed herein, the method may optionally further include: if no problem model corresponding to the OTA work order is matched in the OTA upgrade problem library, then a new problem model is created in the OTA upgrade problem library for the vehicle OTA upgrade problem corresponding to the OTA work order.

[0012] The second aspect of this disclosure, a vehicle over-the-air (OTA) upgrade problem monitoring system, includes: a receiving module configured to receive first information from an OTA server, wherein the OTA server includes multiple error codes for monitoring vehicle OTA upgrade problems, and the first information is associated with the error codes of the monitored error codes; and a generating module configured to generate an OTA work order based on the first information, wherein the OTA work order includes at least: an identifier of the vehicle corresponding to the monitored error code, and second information associated with the vehicle OTA upgrade problem corresponding to the monitored error code.

[0013] According to some embodiments of the vehicle over-the-air (OTA) upgrade problem monitoring system of this disclosure, the second information may optionally include one or more of the following: the time when the error code was detected, the OTA version of the vehicle, the vehicle model, and a description of the OTA upgrade problem corresponding to the detected error code.

[0014] According to some embodiments of the vehicle over-the-air (OTA) upgrade problem monitoring system disclosed herein, the system may optionally include an acquisition module, which is configured to acquire log data corresponding to the monitored error codes, and the generation module is further configured to add the acquired log data to an OTA work order.

[0015] According to some embodiments of the vehicle over-the-air (OTA) upgrade problem monitoring system of this disclosure, optionally, the acquisition module is further configured to: determine the log acquisition logic corresponding to the monitored error code based on the monitored error code; acquire the log data corresponding to the monitored error code based on the log acquisition logic; and the generation module is further configured to: add the log data acquired by the acquisition module to the OTA work order.

[0016] According to some embodiments of the vehicle over-the-air (OTA) update problem monitoring system of this disclosure, optionally, the acquisition module is further configured to: determine the time point for starting to acquire the packaged log data based on the ECU log packaging method corresponding to the monitored error code, including: if the ECU log packaging method is immediate packaging, then the acquisition of the packaged log data begins after a first time delay after the error code is monitored; if the ECU log packaging method is fixed-size packaging, then the acquisition of the packaged log data begins after a second time delay after the error code is monitored, wherein the second time period is longer than the first time period.

[0017] According to some embodiments of the vehicle over-the-air (OTA) upgrade problem monitoring system of this disclosure, optionally, the acquisition module is further configured to: determine the starting time point of the acquired log data based on the occurrence stage of the vehicle OTA upgrade problem corresponding to the monitored error code, including: if the occurrence stage is the ECU flashing stage, then acquire the log data starting from the third time period before the time point when the error code is monitored; if the occurrence stage is not the ECU flashing stage, then acquire the log data starting from the fourth time period before the time point when the error code is monitored, wherein the third time period is longer than the fourth time period.

[0018] According to some embodiments of the vehicle over-the-air (OTA) upgrade problem monitoring system disclosed herein, optionally, the system further includes an OTA upgrade problem library. The OTA upgrade problem library includes multiple problem models corresponding to multiple vehicle OTA upgrade problems. Each problem model includes an identifier of the corresponding vehicle OTA upgrade problem, one or more log keywords, and a recommended solution. Different problem models are distinguished based on one or more log keywords. The generation module is further configured to: determine the problem model matching the OTA work order in the OTA upgrade problem library; add the information in the determined problem model to the OTA work order. If the obtained log data includes one or more log keywords of one of the multiple problem models, then the OTA work order corresponding to the obtained log data matches that problem model.

[0019] According to some embodiments of the vehicle over-the-air (OTA) upgrade problem monitoring system of this disclosure, optionally, the generation module is further configured to: if no problem model corresponding to the OTA work order is matched in the OTA upgrade problem library, then create a new problem model in the OTA upgrade problem library for the vehicle OTA upgrade problem corresponding to the OTA work order.

[0020] The electronic device of the third aspect of this disclosure includes a processor and a memory, the memory storing instructions which, when executed by the processor, implement the vehicle OTA upgrade problem monitoring method according to any of the foregoing.

[0021] The OTA system of the fourth aspect of this disclosure includes: an OTA server that interacts with the vehicle regarding OTA tasks and includes embedded points for monitoring multiple error codes for OTA upgrade issues of the vehicle; and an OTA upgrade issue monitoring system as described in any of the foregoing embodiments. Attached Figure Description

[0022] Figure 1 A flowchart of a vehicle over-the-air (OTA) upgrade problem monitoring method 100 according to some embodiments is shown.

[0023] Figure 2A flowchart of a vehicle over-the-air (OTA) upgrade problem monitoring method 200 according to some embodiments is shown.

[0024] Figure 3 A schematic diagram of the modules of an OTA system 300 according to some embodiments is shown. Detailed Implementation

[0025] The following description describes some of the various embodiments of this disclosure, intended to provide a basic understanding of the disclosure. It is not intended to identify key or decisive elements of the disclosure or to limit the scope of protection sought.

[0026] For purposes of brevity and illustrativeness, the principles of this disclosure are described herein primarily with reference to exemplary embodiments thereof. However, those skilled in the art will readily recognize that the same principles are equivalently applicable to all types of vehicle over-the-air (OTA) update problem monitoring methods and systems, electronic devices, and in which these same principles can be implemented, and that any such variations do not depart from the true spirit and scope of this patent application.

[0027] Furthermore, reference is made in the accompanying drawings, which illustrate specific exemplary embodiments. Electrical, mechanical, logical, and structural changes may be made to these embodiments without departing from the spirit and scope of this disclosure. Moreover, while features of this disclosure are disclosed in combination with only one of several embodiments, such features may be combined with one or more other features of other embodiments if desired and / or advantageous for any given or identifiable function. Therefore, the following description should not be considered limiting in any sense, and the scope of this disclosure is defined by the appended claims and their equivalents.

[0028] Terms such as “possessing” and “comprising” indicate that, in addition to having the units (modules) and steps that are directly and explicitly stated in the specification and claims, the technical solutions of this disclosure do not exclude the presence of other units (modules) and steps that are not directly or explicitly stated.

[0029] Figure 1 A flowchart illustrating a method 100 for monitoring vehicle over-the-air (OTA) upgrade issues according to some embodiments is shown. The method 100 may include the following steps: In step S1, based on the error codes monitored in the OTA server, first information corresponding to the monitored error codes is received from the OTA server, wherein the OTA server includes multiple error codes for monitoring vehicle OTA upgrade issues.

[0030] In step S2, an OTA work order is generated based on the information received from the OTA server. The OTA work order includes at least: the identifier of the vehicle corresponding to the monitored error code, and second information related to the OTA upgrade problem of the vehicle corresponding to the monitored error code.

[0031] Over-the-air (OTA) software upgrades in some vehicle electronic control units (ECUs) involve interaction between the vehicle and the OTA server regarding OTA tasks such as upgrades and vulnerability fixes. During this OTA upgrade process, various problems or malfunctions may occur, such as software update data package download errors, download interruptions, version incompatibility during installation, insufficient vehicle storage space, weak or interrupted network signals, etc. The OTA upgrade software (including both the software installed on the vehicle and the OTA server) continuously monitors itself throughout the update process, covering all aspects of software download, installation, and interaction with hardware. For these problems arising during the OTA upgrade process, the OTA upgrade software generates an error code (errcode, or error string errstring; in this document, error codes and error strings are used interchangeably) indicating the problem (e.g., problem type and characteristics).

[0032] In some embodiments, for known OTA upgrade issues and their corresponding error codes, tracking points can be placed on the OTA server to monitor these error codes. In this document, "tracking points" refers to inserting code logic at specific locations in a software system to collect specific data. For example, in the OTA upgrade software of an OTA server, tracking logic can be inserted at key code locations (or paths, trigger points) where the OTA server processes vehicle-side reported messages, targeting known or relevant OTA upgrade issues and their corresponding error codes. When the OTA server processes vehicle-side messages and reaches these tracking points, if the message contains a preset specific error code, the tracking logic will be triggered, thereby performing operations such as data collection and reporting. In some examples, tracking points can be placed during the OTA upgrade process of the vehicle's software to be updated, at key steps such as the OTA server processing download requests, verifying software update packages, and flashing ECUs (Electronic Control Units). When the OTA server processes vehicle-side messages and reaches these tracking point locations, corresponding operations will be triggered, such as reporting the error code for that tracking point. It is understood that this article does not restrict the method of "tracking," but any tracking method that can achieve monitoring and information reporting of error codes for known OTA upgrade issues is acceptable.

[0033] When the OTA server detects an error code at a monitored point, it can package the first piece of information related to that error code. This first piece of information may include, for example, the error code itself, vehicle-related information (such as model information, Vehicle Identification Number (VIN), production batch, owner information, etc.), the current software version information of the software to be updated, software update history, etc. Then, an OTA work order can be generated based on this information. The OTA work order at least includes the identifier of the specific vehicle experiencing the OTA upgrade problem and information associated with that problem (such as all or part of the aforementioned first piece of information), making it easier for maintenance personnel to locate the specific vehicle and review the details of the OTA upgrade problem. In this way, automatic monitoring of error codes and generation of OTA work orders can be achieved by monitoring the OTA server. OTA work orders can be pushed to maintenance personnel in various ways, thereby achieving automatic monitoring and efficient handling of OTA upgrade problems. Simultaneously, the automatic reporting of information related to error codes or OTA upgrade problems to the OTA server reduces the information retrieval workload for maintenance personnel.

[0034] In some embodiments, the OTA work order includes at least identification information about the vehicle and information about the OTA upgrade problem, such as the Vehicle Identification Number (VIN) and an error code indicating the OTA upgrade problem (e.g., problem type and characteristics), to provide the maintenance personnel responsible for the OTA work order with information on handling the OTA upgrade problem (i.e., the OTA upgrade problem caused by the specific vehicle indicated by the error code during the OTA upgrade process). In other embodiments, the OTA work order may further include one or more of the following: the time the error code was detected, the current version of the vehicle's OTA upgrade software, the vehicle model, and a problem description corresponding to the detected error code. This provides maintenance personnel with more detailed information about the vehicle's OTA upgrade problem. In still other embodiments, when the OTA server detects an error code from a data entry point, log data related to the OTA upgrade problem can be acquired and packaged. This log data can be added to the OTA work order as part of the OTA work order, providing maintenance personnel with this log data as a reference regarding the OTA upgrade problem indicated by the error code. The log data is generated and packaged by the vehicle ECU (e.g., the relevant ECU) performing the OTA upgrade process.

[0035] In some embodiments, the aforementioned OTA work order can be generated via an OTA upgrade issue monitoring system independent of the OTA server. This OTA upgrade issue monitoring system can be configured to have a user-facing interface (e.g., for maintenance personnel) and communicate with the OTA server. When the OTA server detects an error code related to a data entry point, it can package the information associated with that error code (first information) and transmit it to the OTA upgrade issue monitoring system. The OTA upgrade issue monitoring system processes this packaged information to generate an OTA work order. For example, it parses the packaged information and extracts fields such as vehicle VIN, data entry trigger time, vehicle model, problem description, and vehicle version from the first information as content displayed to the user in the OTA work order. The OTA upgrade issue monitoring system can be further configured to set issue levels for OTA work orders. For example, in some examples, notifications can be sent based on the severity or urgency of the OTA upgrade issue indicated by the error code. OTA work orders with a severity or urgency level of "severe" or "urgent" can be delivered to users through more frequent notifications and more diverse transmission mechanisms, such as email, automated voice calls, SMS, internal applications, or repeated notifications at regular intervals. Furthermore, users can manage the information and processing status of multiple OTA work orders within the OTA upgrade issue monitoring system, such as the work order's ongoing or completed status, work order creation and deletion, and matching of work orders with issue models (see below), etc.

[0036] In some embodiments, the composition of error codes is configurable. Therefore, various OTA upgrade service providers (such as automakers, OTA upgrade software service providers, etc.) can configure or modify the form of error codes as needed. For example, error codes can be used to indicate various aspects of information regarding OTA upgrade issues. For instance, error codes may include indications of the type of error generated during the OTA upgrade, such as whether the error is a communication error (e.g., error codes starting with "COM"), a software error (e.g., error codes starting with "SW"), or a hardware error (e.g., error codes starting with "HW"). Error codes may also include indications of the location of the error during the OTA upgrade, such as whether the error occurred at the system level (e.g., involving "ECU") or a specific module (e.g., "ADAS" indicating an advanced driver assistance system). Error codes may also include indications of the severity of the error during the OTA upgrade, such as using specific identifiers or numerical ranges to indicate urgency (e.g., error codes starting with "E" indicating an urgent error, and error codes starting with "W" indicating an error requiring only a warning) and the degree of impact on vehicle functionality (e.g., fields indicating complete or partial functional failure, fields indicating whether the vehicle can continue to be driven or cannot). Error codes may also include the time when the OTA upgrade error occurred.

[0037] In some embodiments, method 100 may further include: determining log acquisition logic corresponding to each monitored error code based on the different monitored error codes; acquiring log data corresponding to each monitored error code based on the log acquisition logic; and adding the acquired log data to an OTA work order. Different error codes may indicate different vehicle OTA upgrade problems and the ECUs of the vehicle that have malfunctioned. Different vehicle OTA upgrade problems may require analysis of log data from different ECUs of the vehicle and log data from different time ranges. For example, for an error code indicating a network connection-related error, it may be necessary to acquire ECU information related to the network communication module and its log data regarding the vehicle's network connection during the OTA upgrade process, including the time when the vehicle attempted to connect to the network, changes in network signal strength, and specific error messages indicating network connection failure. For an error code indicating a software update package installation failure, it may be necessary to acquire ECU information related to the software update package installation program and its log data regarding the execution of the software update package installation, such as the file decompression process and the results of file write operations. The determination of the log acquisition logic may be based, for example, on pre-defined rules and experience summaries. For example, automakers or technical teams can use their past experience in handling OTA upgrade issues to define a suitable log acquisition logic for each possible error code, including the type of log data to be acquired, one or more ECUs for which information needs to be acquired, the time range, and the start time of the acquisition operation.

[0038] Once the log acquisition logic is determined, log data corresponding to the monitored error codes can be retrieved according to this logic. As mentioned earlier, log data can be extracted from the vehicle's ECU, sensors, and related software modules (such as the aforementioned ADAS). Specifically, this may include reading the operation logs recorded by the ECU through communication methods such as following the CAN protocol standard, or extracting vehicle system event logs for a specific time period from the vehicle's operating system log files. During the log data acquisition process, log data can be filtered and extracted according to the time range and log type determined in the log acquisition logic, thus obtaining necessary data while avoiding the acquisition of excessive irrelevant data.

[0039] After obtaining the log data, this data can be added to the previously generated OTA work orders. Maintenance personnel can then analyze this log data when processing OTA work orders. For example, when processing an OTA work order regarding a failed vehicle OTA upgrade, in addition to checking the error code on the OTA work order, maintenance personnel can also understand the download progress of the software package, the execution status of the installation steps, and the status changes of each ECU by reviewing the log data added to the work order. This helps in locating OTA upgrade problems and understanding the details.

[0040] Through the above steps, this disclosure can, during the monitoring of vehicle OTA upgrade issues, obtain relevant log data based on specific error codes and add it to the work order according to specific log acquisition logic, thereby improving the completeness of OTA work orders and facilitating maintenance personnel to diagnose or trace OTA upgrade issues.

[0041] In some embodiments, the above-mentioned determination of the log acquisition logic may further include: determining the time point for starting to acquire the packaged log data based on the log packaging method of the ECU corresponding to the monitored error code (i.e., the ECU corresponding to the occurrence of the OTA upgrade problem). Specifically, if the ECU log packaging method is immediate packaging, then the acquisition of the packaged log data begins after a first time delay following the monitoring of the error code. In this approach, when an OTA upgrade problem occurs, the log data generated by the ECU is immediately packaged and stored. Considering the potential delay in ECU processing packaging and external data transmission, after monitoring the error code, a first time delay is required to trigger the log acquisition request (e.g., via an OTA server) and begin acquiring the log data. Thus, when the log data acquisition begins, the relevant log data for the vehicle OTA upgrade problem corresponding to the error code has already been packaged and can be completely acquired. For example, the first time period can be set to a value greater than 10 seconds, such as 60 seconds. That is, after monitoring the error code, a 60-second delay is made, during which more complete and reliable log data can be acquired. In other embodiments, if the ECU logs are packaged to a fixed size, the acquisition of the packaged log data begins after a second time delay following the detection of an error code. In this method, the ECU packages the log data only after it has accumulated to a certain size. Since the packaging time for log data in this method is relatively variable and may involve some delay, to ensure that more complete log data related to the vehicle OTA upgrade issue corresponding to the error code is obtained, the acquisition of log data needs to begin after a second time delay following the detection of the error code. This second time delay can be longer than the first time delay. For example, the second time delay can be set to 300 seconds. Compared to the immediate packaging method, the longer delay ensures that the relevant log data is fully packaged during the fixed-size packaging process. Therefore, by determining the start time for acquiring log data based on different ECU log packaging methods, the completeness of the acquired log data can be improved, while avoiding the packaging of excessive log data.

[0042] In some embodiments, the above-described log acquisition logic may further include: determining the starting time point for packaging log data based on the stage of the OTA upgrade when the vehicle OTA upgrade problem corresponding to the monitored error code occurs. Specifically, if the OTA upgrade problem occurs during the ECU flashing stage, the third time period before the time the error code is monitored is the starting time point for packaging log data. Compared to the non-ECU flashing stage, the ECU flashing stage involves more data writing and configuration changes. By setting a third time period to obtain log data from the time the error code is monitored (i.e., when the OTA upgrade problem occurs), a larger time range of log data involving the steps of the OTA operation during the ECU flashing stage and the potential for problems can be obtained (because log data within the third time period before the error code is monitored is also obtained), thus facilitating a more complete log data regarding the OTA upgrade problem. The third time period can be set to a value greater than 100 seconds, such as 7300 seconds. If the OTA upgrade problem occurs outside the ECU flashing stage, the fourth time period before the time the error code is monitored is the starting time point for packaging log data. The non-ECU flashing stage may include, for example, downloading the update package for the software to be updated, initializing the vehicle system, etc. These stages involve less data interaction and have a smaller time span compared to the flashing stage. Therefore, log data acquisition begins four time periods before the error code is detected (i.e., the starting time for packaging log data is the fourth time period before the error code is detected), and this fourth time period is shorter than the third time period. For example, for a third time period of 7300 seconds, the fourth time period can be set to 3600 seconds.

[0043] By determining the starting point for acquiring log data based on the stage of the OTA upgrade when the vehicle OTA upgrade problem occurs, more complete and efficient acquisition of log data can be achieved. That is, by setting different starting points for acquiring log data for different stages of the OTA upgrade problem, more complete log data related to the problem can be obtained, and interference from irrelevant log information can be reduced. This allows maintenance personnel to more quickly locate and analyze the OTA upgrade problem in the log data of the OTA work order.

[0044] In some embodiments, method 100 may further include generating an OTA upgrade issue library based on generated and analyzed vehicle OTA upgrade issues. This OTA upgrade issue library includes multiple issue models corresponding to various vehicle OTA upgrade issues. Each issue model includes an identifier for a corresponding generated and analyzed vehicle OTA upgrade issue, one or more log keywords, and a recommended solution. Each issue model uniquely corresponds to one or more log keywords; that is, different issue models can be determined based on their included log keywords. The vehicle OTA upgrade issue identifier is used to identify each OTA upgrade issue in the OTA upgrade issue library, facilitating searching and management within the library. For example, an issue ticket number can be used to distinguish and number each OTA upgrade issue. The log keywords are extracted from log data related to the corresponding generated and analyzed OTA upgrade issues. Since the OTA upgrade issue library contains known OTA upgrade issues and their solutions, and these known OTA upgrade issues also have corresponding log data, by determining whether the log data corresponding to a newly generated OTA upgrade issue contains these log keywords, it can be determined whether the log data is related to the issue model uniquely corresponding to that log keyword. Recommended solutions are pre-stored solution description documents for this problem model. Operations personnel can use the recommended solutions mentioned in these documents to resolve OTA upgrade issues. In other words, log data matching one or more of these log keywords corresponds to a specific problem model.

[0045] Based on the OTA upgrade issue database, the log data obtained from the OTA work order can be matched with multiple issue models in the database to determine the issue model corresponding to the vehicle OTA upgrade problem. Matching involves determining whether the log data obtained from the OTA work order contains one or more log keywords uniquely corresponding to a specific issue model in the database. For example, if the obtained log data contains log keywords such as "software version mismatch" or "upgrade failed" uniquely corresponding to a specific issue model, then the obtained log data matches that issue model. Once the issue model corresponding to the identified vehicle OTA upgrade problem is determined, the information from the determined issue model is added to the OTA work order. This information includes the issue identifier (e.g., issue ticket number), recommended solutions, etc. In this way, when processing OTA work orders, maintenance personnel can directly obtain more information and solutions from the matched issue model without needing additional analysis and searching. It can be understood that each issue model in the OTA upgrade issue database can include more information to facilitate the analysis of the OTA upgrade problem by maintenance personnel, such as a description of the problem cause and whether the vehicle is drivable, and is not limited to issue identifiers, log keywords, and recommended solutions.

[0046] Therefore, log keywords can be used to accurately identify the corresponding problem model, thereby obtaining relevant information and recommended solutions for the OTA upgrade issue. For example, if an OTA upgrade fails due to software version incompatibility, the corresponding log keywords might include "software version mismatch" or "upgrade failed." When these keywords are matched in the acquired log data, it can be determined that the acquired log data corresponds to the problem model, and recommended solutions for the software version incompatibility problem can be obtained. In this way, the problem model can be quickly located and recommended solutions obtained by checking whether log keywords are covered by the acquired log data, avoiding repeated analysis and troubleshooting processes and shortening the time spent by operations and maintenance personnel in resolving problems. Furthermore, the OTA upgrade problem database centrally manages various problems and their corresponding recommended solutions, facilitating knowledge accumulation and sharing among operations and maintenance personnel.

[0047] Furthermore, due to the limited length of error codes and the limited information they indicate about OTA upgrade issues, relying solely on the error code may not be sufficient to identify the specific problem occurring during the upgrade process. Therefore, identifying different problem models based on one or more log keywords can further diagnose the specific OTA upgrade issue that triggered the monitored error code. For example, if the same error code (e.g., a communication error starting with "COM") is monitored at two different time points, T1 and T2, this error code only indicates that a communication error occurred at both time points, but it cannot indicate which specific communication error occurred (e.g., the specific communication module or communication level). Moreover, the OTA upgrade problem database may contain multiple problem models for communication errors. Therefore, obtaining the log data corresponding to the error codes monitored at these two time points separately, and determining which problem model's log keyword matches the log data, helps to match a more accurate problem model for the vehicle's OTA upgrade issue.

[0048] Correspondingly, in some other embodiments, method 100 may further include: if no problem model corresponding to the determined vehicle OTA upgrade problem is matched in the problem database, a new problem model for the vehicle OTA upgrade problem is created in the problem database. The specific process includes creating a new problem identifier for the problem, extracting log keywords from the acquired log data, and populating the recommended solution for the problem. The solution can be temporarily populated as a solution to a problem model similar to the problem, such as a problem model that matches a large number of log keywords or nearly matches all log keywords. For example, if the log data corresponding to the monitored error code does not cover all log keywords of a certain problem model A, but covers most of them (e.g., covering 4 out of 5 log keywords), the recommended solution for problem model A can be populated in the newly created problem model for that problem. Furthermore, the solution can also be populated by maintenance personnel later. For example, for a newly emerging OTA upgrade failure caused by a vehicle sensor malfunction, a new problem identifier, such as "S005," is assigned. Information related to the vehicle sensor malfunction is extracted from the log data as log keywords, such as "abnormal sensor data" or "upgrade interrupted." Then, maintenance personnel summarize recommended solutions based on the specific circumstances and experience of the problem, such as "check sensor connections or replace the faulty sensor." This information regarding newly emerging OTA upgrade failures is integrated into a new problem model and added to the OTA upgrade problem database. In this way, the OTA upgrade problem database can be continuously improved during the vehicle OTA process, and newly emerging problems can be promptly included in the database management, improving the ability to handle various vehicle OTA upgrade problems.

[0049] Figure 2 A flowchart illustrating a vehicle over-the-air (OTA) update problem monitoring method 200 according to some embodiments is shown. In step 210, an error code from a data entry point is detected on the OTA server, and two requests are generated accordingly.

[0050] Request 1 corresponds to Figure 2 The left portion following 210 instructs the OTA server to acquire (220) the first information associated with the monitored error code. This acquisition can be divided into three parts: acquiring vehicle-related information (e.g., vehicle model information, Vehicle Identification Number (VIN), production batch, owner information, etc.) in step 221; acquiring the vehicle's current software version information (e.g., the version of the OTA upgrade software) in step 222; and acquiring information related to the error code (e.g., the error code itself) in step 223. All acquired information can then be transmitted to a problem monitoring platform (e.g., the vehicle OTA upgrade problem monitoring system described below), and an OTA work order is created in step 240 based on the acquired information.

[0051] In another alternative embodiment, request 2 may also be generated in step 210, and request 2 corresponds to Figure 2 The right part after 210 indicates a request to retrieve log data associated with the monitored error code. In step 230, a request to retrieve log data is triggered, and in subsequent steps 231-236, the log retrieval logic is determined based on the monitored error code, and the data is retrieved according to the log retrieval logic. Specifically, in step 231, because certain fields of the error code itself can indicate the ECU log packaging method, the vehicle OTA upgrade problem monitoring system can determine the ECU log packaging method based on the monitored error code. If it is packaged according to a fixed size, it proceeds to 232; if it is packaged immediately, it proceeds to 233. In step 232, log data retrieval begins after a first time interval (e.g., 300 seconds) following the time point when the error code is detected. In step 233, log data retrieval begins after a second time interval (e.g., 60 seconds) following the time point when the error code is detected, which is shorter than the first time interval. Then, in step 234, since certain fields of the error code itself can indicate the stage at which the OTA upgrade problem occurred, the stage at which the vehicle OTA upgrade problem occurred corresponding to the monitored error code can be determined. If the stage is not the ECU flashing stage, proceed to step 235; if the stage is the ECU flashing stage, proceed to step 236. Specifically, in step 235, log data starting from the fourth time period (e.g., 3600 seconds) before the time the error code was detected is packaged; in step 236, log data starting from the third time period (e.g., 7200 seconds) longer than the fourth time period before the time the error code was detected is packaged. Finally, optionally, in step 237, the OTA server can determine whether the log data was successfully acquired, for example, whether the OTA server acquired the log data within a predetermined time (e.g., 6 hours). If step 237 determines that the log data acquisition failed, it can return to step 230 to reacquire it. Optionally, if acquisition always fails, it can repeatedly return to step 230 to reacquire it, for example, it can be set to return to step 230 every hour. After successfully obtaining the log data, the log data can be synchronized to the OTA work order in step 240.

[0052] Next, in step 250, notifications can be sent based on the severity or urgency of the OTA upgrade issue indicated by the error code. Specifically, as described above, OTA tickets for severe or urgent OTA upgrade issues will be delivered to users through more frequent notifications and more diverse transmission mechanisms. For example, notifications can be sent via email, automated voice calls, SMS, internal applications, or repeated notifications at regular intervals. In step 260, a problem model is matched to the created OTA ticket. Specifically, this can be done, for example, by matching the log data obtained in steps 230-237 in the OTA ticket against a problem database based on generated and analyzed vehicle OTA upgrade issues (e.g., matching using one or more log keywords as described above). In step 270, it is determined whether a problem model is matched. If no problem model is matched (matching fails), the process proceeds to step 271 to create a new problem model based on the error code, OTA ticket, and log data for this monitoring, and initiates a rematch (returning to step 260). If a problem model is matched in step 270 (match successful), proceed to step 280 to add the problem model information to the OTA work order created in step 240. The problem model matching process can be understood as described above and will not be repeated here.

[0053] Figure 3 A schematic diagram of a vehicle OTA system 300 according to some embodiments is shown. The OTA system 300 includes an OTA server 310 and a vehicle OTA upgrade problem monitoring system 320. The problem monitoring system 320 includes a receiving module 322 and a generating module 324. The receiving module 322 is configured to receive first information from the OTA server 310, which may include multiple error codes for monitoring vehicle OTA upgrade problems. The first information is associated with the error codes of the monitored error codes. The generating module 324 is configured to generate an OTA work order based on the first information. The OTA work order includes at least: an identifier of the vehicle corresponding to the monitored error code, and second information associated with the vehicle OTA upgrade problem corresponding to the monitored error code.

[0054] The OTA system 300 will continuously monitor itself throughout the update process. For some known OTA upgrade issues and their corresponding error codes, instrumentation points can be placed on the OTA server 310 to monitor the error codes of these known OTA upgrade issues on the OTA server 310.

[0055] When the OTA server 310 detects an error code at a specific data point, it can package the first piece of information related to that error code. This first piece of information may include, for example, the error code itself, vehicle-related information (such as vehicle model information, Vehicle Identification Number (VIN), production batch, owner information, etc.), the current software version information of the OTA upgrade software, software update history, etc. Then, the generation module 324 of the problem monitoring system 320 can generate an OTA work order based on this information. The OTA work order includes at least the identifier of the specific vehicle experiencing the OTA upgrade problem (such as the vehicle ID) and information associated with the OTA upgrade problem (such as all or part of the aforementioned first piece of information), facilitating maintenance personnel to locate the specific vehicle and review the details of the OTA upgrade problem based on the work order. In this way, automatic monitoring of error codes and generation of OTA work orders can be achieved by tracking data points on the OTA server. OTA work orders can be pushed to maintenance personnel in various ways, thereby achieving automatic monitoring and efficient handling of OTA upgrade problems. Simultaneously, the automatic reporting of information related to error codes or OTA upgrade problems to the OTA server reduces the information acquisition workload for maintenance personnel.

[0056] In some embodiments, the OTA work order includes at least identification information about the vehicle and information about the OTA upgrade problem, such as the Vehicle Identification Number (VIN) and an error code indicating the OTA upgrade problem (e.g., problem type and characteristics), to provide the maintenance personnel responsible for the OTA work order with information on handling the OTA upgrade problem (i.e., the OTA upgrade problem caused by the specific vehicle indicated by the error code during the OTA upgrade process). In other embodiments, the OTA work order may further include one or more of the following: the time when the error code was detected, the current version of the vehicle's OTA upgrade software, the vehicle model, and a problem description corresponding to the detected error code. This provides maintenance personnel with more detailed information about the vehicle's OTA upgrade problem. In still other embodiments, the problem monitoring system 320 may further include an acquisition module 326. After the OTA server 310 detects the error code at the embedded point and transmits the first information to the problem monitoring system 320, the problem monitoring system 320 can interact with the OTA server 310 via its acquisition module 326 based on the first information (e.g., the error code reported by the OTA server 310) to acquire the log data packaged by the OTA server 310. This log data can be added to an OTA work order via generation module 324 as part of the OTA work order, providing maintenance personnel with this log data as a reference for the OTA upgrade issues indicated by the error code. The log data is generated and packaged by one or more vehicle ECUs involved in the vehicle's OTA upgrade process.

[0057] Furthermore, the OTA upgrade issue monitoring system 320 can be configured to have a user-facing interface (e.g., for maintenance personnel) and communicate with the OTA server 310. In some examples, when the OTA server 310 detects an error code at a data entry point, it can package the information related to that error code (first information) and transmit it to the OTA upgrade issue monitoring system 320. The OTA upgrade issue monitoring system 320 processes this packaged information to generate an OTA work order. For example, it parses the packaged information and extracts fields such as vehicle VIN, trigger time, vehicle model, problem description, and vehicle version as content to be displayed to the user in the OTA work order. The OTA upgrade issue monitoring system 320 can be further configured to set issue levels for OTA work orders. For example, in some examples, notifications can be sent based on the severity or urgency of the OTA upgrade issue indicated by the error code. OTA work orders with a severity or urgency level of "severe" or "urgent" can be delivered to users through more frequent notifications and more diverse transmission mechanisms, such as email, automated voice calls, SMS, internal applications, or repeated notifications at regular intervals. Furthermore, users can manage the information and processing status of multiple OTA work orders within the OTA upgrade issue monitoring system 320. This includes viewing the in-progress or completed status of work orders through the system's interface, and performing operations such as creating and deleting work orders, and matching work orders with issue models.

[0058] In some embodiments, the acquisition module 326 may be further configured to: determine the log acquisition logic corresponding to each monitored error code based on the different monitored error codes; acquire the log data corresponding to each monitored error code based on the log acquisition logic; and the generation module may be further configured to: add the log data acquired by the acquisition module to the OTA work order. Different error codes may indicate different vehicle OTA upgrade problems and the vehicle system level (e.g., different ECUs) at which the error occurred. Different vehicle OTA upgrade problems may require analysis of log data from different system levels (e.g., different ECUs) and different time ranges. For example, for an error code indicating a network connection-related error, it may be necessary to acquire the ECU information related to the network communication module and its log data regarding the vehicle's network connection during the OTA upgrade process, including the time when the vehicle attempted to connect to the network, changes in network signal strength, and specific error information about network connection failure. For an error code indicating a software update package installation failure, it may be necessary to acquire the ECU information related to the software update package installation program and its log data regarding the execution of the software update package installation, such as the file decompression process and the results of file writing operations. The determination of the log acquisition logic may be based, for example, on pre-defined rules and experience summaries. For example, automakers or technology teams can use their past experience in handling OTA upgrade issues to define a suitable log acquisition logic for each possible error code, including the type of log data to be acquired, the system level range (e.g., ECU), the time range, and the start time of the acquisition operation.

[0059] After determining the log acquisition logic, the acquisition module 326 of the problem monitoring system 320 can acquire log data corresponding to the monitored error codes according to this logic. As mentioned earlier, log data is extracted from various ECUs, sensors, and related software modules (such as the aforementioned ADAS) of the vehicle. For example, it can read the operation logs recorded by the ECU through communication methods such as CAN bus, or extract the vehicle system event logs within a specific time period from the log files of the vehicle operating system. During the process of acquiring log data, the acquisition module 326 can filter and extract log data according to the time range and log type determined in the log acquisition logic, thus acquiring necessary data while avoiding acquiring too much irrelevant data.

[0060] After acquiring the log data, the generation module 324 can add this data to the previously generated OTA work order. Maintenance personnel can then analyze this log data when processing OTA work orders. For example, when processing an OTA work order regarding a failed vehicle OTA upgrade, in addition to checking the error code on the OTA work order, maintenance personnel can also understand the download progress of the software package, the execution status of the installation steps, and the status changes of various ECUs by reviewing the log data added to the work order. This helps in locating OTA upgrade problems and understanding the details.

[0061] Therefore, during the monitoring of vehicle OTA upgrade issues, this problem monitoring system 320 can obtain relevant log data based on specific error codes and add it to the work order according to specific log acquisition logic, thereby improving the completeness of OTA work orders and facilitating maintenance personnel to diagnose or trace OTA upgrade issues.

[0062] In some embodiments, the acquisition module 326 can be further configured to: determine the starting point for acquiring the packaged log data based on the log packaging method of the ECU corresponding to the monitored error code (i.e., the ECU corresponding to the occurrence of the OTA upgrade problem), including: if the ECU log packaging method is immediate packaging, then after a first time period following the monitoring of the error code, the acquisition of the packaged log data will begin. In this method, when an OTA upgrade problem occurs, the ECU immediately packages and stores the log data generated by that ECU. Considering that there may be a certain delay in the ECU's processing of packaging and external data transmission, after monitoring the error code, the acquisition module 326 needs to delay for a first time period before triggering the log acquisition request and starting to acquire the log data. Thus, when the acquisition of log data begins, the relevant log data of the vehicle OTA upgrade problem corresponding to the error code has been packaged and can be completely acquired. For example, the first time period can be set to a value greater than 10 seconds, such as 60 seconds, that is, after monitoring the error code, wait 60 seconds, at which time more complete and reliable log data can be acquired. In other embodiments, if the ECU logs are packaged in a fixed-size manner, the acquisition of the packaged log data begins after a second time period following the detection of an error code, where the second time period is longer than the first time period. In this method, the ECU packages the log data only after it has accumulated to a certain size. Since the packaging time for log data in this method is relatively variable and may involve some delay, to ensure that more complete log data related to the vehicle OTA upgrade issue corresponding to the error code is obtained, the acquisition module 326 needs to delay the acquisition of log data for a second time period after detecting the error code, and this second time period can be longer than the first time period. For example, the second time period can be set to 300 seconds. Compared to the immediate packaging method, the longer delay ensures that the relevant log data is fully packaged during the fixed-size packaging process. Therefore, by determining the start time for acquiring log data based on different ECU log packaging methods, the completeness of the acquired log data can be improved, while avoiding excessive log data being packaged.

[0063] In some embodiments, the acquisition module 326 can be further configured to determine the start time of the acquired log data based on the stage of the OTA upgrade when the vehicle OTA upgrade problem corresponding to the monitored error code occurs. Specifically, if the OTA upgrade problem occurs during the ECU flashing stage, the start time of the packaged log data is the third time period before the time the error code is monitored. Compared to the non-ECU flashing stage, the ECU flashing stage involves more data writing and configuration changes. By setting a third time period to acquire log data from the time the error code is monitored (i.e., when the OTA upgrade problem occurs), the acquisition module 326 can acquire log data covering a larger time range of steps involved in the OTA operation during the flashing stage and the potential for problems (because log data within the third time period before the error code is monitored is also acquired), thus facilitating a more complete set of log data regarding the OTA upgrade problem. The third time period can be set to a value greater than 100 seconds, such as 7300 seconds. If the OTA upgrade issue occurs outside the ECU flashing phase, the fourth time period before the time the error code is monitored is the starting point for packaging the log data. The non-ECU flashing phase may include, for example, downloading the software update package or initializing the vehicle system. These phases involve less data interaction and have a shorter time span compared to the flashing phase. Therefore, the acquisition module 326 starts acquiring log data from the fourth time period before the error code is monitored (i.e., the fourth time period before the time the error code is monitored is the starting point for packaging the log data), and this fourth time period is shorter than the third time period. For example, for a third time period of 7300 seconds, the fourth time period can be set to 3600 seconds. This shorter time range avoids acquiring too much irrelevant log information.

[0064] By determining the starting point for acquiring log data based on the stage of the OTA upgrade when the vehicle OTA upgrade problem occurs, more complete and efficient acquisition of log data can be achieved. That is, by setting different starting points for acquiring log data for different stages of the OTA upgrade problem, more complete log data related to the problem can be obtained, interference from irrelevant log information can be reduced, and maintenance personnel can more quickly locate and analyze the OTA upgrade problem in the log data of the OTA work order.

[0065] In some embodiments, the problem monitoring system 320 of the OTA system 300 may further include an OTA upgrade problem library 328. The OTA upgrade problem library 328 includes multiple problem models corresponding to various vehicle OTA upgrade problems. Each problem model includes an identifier of a corresponding generated and analyzed vehicle OTA upgrade problem, one or more log keywords, and a recommended solution. Different problem models are distinguished by the one or more log keywords they include. The vehicle OTA upgrade problem identifier is used to identify each OTA upgrade problem in the OTA upgrade problem library, facilitating searching and management within the library. For example, a problem ticket number can be used to distinguish each OTA upgrade problem. The log keywords are extracted from log data related to the corresponding generated and analyzed OTA upgrade problems. Since the OTA upgrade problem library contains known OTA upgrade problems and their solutions, and these known OTA upgrade problems also have corresponding log data, by determining whether the log data corresponding to a newly generated OTA upgrade problem contains these log keywords, it can be determined whether the log data is related to the problem model uniquely corresponding to that log keyword. The recommended solution is a pre-stored solution description document for the problem model. Maintenance personnel can use the recommended solutions mentioned in this document to resolve OTA upgrade problems. In other words, log data that matches one or more log keywords corresponds to a specific problem model.

[0066] The generation module 324 is further configured to: determine the problem model matching the OTA work order in the OTA upgrade problem library; add the information from the determined problem model to the OTA work order. Specifically, if the acquired log data includes one or more log keywords from one of the multiple problem models, then the OTA work order corresponding to the acquired log data matches that problem model. Matching includes determining whether the log data acquired in the OTA work order includes one or more log keywords uniquely corresponding to a specific problem model in the OTA upgrade problem library 328. For example, if the acquired log data includes log keywords such as "software version mismatch" or "upgrade failed" uniquely corresponding to a certain problem model, then the acquired log data matches that problem model. After determining the problem model corresponding to the determined vehicle OTA upgrade problem, the information from the determined problem model is added to the OTA work order. This information includes problem identifiers (e.g., problem ticket number), recommended solutions, etc. In this way, maintenance personnel can directly obtain more information and solutions from the matched problem model when processing OTA work orders, without needing to perform additional analysis and searching. It is understandable that each problem model in the OTA upgrade problem library 328 can include more information to help operations and maintenance personnel analyze the OTA upgrade problems that occur, such as a description of the cause of the problem, whether the vehicle can be driven, and not limited to problem identifiers, log keywords, and recommended solutions.

[0067] Therefore, log keywords can be used to accurately identify the corresponding problem model, thereby obtaining relevant information and recommended solutions for the OTA upgrade problem. For example, if an OTA upgrade fails due to software version incompatibility, the corresponding log keywords for this problem model might include "software version mismatch" or "upgrade failed." When these keywords are matched in the acquired log data, it can be determined that the acquired log data corresponds to the problem model, and a recommended solution for the software version incompatibility problem can be obtained. In this way, the problem model can be quickly located and a recommended solution obtained by checking whether the log keywords are covered by the acquired log data, avoiding the process of repeatedly analyzing and troubleshooting the problem, and shortening the time that operations and maintenance personnel spend on problem solving. In addition, the OTA upgrade problem database 328 centrally manages various problems and their corresponding recommended solutions, facilitating knowledge accumulation and sharing among operations and maintenance personnel.

[0068] Furthermore, due to the limited length of error codes and the limited information they indicate about OTA upgrade issues, relying solely on the error code may not be sufficient to identify the specific problem occurring during the upgrade process. Therefore, identifying different problem models based on one or more log keywords can further diagnose the specific OTA upgrade issue that triggered the monitored error code. For example, if the same error code (e.g., a communication error, starting with "COM") is monitored at two different time points, T1 and T2, this error code only indicates that a communication error occurred at both time points, but it cannot indicate which specific communication error occurred (e.g., the specific communication module or communication level). Moreover, the OTA upgrade issue database may contain multiple problem models for communication errors. Therefore, obtaining the log data corresponding to the error codes monitored at these two time points and determining which problem model among the multiple problem models for communication errors matches the log data is beneficial for matching a more accurate problem model for the vehicle's OTA upgrade issue.

[0069] Correspondingly, in some other embodiments, the generation module 324 is further configured to: if no problem model corresponding to the OTA work order is matched in the OTA upgrade problem library 328, then a new problem model is created in the OTA upgrade problem library 328 for the vehicle OTA upgrade problem corresponding to the OTA work order. The specific process includes creating a problem identifier for the problem, extracting log keywords from the acquired log data, and populating the recommended solution for the problem. The solution can be temporarily populated as a solution to a problem model similar to the problem, such as a problem model that matches a large number of log keywords or nearly matches all log keywords. For example, if the log data corresponding to the monitored error code does not cover all log keywords of a certain problem model A, but covers most of them (e.g., covering 4 out of 5 log keywords), then the recommended solution for problem model A can be populated in the newly created problem model for that problem. Furthermore, the solution can also be populated by maintenance personnel later. For example, for a newly emerging OTA upgrade failure caused by a vehicle sensor malfunction, a new problem identifier, such as "S005," is assigned. Information related to the vehicle sensor malfunction is extracted from the log data as log keywords, such as "abnormal sensor data" and "upgrade interrupted." Then, maintenance personnel summarize recommended solutions based on the specific circumstances of the problem and their experience, such as "check sensor connections and replace the faulty sensor." This information regarding newly emerging OTA upgrade failures is integrated into a new problem model and added to the OTA upgrade problem database. In this way, the OTA upgrade problem database can be continuously improved during the vehicle OTA process, and newly emerging problems can be promptly included in the database management, improving the ability to handle various vehicle OTA upgrade problems.

[0070] According to another aspect of this disclosure, an electronic device is also provided. The electronic device includes a memory and a processor, the memory storing instructions that, when executed by the processor, perform the method 100 according to any of the foregoing embodiments. According to yet another aspect of this disclosure, a computer-readable storage medium storing instructions that, when executed, perform the method 100 according to any embodiment of this disclosure.

[0071] The computer-readable storage medium, memory, storage unit, storage module, etc., referred to in this application include various types of computer-readable storage media, and can be any available medium that can be accessed by a general-purpose or special-purpose computer. For example, computer-readable media may include RAM, ROM, EPROM, E... 2 PROM, registers, hard disk, removable disk, CD-ROM or other optical disc storage, magnetic disk storage or other magnetic storage device, or any other temporary or non-temporary medium capable of carrying or storing desired program code units in the form of instructions or data structures and accessible by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Combinations of the above should also be included within the scope of protection for computer-readable media. An exemplary storage medium is coupled to a processor so that the processor can read and write information from / to the storage medium.

[0072] The foregoing primarily describes the vehicle over-the-air (OTA) upgrade problem monitoring method, system, and electronic equipment disclosed herein. Although only some specific embodiments of this disclosure have been described, those skilled in the art should understand that this disclosure can be implemented in many other forms without departing from its spirit and scope. Therefore, the examples and embodiments shown are considered illustrative rather than restrictive, and this disclosure may cover various modifications and substitutions without departing from the spirit and scope of this disclosure as defined by the appended claims.

Claims

1. A method for monitoring vehicle OTA upgrade issues, characterized in that, The method includes the following steps: S1: Based on error codes monitored in the OTA server, receive first information associated with the monitored error codes from the OTA server, wherein the OTA server includes monitoring points for multiple error codes used to monitor vehicle OTA upgrade issues; and S2: Based on the first information received from the OTA server, generate an OTA work order, the OTA work order including at least: the identifier of the vehicle corresponding to the monitored error code, and second information related to the OTA upgrade problem of the vehicle corresponding to the monitored error code.

2. The method according to claim 1, characterized in that, The second information further includes one or more of the following: the time when the error code was detected, the current version of the vehicle's OTA upgrade software, the vehicle model, and a description of the OTA upgrade problem corresponding to the detected error code.

3. The method according to claim 1, characterized in that, The method further includes: acquiring log data corresponding to the monitored error code; and adding the acquired log data to the OTA work order.

4. The method according to claim 3, characterized in that, The acquisition of log data corresponding to the monitored error codes further includes: Based on the monitored error codes, determine the log retrieval logic corresponding to the monitored error codes; Based on the log acquisition logic, log data corresponding to the monitored error codes is acquired; The obtained log data is added to the OTA work order.

5. The method according to claim 4, characterized in that, The determination of the log acquisition logic includes determining the starting point for acquiring the packaged log data based on the ECU log packaging method corresponding to the monitored error code: If the ECU log packaging method is immediate packaging, then after a first time delay following the detection of the error code, the acquisition of the packaged log data will begin. If the ECU log is packaged in a fixed size, then after a second time delay following the detection of the error code, the packaged log data will be retrieved. The second time period is longer than the first time period.

6. The method according to claim 4, characterized in that, The determination of the log acquisition logic includes determining the start time point of the acquired log data based on the occurrence stage of the vehicle OTA upgrade problem corresponding to the monitored error code: If the occurrence stage is the ECU flashing stage, then log data starting from the third time period before the time point when the error code is detected is obtained; If the occurrence stage is not the ECU flashing stage, then log data starting from the fourth time period before the time point when the error code was detected will be acquired. The third time period is longer than the fourth time period.

7. The method according to claim 3, characterized in that, The method further includes: Identify the problem model that matches the OTA work order from the OTA upgrade problem database; The information from the identified problem model is added to the OTA work order. The OTA upgrade issue database includes multiple issue models corresponding to various vehicle OTA upgrade issues. Each issue model includes an identifier for the corresponding vehicle OTA upgrade issue, one or more log keywords, and a recommended solution. Different issue models are distinguished based on the one or more log keywords. Furthermore, if the obtained log data includes one or more log keywords of one of the multiple problem models, then the OTA work order corresponding to the obtained log data matches that problem model.

8. A monitoring system for over-the-air (OTA) upgrade issues in vehicles, characterized in that, The problem monitoring system includes: A receiving module is configured to receive first information from an OTA server, wherein the OTA server includes multiple error codes for monitoring vehicle OTA upgrade issues, and the first information is associated with the error codes of the monitored error codes. The generation module is configured to generate an OTA work order based on the first information, wherein the OTA work order includes at least: an identifier of the vehicle corresponding to the monitored error code, and second information associated with the OTA upgrade problem of the vehicle corresponding to the monitored error code.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing instructions that, when executed by the processor, perform the method according to any one of claims 1-7.

10. An OTA system, characterized in that, The OTA system includes: An OTA server that interacts with the vehicle regarding OTA tasks and includes tracking points for multiple error codes used to monitor for OTA upgrade issues in the vehicle; The OTA upgrade problem monitoring system as described in claim 8.

Images