Method for detecting device failure, related apparatus and system

Abstract

The application discloses a method for detecting equipment failure, a related device and system. In the method, when an electronic device fails, another electronic device can be used to detect the failure of the electronic device. The method has low requirements for other electronic devices that fail, and can accurately and quickly detect the failure even if the detected electronic device has limited running space, does not have self-checking capability, is not configured with an input device, or is large in size and not easy to carry. The method is suitable for any type of electronic device, can conveniently detect failure, and ordinary users can independently initiate failure detection, thereby improving operability and convenience, reducing the dependence of users on after-sales service, and improving user experience.

Description

Technical Field

[0001] This application relates to the fields of terminal technology and communication technology, and in particular to methods, devices and systems for detecting equipment failures. Background Technology

[0002] With the rapid development of electronic devices, their functions are becoming increasingly complex. Hardware and software malfunctions are inevitable during user interaction. When some slim devices, such as smartwatches and smart bracelets, malfunction, they cannot perform self-diagnostics, requiring users to visit authorized service centers or contact customer service for assistance. Finding the true cause of a malfunction accurately and quickly without needing to visit authorized service centers or contact customer service is crucial for targeted problem-solving and improving user experience, and is a pressing issue that needs to be addressed now and in the future. Summary of the Invention

[0003] This application provides a method, related apparatus and system for detecting equipment failures, which can use one electronic device to detect the failure of another electronic device, making failure detection more convenient, improving operability and ease of use, reducing users' reliance on after-sales service, and thus improving user experience.

[0004] In a first aspect, embodiments of this application provide a method for detecting device faults. The method is applied to a first device and includes: receiving a first operation to detect a second device; acquiring operating data of the second device, the operating data of the second device including one or more of the following: log data, hardware data, or system configuration information; determining a first fault of the second device based on first information and the operating data of the second device, wherein the first information describes the logical relationship between the fault and the cause of the fault in the second device.

[0005] The method provided in the first aspect utilizes an electronic device to detect faults in other electronic devices. It has low requirements for the other electronic devices that are malfunctioning. Even if the electronic device under test has limited operating space, lacks self-testing capabilities, is not equipped with an input device, or is large and difficult to move, this detection method can accurately and quickly detect the faults.

[0006] In conjunction with the first aspect, the second device can be either a thin device or a rich device. A device with limited memory and operating space and lacking self-testing capabilities can be called a thin device, while a device with large operating space and self-testing capabilities can be called a rich device.

[0007] In other words, the detection method provided in the first aspect is applicable to any type of electronic device, which can facilitate fault detection. Ordinary users can initiate fault detection independently, which improves operability and convenience, reduces users' dependence on after-sales service, and thus enhances user experience.

[0008] In conjunction with the first aspect, in some implementations, after the first device determines the first fault of the second device, it can also output indication information of the first fault. This allows the first device to intuitively display the detected fault information of the second device to the user, facilitating the user's subsequent troubleshooting.

[0009] In conjunction with the first aspect, in some implementations, after the first device determines the first fault of the second device, it can also obtain the corresponding solution for the first fault from the cloud platform and output the solution. This allows the solution to be provided to the user intuitively, facilitating subsequent fault repair.

[0010] In conjunction with the first aspect, in some implementations, after the first device determines the first fault of the second device, it can also obtain a solution corresponding to the first fault from the cloud platform and send the solution to the second device for the second device to repair the first fault. This allows the second device to repair the first fault based on the solution.

[0011] In conjunction with the first aspect, in some embodiments, before the first device receives the first operation to detect the second device, it may also display a first user interface showing options for the second device; wherein the first operation includes a user operation on the options of the second device. In this way, the first device can respond to the user's operation on the first user interface and begin fault detection of the second device.

[0012] In conjunction with the first aspect, in some embodiments, the first device can perform overall fault detection on the second device. Specifically, after receiving a first operation to detect the second device, and before acquiring the operating data of the second device, the first device, in response to the first operation, displays a second user interface, which includes a first control; and receives a user operation applied to the first control. Then, the first device can respond to the user operation applied to the first control to perform overall fault detection on the second device.

[0013] In conjunction with the previous implementation, in one possible scheme, before the first device determines the first fault of the second device, it can obtain first information in the following manner: obtain one or more of the following information: device type, device model, software system type or software system version of the second device; and obtain first information from the cloud platform based on one or more of the information, wherein the first information describes the logical relationship between the fault and the cause of the fault corresponding to one or more of the information.

[0014] In conjunction with the first aspect, in some embodiments, the first device can perform targeted fault detection on the second device. Specifically, after receiving a first operation to detect the second device, and before acquiring the operating data of the second device, the first device, in response to the first operation, displays a second user interface, which includes a first control; in response to a user operation applied to the first control, it displays a third user interface, which displays one or more detection items of the second device; and it receives a user operation applied to the first detection item among the one or more detection items. In this way, the first device can perform targeted fault detection on the first detection item of the second device.

[0015] In conjunction with the previous implementation, in one possible solution, before the first device displays the third user interface, one or more detection items of the second device can also be obtained through any of the following methods:

[0016] 1. Obtain one or more detection items from the second device.

[0017] 2. Obtain the device information of the second device, and based on the device information of the second device, obtain one or more detection items of the second device from the cloud platform.

[0018] 3. Obtain the device information of the second device; obtain the correspondence between multiple different device information and detection items from the cloud platform; from the correspondence between multiple different device information and detection items, determine the detection items corresponding to the device information of the second device as one or more detection items.

[0019] The equipment information includes one or more of the following: equipment type, equipment model, software system type or software system version number, and region.

[0020] In conjunction with the previous implementation, in one possible approach, the first information describes the logical relationship between the fault corresponding to the first detection item and the fault cause. Before the first device determines the first fault of the second device, the first information can be obtained in any of the following ways:

[0021] 1. In response to a user action applied to the first detection item, obtain the first information from the cloud platform.

[0022] 2. Before the first device displays the third user interface, it retrieves information corresponding to one or more detection items from the cloud platform; wherein, the first information is the information corresponding to the first detection item from among the information corresponding to the one or more detection items. This allows the necessary information for fault detection to be downloaded in advance, improving the efficiency of fault detection.

[0023] In conjunction with the first aspect, in some implementations, the first device may also have the first information pre-downloaded or pre-set, which can improve the efficiency of fault detection.

[0024] In conjunction with the first aspect, in some implementations, the first device can establish a communication connection with the second device before acquiring the second device's operational data. The first and second devices can establish a short-range connection via BT, WLAN (such as Wi-Fi P2P), NFC, ZigBee, etc., or they can establish a remote connection by logging into the same account.

[0025] Secondly, embodiments of this application provide a method for detecting device faults. The method is applied to a communication system including a first device and a third device. The method includes: the first device receiving a second operation acting on the detection of the third device and sending a fault detection command to the third device; the third device responding to the fault detection command and acquiring the operating data of the third device, the operating data of the third device including one or more of the following: log data, hardware data, or system configuration information; the third device determining a second fault of the third device based on the second information and the operating data of the third device, the second information describing the logical relationship between the fault and the cause of the fault of the third device.

[0026] By implementing the method provided in the second aspect, the first device can trigger the third device to perform fault detection. The first device has a function similar to a smart remote control, and the user can initiate fault detection of other devices, such as the third device, from the first device.

[0027] In conjunction with the second aspect, the third device can be a rich device. That is to say, the detection method provided in the second aspect is applicable to rich devices, which can facilitate fault detection. Ordinary users can independently initiate fault detection, improving operability and convenience, reducing users' reliance on after-sales service, and thus enhancing the user experience.

[0028] In conjunction with the second aspect, in some implementations, after the third device determines the second fault, it can send the indication information of the second fault to the first device; the first device then outputs the indication information of the second fault. This allows the first device to intuitively display the detected fault information of the third device to the user, facilitating subsequent fault repair.

[0029] In conjunction with the second aspect, in some implementations, after the third device identifies the second fault, it can also send the indication information of the second fault to the first device; the first device retrieves the solution corresponding to the second fault from the cloud platform; and the first device outputs the solution. This allows the solution to be provided to the user intuitively, facilitating subsequent fault repair.

[0030] In conjunction with the second aspect, in some implementations, after the first device obtains the solution corresponding to the second fault from the cloud platform, it can also send the solution to the third device; the third device then repairs the second fault according to the solution. This allows the third device to directly repair the second fault based on the solution.

[0031] In conjunction with the second aspect, in some embodiments, before the first device receives the second operation to detect the third device, it may also display a first user interface showing options for the third device; wherein the second operation includes a user action on the options of the third device. In this way, the first device can trigger the third device to perform self-fault detection in response to the user's operation on the first user interface.

[0032] In conjunction with the second aspect, in some implementations, the first device can trigger the third device to perform overall fault detection. Specifically, after receiving the second operation of the option applied to the third device, and before sending a fault detection command to the third device, the first device can respond to the second operation by displaying a fourth user interface (…). Figure 4A The fourth user interface includes a second control (401a); the first device receives a user operation applied to the second control. Subsequently, the first device can send a fault detection command to the third device, which triggers the third device to perform an overall fault detection.

[0033] In conjunction with the previous implementation, in one possible scheme, before the third device determines the second fault, it can obtain the second information in the following manner: the third device obtains one or more of the following information: the device type, device model, software system type, or software system version of the third device; the third device obtains the second information from the cloud platform based on one or more of the information, and the second information describes the logical relationship between the fault and the cause of the fault corresponding to one or more of the information.

[0034] In conjunction with the second aspect, in some implementations, the first device can trigger the third device to perform targeted fault detection. Specifically, after receiving a second operation applied to the option on the third device, the first device can respond to the second operation by displaying a fourth user interface, which includes a second control; in response to a user operation applied to the second control, the first device can display a fifth user interface, which displays one or more detection items of the third device; the first device receives a user operation applied to the second detection item among the one or more detection items. Then, the first device can send a fault detection command to the third device, which carries indication information for the second detection item. In this way, the first device can trigger the third device to perform targeted fault detection on the second detection item.

[0035] In conjunction with the previous implementation, in one possible solution, before the first device displays the fifth user interface, one or more detection items of the third device can also be obtained through any of the following methods:

[0036] 1. The first device obtains one or more detection items from the third device.

[0037] 2. The first device obtains the device information of the third device, and based on the device information of the third device, obtains one or more detection items of the third device from the cloud platform.

[0038] 3. The first device obtains the device information of the third device; obtains the correspondence between multiple different device information and detection items from the cloud platform; and determines the detection items corresponding to the device information of the third device as one or more detection items from the correspondence between multiple different device information and detection items.

[0039] The equipment information includes one or more of the following: equipment type, equipment model, software system type or software system version number, and region.

[0040] In conjunction with the previous implementation, in one possible solution, the second information describes the logical relationship between the fault corresponding to the second detection item and the fault cause. Before the third device determines the second fault, it can obtain the second information in any of the following ways:

[0041] 1. The third device responds to the user operation applied to the second detection item and obtains the second information from the cloud platform.

[0042] 2. The third device retrieves information corresponding to one or more detection items from the cloud platform; wherein, the second information is the information corresponding to the second detection item from the information corresponding to the one or more detection items. This allows the necessary information for fault detection to be downloaded in advance, improving the efficiency of fault detection.

[0043] In conjunction with the second aspect, in some implementations, the third device may also download or have a threshold for the second information in advance, which can improve the efficiency of fault detection.

[0044] In conjunction with the second aspect, in some implementations, the first device can establish a communication connection with the third device before sending a fault detection command to the third device. The first device and the third device can establish a short-range connection via BT, WLAN (such as Wi-Fi P2P), NFC, ZigBee, etc., or they can establish a remote connection by logging into the same account.

[0045] Thirdly, embodiments of this application provide a fault detection method applied to a first device. The method includes: the first device receiving a second operation acting on a third device, and sending a fault detection command to the third device, the fault detection command being used to trigger the third device to perform fault detection.

[0046] The specific implementation of the method in the third aspect can be found in the implementation of the method described in the second aspect on the first device side, and will not be repeated here.

[0047] Fourthly, embodiments of this application provide a fault detection method applied to a third device. The method includes: the third device receiving a fault detection command sent by a first device; the third device responding to the fault detection command by acquiring operational data of the third device, the operational data of the third device including one or more of the following: log data, hardware data, or system configuration information; and the third device determining a second fault of the third device based on second information and the operational data of the third device, the second information describing the logical relationship between the corresponding fault and its cause.

[0048] The specific implementation of the method in the fourth aspect can be found in the implementation of the method described in the second aspect on the third device side, and will not be repeated here.

[0049] Fifthly, embodiments of this application provide a fault detection method applied to a first device. The first device and a fourth device work collaboratively. The method includes: receiving a third operation; acquiring operating data from the fourth device and operating data from the first device, the operating data including one or more of the following: log data, hardware data, or system configuration information; determining a third fault based on the third information, the operating data from the fourth device, and the operating data from the first device, wherein the third information describes the logical relationship between the fault and the cause of the fault corresponding to a first scenario in which the first device and the fourth device work collaboratively.

[0050] By implementing the method provided in the fifth aspect, the first device can perform joint fault detection by integrating the operating data of various devices involved in the collaborative work scenario. This can accurately detect faults in the collaborative work scenario, reduce users' reliance on customer service and after-sales service, and improve user experience.

[0051] In collaborative work scenarios, the methods provided in the fifth aspect can comprehensively detect faults. For example, in a collaborative work scenario, each of the individual devices may be functioning correctly, but a fault may occur when they work together. In this case, the methods provided in the fifth aspect can accurately detect the fault.

[0052] In conjunction with the fifth aspect, the fourth device can be either a thin device or a rich device.

