Software upgrade failure user notification method, vehicle-mounted system, server and medium

Abstract

This application provides a method for notifying users of software upgrade failures, an in-vehicle system, a server, and a medium. The method includes: responding to the in-vehicle system receiving software upgrade strategy data, performing a software upgrade based on the software upgrade strategy data and generating a software upgrade result; when the software upgrade result meets preset upgrade failure conditions, generating upgrade failure information based on the software upgrade result, and uploading the vehicle's identification information and upgrade failure information to the server; querying the in-vehicle system's preset configuration database based on the upgrade failure information to obtain failure error information and generate an error risk level; generating a failure prompt message based on the failure error information and the vehicle's fault log; determining an information sending strategy based on the error risk level, and sending the failure prompt message to the target terminal based on the information sending strategy. This shortens response time, provides differentiated notification based on risk level, avoids insufficient or excessive notifications, and reduces the risk of misoperation.

Description

Technical Field

[0001] This application relates to the field of software upgrade technology, and in particular to a method for notifying users of software upgrade failure, an in-vehicle system, a server, and a medium. Background Technology

[0002] With the continuous improvement of vehicle intelligence and connectivity, OTA (Over-The-Air) remote upgrades have become a core means for modern intelligent vehicles to achieve functional iteration and performance optimization. Its application scope covers multiple levels, including ECU (Electronic Control Unit) firmware upgrades, in-vehicle software function updates, and security patch deployments. Under normal circumstances, after an OTA upgrade is completed, the in-vehicle system will display a corresponding success message to the user.

[0003] When anomalies or failures occur during OTA upgrades, relevant technologies are generally equipped with rollback fault tolerance mechanisms, which can attempt to restore the vehicle to the state of the software version before the upgrade to a certain extent. However, the effectiveness and completeness of this mechanism are often uncertain. More importantly, regardless of whether the rollback operation is successful or not, existing in-vehicle systems provide users with highly generalized fault prompts at the human-machine interface level. This may lead users to continue driving without knowing that critical safety functions are malfunctioning, or to take inappropriate actions due to misjudgment of the vehicle's status, increasing the communication costs and handling difficulties of after-sales service. Summary of the Invention

[0004] This application aims to at least partially address one of the technical problems in the related art.

[0005] Therefore, the first objective of this application is to propose a method for notifying users of software upgrade failures, which can instantly map error codes to user-readable descriptions on the vehicle side when an upgrade failure occurs, significantly shortening the fault response latency; at the same time, it matches differentiated sending strategies according to risk levels, avoiding excessive disturbance to users for low-risk faults and insufficient notification for high-risk faults, and ensuring that users can intuitively understand the scope of fault impact and handling methods without having to interpret the technical code themselves, effectively reducing the safety risks of misoperation caused by unclear information.

[0006] The second objective of this application is to propose a method for notifying users when software upgrades fail.

[0007] The third objective of this application is to propose an in-vehicle system.

[0008] The fourth objective of this application is to propose a server.

[0009] The fifth objective of this application is to provide a computer-readable storage medium.

[0010] To achieve the above objectives, the first aspect of this application proposes a method for notifying users of software upgrade failures, applied to an in-vehicle system. The method includes: responding to the in-vehicle system receiving software upgrade strategy data sent by a server, performing a software upgrade based on the software upgrade strategy data and generating a software upgrade result; responding to the software upgrade result meeting preset upgrade failure conditions, generating upgrade failure information based on the software upgrade result, and uploading the vehicle's identification information and upgrade failure information to the server; querying the in-vehicle system's preset configuration database based on the upgrade failure information to obtain failure error information, and generating an error risk level based on the failure error information; generating a failure prompt message based on the failure error information and the vehicle's fault log; determining an information sending strategy based on the error risk level, and sending the failure prompt message to the target terminal based on the information sending strategy.

[0011] In addition, the user notification method for software upgrade failure according to the above embodiments of this application may also have the following additional technical features: According to one embodiment of this application, the upgrade failure information includes an error controller identifier code and an error category code. The system queries the pre-configured database of the vehicle system based on the upgrade failure information to obtain failure error information, including: querying the pre-configured database based on the error controller identifier code to obtain the error controller; querying the pre-configured database based on the error category code to obtain error category information; and generating failure error information based on the error controller and the error category information.

[0012] According to one embodiment of this application, the failure error information includes functional impact description information and operation guidance information. A failure prompt information is generated based on the failure error information and the vehicle's fault log, including: performing semantic conversion processing on the functional impact description information to generate natural language description information; searching the fault log based on the failure error information to obtain historical fault auxiliary information; and generating the failure prompt information based on the natural language description information, operation guidance information, and historical fault auxiliary information.

