A fault identification method, device and electronic equipment

Abstract

This application discloses a fault identification method, apparatus, and electronic device. The method includes: if the current state of a vehicle meets the target fault detection conditions corresponding to a displayed fault, then acquiring the vehicle's embedded data and the screenshot data of the vehicle's screen; if the target fault identification model determines that the vehicle has a fault based on the embedded data, then sending the embedded data and the screenshot data to a server; receiving optimized fault detection conditions and a trained fault identification model sent by the server; updating the target fault detection conditions based on the optimized fault detection conditions, and updating the target fault identification model based on the trained fault identification model; the updated target fault detection conditions and target fault identification model are used for subsequent fault identification of the vehicle, thereby improving the sensitivity of identifying the vehicle's displayed faults.

Description

Technical Field

[0001] This application relates to the field of fault detection technology, and more specifically, to a fault identification method, apparatus, and electronic device. Background Technology

[0002] With the rapid development of automotive intelligence and connectivity, the cockpit domain controller, as a core component of human-machine interaction, is experiencing increasing system complexity and integration. This domain hosts various applications, operating systems, and underlying software. Any failure in any module—such as application crashes, operating system malfunctions, black or distorted screens, or touchscreen malfunctions—will severely impact user experience and even driving safety. Therefore, the ability to sensitively identify various display screen malfunctions has become a significant challenge in the current technological field. Summary of the Invention

[0003] In view of this, embodiments of this application propose a fault identification method, apparatus, and electronic device to improve the above-mentioned problems.

[0004] In a first aspect, embodiments of this application provide a fault identification method, the method comprising: if the current state of a vehicle meets the target fault detection conditions corresponding to a displayed fault, then acquiring embedded data of the vehicle and screenshot data of the vehicle screen; if a fault is determined to have occurred in the vehicle based on the embedded data by a target fault identification model, then sending the embedded data and the screenshot data to a server; receiving optimized fault detection conditions and a trained fault identification model sent by the server, wherein the optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data to obtain a tag dataset, and optimizing the target fault detection conditions based on the tag dataset, and the trained fault identification model is obtained by the server after training the target fault identification model based on the tag dataset; updating the target fault detection conditions based on the optimized fault detection conditions, and updating the target fault identification model based on the trained fault identification model, wherein the updated target fault detection conditions and the target fault identification model are used for subsequent fault identification of the vehicle.

[0005] Secondly, embodiments of this application provide a fault identification method, the method comprising: receiving embedded data and screenshot data of the vehicle's screen sent by a vehicle, wherein the embedded data and the screenshot data are obtained by the vehicle when its current state meets the target fault detection conditions corresponding to a displayed fault, and are sent when a fault is determined to have occurred in the vehicle based on the embedded data by a target fault identification model; labeling the embedded data based on the screenshot data to obtain a label dataset; optimizing the target fault detection conditions according to the label dataset to obtain optimized fault detection conditions, and training the target fault identification model according to the label dataset to obtain a trained fault identification model; sending the optimized fault detection conditions and the trained fault identification model to the vehicle, so that the vehicle updates the target fault detection conditions based on the optimized fault detection conditions, and updates the target fault identification model based on the trained fault identification model, the updated target fault detection conditions and the target fault identification model being used by the vehicle for subsequent fault identification.

[0006] Thirdly, embodiments of this application provide a fault identification device, which includes: a multi-dimensional data acquisition module, an edge computing module, a training model receiving module, and an edge computing update module. The system includes: a multi-dimensional data acquisition module for acquiring vehicle tracking data and screen screenshots if the vehicle's current state meets the target fault detection conditions corresponding to the displayed fault; an edge computing module for sending the tracking data and screenshots to the server if the target fault identification model determines that the vehicle has a fault based on the tracking data; a training model receiving module for receiving optimized fault detection conditions and a trained fault identification model from the server, wherein the optimized fault detection conditions are obtained by the server after labeling the tracking data with the screenshots, obtaining a label dataset, and optimizing the target fault detection conditions based on the label dataset, and the trained fault identification model is obtained by the server after training the target fault identification model based on the label dataset; and an edge computing update module for updating the target fault detection conditions based on the optimized fault detection conditions and updating the target fault identification model based on the trained fault identification model, wherein the updated target fault detection conditions and target fault identification model are used for subsequent fault identification of the vehicle.

[0007] Fourthly, embodiments of this application provide a fault identification device, which includes: a data reporting receiving module, a data annotation module, a model training module, and a training model distribution module. The system includes a data receiving module for receiving embedded data and screenshots of the vehicle's screen. The embedded data and screenshots are obtained when the vehicle meets the target fault detection conditions corresponding to the displayed fault in its current state, and are sent after a target fault identification model determines that the vehicle has a fault based on the embedded data. A data labeling module labels the embedded data based on the screenshots to obtain a label dataset. A model training module optimizes the target fault detection conditions based on the label dataset to obtain optimized fault detection conditions, and trains the target fault identification model based on the label dataset to obtain a trained fault identification model. A training model distribution module sends the optimized fault detection conditions and the trained fault identification model to the vehicle, enabling the vehicle to update the target fault detection conditions based on the optimized fault detection conditions and update the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and target fault identification model are used by the vehicle for subsequent fault identification.

[0008] Fifthly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory is coupled to the processor, the memory stores instructions, and when the instructions are executed by the processor, the processor executes the fault identification method provided in the first or second aspect described above.

[0009] Sixthly, embodiments of this application provide a computer-readable storage medium storing program code, which can be invoked by a processor to execute the fault identification method provided in the first or second aspect above.

[0010] In this application's solution, if the current state of the vehicle meets the target fault detection conditions corresponding to the displayed fault, then the vehicle's embedded data and the vehicle's screen screenshot data are obtained; if the target fault recognition model determines that the vehicle has a fault based on the embedded data, then the embedded data and screenshot data are sent to the server; the optimized fault detection conditions and the trained fault recognition model sent by the server are received, wherein the optimized fault detection conditions are obtained by the server after annotating the embedded data based on the screenshot data, obtaining a label dataset, and optimizing the target fault detection conditions based on the label dataset; the trained fault recognition model is obtained by the server after training the target fault recognition model based on the label dataset; the target fault detection conditions are updated based on the optimized fault detection conditions, and based on... The trained fault identification model updates the target fault identification model. The updated target fault detection conditions and target fault identification model are used for subsequent fault identification of the vehicle. For the displayed fault of the vehicle, the system triggers the collection of vehicle fault identification data points and screenshots based on the current state of the vehicle. When the fault identification model stored in the vehicle determines that a fault has occurred based on the data points, it sends the corresponding data points and screenshots to the server. The server annotates the data points based on the screenshots and uses the annotated data points to train the fault identification model and optimize the fault detection conditions. The trained fault identification model and optimized fault detection conditions are then sent to the vehicle for fault detection, improving the sensitivity and accuracy of vehicle fault identification. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0012] Figure 1 A flowchart illustrating a fault identification method provided in an embodiment of this application is shown; Figure 2 This illustration shows a schematic diagram of screenshot data provided in an embodiment of this application; Figure 3 A schematic diagram of a fault identification process provided in an embodiment of this application is shown; Figure 4 A flowchart illustrating a fault identification method provided in an embodiment of this application is shown; Figure 5 A flowchart illustrating a fault identification method provided in an embodiment of this application is shown; Figure 6A flowchart illustrating a fault identification method provided in an embodiment of this application is shown; Figure 7 This paper shows a timing diagram of the vehicle-cloud collaborative fault identification system provided in an embodiment of this application; Figure 8 A block diagram of a fault identification device provided in one embodiment of this application is shown; Figure 9 A block diagram of a fault identification device provided in one embodiment of this application is shown; Figure 10 A block diagram of a vehicle used to perform the fault identification method according to an embodiment of this application is shown. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0014] The implementation details of the technical solutions in the embodiments of this application are described in detail below: With advancements in technology, vehicles are increasingly equipped with more and more functions, with numerous vehicle features and applications integrated into in-vehicle infotainment screens. Against this backdrop, accurately detecting display faults on in-vehicle devices has become a pressing issue.