[0053] The collaborative working scenario between the first and fourth devices, i.e., the first scenario, may include screen projection, projection, multi-screen collaboration, etc. For example, the first device can be a mobile phone, and the fourth device can be a smart screen or projector, etc.

[0054] In conjunction with the fifth aspect, the third fault may occur on the first equipment side or on the fourth equipment side; no limitation is made here.

[0055] In conjunction with the fifth aspect, in some implementations, after the first device determines the third fault, it can also output indication information of the third fault. This allows the first device to intuitively display the fault information detected in the first scenario to the user, facilitating the user's subsequent fault repair.

[0056] In conjunction with the fifth aspect, in some implementations, after the first device identifies the third fault, it can also retrieve the corresponding solution from the cloud platform and output the solution. This allows the solution to be provided to the user intuitively, facilitating subsequent fault repair.

[0057] In conjunction with the fifth aspect, in some implementations, after the first device identifies the third fault, it can also obtain a solution corresponding to the third fault from the cloud platform and send the solution to the fourth device for the fourth device to repair the third fault; or, the first device repairs the third fault according to the solution. This allows either the first device or the fourth device to repair the third fault based on the solution.

[0058] In conjunction with the fifth aspect, in some embodiments, before the first device receives the third operation, a first user interface may be displayed, showing options for the fourth device; wherein the third operation includes a user operation on the options of the fourth device. In this way, the first device can respond to the user's operation on the first user interface and begin joint fault detection of both the first and fourth devices.

[0059] In conjunction with the fifth aspect, in some embodiments, the first device can perform overall joint fault detection. Specifically, after receiving the third operation and before acquiring the operating data of the fourth device and the first device, the first device can also respond to the third operation by displaying a sixth user interface, which includes a third control; and receive user operations applied to the third control. Afterward, the first device can respond to the user operations applied to the third control and begin joint fault detection of both the first and fourth devices.

[0060] In conjunction with the previous implementation, in one possible scheme, before the first device determines the third fault, it can obtain the third information in the following manner: obtain one or more of the following information: the device type, device model, software system type or software system version of the first device, and the device type, device model, software system type or software system version of the fourth device; based on one or more of the information, obtain the third information from the cloud platform, wherein the third information describes the logical relationship between the fault and the cause of the fault corresponding to one or more of the information.

[0061] In conjunction with the fifth aspect, in some implementations, the first device can perform targeted joint fault detection. Specifically, after receiving the third operation but before acquiring the operating data of the fourth device and the first device, the first device can respond to the third operation by displaying a sixth user interface, which includes a third control; responding to user operations applied to the third control, it can display a seventh user interface, which displays one or more detection items corresponding to the first scenario; and receive user operations applied to the third detection item among the one or more detection items. In this way, the first device can perform targeted joint fault detection on the third detection item in the collaborative work scenario.

[0062] In conjunction with the previous implementation, in one possible solution, before the first device displays the seventh user interface, one or more detectable items in the collaborative work scenario can be acquired through any of the following methods:

[0063] 1. Obtain the device information of the fourth device and the device information of the first device, and obtain one or more detection items from the cloud platform based on the device information of the fourth device and the device information of the first device.

[0064] 2. Obtain the device information of the fourth device and the device information of the first device; obtain the correspondence between multiple different device information and detection items in the first scenario from the cloud platform; determine one or more detection items from the correspondence between the device information of the fourth device and the device information of the first device.

[0065] The equipment information includes one or more of the following: equipment type, equipment model, software system type or software system version number, and region.

[0066] In conjunction with the previous implementation, in one possible solution, the third information describes the logical relationship between the fault and the cause of the fault corresponding to the third detection item in the first scenario. Before determining the third fault, the first device can obtain the third information in any of the following ways:

[0067] 1. In response to user actions applied to the third detection item, obtain third information from the cloud platform.

[0068] 2. Before the first device displays the seventh user interface, it retrieves information corresponding to one or more detection items in the first scenario from the cloud platform; among which, the third information is the information corresponding to the third detection item from the information corresponding to one or more detection items in the first scenario. This allows for the pre-downloading of the information required for fault detection, improving the efficiency of fault detection.

[0069] In conjunction with the fifth aspect, in some implementations, the first device may also download or pre-set third information in advance, which can improve the efficiency of fault detection.

[0070] In conjunction with the fifth aspect, in some embodiments, the first device can establish a communication connection with the fourth device before acquiring the fourth device's operational data. The first device and the fourth device can establish a short-range connection via BT, WLAN (such as Wi-Fi P2P), NFC, ZigBee, etc., or they can establish a remote connection by logging into the same account.

[0071] In a sixth aspect, embodiments of this application provide an electronic device, including: a memory and one or more processors; the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the electronic device to perform the method described in the first aspect or any one of the first aspects, or, the third aspect or any one of the third aspects, or, the fourth aspect or any one of the fourth aspects, or the fifth aspect or any one of the fifth aspects.

[0072] In a seventh aspect, embodiments of this application provide a communication system including a first device and a second device, wherein the first device is used to perform the method as described in the first aspect or any embodiment of the first aspect.

[0073] Eighthly, embodiments of this application provide a communication system including a first device and a third device. The first device is used to perform the method described in the third aspect or any embodiment of the third aspect, and the third device is used to perform the method described in the fourth aspect or any embodiment of the fourth aspect.

[0074] Ninthly, embodiments of this application provide a communication system including a first device and a fourth device, the first device being configured to perform the method as described in the fifth aspect or any embodiment of the fifth aspect.

[0075] In conjunction with the seventh, eighth, or ninth aspects, in some embodiments, the communication system also includes a cloud platform.

[0076] In a tenth aspect, embodiments of this application provide a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect or any one of the embodiments of the first aspect, or the third aspect or any one of the embodiments of the third aspect, or the fourth aspect or any one of the embodiments of the fourth aspect, or the fifth aspect or any one of the embodiments of the fifth aspect.

[0077] In the eleventh aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect or any one of the first aspects, or the third aspect or any one of the third aspects, or the fourth aspect or any one of the fourth aspects, or the fifth aspect or any one of the fifth aspects.

[0078] By implementing the technical solutions provided in the embodiments of this application, one electronic device can be used to detect the faults of another electronic device, which can facilitate fault detection, improve operability and convenience, reduce users' dependence on after-sales service, and thus enhance user experience. Attached Figure Description

[0079] Figure 1 This is a schematic diagram of the communication system provided in an embodiment of this application;

[0080] Figure 2A This is a schematic diagram of the structure of the electronic device 100 provided in the embodiments of this application;

[0081] Figure 2B This is a schematic diagram of the structure of the cloud platform 500 provided in the embodiments of this application;

[0082] Figure 2C A schematic diagram of the software structure of the electronic device 100 and the cloud platform 500 provided in the embodiments of this application;

[0083] Figures 3A-3H A series of user interfaces involved in the electronic device 100 provided in this application for fault detection of a smartwatch;

[0084] Figures 4A-4F A series of user interfaces involved in triggering a tablet computer to perform fault detection by the electronic device 100 provided in the embodiments of this application;

[0085] Figures 5A-5E The electronic device 100 provided in this application provides a series of user interfaces involved in joint fault detection of devices involved in a screen projection scenario;

[0086] Figure 6AThis is a schematic diagram of the communication interface between electronic device 100, electronic device 200, and cloud platform 500 provided in Embodiment 1;

[0087] Figure 6B This is a flowchart illustrating the equipment fault detection method provided in Example 1;

[0088] Figure 7A This is a schematic diagram of the communication interface between electronic device 100, electronic device 300, and cloud platform 500 provided in Embodiment 2;

[0089] Figure 7B This is a flowchart illustrating the equipment fault detection method provided in Example 2;

[0090] Figure 8A This is a schematic diagram of the communication interface between electronic device 100, electronic device 400, and cloud platform 500 provided in Embodiment 3;

[0091] Figure 8B This is a flowchart illustrating the equipment fault detection method provided in Example 3. Detailed Implementation

[0092] The technical solutions in the embodiments of this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text 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, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0093] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0094] The term "user interface (UI)" used in the following embodiments of this application refers to the medium interface through which an application or operating system interacts and exchanges information with the user. It realizes the conversion between the internal form of information and the form that the user can accept. The user interface is source code written in a specific computer language such as Java or Extensible Markup Language (XML). The interface source code is parsed and rendered on the electronic device, ultimately presenting content that the user can recognize. A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operation displayed graphically. It can be visible interface elements such as text, icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, and widgets displayed on the screen of an electronic device.

[0095] The main methods for fault detection in electronic equipment are as follows:

[0096] 1. Self-diagnosis. Electronic devices can be equipped with a fault detection application (APP), which can automatically perform fault detection when a fault occurs.

[0097] 2. Remote detection. The user enters a verification code into the electronic device, triggering the device to initiate a corresponding fault detection. This verification code can be obtained by the user from the cloud platform.

[0098] 3. Service Center Inspection. Electronic devices undergo fault detection at service centers using professional testing equipment.

[0099] For electronic devices that are developing at an increasingly rapid pace, the three fault detection methods mentioned above cannot accurately and quickly find the faults that exist in the electronic devices.

[0100] The first option mentioned above requires that the electronic device has space to install and run the fault detection APP, and is not suitable for devices with limited memory and running space or without self-testing capabilities.

[0101] The second option mentioned above requires the electronic device to be equipped with a display screen or other input device, and is not applicable to electronic devices that do not have input devices.

[0102] The third option mentioned above requires users to send the malfunctioning electronic device to a service center, and is not applicable to large or difficult-to-move electronic devices.

[0103] To accurately, quickly, and conveniently locate and resolve faults in electronic devices, this application provides a method, related apparatus, and system for detecting device faults, as illustrated in the following embodiments. In this method, when an electronic device malfunctions, another electronic device can be used to detect the fault, and the detection results can be displayed on the other electronic device. Subsequently, the original electronic device can resolve the fault based on the detection results.

[0104] This method utilizes one electronic device to detect faults in other electronic devices. It has low requirements for the faulty electronic devices; even if the tested electronic devices have limited operating space, lack self-testing capabilities, are not equipped with input devices, or are large and difficult to move, this detection method can accurately and quickly detect the faults. In other words, the detection method provided in the following embodiments of this application is applicable to any type of electronic device, facilitating fault detection. Ordinary users can independently initiate fault detection, improving operability and convenience, reducing user dependence on after-sales service, and thus enhancing the user experience.

[0105] In this method, the device being tested can be a smartwatch, smart bracelet, Bluetooth headset, or other device with limited memory and operating space and lacking self-testing capabilities. Other devices that can be tested include smart screens, tablets, televisions, routers, personal computers, smart speakers, and in-vehicle infotainment systems. In other words, this method has no requirements regarding the space or self-testing capabilities of the device being tested. Here, devices with limited memory and operating space and lacking self-testing capabilities can be referred to as thin devices, while devices with ample operating space and self-testing capabilities can be referred to as rich devices.

[0106] In this method, the device being tested may or may not have an input device. That is to say, this method does not require the device to have an input device, and it eliminates the need for frequent interaction between the user and the device, thus improving operability and making it more user-friendly.

[0107] In this method, the size or installation method of the device being tested is not limited. In other words, this method eliminates the need for users to transport the device to a service center, making the testing process more convenient.

[0108] The following embodiments of this application also provide another method for detecting device faults. In a scenario where multiple electronic devices work collaboratively, if a fault occurs, one of the multiple electronic devices can obtain the operating data of all devices and initiate a correlation detection to find the fault based on the operating data of all devices. This allows for convenient, quick, and accurate detection of faults in multi-device collaborative scenarios, eliminating the need for individual detection of each device and improving detection efficiency. Multi-device collaborative scenarios may include, for example, screen projection scenarios, projection scenarios, multi-screen collaborative scenarios, etc.

[0109] To more clearly describe the device fault detection method provided in the embodiments of this application, the communication system provided in the embodiments of this application will be introduced first.

[0110] refer to Figure 1 , Figure 1 The structure of the communication system 10 provided in an embodiment of this application is illustrated by way of example.

[0111] like Figure 1 As shown, the communication system 10 may include: electronic device 100, electronic device 200, electronic device 300, electronic device 400, and cloud platform 500. Among them,

[0112] The cloud platform 500 deploys a fault database. This database includes multiple fault trees. A fault tree, also known as an error tree, is a logic tree diagram that primarily uses event symbols, logic gate symbols, and transfer symbols to represent the causes and logical relationships of accidents or malfunctions. A fault tree can encompass faults caused by various factors, including hardware, software, environment, and human error. Fault trees can be used to analyze equipment faults, resolve faults, calculate the probability of fault occurrence, etc., as detailed in the subsequent method embodiments.

[0113] The fault trees in the fault database can be categorized by device type, such as mobile phone fault trees, tablet fault trees, smart bracelet fault trees, smart screen fault trees, in-vehicle fault trees, and so on. Fault trees corresponding to different device types can be used to accurately analyze different types of devices, thereby quickly and precisely identifying faults.

[0114] The fault trees in the fault database can be further categorized based on device type and different test items. For example, for mobile phones, it could include audio fault trees, network fault trees, battery fault trees, and so on. Similarly, for smart screens, it could include audio fault trees, network fault trees, display fault trees, and so on. This allows for further analysis of different test items for each type of device, leading to more precise fault identification.

[0115] In other embodiments, the fault trees in the fault database may not be categorized by device type, but rather by different detection items. This allows for the creation of a unified and universal fault tree for multiple devices, resulting in lower costs.

[0116] The fault database can also include fault trees corresponding to multiple multi-device collaboration scenarios, such as fault trees for screen mirroring scenarios, projection scenarios, and multi-screen collaboration scenarios. Fault trees corresponding to multi-device collaboration scenarios can be used to accurately analyze faults in different multi-device collaboration scenarios, thereby accurately and quickly identifying faults.

