Fault repairing method and first equipment

Abstract

The invention provides a fault recovery method and first equipment, and the method comprises the steps: obtaining a first state code of the first equipment in response to a fault of the first equipment; the first state code is used for representing the current operation stage of the first equipment; inputting the first state code into a fault model to obtain a fault repair measure corresponding to the first equipment; the fault model is trained according to a historical fault case set, and each historical fault case in the historical fault case set comprises a corresponding historical state code; and performing fault repair on the first equipment based on the fault repair measure.

Description

Technical Field

[0001] This application relates to a fault repair method and a first device. Background Technology

[0002] During the use of computer equipment, various hardware or software malfunctions are frequently encountered, such as abnormal system startup, interface failure, and system crashes. Since ordinary users typically lack the relevant technical background, they find it difficult to accurately diagnose and resolve these problems, often requiring reliance on technical support services provided by the manufacturer. This not only affects the user experience but also increases the burden of after-sales service. Summary of the Invention

[0003] This application provides a fault repair method and a first device.

[0004] The technical solution of this application is implemented as follows: In a first aspect, embodiments of this application provide a fault repair method, the method comprising: In response to a malfunction in the first device, the first status code of the first device is obtained; the first status code is used to characterize the current operating stage of the first device. The first status code is input into the fault model to obtain the fault repair measures corresponding to the first device; the fault model is trained based on the historical fault case set, and each historical fault case in the historical fault case set includes the corresponding historical status code; The first device was repaired based on the fault repair measures.

[0005] Secondly, embodiments of this application provide a first device, the first device comprising: Embedded controller; The processing component communicates with the embedded controller and is used for: In response to a malfunction in the first device, a first status code output by the embedded controller in the first device is obtained; the first status code is used to characterize the current operating stage of the first device. The first status code is input into the fault model to obtain the fault repair measures corresponding to the first device; the fault model is trained based on the historical fault case set, and each historical fault case in the historical fault case set includes the corresponding historical status code; The first device was repaired based on the fault repair measures.

[0006] This application provides a fault repair method and a first device. The method includes: in response to a fault occurring in the first device, obtaining a first status code of the first device; the first status code is used to characterize the current operating stage of the first device; inputting the first status code into a fault model to obtain fault repair measures corresponding to the first device; training the fault model based on a set of historical fault cases, each historical fault case in the set of historical fault cases including a corresponding historical status code; and performing fault repair on the first device based on the fault repair measures. Attached Figure Description

[0007] Figure 1 A fault repair method flow provided in the embodiments of this application Figure 1 ; Figure 2 A schematic diagram of the composition structure of an exemplary first device provided in this application embodiment; Figure 3 An exemplary correspondence diagram between a first status code, an operating stage, and a function is provided for embodiments of this application. Figure 4 A fault repair method flow provided in the embodiments of this application Figure 2 ; Figure 5 A schematic diagram of an exemplary device provided in this application embodiment. Figure 1 ; Figure 6 A schematic diagram of an exemplary device provided in this application embodiment. Figure 2 ; Figure 7 A schematic diagram of an exemplary device provided in this application embodiment. Figure 3 ; Figure 8 A fault repair method flow provided in the embodiments of this application Figure 3 ; Figure 9 A fault repair method flow provided in the embodiments of this application Figure 4 ; Figure 10 A flowchart illustrating an exemplary fault repair method provided in this application embodiment; Figure 11 This is a schematic diagram of the composition structure of a first device 1100 provided in an embodiment of this application.

[0008] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0009] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit the scope of this application.

[0010] Modern laptops and desktop computers inevitably encounter various malfunctions during use, such as black screens, crashes, inability to boot, fan malfunctions, and port failures. However, most users lack engineering backgrounds and have little knowledge of hardware circuit structures and software processes, making it impossible for them to diagnose the source of the problem themselves. This often results in users needing to report or send their devices for repair when malfunctions occur, significantly impacting the user experience and increasing after-sales costs for manufacturers.

[0011] Currently, some manufacturers provide self-testing and diagnostic software or online services for the Basic Input / Output System (BIOS) layer, but these methods have many drawbacks: 1. It can only detect surface or general problems, lacks in-depth fault understanding, and can only provide the most basic problem answers. In the end, users often have to send the product to offline after-sales service.