[0013] According to one embodiment of this application, after determining the information sending strategy based on the error risk level, the method further includes: matching the error category code and the error risk level in a preset configuration database to obtain a service invocation strategy; and sending a failure message to the target terminal based on the information sending strategy and the service invocation strategy.

[0014] According to one embodiment of this application, determining an information sending strategy based on an error risk level includes: setting the information sending strategy to a silent notification strategy in response to a low error risk level; setting the information sending strategy to a prominent notification strategy in response to a medium error risk level; and setting the information sending strategy to an acknowledgment notification strategy in response to a high error risk level.

[0015] To achieve the above objectives, a second aspect of this application proposes a method for notifying users of software upgrade failures, applied to a server. The method includes: in response to an in-vehicle software upgrade request, the server generates software upgrade strategy data based on the in-vehicle software upgrade request and sends the software upgrade strategy data to the corresponding in-vehicle system; in response to receiving identification information and upgrade failure information corresponding to the software upgrade strategy data uploaded by the in-vehicle system, the server records the identification information and upgrade failure information to an error database.

[0016] In addition, the user notification method for software upgrade failure according to the above embodiments of this application may also have the following additional technical features: According to one embodiment of this application, the method for notifying users of software upgrade failures further includes: the server performing statistical analysis based on error data in the error database to generate error analysis results.

[0017] The software upgrade failure notification method provided in this application can instantly map error codes to user-readable descriptions on the vehicle side when an upgrade failure occurs, significantly shortening the fault response latency. At the same time, it matches differentiated sending strategies according to risk levels, avoiding excessive disturbance to users for low-risk faults and insufficient notification for high-risk faults, and ensuring that users can intuitively understand the scope of fault impact and handling methods without having to interpret the technical code themselves, effectively reducing the safety risks of misoperation caused by unclear information.

[0018] To achieve the above objectives, a third aspect of this application provides an in-vehicle system, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the aforementioned method for notifying users of software upgrade failures.

[0019] According to the vehicle-mounted system of this application, the aforementioned method for notifying users of software upgrade failures is implemented. When an upgrade failure occurs, the system can instantly map and convert error codes to user-readable descriptions locally on the vehicle, significantly shortening fault response latency. Simultaneously, it matches differentiated sending strategies based on risk levels, avoiding excessive disruption to users with low-risk faults while providing insufficient notification for high-risk faults. Furthermore, it ensures that users can intuitively understand the scope of the fault's impact and handling methods without having to interpret the technical code themselves, effectively reducing the safety risks of misoperation caused by unclear information.

[0020] To achieve the above objectives, a fourth aspect of this application provides a server, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the aforementioned method for notifying users of software upgrade failures.

[0021] According to the server described in this application, when the processor on it executes a program stored in memory, it implements the aforementioned method for notifying users of software upgrade failures. Through this method, the server provides effective support in three areas: upgrade task scheduling, fault data accumulation, and emergency event response. During the upgrade distribution phase, corresponding upgrade strategy data is generated and pushed based on vehicle requests, providing complete content and configuration basis for the upgrade execution on the vehicle side. During the data feedback phase, the identification information and upgrade failure information reported by each vehicle are centrally recorded in the error database, providing a data accumulation foundation for subsequent fault type statistics, version anomaly identification, and configuration library rule revision. During the emergency event phase, upon receiving a distress message from a vehicle, it is promptly forwarded to the rescue terminal, establishing an information transmission link from the occurrence of vehicle anomaly to the receipt by the external server, shortening the time delay for external rescue intervention in emergency situations.

[0022] To achieve the above objectives, a fifth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the aforementioned software upgrade failure user notification method.

[0023] According to the computer-readable storage medium of this application, when the computer program stored thereon is executed by a processor, it is used to implement the aforementioned method for notifying users of software upgrade failures. A complete processing link is formed through the coordinated cooperation of the vehicle-mounted terminal and the server. After an upgrade failure occurs, the vehicle-mounted terminal immediately completes the mapping conversion from error code to user-readable description locally, and matches differentiated sending strategies according to different risk levels; the server provides support at three levels: upgrade strategy distribution, failure data accumulation, and emergency distress call forwarding. It centrally records the reported failure information to form a data accumulation basis, and promptly transmits it to the rescue terminal when it receives distress information. The combination of these two methods ensures the timeliness of fault response and the intuitiveness of notification content at the vehicle end, and provides a data foundation and information channel at the server end for subsequent fault attribution analysis, configuration library rule revision, and emergency external rescue response. Attached Figure Description

