Fault analysis method and electronic equipment

By collecting and analyzing user fault information in electronic devices and determining the working data for handling incidents, the problem of low efficiency in electronic devices is solved, and fast and accurate fault analysis and solution push is achieved.

CN119271440APending Publication Date: 2025-01-07HONOR DEVICE CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202410269034.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-03-08
Publication Date
2025-01-07

AI Technical Summary

Technical Problem

Failures encountered by users when using electronic devices, such as inaccurate GPS positioning and lag in gaming, lead to low fault handling efficiency, and it is difficult for the existing technology to quickly analyze the cause of the fault.

Method used

By collecting fault information reported by users in electronic devices, determining the associated control events, and screening out the target control events as the cause of the fault based on the work data of the control events, and using large language models and preset judgment rules to improve the accuracy of fault analysis. Sex and efficiency.

Benefits of technology

It realizes rapid and accurate analysis of the root causes of electronic equipment failures, improves fault handling efficiency, and can push solutions to users.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119271440A_ABST
    Figure CN119271440A_ABST
Patent Text Reader

Abstract

The invention provides a fault analysis method and electronic equipment, which are applied to the electronic equipment, and the method comprises the following steps: the electronic equipment collects fault information for the electronic equipment reported by a user; the electronic equipment determines at least one associated dotting event based on the fault information; wherein each dotting event corresponds to working data of the event during operation of the electronic equipment; and the electronic equipment screens out a target dotting event in the at least one dotting event based on the working data corresponding to each dotting event, and the target dotting event is used as a reason of the fault information. According to the scheme, the root cause of the fault of the electronic equipment can be quickly analyzed according to the fault information provided by the user, and the fault processing efficiency of the electronic equipment is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the technical field of electronic equipment, and in particular to a fault analysis method and electronic equipment. Background Art

[0002] Currently, when using electronic devices, users may find various problems during use, such as inaccurate global positioning system (GPS) positioning, lags when playing games, etc., which affect the user experience.

[0003] Users may report various problems encountered during the use of electronic devices through various means such as text messages, phone calls, and online messages. However, based on the information provided by users, R&D personnel are unable to quickly analyze the causes of the above problems in electronic devices, which affects the efficiency of troubleshooting of electronic devices. Summary of the invention

[0004] The embodiments of the present application provide a fault analysis method and an electronic device, which can quickly analyze the root cause of a fault in an electronic device based on fault information provided by a user, thereby improving the fault handling efficiency of the electronic device.

[0005] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0006] In a first aspect, a fault analysis method is provided, which is applied to an electronic device, and the method includes: the electronic device can collect fault information reported by a user for the electronic device. The fault information reported by the user can refer to a fault discovered by the user during the use of the mobile phone. The electronic device determines at least one associated dotting event based on the received fault information; each dotting event corresponds to working data of the event during the operation of the electronic device. Then, the electronic device can screen out a target dotting event in at least one dotting event as the cause of the fault information based on the working data corresponding to each dotting event.

[0007] By adopting the above solution, the electronic device can determine the dotting event corresponding to each fault information by analyzing the fault information reported by the user. Then, the electronic device can determine the target dotting event that causes the fault based on the corresponding judgment conditions for the working data corresponding to each dotting event. As a result, the electronic device can accurately analyze the root cause of the fault described in the fault information reported by the user, thereby improving the fault handling efficiency of the electronic device.

[0008] In a possible implementation of the first aspect, the electronic device determines at least one associated dotting event based on fault information, including: the electronic device extracts at least one viewpoint from the fault information; wherein one viewpoint corresponds to one fault scenario. The electronic device determines at least one dotting event associated with the fault scenario corresponding to each viewpoint. The above viewpoints can be extracted by a pre-trained large language model.

[0009] Through viewpoint extraction, this solution can identify all fault scenarios contained in the fault information, and then determine the cause of each fault scenario.

[0010] In a possible implementation of the first aspect, screening out a target dotting event from at least one dotting event includes: the electronic device determines whether the working data of each dotting event satisfies a corresponding judgment condition when obtaining working data corresponding to each dotting event. Different dotting events correspond to different judgment conditions. When the working data of the dotting event satisfies the corresponding judgment condition, the dotting event is used as the target dotting event.

[0011] This solution can analyze each dotting event corresponding to the fault information by detecting whether the working data of each dotting event meets the judgment condition, so as to accurately analyze the cause of the fault information. In addition, since the mapping relationship between the fault information and the dotting event is set in advance in the electronic device, the efficiency of fault analysis is further improved when the cause of the fault information is comprehensively analyzed.

[0012] In a possible implementation of the first aspect, before the electronic device screens out a target dotting event from at least one dotting event based on the work data corresponding to each dotting event, the method further includes: the electronic device determines the attributes of the dotting event and the mapping relationship between the attributes and the preset judgment rules. The preset judgment rules include at least fault rules, command rules, node rules, and code rules. The electronic device determines the judgment condition corresponding to the dotting event based on the preset judgment rule corresponding to the attribute of the dotting event.

[0013] In a possible implementation of the first aspect, the electronic device determines a judgment condition corresponding to the dotting event based on a preset judgment rule corresponding to the attribute of the dotting event, including: the electronic device determines at least one parameter corresponding to each dotting event; the electronic device generates a judgment condition corresponding to the dotting event based on the preset judgment condition corresponding to the parameter and the preset judgment rule corresponding to the attribute of the dotting event. This solution can improve the accuracy of fault analysis by further judging the parameters corresponding to the dotting event.

[0014] In a possible implementation of the first aspect, the electronic device collects fault information about the electronic device reported by a user, including: the electronic device collects fault information reported by the user through a preset collection module of the electronic device; wherein the fault information includes a voice message or a text message.

[0015] In a possible implementation of the first aspect, after the electronic device screens out a target dotting event from at least one dotting event as the cause of the fault information based on the working data corresponding to each dotting event, it also includes: the electronic device determines a corresponding solution based on the target dotting event and pushes the solution to the user.

[0016] In a possible implementation of the first aspect, the electronic device determines a corresponding solution based on a target tapping event and pushes the solution to a user, including: the electronic device determines at least one target parameter corresponding to the target tapping event. Then, the electronic device determines a solution corresponding to each target parameter and pushes the solution to the user.

[0017] In a second aspect, a fault analysis method is applied to an electronic device, the method comprising: the electronic device collects fault information about the electronic device reported by a user. The electronic device sends the fault information to a cloud server, so that the cloud server obtains at least one associated dotting event based on the fault information, and based on the working data corresponding to each dotting event, screens out a target dotting event in at least one dotting event as the cause of the fault information. Each dotting event corresponds to the working data of the event during the operation of the electronic device.

[0018] In this solution, an intelligent diagnosis engine is provided in the cloud server to diagnose the fault information uploaded by the electronic device, so as to determine the cause of the fault information.

[0019] In a possible implementation of the second aspect, the method further includes: the electronic device receives a solution sent by the cloud server, and pushes the solution to the user, wherein the solution is determined by the cloud server based on the target marking event.

[0020] In a possible implementation of the second aspect, the method further includes: after the cloud server screens out a target dotting event from the at least one dotting event as the cause of the fault information, the cloud server may also send the target dotting event to the electronic device. After receiving the target dotting event, the electronic device determines a corresponding solution based on the target dotting event. Then, the electronic device pushes the solution to the user.