[0015] In related technologies, existing solutions identify cockpit domain faults by setting up isolated data points on the vehicle side and collecting predefined single-dimensional indicators (such as CPU utilization and memory usage). However, this approach relies solely on data from a single source (e.g., using only vehicle logs or relying solely on cloud heartbeat packets) for fault diagnosis. The information obtained is often indirect and superficial, making it difficult to directly and accurately reflect complex faults that users can perceive, such as "black screen," "screen flickering," and "lag." This "isolated" diagnostic approach lacks cross-validation of multi-dimensional information, making it difficult to accurately capture complex and intermittent cockpit faults (such as momentary black screen or application unresponsiveness), resulting in low fault identification accuracy and frequent false alarms and missed alarms.

[0016] Furthermore, when relying on periodic data reporting or local log dumping after a failure for fault identification, the system often cannot capture instantaneous faults in real time. In the event of a serious fault (such as a system restart), local logs may be lost, making it impossible to recover the fault scene information. Simultaneously, for fault analysis, it is usually necessary to continuously and completely upload large amounts of raw log data generated by the vehicle to the cloud for processing, resulting in excessive cloud computing load and high resource and bandwidth costs. This not only consumes a large amount of cloud computing resources but also incurs expensive wireless data transmission fees, making it uneconomical for operators with large fleets and hindering large-scale application.

[0017] To avoid missed reports, some solutions choose to continuously report large amounts of raw data to the cloud for unified fault identification. However, this further increases the cost of wireless communication and puts enormous pressure on the cloud's data storage and processing capabilities.

[0018] For malfunctions like "black screen" that require visual confirmation, traditional logs and numerical data are difficult to use as direct evidence. Developers cannot intuitively obtain the actual screen state when the malfunction occurs, which brings huge challenges to problem localization and resolution.

[0019] In summary, the relevant technologies still have significant shortcomings in terms of sensitivity and accuracy in identifying various display screen faults, and more effective detection methods are urgently needed.

[0020] To address the aforementioned problems, the inventors, through extensive research, have developed a fault identification method, apparatus, and electronic device as provided in this application. This method, targeting vehicle display faults, triggers the collection of embedded data and screenshots based on the vehicle's current state. When a fault is determined to have occurred using the fault identification model stored in the vehicle and the embedded data, the corresponding embedded data and screenshots are sent to a server. The server then annotates the embedded data based on the screenshots and uses this annotated data to train the fault identification model and optimize fault detection conditions. The trained fault identification model and optimized fault detection conditions are then sent to the vehicle for fault detection, improving the sensitivity and accuracy of vehicle display fault identification. The specific fault identification method will be described in detail in subsequent embodiments.

[0021] The embodiments involved in this application will now be described with reference to the accompanying drawings.

[0022] Please see Figure 1 , Figure 1 A flowchart illustrating a fault identification method according to an embodiment of this application is shown. In a specific embodiment, this fault identification method can be applied to, for example... Figure 8The fault identification device 200 and the electronic device 100 equipped with the fault identification device 200 are shown. Figure 10 The following will use an electronic device as an example to illustrate the specific process of this embodiment. The following will address... Figure 1 The process shown will be described in detail. The fault identification method may specifically include the following steps: Step S110: If the current state of the vehicle meets the target fault detection conditions corresponding to the displayed fault, then obtain the embedded data of the vehicle and the screenshot data of the vehicle screen.

[0023] In this embodiment, the electronic device can be a vehicle (which can be understood as a self-driving car). The self-driving car may be equipped with multiple sensors, such as temperature sensors, speed sensors, and steering wheel sensors. The self-driving car can acquire sensor data collected by these multiple sensors, as well as its CAN bus data (e.g., processor utilization, memory utilization, voltage signals, current signals, etc.), and can determine the current state of the self-driving car based on the sensor data and / or the CAN bus data. The current state of the self-driving car includes, but is not limited to, the self-driving car's processor utilization, memory utilization, and processor temperature.

[0024] In some implementations, the vehicle may pre-store target fault detection conditions corresponding to displayed faults. These target fault detection conditions can be obtained by the vehicle from an associated cloud (which can be understood as a server) or electronic device, or can be set by the user; no limitation is made here. For example, the vehicle can communicate with the cloud and receive fault handling configurations periodically sent by the cloud. These fault handling configurations include, but are not limited to, target fault detection conditions and target fault identification models. The target fault detection conditions include, but are not limited to, processor utilization exceeding a first threshold, memory utilization exceeding a second threshold, and processor temperature exceeding a third threshold.

[0025] The target fault detection condition can be understood as a data tracking trigger condition, and it can be bound to screenshot or screen recording functions. After the vehicle obtains its current state, it can compare the current state with the data tracking trigger condition. If the current state meets the target fault detection condition, the data tracking will be triggered, and a screenshot / screen recording of the vehicle screen will be taken, obtaining the vehicle's data tracking data and the screenshot data. The screenshot data can include data from the screenshot and / or screen recording of the vehicle. For an example, please refer to [link to example]. Figure 2 This illustrates a schematic diagram of screenshot data provided in an embodiment of this application.

[0026] The embedded data of the vehicle includes, but is not limited to, the current status of the vehicle, data collected by multiple sensors installed on the vehicle, CAN bus data of the vehicle, log data of the vehicle, and diagnostic fault codes (DTCs) of the vehicle.

[0027] Step S120: If the target fault identification model determines that the vehicle has a fault based on the embedded data, then the embedded data and the screenshot data are sent to the server.

[0028] In some implementations, after the vehicle collects its own embedded data and screenshots of its screen, a target fault identification model can determine whether the vehicle has malfunctioned based on the embedded data. The model can then determine whether to report the embedded data to the server that issued the target fault identification model for model training, based on the fault identification result. Specifically, if the vehicle determines that it has malfunctioned based on the embedded data using the target fault identification model, then the embedded data and the corresponding screenshots can be sent to the server.