[0024] Figure 1 A flowchart of a user notification method for software upgrade failure according to some embodiments of this application; Figure 2 A flowchart of a user notification method for software upgrade failure according to some embodiments of this application; Figure 3This is a flowchart of a user notification method for software upgrade failure according to a specific embodiment of this application; Figure 4 This is a block diagram of an in-vehicle system according to some embodiments of this application; Figure 5 This is a block diagram of a server according to some embodiments of this application. Detailed Implementation

[0025] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0026] The following describes in detail, with reference to the accompanying drawings, a user notification method for software upgrade failure, an in-vehicle system, a server, and a medium according to embodiments of this application.

[0027] It is understood that the user notification method for software upgrade failure in this application can be implemented using SOA (Service-Oriented Architecture). In this approach, each functional module of the vehicle-mounted system encapsulates its capabilities as callable services. Each step in the user notification process for upgrade failure is completed through service calls and collaboration, thereby decoupling each processing step into an independent service. This facilitates independent development, deployment, and maintenance of each service, and also promotes the reuse of services across different vehicle models or projects. This application provides a user notification method for software upgrade failure. (Refer to...) Figure 1 Methods for notifying users of software upgrade failures may include: S1, in response to the vehicle system receiving software upgrade strategy data sent by the server, performs software upgrade based on the software upgrade strategy data and generates software upgrade results, wherein the software upgrade strategy data includes a pre-configured database.

[0028] Among them, software upgrade strategy data can refer to the set of relevant data issued by the server to guide the vehicle system to complete this upgrade task.

[0029] In some embodiments, the software upgrade strategy data also includes a software upgrade data package, which may refer to a collection of data such as firmware binary files, application executable files, configuration files or checksums that the target ECU needs to update, used to transmit and write the new version of software content to the target controller in the actual upgrade process.

[0030] Specifically, the T-Box (Telematics Box, vehicle-mounted remote information processing terminal) performs firmware or software package version update operations on the target ECU based on the received upgrade strategy data. After the operation is completed, it collects the return status codes and communication response results of each relevant controller, and comprehensively judges whether the upgrade process has been fully executed, thereby forming a software upgrade result containing success or error indicators.

[0031] S2, in response to the software upgrade result meeting the preset upgrade failure conditions, generates upgrade failure information based on the software upgrade result, and uploads the vehicle identification information and upgrade failure information to the server.

[0032] The preset upgrade failure conditions refer to a set of judgment rules pre-defined by technical personnel based on the normal return code range and timeout threshold of each controller during the upgrade process. These preset upgrade failure conditions can refer to the response characteristic analysis and vehicle calibration results of different controllers under different abnormal operating conditions during the development phase. Specific thresholds and judgment logic can be adaptively adjusted according to different vehicle models or subsequent data accumulation, and are not specifically limited.

[0033] If the software upgrade result meets the preset upgrade failure conditions, it means that the upgrade execution status collected by the current vehicle system matches the set of judgment rules, indicating that the upgrade process was not fully executed or the execution result is abnormal.

[0034] Furthermore, upgrade failure information can refer to structured data records that describe the specific types and sources of anomalies that occurred during the upgrade process.

[0035] In some embodiments, a complete fault log is uploaded to the server. The complete fault log may refer to a time-seriesd raw data set recorded by the vehicle system during and before and after the execution of this upgrade process, which includes changes in the status of each controller, communication interaction timing, error return codes and abnormal events.

[0036] Once the complete fault log is uploaded to the server, it can be used by server-side technicians or automated analysis tools to perform offline reproduction and diagnostic analysis of the root causes of this upgrade failure. It can also serve as an iterative optimization data source for mapping rules and risk level classification in the pre-configured database, without any specific limitations.

[0037] Specifically, in response to the software upgrade result meeting the preset upgrade failure conditions, the vehicle system generates a structured upgrade failure message based on the abnormal status return code and incomplete operation step identifier contained in the software upgrade result. Subsequently, the vehicle system encapsulates the vehicle's identification information along with the upgrade failure message and sends it to the server via a wireless communication link.

[0038] S3 queries the pre-configured database of the vehicle system based on upgrade failure information to obtain failure error information and generates an error risk level based on the failure error information.

[0039] Furthermore, in some embodiments of this application, the upgrade failure information includes an error controller identifier code and an error category code.

[0040] The error controller identifier code is a coded information used to uniquely identify the ECU that returned an abnormal state or failed to respond correctly to the upgrade request during this upgrade process. The error category code is a coded information used to characterize the specific type or cause of the abnormal response returned by the controller.