[0021] In a third aspect, a fault analysis method is provided, which is applied to a cloud server, and the method includes: the cloud server receives fault information about an electronic device reported by a user, and then obtains at least one associated dotting event based on the fault information. Each dotting event corresponds to working data of the event during the operation of the electronic device. Based on the working data corresponding to each dotting event, the cloud server screens out a target dotting event in at least one dotting event as the cause of the fault information.

[0022] By adopting the above scheme, the cloud server can receive the fault information reported by the user and obtain the corresponding dotting event from the electronic device based on each fault information. Then the cloud server can determine the dotting event that caused the fault based on the corresponding judgment conditions for the working data corresponding to each dotting event. As a result, the cloud server can accurately analyze the root cause of the fault described in the fault information reported by the user for the mobile phone. By determining the dotting event corresponding to each fault information in advance, the cloud server can analyze all possible dotting events that cause the fault information, and the analysis of the cause of the fault information is more comprehensive, further improving the efficiency of fault analysis.

[0023] In a possible implementation of the third aspect, a cloud server receives fault information about an electronic device reported by a user, including: the cloud server receives fault information reported by the user through a preset collection module of the electronic device; wherein the fault information includes a voice message or a text message; and / or, the cloud server receives fault information reported by the user through a hotline; and / or, the cloud server receives fault information reported by the user through an outlet.

[0024] In a possible implementation manner of the third aspect, the method further includes: the cloud server determines a corresponding solution based on the target marking event, and pushes the solution to the user.

[0025] The cloud server may also push solutions to users via electronic devices, and / or hotlines, and / or outlets.

[0026] In a possible implementation of the third aspect, the method further includes: the cloud server sends the target tapping event to the electronic device, so that the electronic device determines a corresponding solution based on the received target tapping event. Then, the electronic device pushes the solution to the user.

[0027] In a possible implementation of the third aspect, the method also includes: if the number of times the cloud server receives fault information within a preset time period exceeds a preset threshold, the cloud server sends early warning information for the fault information; and / or, if the number of times the cloud server collects fault information reported by users through a hotline or outlets within a preset time period exceeds a preset threshold, the cloud server sends early warning information for the fault information through a hotline or outlet.

[0028] In this solution, the cloud server sends warning information for the fault information via mobile phone, and / or hotline and / or outlets, which can remind users who use the product corresponding to the fault information of possible fault information of the product.

[0029] In a fourth aspect, the present application provides an electronic device, comprising: a communication module, a memory and one or more processors; the communication module, the memory and the processor are coupled; the memory is used to store computer program code, the computer program code includes computer instructions, and when the computer instructions are executed by the electronic device, the electronic device executes the methods described in the first, second and third aspects above.

[0030] In a fifth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, the computer can execute any of the methods in the first, second and third aspects above.

[0031] In a sixth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute any of the methods in the first, second and third aspects above.

[0032] It can be understood that the electronic device described in the fourth aspect provided above, the computer-readable storage medium described in the fifth aspect and the computer program product described in the sixth aspect are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 An example table diagram of a VOC top positioning problem scenario and GPS fault point definition provided in an embodiment of the present application;

[0034] Figure 2 A schematic diagram of a fault reporting and diagnosis process provided in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of the association between a fault scenario and a dot event provided in an embodiment of the present application;

[0036] Figure 4 A schematic diagram of a fault analysis process provided by an embodiment of the present application;

[0037] Figure 5 An example diagram of a scenario fault tree provided in an embodiment of the present application;

[0038] Figure 6 A schematic diagram of a scenario fault tree analysis provided in an embodiment of the present application;

[0039] Figure 7 Another schematic diagram of a fault reporting and diagnosis process provided in an embodiment of the present application

[0040] Figure 8 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application;

[0041] Fig. 9 A timing diagram of software implementation of a charging method provided in an embodiment of the present application;

[0042] Fig.10 A schematic diagram of the structure of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments. The following terms "first", "second", etc. are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the number of indicated technical features. Thus, features defined as "first", "second", etc. may explicitly or implicitly include one or more of the features.

[0044] First, professional terms related to this patent are introduced.

[0045] Dotting: refers to inserting some logging code into the program to record the program's running status, output key information, and monitor program behavior. Dotting is mainly used to obtain the program's running status and distinguish the program's execution path, to track the program's execution process, locate potential problems, and optimize performance.

[0046] Voice of Customer (VOC): refers to the process of collecting customer opinions, needs, suggestions and experiences through various channels and methods, and using this information for product development, service improvement and user experience optimization.

[0047] In the embodiment of the present application, the electronic device is described as a mobile phone, and various faults may occur during the use of the mobile phone. Then, if the user perceives a fault during the use of the mobile phone, he may report the fault through various methods.

[0048] Taking the scenario of VOC failure as an example, the information fed back by VOC is the failure described by the user during the use of the mobile phone. The failure described by the user here corresponds to a broader failure scenario.

[0049] Tracking can monitor the status of the program when it is running. Usually, the tracking settings are relatively detailed and cannot be associated with the faults described by the users, resulting in R&D personnel being unable to quickly analyze the root causes of the faults based on the faults described by the users.

[0050] Common faults described by users include fast power consumption, heating, lag, poor signal, GPS navigation abnormalities, etc. At present, the manufacturer's staff can only judge the possible causes of the user's mobile phone problems based on the user's fault description and experience. However, this analysis is limited by factors such as the staff's experience and time, which easily leads to low efficiency and analysis errors in fault cause analysis.

[0051] A fault analysis method provided in the present application determines the dotting event corresponding to each fault information by analyzing the fault information reported by the user. Then, the electronic device screens out the target dotting event in the at least one dotting event as the cause of the fault information for the working data corresponding to each dotting event. Thus, the electronic device can accurately analyze the root cause of the fault information reported by the user. Moreover, the electronic device can determine a solution to the fault information reported by the user based on the dotting event.

[0052] Take GPS scenario as an example, see Figure 1 , Figure 1 This is an example table of a VOC top positioning problem scenario and GPS fault point definition provided in the embodiment of the present application. Figure 1As shown, the GPS scenario mainly includes six types of fault scenarios, specifically: GPS positioning failure, GPS function abnormality failure, GPS switch failure, GPS sound failure, GPS signal failure, and GPS overall experience failure. Among them, GPS positioning failure may include inaccurate GPS positioning, slow GPS positioning, GPS unable to locate, wrong pointer during navigation, unable to full screen during navigation, and unable to open the positioning service. GPS function abnormality failure may include GPS function abnormality, abnormal positioning after going abroad, navigation fever, and unable to turn on the GPS switch (pending offline). GPS switch failure may include the GPS switch cannot be found and the GPS switch automatically turns on. GPS sound failure may include low navigation sound and silent navigation. GPS signal failure may include no GPS signal and weak GPS signal. GPS overall experience failure may include poor overall GPS experience.

