Abnormality processing method and vehicle

Abstract

This application provides an anomaly handling method and vehicle, relating to the field of intelligent cockpit technology. It utilizes an emergency voice module that operates independently of the main control chip to perform emergency voice interaction and trigger anomaly reporting when the chip malfunctions, thereby improving the timeliness and security of anomaly handling. The method includes: in response to a main control chip anomaly indication triggered by the emergency voice module, acquiring historical vehicle data; wherein the emergency voice module operates independently of the main control chip; sending an anomaly diagnosis request carrying the historical vehicle data to a server; and performing anomaly handling operations on the main control chip based on an anomaly handling instruction issued by the server for the historical vehicle data.

Description

Technical Field

[0001] This application relates to intelligent cockpit technology, and provides an anomaly handling method and vehicle. Background Technology

[0002] With the rapid development of intelligent vehicles, in-vehicle terminals have evolved from traditional infotainment devices into comprehensive interactive platforms integrating navigation, communication, cockpit control, and driver assistance. To support increasingly complex functional requirements, in-vehicle systems generally adopt a highly integrated system-on-a-chip (SoC) architecture, integrating various applications and interaction modules into the same system environment.

[0003] However, the main control chip may malfunction due to software errors, resource exhaustion, or other reasons (such as interface freezes or system black screens). In such cases, all functions that rely on the main control chip will be disabled. In current system architectures, the in-vehicle voice module is often integrated into the main control chip as a functional component. When the main control chip fails, the in-vehicle voice module will also disconnect and become unable to respond to user commands, causing users to lose the ability to proactively report faults or request assistance. Summary of the Invention

[0004] This application provides an anomaly handling method and vehicle, which uses an emergency voice module that operates independently of the main control chip to perform emergency voice interaction and trigger anomaly reporting when the chip malfunctions, thereby improving the timeliness and safety of anomaly handling.

[0005] In a first aspect, embodiments of this application provide an anomaly handling method, comprising: in response to an anomaly indication of the main control chip triggered by an emergency voice module, acquiring historical vehicle data; wherein the emergency voice module operates independently of the main control chip; sending an anomaly diagnosis request carrying the historical vehicle data to a server; and performing an anomaly handling operation on the main control chip based on an anomaly handling indication issued by the server for the historical vehicle data.

[0006] In some embodiments, the emergency voice module is associated with an emergency voice command set; the main control chip anomaly indication is triggered when the acoustic feature matching degree between the received user voice and any emergency voice command in the emergency voice command set is higher than a first matching degree threshold.

[0007] In some embodiments, the method further includes: in response to a voice confirmation instruction triggered by the emergency voice module, acquiring a voice to be identified; wherein the voice to be identified is user voice whose acoustic feature matching degree with at least one emergency voice command is between a second matching degree threshold and a first matching degree threshold; sending a semantic recognition request carrying the voice to be identified to the server; acquiring the semantic recognition result issued by the server for the voice to be identified, so that the emergency voice module triggers the main control chip abnormal indication when it determines that the semantic similarity between the semantic recognition result and any emergency voice command is higher than a similarity threshold.

[0008] In some embodiments, the anomaly handling instruction is generated by the server based on anomaly root cause data, which is obtained by the server after performing feature recognition on the historical vehicle data based on a trained anomaly diagnosis model; the anomaly handling instruction includes at least one of: lightweight restart, module restart, safe mode switching, or hardware reset.

[0009] In some embodiments, the method further includes: in response to an over-the-air download instruction issued by the server, obtaining software update data; wherein the software update data is determined based on the anomaly root cause data; and after detecting an anomaly recovery of the main control chip, performing a software update on the main control chip using the software update data.

[0010] In some embodiments, the method further includes: after the vehicle is powered on, storing the vehicle operation data generated by the vehicle into a designated cache area using a designated caching method; wherein the designated caching method includes at least one of: circular overlay cache, rolling overlay cache, and page rotation cache; the historical vehicle data includes: vehicle operation data stored in the designated cache area during historical periods, and system snapshot data of the vehicle.

[0011] In some embodiments, before sending the abnormal diagnosis request carrying the historical vehicle data to the server, the method further includes: determining that the main control chip meets preset abnormal conditions; wherein the preset abnormal conditions include: the heartbeat signal frequency of the main control chip is lower than a preset frequency threshold, and / or, the response delay of the main control chip is higher than a preset delay threshold.

[0012] In some embodiments, the method further includes: synchronizing the processing progress data of the exception handling operation to the user terminal during the execution of the exception handling operation; and, after detecting the abnormal recovery of the main control chip, displaying a processing completion prompt for the exception handling operation on the vehicle screen.

[0013] In some embodiments, the emergency voice module is a microcontroller unit with an independent power supply circuit and a designated communication interface for communicating with the vehicle communication terminal and / or the server; sending an anomaly diagnosis request carrying the historical vehicle data to the server includes sending the anomaly diagnosis request through the designated communication interface.

[0014] Secondly, embodiments of this application also provide an anomaly handling device, including: an anomaly detection unit configured to: acquire historical vehicle data in response to an anomaly indication from the main control chip triggered by an emergency voice module; wherein the emergency voice module operates independently of the main control chip; a diagnostic request unit configured to: send an anomaly diagnostic request carrying the historical vehicle data to a server; and an anomaly handling unit configured to: perform an anomaly handling operation on the main control chip based on an anomaly handling indication issued by the server for the historical vehicle data.

[0015] In some embodiments, the emergency voice module is associated with an emergency voice command set; the main control chip anomaly indication is triggered when the acoustic feature matching degree between the received user voice and any emergency voice command in the emergency voice command set is higher than a first matching degree threshold.

[0016] In some embodiments, the anomaly detection unit is further configured to: in response to a voice confirmation instruction triggered by the emergency voice module, acquire a voice to be identified; wherein the voice to be identified is user voice whose acoustic feature matching degree with at least one emergency voice command is between a second matching degree threshold and a first matching degree threshold; send a semantic recognition request carrying the voice to be identified to the server; acquire the semantic recognition result issued by the server for the voice to be identified, so that the emergency voice module triggers the main control chip anomaly indication when it determines that the semantic similarity between the semantic recognition result and any emergency voice command is higher than a similarity threshold.

[0017] In some embodiments, the anomaly handling instruction is generated by the server based on anomaly root cause data, which is obtained by the server after performing feature recognition on the historical vehicle data based on a trained anomaly diagnosis model; the anomaly handling instruction includes at least one of: lightweight restart, module restart, safe mode switching, or hardware reset.