[0117] The fault trees in the fault database can be further categorized according to different detection items, based on multi-device collaboration scenarios. For example, for screen mirroring scenarios, it can include connection fault trees, audio fault trees, network fault trees, and so on.

[0118] The cloud platform 500 is also used to receive fault diagnosis data reported by various electronic devices with fault diagnosis capabilities (such as electronic device 100 and electronic device 300), and to update or improve the fault database based on the fault diagnosis data. This fault diagnosis data may include: operating data acquired by electronic device 100 from other electronic devices, such as electronic device 200, and the detection results obtained by electronic device 100 based on the operating data; operating data of electronic device 300, and the detection results obtained by electronic device 300 based on the operating data, etc. Subsequently, the cloud platform 500 can also utilize the fault diagnosis data to continuously optimize the fault database deployed in the cloud platform 500, improving the fault diagnosis capability of the communication system 10, thereby finding faults more accurately and quickly.

[0119] Here, the operational data of a device includes relevant data of the device that is affected by various factors such as hardware, software, environment, and human factors. The operational data of the device may include, for example, log data, system configuration information, hardware data, etc. For details, please refer to the relevant descriptions in the subsequent method embodiments, which will not be elaborated here.

[0120] The cloud platform 500 can store solutions for different types of faults. These solutions can be continuously updated.

[0121] The cloud platform 500 can be implemented as a cloud server or a regular server; there are no restrictions here.

[0122] Electronic device 100 may be a mobile phone, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, as well as cellular phone, personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, in-vehicle device, smart home device, and / or smart city device. This application embodiment does not impose any special limitations on the specific type of electronic device. Exemplary embodiments of electronic device 100 include, but are not limited to, devices equipped with… Portable or non-portable electronic devices running Linux or other operating systems.

[0123] Electronic device 100 can establish a short-range connection with other electronic devices, such as electronic devices 200-400, via Bluetooth (BT), wireless local area networks (WLAN) such as Wireless Fidelity Point-to-Point (Wi-Fi P2P), near field communication (NFC), infrared (IR), etc. In some other embodiments, electronic device 100 and other electronic devices can also establish a remote connection by logging into the same account. For example, electronic device 100 and electronic device 200 can log into the same Huawei account and connect through a Huawei server.

[0124] Understandable Figure 1 The communication system 10 shown is only an example. In a specific implementation, the communication system 10 may include more or fewer devices.

[0125] In some embodiments, the communication system 10 may include only electronic device 100, electronic device 200 and cloud platform 500, with electronic device 100 performing fault detection of electronic device 200 locally.

[0126] Specifically, electronic device 100 can obtain operational data from electronic device 200 through its connection with electronic device 200, and then retrieve a fault tree from cloud platform 500. Afterwards, electronic device 100 can obtain detection results for electronic device 200 based on the fault tree and operational data, including faults in electronic device 200, etc. Furthermore, electronic device 100 can display these detection results on a screen. Electronic device 100 can also obtain solutions corresponding to the detected faults and send these solutions to electronic device 100. These solutions can be obtained from cloud platform 500 or stored within electronic device 100 itself. Electronic device 200 can be either a thin device or a rich device; there are no restrictions on this.

[0127] In some other embodiments, the communication system 10 may consist only of electronic device 100, electronic device 300, and cloud platform 500, with electronic device 100 triggering electronic device 300 to perform fault detection.

[0128] Specifically, electronic device 100 can trigger electronic device 300 to begin fault detection through its connection with electronic device 300. Upon triggering by electronic device 100, electronic device 300 begins fault detection. Electronic device 300 can obtain the corresponding fault tree from cloud platform 500, and then, based on the fault tree and its own operational data, obtain its own detection results, including faults of electronic device 300, etc., and can also send these detection results to electronic device 100. Afterwards, electronic device 300 can obtain the solutions corresponding to the detected faults and repair them according to the solutions. Furthermore, after receiving the detection results from electronic device 300, electronic device 100 can also display the detection results on its display screen. Notably, electronic device 300 can be a rich device.

[0129] In some other embodiments, the communication system 10 may include only electronic device 100, electronic device 400 and cloud platform 500, with electronic device 100 performing joint fault detection of electronic device 100 and electronic device 400 locally.

[0130] Specifically, electronic devices 100 and 400 can work collaboratively, and there can be one or more electronic devices 400. For example, electronic device 100 can be a smartphone, and electronic device 400 can be a smart screen, with both collaboratively projecting the screen. Alternatively, electronic device 100 can be a smartphone, and electronic device 400 can be a projector, with both collaboratively projecting the screen. Electronic device 100 can obtain log data from electronic device 400 through its connection with electronic device 400, and then obtain the corresponding fault tree from the cloud platform 500. Afterwards, electronic device 100 can obtain detection results based on the fault tree, the operating data of electronic device 400, and its own operating data, including faults in the current multi-device collaborative scenario. Furthermore, electronic device 100 can display the detection results on its screen. Electronic device 100 can also obtain solutions corresponding to the detected faults and perform self-repair based on the solutions or send the solutions to electronic device 400. Electronic device 400 can be a thin device or a rich device; there are no restrictions.

[0131] The aforementioned thin devices refer to devices with limited memory and operating space that lack self-testing capabilities. For example, thin devices such as electronic devices 200 can include smartwatches, smart bracelets, Bluetooth headsets, etc.

[0132] The aforementioned "rich devices" refer to devices with ample operating space and self-testing capabilities. Examples of rich devices, such as electronic devices 300, can include smart screens, tablets, televisions, routers, personal computers, smart speakers, and in-vehicle infotainment systems.

[0133] Figure 1 The communication system 10 shown is merely an example and does not constitute a limitation on the communication system provided in the embodiments of this application. In some other embodiments, the communication system 10 may not include the cloud platform 500. In some implementations, electronic devices 100, 300, or 400 may have fault trees pre-configured or pre-downloaded. The types and functions of these fault trees can be found in the relevant description of fault trees in the cloud platform 500 section above. This reduces the interaction between the various electronic devices and the cloud platform in the communication system 10, improving the efficiency of fault detection.

[0134] The following describes the various devices in communication system 10.

[0135] refer to Figure 2A , Figure 2A The hardware structure of electronic device 100 is illustrated by way of example.

[0136] Electronic device 100 may include processor 110, external memory interface 120, internal memory 121, universal serial bus (USB) interface 130, charging management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an accelerometer sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0137] It is understood that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0138] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0139] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0140] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0141] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0142] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0143] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 150 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 150 and at least some modules of the processor 110 may be housed in the same device.

[0144] The modem processor may include a modulator and a demodulator. The modulator modulates the low-frequency baseband signal to be transmitted into a mid-to-high frequency signal. The demodulator demodulates the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After processing by the baseband processor, the low-frequency baseband signal is transmitted to the application processor. The application processor outputs sound signals through an audio device (not limited to speaker 170A, receiver 170B, etc.) or displays images or videos through the display screen 194. In some embodiments, the modem processor may be a separate device. In other embodiments, the modem processor may be independent of the processor 110 and may be housed in the same device as the mobile communication module 150 or other functional modules.

[0145] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including WLAN (such as Wi-Fi), BT, GNSS, frequency modulation (FM), NFC, IR, etc. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, demodulates and filters the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, frequency modulate and amplify them, and then convert them into electromagnetic waves for radiation via antenna 2.

[0146] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, and / or IR technologies, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0147] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. Processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0148] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. The display panel may be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniature LED, a microLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than 1.

[0149] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0150] Internal memory 121 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM).

[0151] Random access memory can include static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), and double data rate synchronous dynamic random access memory (DDR SDRAM, such as fifth-generation DDR SDRAM, which is generally called DDR5 SDRAM). Non-volatile memory can include disk storage devices and flash memory.

[0152] The random access memory can be directly read and written by the processor 110. It can be used to store executable programs (such as machine instructions) of the operating system or other running programs, as well as user and application data.

[0153] Non-volatile memory can also store executable programs and user and application data, and can be pre-loaded into random access memory for direct reading and writing by the processor 110.

[0154] The external memory interface 120 can be used to connect to external non-volatile memory, thereby expanding the storage capacity of the electronic device 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to perform data storage functions. For example, music, video, and other files can be stored in the external non-volatile memory.

[0155] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0156] Touch sensor 180K, also known as a "touch device," can be located on display screen 194. The touch sensor 180K and display screen 194 together form a touchscreen, also known as a "touchscreen." Touch sensor 180K detects touch operations applied to or near it. The touch sensor can transmit the detected touch operation to the application processor to determine the type of touch event. Visual output related to the touch operation can be provided through display screen 194. In other embodiments, touch sensor 180K may also be located on the surface of electronic device 100, in a different position than display screen 194.

[0157] In this embodiment, the wireless communication module 160 or the mobile communication module 150 can be used to discover other electronic devices, such as electronic devices 200-400, and establish communication connections with them. The specific implementation of this communication connection can be found in the relevant descriptions of the communication system 10 and subsequent method embodiments.

[0158] In some embodiments, the wireless communication module 160 or the mobile communication module 150 can acquire the operating data of the electronic device 200 through a connection with the electronic device 200. Then, the wireless communication module 160 or the mobile communication module 150 can obtain the corresponding fault tree from the cloud platform 500. Subsequently, the processor 110 can be used to obtain the detection results of the electronic device 200 based on the fault tree and the operating data of the electronic device 200, including faults in the electronic device 200, etc. Furthermore, the display screen 194 can be used to display the detection results.

[0159] In other embodiments, the wireless communication module 160 or the mobile communication module 150 can trigger the electronic device 300 to begin fault detection via a connection with the electronic device 300. Furthermore, the display screen 194 can be used to display the detection results of the electronic device 300.

[0160] In some embodiments, the wireless communication module 160 or the mobile communication module 150 can obtain the operating data of the electronic device 400 through a connection with the electronic device 400. Then, the wireless communication module 160 or the mobile communication module 150 can obtain the corresponding fault tree from the cloud platform 500. Subsequently, the processor 110 can be used to obtain detection results based on the fault tree, the operating data of the electronic device 400, and the operating data of the electronic device 100 itself, including faults in the current multi-device collaborative scenario, etc. Furthermore, the display screen 194 can be used to display the detection results.

[0161] In some embodiments, the wireless communication module 160 or the mobile communication module 150 may also report its own and other electronic devices (e.g., electronic device 200, electronic device 300) operating data, as well as the detection results obtained from the analysis of the operating data, to the cloud platform 500 for the cloud platform 500 to update or improve the fault database.

[0162] The display screen 194 is used to display the user interface implemented on the electronic device 100 provided in the embodiments of this application, and can be referred to the relevant description in the following embodiments.

[0163] refer to Figure 2B , Figure 2B The hardware structure of the cloud platform 500 provided in the embodiments of this application is illustrated by way of example.

[0164] like Figure 2B As shown, the cloud platform 500 may include: one or more processors 201, memory 202, communication interface 203, transmitter 205, receiver 206, coupler 207, and antenna 208. These components can be connected via bus 204 or other means. Figure 2B Taking a connection via bus 204 as an example. Where:

[0165] Communication interface 203 can be used by the cloud platform 500 to communicate with other communication devices, such as electronic devices 100-1004, for example, to send fault trees to electronic devices 100 and receive fault diagnosis data reported by electronic devices 100. Specifically, communication interface 203 can be a 3G communication interface, a Long Term Evolution (LTE) (4G) communication interface, a 5G communication interface, a WLAN communication interface, a WAN communication interface, etc. Not limited to wireless communication interfaces, the cloud platform 300 can also be configured with a wired communication interface 203 to support wired communication; for example, the backhaul link between the cloud platform 500 and other servers can be a wired communication connection.

[0166] In some embodiments of this application, transmitter 205 and receiver 206 can be considered as a wireless modem. Transmitter 205 can be used to transmit signals output by processor 201. Receiver 206 can be used to receive signals. In cloud platform 500, the number of transmitters 205 and receivers 206 can be one or more. Antenna 208 can be used to convert electromagnetic energy in a transmission line into electromagnetic waves in free space, or to convert electromagnetic waves in free space into electromagnetic energy in a transmission line. Coupler 207 can be used to split mobile communication signals into multiple paths and distribute them to multiple receivers 206. Understandably, the antenna 208 of the network device can be implemented as a massive MIMO (Massively Multi-Size Antenna Array).

[0167] The memory 202 is coupled to the processor 201 and is used to store various software programs and / or multiple sets of instructions. Specifically, the memory 202 may include high-speed random access memory and may also include non-volatile memory, such as one or more disk storage devices, flash memory devices, or other non-volatile solid-state storage devices.

[0168] The memory 202 may store an operating system (hereinafter referred to as the system), such as uCOS, VxWorks, RTLinux, or other embedded operating systems. The memory 202 may also store a network communication program, which can be used to communicate with one or more electronic devices.

[0169] In this embodiment, the memory 202 can store fault trees of multiple different types of devices, and can also store fault trees corresponding to multi-device collaborative scenarios, etc. For details, please refer to the above description.

[0170] In this embodiment, the processor 201 can be used to read and execute computer-readable instructions. Specifically, the processor 201 can be used to call a program stored in the memory 202, such as the implementation program of the device fault detection method provided in one or more embodiments of this application on the cloud platform 500 side, and execute the instructions contained in the program.

[0171] It needs to be explained that, Figure 2BThe cloud platform 500 shown is merely one implementation of the embodiment of this application. In actual applications, the cloud platform 500 may include more or fewer components, which is not limited here.

[0172] refer to Figure 2C , Figure 2C The software structure of the electronic device 100 and cloud platform 500 provided in the embodiments of this application is illustrated by way of example.

[0173] The software system of Cloud Platform 500 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture, etc. For example, the software system of Cloud Platform 500 includes, but is not limited to, […]. Linux or other operating systems. It refers to Huawei's HarmonyOS operating system.