[0053] like Figure 1As shown in the figure, the event identification documents (EventId) and corresponding Chinese descriptions of multiple GPS dot events are as follows: XX0000006-Global Navigation Satellite System (GNSS) daily data statistics, XX0000007-GNSS abnormal events, XX0000008-Natural Language Processing (Natural Language Processing) Processing, NLP) abnormal events, XX0000009-Geocoding (Geocoder) abnormal events, XX0000017-Navigation delay event reporting, XX0000019-GPS positioning status record, XX0000020-Position jump point monitoring, XX0000021-Strict scene information, XX0000022-Observation monitoring events, XX0000026-Crowdsourcing abnormal stop, XX0009009-Related information when the position is lost, XX0009010-Related information about the first positioning timeout, XX0009011-Framework layer (FrameWork, FWK) data transmission timeout error, XX0009012-Network positioning abnormality, XX0009013-Assisted Global Positioning System (Assisted Global Positioning System System, AGPS) abnormality, XX0009014- chip abnormal reset, XX0009015- network positioning abnormality, XX0009016- Network Time Protocol (NTP) injection parameters, XX0009017- satellite history records, XX0009023- self-developed navigation wireless network (Wireless Fidelity, WiFi) service initialization failed, XX0009024-Self-developed navigation failed to connect to WiFi positioning service, XX0009025-Self-developed navigation WiFi positioning failed, XX0009039-Commercial GPS positioning session data statistics, XX0009041-User level location status, XX0009042-Preprocessing (PreProcessing) failed, XX0009043-Context (Context) module failure, XX0009061-Single use daily network positioning request, XX0009062-Saving Wizard frozen record, XX0009063-Stop global positioning system record in idle state, XX0009064-Security protection (iAware) management record.

[0054] For example, in the failure scenario where GPS cannot locate, the possible causes can correspond to at least four marking events: navigation delay event reporting (XX0000017), first positioning timeout related information (XX0009010), network positioning timeout (XX0009012), and chip abnormal reset (XX0009014).

[0055] Thus, the marking event can be associated with the fault described by the user, and diagnosis of all related fields of the field where the fault is located can be achieved.

[0056] A fault analysis method provided in an embodiment of the present application can be applied to electronic devices, and the electronic devices can include at least one of mobile phones, foldable electronic devices, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (ultra-mobile personal computers, UMPCs), netbooks, cellular phones, personal digital assistants (personal digital assistants, PDAs), augmented reality (augmented reality, AR) devices, virtual reality (virtual reality, VR) devices, artificial intelligence (artificial intelligence, AI) devices, wearable devices, vehicle-mounted devices, smart home devices, or smart city devices. The embodiment of the present application does not impose any special restrictions on the specific type of the electronic device.

[0057] See also Figure 2 , Figure 2 A schematic diagram of a fault reporting and diagnosis process provided for the implementation of this application. Figure 2 As shown, taking a mobile phone as an example, the mobile phone is provided with modules such as GPS, restart, performance, touch screen, and camera as modules that may fail in the mobile phone. The fault collection engine of the mobile phone can collect working data related to the above modules. Specifically, after receiving the fault information reported by the user, the mobile phone can collect working data of the dot event associated with the fault information through the fault collection engine.

[0058] Among them, the mobile phone can process the collected fault information locally. The mobile phone inputs the working data of the dot event associated with the collected fault information into the intelligent diagnosis engine set in the mobile phone, and determines the root cause of the fault described in the fault information through the intelligent diagnosis engine, and determines the repair plan (solution) corresponding to the fault. After the mobile phone determines the repair plan, it can interact with the user through the intelligent customer service and intelligent voice assistant set in the mobile phone. The mobile phone is also provided with a scenario fault tree management module, which can manage each scenario fault tree, such as adding or deleting a scenario fault tree, and adding dot events to a single scenario fault tree.

[0059] Among them, the mobile phone can also report the fault information that meets the preset conditions to the cloud server. The preset condition here means that the number of occurrences of the fault information exceeds the preset threshold value within the preset time. After receiving the fault information uploaded locally by multiple mobile phones, the cloud server can issue a fault warning through the fault big data warning module, for example, sending a warning information for the fault information through the mobile phone to remind users who use the product corresponding to the fault information of the possible fault information of the product.

[0060] The specific steps of a fault analysis method provided in the embodiment of the present application may include steps S101 to S103, as follows:

[0061] Step S101: The mobile phone collects fault information reported by the user.

[0062] In the embodiment of the present application, the fault information reported by the user refers to the faults found by the user during the use of the mobile phone, which may include fast power consumption, heating, lag in use, poor signal, abnormal GPS navigation, lag in playing games, lag in video calls, etc. Among them, the user can report the above fault information through different methods. Among them, the mobile phone can collect the fault information reported by the user through the preset collection module in the mobile phone. The preset collection module may include intelligent customer service or intelligent voice assistant.

[0063] For example, the mobile phone can respond to the user's operation of turning on the smart voice assistant, receive the user's voice message through the smart voice assistant, and then process the received voice message, analyze the cause of the fault, and feedback the solution to the user through the smart voice assistant.

[0064] The mobile phone can collect the fault information reported by the user and further analyze the cause of the fault information.

[0065] It is understandable that the descriptions corresponding to the same fault information are not exactly the same. For example, the fault information 1 reported by the user collected by the mobile phone is: "Frequent freezes during game play", and the fault information 2 reported by the user collected by the mobile phone is: "Freezes during game play". The mobile phone can perform semantic analysis on the fault information reported by the user, so the fault information 1 and the fault information 2 are essentially the same.

[0066] In some embodiments, assuming that corresponding options for various types of fault information can be set in the user experience improvement plan, if the user reports the fault information through the user experience improvement plan, then the user can select the corresponding option of the fault information and submit the user experience improvement plan. Thus, the mobile phone can determine the corresponding fault information through the options obtained from the user experience improvement plan. Then, the description of the fault information reported by the user here is fixed, and the mobile phone no longer performs semantic analysis on the fault information.

[0067] In an embodiment of the present application, a large language model can be constructed in the mobile phone. By inputting the fault information reported by the user into the large language model, at least one viewpoint is extracted from the fault information, and each viewpoint can correspond to a fault scenario.

[0068] For example, the fault information reported by the user is: GPS positioning is slow and inaccurate. Then, the mobile phone can extract two viewpoints from the above fault information through the large language model: Viewpoint 1, GPS positioning is slow; Viewpoint 2, GPS positioning is inaccurate. Therefore, the mobile phone can correspond to the two fault scenarios of slow GPS positioning and inaccurate GPS positioning through the two extracted viewpoints.

[0069] Step S102: The mobile phone determines at least one associated marking event based on the fault information.

[0070] In the embodiment of the present application, the mobile phone can determine at least one dot event associated with each fault information through a pre-trained large model, wherein the fault information is associated with the dot event, indicating that the dot event may be the cause of the fault described in the fault information.

[0071] Among them, the fault information can be associated with at least one RBI event. For example, if the fault information is an application restart, then the fault information can correspond to a single RBI event. For another example, if the fault information is that the GPS cannot be positioned, then the fault information can correspond to multiple RBI events, including: navigation delay event reporting, first positioning timeout related information, network positioning timeout, chip abnormal reset, etc.

[0072] If the fault information is associated with a single RBI event, then the mobile phone can accurately locate the cause of the fault after determining the RBI event associated with the fault information.

[0073] If the fault information is associated with two or more RBI events, then after determining the RBI event associated with the fault information, the mobile phone needs to further perform conditional judgment on the RBI event to determine the target RBI event, so as to accurately locate the cause of the fault.

[0074] See also Figure 3 , Figure 3 A schematic diagram of the association between a fault scenario and a dot event provided in an embodiment of the present application. The mobile phone can determine the user scenario (fault scenario) through the fault information reported by the user. The user scenario is provided with a corresponding user scenario identifier (Identity document, ID) or a corresponding user scenario description. Each dot event is provided with a corresponding event identifier or a corresponding dot event description. Figure 3 As shown, fault scenario 1 is associated with a single dotting event, and fault scenario 2 is associated with two dotting events.