[0018] In some embodiments, the exception handling unit is further configured to: obtain software update data in response to an over-the-air download instruction issued by the server; wherein the software update data is determined based on the exception root cause data; and after detecting the exception recovery of the main control chip, perform a software update on the main control chip using the software update data.

[0019] In some embodiments, the exception handling unit is further configured to: after the vehicle is powered on, store the vehicle operation data generated by the vehicle into a designated cache area using a designated caching method; wherein, the designated caching method includes at least one of: circular overlay cache, rolling overlay cache, and page rotation cache; the historical vehicle data includes: vehicle operation data stored in the designated cache area during historical periods, and system snapshot data of the vehicle.

[0020] In some embodiments, before executing the abnormal diagnostic request to send the historical vehicle data to the server, the diagnostic request unit is further configured to: determine that the main control chip meets preset abnormal conditions; wherein, the preset abnormal conditions include: the heartbeat signal frequency of the main control chip is lower than a preset frequency threshold, and / or, the response delay of the main control chip is higher than a preset delay threshold.

[0021] In some embodiments, the exception handling unit is further configured to: synchronize the processing progress data of the exception handling operation to the user terminal during the execution of the exception handling operation; and, after detecting the abnormal recovery of the main control chip, display a processing completion prompt for the exception handling operation on the vehicle screen.

[0022] In some embodiments, the emergency voice module is a microcontroller unit with an independent power supply circuit and a designated communication interface for communicating with the vehicle communication terminal and / or the server; it executes the sending of an abnormal diagnostic request carrying the historical vehicle data to the server, and the diagnostic request unit is specifically configured to send the abnormal diagnostic request through the designated communication interface.

[0023] Thirdly, embodiments of this application provide a vehicle including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any one of the first aspects.

[0024] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in any one of the first aspects.

[0025] Fifthly, embodiments of this application provide an electronic device, including: a memory for storing program instructions; and a processor for calling the program instructions stored in the memory and executing the steps included in the method described in any one of the first aspects according to the obtained program instructions.

[0026] In a sixth aspect, embodiments of this application provide a computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform the method described in any of the first aspects.

[0027] In this embodiment, historical vehicle data is acquired in response to an anomaly indication from the main control chip triggered by the emergency voice module. The emergency voice module operates independently of the main control chip. Because the emergency voice module does not depend on the operating state of the main control chip, it can still receive user voice commands and trigger anomaly indications even when the main control chip experiences serious malfunctions such as black screen or freezing, thus ensuring that the fault reporting channel remains available even in scenarios where the main system fails.

[0028] Subsequently, by sending an anomaly diagnosis request carrying historical vehicle data to the server, the server can perform remote analysis based on the actual fault scene information. Then, based on the anomaly handling instructions issued by the server for the historical vehicle data, it executes anomaly handling operations on the main control chip. This process utilizes an emergency voice module that operates independently of the main control chip. In the event of a chip malfunction, it provides emergency voice interaction and triggers anomaly reporting, all without requiring manual user intervention, effectively improving the timeliness and security of anomaly handling. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. The drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 The flowchart illustrates the overall process of the exception handling method provided in this application embodiment.

[0031] Figure 2 A schematic diagram of an emergency voice module provided in an embodiment of this application.

[0032] Figure 3 This is a schematic diagram of the exception handling instruction issuance process provided in the embodiments of this application.

[0033] Figure 4 This is a schematic diagram of the over-the-air download instruction issuance process provided in an embodiment of this application.

[0034] Figure 5 This is a structural block diagram of the exception handling device provided in the embodiments of this application.

[0035] Figure 6 A structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " will mean "or", for example, A / B can mean A or B; "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0037] In the description of the embodiments of this application, unless otherwise stated, the term "multiple" refers to two or more, and other quantifiers are similarly understood. The preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0038] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, more or fewer operation steps may be included in the method based on conventional or non-inventive effort. For steps that do not logically have a necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the control device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0039] As mentioned earlier, the main control chip may malfunction due to software errors, resource exhaustion, or other reasons (such as interface freezes or system black screens). In such cases, all functions that rely on the main control chip will be disabled. In current system architectures, the in-vehicle voice module is often integrated into the main control chip as a functional component. When the main control chip fails, the in-vehicle voice module will also disconnect and become unable to respond to user commands, causing users to lose the ability to proactively report faults or request assistance.

[0040] Specifically, the voice recognition engine, wake-up word detection, and command parsing logic of the in-vehicle voice module all run on the main control chip's operating system, sharing memory and audio driver resources. If the system process of the main control chip becomes blocked or the kernel crashes, the in-vehicle voice module will immediately fail due to the loss of its operating environment.

[0041] While some manufacturers address sudden main control chip failures by installing emergency buttons inside the vehicle, this method primarily triggers a forced system restart. A forced restart involves powering back the main control chip via the power management chip, a hardware-level reset. This process bypasses the operating system, therefore no log saving or network reporting is performed, and cached vehicle operation data (such as the process stack before the crash, system logs, user operation sequences, etc.) is cleared upon restart. This makes it impossible to trace the main control chip failure afterward and hinders targeted troubleshooting.

[0042] Furthermore, to avoid accidental button presses that force a restart, the emergency button requires specific operating procedures; for example, pressing and holding for 10 seconds or alternating between long and short presses. This not only requires users to understand the relevant operation of the emergency button, but also because operating the emergency button while driving may cause additional safety hazards.

[0043] In view of this, the inventive concept of this application embodiment is as follows: in response to the main control chip abnormality indication triggered by the emergency voice module, historical vehicle data is acquired; wherein, the emergency voice module operates independently of the main control chip. Since the emergency voice module does not depend on the operating state of the main control chip, even if the main control chip experiences serious failures such as black screen or freezing, it can still receive user voice commands and trigger abnormality indications, thereby ensuring that the fault reporting channel remains available in scenarios where the main system fails.

[0044] Subsequently, by sending an anomaly diagnosis request carrying historical vehicle data to the server, the server can perform remote analysis based on the actual fault scene information. Then, based on the anomaly handling instructions issued by the server for the historical vehicle data, it executes anomaly handling operations on the main control chip. This process utilizes an emergency voice module that operates independently of the main control chip. In the event of a chip malfunction, it provides emergency voice interaction and triggers anomaly reporting, all without requiring manual user intervention, effectively improving the timeliness and security of anomaly handling.