[0174] like Figure 2C As shown, the software system of the cloud platform 500 may include: a data analysis system and a fault database. The data analysis system and the fault database together provide diagnostic services for the communication system 10.

[0175] The fault database includes fault trees for multiple different types of devices, and may also include fault trees for multi-device collaborative scenarios. For details, please refer to [link / reference needed]. Figure 1 The relevant description is provided in the communication system 10 shown. The fault tree in the fault database can be updated as needed or periodically for other electronic devices, such as electronic device 100, electronic device 300, etc.

[0176] The data analysis system is used to update or improve the fault database based on fault diagnosis data from various electronic devices (e.g., electronic device 100, electronic device 200, electronic device 300).

[0177] It needs to be emphasized that, Figure 2C This is merely an illustrative example; the software architecture of the cloud platform 500 provided in this application embodiment can also adopt other software architectures, which are not limited here.

[0178] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture, etc. For example, the software system of electronic device 100 includes, but is not limited to, […]. Linux or other operating systems. This application embodiment uses the layered architecture of the Android system as an example to illustrate the software structure of the mobile device 100.

[0179] like Figure 2CAs shown in the illustration, this application provides a schematic block diagram of a software architecture for an electronic device 100. The layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, the Android system may include, from top to bottom, an application layer and a system service layer. However, this is not the only possibility; in other embodiments, the Android system may also include an application framework layer, a kernel layer, and so on.

[0180] The application layer can include a series of application packages.

[0181] like Figure 2C As shown, the application package may include fault detection and repair applications, as well as applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, and SMS.

[0182] The fault detection and repair application provides fault detection and repair functions for electronic device 100.

[0183] The fault detection and repair application supports electronic device 100 in discovering other electronic devices and binding electronic device 100 to the discovered other electronic devices. Binding refers to electronic device 100 storing some information about the other electronic devices (such as device model, device software system version, etc.). This process will be described in detail in subsequent embodiments and will not be repeated here. For example, as... Figure 2C As shown, fault detection and repair applications may include HiCare APP, which can support electronic device 100 in discovering and binding other electronic devices, such as electronic device 200, electronic device 300, or electronic device 400.

[0184] The fault detection and repair application also supports establishing connections between electronic device 100 and bound electronic devices, and using these connections to communicate with other electronic devices, such as obtaining operational data from other electronic devices, sending fault solutions to other electronic devices, etc. The connection between electronic device 100 and other electronic devices can be a short-range connection or a long-range connection, as detailed in the preceding descriptions.

[0185] For example, such as Figure 2C As shown, the fault detection and repair application may include a thin device agent APP, which can be used by electronic device 100 to communicate with connected thin devices such as electronic device 200, for example, to request the operation data of electronic device 100.

[0186] In some embodiments, the fault detection and repair application enables electronic device 100 to obtain the operating data of electronic device 200, obtain the corresponding fault tree from cloud platform 500, obtain the detection results of electronic device 200 based on the fault tree and operating data, obtain the solution corresponding to the detected fault, and send the solution to electronic device 100.

[0187] In other embodiments, the fault detection and repair application supports electronic device 100 in triggering electronic device 300 to begin fault detection.

[0188] In some other embodiments, the fault detection and repair application supports electronic device 100 to obtain the operating data of electronic device 400 from electronic device 400, obtain the corresponding fault tree from cloud platform 500, and obtain the detection results based on the fault tree, the operating data of electronic device 400 and the operating data of electronic device 100 itself, as well as obtain the solution corresponding to the detected fault, and perform self-repair based on the solution or send the solution to electronic device 400.

[0189] For example, such as Figure 2C As shown, the fault detection and repair application may include a DetectRepair APP, which is used to obtain detection results and fault solutions based on relevant information, and can also be used for self-repair based on the fault solutions. This relevant information can be found in the preceding descriptions. The DetectRepair APP can interact with a thin device agent APP to obtain operational data from the thin device (e.g., electronic device 200). The DetectRepair APP and the thin device agent APP can communicate via the CoDiagnosisInterface. The DetectRepair APP can also interact with DetectRepair APPs in other rich devices to obtain operational data from those rich devices (e.g., electronic device 300).

[0190] In practice, the fault detection and repair application can call the wireless communication module 160, mobile communication module 150, etc. of the electronic device to communicate with the cloud platform 500 and other electronic devices. It can also call the processor 110 to perform fault analysis and obtain detection results. In addition, it can call the display screen 194 to display the final detection results.

[0191] The system service layer may include various services, such as system services, HiView services, and the Hardware Abstraction Layer (HAL). It is not limited to these; the system service layer may also include modules such as system settings. The system service is used to manage the following information of the electronic device 100: device information and system configuration information.

[0192] The device information refers to the hardware and software specifications of the electronic device 100, which may include, for example, device type, device model, software system type, and software system version number. The device type and model number typically remain unchanged, while the software system type and version number may change with updates to the electronic device 100.

[0193] System configuration information, also known as system status, may include, for example, the type of installed software system, software system version number, memory size, ROM space size, and other configuration items. System configuration information can be changed or updated as the electronic device 100 operates.

[0194] In addition, the system service can also be used to manage the region where the electronic device 100 is located, such as the country or region.

[0195] The HiView service manages the log database (Log DB) of the electronic device 100. The Log DB is used to collect, store, and query log data. Log data records events generated by the electronic device 100 during operation, including descriptions of the date, time, user, and actions.

[0196] The HAL layer can be used to interact with the hardware of electronic device 100 and obtain relevant hardware operation data. This hardware operation data includes the operating status of various hardware components of electronic device 100, such as the sound transmission and reception status of audio devices, the signal transmission and reception status of communication modules, the display status of the screen, and the image acquisition status of cameras. The hardware operation data changes continuously according to the actual situation of electronic device 100.

[0197] Understandably, the above Figure 2CThe terms "fault detection and repair application," "HiCare APP," "DetectRepair APP," "thin device proxy APP," and "rich device proxy APP" shown are merely terms used in the embodiments of this application. Their meanings have been described in this embodiment, and their names do not constitute any limitation on this embodiment. These names can also be referred to as other terms. In some embodiments, HiCare APP, DetectRepair APP, thin device proxy APP, and rich device proxy APP can be integrated into a single application, which is not limited here.

[0198] It needs to be emphasized that, Figure 2C This is merely an illustrative example; the software architecture of the electronic device 100 provided in this application embodiment may also adopt other software architectures, which are not limited here.

[0199] The software systems in electronic devices 200, 300, and 400 can all adopt layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture, etc. Examples include, but are not limited to, those mentioned above. Linux or other operating systems.

[0200] Among them, the software structure of rich devices such as electronic devices 300 and 400 is similar to that of electronic device 100, and both are equipped with fault detection and repair applications. For details, please refer to [reference needed]. Figure 2C The relevant description is as follows. The difference between thin devices, such as electronic device 200 and electronic device 100, is that thin devices do not include fault detection and repair applications.

[0201] The following describes a series of user interfaces provided in the embodiments of this application. .

[0202] Figure 3A An exemplary user interface 31 for displaying installed applications is shown on an electronic device 100.

[0203] The user interface 31 displays: a status bar, a calendar indicator, a weather indicator, a tray with icons for commonly used applications, and other application icons such as an icon for a troubleshooting and repair application 301, a gallery icon, a file browser icon, etc. The status bar may include: one or more signal strength indicators for mobile communication signals (also known as cellular signals), a Bluetooth indicator, one or more signal strength indicators for Wi-Fi signals, a battery status indicator, a time indicator, etc. The calendar indicator and weather indicator are used to indicate the calendar and weather, respectively. However, this is not the only aspect. Figure 3A The user interface 31 shown may also include a navigation bar, a sidebar, etc. In some embodiments, Figure 3AThe user interface 31 shown in the example can be the home screen.

[0204] The fault detection and repair application is an application installed on electronic device 100. Its function and specific implementation can be found in the previous description, and will not be repeated here.

[0205] like Figure 3A As shown, the electronic device 100 can detect user operations (such as click operations, touch operations, etc.) on the icon 301 of the fault detection and repair application, and in response to the user operation, launch the fault detection and repair application and display the user interface 32 provided by the fault detection and repair application.

[0206] like Figure 3B As shown, user interface 32 serves as the main page for the fault detection and repair application, showcasing its various functions. User interface 32 displays: a status bar, a page indicator, a user indicator, and one or more function options. The status bar can be referenced... Figure 3A The relevant descriptions are as follows: Page indicators are used to indicate that this user interface 32 is provided by the fault detection and repair application. User indicators are used to indicate the user currently logged into the fault detection and repair application. Both page indicators and user indicators can be implemented as text, icons, or a combination of both. Function options can be used to provide various functions, such as service center options, warranty policy options, user manual options, My Device options 302, etc.

[0207] like Figure 3B As shown, the electronic device 100 can detect user actions (such as clicks, touches, etc.) applied to the My Device option 302 and, in response to the user action, display... Figure 3C The user interface shown is 33.

[0208] User interface 33 is used to display information about the bound device. Here, the bound device can refer to other electronic devices bound to electronic device 100, or it can refer to other electronic devices bound to the user currently logged into the fault detection and repair application.

[0209] like Figure 3C As shown, the user interface 33 displays: a status bar, a back button, a page indicator, and information bars for one or more bound devices. The status bar can be found in [reference needed]. Figure 3A The relevant description is provided in the documentation. The back button can be used to return to the previous page in the fault detection and repair application, for example... Figure 3BThe user interface 32. A page indicator is used to indicate the current user interface 33, which displays information about the bound device; for example, it could be the text "My Device". Information bars for the bound device may include, for example, an information bar 303 for a smartwatch, an information bar 304 for a tablet, and an information bar 305 for a smart screen. Any information bar can include relevant information about the corresponding device, such as a picture of the device, its type, and its connection to the electronic device 100.

[0210] The user interface 33 may also display a control 306 for binding more devices. Control 306 can be used to listen for user actions (such as clicks, touches, etc.), and the electronic device 100 can respond to these user actions by searching for other electronic devices and adding or binding the user-selected device. Here, the electronic device 100 can use Bluetooth, NFC, ZigBee, WLAN, or other technologies to search for and bind other devices. Not limited to control 306, the electronic device 100 can also use other methods to bind devices, such as NFC tap-to-bind or QR code scanning, etc., and this embodiment does not impose limitations.

[0211] Each information bar can be used to receive user actions and display detailed information about the corresponding device in response to those actions.

[0212] Figure 3D-Figure 3H This illustrates a series of user interfaces involved when electronic device 100 performs fault detection on a smartwatch. noodle .

[0213] Figure 3D A user interface 34 on the electronic device 100 is shown, displaying detailed information about a smartwatch. This user interface 34 may be displayed by the electronic device 100 in response to a user action detected on the information bar 303 of the smartwatch.

[0214] The user interface 34 displays: a status bar, a back button, a page indicator, an information bar for the smartwatch, and a function area 307 for controlling the smartwatch. (See the status bar for reference.) Figure 3A The relevant description is provided in the documentation. The back button can be used to return to the previous page in the fault detection and repair application, for example... Figure 3C The user interface 33. A page indicator is used to indicate the current user interface 34, which displays detailed information about the smartwatch, such as the text "Smartwatch". The smartwatch's information bar can display an image of the smartwatch, its model, connection status, battery level, etc. Figure 3D The smartwatch and electronic device 100 are connected via Bluetooth.

[0215] Function area 307 may include multiple controls for controlling the smartwatch, such as controls to turn the smartwatch's sports mode on / off, controls to open the smartwatch's user guide, and controls 307c for performing fault detection on the smartwatch, etc. Function area 307 may also include prompt information 307b to inform the user of the function of control 307c, such as the text "Click this control to complete fault detection of this device on this device!". Because the smartwatch is a thin device, the electronic device 100 can directly perform fault detection on the smartwatch on its own, without requiring the smartwatch to perform fault detection itself.

[0216] like Figure 3D As shown, the electronic device 100 can detect user operations applied to the control 307a and display a response to the user operation. Figure 3E The user interface shown is 35.

[0217] User interface 35 is used to display the detectable items corresponding to the smartwatch. For example, the detectable items of the smartwatch may include: image and display option 308a, audio option 308b, camera option 308c, battery option 308d, sensor option 308e, network option 308f, all options 308g, etc. It is understood that the detectable items may differ between different devices, and specific details can be found in the relevant descriptions of the subsequent method embodiments. The method by which the electronic device 100 acquires these detectable items can also be found in the relevant descriptions of the subsequent method embodiments.

[0218] Referring to 3E, after detecting a user operation on audio option 308b, electronic device 100 can respond to the user operation by initiating fault detection for the audio item of the smartwatch.

[0219] In some embodiments, after detecting a user operation on audio option 308b, electronic device 100 can send a fault detection request to smartwatch. Upon receiving the fault request, smartwatch can display... Figure 3F The user interface 36 is shown. User interface 36 may display a prompt message 309a, a control 309b, and a control 309c. Prompt message 309a can be used to inform the user that the smartwatch has received a fault detection request from electronic device 100. Control 309b can listen for user actions; the smartwatch can respond to the action by agreeing to the fault detection request and performing subsequent operations. Control 309c can listen for user actions; the smartwatch can respond to the action by rejecting the fault detection request.

[0220] After the smartwatch agrees to the fault detection request initiated by the electronic device 100, the electronic device 100 performs fault detection on the smartwatch. Specifically, the electronic device 100 can obtain the smartwatch's operating data and, in conjunction with the corresponding fault tree, find the smartwatch's fault and obtain the corresponding solution.

[0221] Figure 3G The user interface 37 displayed by the electronic device 100 during the fault detection process of the smartwatch is shown. The user interface 37 can display the detection progress in real time.