[0075] In some embodiments, the dotting event associated with the fault information is not fixed, and the electronic device can update the dotting event associated with the fault information by analyzing more fault data reported by users. Wherein, updating the dotting event associated with the fault information includes adding or deleting the dotting event associated with the fault information.

[0076] For example, when the current fault information is fault 1, it corresponds to a single dot event, which is set as dot event 1. When the electronic device analyzes more fault information about fault 1 reported by users, it is possible to analyze other events that can cause fault 1. At this time, the electronic device can dot the event that causes fault 1 and set it as dot event 2. Then, the electronic device can update the dot events associated with fault 1 to include dot event 1 and dot event 2.

[0077] After the mobile phone determines a plurality of marking events according to the fault scenarios corresponding to the fault information reported by the user, it can further determine the cause of the fault information reported by the user through the judgment condition corresponding to each marking event.

[0078] Step S103: The mobile phone screens out a target dotting event from at least one dotting event based on the working data corresponding to each dotting event as the cause of the fault information.

[0079] Different dotting events may correspond to different judgment conditions, and the mobile phone may judge whether the working data corresponding to each dotting event meets the corresponding judgment condition. If the working data meets the judgment condition, the mobile phone determines that the corresponding dotting event is the cause of the fault information reported by the user.

[0080] There may be different judgment conditions for a dot event.

[0081] For example, for the fault information of lag and unsmoothness, one of the corresponding marking events is: the pre-made application is unresponsive. Then, a judgment condition corresponding to the marking event is: obtain the foreground application that has been marked as unresponsive more than three times in the past 30 days from the marking database. If there is a corresponding application, it meets the condition of unresponsive pre-made application.

[0082] Assuming that the task values ​​can be stored in the dot database, for example, correct (true) indicates normal, and error (false) indicates failure, then another judgment condition corresponding to the dot event can be: determine from the dot database whether there is an application corresponding to the value of false. If there is a corresponding application, the condition that the prefabricated application is unresponsive is met.

[0083] In the embodiment of the present application, the mobile phone can establish a scenario fault tree, and each RBI event corresponds to a scenario fault tree. The smart diagnosis engine module of the mobile phone contains multiple scenario fault trees corresponding to each fault scenario. The mobile phone determines the cause of the fault information reported by the user through the joint diagnosis of multiple scenario fault trees corresponding to each fault scenario in the smart diagnosis engine module.

[0084] See also Figure 4 , Figure 4 A schematic diagram of a fault analysis process provided by an embodiment of the present application. Figure 4 As shown, the mobile phone can collect fault information reported by users in different scenarios. For example, the first scenario can be a user satisfaction (Net Promoter Score, NPS) analysis scenario or a VOC analysis scenario. The second scenario can be a scenario where the user's intelligent customer service or intelligent voice assistant solves the problem.

[0085] The mobile phone can be provided with a large language model module, a diagnosis engine module (intelligent diagnosis engine) and a solution module. First, the mobile phone inputs the fault information reported by the user in different scenarios into the large language model module, and extracts at least one viewpoint in the fault information through the trained large language model. Figure 4 As shown, the mobile phone extracts viewpoint 1, viewpoint 2 and viewpoint 3 through the large language model, and determines the fault scenario corresponding to each viewpoint. Among them, viewpoint 1 corresponds to scenario 1, viewpoint 2 corresponds to scenario 2, and viewpoint 3 corresponds to scenario 3.

[0086] Then, the mobile phone inputs each determined scenario into the diagnosis engine module, such as Figure 4, a fault scenario (set as scenario 1) can correspond to scenario fault tree 1, scenario fault tree 2 and scenario fault tree 3. The mobile phone determines the root cause of scenario 1 described in the fault information reported by the user through the diagnosis of scenario fault tree 1, scenario fault tree 2 and scenario fault tree 3. Similarly, the mobile phone determines the root causes of scenario 2 and scenario 3 described in the fault information reported by the user by determining the scenario fault trees corresponding to scenario 2 and scenario 3 respectively, and by diagnosing the scenario fault trees corresponding to scenario 2 and the scenario fault trees corresponding to scenario 3. In this way, the mobile phone can determine the causes of all fault scenarios described in the fault information reported by the user.

[0087] The mobile phone further determines the corresponding solution based on the determined cause of the fault. The solution pushed to the user may include version information to solve the problem, how to use the phone, frequently asked questions (FAQ), setting suggestions, application updates, space cleaning and rogue application cleaning, etc.

[0088] In some embodiments, if the fault determined by the mobile phone is unsolvable by the mobile phone itself, the mobile phone can report the corresponding fault information to the cloud server, and the cloud server can record the fault information.

[0089] After the mobile phone determines the solution, it can push the solution to the user according to different scenarios. For example, if the user's intelligent customer service or intelligent voice assistant solves the problem in the scenario (the second scenario), the mobile phone collects the fault information reported by the user through the intelligent customer service or intelligent voice assistant, then the solution will also be pushed to the user through the mobile phone's intelligent customer service or intelligent voice assistant.

[0090] In the embodiment of the present application, the scenario fault tree parses the input according to four types of rules, wherein the above rules include: alarm rule, command rule, node rule, and code rule.

[0091] The parameters of the fault rule include: checkpoint, time range, threshold type, threshold, expected result, and result match. The parameters of the command rule include: database path, Structured Query Language (SQL) read statement and algorithm, expected result, and result match. The parameters of the node rule include: system or configuration file, relevant fields in the file, expected result, and result match. The parameters of the code rule include: custom algorithm, algorithm input parameter, and result return. The result includes correct (true) or wrong (false).

[0092] See also Figure 5 , Figure 5 This is an example diagram of a scenario fault tree provided in an embodiment of the present application. Figure 5 As shown in the figure, taking the phenomenon of lag and unsmoothness during the use of the mobile phone as an example, there is a corresponding diagnostic logic for the lag and unsmoothness. First, find the corresponding scenario fault tree for the lag and unsmoothness. Specifically, the lag and unsmoothness fault has at least four RBI events under the corresponding diagnostic logic, including: no response from pre-made applications, slow startup of self-developed applications, aging of storage devices, memory leaks, etc.

[0093] It should be noted that the fault rules correspond to the points, the command rules correspond to the database, the node rules correspond to the files, and the code rules correspond to the logic execution, which are pre-set in the mobile phone.

[0094] The mobile phone can configure corresponding rules for different tap events through a pre-trained large model. Specifically, the mobile phone can determine the attributes of the tap event and the mapping relationship between the attributes and the rules. Then, the mobile phone can determine the rules corresponding to the tap event based on the attributes of the tap event.

[0095] For example, if the marking event is storage device aging, then since the storage device aging can be estimated by reading the relevant file that records the life of the storage device, the storage device aging corresponds to the file and the node rule corresponding to the file.

[0096] like Figure 5 As shown in the figure, the unresponsiveness of the prefabricated application mentioned above corresponds to the dot + fault rule, the slow startup of the self-developed application corresponds to the database + command rule, the aging of the storage device corresponds to the file + node rule, and the memory leak corresponds to the logic execution + code rule.