[0029] For example, please refer to Figure 3 This document illustrates a flowchart of a fault identification process provided in an embodiment of this application. The vehicle, when its current state meets the target fault detection conditions corresponding to the displayed fault, collects embedded data and screenshots of its screen. The embedded data and screenshots can be compressed and stored. A target fault identification model can be used to determine whether a fault has occurred in the vehicle based on the embedded data, thereby identifying the fault on the vehicle side and outputting a fault identification result. If the fault identification result indicates a fault has occurred, the vehicle imports the embedded data and screenshots into a cloud platform (server). The cloud platform then trains the target fault identification model based on the embedded data and screenshots, and distributes the trained fault identification model to the vehicle's edge computing module.

[0030] Step S130: Receive the optimized fault detection conditions and the trained fault identification model sent by the server. The optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data and obtaining the tag dataset, and then optimizing the target fault detection conditions according to the tag dataset. The trained fault identification model is obtained by the server after training the target fault identification model according to the tag dataset.

[0031] In some implementations, after the vehicle sends its embedded data and screenshots to the server, it can receive optimized fault detection conditions and a trained fault identification model from the server. The optimized fault detection conditions can be obtained by the server annotating the embedded data with the screenshots reported by the vehicle, obtaining a labeled dataset, and then optimizing the target fault detection conditions based on this labeled dataset. Similarly, the trained fault identification model can be obtained by the server training a target fault identification model using the labeled dataset.

[0032] Understandably, the server trains the fault identification model by annotating the embedded data based on the screenshot data. The screenshot data can reflect specific and complex cockpit-domain user-perceptible display faults such as "black screen," "screen flickering," and "lag." Based on this, the model is trained by annotating the embedded data with the screenshot data, which improves the sensitivity and accuracy of the model in identifying display faults.

[0033] Optionally, the server can periodically retrieve or monitor the fault handling configurations sent to the vehicle to update the vehicle's fault handling configurations in a timely manner. Specifically, based on the embedded data and screenshot data sent by the vehicle, the server can obtain optimized fault detection conditions and a trained fault recognition model. Then, based on the optimized fault detection conditions and the trained fault recognition model, the server can obtain the updated fault handling configuration and its version information. The server can obtain the version information of the fault handling configuration in the vehicle. If it determines that the version information of the fault handling configuration in the vehicle differs from the version information of the updated fault handling configuration on the server, it can send the updated fault handling configuration to the vehicle. Correspondingly, the vehicle can receive the updated fault handling configuration and obtain the optimized fault detection conditions and the trained fault recognition model.

[0034] Step S140: Update the target fault detection conditions based on the optimized fault detection conditions, and update the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used for subsequent fault identification by the vehicle.

[0035] In some implementations, after receiving the optimized fault detection conditions and the trained fault identification model from the server, the vehicle can update the target fault detection conditions stored in the vehicle based on the optimized fault detection conditions, and update the target fault identification model stored in the vehicle based on the trained fault identification model. The updated target fault detection conditions and target fault identification model can then be used by the vehicle for subsequent fault identification.

[0036] In this embodiment, the vehicle can load and run the fault identification model issued by the server to perform online analysis of the local embedded data generated in real time and make a preliminary fault judgment. If a vehicle fault is determined, the captured fault evidence (embedded data and screenshot data) can be compressed and sent back to the server. The server then enriches the sample library for training the fault identification model based on the fault evidence, retrains the model, and issues it again, thus forming a continuously improving feedback loop. Based on this, vehicle fault identification is achieved through vehicle-cloud collaborative big data identification and edge computing, improving the accuracy of fault identification, reducing cloud computing resource consumption, lowering data backhaul bandwidth costs, and using an edge computing deployment scheme to identify faults locally on the vehicle, reducing fault identification latency and improving efficiency.

[0037] One embodiment of this application provides a fault identification method that, if the current state of the vehicle meets the target fault detection conditions corresponding to the displayed fault, acquires the vehicle's embedded data and screenshot data of the vehicle's screen; if the target fault identification model determines that the vehicle has a fault based on the embedded data, the embedded data and screenshot data are sent to the server; receives optimized fault detection conditions and a trained fault identification model sent by the server, wherein the optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data, obtaining a label dataset, and optimizing the target fault detection conditions based on the label dataset; the trained fault identification model is obtained by the server after training the target fault identification model based on the label dataset; and updates the target fault detection conditions based on the optimized fault detection conditions. The system updates the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and target fault identification model are used for subsequent fault identification of the vehicle. For the vehicle's displayed faults, the system triggers the collection of vehicle fault identification data points and screenshots based on the vehicle's current state. When the fault identification model stored in the vehicle determines that a fault has occurred based on the data points, the system sends the corresponding data points and screenshots to the server. The server then annotates the data points based on the screenshots and trains the fault identification model and optimizes the fault detection conditions based on the annotated data points. Finally, the trained fault identification model and optimized fault detection conditions are sent to the vehicle for fault detection, improving the sensitivity and accuracy of vehicle fault identification.

[0038] Please see Figure 4 , Figure 4 A flowchart illustrating a fault identification method according to an embodiment of this application is shown. This method is applied to the aforementioned electronic device, and will be discussed below. Figure 4 The process shown will be described in detail. The fault identification method may specifically include the following steps: Step S210: If the processor utilization rate of the vehicle is higher than the first threshold, and / or the memory utilization rate of the vehicle is higher than the second threshold, then obtain the embedded data of the vehicle and the screenshot data of the vehicle screen.

[0039] In some implementations, the current state of the vehicle includes, but is not limited to, multi-dimensional information such as the utilization rate of the vehicle's processor and the utilization rate of the vehicle's memory.

[0040] In some implementations, the vehicle may pre-store target fault detection conditions corresponding to display faults. If the vehicle's current state meets the target fault detection conditions for a display fault, then the vehicle's embedded data and a screenshot of the vehicle's screen are acquired. For example, if it is determined that the vehicle's processor utilization rate is higher than a first threshold (e.g., 80%, 85%, etc.), and / or the vehicle's memory utilization rate is higher than a second threshold (e.g., 50%, 60%, etc.), then it can be determined that the vehicle's current state meets the target fault detection conditions for a display fault, and the vehicle's embedded data and a screenshot of the vehicle's screen can then be acquired.

[0041] Step S220: If the target fault identification model determines that the vehicle has a fault based on the embedded data, then obtain the authorization status of the vehicle data transmission.

[0042] In some implementations, after acquiring embedded data and screen screenshots, the vehicle can perform fault detection based on the embedded data using a pre-stored target fault identification model. Specifically, if the vehicle determines a fault has occurred based on the embedded data using the target fault identification model, it can obtain the authorization status for data transmission.