[0045] After introducing the inventive concept of the embodiments of this application, the following is a detailed description of an exception handling method provided by the embodiments of this application, as follows: Figure 1 As shown, it includes the following steps: Step S11: In response to the main control chip malfunction indication triggered by the emergency voice module, acquire historical vehicle data; wherein, the emergency voice module operates independently of the main control chip; To facilitate understanding, the emergency voice module of this application embodiment will be described first: Specifically, such as Figure 2As shown, the emergency voice module in this embodiment is a microcontroller unit (MCU) that operates independently of the main control chip. It has an independent power supply circuit and can be directly powered by the vehicle's constant power or backup power supply, without depending on the power status of the main control chip. Even if the main control chip stops working due to software crashes, resource exhaustion, or hardware malfunctions, this module can still maintain basic operating capabilities. Moreover, this emergency voice module does not run the vehicle's operating system and does not share the processor, bus, or peripheral resources of the main control chip; its hardware is completely isolated from the main control chip.

[0046] Continue as Figure 2 As shown, in some embodiments, the emergency voice module integrates a speech recognition engine, which is a lightweight offline speech recognition model (Automatic Speech Recognition, ASR) used to recognize emergency voices emitted by the user. The speech recognition process is completed locally within the emergency voice module, without requiring the main control chip's computing power or network services.

[0047] In addition, the emergency voice module is equipped with a designated communication interface, which connects to the vehicle-mounted communication terminal (T-box) or directly to a server. For example, in an implementation that establishes a connection with the vehicle-mounted communication terminal (T-box), the emergency voice module is connected to the T-box's independent communication controller via a low-speed serial communication bus. This communication controller operates outside the T-box's main control unit, possesses an independent protocol stack and data encapsulation capabilities, and can receive data packets from the emergency voice module without relying on the vehicle's main control chip operating system. It then encapsulates these packets into uplink messages conforming to vehicle network communication specifications and uploads them to the server via the T-box's built-in cellular communication module (such as a 4G / 5G module).

[0048] For example, in a direct server connection implementation, the emergency voice module integrates a streamlined communication protocol stack and physical layer interface, which can directly drive external or on-chip integrated wireless communication modules and establish an encrypted communication channel with the server through pre-configured secure access credentials. This communication channel is built on a lightweight transmission protocol, which supports reliable transmission of short messages under extremely low power consumption, ensuring that abnormal indications triggered by emergency voice commands can be delivered to the cloud platform in a timely manner.

[0049] In this way, regardless of whether a communication architecture is adopted via T-box relay or direct connection to the server, the designated communication interface built for the emergency voice module can bypass the application layer scheduling logic of the main control chip. Its data path is decoupled from the main control chip at both the physical and protocol layers. Therefore, when the main control chip experiences serious failures such as black screen, system crash, or kernel crash, the emergency voice module can still reliably transmit the main control chip's abnormal indication, the voice to be recognized, or subsequent control commands to the external system through this independent communication path. This ensures the availability and real-time performance of the fault reporting channel and prevents users from losing their ability to actively seek help or conduct remote diagnostics due to the failure of the main system.

[0050] Next, we will explain how the emergency voice module in this embodiment triggers the main control chip's abnormal indication: In some embodiments, the emergency voice module of this application is associated with an emergency voice command set, which includes multiple pre-set emergency voice commands. After receiving user voice, the emergency voice module can perform acoustic feature matching between the user voice and each emergency voice command in the emergency voice command set. When the acoustic feature matching degree between the user voice and any emergency voice command is higher than a first matching degree threshold, the main control chip is triggered to malfunction.

[0051] Specifically, the lightweight offline speech recognition engine integrated within the emergency voice module is in a low-power listening state after the vehicle is powered on. This engine runs based on a locally stored acoustic template library, which is generated offline from each instruction in the aforementioned emergency voice command set. Each instruction corresponds to a set of high-dimensional acoustic feature vectors, which are stored in the non-volatile memory of the emergency voice module.

[0052] The emergency voice commands in this application embodiment can be set based on actual needs, and are used to enable users to quickly initiate corresponding emergency operations through natural voice when the vehicle's main system experiences abnormalities such as black screen or freezing. For example, emergency voice commands include, but are not limited to: "upload abnormality", "emergency help", and "restart vehicle system".

[0053] Among them, "Upload Anomaly" is used to proactively report fault data for remote diagnosis when the vehicle's infotainment system malfunctions but driving safety is not affected; "Emergency Assistance" is used to trigger emergency contact with customer service or roadside assistance when the user perceives a driving safety hazard or requires manual intervention; and "Restart Vehicle Infotainment System" is used when the user determines the problem is a temporary software lag and wishes to immediately try to restore the vehicle's infotainment system. Users can issue corresponding voice commands based on the actual abnormal scenario they encounter, which will be recognized by the emergency voice module.

[0054] When a user speaks, the vehicle microphone sends an analog voice signal to the emergency voice module via an independent audio input channel. The emergency voice module performs analog-to-digital conversion, noise reduction, and gain control through its audio front-end circuitry. It then extracts the real-time acoustic features of the current voice segment and matches them against each emergency voice command template in the aforementioned acoustic template library. If the acoustic feature matching degree between the user's voice and any emergency voice command is higher than a first matching degree threshold, the user's voice is determined to have effectively matched the emergency voice command set. At this point, the emergency voice module immediately triggers an anomaly indication to the vehicle's main control chip.

[0055] Among them, the acoustic feature matching degree refers to the degree of similarity between the user's voice and the emergency voice command at the acoustic level. Its specific calculation method can be set based on actual business needs. For example, algorithms such as dynamic time warping (DTW) distance calculation and cosine similarity ratio can be used for acoustic feature matching. This application does not limit this.

[0056] It should be noted that the emergency voice module runs on an independent MCU, which has limited computing power, storage capacity and power consumption budget. If the general voice model deployed in the traditional vehicle voice system is used, it will not only fail to adapt to the resource constraints of the MCU, but will also be difficult to meet the real-time requirements in emergency scenarios due to the high complexity of the model and the large inference latency.

[0057] Therefore, the embodiments of this application deliberately streamline the emergency voice command set to a high degree, for example, containing only 3 to 5 high-priority commands. By limiting the number of commands and generating corresponding acoustic templates based on offline training, the entire acoustic template library can be compressed to the tens of KB level, perfectly adapting to the non-volatile storage space and running memory of the emergency voice module. At the same time, the matching process only requires lightweight acoustic feature comparison within a very small set of templates, significantly reducing recognition complexity and processing latency. More importantly, this design avoids a high false trigger rate caused by semantically similar commands or environmental noise interference, ensuring that in an emergency state where the main control chip fails, it only responds to clear and high-confidence emergency intentions, thus balancing recognition efficiency and security under resource-constrained conditions.