[0097] Each dotting event corresponds to a specific judgment condition. The judgment condition can be set according to the rule corresponding to the attribute of the dotting event and the parameters corresponding to the rule. For example, Figure 5 As shown, the prefabricated application unresponsiveness corresponds to the dot + fault rule, so the corresponding judgment condition is: obtain the foreground application that has been dotted more than three times in the past 30 days from the dot database. If there is a corresponding application, it meets the condition of prefabricated application unresponsiveness.

[0098] The database + command rule corresponds to the slow startup of self-developed applications. The corresponding judgment conditions are as follows: search for the startup application from the performance fault database, and the package name is com.hihonor or com.android, and the value of (total (CNT6+CNT7+CNT8) as float) / total (CNT1+CNT2+CNT3+CNT4+CNT5+CNT6+CNT7+CNT8) is greater than 6, which means that the self-developed application startup is slow.

[0099] The corresponding file + node rule for storage device aging is as follows: read the device life_time_est_typ_a file and life_time_est_typ_b file, and the value of estTypeA or estTypeB is greater than or equal to 0x0A and less than or equal to 0x0F, or read / proc / bootdevice / pre_eol_info, and the value of pre_Eol_Info is greater than or equal to 0x02 and less than or equal to 0x0F. Among them, the life_time_est_typ_a file and the life_time_est_typ_b file can provide an estimated indicator to reflect the average degree of wear of type a memory and type b memory devices relative to the maximum expected life of the device, thereby providing an estimated indicator of device life. pre_Eol_Info represents pre-end life information. This field provides information about the state of the storage device before the expected end of its life. This information can help the system determine when to replace the device to ensure data security and reliability. This field contains various information about the device life, such as the number of writes and the number of bad blocks.

[0100] Memory leaks correspond to logic execution + code rules, so the corresponding algorithm judgment condition is: match the memory growth limit in 30 days from the dot database. Get the leakage information data that meets the preset conditions, where the preset conditions are: not kernel memory, total memory is less than 350M, and free memory ratio is less than 50%. If the data that meets the preset conditions is greater than or equal to 5, it indicates a memory leak.

[0101] Therefore, the mobile phone can determine the target marking event that meets the judgment condition through the judgment condition corresponding to the marking event associated with the fault scenario of freezing and not smoothness, thereby determining the root cause of the freezing and not smoothness of the mobile phone.

[0102] In the embodiment of the present application, the mobile phone determines whether the working data of each dot event meets the corresponding judgment conditions, determines the root cause of the fault, and can provide a corresponding solution.

[0103] The mobile phone creates corresponding fault scenario identifiers for different fault scenarios. After the mobile phone inputs the fault scenario into the diagnosis engine module, the corresponding scenario fault tree can be determined through the fault scenario identifier.

[0104] In some embodiments, the mobile phone can establish corresponding collection scene identifiers for different collection scenes. The collection scenes here refer to the first scene and the second scene mentioned above. The collection scenes may also include self-feedback, knowledge base, self-service, etc.

[0105] In the embodiment of the present application, after the mobile phone determines at least one target dotting event from the dotting events associated with the fault information, it determines a corresponding solution according to the dotting event and feeds back the solution to the user.

[0106] For example, if the root cause of the fault is a setting-related issue, then information on adjusting the settings can be pushed to the user. If the root cause of the fault is a TP fault, then suggestions and information on network point troubleshooting can be pushed to the user. In this way, the mobile phone can determine the corresponding solution based on the root cause of the fault.

[0107] See also Figure 6 , Figure 6 This is a schematic diagram of a scenario fault tree analysis provided by an embodiment of the present application. Figure 6 As shown, the faults perceived by the user may be, for example, frequent freezes when playing games, freezes in video calls, etc. For example, the mobile phone uses the frequent freezes when playing games extracted from the fault information reported by the user as the viewpoint input, and first refines the fault scenario, for example, from the aspects of settings, data services and / or Wi-Fi Internet access abnormalities, touch screen (Touch Panel, TP) abnormalities, central processing unit (Central Processing Unit, CPU) load, etc. Among them, refining the fault scenario means determining the RBI events associated with the fault scenario.

[0108] like Figure 6 As shown, the corresponding RBI events for frequent gaming jams may include: settings related, slow data service access, TP failure, CPU load, malicious keep-alive, memory leak, and abnormal Wi-Fi access. The RBI events associated with each fault scenario may correspond to at least one parameter (factor). For example, the settings related corresponding factors include low power mode, frame rate, and game acceleration. Factors for slow data service access include resource preemption conflicts, slow game server response, and network reasons. Factors for TP failures include touch screen ghost hands and touch screen wake-up failures. Factors for CPU load include high CPU load and temperature control frequency limit. Factors for malicious keep-alive include rogue and risky applications. Factors for memory leaks include application memory leaks. Factors for abnormal Wi-Fi access include frequent disconnections and slow access.

[0109] Therefore, if lag occurs during the game, the large model training can be used to conduct a joint diagnosis of settings, data services, touch screens, rogue applications, Wi-Fi Internet anomalies, etc., that is, the factors corresponding to the above-mentioned dot events are detected, and the final joint diagnosis results are given. The diagnosis of all relevant areas corresponding to the fault can be realized, and the root cause of the lag during the game can be quickly found, and a suitable solution can be given based on the root cause.

[0110] For example, the mobile phone will extract the video call freeze of application 1 from the fault information reported by the user as the opinion input, and first refine the fault scenario, such as from the aspects of application 1 space, data service and / or Wi-Fi Internet access abnormality, TP abnormality, CPU load, memory leakage, service freeze, camera slowness and rogue application. Figure 6 As shown, the marking events corresponding to the video call freeze of Application 1 may include: slow data service access, malicious keep-alive, memory leakage, abnormal Wi-Fi access, application diagnosis, slow camera, and service stuck. Among them, the factors of slow data service access include resource preemption conflict, slow response of game server, and network reasons. The factors of malicious keep-alive include rogue and risky applications. The factors of memory leakage include application memory leakage. The factors of abnormal Wi-Fi access include frequent disconnection and slow access. The factors of application diagnosis include oversized application database and version detection. The factors of slow camera include abnormal underlying algorithm. The factors of service stuck include abnormal service stuck.

[0111] Therefore, if the video call of Application 1 is stuck, the large model training can be used to jointly diagnose the space, data service and / or Wi-Fi Internet access anomalies, TP anomalies, CPU load, memory leaks, service freezes, camera slowness and rogue applications of Application 1. That is, the factors corresponding to the above aspects are detected, and the final joint diagnosis result is given to quickly find the root cause of the video call jam of Application 1, and provide a suitable solution based on the root cause.

[0112] For each factor corresponding to a dot event, each factor may be set with a corresponding preset judgment condition, and the mobile phone may generate a judgment condition corresponding to the dot event according to the preset judgment condition corresponding to each factor and the preset judgment rule corresponding to the attribute of the dot event.

[0113] For example, factors of abnormal Wi-Fi Internet access include frequent disconnection and slow Internet access. Then, for frequent disconnection, the corresponding preset judgment condition can be set as follows: if the number of times application 1 is disconnected from Wi-Fi exceeds a threshold within a preset time period, the condition of frequent disconnection is met. For slow Internet access, the corresponding preset judgment condition can be set as follows: if the Wi-Fi rate of application 1 is found to be lower than a certain threshold, the condition of slow Internet access is met. Therefore, the judgment condition of abnormal Wi-Fi Internet access is generated by the preset judgment conditions of the above two factors and the preset judgment rules corresponding to the attributes.