[0012] 2. Online customer service representatives are usually responsible for multiple products and cannot provide detailed and professional explanations of faults; their answers are often vague and general. Furthermore, users cannot obtain illustrated operation guides, which reduces the efficiency of problem resolution.

[0013] 3. The problem of information silos is serious; software and hardware designs and documentation are not truly integrated into the after-sales service process. However, directly distributing this information to users raises confidentiality concerns.

[0014] 4. Currently available artificial intelligence (AI) models are all open-source models, which are good at outputting general and common information, but they only understand publicly available information online. When the device itself has problems, they often cannot provide effective solutions.

[0015] 5. Currently, existing large AI models can only perform common operations such as cache clearing, meeting record document processing, and calling PC management interface. All operations rely on presets and rules and cannot proactively consider potential problems with the machine itself.

[0016] Based on the above problems, this application provides a fault repair method. Figure 1 A flowchart of a fault repair method provided in an embodiment of this application is shown below. Figure 1 As shown, the fault repair method may include the following steps S100 to S120: Step S100: In response to a fault in the first device, obtain the first status code of the first device; the first status code is used to characterize the current operating stage of the first device.

[0017] In this embodiment of the application, in response to a malfunction in the first device, the first device can obtain a first status code; the first status code is used to characterize the current operating stage of the first device.

[0018] It should be noted that the first device can be any type of device, such as a laptop, desktop computer, or server, and this embodiment does not limit it.

[0019] It should also be noted that the failure of the first device may be that the first device cannot start, or the first device has a black screen, or the fan of the first device is abnormal, etc. This embodiment does not limit it.

[0020] It should be noted that the reference Figure 2 This is a schematic diagram illustrating the composition of an exemplary first device according to an embodiment of this application. Figure 2 In this configuration, the display and speaker of the first device are connected to the Neural Processing Unit (NPU) + System on a Chip (SoC) via a switch, or to the Central Processing Unit (CPU). The NPU + SoC and the CPU communicate with the Embedded Controller (EC). The EC can obtain the running status of the Basic Input / Output System (BIOS) and / or Operating System (OS) in the first device. Furthermore, the CPU is connected to a power source, and the NPU + SoC can acquire the voltage and signals of the first device after it is powered on.

[0021] In some embodiments, in the event of a malfunction, the first device refers to Figure 2 Regardless of whether the first device fails in the BIOS stage or the OS stage, since the EC is the first component to be pulled up after the first device is powered on, the EC can output the first status code of the first device, whether the failure occurred in the BIOS stage or the OS stage.

[0022] It should be noted that the first status code can not only indicate whether the first device is currently experiencing a fault in the BIOS stage or the OS stage, but also indicate which node in the BIOS stage or which node in the OS stage the first device is experiencing a fault. This embodiment does not limit this.