[0222] refer to Figure 3H After the electronic device 100 completes the fault detection of the smartwatch, if a fault is detected, the following can be displayed in the user interface 37: a fault prompt icon 309, text indicating the fault 310, and text indicating the solution 311 (i.e., repair suggestions in the figure). Figure 3H As shown, the user interface 37 can also display some functional controls, such as control 312 for triggering the smartwatch to perform repairs, control 313 for triggering a re-detection of the smartwatch for faults, control 314 for obtaining more repair solutions, and so on.

[0223] Figures 4A-4F This illustrates a series of user actions involved when electronic device 100 triggers a tablet computer for fault detection. interface .

[0224] Figure 4A A user interface 41 on the electronic device 100 is shown, displaying detailed information about a tablet computer. This user interface 41 may be displayed by the electronic device 100 in response to a user action detected on the information bar 304 of the tablet computer.

[0225] User interface 41 and Figure 3D The user interface 34 shown is similar; please refer to the relevant description. Figure 4A The tablet computer and electronic device 100 are connected via Wi-Fi P2P.

[0226] The functional area in the user interface 41 may include a control 401a for triggering fault detection on the tablet computer and a prompt message 401b. The prompt message 401b is used to inform the user of the function of the control 401a, for example, it may be the text "Click this control to complete the fault detection of this device!". Since the tablet computer is a rich device, the electronic device 100 can trigger the tablet computer to complete the fault detection itself, or the electronic device 100 can directly perform fault detection on the tablet computer.

[0227] like Figure 3A As shown, the electronic device 100 can detect user operations applied to the control 401a and display a response to the user operation. Figure 4BThe user interface shown is 42.

[0228] User interface 42 is used to display the detectable items corresponding to the tablet computer. The method by which the electronic device 100 acquires these detectable items can also be found in the relevant description of the subsequent method embodiments.

[0229] In some embodiments, the electronic device 100 detects Figure 4B After a user action is performed on the battery options, a response can be displayed in response to that user action. Figure 4C The window shown contains: prompt message 402a, control 402b, and control 402c. Prompt message 402a prompts the user to choose whether electronic device 100 or tablet computer performs a fault detection on the tablet computer. Control 401b listens for user input, and electronic device 100 responds to this input by performing a fault detection on the tablet computer's battery. Control 401c listens for user input, and electronic device 100 responds to this input by triggering the tablet computer to perform a battery fault detection itself.

[0230] In some other embodiments, the electronic device 100 does not need to display. Figure 4C The window in the middle can directly respond to user actions received on the battery options, triggering the tablet itself to perform battery fault detection.

[0231] In some embodiments, after detecting a user operation on control 401a or control 402b, electronic device 100 may send a fault detection request to tablet computer. Upon receiving the fault request, tablet computer may display... Figure 4D User interface 43 is shown. User interface 43 and Figure 3F The user interface 36 shown is similar; please refer to the relevant description.

[0232] After the tablet computer agrees to the fault detection request initiated by the electronic device 100, the tablet computer will perform a fault detection on the battery. Specifically, the tablet computer can obtain its own operating data and combine it with the corresponding fault tree to find the fault, and can also obtain the corresponding solution for the fault.

[0233] Figure 4E The user interface 44 displayed by the electronic device 100 during fault detection on the tablet computer is shown. This user interface 44 can display the detection progress in real time.

[0234] refer to Figure 4F After the tablet computer completes the battery fault detection, if a fault is detected, the electronic device 100 can display... Figure 4F The user interface 44 shown. This user interface 44 and... Figure 3H The user interface 37 shown is similar; please refer to the relevant description.

[0235] Figures 5A-5E This demonstrates how electronic device 100 performs joint fault detection on devices involved in a screen projection scenario. A series of user interfaces involved .

[0236] Figure 5A A user interface 51 on the electronic device 100 is shown, displaying detailed information about the smart screen. This user interface 51 may be displayed by the electronic device 100 in response to a user action detected on the information bar 305 of the smart screen.

[0237] User interface 51 and Figure 3D The user interface 34 shown is similar; please refer to the relevant description. Figure 5A The smart screen and electronic device 100 are connected, and electronic device 100 and smart screen are working together to project the screen.

[0238] The functional area in the user interface 51 may include a control 501a for triggering the electronic device 100 to perform joint fault detection and a prompt message 501b. The prompt message 501b is used to inform the user of the function of the control 501a, for example, it may be the text "Click this control to perform joint fault detection on associated devices!". Since the smart screen and the electronic device 100 are collaboratively projecting their screens, the electronic device 100 performs joint fault detection on itself and the smart screen.

[0239] like Figure 5A As shown, the electronic device 100 can detect user operations applied to the control 501a and display a response to the user operation. Figure 5B The user interface shown is 52.

[0240] User interface 52 is used to display detectable items. The method by which electronic device 100 acquires these detectable items can also be found in the relevant description of subsequent method embodiments.

[0241] In some embodiments, the electronic device 100 detects Figure 5B After a user interacts with the screen mirroring option, a fault detection request can be sent to the smart screen. Upon receiving the fault request, the smart screen can display... Figure 5C User interface 53 is shown. User interface 53 and Figure 3F The user interface 36 shown is similar; please refer to the relevant description.

[0242] After the smart screen agrees to the fault detection request initiated by the electronic device 100, the electronic device 100 will conduct joint fault detection on the screen projection scenario between the smart screen and the electronic device 100. Specifically, the electronic device 100 can obtain its own and the smart screen's operating data, and combine it with the corresponding fault tree to find the fault, and can also obtain the corresponding solution for the fault.

[0243] Figure 5DThe user interface 54 displayed by the electronic device 100 during joint fault detection is shown. This user interface 54 can display the detection progress in real time.

[0244] refer to Figure 5E After the electronic device 100 completes the joint fault detection of the projection scenario, if a fault is detected, it can display... Figure 5E The user interface 54 shown. This user interface 54 and... Figure 3H The user interface 37 shown is similar; please refer to the relevant description.

[0245] Understandably, the above Figures 3A-3H , Figures 4A-4F , Figures 5A-5D This is merely an example and does not constitute a limitation on the embodiments of this application. In the embodiments of this application, various devices may also display other user interfaces, which are not limited here.

[0246] Based on the above description of the communication system and various devices provided in the embodiments of this application, and in conjunction with the above exemplary user interface, the specific implementation of the device fault detection method will be described in detail below.

[0247] The following three examples will illustrate the method for detecting equipment malfunctions.

[0248] (I) Example 1

[0249] In Embodiment 1, the electronic device 100 can perform fault detection on the electronic device 200 locally.

[0250] Electronic device 100 is a rich device, while electronic device 200 can be either a thin device or a rich device. The following explanation uses electronic device 200 as an example of a thin device. For instance, electronic device 100 could be a mobile phone, and electronic device 200 could be a smartwatch.

[0251] Figure 6A This diagram illustrates the communication interfaces between electronic devices 100 and 200, and the cloud platform 500, as provided in Embodiment 1. The device fault detection method provided in Embodiment 1 will be described below in conjunction with each communication interface. The communication interface can be an application programming interface (API) provided by an application program, including some predefined functions for accessing data and calling functions.

[0252] Figure 6B This is a flowchart illustrating the equipment fault detection method provided in Example 1. Figure 6B As shown, the method for detecting equipment malfunctions may include the following steps:

[0253] S101, electronic device 100 and electronic device 200 establish a communication connection.

[0254] In some embodiments, electronic device 100 and electronic device 200 can establish a short-range connection via BT, WLAN (such as Wi-Fi P2P), NFC, ZigBee, etc. In other embodiments, electronic device 100 and other electronic devices can also establish a remote connection by logging into the same account. For example, electronic device 100 and electronic device 200 can log into the same Huawei account and connect through a Huawei server.

[0255] In some embodiments, when a user binds electronic device 200 to the fault detection and repair application of electronic device 100, a communication connection is established between electronic device 100 and electronic device 200. The method by which a user binds other electronic devices to the fault detection and repair application can be found in the preceding descriptions, for example, through... Figure 3C The control 306 in the software can be used to bind other electronic devices. Other electronic devices can also be bound via NFC tap, QR code scanning, etc. There are no restrictions here.

[0256] In some embodiments, electronic device 100 may establish a communication connection with electronic device 200 in response to a received user operation. For example, see reference... Figure 3C The user interface shown allows the electronic device 100 to establish a communication connection with the smartwatch after the smartwatch is bound to it, when the electronic device 100 receives a user operation on the information bar 303 of the smartwatch.

[0257] In some other embodiments, when electronic devices 100 and 200 meet the conditions for establishing a communication connection, electronic device 100 can automatically establish a connection with electronic device 200 without user intervention. For example, after electronic device 200 is bound, if the distance between electronic devices 100 and 200 is within the signal range of BT, electronic device 100 can automatically establish a connection with electronic device 200 without user operation.

[0258] Not limited to the above examples, in the embodiments of this application, electronic device 100 and electronic device 200 can also establish a communication connection in other situations, such as establishing an NFC connection through a tap operation, establishing a WLAN connection through scanning a code, etc., without limitation.

[0259] refer to Figure 6A In specific implementation, the Hicare APP for fault detection and repair in electronic device 100 is used to bind electronic device 200.

[0260] S102, the electronic device 100 displays a first user interface provided by a fault detection and repair application, the first user interface displaying one or more device options, the one or more device options including the options of the electronic device 200.

[0261] For a detailed introduction to fault detection and repair applications, please refer to the relevant descriptions above.

[0262] The one or more device options displayed in the first user interface may include: options for other electronic devices bound to electronic device 100, or options for other electronic devices bound to the user currently logged into the fault detection and repair application on electronic device 100. For specific instructions on binding other electronic devices, please refer to the relevant descriptions above.

[0263] An example of the first user interface can be found here. Figure 3C The user interface 33 shown is provided. This user interface 33 allows the user to click first. Figure 3A In the user interface 31, click icon 301, then click... Figure 3B The interface displayed by the electronic device 100 after selecting option 302 in the user interface 32.

[0264] Examples of one or more device options in the first user interface may include: Figure 3C The user interface 33 shown includes the information bar 303 of the smartwatch, the information bar 304 of the tablet computer, and the information bar 305 of the smart screen.

[0265] The options for electronic device 200 can be, for example, Figure 3C The information bar 303 of the smartwatch.

[0266] S103, electronic device 100 receives a first operation of the option applied to electronic device 200.

[0267] The first operation is used to trigger electronic device 100 to perform fault detection on electronic device 200. That is, the first operation is used to trigger subsequent steps S104-S110.

[0268] In some embodiments, reference Figure 3C and Figure 3D Electronic device 100 receives an action on Figure 3C After the first operation of the information bar 303 of the smartwatch in the user interface 33 shown, it can display... Figure 3D The user interface 34 is shown. Afterwards, the electronic device 100 can detect the user operation applied to the control 307a and, in response to the user operation, begin performing fault detection on the electronic device 200. In this case, the electronic device 100 can perform a comprehensive fault detection on the electronic device 200.

[0269] In other embodiments, reference is made to Figures 3D-3E Electronic device 100 receives an action on Figure 3C After the first operation of the information bar 303 of the smartwatch in the user interface 33 shown, it can display... Figure 3D The user interface 34 is shown. Afterwards, the electronic device 100 can detect the user operation applied to control 307a and display... Figure 3E The user interface 35 shown is shown. Figure 3E The user interface 35 shown displays the detection items corresponding to the electronic device 200. Then, the electronic device 100 can detect the user operation applied to the first detection item and begin fault detection of the electronic device 200 for that first detection item. In this situation, the electronic device 100 can perform fault detection for the first detection item of the electronic device 200, enabling targeted detection and quickly and accurately identifying the faults existing in the electronic device 200.

[0270] In the above embodiments, reference is made to Figure 3E The detection items corresponding to electronic device 200 may include detectable items of smartwatches, such as image and display option 308a, audio option 308b, camera option 308c, battery option 308d, sensor option 308e, network option 308f, and all options 308g. Among them, all options 308g includes all detectable items of electronic device 200.

[0271] An example of the first detection item can be... Figure 3E Audio option 308b.

[0272] In the specific implementation, refer to Figure 6A The thin agent app is used to acquire and manage the detection items of electronic device 200. The detection items of electronic device 200 can be combined into a profile file. The DetectRepair app of electronic device 100 can retrieve the detection items of electronic device 200 from the thin agent app through the GetDiagnosisCapability method in the CoDiagnosisInterface interface and display them. Figure 3E The user interface 35 shown.

[0273] The detectable items of a device refer to the aspects of the device that may malfunction, and are usually related to the device's capabilities. For example, a mobile phone has a camera, audio device, battery, and network communication functions, so the detectable items of a mobile phone include the items listed above. As another example, the software system installed on a mobile phone supports functions such as call recording and live wallpapers, so the detectable items of a mobile phone also include the corresponding call recording and live wallpaper items, and so on.

[0274] Because different devices possess different hardware and software capabilities, the items they can detect also differ. For example, compared to a PC, a mobile phone adds mobile communication capabilities, therefore a mobile phone can be tested. Similarly, compared to a smart bracelet, a smart screen adds a camera, therefore a camera is included as a detection item for a smart screen.

[0275] This application does not limit the way the detectable items of the device are divided. For example, it may include audio detection items for all audio devices, or microphone detection items for microphones, speaker detection items for speakers, and so on.

[0276] In this embodiment of the application, the electronic device 100 (thin agent APP) may acquire the detection items of the electronic device 200 in the following ways:

[0277] 1. After electronic device 100 and electronic device 200 are bound or a communication connection is established, electronic device 100 can directly obtain the detectable items of electronic device 200. The obtained detectable items of electronic device 200 can be stored in the thin agent APP.