[0114] It is understandable that through large model training, the electronic device can determine the relevant event for each fault scenario described by the user. Therefore, this solution can dynamically describe the faults perceived by the user through the scenario-based fault model, and quickly and accurately locate the user's problem.

[0115] like Figure 6 As shown, this solution can set up a variety of repair plans (solutions), and one or more corresponding repair plans can be set for different RBI events. Specifically, setting up relevant corresponding repair plans includes adjusting settings; the repair plan corresponding to slow data service access includes FAQ guidance; the repair plan corresponding to TP failure includes suggestions to go to the outlet for investigation; the repair plan corresponding to CPU load includes background cleaning and application startup management; the repair plan corresponding to malicious keep-alive includes virus detection and application uninstallation; the repair plan corresponding to memory leaks includes version updates and restarting applications. The repair plan corresponding to Wi-Fi Internet access anomalies includes FAQ guidance. The repair plan corresponding to application diagnosis includes cleaning acceleration and application cleaning. The repair plan corresponding to the slow camera includes system update. The repair plan corresponding to the service freeze includes restarting the system and system update.

[0116] Therefore, in the embodiment of the present application, the repair capability can be atomized and different repair plans can be set for different dot events.

[0117] In some embodiments, if the determined target RBI event corresponds to multiple factors, different repair plans can be set for the factors. For example, if the fault scenario of frequent freezing when playing games is analyzed by the electronic device for each RBI event corresponding to the fault scenario, it is finally determined that the target RBI event is the CPU load. Then the two factors corresponding to the CPU load include high CPU load and temperature control frequency limit. Then, for the factor of high CPU load, the set repair plan can include cleaning the background.

[0118] A fault analysis method provided in an embodiment of the present application can be applied to electronic devices, and can determine the dotting event corresponding to each fault information by analyzing the fault information reported by the user. Then, the electronic device can determine the dotting event that causes the fault based on the corresponding judgment conditions for the working data corresponding to each dotting event. As a result, the electronic device can accurately analyze the root cause of the fault described in the fault information reported by the user, further improving the efficiency of the electronic device in analyzing faults. In addition, the electronic device can determine a solution to the fault information reported by the user based on the root cause of the fault.

[0119] A fault analysis method provided in the embodiment of the present application can also be applied to a cloud server. Figure 7 , Figure 7 Another flow chart of fault reporting and diagnosis provided for the implementation of this application. Figure 7 As shown, the mobile phone is provided with modules such as GPS, restart, performance, touch screen, and camera as modules that may fail in the mobile phone. The fault collection engine of the mobile phone can collect fault data related to the above modules. Specifically, after receiving the fault information reported by the user, the mobile phone can collect the working data of the dot event associated with the fault information through the fault collection engine.

[0120] Among them, the mobile phone can report the collected fault information to the cloud server for processing. The cloud server inputs the working data of the dot event associated with the received fault information into the intelligent diagnosis engine set in the cloud server, and determines the root cause of the fault described in the fault information through the intelligent diagnosis engine, and determines the corresponding repair plan (solution) of the fault.

[0121] Among them, the cloud server can also receive fault information reported by users through hotlines or outlets.

[0122] After determining the repair plan, the cloud server can send the repair plan to the mobile phone, for example, through the intelligent customer service and intelligent voice assistant set in the mobile phone to interact with the user. Alternatively, the cloud server feedbacks the repair plan to the user through a hotline or outlet.

[0123] The cloud server is also equipped with a fault big data warning module. If the fault data corresponding to the fault information received by the cloud server exceeds the preset threshold value within a preset time period, a fault warning can be issued for the fault information through the fault big data warning module, for example, a warning message for the fault information can be sent via a mobile phone.

[0124] The cloud server is also equipped with a scenario fault tree management module, which can manage various scenario fault trees, such as adding or deleting scenario fault trees, and adding dot events to a single scenario fault tree.

[0125] In some embodiments, the cloud server can send the analyzed root cause of the fault (target RBI event) to the mobile phone, and the mobile phone determines a solution for the fault information reported by the user based on the root cause of the fault.

[0126] A fault analysis method provided in an embodiment of the present application can be applied to a cloud server, and the specific steps may include steps S201 to S203 as follows:

[0127] Step S201: The cloud server receives fault information about an electronic device reported by a user.

[0128] In the embodiment of the present application, taking the electronic device as a mobile phone as an example, the fault information for the mobile phone refers to the faults discovered by the user during the use of the mobile phone, which may include fast power consumption, heating, lag in use, poor signal, abnormal GPS navigation, lag in playing games, lag in video calls, etc.

[0129] The cloud server may receive the above fault information in different ways. The cloud server may receive the fault information reported by the user through a preset collection module of the mobile phone. The preset collection module may include intelligent customer service, intelligent voice assistant, etc.

[0130] The cloud server can also report fault information through various means such as receiving text messages sent by users, hotline tickets, online messages, and user experience improvement plans in mobile phones.

[0131] After receiving the fault information for the mobile phone, the cloud server can further analyze the cause of the fault information.

[0132] In an embodiment of the present application, a large language model can be constructed in the cloud server. By inputting the received fault information into the large language model, at least one viewpoint can be extracted from the fault information, and each viewpoint can correspond to a fault scenario.

[0133] For example, the fault information received by the cloud server is: GPS positioning is slow and inaccurate. Then, the cloud server can extract two viewpoints from the above fault information through the large language model: Viewpoint 1, GPS positioning is slow; Viewpoint 2, GPS positioning is inaccurate. Therefore, the cloud server can obtain the two fault scenarios of slow GPS positioning and inaccurate GPS positioning through the two extracted viewpoints.

[0134] Step S202: The cloud server obtains at least one associated marking event based on the fault information.

[0135] In the embodiment of the present application, the cloud server obtains at least one dot event associated with the fault information from the mobile phone based on the fault information. Then, before the cloud server obtains at least one dot event associated with the fault information, the mobile phone determines at least one dot event associated with the fault information based on the fault information.

[0136] The specific steps of the mobile phone determining at least one associated dotting event based on the fault information can refer to the specific steps of “step S102, the mobile phone determines at least one associated dotting event based on the fault information”, which will not be repeated here.

[0137] After the mobile phone determines at least one associated dotting event based on the fault information, the cloud server obtains the dotting event associated with the received fault information from the mobile phone, and can further determine the cause of the fault information through the judgment conditions corresponding to each dotting event.

[0138] S203: The cloud server screens out a target dotting event from at least one dotting event as a cause of the fault information based on the work data corresponding to each dotting event.

[0139] In the embodiment of the present application, the specific steps of the cloud server screening out the target dotting event in at least one dotting event based on the working data corresponding to each dotting event can refer to the specific steps of "step S103, the mobile phone screens out the target dotting event in at least one dotting event based on the working data corresponding to each dotting event as the cause of the fault information", which will not be repeated here.

[0140] After determining the cause of the fault information, the cloud server can further determine the corresponding solution. Among them, the solutions determined by the cloud server can be divided into two types: one is the automatic delimitation information given to developers, and the other is a comprehensive solution given to public opinion processing personnel, service personnel, users, etc.