[0023] It should also be noted that the first status code can be in hexadecimal format, such as P80. The first status code can accurately reflect a specific node in the hardware initialization process or software loading process that the first device is currently in. (See reference...) Figure 3 The first status code provided in this application is an example of the first status code (i.e. Figure 3 The diagram shows the correspondence between the POST codes in the BIOS and the running stages and functions. Taking the first status code as 40 as an example, it can be determined that the first device has encountered a fault when running the DXE_TCGDXE function in the DXE stage of the BIOS.

[0024] Step S110: Input the first status code into the fault model to obtain the fault repair measures corresponding to the first device; the fault model is trained based on the historical fault case set, and each historical fault case in the historical fault case set includes the corresponding historical status code.

[0025] In this embodiment of the application, the first device inputs the first status code into the fault model to obtain the fault repair measures corresponding to the first device.

[0026] It should be noted that since the fault model is trained based on a set of historical fault cases, each set of historical fault cases can include a fault case, the status code when the fault case occurred, the cause of the fault, and the corresponding repair measures. The set of historical fault cases can be obtained from the production line or during the manufacturer's after-sales process. For example, if a device malfunctions during startup and outputs a status code of "0506", and analysis reveals that the problem is caused by an unstable CPU power supply, and the problem is eventually solved by checking and replacing the inductor, the fault case corresponding to this device is included in the set of historical fault cases for training the fault model.

[0027] It should also be noted that the reference Figure 2 In some implementations, the fault model can typically be deployed on the NPU inside the first device. Since the NPU has low latency and high efficiency computing capabilities, it can promptly input the status code into the fault model after the device outputs a fault status code to predict the corresponding fault repair measures.

[0028] Step S120: Perform fault repair on the first device based on fault repair measures.

[0029] In this embodiment of the application, the first device performs fault repair based on fault repair measures.

[0030] In some embodiments, after obtaining fault repair measures, the first device can automatically repair its own faults based on the fault repair measures.

[0031] For example, if the fault model determines that the read-only memory (ROM) of the first device is damaged based on the first status code, then after obtaining the corresponding fault repair measures, the first device can prompt the user not to operate any buttons and wait for the first device to automatically complete the ROM recovery process based on the fault repair measures.

[0032] In other embodiments, when the first device is repairing its own faults based on fault repair measures, there may be measures that require user intervention. In this case, the first device can control the display and speaker through the NPU to provide the user with illustrated operation guides based on the display and speaker, reducing the risk of further damage caused by the user's blind operation.

[0033] It should be noted that, under certain special circumstances, the first device can also directly call the built-in function modules of the first device, such as the self-test program of the EC or BIOS, to assist in completing the fault repair task.

[0034] It should also be noted that if the first device fails to be repaired according to the predicted fault repair measures, the fault model can readjust the corresponding fault repair measures based on the current repair process, and then re-execute the fault repair of the first device based on the adjusted fault repair measures.

[0035] In some implementations, based on the above Figure 1 ,refer to Figure 4 The fault repair method provided in this embodiment may further include the following steps S400 to S420: Step S400: Obtain multiple historical fault cases corresponding to multiple devices; each historical fault case includes the historical status code of the corresponding device when the fault occurred, the historical fault cause, and the historical fault repair measures.

[0036] It should be noted that, during the production line or after-sales process from the manufacturer, for each faulty device, we can first obtain the current EC output status code (i.e., historical status code) of the faulty device, then record the cause of the faulty device's current failure (i.e., historical failure cause), and finally determine the fault repair measures taken when repairing the faulty device (i.e., historical failure repair measures). Thus, we can obtain a historical status code, a historical failure cause, and a fault repair measure for each faulty device, and obtain a historical failure case based on this.

[0037] Step S410: Generate a historical fault case set based on multiple historical fault cases.

[0038] In some embodiments, when multiple historical failure cases corresponding to multiple faulty devices are obtained, a historical failure case set can be generated based on the multiple historical failure cases.

[0039] It should be noted that when generating a historical fault case set based on multiple historical fault cases, identical historical fault cases can be merged, and some incomplete historical fault cases can be removed. This embodiment does not impose any limitations on this.

[0040] Step S420: Train the initial fault model using the historical fault case set to obtain the fault model.

[0041] In some embodiments, the initial fault model can be a machine learning model, such as a random forest or a support vector machine (SVM). Alternatively, the initial fault model can also be a deep learning model, such as a convolutional neural network (CNN) or a long short-term memory network (LSTM). This embodiment does not limit the specific model.

[0042] In some embodiments, step S400 may further include the following steps: obtaining a first part of historical fault cases corresponding to multiple devices in the BIOS stage, and a second part of historical fault cases corresponding to multiple devices in the OS stage; Among them, there are multiple historical failure cases, including the first part of historical failure cases and the second part of historical failure cases.

[0043] It's important to note that the BIOS is the firmware program that runs when a device boots up, primarily responsible for hardware initialization and system self-test. The first software process executed after the device powers on is the BIOS stage, which handles basic configuration and hardware checks before loading the operating system. BIOS stage failures typically manifest as inability to boot into the system, hardware recognition failures, or abnormal startup. Therefore, using historical failure cases from the first part of the BIOS stage to train the initial failure model can help the trained model better identify hardware-level problems.

[0044] It's also important to note that the OS phase refers to the system state after the operating system is loaded and running. OS phase failures can be caused by factors such as software conflicts, driver issues, and failed system updates, manifesting as system crashes, blue screens, and application crashes. Therefore, using the second part of historical failure cases from the OS phase to train the initial failure model can help the trained model better identify software-level problems in the device.

[0045] In some embodiments, step S420 may further include the following steps: obtaining device schematic diagrams corresponding to multiple devices; the device schematic diagrams include the connection relationships between the components of the devices; and training an initial fault model using a historical fault case set and the device schematic diagrams to obtain a fault model.

[0046] It should be noted that a device schematic diagram refers to a drawing or data file used to describe the internal structure and electrical connections of a device. This includes a Netlist file that records the connection methods between various components (such as the CPU, memory modules, and hard drive). (See reference...) Figure 5 Netlist is a structured text file that describes the name, model number, and connection nodes of each component to other components. Storing device schematics in Netlist format allows fault models to automatically parse and build the device's topology, thus supporting a more efficient fault identification process.

[0047] It should also be noted that the reference Figure 6 and Figure 7 The device schematic diagram may also include a circuit diagram used to record the circuit connection information between various components (such as CPU, memory modules, hard disk, etc.).

[0048] Understandably, a fault model trained on an initial fault model based on the equipment schematic and a set of historical fault cases can help to better pinpoint the cause of equipment failure.

[0049] For example, if a device outputs a status code when it malfunctions, the trained fault model can determine the circuit area that may be affected by the device schematic diagram, and quickly deduce the most likely cause of the fault by combining similar situations recorded in the historical fault case set.

[0050] In some embodiments, reference Figure 8 The above step S110 may include the following steps S800 to S820: Step S800: Input the first status code into the fault model, and use the first sub-model in the fault model to predict at least one fault cause corresponding to the first status code.

[0051] In some embodiments, the first sub-model can be trained based on the correspondence between historical status codes and fault causes in a historical fault case set. Based on this, after inputting the first status code into the fault model, the first sub-model can be used to determine at least one fault cause that may cause the first device to output the first status code.

[0052] For example, if the first status code obtained is 0283, 0283 is input into the fault model, and the first sub-model in the fault model can output at least one possible fault cause such as a short circuit in the solid state drive (SSD) connection or abnormal power supply to the motherboard.

[0053] Step S810: Using the second sub-model in the fault model, locate the first fault cause from at least one fault cause.

[0054] In some embodiments, the second sub-model can be trained based on the device schematic diagram. Therefore, the second sub-model can locate the most likely first fault cause from at least one fault cause output by the first sub-model, based on the first sub-model.

[0055] For example, if the first sub-model determines, based on the first status code, that there are no three possible causes of failure: ROM damage, SSB connection short circuit, and abnormal motherboard power supply, then the second sub-model can ultimately confirm one of the three possible causes as the most likely cause of failure by checking the ROM burning status, SSD interface voltage, and signal acquisition results of the motherboard power supply module.

[0056] Step S820: Using the third sub-model in the fault model, determine the fault repair measures corresponding to the first fault cause.

[0057] In some embodiments, the third sub-model can be trained based on the causes of failures and the corresponding fault repair measures in a historical failure case set. Therefore, when the second sub-model locates the first cause of failure, the third sub-model can provide fault repair measures for the first cause of failure.

[0058] For example, when the primary cause of the fault is identified as ROM damage, since the historical fault case set provides the corresponding fault repair measures in actual situations when the ROM is damaged, the third sub-model can directly provide the corresponding fault repair measures, such as plugging in the power adapter and waiting for automatic recovery, or rewriting the ROM, etc.

[0059] In some embodiments, reference Figure 9 The above step S810 may further include the following steps S900 to S920: Step S900: Using the second sub-model in the fault model, determine at least one set of components in the first device that are related to at least one fault cause according to the device schematic diagram.

[0060] In some embodiments, since the device schematic may include the connection relationships between components in the device, a set of components associated with each fault cause can be identified.

[0061] For example, if a fault is caused by a damaged ROM, then a group of components connected to the ROM can be identified based on the device schematic, such as the motherboard and the communication bus.

[0062] Step S910: Power on a portion of the circuit corresponding to each group of components to obtain the circuit acquisition information corresponding to each group of components; the circuit acquisition information includes one or more of the following: voltage information, current information, and timing information.

[0063] In some embodiments, since the device schematic may also include circuit connection information between components in the device, based on this, after determining a group of components associated with each fault cause, the circuit connection information between each group of components can be determined, and a portion of the circuit corresponding to each group of components can be powered on based on the circuit connection information between each group of components to obtain circuit acquisition information corresponding to each group of components, such as one or more of voltage information, current information and timing information.

[0064] It should be noted that the voltage information corresponding to each group of components can be used to determine whether the power supply to that group of components is normal, the current information corresponding to each group of components can be used to determine whether there is a short circuit or abnormal load in the circuit of that group of components, and the timing information corresponding to each group of components can be used to determine whether the signal transmission of that group of components is synchronized.

[0065] For example, if the cause of the fault is an abnormality in the Double Data Rate (DDR) interface, power can be supplied to the memory slots associated with DDR, and the power supply voltage, current changes, and timing behavior during the initialization process of the memory slots can be read. Based on this information, it can be determined whether there is an abnormality in the DDR interface.

[0066] Step S920: Based on the information collected from at least one circuit corresponding to at least one set of components, locate the first fault cause from at least one fault cause.

[0067] It should be noted that, based on the circuit information collected for each group of components, the most likely first fault cause can be located from at least one fault cause, and then the fault repair measures corresponding to the first fault cause can be output.

[0068] In some embodiments, step S120 may further include the following steps: determining a set of repair operations corresponding to the fault repair measures and a set of execution sequences corresponding to the set of repair operations; controlling the first device to execute a set of repair operations according to the set of execution sequences.

[0069] It should be noted that when determining the execution order of a set of repair operations in the fault repair measures, it can be based on the UX behavior document. Since the UX behavior document can be understood as the operation guide of the first device during use, the execution order of a set of repair operations can be determined according to the UX behavior document in the actual operation process, so that a set of repair operations can be automatically executed on the first device based on the execution order.

[0070] It should also be noted that if some repair operations in a set of repair operations require user participation, the NPU can control the display and speaker to show the repair operations that the user needs to perform on the display and to provide reminders through the speaker. Based on this, the fault repair of the first device can be achieved by having the user participate in the repair process.

[0071] This application provides a fault repair method, which includes: in response to a fault in a first device, obtaining a first status code of the first device; the first status code is used to characterize the current operating stage of the first device; inputting the first status code into a fault model to obtain fault repair measures corresponding to the first device; training the fault model based on a historical fault case set, wherein each historical fault case in the historical fault case set includes a corresponding historical status code; and performing fault repair on the first device based on the fault repair measures. By adopting the above implementation scheme, when a device malfunctions, the corresponding repair measures can be determined through the fault model, and the device itself can perform automated repair based on the repair measures, thereby improving fault handling efficiency and enhancing user experience.

[0072] Based on the above embodiments, this application explains the fault repair method in the above embodiments through an exemplary fault repair process.

[0073] This embodiment primarily integrates the BIOS / OS EC P80 code (status codes in the above embodiment), the issue case summary document library (historical fault case set in the above embodiment), and the hardware schematic diagram (device schematic diagram in the above embodiment) as the basic data source for fault model training. By combining the P80 code, historical fault cases, and circuit points, precise and targeted analysis of problem points can be achieved.

[0074] It should be noted that this application mainly includes modules such as document collection and input module, unified knowledge graph construction framework, model running module, fault monitoring module, user interaction module, and self-learning feedback mechanism.

[0075] 1. The document collection and input module can summarize the issue case summary document library, hardware schematics and BIOS / OSEC P80 codes to obtain the historical fault case set as described in the above embodiment.

[0076] 2. A unified knowledge graph construction framework can extract tag numbers (such as the index values ​​of components in a hardware schematic), component names, initialization steps, and state flowcharts (i.e., flowcharts of the device's operation process, which can be determined based on UX behavior documentation). This is then combined with relevant fault cases for classification.

[0077] 3. The model running module can deploy the fault model in the NPU and has graph retrieval capabilities.

[0078] 4. The fault monitoring module can be used to monitor temperature, fan speed, timing, voltage, current, BIOS behavior, etc., and can be understood as a key signal acquisition module.

[0079] 5. The user interaction module can be used to guide users to try certain methods to see if the problem can be resolved based on the fault repair measures.

[0080] 6. The self-learning feedback mechanism can be understood as recording fault repair paths to optimize the above fault model.

[0081] Based on the above embodiments, it should be noted that the P80 code of the BIOS / OS EC can be referenced. Figure 3 .

[0082] It should be noted that the historical failure case set may include: Case 1: Error code 0506 indicates unstable power supply related to the CPU core. The cause of the fault is a poor solder joint on a related inductor in the CPU core power supply, resulting in an open circuit.

[0083] Case 2: Error code 0808 indicates ROM initialization failure. The cause of the failure is that some ROMs on the production line failed to be burned, and the BIOS needs to be re-burned.

[0084] Case 3: Error code 0283, power on normally, but cannot enter the system, pointing to the Peripheral Component Interconnect Express (PCIE) related device, the cause of the failure is a short circuit in the SSD interface.

[0085] It should be noted that the reference Figure 5 The circuit netlist file (i.e., device schematic / hardware schematic) specifies the connection relationships of each device.

[0086] It should be noted that the reference Figure 6 and Figure 7 The signal acquisition circuit can work in conjunction with the signal acquisition circuit on the key circuit to acquire information.

[0087] To better illustrate the practical application scenarios of this application, the following are some typical fault handling examples: Bug Example 1 An improper shutdown by the user caused the computer to fail to boot on the second attempt, resulting in a blank screen. The NPU read the EC post code (0066) and found no abnormalities in any power supply status. The NPU's fault model determined that the cause of the failure was a corrupted BIOS ROM, requiring repair. At this point, the NPU can take over display control, displaying a message informing the user that the ROM is corrupted and instructing them to connect the power supply and refrain from pressing any buttons. The NPU can also instruct the EC and BIOS modules to initiate the ROM recovery function.

[0088] Bug Example 2 When the user's computer boots up but the screen is not displayed, the NPU reads the EC postcode. If the system detects that the BIOS code is not running (i.e., no status code is output), the NPU can collect relevant data through the circuitry, check the voltage on each power rail and the power-on sequence status, and then analyze the data in conjunction with the fault model to deduce which component may be faulty.

[0089] If the current is high during the voltage rise process and the voltage fails to rise, it indicates a short circuit in the circuit. The NPU can prompt the user to send the device to a service center for inspection and report the short circuit fault to the back-end maintenance team. The NPU can also remind relevant personnel to pay attention to this short circuit fault.

[0090] If all voltages are normal, and the device detects a normal screen voltage but zero current, the screen itself may be damaged, or there may be an open circuit in the motherboard's control unit that manages the screen. In this case, the NPU can issue an audible alert to the user, suggesting that they rotate the screen hinge to check for current fluctuations in the relevant circuitry, thus determining whether the problem lies with the ribbon cable.

[0091] Bug Example 3 The user found that their purchased DDR memory wouldn't power on after being installed on the motherboard. The NPU read the EC postcode as 0282. If the Surge Protective Device (SPD) module detects that the power supply and related voltages are within normal ranges, it indicates a potential defect in the DDR memory. The NPU can display a message indicating a DDR initialization failure and suggest replacing the DDR memory module. If the SPD communication is abnormal but the voltage is within normal range, the NPU can indicate a problem with the DDR module installation and suggest reinstalling it. If the voltage is abnormal, the user should check for short circuits in the surrounding area or the slot.

[0092] Bug Example 4 The device fails to power on after entering hibernation. The NPU reads the EC postcode as 0002. The critical reset signal PLTRST# is not issued, and the fault model predicts the cause as an abnormal CPU state. In this situation, the NPU can notify the EC to enter the recovery procedure. Perform the following operations: shut down all power, pull the Real-Time Clock Reset (RTC RST) signal low, and then rerun the power-on initialization process.

[0093] Based on the above example, refer to Figure 10 The specific fault repair process may include the following steps S1000 to S1050: Step S1000: Determine that the equipment has malfunctioned.

[0094] Step S1010: Read P80 code and EC status.

[0095] Step S1020: Locate the cause of the fault using the fault model.

[0096] Step S1030: Does circuit testing need to be performed?

[0097] It should be noted that if "No", proceed to step S1050; if "Yes", proceed to step S1040.

[0098] Step S1040: Read voltage, current and timing information.

[0099] Step S1050: Output fault repair measures.

[0100] It should be noted that fault repair measures can be output directly, or they can be output after circuit testing, in combination with voltage, current and timing information.

[0101] In summary, this application has the following innovative points: 1. Currently, there is no solution that integrates device schematics, EC code structure documents, BIOS documents, and user behavior documents into a large AI model to form a "device self-explanation + guidance" system.

[0102] 2. Users have increasing demands for device explainability and self-service maintenance, which urgently requires the integration of AI tools to form a new system. For example, the ability of humans to write code is already very practical, and machines are also excellent at reading local code, which can tell users the specific possible causes. For identified bugs, they can be submitted to the system for maintenance in the background, which will facilitate push notifications later.

[0103] 3. Users can visually view and receive step-by-step operation suggestions, reducing the likelihood of damage caused by blind operation and resulting in invalid complaints.

[0104] 4. The trained fault model can identify the problem point by combining drawings / circuit reference numbers / BIOS process, improving the efficiency of the after-sales team and shortening the user's repair waiting time.

[0105] Based on the above embodiments, in another embodiment of this application, a first device 1100 is provided. Figure 11 A schematic diagram of the composition structure of a first device 1100 provided in this application is shown below. Figure 11 As shown, the first device 1100 includes: Embedded controller 1110; Processing component 1120, which is communicatively connected to embedded controller 1110, is used for: In response to a malfunction in the first device, the first status code output by the embedded controller 1110 in the first device is obtained; the first status code is used to characterize the current operating stage of the first device. The first status code is input into the fault model to obtain the fault repair measures corresponding to the first device; the fault model is trained based on the historical fault case set, and each historical fault case in the historical fault case set includes the corresponding historical status code; The first device was repaired based on the fault repair measures.

[0106] In some embodiments, the processing component 1120 is further configured to: obtain multiple historical fault cases corresponding to multiple devices; each historical fault case includes the historical status code of the corresponding device when the fault occurred, the historical fault cause and the historical fault repair measures; generate a historical fault case set based on the multiple historical fault cases; and train an initial fault model using the historical fault case set to obtain a fault model.

[0107] In some embodiments, the processing component 1120 is further configured to: obtain a first part of historical fault cases corresponding to a plurality of devices in the BIOS stage, and a second part of historical fault cases corresponding to a plurality of devices in the OS stage; wherein the plurality of historical fault cases include the first part of historical fault cases and the second part of historical fault cases.

[0108] In some embodiments, the processing component 1120 is further configured to: acquire device schematic diagrams corresponding to multiple devices; the device schematic diagrams include connection relationships between components of the devices and circuit connection information; and train an initial fault model using a historical fault case set and the device schematic diagrams to obtain a fault model.

[0109] In some embodiments, the processing component 1120 is further configured to: input a first status code into a fault model; predict at least one fault cause corresponding to the first status code using a first sub-model in the fault model; locate the first fault cause from at least one fault cause using a second sub-model in the fault model; and determine the fault repair measures corresponding to the first fault cause using a third sub-model in the fault model.

[0110] In some embodiments, the processing component 1120 is further configured to: use a second sub-model in the fault model to determine, according to the device schematic diagram, at least one group of components in the first device that are related to at least one fault cause; power on a portion of the circuit corresponding to each group of components to obtain circuit acquisition information corresponding to each group of components; the circuit acquisition information includes one or more of voltage information, current information and timing information; and locate the first fault cause from at least one fault cause based on at least one circuit acquisition information corresponding to at least one group of components.

[0111] In some embodiments, the processing component 1120 is further configured to: determine a set of repair operations corresponding to the fault repair measures and a set of execution sequences corresponding to the set of repair operations; and control the first device to execute the set of repair operations in a set of execution sequences.

[0112] This application provides a computer-readable storage medium storing one or more programs, which can be executed by one or more processors and applied to the processing component of a first device. The computer program implements the fault repair method described above.

[0113] This application provides a computer program product that stores one or more program instructions, which can be executed by one or more processors and applied to the processing component of a first device. The computer program implements the fault repair method described above.

[0114] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0115] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0116] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0117] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0118] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0119] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0120] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, random access memory (RAM), magnetic disks, or optical disks.