[0041] In some embodiments of this application, querying the pre-configured database of the vehicle system based on upgrade failure information to obtain failure error information includes: querying the pre-configured database based on the error controller identifier to obtain the error controller; querying the pre-configured database based on the error category code to obtain error category information; and generating failure error information based on the error controller and the error category information.

[0042] Furthermore, the pre-configured database can refer to a set of structured mapping data pre-deployed in the local storage of the in-vehicle system. The pre-configured database can be pre-set by technicians during the development phase based on the functional safety level, failure mode analysis, and historical fault data of each controller, combined with the results of real vehicle test calibration. The specific values ​​and corresponding relationships can be adaptively adjusted according to different vehicle models or subsequent data accumulation, and there are no specific limitations.

[0043] Among them, the error controller can refer to the specific controller name or functional module that has an anomaly during this upgrade process, which is determined by matching and querying the error controller identifier code in the preset configuration database.

[0044] Error category information refers to a textual description of the specific type or nature of the current anomaly, determined by matching the error category code in the pre-configured database.

[0045] Specifically, the in-vehicle system (e.g., OTA Master) first uses the error controller identifier code as the search key to perform a match in the pre-configured database to locate the specific controller object where the anomaly occurred; then, it uses the error category code as the search key to perform a match in the same database to obtain the specific error type or fault nature description corresponding to the anomaly; finally, it associates and combines the located controller object with the obtained error type description to form the failure error information for this upgrade failure.

[0046] As a specific embodiment of this example, the mapping relationship between the error controller identifier code and the controller is shown in Table 1.

[0047] Table 1

[0048] Furthermore, OTA Master uses the faulty controller and error category information from the failure error message as joint matching conditions to retrieve the corresponding risk level identifier from the pre-configured database. This risk level identifier is pre-defined and stored by technicians based on the impact of each controller on vehicle driving safety, functional availability, and regulatory compliance under different error categories when the database is built, thereby obtaining the error risk level of the current failure event.

[0049] In some embodiments of this application, if no failure error information corresponding to the upgrade failure information is found in the pre-configured database of the vehicle system, a default general prompt policy is returned to the OTA Master, and the upgrade failure is marked as an unknown risk.

[0050] S4 generates a failure message based on the failure error information and the vehicle's fault log. The fault log refers to the time-series data recorded by the OTA Master during and before and after the execution of this upgrade process, including changes in the status of each controller, the timing of communication interactions, and abnormal events.

[0051] Specifically, OTA Master integrates the faulty controller name and error category description parsed from the failure error message with the context status data associated with the timestamp and controller identifier in the fault log to form a failure prompt message that includes the location of the fault, the type of the anomaly, and the status information of the surrounding environment.

[0052] In some embodiments of this application, the failure error information includes functional impact description information and operation guidance information.

[0053] The functional impact description information refers to the textual description in the pre-configured database that is associated with the fault controller and the fault category code and is used to explain the actual impact of the current fault on the specific functions of the vehicle.

[0054] Operation guidance information may refer to the textual guidance content in the pre-configured database that is associated with the error controller and error category code, and is used to provide users with follow-up handling suggestions or operation steps for the current fault state.

[0055] Furthermore, in some embodiments of this application, generating failure prompt information based on failure error information and vehicle fault log includes: performing semantic conversion processing on functional impact description information to generate natural language description information; searching the fault log based on failure error information to obtain historical fault auxiliary information; and generating failure prompt information based on natural language description information, operation guidance information, and historical fault auxiliary information.

[0056] Among them, natural language description information can refer to the result text formed by replacing or transcribing the technical terms or abbreviations in the description information of functional impact into colloquial expressions that are easy for users to understand in daily scenarios.

[0057] Historical fault auxiliary information refers to the relevant record data of historical abnormal events retrieved from the fault log that have the same or similar characteristics as the controller identifier or error category in the current failure error information.

[0058] Specifically, OTA Master extracts the functional impact description information from the failure error message, maps the technical terms or coded fields contained within it into corresponding natural language expressions, forming user-readable descriptive text, i.e., natural language description information. Simultaneously, using the controller identifier or error category contained in the failure error message as search keywords, it searches the fault log for historical abnormal events with similar characteristics and their handling records, forming historical fault auxiliary information. Subsequently, the converted natural language description information, the operation guidance information directly obtained from the pre-configured database, and the retrieved historical fault auxiliary information are merged and arranged to form a complete failure prompt message.