[0141] After determining the solution, the cloud server can push the solution to the user according to different scenarios. For example, if the cloud server receives the fault information reported by the user through the smart customer service or smart voice assistant on the mobile phone, the cloud server will also push the solution to the user through the smart customer service or smart voice assistant on the mobile phone. If the cloud server receives the fault information reported by the user through a hotline or outlet, the cloud server can inform the user of the solution through the hotline or outlet.

[0142] In some embodiments, the present solution can be applied to big data warning. If a certain fault scenario occurs a large number of times within a preset time period, for example, reaching a certain preset threshold value, then the cloud server or outlet or hotline can issue a warning for the fault scenario.

[0143] For the big data warning of the cloud server, the cloud server can record the number of occurrences of each fault scenario within a preset time. For example, for a single product 1, if the scenario where GPS cannot locate exceeds 5,000 times within a month, it can be considered that the fault scenario (GPS cannot locate) has reached the preset threshold value (5,000) within the preset time (one month), and the cloud server can issue early warnings to each user using product 1 for the fault scenario where GPS cannot locate. The preset time can be customized, such as one week, one month, etc.

[0144] The preset threshold value may also be set according to different fault scenarios. For example, for a single product 1, the fault scenario is inaccurate GPS positioning, the preset duration is one month, and the preset threshold value may be 10,000 times.

[0145] The preset threshold value may also be set according to different products. For example, for a certain product 2, the fault scenario is that GPS cannot locate, the preset duration is one month, and the preset threshold value may be 50,000 times.

[0146] For big data warnings of outlets or hotlines, users can go to outlets or use hotlines to detect fault scenarios. Then, outlets or hotlines can record the number of times users detect fault scenarios within a preset time period. For product 1, if the number of times a user detects GPS exceeds 500 times within a month, it can be considered that the fault data of the fault scenario (GPS anomaly) has reached the preset threshold value (500) within the preset time period (one month). The hotline or outlet can issue early warnings to various users of product 1 for various GPS scenarios. Among them, the above preset time period can also be customized, which can be, for example, one month, one quarter, etc.

[0147] Among them, the preset threshold value can also be set according to different fault scenarios. For example, for product 1, the fault scenario is lag in playing games, the preset duration is one month, and the preset threshold value can be 600 times.

[0148] The preset threshold value may also be set according to different products. For example, for product 2, the fault scenario is GPS abnormality, the preset duration is one month, and the preset threshold value may be 1000 times.

[0149] A fault analysis method provided in an embodiment of the present application can be applied to a cloud server, and can obtain the dotting event corresponding to each fault information by receiving the fault information reported by the user. Then the cloud server can determine the dotting event that causes the fault based on the corresponding judgment conditions for the work data corresponding to each dotting event. As a result, the cloud server can accurately analyze the root cause of the fault described in the fault information reported by the user for the mobile phone. By determining the dotting event corresponding to each fault information in advance, the cloud server can analyze all possible dotting events that cause the fault information to occur, and the analysis of the cause of the fault information is more comprehensive, further improving the efficiency of fault analysis.

[0150] The execution subject of the fault analysis method provided in the embodiment of the present application may be a fault analysis device, and the execution device may be Figure 8 The electronic device shown. At the same time, the execution device can also be a central processing unit (CPU) of the electronic device, or a control module for fault analysis in the electronic device. In the embodiment of the present application, the fault analysis method provided by the embodiment of the present application is described by taking the execution of the fault analysis method by the electronic device as an example.

[0151] The implementation of the embodiments of the present application will be described in detail below with reference to the accompanying drawings. Figure 8 A structural diagram of an electronic device 100 is shown.

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

[0153] It is to be understood that the structure illustrated in the embodiment of the present application does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown in the figure, or combine some components, or split some components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0154] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0155] The processor can generate operation control signals based on instruction opcodes and timing signals to complete the control of instruction fetching and execution.

[0156] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 may be a cache memory. The memory may store instructions or data that have been used or are frequently used by the processor 110. If the processor 110 needs to use the instruction or data, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0157] In some embodiments, the processor 110 may include one or more interfaces. The interface may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc. The processor 110 may be connected to a touch sensor, an audio module, a wireless communication module, a display, a camera, and other modules through at least one of the above interfaces.

[0158] It is understandable that the interface connection relationship between the modules illustrated in the embodiment of the present application is only a schematic illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

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

[0160] 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 a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of antennas. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0161] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0162] The modem processor may include a modulator and a demodulator. Among them, the modulator is used to modulate the low-frequency baseband signal to be sent into a medium-high frequency signal. The demodulator is used to demodulate 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 the low-frequency baseband signal is processed by the baseband processor, it is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker 170A, a receiver 170B, etc.), or displays an image or video through a display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0163] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), bluetooth low energy (BLE), ultra wide band (UWB), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. 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 the antenna 2, modulates the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, modulate the frequency, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0164] In some embodiments, the antenna 1 of the electronic device 100 is coupled to the mobile communication module 150, and the antenna 2 is coupled to the wireless communication module 160, so that the electronic device 100 can communicate with the network and other electronic devices through 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 technology, etc. The GNSS may include a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), a quasi-zenith satellite system (QZSS) and / or a satellite based augmentation system (SBAS).

[0165] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are stored in the external memory card. Or files such as music and videos are transferred from the electronic device to the external memory card.

[0166] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional methods or data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

[0167] Some other embodiments of the present application provide an electronic device. The electronic device may include: a communication module, a memory, and one or more processors; the communication module, the memory, and the processor are coupled. The memory is also used to store computer program code, and the computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device can perform the various functions or steps performed by the electronic device in the above method embodiment. The structure of the electronic device can refer to Figure 8 The structure of the electronic device 100 is shown.

[0168] like Fig. 9 As shown, it is a diagram of the software architecture inside the electronic device. The layered architecture divides the software into several layers, each layer has a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the internal architecture of the electronic device can be divided into five layers, from top to bottom, namely, the application layer, the application framework layer, the Android runtime (ART) and the native C / C++ library, the hardware abstract layer (HAL) and the kernel layer.

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

[0170] like Fig. 9 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, SMS, etc. Among them, navigation may be GPS.

[0171] The application framework layer provides an application programming interface (API) and a programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

[0172] like Fig. 9 As shown, the application framework layer may include a window manager, a content provider, a view system, a resource manager, a notification manager, an activity manager, an input manager, and the like.

[0173] The window manager provides window management services (WMS). WMS can be used for window management, window animation management, surface management, and as a transfer station for the input system.

[0174] Content providers are used to store and retrieve data and make it accessible to applications. This data can include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc.

[0175] The view system includes visual controls, such as controls for displaying text, controls for displaying images, etc. The view system can be used to build applications. A display interface can be composed of one or more views. For example, a display interface including a text notification icon can include a view for displaying text and a view for displaying images.

[0176] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0177] The notification manager enables applications to display notification information in the status bar, which can be used to convey notification-type messages and disappear automatically after a short stay without user interaction.

[0178] The activity manager can provide activity management services (AMS), which can be used to start, switch, and schedule system components (such as activities, services, content providers, and broadcast receivers) as well as manage and schedule application processes.

[0179] The input manager can provide input management services (IMS), which can be used to manage system input, such as touch screen input, key input, sensor input, etc. IMS takes events from input device nodes and distributes them to appropriate windows through interaction with WMS.