[0058] In the event of a main control chip malfunction, the user can still issue a voice command to the emergency voice module for recognition and to trigger a main control chip malfunction indication to the vehicle. This mechanism is entirely completed independently by the emergency voice module, without relying on any function of the main control chip. This avoids the safety risks associated with operating physical buttons in traditional solutions, while ensuring that data reporting and subsequent processing can still be initiated even when the main control chip fails. This significantly improves the emergency response capability of the vehicle terminal under abnormal operating conditions.

[0059] Specifically, while some manufacturers address sudden main control chip malfunctions by installing emergency buttons inside the vehicle, triggering these buttons requires specific procedures to avoid accidental button presses and forced restarts; for example, pressing and holding for 10 seconds or alternating between long and short presses. This not only requires users to understand the operation of the emergency button but also poses additional safety hazards when operating it while driving. The aforementioned process, however, integrates a lightweight offline voice recognition engine into the emergency voice module and performs real-time acoustic feature matching on a highly streamlined set of emergency voice commands based on a locally stored acoustic template library. This eliminates the need to wait for network responses or main control chip scheduling, significantly reducing the processing latency from when the user issues a voice command to when the main control chip indicates an malfunction. Since all recognition logic is completed within an independent MCU, and the acoustic template library contains only 3-5 high-priority emergency voice commands, the matching process can be completed within milliseconds, a response speed far faster than physical emergency buttons that require multiple steps.

[0060] Furthermore, considering that vehicles often operate in complex acoustic environments, the clarity or signal-to-noise ratio of user speech may be low. Relying solely on a lightweight offline speech recognition engine for acoustic feature matching may lead to missed triggers or misjudgments. Therefore, this application also introduces a cloud-based collaborative semantic verification mechanism to improve the accuracy of user speech recognition.

[0061] In some embodiments, in response to a voice confirmation instruction triggered by an emergency voice module, the system may acquire the voice to be recognized; send a semantic recognition request carrying the voice to be recognized to the server; and acquire the semantic recognition result issued by the server for the voice to be recognized, so that the emergency voice module triggers an abnormal indication from the main control chip when it determines that the semantic similarity between the semantic recognition result and any emergency voice instruction is higher than the similarity threshold.

[0062] The speech to be identified is the acoustic feature matching degree between the speech and at least one emergency voice command, and the user speech between the second matching degree threshold and the first matching degree threshold; for example, if the first matching degree threshold is 85% and the second matching degree threshold is 65%, then user speech with an acoustic feature matching degree between 65% and 85% can be considered as the speech to be identified. It should be understood that the specific data of the above matching degree threshold can be set based on actual business needs, and this application does not limit it in this regard.

[0063] Specifically, after the emergency voice module performs acoustic feature matching on the user's voice, if the matching degree does not reach a high first matching degree threshold but exceeds a moderate second matching degree threshold, it indicates that the user's voice is likely an emergency voice. At this point, the emergency voice module can use the user's voice as the voice to be recognized and generate a voice confirmation instruction, temporarily storing the voice to be recognized. Subsequently, the vehicle can upload the voice to be recognized to the server to initiate a semantic recognition request.

[0064] As mentioned earlier, the emergency voice module in this embodiment of the application has the ability to communicate with the vehicle-mounted communication terminal. Therefore, the emergency voice module can connect to the vehicle-mounted communication terminal through the integrated communication interface, directly upload the voice to be recognized to the server of the vehicle network platform, and initiate a semantic recognition request.

[0065] Furthermore, considering hardware cost and power consumption optimization, in some embodiments, the emergency voice module may not directly undertake network transmission tasks. In this case, the emergency voice module can transmit the voice to be recognized and the voice confirmation instruction to the vehicle via a low-speed serial bus, and the vehicle is responsible for constructing and sending a semantic recognition request carrying the voice to be recognized to the server. This design further reduces the hardware complexity and power consumption of the emergency voice module while ensuring functional integrity.

[0066] After receiving the speech to be recognized, the server uses its high-precision speech recognition model and Natural Language Understanding (NLU) engine to convert the speech into text and parse its semantic intent, generating a structured semantic recognition result, which is then returned to the emergency speech module. The emergency speech module performs semantic similarity calculations on this result against each instruction in a preset emergency speech command set. If the semantic similarity between any emergency speech command and the semantic recognition result exceeds a preset similarity threshold, an anomaly indication is triggered on the main control chip.

[0067] In this way, user speech with an acoustic matching degree within a specific range is uploaded to the server as the speech to be recognized, and semantic recognition is performed using a high-precision speech model on the server side. For user speech in complex acoustic environments, the system can accurately determine the true intent of the user and reliably trigger abnormal indications from the main control chip, thereby improving the accuracy and availability of emergency response from the vehicle terminal.

[0068] In this embodiment, a designated cache area is pre-set. After the vehicle is powered on, the vehicle operation data generated during vehicle operation can be stored in the designated cache area using the designated caching method. After the emergency voice module triggers an abnormal indication of the main control chip, the vehicle will respond to the indication by retrieving historical vehicle data, which is the vehicle operation data stored in the designated cache area during the historical period, as well as the vehicle's system snapshot data.

[0069] Specifically, the designated cache is actively managed by the main control chip during normal operation. Before the main control chip malfunctions, it will continuously write critical data generated during vehicle operation (such as system logs, process status, bus communication records, user interaction events, etc.) into the designated cache according to a preset strategy, thereby achieving dynamic backup of the operating context.

[0070] The specified caching methods in this application include at least one of: circular overlay caching, rolling overlay caching, and paged rotation caching. These caching methods can prioritize retaining the runtime context within a limited storage space, ensuring that critical data before a failure is prematurely deleted.

[0071] Taking a circular overlay buffer as an example, the main control chip continuously writes real-time vehicle operation data sequentially into a designated buffer area during vehicle operation. When the buffer area is full, new data automatically overwrites the earliest written data, forming a circular buffer structure. Thus, the designated buffer area always stores continuous operation data from the most recent few minutes (e.g., 5 minutes).

[0072] When the emergency voice module triggers an anomaly indication from the main control chip, this indication is sent to the vehicle communication terminal via a hardware interrupt signal or a low-speed communication bus. Upon receiving this indication, the vehicle can read the vehicle operation data stored in the historical time period from a designated buffer. Furthermore, to improve the accuracy of anomaly handling, system snapshot data can be generated based on currently collectable low-level hardware status parameters (such as power domain status, peripheral enable flags, CAN bus activity records, etc.). The vehicle operation data and system snapshot data will be read from the designated buffer and used together as historical vehicle data.

[0073] It should be understood that the amount of data read from the specified cache can be set based on actual needs. For example, all vehicle operation data in the specified cache can be read, or vehicle operation data cached in the last few minutes can be read. This application does not limit this.