[0043] As an feasible approach, when a vehicle malfunctions based on embedded data and a target fault identification model, it can output authorization prompts and obtain the authorization status of its data transmission based on these prompts. The methods for outputting authorization prompts include, but are not limited to, displaying an authorization confirmation interface (e.g., an interface including authorization and denial controls for user selection), outputting authorization confirmation voice prompts, and controlling the flashing of authorization confirmation indicator lights. Users can input authorization or denial commands based on the prompts. For example, they can input authorization commands by touching the authorization control displayed on the authorization confirmation interface, or by touching the denial control displayed on the authorization confirmation interface, or by pressing the authorization control included in the vehicle (which can be a physical button or a control displayed on the interface) based on the authorization confirmation voice prompt. The vehicle can determine the authorization status of its data transmission as authorized based on the authorization command, or as unauthorized based on the denial command.

[0044] As one feasible approach, the vehicle can be pre-configured with an identity identifier. The vehicle can send this identifier to a server, which determines its validity and returns a validity check result. Based on this result, the vehicle can determine the authorization status of its data transmission. For example, if the result is valid, the data transmission is determined to be authorized; if the result is invalid, the data transmission is determined to be unauthorized.

[0045] Step S230: If the authorization status is authorized, then send the embedded data and the screenshot data to the server.

[0046] In some implementations, if the vehicle determines that its data transmission authorization status is authorized, it can send the embedded data and screenshot data to the server. Specifically, if the vehicle determines a fault has occurred based on the embedded data using a target fault identification model, it can compress and store the embedded data and screenshot data, and can send the compressed and stored embedded data and screenshot data to the server if the authorization status is confirmed to be authorized.

[0047] In some implementations, the vehicle can send an identification application request to the server before sending the tracking data and screenshot data to the server, and can receive a business identification issued by the server in response to the identification application request. It can also associate the stored tracking data and screenshot data with the business identification, and can send the tracking data and screenshot data associated with the business identification to the server.

[0048] The vehicle can also check its network status before sending the embedded data and screenshots to the server. If the network status meets preset conditions, it can send the embedded data and screenshots associated with the business identifier to the server. If the network status does not meet the preset conditions, it can wait until the vehicle's network status meets the preset conditions before sending the embedded data and screenshots associated with the business identifier to the server. The preset conditions include, but are not limited to, the vehicle communicating with the server via a preset network (such as WiFi, Zigbee, wired connection, etc.), the bandwidth of the vehicle's network exceeding a bandwidth threshold, and the latency of data transmission in the vehicle's network being lower than a latency threshold.

[0049] It should be noted that the server can store multiple sets of data groups containing event tracking data and screenshot data associated with business identifiers. Each data group corresponds to a different business identifier. During the process of annotating event tracking data based on screenshot data, the server can retrieve the event tracking data corresponding to the screenshot data from multiple data groups stored on the server based on the business identifier for annotation, thereby improving the accuracy and efficiency of data annotation.

[0050] Step S240: Receive the optimized fault detection conditions and the trained fault identification model sent by the server. The optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data and obtaining the tag dataset, and then optimizing the target fault detection conditions according to the tag dataset. The trained fault identification model is obtained by the server after training the target fault identification model according to the tag dataset.

[0051] Step S250: Update the target fault detection conditions based on the optimized fault detection conditions, and update the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used for subsequent fault identification by the vehicle.

[0052] For a detailed description of steps S240-S250, please refer to the previous description of steps S130-S140, which will not be repeated here.

[0053] The fault identification method provided in one embodiment of this application is compared to Figure 1 The fault identification method shown in this embodiment may include at least one of the vehicle's processor utilization rate and memory utilization rate. In this embodiment, if the processor utilization rate is higher than a first threshold and / or the memory utilization rate is higher than a second threshold, the embedded data of the vehicle and the screenshot data of the vehicle's screen are obtained. Thus, the collection of embedded data and screenshot data for fault identification is triggered according to the vehicle's processor utilization rate and / or memory utilization rate, which reduces the computational resource consumption of fault identification, increases the amount of fault identification analysis data, and also improves the efficiency of fault identification.

[0054] Meanwhile, this embodiment can also obtain the authorization status of vehicle data transmission; if the authorization status is authorized, the embedded data and screenshot data are sent to the server, so that when the vehicle data transmission status is authorized, the data is sent to the server to protect the privacy of the data during upload and improve the user experience.

[0055] Please see Figure 5 , Figure 5A flowchart illustrating a fault identification method according to an embodiment of this application is shown. In a specific embodiment, this fault identification method can be applied to, for example... Figure 9 The fault identification device 300 and the electronic device 100 equipped with the fault identification device 300 are shown. Figure 10 The following will use an electronic device as an example to illustrate the specific process of this embodiment. The following will address... Figure 5 The process shown will be described in detail. The fault identification method may specifically include the following steps: Step S310: Receive embedded data and screenshot data of the vehicle's screen sent by the vehicle, wherein the embedded data and the screenshot data are obtained by the vehicle when the current state meets the target fault detection conditions corresponding to the display fault, and are sent when the target fault identification model determines that the vehicle has a fault based on the embedded data.

[0056] In some implementations, the electronic device can be a server (or the cloud). The cloud can communicate with the vehicle and periodically send target fault detection conditions and target fault identification models to the vehicle, so that the vehicle can identify faults based on the target fault detection conditions and target fault identification models.

[0057] In some implementations, after the cloud sends the target fault detection conditions and the target fault identification model to the vehicle, it can receive the embedded data and screenshots of the vehicle's screen sent by the vehicle. The embedded data and screenshots can be obtained by the vehicle when its current state meets the target fault detection conditions corresponding to the displayed fault, and sent after the target fault identification model determines that a vehicle fault has occurred based on the embedded data.

[0058] Step S320: Annotate the embedded data based on the screenshot data to obtain a tag dataset.

[0059] In some implementations, after receiving the embedded data and screenshot data sent by the vehicle, the cloud can annotate the embedded data based on the screenshot data to obtain a labeled dataset. Specifically, the cloud can use the screenshot data to obtain information about the vehicle's screen malfunctions, such as "black screen," "flickering," and "lag," identifying specific and complex user-perceptible faults. The cloud can then annotate the embedded data based on these fault conditions, thereby constructing a multi-dimensional fault identification model based on both visible and invisible faults, improving the model's sensitivity and accuracy in identifying visible faults.

[0060] In some implementations, the labeled dataset may include a first dataset and a second dataset; wherein the first dataset may include data labeled with a first label, and the second dataset may include data labeled with a second label. The first label may be used to characterize a display malfunction in the vehicle's screen, and the second label may be used to characterize a display malfunction in the vehicle's screen. The electronic device can use an image recognition model to perform image recognition on the screenshot data to determine the screen malfunction; if the malfunction indicates a display malfunction, the tracking data can be labeled with the first label, and the first dataset can be obtained based on the labeled tracking data; if the malfunction indicates a display malfunction in the vehicle, the tracking data can be labeled with the second label, and the second dataset can be obtained based on the labeled tracking data.