[0180] The Android runtime includes the core library and the Android runtime. The Android runtime is responsible for converting source code into machine code. The Android runtime mainly uses the ahead of time (AOT) compilation technology and the just in time (JIT) compilation technology.

[0181] The core library is mainly used to provide basic Java class library functions, such as basic data structures, mathematics, IO, tools, databases, networks, etc. The core library provides an API for users to develop Android applications.

[0182] The native C / C++ library can include multiple functional modules, such as surface manager, media framework, libc, OpenGL ES, SQLite, Webkit, etc.

[0183] The hardware abstraction layer runs in user space, encapsulates the kernel layer driver, and provides a calling interface to the upper layer. The hardware abstraction layer includes at least a display module, a camera module, an audio module, and a Bluetooth module.

[0184] The kernel layer is the layer between hardware and software. The kernel layer contains at least display driver, camera driver, audio driver, and Bluetooth driver.

[0185] The fault analysis methods in the aforementioned embodiments can all be implemented in the electronic device 100 having the aforementioned hardware structure and software structure.

[0186] The present application also provides a chip system, such as Fig.10 As shown, the chip system 900 includes at least one processor 901 and at least one interface circuit 902. The processor 901 and the interface circuit 902 can be interconnected via lines. For example, the interface circuit 902 can be used to receive signals from other devices (such as a memory of an electronic device). For another example, the interface circuit 902 can be used to send signals to other devices (such as the processor 901). Exemplarily, the interface circuit 902 can read instructions stored in the memory and send the instructions to the processor 901. When the instructions are executed by the processor 901, the electronic device can execute the various steps in the above embodiments. Of course, the chip system may also include other discrete devices, which are not specifically limited in the embodiments of the present application.

[0187] An embodiment of the present application also provides a computer storage medium, which includes computer instructions. When the computer instructions are executed on the above-mentioned electronic device, the electronic device executes each function or step executed by the mobile phone in the above-mentioned method embodiment.

[0188] The embodiment of the present application also provides a computer program product. When the computer program product is run on a computer, the computer is enabled to execute each function or step executed by the mobile phone in the above method embodiment.

[0189] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0190] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0191] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0192] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0193] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0194] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A fault analysis method, characterized in that: Applied to electronic equipment, the method comprises: The electronic device collects fault information about the electronic device reported by a user; The electronic device determines at least one associated dotting event based on the fault information; wherein each dotting event corresponds to working data of the event during the operation of the electronic device; The electronic device screens out a target dotting event from the at least one dotting event as a cause of the fault information based on the working data corresponding to each of the dotting events.

2. The method according to claim 1, characterized in that The electronic device determines at least one associated dotting event based on the fault information, including: The electronic device extracts at least one viewpoint from the fault information; wherein one viewpoint corresponds to one fault scenario; The electronic device determines at least one dot event associated with the fault scenario corresponding to each of the viewpoints.

3. The method according to claim 1 or 2, characterized in that: The step of screening out a target dotting event from the at least one dotting event comprises: The electronic device determines whether the working data of each dotting event satisfies a corresponding judgment condition when acquiring the working data corresponding to each dotting event; wherein different dotting events correspond to different judgment conditions; When the working data of the dotting event meets the corresponding judgment condition, the dotting event is used as the target dotting event.

4. The method according to claim 3, characterized in that Before the electronic device screens out a target dotting event from the at least one dotting event based on the working data corresponding to each dotting event, the method further includes: The electronic device determines the attributes of the dot event and the mapping relationship between the attributes and the preset determination rules; wherein the preset determination rules at least include fault rules, command rules, node rules and code rules; The electronic device determines a judgment condition corresponding to the dotting event based on a preset judgment rule corresponding to an attribute of the dotting event.

5. The method according to claim 4, characterized in that The electronic device determines a judgment condition corresponding to the dot event based on a preset judgment rule corresponding to an attribute of the dot event, including: The electronic device determines at least one parameter corresponding to each of the dotting events; The electronic device generates a judgment condition corresponding to the dotting event based on the preset judgment condition corresponding to the parameter and the preset judgment rule corresponding to the attribute of the dotting event.

6. The method according to any one of claims 1 to 5, characterized in that The electronic device collects fault information about the electronic device reported by a user, including: The electronic device collects the fault information reported by the user through a preset collection module of the electronic device; wherein the fault information includes a voice message or a text message.

7. The method according to any one of claims 1 to 6, characterized in that After the electronic device screens out a target dotting event from the at least one dotting event as the cause of the fault information based on the working data corresponding to each of the dotting events, the electronic device further includes: The electronic device determines a corresponding solution based on the target dot event; The electronic device pushes the solution to the user.

8. The method according to claim 7, characterized in that The electronic device determines a corresponding solution based on the target dot event, including: The electronic device determines at least one target parameter corresponding to the target dot event; The electronic device determines a solution corresponding to each of the target parameters.

9. A fault analysis method, characterized in that: Applied to electronic equipment, the method comprises: The electronic device collects fault information about the electronic device reported by a user; The electronic device sends the fault information to the cloud server, so that the cloud server obtains at least one associated dotting event based on the fault information, and based on the working data corresponding to each of the dotting events, screens out a target dotting event in the at least one dotting event as the cause of the fault information; wherein each of the dotting events corresponds to the working data of the event during the operation of the electronic device.

10. The method according to claim 9, characterized in that The method further comprises: The electronic device receives a solution sent by the cloud server; wherein the solution is determined by the cloud server based on the target dot event; The electronic device pushes the solution to the user.

11. A fault analysis method, characterized in that: Applied to a cloud server, the method comprises: The cloud server receives fault information about the electronic device reported by the user; The cloud server acquires at least one associated dotting event based on the fault information; wherein each dotting event corresponds to working data of the event during the operation of the electronic device; The cloud server screens out a target dotting event from the at least one dotting event as a cause of the fault information based on the working data corresponding to each of the dotting events.

12. The method according to claim 11, characterized in that The cloud server receives the fault information about the electronic device reported by the user, including: The cloud server receives the fault information reported by the user through the preset collection module of the electronic device; wherein the fault information includes a voice message or a text message; and / or, The cloud server receives the fault information reported by the user via a hotline; and / or, The cloud server receives the fault information reported by the user through the network point.

13. The method according to claim 11 or 12, characterized in that: The method further comprises: The cloud server determines a corresponding solution based on the target dot event and pushes the solution to the user.

14. The method according to any one of claims 11 to 13, characterized in that The method further comprises: If the number of times the cloud server receives the fault information within a preset time period exceeds a preset threshold, the cloud server sends a warning message for the fault information; and / or, If the number of times the cloud server collects the fault information reported by users through a hotline or outlets within a preset time period exceeds the preset threshold, the cloud server sends warning information for the fault information through the hotline or outlets.

15. An electronic device, characterized in that: The electronic device comprises: a communication module, a memory and one or more processors; the communication module, the memory and the processor are coupled; the memory is used to store computer program code, and the computer program code comprises computer instructions, and when the computer instructions are executed by the electronic device, the electronic device executes the method as described in any one of claims 1 to 14.

16. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed in an electronic device, the electronic device executes the method according to any one of claims 1 to 14.

17. A computer program product, characterized in that The computer program product includes instructions, and when the instructions are executed in an electronic device, the electronic device executes the method according to any one of claims 1 to 14.

Citation Information

Patent Citations

  • Information processing method and electronic equipment

    CN106844173A

  • Failure analyzing method and related device

    WO2019061364A1