[0074] Furthermore, the designated cache area is configured in the system architecture as a shared storage area accessible to both the main control chip and the vehicle communication terminal. During normal operation of the main control chip, it is responsible for continuously writing real-time vehicle operation data into this area; after the main control chip malfunctions, the vehicle communication terminal can bypass the main control chip and directly read the cached data from this area. This design enables the designated cache area to essentially serve as a temporary storage and relay for abnormal situation data, ensuring that the fault context can still be reliably extracted after the main control chip fails. Because the designated cache area is physically designed to support independent access by the vehicle communication terminal, even if the main control chip is in a black screen, frozen, or unresponsive state, the vehicle can still directly obtain the critical operating context before the fault occurred without relying on any function of the main control chip.

[0075] Through the above process, after the emergency voice module triggers the main control chip abnormality indication, it can automatically obtain the vehicle operation data and hardware status before the main control chip abnormality occurred. This eliminates the need for manual operation by the user or reliance on the main control chip's response capability in abnormal conditions, thus avoiding the problem of data failure to be reported due to main control chip abnormality.

[0076] Step S12: Send an anomaly diagnosis request carrying the historical vehicle data to the server; After obtaining historical vehicle data, the vehicle can construct an anomaly diagnosis request based on the historical vehicle data and send the request to the server of the vehicle network platform through the independent communication link of the station communication terminal.

[0077] Specifically, in this application embodiment, the communication between the vehicle-mounted communication terminal and the server does not rely on the network protocol stack or operating system service of the main control chip, but is completed through the communication module (such as 4G / 5G module) integrated by the vehicle-mounted communication terminal itself and the independently running lightweight transmission protocol.

[0078] The anomaly diagnosis request can be encapsulated using a lightweight transmission protocol to ensure the security and reliability of data transmission. Furthermore, the anomaly diagnosis request can employ a custom secure message format, combined with device authentication and data integrity verification mechanisms, to achieve low-latency reporting. It should be understood that the specific type of communication protocol can be set based on actual business needs, and this application does not impose any limitations on it.

[0079] Furthermore, considering that users may unintentionally utter similar emergency voice commands due to mispronunciation, environmental noise, or non-emergency scenarios, false reports are likely to occur.

[0080] To avoid unnecessary data reporting and system intervention due to voice misrecognition, in some embodiments, before sending an anomaly diagnosis request carrying historical vehicle data to the server, it is pre-determined that the main control chip meets preset anomaly conditions; wherein, the preset anomaly conditions include: the heartbeat signal frequency of the main control chip is lower than a preset frequency threshold, and / or, the response delay of the main control chip is higher than a preset delay threshold.

[0081] Specifically, after receiving an anomaly indication from the main control chip triggered by the emergency voice module, the vehicle-mounted communication terminal does not immediately construct and send an anomaly diagnosis request. Instead, it first detects the current operating status of the main control chip via a low-speed communication bus. During normal operation, the main control chip periodically sends a heartbeat signal to the vehicle-mounted communication terminal. This signal is used to characterize the activity of its operating system scheduler and critical services. If the vehicle-mounted communication terminal does not receive a heartbeat signal for several consecutive detection cycles, or if the interval between received heartbeat signals significantly exceeds the normal range (for example, the normal heartbeat cycle is 1 second, but the measured interval is consistently greater than 5 seconds), then it is determined that the heartbeat signal frequency of the main control chip is lower than a preset frequency threshold.

[0082] Simultaneously, the vehicle-mounted communication terminal can proactively send lightweight status query commands to the main control chip and record its response time. If the main control chip does not return a valid response within a preset timeout window, or if the response delay consistently exceeds a preset delay threshold (e.g., 2 seconds), its response capability is deemed severely degraded. Only when any of the above preset abnormal conditions is met does the vehicle-mounted communication terminal confirm that the main control chip is indeed in an abnormal state. Based on this confirmation, it reads historical vehicle data from a designated cache, constructs an abnormal diagnosis request, and sends it to the server.

[0083] In this way, after an emergency voice command is triggered, it can be verified in conjunction with the actual operating status of the main control chip, effectively avoiding invalid data reporting caused by voice misrecognition or misoperation in non-abnormal scenarios; by only initiating the reading of historical vehicle data and sending of abnormal diagnosis requests when it is confirmed that the main control chip does meet the preset abnormal conditions, the accuracy of the abnormal reporting mechanism and the efficiency of system resource utilization are improved.

[0084] Step S13: Based on the anomaly handling instruction issued by the server for the historical vehicle data, perform anomaly handling operation for the main control chip.

[0085] The server in this embodiment can automatically complete anomaly diagnosis based on the received historical vehicle data and generate anomaly handling instructions to guide the vehicle terminal to perform emergency operations.

[0086] The exception handling instructions in this embodiment are generated by the server based on exception root cause data. These instructions include at least one of the following: lightweight reboot, module reboot, safe mode switching, or hardware reset. The exception root cause data is obtained by the server after performing feature recognition on historical vehicle data based on a trained exception diagnosis model.

[0087] For ease of understanding, the specifics are as follows: Figure 3 As shown: The server in this embodiment of the application is equipped with a trained anomaly diagnostic model, hereinafter referred to as the diagnostic model. This diagnostic model is trained based on a large number of historical vehicle anomaly samples and can identify the core root causes of main control chip anomalies from multi-dimensional historical vehicle data such as system logs, CAN bus communication anomaly frames, memory usage trends, process states, and system snapshot data. After receiving an anomaly diagnostic request carrying historical vehicle data, the server pre-decrypts and verifies the integrity of the request. After the verification is successful, the historical vehicle data is input into the diagnostic model, and the model outputs structured anomaly root cause data.

[0088] The abnormal root cause data in this application embodiment is used to characterize the structured diagnostic results of the abnormal essential characteristics of the main control chip, including but not limited to the abnormal type, abnormal cause and event level that caused the abnormality of the main control chip.

[0089] The event level characterizes the current extent of damage to the main control chip and its functional availability. The anomaly type identifies the technical category to which the main control chip anomaly belongs, such as kernel crash, unresponsive critical applications, or memory exhaustion. The anomaly cause characterizes the specific technical factors that triggered the main control chip anomaly, such as timeout triggering a restart or a kernel process being terminated due to insufficient memory (OOM). The event level quantifies the severity of the main control chip anomaly and its impact on vehicle functionality.

[0090] In this embodiment, the event level is divided into four levels from high to low according to the degree of impact on driving safety: Level 1 indicates a hardware-level failure that endangers driving safety and requires immediate stopping; Level 2 indicates a kernel crash of the main control chip or an anomaly in a critical application, but safety-related systems such as power, chassis, and braking are still operating normally and can be remotely restored; Level 3 indicates a lag or service interruption in a non-critical application, which does not affect the core vehicle system functions; and Level 4 indicates a slight performance degradation or occasional log alarms, which do not require active intervention.