[0061] In this process, the cloud-based system uses an image recognition model to perform image recognition on screenshot data to determine the screen's fault status. During this process, the screenshot data can be preprocessed to obtain image data to be processed. Preprocessing includes, but is not limited to, image size normalization and pixel value standardization. The cloud-based system can also input the image data to be processed into the image recognition model to obtain the screen's fault status output by the model.

[0062] In the cloud-based preprocessing of screenshot data, bilinear interpolation can be used to uniformly scale the image frames (H×W×C) of the screenshot data to the model input size (H0×W0×C), thereby normalizing the image size. For example, a normalized image can be obtained by processing the image using a normalization formula. The normalization formula can be: = Where (x, y) can represent the pixel coordinates in the normalized image, (x_i, y_j) can represent the coordinates of the neighboring pixels of the original image, w_i and w_j can represent the interpolation weights, and C can represent the number of channels of the image (e.g., C=3 for RGB images, C=1 for grayscale images, etc.).

[0063] The cloud-based system, after normalizing screenshot data, can further standardize pixel values ​​in the normalized image to eliminate the impact of brightness differences on image recognition and improve accuracy. For example, the cloud can use Z-Score for image standardization. This can be achieved by processing the normalized image using a standardization formula to obtain an image with standardized pixel values. The standardization formula could be: Where μ_c can represent the mean value of the c-th channel pixels in the screenshot data, and σ_c can represent the standard deviation of the c-th channel pixels in the screenshot data.

[0064] The image recognition model can be a convolutional neural network, etc. For example, an image recognition model using a lightweight CNN architecture (such as MobileNetV2) includes the following core process formulas: ① Feature extraction from convolutional layers: Where F{l} can represent the feature map of the I-th layer, K can represent the size of the convolution kernel, W_l can represent the weight of the convolution kernel, b_l can represent the bias term, C_{l-1} can represent the number of channels in the previous layer, and ReLU can represent the activation function.

[0065] ② Pooling layer downsampling. In this process, max pooling can be used in the cloud to preserve key image features, reducing the computational load for image recognition. For example, pooling layer downsampling: Where P can represent the pooling kernel size, and F_conv can represent the output feature map of the convolutional layer.

[0066] ③ Fully connected layer classification. In this process, the last pooling feature map is flattened into a vector V (dimension D) in the cloud, and the probability is output through a fully connected layer. For example, fully connected layer classification: Here, W_fc represents the weights of the fully connected layer, b_fc represents the bias term, and the sigmoid function maps the output to the interval [0, 1]. It can represent the predicted probability of "the existence of a black screen failure".

[0067] In this process, the cloud can pre-optimize the image recognition model's parameters and then perform image recognition based on the optimized model. For example, the cloud can train the loss function formula for the image recognition model and optimize the model parameters. Specifically, the cloud can use binary classification cross-entropy loss to adapt the label y (0 / 1) and the predicted probability y: Where N represents the number of samples used to train the image recognition model, and y_n represents the true label of the nth sample. It can characterize the prediction probability of the nth sample.

[0068] The image recognition model can determine the probability of an image being a normal display or the probability of it being a black screen, flickering screen, or lagging display. Probability thresholds can be pre-set in the cloud. If the image recognition model determines the probability that the image will be displayed as a black screen, flickering screen, or laggy image, then... Among them, if ≥ This confirms that the screen malfunction is a display problem. ≤ If so, it can be determined that there is no display fault on the screen.

[0069] In this process, after determining the fault condition of the vehicle screen based on the screenshot data, the cloud can create labeled data for training a fault recognition model based on the fault condition and the purchase point data. If the fault condition indicates a display fault, a first label can be assigned to the tracked data, and a first dataset can be obtained from the labeled tracked data. If the fault condition indicates no display fault, a second label can be assigned to the tracked data, and a second dataset can be obtained from the labeled tracked data. The cloud can then use the first and second data to train the fault recognition model and optimize the fault detection conditions.

[0070] For example, please refer to Figure 6 The diagram illustrates a flowchart of a fault identification method provided in an embodiment of this application. The vehicle can obtain its current state (e.g., CPU utilization), and if the CPU utilization exceeds a first threshold (e.g., 80%), it can trigger the vehicle's data tracking and screenshot / screen recording functions to acquire data from multi-dimensional sensors and screenshot data from the vehicle's screen. The vehicle can perform edge computing for fault identification based on the data tracking and a target fault identification model, and if a vehicle fault is determined, it can associate and store the data tracking and screenshot data. The vehicle can also obtain the authorization status of its data transmission, and if the authorization status is confirmed as authorized, it can send the associated stored data tracking and screenshot data to the server.

[0071] Specifically, after receiving the embedded data and screenshot data sent by the vehicle, the cloud can use an image recognition model to perform image recognition on the screenshot data to determine the screen's fault condition. If the fault condition indicates that the vehicle has a display fault, the cloud can label the embedded data with a first label and obtain a first dataset based on the labeled embedded data. If the fault condition indicates that the vehicle does not have a display fault, the cloud can label the embedded data with a second label and obtain a second dataset based on the labeled embedded data.

[0072] Specifically, the cloud can train the target fault identification model based on the first and second datasets to obtain the trained fault identification model, and can also optimize the target fault detection conditions based on the first and second datasets to obtain optimized fault detection conditions (e.g., CPU utilization greater than or equal to 85% and memory utilization greater than or equal to 50%). The cloud can also send the trained fault identification model and optimized fault detection conditions to the vehicle, allowing the vehicle to update the target fault detection conditions based on the optimized fault detection conditions, update the target fault identification model based on the trained fault identification model, and perform fault identification based on the updated target fault detection conditions and the target fault identification model.

[0073] Step S330: Optimize the target fault detection conditions based on the label dataset to obtain optimized fault detection conditions, and train the target fault identification model based on the label dataset to obtain the trained fault identification model.

[0074] In some implementations, after obtaining the label dataset in the cloud, the target fault detection conditions can be optimized based on the label dataset to obtain optimized fault detection conditions, and the target fault identification model can be trained based on the label dataset to obtain the trained fault identification model.

[0075] The label dataset can include event tracking data and the corresponding labels. The cloud can quantize the event tracking data in the label dataset to obtain a quantized vector; it can then use the target fault identification model to generate a threshold based on the quantized vector, obtaining a first threshold; and it can train the target fault identification model based on the first threshold and the labels corresponding to the event tracking data to obtain the trained fault identification model.