[0121] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A fault repair method, the method comprising: In response to a malfunction in the first device, the first status code of the first device is obtained; The first status code is used to characterize the current operating stage of the first device; Input the first status code into the fault model to obtain the fault repair measures corresponding to the first device; The fault model is trained based on a set of historical fault cases, and each historical fault case in the set includes a corresponding historical status code. The fault repair measures are used to repair the fault in the first device.

2. The method according to claim 1, wherein, The method further includes: Obtain multiple historical fault cases corresponding to multiple devices; each historical fault case includes the historical status code of the corresponding device when the fault occurred, the historical fault cause, and the historical fault repair measures; A historical failure case set is generated based on the multiple historical failure cases; The initial fault model is trained using the historical fault case set to obtain the fault model.

3. The method according to claim 2, wherein, The acquisition of multiple historical fault cases corresponding to multiple devices includes: Obtain a first part of historical fault cases corresponding to the multiple devices in the Basic Input / Output System (BIOS) stage, and a second part of historical fault cases corresponding to the multiple devices in the Operating System (OS) stage; The plurality of historical fault cases include the first part of historical fault cases and the second part of historical fault cases.

4. The method according to claim 2 or 3, wherein, The process of training an initial fault model using the historical fault case set to obtain the fault model includes: Obtain the device schematic diagrams corresponding to the plurality of devices; the device schematic diagrams include the connection relationships between the components of the devices and the circuit connection information. The initial fault model is trained using the historical fault case set and the equipment schematic diagram to obtain the fault model.