[0091] In some embodiments, the server presets a corresponding hierarchical exception handling strategy for each event level, automatically determines the corresponding handling action based on the event level in the exception root cause data, and generates exception handling instructions accordingly.

[0092] Specifically, when the event level is Level 1, since the main control chip malfunction has affected the vehicle's basic driving safety, the server can generate an exception handling instruction instructing the vehicle to perform a hardware reset to restore the underlying hardware functions and ensure driving safety. When the event level is Level 2, since the main control chip has crashed but the vehicle's safety-related systems are still functioning normally, the server can generate an exception handling instruction instructing the vehicle to perform a module restart to restart the main control chip and its upper-layer applications, restoring the vehicle's infotainment system functions. When the event level is Level 3, since the anomaly only affects non-critical services, the server can generate an exception handling instruction instructing the vehicle to switch to safe mode to maintain basic human-machine interaction. When the event level is Level 4, since the anomaly is minor and has the potential for self-recovery, the server can generate an exception handling instruction instructing the vehicle to perform a lightweight restart, restarting only the relevant application processes without affecting the overall system operation, thereby completing the anomaly recovery with minimal disruption.

[0093] After generating an anomaly diagnostic instruction, the server sends it to the vehicle, instructing the vehicle to perform corresponding anomaly handling operations for the main control chip. This allows the server to automatically perform intelligent diagnosis of historical vehicle data based on a data reporting mechanism triggered by emergency voice commands after a main control chip malfunctions. The server then accurately matches the appropriate emergency response strategy based on the event level in the diagnostic results, generating corresponding anomaly handling instructions and sending them to the vehicle. The entire process requires no manual intervention, avoiding the loss of fault information due to main control chip failure and achieving end-to-end automation from anomaly identification and tiered judgment to remote recovery.

[0094] It should be noted that the abnormal handling operation for the main control chip in this embodiment is not executed by the main control chip itself, but is implemented by the vehicle communication terminal in coordination with the vehicle's underlying hardware control unit after receiving the abnormal handling instruction issued by the server.

[0095] Specifically, a dedicated control channel is provided between the vehicle-mounted communication terminal and the vehicle's power management unit (PMU) or reset control circuit. When the server issues an exception handling instruction of "hardware reset," the vehicle-mounted communication terminal sends a reset command to the PMU through this control channel. The PMU then performs a power-off and power-on operation on the main control chip, achieving a hardware-level restart. When the exception handling instruction is "module restart," the vehicle-mounted communication terminal outputs a valid reset signal to the main control chip's reset pin via a low-speed communication bus, thereby forcing the main control chip to reinitialize. When the exception handling instruction is "safe mode switch" or "lightweight restart," the main control chip has limited response capabilities (e.g., only the application layer is stuck while the kernel is still schedulable). The vehicle-mounted communication terminal can send a mode switch or process restart instruction to the main control chip's operating system daemon service through a preset local inter-process communication mechanism, which then internally executes the corresponding recovery action.

[0096] The aforementioned exception handling operations are all executed by the vehicle communication terminal and its coupled underlying hardware control unit, and their control logic is independent of the main control chip's operating state. Even if the main control chip is completely unresponsive, has a black screen, or has a kernel crash, as long as the vehicle power system is normal and the vehicle communication terminal remains operational, the main control chip can undergo multi-granularity recovery operations, from process-level restart to hardware-level reset, based on the exception handling instructions issued by the server.

[0097] To support subsequent fault tracing and system optimization, the server in this application also includes an automatic ticket generation module. This module generates standardized work orders based on root cause data and historical vehicle data reported by the current vehicle during anomaly diagnosis by the diagnostic model. The work order may include information such as the Vehicle Identification Number (VIN), vehicle model, software version, fault occurrence time, geographical location, vehicle speed, complete historical vehicle data package, and diagnostic conclusions (i.e., anomaly handling instructions) issued by the server.

[0098] The server can synchronize work orders to the vehicle manufacturer's repair system based on this automatic ticketing module, and perform in-depth machine or manual verification of the work order content. This verification operation involves matching the current anomaly root cause data with a pre-built defect knowledge base. This defect knowledge base can store anomaly repair records corresponding to historical anomaly root cause data. These anomaly repair records can include the specific repair method and the identifier ID of the software update data used for the repair.

[0099] For ease of understanding, the specifics are as follows: Figure 4 As shown: Suppose a vehicle triggers the emergency voice command "Upload Anomaly" due to a main control chip malfunction. The vehicle communication terminal then reports historical vehicle data, including system logs, CAN bus records, and hardware snapshots, to the server. After analysis by the diagnostic model, the server outputs the root cause data of the anomaly as follows: "Anomaly Type: Critical Application Unresponsive, Anomaly Cause: Navigation Application Memory Leak Leading to Main Control Chip Malfunction, Event Level: Level 2".

[0100] The root cause data of this anomaly can be used by the automatic ticketing module to generate standardized work orders, which are then synchronized to the vehicle manufacturer's repair system. Subsequently, the content of this work order is matched against anomaly repair records stored in the defect knowledge base. For example, the defect knowledge base contains an anomaly repair record: "The navigation application had a memory leak issue in versions 1 and below, which has been fixed in version 2. The fix was to optimize the map cache release logic, and the identifier ID of the associated software update data (e.g., OTA upgrade package) is 123."

[0101] If the verification results indicate that the software version currently running on the vehicle is lower than the target version mentioned in the repair log, an over-the-air (OTA) download instruction can be generated and sent to the corresponding vehicle. Continue as follows... Figure 4 As shown, assuming that after comparing the current vehicle's software version and confirming that it is lower than the target version, the server can generate an over-the-air download instruction containing the version number of the target version (i.e., the aforementioned version 2) and the identifier ID of the software update data package.

[0102] In some embodiments, the vehicle may obtain software update data in response to an over-the-air download instruction issued by the server; this software update data is determined by the server based on anomaly root cause data. Thus, after detecting a recovery from an anomaly in the main control chip, the vehicle can use this software update data to update the main control chip's software, thereby preventing future anomalies.

[0103] For ease of understanding, the above will still be used. Figure 4 For example: After the server sends an over-the-air (OTA) download instruction to the vehicle, the vehicle can respond to the OTA download instruction. After the main control chip recovers from the malfunction, the specific content of the OTA download instruction will be displayed to the user through the vehicle's infotainment system. The user can choose to update immediately, schedule an update time, or not process it for the time being based on actual needs.