[0076] For example, the cloud can map event tracking data into network-processable state vectors (which can also be understood as metrics, such as state vectors). =[ , ,......, Furthermore, the cloud can also eliminate the influence of dimensions based on the feature normalization formula; the feature normalization formula can be: = in, This can represent the original value of the i-th indicator at time t (e.g., CPU utilization, memory utilization, etc.); where, / It can represent the historical minimum / maximum value of the i-th indicator (based on statistics from the label dataset).

[0077] Specifically, the cloud can generate a first threshold based on the quantized vector using the target fault identification model. Then, it can train the target fault identification model based on the first threshold and the labels corresponding to the embedded data, resulting in a trained fault identification model. For example, the action vector... =[ , ,......, ,\logic(t)], where the fault identification model includes a threshold generation formula (the network output index is mapped to the actual threshold): = +( - ) .in, Let be the original output (-∞, +∞) of the neural network for the i-th index. This is the Sigmoid function (maps the output to the 0~1 interval, corresponding to a relative threshold ratio). The fault identification model includes the combinational logic output formula: \logic(t) = argmax(Softmax( , , The three corresponding logics are: 0 = "OR", 1 = "AND", and 2 = "NOT" (e.g., "CPU AND memory" in the example corresponds to \logic(t) = 1). The cloud-based training of the fault identification model using the labeled dataset involves "modifying the thresholds of each indicator + combinational logic," outputting the trained fault identification model (the final trigger rule). The final trigger condition is: Trigger(t) = \logic(t){ ≥ , ≥ , ......}.

[0078] In the process of obtaining the trained fault identification model, the cloud can further optimize the parameters of the fault identification model through the reward function formula. For example, the immediate reward r(t) = R hit (t)-β R false (t)-γ R complex (t).

[0079] Among them, the fault hit reward R hit Trigger(t) = 1 (if t is the actual fault time and Trigger(t) = 1), otherwise it is 0.

[0080] Among them, false alarm penalty Rfalse Trigger(t) = 1 (if t is a normal time and Trigger(t) = 1), otherwise it is 0.

[0081] Among them, the complexity penalty R complex (t) = (k(t) is the number of indicators included in the current triggering condition, and n is the total number of indicators to avoid overly complex rules).

[0082] in, α can represent the hit weight, β can represent the false positive weight, and γ can represent the complexity weight. Among them, α, β and γ are hyperparameters (tuned based on the labeled dataset, such as α=2, β=1 and γ=0.5).

[0083] In the process of obtaining the trained fault identification model, the cloud can also update the parameters in the fault identification model based on the reinforcement learning network parameter update formula. For example, the DQN (Deep Q-Network) framework is used to update the network parameters, minimizing the temporal difference error: The Q-value prediction formula (assessment state - action value) is: Q(S) t A t ; =MLP(S) t A t MLP stands for Multilayer Perceptron (input S). t and A t The output is a single value Q, representing the long-term value of the triggering condition.

[0084] The formula for the target Q value is: y t =r(t)+γ Q(S) t+1 A t+1 ; ), where γ can be a discount factor (0.9~0.99, balancing immediate and future rewards). It can characterize the target network parameters (periodically obtained from the main network). (Copy to ensure stable training).

[0085] Among them, the loss function and parameter updates are as follows: ( ) = E[(y t -Q(S) t A t ; ) 2 Gradient descent is used for updating: ← - ( () The learning rate can be 0.001 to 0.01. In some implementations, the cloud can generate a second threshold based on the quantization vector using a trained fault identification model, and then optimize the target fault detection conditions based on this second threshold to obtain optimized fault detection conditions. For example, the cloud can perform action decoding on the trained fault identification model (from network output to tracking rules). Specifically, the cloud can calculate the final threshold (second threshold) for each indicator based on the threshold generation formula in the trained fault identification model, and obtain optimized fault detection conditions based on these thresholds. For example, the cloud can extract the optimal threshold: = +( - ) .in, It can characterize the optimal original value output by the trained fault identification model.

[0086] Step S340: Send the optimized fault detection conditions and the trained fault identification model to the vehicle, so that the vehicle updates the target fault detection conditions based on the optimized fault detection conditions and updates the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used by the vehicle for subsequent fault identification.

[0087] In some implementations, after obtaining optimized fault detection conditions and a trained fault identification model, the cloud can send these conditions and models to the vehicle. The vehicle then updates the target fault detection conditions based on the optimized conditions and the target fault identification model based on the trained model. The updated conditions and model are used for subsequent fault identification by the vehicle. This vehicle-cloud collaboration decentralizes the real-time processing and analysis of large amounts of raw data to the vehicle edge. The cloud only receives high-value fault feature data or lightweight analysis results that have been pre-screened and aggregated by the vehicle. This "edge preprocessing, cloud-based fine analysis" model reduces cloud computing resource consumption, lowers data backhaul bandwidth costs, effectively reduces the computing load on the central cloud server, reduces the number of high-performance computing instances required, and directly lowers the procurement cost of cloud computing services. Compared to traditional solutions that require continuous uploading of large amounts of raw event logs, this embodiment uses intelligent judgment on the vehicle side to trigger the transmission of key information (screenshots of the fault moment, specific system log fragments) only when a suspected fault occurs or as required by cloud policies. This "event-driven" data upload avoids the network transmission of invalid data and reduces the bandwidth cost of data communication from the vehicle to the cloud. Furthermore, by adopting an edge computing deployment scheme and supporting real-time business decisions, powerful local computing capabilities are provided within the cockpit domain controller or relevant ECUs. This allows fault analysis tasks that previously required aggregation to the cloud for batch processing (typically taking several hours) to be processed in real-time on the vehicle side, achieving processing times in minutes or even seconds. This leap from "hours" to "minutes" represents a significant improvement in response speed, greatly enhancing the efficiency of fault response and handling, and improving user experience and safety assurance.

[0088] For example, please refer to Figure 7This document illustrates a timing diagram of a vehicle-cloud collaborative fault identification system provided in an embodiment of this application. The fault identification system includes a cloud configuration module, a data tracking service module, an in-vehicle hardware module, a recall service module, an in-vehicle upload module, a cloud storage module, and a cloud database module. The cloud continuously analyzes data tracking data transmitted from a massive number of vehicles and continuously optimizes the neural network AI model in the cloud. The vehicle uses the model trained by the AI ​​neural network, deployed in the in-vehicle edge computing module, to identify faults. The in-vehicle hardware module collects sensor fault data, interacts directly with the vehicle hardware, obtains fault tracking data, and transmits it to the data tracking service module. The cloud configuration module can be used to distribute configurations from the cloud to bind screenshots / screen recordings to specific fault tracking points such as "black screen," "flickering," and "lag," outputting the results to the edge computing of the data tracking service module. When a fault occurs, the data tracking service module outputs the edge computing results, performs a real-time screenshot, and stores it locally. The vehicle-mounted upload module can request an upload task ID from the cloud and return an ActiveUploadBusinessID from the cloud storage module. This ActiveUploadBusinessID can then be sent to the event tracking service module, which can report fault information (associated with the BusinessID) to the cloud database module. This improves the accuracy of fault identification through vehicle-cloud collaborative big data recognition, multi-dimensional screenshot information collection, and edge computing.

[0089] One embodiment of this application provides a fault identification method that receives embedded data and screenshots from the vehicle's screen. The embedded data and screenshots are acquired when the vehicle's current state meets the target fault detection conditions corresponding to the displayed fault, and are sent after a fault is determined to have occurred by a target fault identification model based on the embedded data. The embedded data is labeled with the screenshots to obtain a tag dataset. The target fault detection conditions are optimized based on the tag dataset to obtain optimized fault detection conditions. The target fault identification model is trained based on the tag dataset to obtain a trained fault identification model. The optimized fault detection conditions and the trained fault identification model are sent to the vehicle so that the vehicle updates the target fault detection conditions based on the optimized fault detection conditions and updates the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and target fault identification model are used for subsequent fault identification by the vehicle. This method, based on vehicle fault identification and the collection of screenshots and embedded data, allows the server to receive screenshots and embedded data uploaded from the vehicle, label the embedded data with the screenshots, train a fault identification model, and deploy the model on the vehicle after training, thereby improving the accuracy of fault identification.

[0090] Please see Figure 8 , Figure 8 A block diagram of a fault identification device according to an embodiment of this application is shown. This fault identification device 200 is applied to the aforementioned electronic device, and will be discussed below. Figure 8 The process shown is described in detail. The fault identification device 200 includes: a multi-dimensional data acquisition module 210, an edge computing module 220, a training model receiving module 230, and an edge computing update module 240, wherein: The multi-dimensional data acquisition module 210 is used to acquire the embedded data of the vehicle and the screenshot data of the vehicle screen if the current status of the vehicle meets the target fault detection conditions corresponding to the displayed fault.

[0091] The edge computing module 220 is used to send the embedded data and the screenshot data to the server if the target fault identification model determines that the vehicle has a fault based on the embedded data.

[0092] The training model receiving module 230 is used to receive the optimized fault detection conditions and the trained fault identification model sent by the server. The optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data to obtain a tag dataset, and then optimizing the target fault detection conditions according to the tag dataset. The trained fault identification model is obtained by the server after training the target fault identification model according to the tag dataset.

[0093] The edge computing update module 240 is used to update the target fault detection conditions based on the optimized fault detection conditions, and to update the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used for subsequent fault identification by the vehicle.

[0094] Furthermore, the current state includes at least one of the vehicle's processor utilization rate and memory utilization rate, and the multi-dimensional data acquisition module 210 may include: a multi-dimensional data acquisition subunit, wherein: A multi-dimensional data acquisition subunit is used to acquire embedded data of the vehicle and screenshot data of the vehicle screen if the processor utilization rate is higher than a first threshold and / or the memory utilization rate is higher than a second threshold.

[0095] Furthermore, the edge computing module 220 may include: an authorization status acquisition unit and a data reporting unit, wherein: The authorization status acquisition unit is used to acquire the authorization status of the vehicle's data transmission.

[0096] The data reporting unit is used to send the embedded data and the screenshot data to the server if the authorization status is authorized.

[0097] Please see Figure 9 , Figure 9 A block diagram of a fault identification device according to an embodiment of this application is shown. This fault identification device 300 is applied to the aforementioned electronic device, and will be discussed below. Figure 9 The process is described in detail below. The fault identification device 300 includes: a data receiving module 310, a data annotation module 320, a model training module 330, and a training model distribution module 340, wherein: The data receiving module 310 is used to receive embedded data sent by the vehicle and screenshot data of the vehicle's screen. The embedded data and the screenshot data are obtained by the vehicle when the current state meets the target fault detection conditions corresponding to the display fault, and are sent when the target fault identification model determines that the vehicle has a fault based on the embedded data.

[0098] The data annotation module 320 is used to annotate the embedded data based on the screenshot data to obtain a tag dataset.

[0099] The model training module 330 is used to optimize the target fault detection conditions based on the label dataset to obtain optimized fault detection conditions, and to train the target fault identification model based on the label dataset to obtain the trained fault identification model.

[0100] The training model distribution module 340 is used to send the optimized fault detection conditions and the trained fault identification model to the vehicle, so that the vehicle updates the target fault detection conditions based on the optimized fault detection conditions and updates the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used by the vehicle for subsequent fault identification.

[0101] Further, the labeled dataset includes a first dataset and a second dataset, wherein the first dataset includes data labeled with a first label, and the second dataset includes data labeled with a second label. The first label is used to characterize that the vehicle's screen has a display fault, and the second label is used to characterize that the vehicle's screen does not have a display fault. The data labeling module 320 may include: an image recognition unit, a first labeling unit, and a second labeling unit, wherein: An image recognition unit is used to perform image recognition on the screenshot data using an image recognition model to determine the fault status of the screen.

[0102] The first annotation unit is used to annotate the embedded data with the first label if the fault condition characterization indicates a display fault, and to obtain the first dataset based on the annotated embedded data.

[0103] The second annotation unit is used to annotate the embedded data with the second label if the fault condition characterization does not show a fault, and to obtain the second dataset based on the annotated embedded data.

[0104] Furthermore, the image recognition unit may include: an image preprocessing unit and a screen fault recognition unit, wherein: An image preprocessing unit is used to preprocess the screenshot data to obtain image data to be processed, wherein the preprocessing includes at least one of image size normalization processing and image pixel value standardization processing.

[0105] The screen fault identification unit is used to input the image data to be processed into the image recognition model and obtain the fault status of the screen output by the image recognition model.

[0106] Furthermore, the label dataset includes the event tracking data and the labels corresponding to the event tracking data. The model training module 330 may include: a data quantization unit, a threshold generation unit, and a model training subunit, wherein: The data quantization unit is used to quantize the embedded data included in the tag dataset to obtain a quantization vector.

[0107] The threshold generation unit is used to generate a first threshold by using the target fault identification model based on the quantization vector.

[0108] The model training subunit is used to train the target fault identification model based on the first threshold and the labels corresponding to the embedded data, so as to obtain the trained fault identification model.

[0109] Furthermore, the model training module 330 may include: a threshold generation subunit and a trigger condition optimization unit, wherein: The threshold generation subunit is used to generate a second threshold by using the trained fault identification model based on the quantization vector.

[0110] The trigger condition optimization unit is used to optimize the target fault detection condition according to the second threshold to obtain the optimized fault detection condition.

[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0112] In the several embodiments provided in this application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0113] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0114] Please see Figure 10 This document illustrates a structural block diagram of a vehicle according to an embodiment of this application. The electronic device 100 can be a vehicle, a server, or other device with processing capabilities. The electronic device 100 in this application may include one or more of the following components: a processor 110, a memory 120, and one or more application programs. The one or more application programs may be stored in the memory 120 and configured to be executed by one or more processors 110. The one or more programs are configured to perform the methods described in the foregoing method embodiments.

[0115] The processor 110 may include one or more processing cores. The processor 110 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and by calling data stored in the memory 120. Optionally, the processor 110 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 110 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 110 and may be implemented separately using a communication chip.

[0116] The memory 120 may include random access memory (RAM) or read-only memory (ROM). The memory 120 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the electronic device 100 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0117] In this embodiment, a computer-readable medium stores program code, which can be called by a processor to execute the methods described in the above method embodiments.

[0118] Computer-readable storage media can be electronic storage devices such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, computer-readable storage media includes non-transitory computer-readable storage medium. The computer-readable storage medium has storage space for program code that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code can be compressed, for example, in a suitable form.

[0119] In this application, "multiple" refers to two or more.

[0120] In this application, unless otherwise expressly defined, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; 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; and they can refer to the internal connection between two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0121] The terms “first,” “second,” “third,” “fourth,” etc., in this application (if any) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0122] In this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, in this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0123] Unless otherwise specified, all steps in this application may be performed sequentially or randomly. For example, if the method includes steps A and B, it means that the method may include steps A and B performed sequentially, or it may include steps B and A performed sequentially. For example, if the method may also include step C, it means that step C may be added to the method in any order. For example, the method may include steps A, B, and C, or it may include steps A, C, and B, or it may include steps C, A, and B, etc.