[0278] 2. After electronic device 100 and electronic device 200 are bound or a communication connection is established, electronic device 100 can obtain its device information and / or location from electronic device 200, and then send its device information and / or location to cloud platform 500 to obtain the latest version of detectable items of electronic device 200.

[0279] The device information of electronic device 200 reflects its hardware and software capabilities, and may include, for example, device type, device model, software system type, software system version number, etc. Since some areas may restrict device functionality, the region where the device is located will affect its functionality and the detectable items of the device.

[0280] In practice, the thin agent APP can obtain device information, location, etc. of electronic device 200 from the system service of electronic device 200 through the GetDeviceInfo interface.

[0281] In some embodiments, the thin agent app of electronic device 100 can upload device information and / or its location of electronic device 200, as well as the current version number of the profile file containing detectable items of electronic device 200, to cloud platform 500 via the UpdateDiagnosisProfile interface. The cloud platform can verify whether the detectable items of electronic device 200 have been updated. If updated, it will return the latest version of the profile file containing the detectable items of electronic device 200 to the thin agent app of electronic device 100.

[0282] 3. After electronic device 100 and electronic device 200 are bound or a communication connection is established, electronic device 100 can obtain its device information and / or location from electronic device 200. Then, in the latest version of the profile file containing various detection items issued by cloud platform 500, electronic device 100 matches the detectable items of electronic device 200 according to the device information and / or location.

[0283] In some embodiments, the thin agent application of electronic device 100 can obtain the latest version of the profile file containing various detection items from cloud platform 500 through the UpdateDiagnosisProfile interface. This profile file containing various detection items can be a large set of detection items applicable to different devices. Electronic device 100 can find the detection items that match the device information and / or location of electronic device 200 in this set of detection items, i.e., the detection items of electronic device 200.

[0284] In addition to the three methods mentioned above for obtaining the detection items of electronic device 200, electronic device 100 can also obtain the detection items of electronic device 200 through other means, such as electronic device 100 can preset the detection items of electronic device 200, etc. There are no restrictions here.

[0285] S104, Electronic device 100 obtains the first fault tree from cloud platform 500.

[0286] The cloud platform 500 stores a fault database containing multiple fault trees. A fault tree is a tree diagram that represents the logical relationship between faults and their causes. A fault tree can encompass faults caused by various factors such as hardware, software, environment, and human error.

[0287] In some embodiments, the fault tree in the cloud platform 500 can be classified according to device type, such as mobile phone fault tree, tablet computer fault tree, smart bracelet fault tree, smart screen fault tree, vehicle system fault tree, etc.

[0288] In some embodiments, the fault tree in the cloud platform 500 can be further categorized according to different detection items based on the device type. For example, for a mobile phone, it can include an audio fault tree, a network fault tree, a battery fault tree, etc. Similarly, for a smart screen, it can include an audio fault tree, a network fault tree, a display fault tree, etc.

[0289] In some embodiments, the fault tree in the cloud platform 500 may not be categorized by device type, but rather by different detection items. This approach reduces the cost of establishing a unified and universal fault tree for multiple devices.

[0290] In some embodiments, the fault tree in the cloud platform 500 can also be categorized according to the version of the software system.

[0291] Not limited to the above classification examples, the fault tree in the cloud platform 500 can also be classified in other ways, and this application embodiment does not limit this.

[0292] The first fault tree is a fault tree that matches one or more of the following for electronic device 200: device type, device model, software system type, software system version, and first detection item.

[0293] In S104, if the first operation in S103 triggers electronic device 100 to perform overall fault detection on electronic device 200, for example, electronic device 100 detects a user operation on control 307a, or electronic device 100 detects an operation on... Figure 3E When all options in option 308g are selected, the first fault tree is the device type fault tree corresponding to the electronic device 200. For example, the first fault tree could be a smartwatch fault tree. Alternatively, the first fault tree could include fault trees corresponding to all detection items of the electronic device 200, such as an audio fault tree, a network fault tree, a battery fault tree, etc.

[0294] In S104, if the first operation in S103 triggers electronic device 100 to perform a fault detection of the first detection item on electronic device 200, for example, electronic device 100 detects an action acting on... Figure 3E When the user operates the audio option 308b, the first fault tree is the fault tree corresponding to the first detection item (i.e., the audio fault tree). The fault tree corresponding to the first detection item can be a fault tree corresponding to the first detection item after being classified according to the device type of the electronic device 200, or it can be a unified and universal fault tree corresponding to the first detection item.

[0295] In a specific implementation, the DetectRepair APP in the electronic device 100 can obtain the first fault tree from the cloud platform 500 through the GetFaultTree interface.

[0296] In some other embodiments, after receiving the first operation in S103, the electronic device 100 can directly obtain the fault trees corresponding to each detection item of the electronic device 200 from the cloud platform 500, and find the first fault tree among multiple fault trees. In other embodiments, the electronic device 100 can also directly obtain the fault trees corresponding to each detection item of the electronic device 200 from the cloud platform 500 after establishing a communication connection with the electronic device 200, and find the first fault tree among multiple fault trees. This allows the fault trees to be downloaded in advance, improving the efficiency of fault detection.

[0297] S105, electronic device 100 obtains the operating data of electronic device 200 from electronic device 200. The operating data includes one or more of the following: log data, hardware data, or system configuration information.

[0298] In this embodiment, the operating data of the electronic device 200 includes relevant data of the device affected by various factors such as hardware, software, environment, and human factors. For example, the operating data of the electronic device 200 includes one or more of the following: log data, hardware data, or system configuration information of the electronic device 200.

[0299] Log data is a record of events generated by the electronic device 100 during operation, containing descriptions of related operations such as date, time, user, and actions. Different detection items can correspond to different log data; for example, the audio detection item corresponds to the log data generated by the audio device during operation, and the battery detection item corresponds to the log data generated by the battery during operation.

[0300] If the first operation in S103 triggers electronic device 100 to perform overall fault detection on electronic device 200, then the log data in S105 may include log data corresponding to all detection items of electronic device 200. If the first operation in S103 triggers electronic device 100 to perform fault detection on a first detection item on electronic device 200, then the log data in S105 may include log data of electronic device 200 for that first detection item.

[0301] Hardware data refers to the hardware operating status of electronic device 200 during fault detection. For example, when detecting a fault in an audio device, the hardware data may include the microphone output when electronic device 200 plays a preset voice message. Similarly, when detecting a fault in a camera, the hardware data may include the image acquisition status when electronic device 200 activates the camera. In other words, after triggering the fault detection in Embodiment 1, electronic device 200 can perform corresponding operations, such as playing a preset voice message or activating the camera, to provide the relevant hardware data.

[0302] System configuration information, also known as system status, may include, for example, the type of installed software system, software system version number, memory size, ROM space size, and other configuration items.

[0303] In specific implementation, the DetectRepair APP of electronic device 100 can obtain log data from the HiView service of electronic device 200 through the GetDiagnosisLog interface, obtain hardware operation data from the HAL layer of electronic device 200 through the GetDeviceInfo interface, and obtain system configuration information from the system service of electronic device 200 through the GetSystemInfo interface.

[0304] In some embodiments, when electronic device 100 requests information, electronic device 200 may directly send one or more of the aforementioned information to electronic device 100. In other embodiments, electronic device 200 may, upon receiving information requested by electronic device 100, send such information directly to electronic device 100. Figure 3F After a user operation is performed on control 309b, one or more of the above information will be sent to electronic device 200.

[0305] S106, electronic device 100 determines the first fault based on the first fault tree and the operating data of electronic device 200.

[0306] The operational data of electronic device 200 includes relevant data on the device affected by various factors such as hardware, software, environment, and human error. If electronic device 200 malfunctions, this operational data can reflect the malfunction to a certain extent. Since a fault tree is a tree diagram representing the logical relationship between faults and their causes, and encompasses faults caused by various factors such as hardware, software, environment, and human error, the fault existing in electronic device 200, i.e., the first fault, can be analyzed based on the operational data of electronic device 200 in the first fault tree.

[0307] For example, if the operating data of electronic device 100 indicates that the microphone driver failed to start normally during the use of the audio device, it can be determined that the current microphone driver is abnormal.

[0308] In some embodiments, during fault detection of electronic device 200, electronic device 100 may display the detection progress on a screen, for example... Figure 3G The user interface 37 is shown. That is to say, during S103-S106, the electronic device 100 can display the detection progress on the screen in real time for the user's convenience.

[0309] S107, Electronic device 100 obtains the solution corresponding to the first fault.

[0310] In some embodiments, the electronic device 100 can directly find the solution corresponding to the first fault on its own machine. For example, the electronic device 100 can store some simple solutions corresponding to the first fault, such as abnormal battery consumption caused by prolonged high brightness mode of the display screen, which can be resolved by turning off the high brightness mode of the display screen, etc.

[0311] In other embodiments, electronic device 100 can report the identity (ID) of the first fault to cloud platform 500, which then distributes a solution to resolve the first fault to electronic device 200. Understandably, solutions for various first faults can be pre-stored in cloud platform 500 and can be updated as needed. Specifically, the DetectRepair APP in electronic device 100 reports the first fault to cloud platform 500 via the GetFaultSolution interface and obtains a solution from cloud platform 500.

[0312] The number of solutions corresponding to the first fault obtained by electronic device 100 can be one or more, and there is no limit here.

[0313] S108, Electronic device 100 displays indication information and solutions for the first fault.

[0314] The indication information for the first fault may include, but is not limited to: the ID of the first fault, text, or a chart, etc.

[0315] For an example of the indication information and solution for the first fault displayed by the electronic device 100, please refer to... Figure 3H The user interface 37 shown contains text 310 indicating the first fault and text 311 indicating the solution.

[0316] In addition to displaying information directly on the screen, the electronic device 100 can also output indication information and solutions for the first fault through voice broadcast, vibration, and other means.

[0317] S109, Electronic device 100 sends the solution to electronic device 200.

[0318] In some embodiments, after obtaining a solution, electronic device 100 may directly send the solution to electronic device 200 so that electronic device 200 can repair the first fault according to the solution.