[0104] If the user confirms the update of the main control chip, the vehicle can download the corresponding software update data package from the server based on the identifier ID, and perform integrity verification and digital signature verification on the software data package. After successful verification, the vehicle can hand over the update task to the OTA management module of the main control chip, and complete the differential or full upgrade when the system is idle or during the next startup. This ensures that the main control chip is updated in a normal working state after an anomaly recovery, avoiding interference with the normal operation of the vehicle.

[0105] Therefore, by linking the abnormal diagnosis results with the software update mechanism, after the vehicle completes the abnormal recovery, it can repair the software defects that caused the abnormality based on the software update data issued by the server, and then fundamentally repair the abnormality of the main control chip to prevent the same abnormality from happening again, thereby improving the user's driving experience.

[0106] It should be understood that the over-the-air download instruction in this application embodiment is not the same as the aforementioned exception handling instruction. The exception handling instruction issued by the server is used to inform the vehicle how to restore the main control chip from its current abnormal state to a normal working state, while the over-the-air download instruction issued by the server is used to inform the vehicle that the abnormal problem caused by the main control chip can be eradicated through a software update.

[0107] In some embodiments, during the abnormal handling operation of the main control chip, the processing progress data of the abnormal handling operation can be synchronized to the user terminal; and after the abnormal recovery of the main control chip is detected, a processing completion prompt for the abnormal handling operation is displayed on the vehicle screen.

[0108] Specifically, during the abnormal handling operation of the main control chip, the vehicle communication terminal can synchronize the processing progress data corresponding to the abnormal handling operation to the user terminal (such as the bound mobile APP) in real time through the vehicle networking platform. This processing progress data can be generated based on the abnormal handling instruction type and preset execution sequence issued by the server, and is used to transparently provide feedback on the current recovery status to the user, avoiding user misjudgment or anxiety due to the unresponsive vehicle interface.

[0109] After detecting status information that indicates the abnormal recovery of the main control chip, such as the main control chip re-establishing its heartbeat signal or the normal startup of critical service processes, a processing completion prompt can be displayed on the vehicle screen to inform the user that they can drive the vehicle normally.

[0110] Furthermore, after the main control chip recovers from an anomaly, the processing log of this anomaly handling operation can be displayed to the user. This processing log can record information such as the time of the anomaly occurrence, the event level, the anomaly type, the anomaly handling instructions executed by the vehicle (such as "module restart"), the processing time, and whether a software update recommendation has been triggered.

[0111] The anomaly type, cause, and event level are derived from the root cause data returned by the server, while the processing time is obtained locally from the vehicle communication terminal. The completion notification is presented in a structured format, providing users with clear and traceable fault handling instructions, thus enhancing system transparency and user trust.

[0112] This allows for real-time progress feedback to users during the handling of main control chip anomalies, and displays structured processing records after the anomaly is resolved. This effectively alleviates user concerns caused by the vehicle's unresponsive infotainment system, enhances the transparency and traceability of the fault handling process, and improves the human-machine interaction experience and the user's driving experience.

[0113] Based on the same inventive concept, this application also provides an exception handling device 500, which can, as follows: Figure 5 As shown, it includes: The anomaly detection unit 501 is configured to: acquire historical vehicle data in response to an anomaly indication from the main control chip triggered by the emergency voice module; wherein the emergency voice module operates independently of the main control chip; The diagnostic request unit 502 is configured to send an abnormal diagnostic request carrying the historical vehicle data to the server. The exception handling unit 503 is configured to perform exception handling operations on the main control chip based on the exception handling instructions issued by the server for the historical vehicle data.

[0114] In some embodiments, the emergency voice module is associated with an emergency voice command set; the main control chip anomaly indication is triggered when the acoustic feature matching degree between the received user voice and any emergency voice command in the emergency voice command set is higher than a first matching degree threshold.

[0115] In some embodiments, the anomaly detection unit 501 is further configured to: in response to a voice confirmation instruction triggered by the emergency voice module, acquire a voice to be identified; wherein the voice to be identified is user voice whose acoustic feature matching degree with at least one emergency voice command is between a second matching degree threshold and a first matching degree threshold; send a semantic recognition request carrying the voice to be identified to the server; acquire the semantic recognition result issued by the server for the voice to be identified, so that the emergency voice module triggers the main control chip anomaly indication when it determines that the semantic similarity between the semantic recognition result and any emergency voice command is higher than a similarity threshold.

[0116] In some embodiments, the anomaly handling instruction is generated by the server based on anomaly root cause data, which is obtained by the server after performing feature recognition on the historical vehicle data based on a trained anomaly diagnosis model; the anomaly handling instruction includes at least one of: lightweight restart, module restart, safe mode switching, or hardware reset.

[0117] In some embodiments, the exception handling unit 503 is further configured to: obtain software update data in response to an over-the-air download instruction issued by the server; wherein the software update data is determined based on the exception root cause data; and after detecting the exception recovery of the main control chip, perform a software update on the main control chip using the software update data.

[0118] In some embodiments, the exception handling unit 503 is further configured to: after the vehicle is powered on, store the vehicle operation data generated by the vehicle into a designated cache area using a designated caching method; wherein, the designated caching method includes at least one of: circular overlay cache, rolling overlay cache, and page rotation cache; the historical vehicle data includes: vehicle operation data stored in the designated cache area during historical periods, and system snapshot data of the vehicle.

[0119] In some embodiments, before executing the abnormal diagnostic request to send the historical vehicle data to the server, the diagnostic request unit 502 is further configured to: determine that the main control chip meets preset abnormal conditions; wherein, the preset abnormal conditions include: the heartbeat signal frequency of the main control chip is lower than a preset frequency threshold, and / or, the response delay of the main control chip is higher than a preset delay threshold.

[0120] In some embodiments, the exception handling unit 503 is further configured to: synchronize the processing progress data of the exception handling operation to the user terminal during the execution of the exception handling operation; and, after detecting the abnormal recovery of the main control chip, display a processing completion prompt for the exception handling operation on the vehicle screen.

[0121] In some embodiments, the emergency voice module is a microcontroller unit with an independent power supply circuit and a designated communication interface for communicating with the vehicle communication terminal and / or the server; the diagnostic request unit 502 is specifically configured to send the abnormal diagnostic request carrying the historical vehicle data to the server through the designated communication interface.

[0122] Figure 6 An exemplary structural block diagram of the aforementioned electronic device is shown. Figure 6 As shown, the electronic device 600 may include at least one of the following: a tuner / demodulator 601, a communicator 602, a detector 603, an external device interface 604, a processor 605, a display 606, an audio output interface 607, a memory 608, a power supply 609, and a user interface 610.