[0124] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A fault identification method, characterized in that, The method includes: If the current status of the vehicle meets the target fault detection conditions corresponding to the displayed fault, then the embedded data of the vehicle and the screenshot data of the vehicle screen are obtained. If the target fault identification model determines that the vehicle has a fault based on the embedded data, then the embedded data and the screenshot data are sent to the server. The server receives optimized fault detection conditions and trained fault identification models sent by the server. The optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data and obtaining a tag dataset, and then optimizing the target fault detection conditions according to the tag dataset. The trained fault identification model is obtained by the server after training the target fault identification model according to the tag dataset. The target fault detection conditions are updated based on the optimized fault detection conditions, and the target fault identification model is updated based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used for subsequent fault identification by the vehicle.

2. The method according to claim 1, characterized in that, The current state includes at least one of the vehicle's processor utilization rate and memory utilization rate. If the vehicle's current state meets the target fault detection conditions corresponding to the display fault, then the vehicle's embedded data and the vehicle's screen screenshot data are acquired, including: If the processor utilization rate is higher than a first threshold, and / or the memory utilization rate is higher than a second threshold, then the embedded data of the vehicle and the screenshot data of the vehicle screen are obtained.

3. The method according to claim 1, characterized in that, Sending the embedded data and the screenshot data to the server includes: Obtain the authorization status for vehicle data transmission; If the authorization status is "authorized", then the embedded data and the screenshot data are sent to the server.