[0319] In other embodiments, after obtaining a solution, the electronic device 100 can respond to a received user operation (e.g., Figure 3H The user operation applied to control 312 sends the solution to electronic device 200.

[0320] S110, after receiving the solution, the electronic device 200 repairs the first fault according to the solution.

[0321] In some embodiments, after receiving a solution, the electronic device 200 can directly repair the first fault according to the solution. For example, it can directly re-download and reinstall the microphone driver, etc.

[0322] In other embodiments, after receiving a solution, the electronic device 200 can repair the first fault according to the solution under the user's instruction. For example, the electronic device 200 can output a prompt message indicating that the microphone driver will be re-downloaded and reinstalled, and the electronic device 200 will only re-download and reinstall the microphone driver after the user agrees to install it.

[0323] In some other embodiments, after the electronic device 100 obtains and outputs the solution, the user can directly repair the first fault of the electronic device 200 according to the solution, without the electronic device 100 sending the solution to the electronic device 200. For example, if the solution output by the electronic device 100 is to turn off the device's "highlight mode", the user can manually turn off the "highlight mode" of the electronic device 200.

[0324] Understandably, steps S107-S110 above are optional operations.

[0325] Using the device fault detection method provided in Example 1, electronic device 100 can initiate fault detection for electronic device 200 on its own device, and electronic device 100 can directly present the detection results and solutions. In other words, users can independently initiate fault detection for associated thin devices such as watches and wristbands from rich devices such as mobile phones and tablets, and the detection results can be intuitively displayed on the rich device; furthermore, the rich device can obtain relevant fault repair methods from the cloud based on the fault ID, thereby repairing the fault of the thin device, reducing users' reliance on customer service and after-sales support, and improving user experience.

[0326] In the above embodiment 1:

[0327] Electronic device 100 can be referred to as the first device, and electronic device 200 can be referred to as the second device;

[0328] The first operation can also be referred to as the first operation for detecting the second device;

[0329] Figure 3C The user interface shown can be referred to as the first user interface. Figure 3CThe information bar 303 on the smartwatch can be referred to as an option for the second device, and examples of the first operation may include actions performed on... Figure 3C User operation of the information bar 303 of the smartwatch in the user interface 33 shown;

[0330] Figure 3D The user interface 34 shown can be referred to as the second user interface. Figure 3D Control 307a in the text can be referred to as the first control;

[0331] Figure 3E The user interface 35 shown can be referred to as a third user interface. Figure 3E Multiple detection items in the process can be referred to as one or more detection items of the second device. Figure 3E Audio option 308b in the document can be referred to as the first detection item;

[0332] The first fault tree can also be called the first information.

[0333] (II) Example 2

[0334] In Example 2, electronic device 100 can trigger electronic device 300 to perform fault detection.

[0335] The difference between Embodiment 2 and Embodiment 1 is that in Embodiment 1, the electronic device 100 directly performs fault detection on the electronic device 200, while in Embodiment 2, the electronic device 100 is used to trigger the electronic device 300 to perform fault detection itself.

[0336] Both electronic devices 100 and 300 are rich devices. For example, electronic device 100 can be a mobile phone, and electronic device 300 can be a tablet computer.

[0337] Figure 7A This is a schematic diagram of the communication interfaces between electronic device 100, electronic device 300, and cloud platform 500 provided in Embodiment 2. The device fault detection method provided in Embodiment 2 will be described later in conjunction with each communication interface.

[0338] Figure 7B This is a flowchart illustrating the equipment fault detection method provided in Example 2. Figure 7B As shown, the method for detecting equipment malfunctions may include the following steps:

[0339] S201, Electronic device 100 and electronic device 300 establish a communication connection.

[0340] In some embodiments, electronic device 100 and electronic device 300 can establish a short-range connection via BT, WLAN (such as Wi-Fi P2P), NFC, ZigBee, etc. In other embodiments, electronic device 100 and other electronic devices can also establish a remote connection by logging into the same account. For example, electronic device 100 and electronic device 200 can log into the same Huawei account and connect through a Huawei server.

[0341] The specific implementation method for establishing a communication connection between electronic device 100 and electronic device 300 is similar to the method for establishing a communication connection between electronic device 100 and electronic device 200 in S101 of Embodiment 1, and can be referred to the relevant description.

[0342] refer to Figure 7A In the specific implementation, the Hicare APP for fault detection and repair in electronic device 100 is used to bind to electronic device 300. The RepairDetect APP of electronic device 100 and electronic device 300 respectively establish the above communication connection through the CoConnectService interface.

[0343] S202, Electronic device 100 displays a first user interface provided by a fault detection and repair application, the first user interface displaying one or more device options, the one or more device options including options of electronic device 300.

[0344] The first user interface can be found in the relevant description in S201 of Embodiment 1.

[0345] The options for electronic device 300, for example, can be... Figure 3C The information bar on the tablet computer is 304.

[0346] S203, electronic device 100 receives a second operation on the option applied to electronic device 300.

[0347] In some embodiments, reference Figure 3C and Figure 4A Electronic device 100 receives an action on Figure 3C After the second operation of the information bar 304 on the tablet computer in the user interface 33 shown, it can display... Figure 4A The user interface 41 is shown. Subsequently, the electronic device 100 can detect user actions performed on the control 401a and, in response to the user action, trigger the electronic device 300 to perform fault detection. In this case, the electronic device 300 can perform a comprehensive fault detection.

[0348] In other embodiments, reference is made to Figure 3C , Figures 4A-4B Electronic device 100 receives an action on Figure 3C After the second operation of the information bar 304 on the tablet computer in the user interface 33 shown, it can display... Figure 4A The user interface 41 is shown. Afterwards, the electronic device 100 can detect the user operation applied to the control 401a and display... Figure 4B The user interface 42 shown displays detection items corresponding to the electronic device 300. Subsequently, the electronic device 100 can detect user actions performed on the second detection item and trigger the electronic device 300 to perform fault detection for that second detection item. In some other embodiments, the electronic device 100 can also respond to subsequently displayed... Figure 4C The user operation detected on the control 402c triggers the electronic device 300 to perform fault detection for the second detection item. Please refer to the relevant description in the UI embodiment above for details. In this case, the electronic device 100 can trigger the electronic device 300 to perform fault detection on the second detection item, enabling targeted detection and quickly and accurately identifying any faults in the electronic device 300.

[0349] In the above embodiments, reference is made to Figure 4B The detection items corresponding to electronic device 300 may include detectable items of a tablet computer, such as image and display options, audio options, camera options, battery options, sensor options, network options, interface options, software system options, and all options, etc. Among them, all options include all detectable items of electronic device 300. An example of the second detection item could be... Figure 4B Battery options in the settings.

[0350] Here, the specific methods by which the electronic device 300 acquires its own detectable items may include the following:

[0351] 1. Electronic device 300 has its own preset detectable items, which can be directly obtained from the preset detectable items.

[0352] 2. Electronic device 300 can obtain its own device information and / or location, and then send its device information and / or location to cloud platform 500 to obtain the latest version of detectable items of electronic device 300.

[0353] In the specific implementation, electronic device 300 can obtain device information, location, etc. of electronic device 200 from the system service of electronic device 200 through the GetDeviceInfo interface.

[0354] In some embodiments, the DetectRepair APP of electronic device 300 can upload device information and / or its location, as well as the current version number of the profile file containing detectable items of electronic device 300, to cloud platform 500 via the UpdateDiagnosisProfile interface. The cloud platform can verify whether the detectable items of electronic device 300 have been updated. If updated, it returns the latest version of the profile file containing the detectable items of electronic device 300 to the DetectRepair APP of electronic device 300.

[0355] 3. Electronic device 300 can obtain its device information and / or its location, and then, based on the device information and / or its location, match the detectable items of electronic device 200 in the latest version of the profile file containing various detection items issued by cloud platform 500.

[0356] In some embodiments, the DetectRepair APP of the electronic device 300 can obtain the latest version of the profile file containing various detection items from the cloud platform 500 through the UpdateDiagnosisProfile interface. This profile file containing various detection items can be a large set of detection items applicable to different devices. The electronic device 300 can find the detection items that match its own device information and / or its location in this set of detection items, i.e., the detection items of the electronic device 300.

[0357] In addition to the three methods mentioned above for obtaining the detection items of electronic device 300, electronic device 300 can also obtain detection items through other methods, which are not limited here.

[0358] In the specific implementation, refer to Figure 7A After electronic device 300 obtains its own detectable items, the DetectRepair APP of electronic device 100 can retrieve the detectable items of electronic device 300 from the DetectRepair APP of electronic device 300 through the GetDiagnosisCapability method in the CoDiagnosisInterface interface, and display them. Figure 4B The user interface 42 shown.

[0359] S204, Electronic device 100 sends a fault detection command to electronic device 300.

[0360] This fault detection command is used to trigger the electronic device 300 to perform fault detection. That is, this fault detection command is used to trigger subsequent steps S205-S212. The fault detection command may carry indication information of the detection type, which may include overall fault detection or fault detection for a second detection item.

[0361] In practice, the DetectRepair APP of electronic device 100 can send the fault detection command to the DetectRepair APP of electronic device 300 through the StartDiagnosis interface.

[0362] S205, Electronic device 300 obtains the second fault tree from cloud platform 500.

[0363] In some embodiments, electronic device 100 may send a fault detection command to electronic device 300 after receiving the second operation. Electronic device 300 may respond to the fault detection command and obtain a second fault tree from cloud platform 500.

[0364] The method for obtaining the second fault tree is similar to that of the first fault tree in Example 1, and can be found in the relevant description.

[0365] The second fault tree can include fault trees corresponding to all detection items of the electronic device 300, such as audio fault tree, network fault tree, battery fault tree, etc.

[0366] The second fault tree can also be a fault tree corresponding to the second detection item, such as a battery fault tree.

[0367] In a specific implementation, the DetectRepair APP in the electronic device 300 can obtain the second fault tree from the cloud platform 500 through the GetFaultTree interface.

[0368] In some other embodiments, before receiving a detection command from electronic device 100, electronic device 300 can obtain the fault tree corresponding to each detection item of electronic device 300 from cloud platform 500 in advance. Electronic device 300 can also periodically obtain the fault tree corresponding to each detection item from cloud platform 500. Then, electronic device 300 can find a second fault tree among multiple fault trees. This allows for pre-downloading of the fault tree, improving the efficiency of fault detection.

[0369] S206, Electronic device 300 acquires its own operating data, which includes one or more of the following: log data, hardware data, or system configuration information.

[0370] The operating data of electronic device 300 can be found in the description of the operating data of electronic device 200 in Embodiment 1. The two are similar and will not be repeated here.

[0371] In specific implementation, the DetectRepair APP of electronic device 300 can obtain log data from the HiView service through the GetDiagnosisInfo interface, obtain hardware operation data from the HAL layer through the GetDeviceInfo interface, and obtain system configuration information from the system service through the GetSystemState interface.

[0372] S207, electronic device 300 determines the second fault based on the second fault tree and the operating data of electronic device 300.

[0373] For a detailed description of the implementation of S207, please refer to the relevant description of S106 in Embodiment 1, which will not be repeated here.

[0374] In some embodiments, during fault detection, the electronic device 300 can provide real-time feedback on the detection progress to the electronic device 100, so that the electronic device 100 can display the detection progress on a display screen. For example, the electronic device 100 displays on the display screen... Figure 4E The user interface 44 is shown. That is to say, during S203-S207, the electronic device 100 can display the detection progress on the screen in real time for the user's convenience.

[0375] S208, electronic device 300 sends the indication information of the second fault to electronic device 100.

[0376] After determining the second fault, electronic device 300 can notify electronic device 100 of the second fault. There are various ways to implement the indication information of the second fault, which are not limited here.

[0377] S209, Electronic device 100 obtains the solution corresponding to the second fault.

[0378] S210, Electronic device 100 displays the second fault and solution.

[0379] An example of a second fault and solution displayed by electronic device 100 can be found here. Figure 4F The user interface 44 shown includes text indicating a second fault (such as the text "Fault cause: Battery aging") and text indicating a solution (such as the text "Repair suggestion: Replace battery").

[0380] In addition to displaying directly on the screen, the electronic device 100 can also output a second fault and solution through voice broadcast, vibration, and other means.

[0381] S211, Electronic device 100 sends the solution to electronic device 300.

[0382] S212, After receiving the solution, electronic device 300 repairs the first fault according to the solution.

[0383] For the specific implementation of steps S209-S212, please refer to S107-S110 in Embodiment 1.

[0384] Understandably, steps S208-S212 above are optional operations.

[0385] In some other embodiments, steps S208-S212 described above can also be replaced with other steps. For example, electronic device 300 can directly obtain the solution corresponding to the second fault and perform self-repair, without the need for electronic device 100 to relay the solution.

[0386] Using the device fault detection method provided in Example 2, electronic device 100 can trigger electronic device 300 to perform fault detection. Furthermore, electronic device 100 can directly display the fault detection results and solutions of electronic device 300. In other words, rich-data devices such as mobile phones possess functions similar to smart remote controls. Users can initiate fault detection on other rich-data devices such as tablets from their mobile phones, and the detection results and repair methods can be intuitively displayed on the mobile phone. In addition, after completing the fault detection, users can directly issue repair commands on their mobile phones to fix faults in rich-data devices such as tablets. This allows for direct initiation of fault detection and issuance of repair commands on rich-data devices, which is convenient, fast, and improves the user experience.

[0387] In the above embodiment 2:

[0388] Electronic device 100 can be referred to as the first device, and electronic device 300 can be referred to as the third device;

[0389] The second operation can also be referred to as the second operation of detecting the third device;

[0390] Figure 3C The user interface shown can be referred to as the first user interface. Figure 3C The information bar 304 on the tablet computer can be referred to as an option for a second device, and examples of the second operation may include actions performed on... Figure 3C User operation of the information bar 304 of the tablet computer in the user interface 33 shown;

[0391] Figure 4A The user interface 41 shown can be referred to as the fourth user interface. Figure 4A Control 401a in the text can be referred to as a second control;

[0392] Figure 4B The user interface 42 shown can be referred to as the fifth user interface. Figure 4B Multiple detection items in the process can be referred to as one or more detection items of the third device. Figure 4B The battery option in the settings can be referred to as the second detection item;

[0393] The second fault tree can also be called the second information.

[0394] (III) Example 3

[0395] In Example 3, electronic device 100 and electronic device 400 work together, and electronic device 100 can perform joint fault detection on both parties in the collaborative scenario.

[0396] Electronic device 100 is a rich device, and electronic device 200 can be a thin device or a rich device.

[0397] Multi-device collaboration scenarios can include screen mirroring, projection, multi-screen collaboration, and so on. For example, electronic device 100 can be a mobile phone, and electronic device 400 can be a smart screen or projector, etc.

[0398] Figure 8A This is a schematic diagram of the communication interfaces between electronic device 100, electronic device 400, and cloud platform 500 provided in Embodiment 3. The device fault detection method provided in Embodiment 3 will be described below in conjunction with each communication interface.

[0399] Figure 8B This is a schematic flowchart of the equipment fault detection method provided in Example 3. Figure 8B As shown, the method for detecting equipment malfunctions may include the following steps:

[0400] S301, Electronic device 100 and electronic device 400 establish a communication connection and work together.

[0401] In some embodiments, electronic device 100 and electronic device 400 can establish a short-range connection via BT, WLAN (such as Wi-Fi P2P), NFC, ZigBee, etc. In other embodiments, electronic device 100 and other electronic devices can also establish a remote connection by logging into the same account. For example, electronic device 100 and electronic device 400 can log into the same Huawei account and connect through a Huawei server.

[0402] The specific implementation method for establishing a communication connection between electronic device 100 and electronic device 400 is similar to the method for establishing a communication connection between electronic device 100 and electronic device 200 in S101 of Embodiment 1, and can be referred to the relevant description.

[0403] refer to Figure 8A In the specific implementation, the HiCare APP for fault detection and repair in electronic device 100 is used to bind to electronic device 400. The RepairDetect APP of electronic device 100 and electronic device 400 respectively establish the above communication connection through the CoConnectService interface.

[0404] S302, Electronic device 100 displays a first user interface provided by a fault detection and repair application, the first user interface displaying one or more device options, the one or more device options including options of electronic device 400.

[0405] The first user interface can be found in the relevant description in S201 of Embodiment 1.

[0406] The options for electronic device 400, for example, can be... Figure 3C The information bar 305 on the smart screen.

[0407] S303, electronic device 100 receives a third operation on the option applied to electronic device 400.

[0408] In some embodiments, reference Figure 3C and Figure 5A Electronic device 100 receives an action on Figure 3C After the third operation of the information bar 305 on the smart screen in the user interface 33 shown, it can display... Figure 5A The user interface 51 is shown. Afterwards, the electronic device 100 can detect the user operation applied to the control 501a and, in response to the user operation, trigger the electronic device 100 to perform joint fault detection for the collaborative screen-sharing scenario.

[0409] In other embodiments, reference is made to Figure 3C , Figures 5A-5B Electronic device 100 receives an action on Figure 3C After the third operation of the information bar 305 on the smart screen in the user interface 33 shown, it can display... Figure 5A The user interface 51 is shown. Afterwards, the electronic device 100 can detect the user operation applied to the control 501a and display... Figure 5BThe user interface 52 shown displays the detection items corresponding to electronic devices 100 and 400, as well as a third detection item. Electronic device 100 can then detect user actions applied to the third detection item and trigger joint fault detection for the collaborative screen-sharing scenario.

[0410] In the above embodiments, reference is made to Figure 5B The detection items corresponding to electronic devices 100 and 400 may include image and display options, audio options, camera options, battery options, sensor options, network options, etc. The method by which electronic device 100 acquires the corresponding detection items of both devices can be found in the relevant descriptions of Embodiments 1 and 2, and will not be repeated here.

[0411] The third test item is a joint test item for electronic devices 100 and 400, for example, it could be... Figure 5B The screen mirroring options are shown. Specifically, when electronic devices 100 and 400 are detected working collaboratively, this third detection item can be displayed in the first user interface.

[0412] S304, Electronic device 100 obtains the third fault tree from cloud platform 500.

[0413] In some embodiments, the fault tree in the cloud platform 500 can be classified according to different collaborative scenarios, such as screen projection scenario fault tree, projection scenario fault tree, multi-screen collaborative scenario fault tree, etc.

[0414] The third fault tree is the fault tree corresponding to the collaborative scenario between electronic device 100 and electronic device 400, describing the logical relationship between faults and their causes in this collaborative scenario. For example, the third fault tree could be the fault tree corresponding to a screen projection scenario.

[0415] In some other embodiments, the electronic device 100 can directly obtain the third fault tree from the cloud platform 500 after receiving the third operation in S303. This allows the fault tree to be downloaded in advance, improving the efficiency of fault detection.

[0416] S305, Electronic device 100 obtains the operating data of electronic device 400 from electronic device 400. The operating data includes one or more of the following: log data, hardware data, or system configuration information.

[0417] Specifically, electronic device 400 can first obtain its own operating data, and then the RepairDetect APP of electronic device 100 obtains the operating data from the RepairDetect APP of electronic device 400 through the CoDiagnosisInterface interface. For details on how electronic device 400 obtains its own operating data, please refer to the relevant description in S206 of Embodiment 2.

[0418] S306, Electronic device 100 acquires its own operating data.

[0419] For details on how the electronic device 100 acquires its own operating data, please refer to the relevant description in S206 of Embodiment 2.

[0420] S307, Electronic device 100 determines the third fault based on the third fault tree, the operating data of electronic device 100, and the operating data of electronic device 400.

[0421] Since the third fault tree is a tree diagram that represents the logical relationship between faults and fault causes in a collaborative work scenario, and encompasses faults caused by various factors such as hardware, software, environment, and human factors, the faults existing in the current collaborative scenario can be analyzed in the third fault tree based on the operating data of electronic devices 100 and 400, i.e., the third faults.

[0422] The third fault may exist in electronic device 100, electronic device 400, or both electronic device 100 and electronic device 400; no limitation is made here.

[0423] S308, Electronic device 100 obtains the solution corresponding to the third fault.

[0424] S309, Electronic Device 100 displays the third fault and solution.

[0425] S308 and S309 can refer to S107 and S108 in Example 1.

[0426] S310, electronic device 100 and / or electronic device 400, according to this solution, repair the third fault.

[0427] If the third fault is located in electronic device 100, electronic device 100 can repair the third fault according to the solution.

[0428] If the third fault is located in electronic device 400, electronic device 100 can send a solution to electronic device 400 so that electronic device 400 can repair the third fault.

[0429] In some embodiments, electronic device 100 and / or electronic device 400 can, upon user triggering, repair a third fault according to the solution. For example, refer to Figure 5E When electronic device 100 detects the user operation shown in the figure, electronic device 100 and / or electronic device 400 begin to repair the third fault.

[0430] Understandably, steps S307-S310 above are optional operations.

[0431] Not limited to the electronic device 400 exemplified in Embodiment 3, in specific implementations, the collaborative working scenario may also include more devices, and the electronic device may also combine the operating data of more devices to perform joint fault detection.

[0432] Using the device fault detection method provided in Example 3, the electronic device 100 can comprehensively analyze the operational data of various devices involved in a collaborative work scenario to perform joint fault detection, and can also directly present the detection results and solutions. This enables accurate detection of faults in collaborative work scenarios, reduces users' reliance on customer service and after-sales support, and improves user experience.

[0433] In collaborative work scenarios, the method provided in Example 3 can comprehensively detect faults. For example, in a collaborative work scenario, each of the individual devices may be functioning correctly, but a fault may occur during collaborative operation. In this case, Example 3 can accurately detect the fault.

[0434] In the above embodiment 3:

[0435] Electronic device 100 can be referred to as the first device, and electronic device 400 can be referred to as the fourth device;

[0436] Figure 3C The user interface shown can be referred to as the first user interface. Figure 3C The information bar 305 on the smart screen can be referred to as an option for the fourth device; examples of the third operation may include actions performed on... Figure 3C User operation of the information bar 305 of the smart screen in the user interface 33 shown;

[0437] Figure 5A The user interface 51 shown can be referred to as the sixth user interface. Figure 5A Control 501a in the text can be referred to as a third control;

[0438] Figure 5B The user interface 52 shown can be referred to as the seventh user interface. Figure 5B Multiple detection items in the process can be referred to as one or more detection items of the fourth device. Figure 5B The screen mirroring option in the system can be referred to as the third detection item;

[0439] The third fault tree can also be called the third information.

[0440] The above embodiments provide methods for fault detection and repair. However, this application also provides a fault probability detection method, a security vulnerability detection method, and so on. Specifically, similar to the above embodiments, the difference lies in that the electronic device can calculate the probability of various faults based on operating data and fault trees, or identify certain links with relatively low security or reliability. This allows for the implementation of corresponding improvement measures before a fault occurs, further reducing the probability of failure.

[0441] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

[0442] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0443] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0444] In summary, the above description is merely an embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made according to the disclosure of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for detecting equipment faults, characterized in that, The method is applied to a first device, and the method includes: Received the first operation from the second detection device; One or more detection items of the second device are obtained from the second device; or, the device information of the second device is obtained, and one or more detection items of the second device are obtained from the cloud platform based on the device information of the second device; or, the device information of the second device is obtained, and the correspondence between multiple different device information and detection items is obtained from the cloud platform, and one or more detection items of the second device are determined from the correspondence based on the device information of the second device, wherein the device information includes one or more of the following: device type, device model, software system type or software system version number, and region; Received a user operation to select the first detection item from one or more detection items of the second device; Obtain the operating data of the second device, which includes one or more of the following: log data, hardware data, or system configuration information; Based on the first information and the operating data of the second device, a first fault of the second device is determined. The first information describes the logical relationship between the fault and the cause of the fault corresponding to the first detection item of the second device.