[0059] As a specific embodiment of this example, when the software upgrade result meets the preset upgrade failure conditions, and the error controller identifier code in the upgrade failure information points to the BMS, the OTA Master queries the preset configuration database using the error controller identifier code and the error category code, obtaining a BMS upgrade write verification failure. Simultaneously, it obtains the function impact description information "inaccurate range display, fast charging speed may decrease, and in extreme cases, charging may be impossible" and the operation guidance information "Please plan your trip carefully to avoid running out of power and contact customer service." Based on the error controller and error category information, it generates a failure error message and further uses these two as joint matching conditions to determine that the error risk level is high. After generating the failure error message, the OTA Master uploads structured data containing vehicle identification information and complete fault logs to the server.

[0060] S5 determines the information sending strategy based on the error risk level, and sends the failure prompt message to the target terminal based on the information sending strategy.

[0061] In some embodiments of this application, determining the information sending strategy based on the error risk level includes: setting the information sending strategy to a silent notification strategy in response to a low error risk level; setting the information sending strategy to a prominent notification strategy in response to a medium error risk level; and setting the information sending strategy to an acknowledgment notification strategy in response to a high error risk level.

[0062] Among them, the silent notification strategy can refer to a notification method that displays concise text only in the status bar or notification center of the vehicle interface, without occupying the user's active focus, and without being interrupted by sound or pop-ups.

[0063] A prominent notification strategy refers to displaying information in the vehicle interface with a more eye-catching visual style, such as using larger fonts, high-contrast color blocks, or accompanied by short notification sounds, to attract the user's attention, but a notification method that can be closed or ignored without requiring the user to perform a confirmation operation.

[0064] Confirmation notification strategies can refer to displaying notifications in the vehicle interface as pop-ups or full-screen cards, requiring users to manually click to confirm or select the corresponding option before they can continue using other vehicle interaction functions.

[0065] Forced notification strategy refers to a notification method that displays the notification in the vehicle interface in a full-screen blocking manner, keeps it on the front end and cannot be closed or skipped by the user, and can only be lifted after the user completes a specific operation according to the interface instructions or contacts after-sales service.

[0066] Specifically, when the error risk level is high (i.e., a safety-related fault), the OTA Master calls the safety warning service provided by the IVI or instrument cluster via the SOA service bus to execute a full-screen pop-up on the target terminal, blocking other operations. Simultaneously, it triggers a synchronized voice broadcast of an emergency safety prompt and displays a shortcut button for the rescue center or service center. An operation receipt is returned after the driver or user confirms the action. When the error risk level is medium (i.e., a function-limited fault), the OTA Master calls the secondary pop-up or service prompt bar service provided by the IVI via the SOA service bus to synchronously display the fault function limitation information on the target terminal. An operation receipt is returned after the user confirms or returns to the previous action. When the error risk level is low (i.e., a user experience-related fault), the OTA Master calls the message center notification writing service provided by the IVI via the SOA service bus to silently generate a message record on the target terminal without interrupting driving. An operation receipt is returned after the notification writing is complete.

[0067] In the handling of the above three risk levels, after completing the corresponding prompt information distribution and user interaction receipt acquisition, OTA Master triggers T-Box to asynchronously execute background data reporting, uploading the inference results, fault events and user interaction status to the cloud platform without blocking the vehicle-side prompt process. After reporting, the cloud platform will store the received data in the database for subsequent iteration and optimization of the pre-configured database.

[0068] In some embodiments of this application, after determining the information sending strategy based on the error risk level, the method further includes: matching the error category code and the error risk level in a preset configuration database to obtain a service invocation strategy; and sending a failure message to the target terminal based on the information sending strategy and the service invocation strategy.

[0069] Service invocation strategy refers to a set of execution rules formulated by the OTA Master in the SOA architecture for the invocation method, invocation sequence, timeout threshold, retry mechanism and exception handling method of each target service node when distributing the fault information involved in the failure of this upgrade in the form of standard service signals.

[0070] For example, the service invocation strategy includes a list of target service nodes to be invoked, such as IVI (In-Vehicle Infotainment) service, instrument display service, T-Box upload service, etc., the invocation priority order of each service node, the timeout threshold for a single service invocation, the number of retries and the retry interval after a call failure, and the degradation handling scheme when each service node returns an exception.

[0071] According to the service invocation strategy, the OTA Master transforms the failure message into a standard service signal through the SOA service bus, and sequentially calls each target service node according to a predetermined priority and timing to complete the distribution and presentation of the failure message. For example, when the error risk level is high, the service invocation strategy can stipulate that the OTA Master prioritizes calling the instrument display service to immediately present the warning message, while simultaneously calling the T-Box upload service in parallel to report the failure information to the cloud. After the instrument display service call is successful, the IVI service is then called to display detailed operation guidance information. When the error risk level is low, the service invocation strategy can stipulate that the OTA Master only calls the IVI service to present the warning message in a silent notification manner, without calling the instrument display service to avoid interfering with the driver's normal driving.