5. The method according to claim 4, wherein, The step of inputting the first status code into the fault model to obtain the fault repair measures corresponding to the first device includes: The first status code is input into the fault model, and the first sub-model in the fault model is used to predict at least one fault cause corresponding to the first status code. Using the second sub-model in the fault model, the first fault cause is located from the at least one fault cause; Using the third sub-model in the fault model, the fault repair measures corresponding to the cause of the first fault are determined.

6. The method according to claim 5, wherein, The step of using the second sub-model in the fault model to locate the first fault cause from the at least one fault cause includes: Using the second sub-model in the fault model, determine at least one group of components in the first device that are related to the at least one fault cause, according to the device schematic diagram; Power on a portion of the circuit corresponding to each group of components to obtain circuit acquisition information corresponding to each group of components; the circuit acquisition information includes one or more of voltage information, current information, and timing information. Based on the information collected from at least one circuit corresponding to the at least one set of components, the first fault cause is located from the at least one fault cause.

7. The method according to claim 1, wherein, The fault repair of the first device based on the fault repair measures includes: Determine a set of repair operations corresponding to the fault repair measures and a set of execution sequences corresponding to the set of repair operations; Control the first device to execute the set of repair operations in the set of execution order.

8. A first device, the first device comprising: Embedded controller; A processing component, which is communicatively connected to the embedded controller, is used for: In response to a malfunction in the first device, a first status code output by the embedded controller in the first device is obtained; the first status code is used to characterize the current operating stage of the first device. Input the first status code into the fault model to obtain the fault repair measures corresponding to the first device; The fault model is trained based on a set of historical fault cases, and each historical fault case in the set includes a corresponding historical status code. The fault repair measures are used to repair the fault in the first device.

9. The first device according to claim 8, wherein the processing component is further configured to: Obtain multiple historical fault cases corresponding to multiple devices; each historical fault case includes the historical status code of the corresponding device when the fault occurred, the historical fault cause, and the historical fault repair measures; A historical failure case set is generated based on the multiple historical failure cases; The initial fault model is trained using the historical fault case set to obtain the fault model.

10. The first device according to claim 8 or 9, wherein the processing component is further configured to: Obtain the first part of historical fault cases corresponding to the multiple devices in the BIOS stage, and the second part of historical fault cases corresponding to the multiple devices in the OS stage; in, The multiple historical fault cases include the first part of historical fault cases and the second part of historical fault cases.

Images