2. The method according to claim 1, characterized in that, After determining the first fault of the second device, the method further includes: Output the indication information for the first fault.

3. The method according to claim 1, characterized in that, After determining the first fault of the second device, the method further includes: Obtain the solution corresponding to the first fault from the cloud platform; Output the solution corresponding to the first fault.

4. The method according to claim 1, characterized in that, After determining the first fault of the second device, the method further includes: Obtain the solution corresponding to the first fault from the cloud platform; The solution corresponding to the first fault is sent to the second device, which then repairs the first fault.

5. The method according to any one of claims 1-4, characterized in that, Before receiving the first operation from the second detection device, the method further includes: A first user interface is displayed, which shows options for the second device; The first operation includes user operations on options applied to the second device.

6. The method according to any one of claims 1-4, characterized in that, After receiving the first operation to detect the second device and before acquiring the operating data of the second device, the method further includes: In response to the first operation, a second user interface is displayed, the second user interface including the first control; Received user operation applied to the first control.

7. The method according to any one of claims 1-4, characterized in that, Before determining the first fault of the second device, the method further includes: Obtain one or more of the following information: the device type, device model, software system type, or software system version of the second device; Based on one or more of the aforementioned information, the first information is obtained from the cloud platform, wherein the first information describes the logical relationship between the fault and the cause of the fault corresponding to the one or more of the aforementioned information.

8. The method according to any one of claims 1-4, characterized in that, After receiving the first operation to detect the second device and before acquiring the operating data of the second device, the method further includes: In response to the first operation, a second user interface is displayed, the second user interface including the first control; In response to a user operation applied to the first control, a third user interface is displayed, which displays one or more detection items of the second device; The user operation of selecting a first detection item among one or more detection items of the second device includes: the user operation performed on the first detection item among the one or more detection items.

9. The method according to any one of claims 1-4, characterized in that, Before determining the first fault of the second device, the method further includes: In response to a user action performed on the first detection item, the first information is obtained from the cloud platform.

10. The method according to any one of claims 1-4, characterized in that, Before determining the first fault of the second device, the method further includes: Obtain information corresponding to the one or more detection items from the cloud platform; Wherein, the first information is the information corresponding to the one or more detection items, and the information corresponding to the first detection item.

11. A method for detecting equipment faults, characterized in that, The method is applied to a first device, which works collaboratively with a fourth device, and the method includes: Received third operation; Obtain the operating data of the fourth device and the operating data of the first device, wherein the operating data includes one or more of the following: log data, hardware data, or system configuration information; Obtain one or more of the following information: the device type, device model, software system type or software system version of the first device, and the device type, device model, software system type or software system version of the fourth device; Based on one or more of the acquired information, obtain third information from the cloud platform; Based on the third information, the operating data of the fourth device, and the operating data of the first device, a third fault is determined. The third information describes the logical relationship between the fault and the cause of the fault corresponding to the first scenario in which the first device and the fourth device work together.

12. The method according to claim 11, characterized in that, The third information describes the logical relationship between the fault and the cause of the fault corresponding to the third detection item in the first scenario. The third detection item is the detection item selected by the user.

13. An electronic device, characterized in that, include: A memory and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors calling the computer instructions to cause the electronic device to execute: Received the first operation from the second detection device; One or more detection items of the second device are obtained from the second device; or, the device information of the second device is obtained, and one or more detection items of the second device are obtained from the cloud platform based on the device information of the second device; or, the device information of the second device is obtained, and the correspondence between multiple different device information and detection items is obtained from the cloud platform, and one or more detection items of the second device are determined from the correspondence based on the device information of the second device, wherein the device information includes one or more of the following: device type, device model, software system type or software system version number, and region; Received a user operation to select the first detection item from one or more detection items of the second device; Obtain the operating data of the second device, which includes one or more of the following: log data, hardware data, or system configuration information; Based on the first information and the operating data of the second device, a first fault of the second device is determined. The first information describes the logical relationship between the fault and the cause of the fault corresponding to the first detection item of the second device.

14. The electronic device according to claim 13, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: After determining the first fault of the second device, the indication information of the first fault is output.

15. The electronic device according to claim 13, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: After determining the first fault of the second device, obtain the solution corresponding to the first fault from the cloud platform; Output the solution corresponding to the first fault.

16. The electronic device according to claim 13, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: After determining the first fault of the second device, obtain the solution corresponding to the first fault from the cloud platform; The solution corresponding to the first fault is sent to the second device, which then repairs the first fault.

17. The electronic device according to any one of claims 13-16, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: Before receiving the first operation to detect the second device, a first user interface is displayed, which shows options for the second device. The first operation includes user operations on options applied to the second device.

18. The electronic device according to any one of claims 13-16, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: After receiving the first operation to detect the second device, and before acquiring the operating data of the second device, in response to the first operation, a second user interface is displayed, the second user interface including a first control; Received user operation applied to the first control.

19. The electronic device according to any one of claims 13-16, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: Before determining the first fault of the second device, obtain one or more of the following information: the device type, device model, software system type, or software system version of the second device; Based on one or more of the aforementioned information, the first information is obtained from the cloud platform, wherein the first information describes the logical relationship between the fault and the cause of the fault corresponding to the one or more of the aforementioned information.

20. The electronic device according to any one of claims 13-16, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: After receiving the first operation to detect the second device, and before acquiring the operating data of the second device, in response to the first operation, a second user interface is displayed, the second user interface including a first control; In response to a user operation applied to the first control, a third user interface is displayed, which displays one or more detection items of the second device; The user operation of selecting a first detection item among one or more detection items of the second device includes: the user operation performed on the first detection item among the one or more detection items.

21. The electronic device according to any one of claims 13-16, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: Before determining the first fault of the second device, the first information is obtained from the cloud platform in response to a user operation performed on the first detection item.

22. The electronic device according to any one of claims 13-16, characterized in that, The one or more processors are also configured to invoke the computer instructions to cause the electronic device to execute: Before determining the first fault of the second device, information corresponding to the one or more detection items is obtained from the cloud platform; Wherein, the first information is the information corresponding to the one or more detection items, and the information corresponding to the first detection item.

23. An electronic device, characterized in that, include: A memory and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors calling the computer instructions to cause the electronic device to execute: Received third operation; Obtain the operating data of the fourth device and the operating data of the electronic device, wherein the operating data includes one or more of the following: log data, hardware data or system configuration information; Obtain one or more of the following information: the device type, device model, software system type or software system version of the first device, and the device type, device model, software system type or software system version of the fourth device; Based on one or more of the acquired information, obtain third information from the cloud platform; Based on the third information, the operating data of the fourth device, and the operating data of the electronic device, a third fault is determined. The third information describes the logical relationship between the fault and the cause of the fault corresponding to the first scenario in which the electronic device and the fourth device work together.

24. The electronic device according to claim 23, characterized in that, The third information describes the logical relationship between the fault and the cause of the fault corresponding to the third detection item in the first scenario. The third detection item is the detection item selected by the user.

25. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on an electronic device, the electronic device causes the electronic device to perform the method as described in any one of claims 1-12.

26. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1-12.

27. A communication system, characterized in that, The communication system includes: a first device and a second device, wherein the first device is configured to perform the method as described in any one of claims 1-12.

Images