[0123] In some embodiments, processor 605 includes at least one of: a central processing unit (CPU), a video processor, an audio processor, a graphics processing unit (GPU), RAM (randomaccess memory), ROM (read-only memory), a first to an nth interface for input / output, a communication bus, etc.

[0124] The display 606 includes a display screen assembly for presenting images, a driving assembly for driving image display, a component for receiving image signals from the processor, and a user interface for displaying video content, image content, menu control interface, and user control UI.

[0125] The display 606 can be a liquid crystal display, an organic light-emitting diode (OLED) display, or a projection display, etc.

[0126] The communicator 602 is a component used to communicate with external devices or servers according to various communication protocol types. For example, the communicator may include at least one of the following: a Wi-Fi module, a Bluetooth module, a wired Ethernet module, other network communication protocol chips or near-field communication protocol chips, and an infrared receiver. The electronic device 600 can use the communicator 602 to send and receive control signals and data signals with the control device or server.

[0127] The user interface can be used to receive control signals input by the user through a control device (such as an infrared remote control) or by touch or gesture.

[0128] Detector 603 can be used to acquire signals from the external environment or to interact with the external environment. For example, detector 603 may include a light receiver, which can be used to acquire ambient light intensity; or, detector 603 may include an image acquisition device, such as a camera, which can be used to acquire external environmental scenes, user attributes, or user interaction gestures; or, detector 603 may include a sound acquisition device, such as a microphone, for receiving external sounds.

[0129] The external device interface 604 may include, but is not limited to, one or more of the following: High-Definition Multimedia Interface (HDMI), analog or high-definition component input interface (component), Composite Video Broadcast Signal (CVBS), Universal Serial Bus (USB), RGB (Red, Green, Blue) port, etc. It may also be a composite input / output interface formed by multiple of the above interfaces.

[0130] The tuner / demodulator 601 receives broadcast television signals via wired or wireless means, and demodulates audio and video signals, such as EPG data signals, from multiple wireless or wired broadcast television signals. In some embodiments, the processor 605 and the tuner / demodulator 601 may be located in different separate devices; that is, the tuner / demodulator 601 may also be located in an external device of the main device where the processor 605 is located, such as an external set-top box.

[0131] Processor 605 controls the operation of the electronic device and responds to user operations through various software control programs stored in memory. Processor 605 controls the overall operation of electronic device 600. For example, in response to receiving a user command to select a UI object to display on display 606, processor 605 can execute operations related to the object selected by the user command.

[0132] This application also provides a vehicle, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can be used to perform the above-described exception handling method.

[0133] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a computing device, the computing device implements the above-described exception handling method.

[0134] Various aspects of the exception handling method provided in the embodiments of this application can also be implemented in the form of a program product, which includes a computer program. When the program product is run on an electronic device, the computer program is used to cause the electronic device to perform the steps in the exception handling method according to the various exemplary embodiments of this application described above.

[0135] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0136] The program product of the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include a computer program, and may run on an electronic device. It should be understood that the program product of this application is not limited thereto. In this application, the readable storage medium may be any tangible medium that contains or stores a program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0137] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with a command execution system, apparatus, or device.

[0138] Computer programs contained on readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0139] Computer programs for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The computer program can execute entirely on the viewer's local electronic device, partially on the viewer's local electronic device, as a standalone software package, partially on the local electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the electronic device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0140] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0141] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0142] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing a computer-usable computer program.

[0143] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0144] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An abnormality processing method characterized by comprising: include: In response to an anomaly indication from the main control chip triggered by the emergency voice module, historical vehicle data is acquired; wherein, the emergency voice module operates independently of the main control chip; Send an anomaly diagnosis request carrying the historical vehicle data to the server; Based on the anomaly handling instructions issued by the server for the historical vehicle data, anomaly handling operations are performed on the main control chip.

2. The method of claim 1, wherein, The emergency voice module is associated with an emergency voice command set; the main control chip anomaly indication is triggered when the acoustic feature matching degree between the received user voice and any emergency voice command in the emergency voice command set is higher than a first matching degree threshold.

3. The method of claim 2, wherein, The method further includes: In response to a voice confirmation instruction triggered by the emergency voice module, the voice to be identified is acquired; wherein, the voice to be identified is the user voice whose acoustic feature matching degree with at least one emergency voice command is located between a second matching degree threshold and a first matching degree threshold. Send a semantic recognition request carrying the speech to be recognized to the server; The semantic recognition result issued by the server for the speech to be recognized is obtained, so that when the semantic similarity between the semantic recognition result and any emergency voice command is higher than the similarity threshold, the emergency voice module triggers the main control chip abnormal indication.

4. The method of claim 1, wherein, The anomaly handling instruction is generated by the server based on the anomaly root cause data, which is obtained by the server after performing feature recognition on the historical vehicle data based on a trained anomaly diagnosis model. The exception handling instructions include at least one of the following: lightweight reboot, module reboot, safe mode switching, or hardware reset.

5. The method of claim 4, wherein, The method further includes: In response to an over-the-air download instruction issued by the server, software update data is obtained; wherein the software update data is determined based on the anomaly root cause data; After detecting the abnormal recovery of the main control chip, the main control chip is updated using the software update data.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: After the vehicle is powered on, the vehicle operation data generated by the vehicle is stored in the designated cache area using a designated caching method; The historical vehicle data includes: vehicle operation data stored in the designated cache area during historical periods, and system snapshot data of the vehicles; the designated caching method includes at least one of: circular overlay cache, rolling overlay cache, and paged rotating cache.

7. The method according to any one of claims 1 to 5, characterized in that, Before sending the anomaly diagnosis request carrying the historical vehicle data to the server, the method further includes: The main control chip is determined to meet preset abnormal conditions; The preset abnormal conditions include: the heartbeat signal frequency of the main control chip is lower than a preset frequency threshold, and / or the response delay of the main control chip is higher than a preset delay threshold.

8. The method of any one of claims 1-5, wherein, The method further includes: During the execution of the exception handling operation, the processing progress data of the exception handling operation is synchronized to the user terminal; and after the exception recovery of the main control chip is detected, a processing completion prompt for the exception handling operation is displayed on the vehicle screen.

9. The method of any one of claims 1-5, wherein, The emergency voice module is a microcontroller unit with an independent power supply circuit and a designated communication interface for communicating with the vehicle-mounted communication terminal and / or the server. Sending an anomaly diagnosis request carrying the historical vehicle data to the server includes: The anomaly diagnosis request is sent through the specified communication interface.

10. A vehicle characterized by comprising: The vehicle includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method of any one of claims 1-8.

Images