[0072] In one specific embodiment of this application, during the software upgrade of the BMS core module, the vehicle-side OTA Master captures an upgrade failure event with the underlying error code NRC 0x72 (General Programming Fault). The OTA Master uses the error controller identifier and error category code as search keys to perform a matching query in the pre-configured database. It successfully matches the configuration entry corresponding to the error code, identifies the risk level as high, and describes the functional impact as "Battery SOC estimation may be inaccurate, fast charging function is limited." The operation guidance information is "Please contact the authorized service center immediately to schedule maintenance and avoid long-distance driving." Subsequently, according to the information sending strategy corresponding to high risk, the OTA Master calls the "High-Risk Warning Service" of the instrument cluster and central control domain via the SOA service bus to distribute the failure message to the target terminal. On the user interface, a full-screen red warning box immediately pops up, accompanied by an urgent prompt sound. The title displays "Upgrade incomplete," and the text clearly lists "Range display may be inaccurate, fast charging function is limited." Shortcut buttons for "Call for Assistance" or "View Nearest Service Center" are provided at the bottom for user operation.

[0073] In another specific embodiment of this application, during the software upgrade of the IVI system itself or its associated audio amplifier ECU, the vehicle-side OTA Master captures an upgrade failure event with error code 0x93 (transmission / routing failure). The OTA Master uses the error controller identifier code and error category code as search keys to perform a matching query in the pre-configured database. It successfully matches the configuration entry corresponding to the error code, interpreting the risk level as medium risk. The functional impact description is "The in-vehicle audio and navigation voice broadcast functions are temporarily unavailable," and the operation guidance information is "Vehicle driving and charging functions are not affected; you can continue to use the vehicle, and it may automatically recover after a restart." Subsequently, according to the information sending strategy corresponding to medium risk, the OTA Master calls the "Prominent Prompt Service" of the central control domain through the SOA service bus to distribute the failure prompt information to the target terminal. On the user interface, a prominent yellow prompt bar pops up at the top or bottom of the screen, continuously displayed for 10 seconds or until the user manually closes it. The prompt clearly informs the scope of the functional limitation and emphasizes that "it does not affect driving safety," avoiding unnecessary panic for the user.

[0074] In another specific embodiment of this application, during the software upgrade of the in-vehicle air quality sensor or ambient lighting control module, the vehicle-side OTA Master captures an upgrade failure event with error code 0x7F (response pending). The OTA Master uses the error controller identifier and error category code as search keys to perform a matching query in the pre-configured database. It successfully matches the configuration entry corresponding to the error code, identifies the risk level as low, describes the functional impact as "automatic in-vehicle air quality purification function suspended," and provides the operation guidance information as "purification can be manually activated without affecting normal vehicle use." Subsequently, based on the information sending strategy corresponding to low risk, the OTA Master calls the "silent notification service" of the message center through the SOA service bus to distribute the failure message to the target terminal. On the user interface, there are no pop-ups or sound interruptions; only an "upgrade notification" record is generated in the message center list after the vehicle starts, which the user can click to view at idle time to understand the details.

[0075] This application provides a method for notifying users of software upgrade failures. The in-vehicle system receives software upgrade strategy data containing a pre-configured database and performs the upgrade, generating an upgrade result. When the upgrade result meets preset failure conditions, upgrade failure information is generated and uploaded to the server. Subsequently, based on this upgrade failure information, the pre-configured database is queried to obtain failure error information including an error controller, error category information, functional impact description, and operation guidance, and an error risk level is generated accordingly. Simultaneously, a failure prompt message containing natural language description and historical auxiliary information is generated by combining fault logs. Finally, based on low, medium, and high risk levels, silent notification, prominent notification, and acknowledgment notification strategies are used respectively, and the failure prompt message is sent to the target terminal via the SOA service bus.

[0076] This embodiment achieves instant conversion of error codes into user-readable descriptions through a locally pre-built database, eliminating reliance on real-time cloud queries and significantly reducing fault response latency. Simultaneously, it matches differentiated display strategies and operation guidelines based on risk levels, enabling users to intuitively understand the scope of fault impact and handling methods, effectively reducing the safety risks of misoperation caused by unclear information, and improving the efficiency of after-sales problem location and handling.