4. A fault identification method, characterized in that, The method includes: The system receives embedded data sent by the vehicle and screenshot data of the vehicle's screen. The embedded data and the screenshot data are obtained by the vehicle when it meets the target fault detection conditions corresponding to the display fault in its current state, and are sent when the target fault identification model determines that the vehicle has a fault based on the embedded data. Based on the screenshot data, the embedded data is labeled to obtain a tag dataset; The target fault detection conditions are optimized based on the labeled dataset to obtain optimized fault detection conditions, and the target fault identification model is trained based on the labeled dataset to obtain a trained fault identification model. The optimized fault detection conditions and the trained fault identification model are sent to the vehicle so that the vehicle updates the target fault detection conditions based on the optimized fault detection conditions and updates the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used by the vehicle for subsequent fault identification.

5. The method according to claim 4, characterized in that, The labeled dataset includes a first dataset and a second dataset. The first dataset includes data labeled with a first label, and the second dataset includes data labeled with a second label. The first label indicates that the vehicle's screen has a display malfunction, and the second label indicates that the vehicle's screen does not have a display malfunction. The step of labeling the embedded data based on the screenshot data to obtain the labeled dataset includes: The screenshot data is analyzed using an image recognition model to determine the screen's malfunction. If the fault condition indicates a display fault, then the first label is used to annotate the embedded data, and the first dataset is obtained based on the annotated embedded data. If the fault condition description does not indicate a fault, then the embedded data is labeled with the second label, and the second dataset is obtained based on the labeled embedded data.

6. The method according to claim 5, characterized in that, The step of performing image recognition on the screenshot data using an image recognition model to determine the screen's fault status includes: The screenshot data is preprocessed to obtain image data to be processed, wherein the preprocessing includes at least one of image size normalization processing and image pixel value standardization processing; The image data to be processed is input into the image recognition model to obtain the screen's fault status output by the image recognition model.

7. The method according to claim 4, characterized in that, The label dataset includes the embedded data and the labels corresponding to the embedded data. The step of training the target fault identification model based on the label dataset to obtain the trained fault identification model includes: The embedded data included in the tag dataset is quantized to obtain a quantization vector; The target fault identification model generates a threshold based on the quantization vector to obtain a first threshold. The target fault identification model is trained based on the first threshold and the labels corresponding to the embedded data to obtain the trained fault identification model.

8. The method according to claim 7, characterized in that, The step of optimizing the target fault detection conditions based on the label dataset to obtain optimized fault detection conditions includes: The trained fault identification model generates a second threshold based on the quantization vector; The target fault detection conditions are optimized based on the second threshold to obtain the optimized fault detection conditions.

9. A fault identification device, characterized in that, The device includes: The multi-dimensional data acquisition module is used to acquire the vehicle's embedded data and the vehicle's screen screenshot data if the vehicle's current status meets the target fault detection conditions corresponding to the displayed fault. The edge computing module is used to send the embedded data and the screenshot data to the server if the target fault identification model determines that the vehicle has a fault based on the embedded data. The training model receiving module is used to receive the optimized fault detection conditions and the trained fault identification model sent by the server. The optimized fault detection conditions are obtained by the server after annotating the embedded data with the screenshot data and obtaining the tag dataset, and then optimizing the target fault detection conditions according to the tag dataset. The trained fault identification model is obtained by the server after training the target fault identification model according to the tag dataset. The edge computing update module is used to update the target fault detection conditions based on the optimized fault detection conditions, and to update the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used for subsequent fault identification by the vehicle.

10. A fault identification device, characterized in that, The device includes: The data receiving module is used to receive embedded data sent by the vehicle and screenshot data of the vehicle's screen. The embedded data and the screenshot data are obtained by the vehicle when the current state meets the target fault detection conditions corresponding to the display fault, and are sent when the target fault identification model determines that the vehicle has a fault based on the embedded data. The data annotation module is used to annotate the embedded data based on the screenshot data to obtain a tag dataset; The model training module is used to optimize the target fault detection conditions based on the label dataset to obtain optimized fault detection conditions, and to train the target fault identification model based on the label dataset to obtain the trained fault identification model. The training model distribution module is used to send the optimized fault detection conditions and the trained fault identification model to the vehicle, so that the vehicle updates the target fault detection conditions based on the optimized fault detection conditions and updates the target fault identification model based on the trained fault identification model. The updated target fault detection conditions and the target fault identification model are used by the vehicle for subsequent fault identification.

11. An electronic device, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the method as described in any one of claims 1-8.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1-8.

Images