[0077] This application also provides a method for notifying users of software upgrade failures, applied to a server, as described above. Figure 2 The methods include: S210: In response to the vehicle software upgrade request, the server generates software upgrade policy data based on the vehicle software upgrade request and sends the software upgrade policy data to the corresponding vehicle system.

[0078] Among them, the vehicle software upgrade request can refer to the data instruction initiated by the vehicle system or vehicle management platform to instruct the server to prepare and issue the upgrade content corresponding to a specific model or specific vehicle identification code.

[0079] Specifically, in response to an in-vehicle software upgrade request, the server matches the corresponding upgrade data packet and configuration parameters according to the vehicle model information, current software version number and target version number contained in the request, assembles them into complete software upgrade strategy data, and sends the strategy data to the corresponding in-vehicle system through a wireless communication link.

[0080] S220: In response to receiving the identification information and upgrade failure information corresponding to the software upgrade strategy data uploaded by the vehicle system, the server records the identification information and upgrade failure information to the error database.

[0081] The error reporting database can refer to a data storage set deployed on the server side for centrally storing structured data related to upgrade failures reported by each vehicle.

[0082] Specifically, in response to receiving the identification information and upgrade failure information corresponding to the software upgrade strategy data uploaded by the vehicle system, the server parses and formats the identification information and upgrade failure information, and then writes it as an error record into the corresponding data table or set in the error database.

[0083] In some embodiments of this application, the method for notifying users of software upgrade failures further includes: the server performing statistical analysis based on error data in the error database to generate error analysis results.

[0084] Among them, the error analysis results can refer to the statistical conclusions obtained by the server after classifying, counting and trend calculating the identification information and upgrade failure information accumulated in the error database.

[0085] Specifically, the server uses the error controller name or error category code of each record in the error database as a statistical dimension to calculate the frequency and proportion of various types of faults. It also clusters the error data under the same vehicle model or the same software version to identify high-frequency fault types and the distribution of concentrated occurrence time periods, thereby generating error analysis results that include fault frequency ranking, version-related fault rate, and abnormal trend description.

[0086] Error analysis results can be used to provide data support for subsequent adjustments to risk level classification thresholds in the pre-configured database, optimization and revision of functional impact description information and operation guidance information, as well as improvements to upgrade package integrity verification strategies or rollback trigger conditions in software upgrade strategy data.

[0087] It is understood that for details not disclosed in the method for notifying users of software upgrade failure applied to servers in this application, please refer to the method for notifying users of software upgrade failure applied to vehicle systems in this application, and will not be elaborated further.

[0088] As a specific embodiment of this application, refer to Figure 3 The user notification method for software upgrade failure in this application also includes: S301 generates software upgrade strategy data based on the vehicle software upgrade request.

[0089] S302, software upgrade strategy data is sent to the corresponding vehicle system.

[0090] S303 performs software upgrades based on software upgrade strategy data and generates software upgrade results.

[0091] S304, in response to the software upgrade result meeting the preset upgrade failure conditions, upgrade failure information is displayed.

[0092] S305 uploads the vehicle's identification information and upgrade failure information to the server.

[0093] S306 records the identification information and upgrade failure information to the error database.

[0094] S307 obtains failure error information based on upgrade failure information and the pre-configured database.

[0095] S308, Generate error risk level based on failure error information.

[0096] S309 generates a failure message based on the failure error information and the vehicle's fault log.

[0097] S310 determines the information transmission strategy based on the error risk level.

[0098] S311, based on the information sending strategy, sends a failure message to the target terminal.

[0099] The user notification method for software upgrade failure proposed in this application has the following technical advantages over existing technologies: First, by loading the local pre-configured database through the vehicle-side OTA Master for independent decision-making, without relying on real-time instructions from the cloud, the problem of not being able to promptly notify users of upgrade failure information due to network latency or cloud service unavailability, as in traditional solutions, is avoided. This significantly improves the real-time nature and reliability of user notifications in upgrade failure scenarios.

[0100] Secondly, a mapping relationship between ECU identifiers and error codes and functional impact descriptions, risk levels, and SOA service call strategies was established through a pre-configured database. This enables the automatic matching of structured failure prompts after an upgrade failure, overcoming the shortcomings of traditional solutions that can only provide obscure error codes that are difficult for users to understand, and achieving a user-friendly natural language notification effect.

[0101] Third, by setting error risk levels and determining differentiated information sending strategies based on different risk levels, high-risk faults can be immediately notified to users through a strong reminder with a full-screen pop-up and voice broadcast, medium-risk faults are presented with a prominent prompt bar, and low-risk faults are written to the message center with a silent notification. This ensures that emergency information about safety-related faults can effectively reach users, while avoiding excessive disturbance to drivers in low-risk scenarios, thus balancing safety and user experience.

[0102] Fourth, by converting fault information into standard service signals through the SOA service bus and distributing them to different nodes such as IVI, instrument panel, and T-Box, the upgrade failure notification function is decoupled from the vehicle's various display terminals. This facilitates flexible adaptation to different vehicle models or configurations, and improves the portability and scalability of the solution.

[0103] Fifth, by configuring SOA service invocation strategies in the pre-configured database, OTA Master can automatically determine the invocation method, invocation sequence, and timeout threshold for each target service node based on the error category code and error risk level. This avoids the maintenance difficulties caused by hard-coded invocation logic in traditional solutions, reduces system coupling, and facilitates subsequent iterative optimization.

[0104] This application also provides an in-vehicle system, as shown in the reference. Figure 4 The vehicle system 400 includes: a memory 410, a processor 420, and a computer program stored on the memory 410 and executable on the processor 420. The processor 420 executes the program to implement the aforementioned method for notifying users of software upgrade failures.

[0105] This application also provides a server, as shown in the reference. Figure 5 The server 500 includes: a memory 510, a processor 520, and a computer program stored on the memory 510 and executable on the processor 520. The processor 520 executes the program to implement the aforementioned method for notifying users of software upgrade failures.

[0106] This application also provides a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the aforementioned method for notifying users of software upgrade failures.

[0107] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0108] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0109] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components, unless otherwise explicitly limited. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0110] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

[0111] Any process or method described in the flowchart or otherwise herein is to be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0112] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0113] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0114] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0115] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0116] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

[0117] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0118] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for notifying users of software upgrade failures, characterized in that, Applied to in-vehicle systems, the method includes: In response to the vehicle system receiving software upgrade strategy data sent by the server, the system performs a software upgrade based on the software upgrade strategy data and generates a software upgrade result. In response to the software upgrade result meeting the preset upgrade failure conditions, upgrade failure information is generated based on the software upgrade result, and the vehicle identification information and the upgrade failure information are uploaded to the server; Based on the upgrade failure information, the system queries the pre-configuration database of the vehicle system to obtain failure error information, and generates an error risk level based on the failure error information. A failure message is generated based on the failure error information and the vehicle's fault log. Based on the error risk level, an information sending strategy is determined, and the failure message is sent to the target terminal based on the information sending strategy.

2. The method according to claim 1, characterized in that, The upgrade failure information includes an error controller identifier code and an error category code. The process of querying the vehicle system's pre-configured database based on the upgrade failure information to obtain failure error information includes: The error controller is retrieved by querying the preset configuration database based on the error controller identifier. The error category code is used to query the preset configuration database to obtain error category information; The failure error information is generated based on the error controller and the error category information.

3. The method according to claim 2, characterized in that, The failure error information includes a description of the functional impact and operation guidance information. The generation of failure prompt information based on the failure error information and the vehicle's fault log includes: The functional impact description information is semantically transformed to generate natural language description information; The fault log is searched based on the failure error information to obtain historical fault auxiliary information; The failure message is generated based on the natural language description information, the operation guidance information, and the historical fault assistance information.

4. The method according to claim 2, characterized in that, After determining the information sending strategy based on the error risk level, the method further includes: matching the error category code and the error risk level in the preset configuration database to obtain the service invocation strategy; The failure message is sent to the target terminal based on the information sending strategy and the service calling strategy.

5. The method according to claim 1, characterized in that, The method for determining the information transmission strategy based on the error risk level includes: In response to the error risk level being low risk, the information sending strategy is set to a silent notification strategy. In response to the error risk level being medium risk, the information sending strategy is set to a prominent notification strategy; In response to the error risk level being high risk, the information sending strategy is set to an acknowledgment notification strategy.

6. A method for notifying users of software upgrade failures, characterized in that, Applied to a server, the method includes: In response to an in-vehicle software upgrade request, the server generates software upgrade strategy data based on the in-vehicle software upgrade request and sends the software upgrade strategy data to the corresponding in-vehicle system; In response to receiving the identification information and upgrade failure information corresponding to the software upgrade strategy data uploaded by the vehicle system, the server records the identification information and upgrade failure information to the error database.

7. The method according to claim 6, characterized in that, Also includes: The server performs statistical analysis based on the error data in the error database to generate error analysis results.

8. A vehicle-mounted system, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the software upgrade failure user notification method as described in any one of claims 1-5.

9. A server, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the software upgrade failure user notification method as described in any one of claims 6-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the software upgrade failure notification method as described in any one of claims 1-5 or any one of claims 6-7.

Images