Equipment fault troubleshooting method and device, equipment and storage medium

Abstract

The invention relates to the field of troubleshooting, and provides an equipment troubleshooting method and device, equipment and a storage medium. The method comprises the following steps: cyclically executing the following operations until all functional modules associated with target equipment are processed: reading at least one running state parameter of one functional module from a self-inspection result of the functional module which is not judged to have a fault currently, and performing self-inspection on the functional module on the basis of the at least one running state parameter until all the functional modules associated with the target equipment are processed; according to the method, the state of the functional module is evaluated, the corresponding state evaluation result is obtained, and when it is determined that one functional module has a fault based on the state evaluation result, other functional modules influenced by the functional module are rapidly positioned, so that the problem that potential faults of equipment cannot be eliminated due to the fact that other functional modules influenced by the fault module cannot be found out is solved; the fault positioning efficiency is improved, and the reliability and operation efficiency of equipment are guaranteed.

Description

Background Art

[0002] Internet of Things (IoT) devices usually contain multiple functional modules (such as camera module, recognition module, cloud recognition, device signature, etc.), and provide corresponding services to the target object through the collaborative work of multiple functional modules.

[0003] Under related technologies, when an IoT device fails, manual troubleshooting is usually used to detect various functional modules within the IoT device and identify the faulty module that caused the device failure.

[0004] However, since IoT devices provide services in collaboration with multiple functional modules, a faulty module may cause failures in other functional modules that jointly provide services, or the cause of the failure of the faulty module may be caused by other functional modules that jointly provide services.

[0005] Therefore, when a faulty module is detected, the above method cannot detect other functional modules affected by the faulty module, thereby failing to eliminate potential faults in the IoT device.

[0006] In view of this, the present application proposes a new device fault troubleshooting method. Summary of the invention

[0007] The embodiments of the present application provide a device fault troubleshooting method, apparatus, device and storage medium to solve the problem of being unable to troubleshoot potential faults of IOT devices.

[0008] In a first aspect, an embodiment of the present application provides a device fault troubleshooting method, comprising:

[0009] In response to a self-test operation triggered for a target device, a self-test request is sent to each functional module associated with the target device, and a self-test result returned by each functional module is obtained;

[0010] The following operations are performed in a loop until all functional modules are processed: from a self-test result of a functional module that is not currently determined to have a fault, at least one operating status parameter of the functional module is read, and based on the at least one operating status parameter, a status evaluation is performed on the functional module to obtain a corresponding status evaluation result, and when the status evaluation result represents an abnormal state, the functional module is used as a target fault module, and at least one other functional module that has a dependency relationship with the functional module is used as a potential fault module, wherein the dependency relationship is constructed based on a module call record of the functional module.

[0011] In a second aspect, the embodiment of the present application further provides a device for troubleshooting equipment failures, including:

[0012] A self-test unit, configured to, in response to a self-test operation triggered on a target device, send a self-test request to each functional module associated with the target device, and obtain a self-test result returned by each functional module;

[0013] A troubleshooting unit is used to perform the following operations in a loop until all functional modules are processed: from a self-test result of a functional module that is not currently determined to have a fault, read at least one operating status parameter of the functional module, and based on the at least one operating status parameter, perform a status evaluation on the functional module to obtain a corresponding status evaluation result; when the status evaluation result represents an abnormal state, use the functional module as a target fault module, and use at least one other functional module that has a dependency relationship with the functional module as a potential fault module, wherein the dependency relationship is constructed based on a module call record of the functional module.

[0014] Optionally, after the target fault module and at least one potential fault module are obtained through troubleshooting, the device fault troubleshooting apparatus further includes a fault repair unit, and the fault repair unit is used to:

[0015] Based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for the target fault module, triggering execution of a corresponding repair operation for the target fault module;

[0016] For the at least one potential fault module, the following operations are performed respectively: based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for a potential fault module, trigger the execution of a corresponding repair operation for the potential fault module.

[0017] Optionally, when a corresponding repair operation for the target fault module is triggered, the device troubleshooting apparatus further includes a notification unit, wherein the notification unit is configured to:

[0018] When it is detected that a corresponding repair operation for the target fault module is triggered, a notification request is sent to the target fault module, so that the target fault module performs at least one of a cleanup operation and a save operation on its own working data and running state;

[0019] or,

[0020] When it is detected that a corresponding repair operation for the target faulty module is triggered, the repair operation for the target faulty module is intercepted, and when it is detected that the target faulty module completes the corresponding module operation, a notification is given to continue to execute the repair operation for the target faulty module.

[0021] In a third aspect, an embodiment of the present application further provides a computer device, comprising a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor executes the steps of any one of the above-mentioned device fault troubleshooting methods.

[0022] In a fourth aspect, an embodiment of the present application further provides a computer-readable storage medium, which includes a program code. When the program product is run on a computer device, the program code is used to enable the computer device to execute the steps of any one of the above-mentioned device troubleshooting methods.

[0023] In a fifth aspect, an embodiment of the present application further provides a computer program product, including computer instructions, which are executed by a processor to perform the steps of any one of the above-mentioned device fault troubleshooting methods.

[0024] The beneficial effects of this application are as follows:

[0025] The embodiments of the present application provide a device fault troubleshooting method, apparatus, equipment and storage medium, which deploy the self-check operation in various functional modules associated with the target device in a distributed manner, and each functional module performs a self-check on the operating status of its own module and returns its own self-check result. Compared with centralized self-check processing, the distributed deployment method can provide higher computing performance and faster processing speed; then, based on the self-check result of a functional module and the judgment rule for the functional module, the overall operating status of the functional module is automatically evaluated. Compared with the manual troubleshooting method led by operation and maintenance personnel, the module troubleshooting time is shortened and the fault handling cost is further reduced; when a functional module is determined to be a target fault module with a fault, the present application also At least one other functional module that has a dependency relationship with the functional module will be identified as a potential fault module, which can not only quickly locate other functional modules affected by it and improve the efficiency of fault location, but also help to troubleshoot potential fault problems in the target device, solve the existing fault problems and possible fault problems in the device at one time, and ensure the reliability and operating efficiency of the equipment; moreover, for the functional modules that have been determined to be potential fault modules, this application will not repeat the inspection, which saves some self-inspection time and reduces the fault handling cost to a certain extent. Especially when there are many functional modules associated with the target device, this method can be used for self-inspection and self-healing, which can further shorten the fault recovery time and reduce equipment downtime.

[0026] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures specifically pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0028] Figure 1 A schematic diagram of the structure of an IoT device provided in an embodiment of the present application;

[0029] Figure 2A A schematic diagram of the structure of a device fault troubleshooting apparatus provided in an embodiment of the present application;

[0030] Figure 2B This is an optional schematic diagram of an application scenario in an embodiment of the present application;

[0031] Figure 3A A schematic diagram of a process for troubleshooting a target device provided in an embodiment of the present application;

[0032] Figure 3B A logical schematic diagram for troubleshooting a target device provided in an embodiment of the present application;

[0033] Figure 3C A schematic diagram of a dependency tree provided for an embodiment of the present application;

[0034] Figure 3D A schematic diagram of an interface for displaying a troubleshooting report in a self-check interface provided in an embodiment of the present application;

[0035] Figure 3E A schematic diagram of an interface for displaying a fault handling report in a self-check interface provided in an embodiment of the present application;

[0036] Figure 4 This is a flow chart of a distributed self-checking and self-healing solution provided by the present embodiment to perform self-checking and self-healing on one of the functional modules of the target device;

[0037] Figure 5A An overall simplified flowchart for troubleshooting a payment device provided in an embodiment of the present application;

[0038] Figure 5B An overall detailed flow chart of troubleshooting a payment device provided in an embodiment of the present application;

[0039] Figure 5C A schematic diagram of a dependency tree for a face-scanning payment service for a payment device constructed for an embodiment of the present application;

[0040] Figure 5D A schematic diagram of an interface for displaying a troubleshooting report in a self-check interface provided in an embodiment of the present application;

[0041] Figure 5E A schematic diagram of an interface for displaying a fault handling report in a self-check interface provided in an embodiment of the present application;

[0042] Figure 6 A schematic diagram of the structure of a device fault troubleshooting apparatus provided in an embodiment of the present application;

[0043] Figure 7 A schematic diagram of a hardware structure of a computer device to which an embodiment of the present application is applied;

[0044] Figure 8 A schematic diagram of the hardware composition structure of another computer device to which the embodiment of the present application is applied. DETAILED DESCRIPTION

[0045] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the technical solution of the present application, rather than all of the embodiments. Based on the embodiments recorded in the application documents, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the technical solution of the present application.

[0046] Some of the terms used in the embodiments of the present application are explained below to facilitate understanding by those skilled in the art.

[0047] 1. Cloud technology: It is a general term for network technology, information technology, integration technology, management platform technology, application technology, etc. that apply the cloud computing business model. It is a hosting technology that unifies hardware, software, network and other resources within a wide area network or local area network to achieve data computing, storage, processing and sharing. The resource pool built based on cloud technology can be flexibly and conveniently accessed on demand.

[0048] With the rapid development and application of the Internet industry, in the future, each item may have its own identification mark, which needs to be transmitted to the backend system for logical processing, and data of different levels will be processed separately. All kinds of industry data need a strong system backing as technical support. Cloud computing is one of the important supports of cloud technology, which mainly solves the problem that the backend services in the network system based on cloud technology need a lot of computing and storage resources. Among them, the cloud technology network system includes but is not limited to: video websites, picture websites, and more portal websites.

[0049] 2. Cloud computing:

[0050] Cloud computing is the product of the integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing. With the development of the Internet, real-time data streams, and the diversification of connected devices, as well as the demand for search services, social networks, mobile commerce, and open collaboration, cloud computing has developed rapidly. Different from the previous parallel distributed computing, the birth of cloud computing has promoted a revolutionary change in the entire Internet model and enterprise management model from the perspective of concept.

[0051] According to the definition scope, cloud computing includes narrow cloud computing and broad cloud computing. Among them, narrow cloud computing refers to the delivery and use model of information technology (IT) infrastructure, which is to obtain the required resources through the network in an on-demand and easily scalable manner; while broad cloud computing refers to the delivery and use model of services, which is to obtain the required services through the network in an on-demand and easily scalable manner. Such services can be IT and software, Internet-related, or other services.

[0052] 3. IoT:

[0053] As the name suggests, "IoT is the Internet of Things". This has two meanings: first, the core and foundation of IoT is still the Internet, and it is an extended and expanded network based on the Internet; second, its user end extends and expands to any object to exchange information and communicate.

[0054] Therefore, the definition of IoT is a network that connects any object to the Internet through information sensing devices such as radio frequency identification, infrared sensors, global positioning systems, laser scanners, etc., in accordance with agreed protocols, to exchange and communicate information, so as to realize the intelligent identification, positioning, detection, management and other functions of objects.

[0055] 4. IoT devices: Devices based on IoT technology are called IoT devices. Figure 1 As shown, IoT devices include input devices for detecting user operations and changes in the device's surrounding environment, output devices that prompt certain information or directly act on the environment, and microcontrollers that serve as the "brain of the device" and are used to control the machine.

[0056] The following is a brief introduction to the design concept of the embodiment of the present application:

[0057] IoT devices usually contain multiple functional modules (such as camera module, recognition module, cloud recognition, device signature, etc.), and provide corresponding services to the target objects through the collaborative work of multiple functional modules.

[0058] Under related technologies, when an IoT device fails, manual troubleshooting is usually used to detect various functional modules within the IoT device and identify the faulty module that caused the device failure.

[0059] However, since IoT devices provide services in collaboration with multiple functional modules, a faulty module may cause failures in other functional modules that jointly provide services, or the cause of the failure of the faulty module may be caused by other functional modules that jointly provide services.

[0060] Therefore, when a faulty module is detected, the above method cannot detect other functional modules affected by the faulty module, thereby failing to eliminate potential faults in the IoT device.

[0061] In view of this, the embodiment of the present application provides a device fault troubleshooting method, apparatus, equipment and storage medium. The method includes: in response to a self-test operation triggered for a target device, sending a self-test request to each functional module associated with the target device, and obtaining the self-test results returned by each functional module; looping the following operations until all functional modules are processed: from the self-test result of a functional module that is not currently determined to have a fault, reading at least one operating status parameter of a functional module, and based on at least one operating status parameter, performing a status evaluation on the functional module to obtain a corresponding status evaluation result, when the status evaluation result represents an abnormal state, the functional module is used as a target fault module, and at least one other functional module that has a dependency relationship with the functional module is used as a potential fault module, and the dependency relationship is constructed based on the module call record of the functional module.

[0062] This application automatically evaluates the overall operating status of a functional module based on the self-test results of a functional module and the judgment rules for the functional module. Compared with the manual troubleshooting method led by operation and maintenance personnel, it shortens the module troubleshooting time and further reduces the troubleshooting cost. It is also conducive to quickly implementing repair operations for functional modules with faulty problems, shortening the fault recovery time and reducing equipment downtime.

[0063] When a functional module is determined to be a target fault module with a fault, the present application will also identify at least one other functional module that has a dependency relationship with the functional module as a potential fault module. This can not only quickly locate other functional modules affected by it and improve fault location efficiency, but also help to troubleshoot potential fault problems in the target device, solve existing fault problems and potential fault problems in the device at one time, and ensure the reliability and operating efficiency of the equipment.

[0064] Moreover, for functional modules that have been determined to be potential fault modules, this application will not repeat the inspection, which saves some self-inspection time and reduces the fault handling cost to a certain extent. Especially when there are many functional modules associated with the target device, this method can be used for self-inspection and self-healing, which can further shorten the fault recovery time and reduce equipment downtime.

[0065] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application may be combined with each other if there is no conflict.

[0066] The device fault detection device is used to detect whether there are faults in various functional modules associated with IoT devices. Figure 2A As shown, the equipment fault troubleshooting device includes: a self-check module, a self-check framework, a self-healing framework, a notification module and a self-check interface.

[0067] The self-check module is registered when a functional module is initialized, and is used to collect at least one operating status parameter of the functional module and send at least one operating status parameter of the functional module to the self-check framework, so that the self-check framework can evaluate the status of the functional module based on the at least one operating status parameter and obtain the corresponding status evaluation result. In order to improve the scalability of the self-check module, the self-check module can also be flexibly expanded according to the needs of actual business scenarios.

[0068] The self-checking framework is responsible for the execution of the self-checking function, including the knowledge layer and the reasoning layer. Figure 2B As shown in the figure, the knowledge layer specifically includes: dependency set, judgment rules, repair strategy and real-time operation status of the device. Among them, the dependency set of a functional module presents at least one other functional module that has a dependency relationship with the functional module, the judgment rule is used to troubleshoot the functional module with faults in the device, the repair strategy provides guidance for self-healing operations, and the real-time operation status of the device is used to detect the device status of the IoT device in real time.

[0069] The reasoning layer is responsible for executing the self-check logic. It uses a concurrent method to quickly obtain the self-check results of each functional module. Based on at least one operating status parameter recorded in each self-check result, it evaluates the status of the corresponding functional module and predicts the overall business availability of the IoT device.

[0070] For self-healing faulty modules, the self-healing framework mainly provides progressive repair operations such as module restart, application (APP) restart, and device restart. According to the fault type and fault severity of the module, the self-healing framework automatically selects the appropriate repair strategy to improve the recovery speed of the faulty module and shorten the equipment downtime. For non-self-healing faulty modules, the self-healing framework also provides guidance information such as status display and recovery guidance to guide the users of IoT devices to take correct fault handling measures to avoid aggravating the equipment's fault problems due to incorrect operations and causing additional losses.

[0071] However, before solving the fault problem of the functional module, the self-healing detector of the notification module can be called to notify the faulty module to perform at least one of the cleanup operations and the save operations on the working data and operating status of its own module, so as to ensure that the key working data of the faulty module is properly handled in the operating status, and avoid data loss, inconsistent operating status and other situations that affect the normal operation of the equipment.

[0072] In addition to calling the self-healing detector, before resolving the fault problem of the functional module, you can also call the interceptor of the notification module to temporarily intercept the self-healing framework. When the functional module with the fault problem completes the corresponding module operation, the self-healing framework is allowed to continue to perform the repair operation. Alternatively, the self-healing framework can be directly intercepted through the interceptor to refuse the self-healing framework from continuing to perform the repair operation.

[0073] The self-check interface is used to display the target device's troubleshooting report, which helps IoT device users understand the device status. The self-check interface is also used to display the self-healing framework to provide status display, recovery guidance and other guidance information for the faulty modules that cannot be self-healed, guiding IoT device users to take correct fault handling measures.

[0074] This application also provides multiple triggering methods such as power-on self-test, standby self-test, and manual inspection. You can select one or more of these triggering methods to trigger the self-test operation according to the needs of the actual business scenario. Among them, the power-on self-test is performed when the target device is started, the standby self-test is performed when the target device is idle, and the manual inspection is actively triggered by the user of the target device.

[0075] Since the present application provides a variety of triggering methods, the self-test interface can also be adjusted according to different triggering methods (such as power-on self-test, standby self-test, manual inspection, etc.) to achieve the adaptation of the self-test interface to the triggering method. The flexible display method also makes the solution provided by the present application more practical.

[0076] The embodiments of the present application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, assisted driving, etc.

[0077] Figure 2B One application scenario is shown, including two IoT technology-based terminal devices 210 and a server 230. The terminal device 210 establishes a communication connection with the server 230 through a wired network or a wireless network.

[0078] Among them, the terminal device 210 of the embodiment of the present application includes but is not limited to: mobile phones, computers (such as tablets, laptops, desktop computers, etc.), smart home appliances, intelligent voice interaction devices (such as smart speakers, smart watches, etc.), vehicle-mounted terminals, aircraft, etc.

[0079] The server 230 of the embodiment of the present application can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), and big data and artificial intelligence platforms. This application does not make any restrictions here.

[0080] The device fault troubleshooting device can be set in a functional module in the terminal device 210, or can be a device independent of the terminal device 210. Assuming that the device fault troubleshooting device is deployed in the server 230, the process of using the device fault troubleshooting device to troubleshoot the terminal device 210 is as follows:

[0081] In response to the self-test operation triggered on the terminal device 210, a self-test request is sent to each functional module associated with the terminal device 210, and a self-test result returned by each functional module is obtained; the following operations are performed in a loop until all functional modules are processed, and a troubleshooting report of the target device and guidance information for the faulty module are displayed in the self-test interface: from the self-test result of a functional module that is not currently determined to have a fault, at least one operating status parameter of a functional module is read, and based on the at least one operating status parameter, a status evaluation is performed on the functional module to obtain a corresponding status evaluation result; when the status evaluation result represents an abnormal state, the functional module is used as a target fault module, and at least one other functional module that has a dependency relationship with the functional module is used as a potential fault module, and the dependency relationship is constructed based on the module call record of the functional module.

[0082] Next, see Figure 3A-3B As shown in the schematic diagram, the process of using the device troubleshooting device to troubleshoot each functional module associated with the target device is as follows:

[0083] S301: In response to a self-test operation triggered on a target device, a self-test request is sent to each functional module associated with the target device, and a self-test result returned by each functional module is obtained.

[0084] The target device of this application is a device based on IoT technology, which exchanges information and communicates through the Internet to provide users with corresponding device services. The target device is associated with multiple functional modules, which can be modules that exist in physical or virtual form (such as a preferred module, a camera module), or function points in a functional module for implementing specified functions (such as local recognition and cloud recognition in a recognition module).

[0085] In this application, the troubleshooting process is divided into two stages, namely: initialization stage, troubleshooting stage and fault repair stage. Among them, the initialization stage is before executing S301, the calling program in the scheduler initializes the self-check framework and each functional module associated with the target device; the troubleshooting stage is the operation performed by S301~302, which is used to troubleshoot the fault problems in the functional modules, and the fault repair stage is the self-healing framework to repair the functional modules with fault problems to solve the fault problems and restore the normal operation of the equipment as soon as possible.

[0086] The specific process of initialization is as follows:

[0087] First, the equipment fault troubleshooting device starts the calling program in the scheduler, and initializes the self-check framework by calling the program, providing basic support for the subsequent implementation of self-check and self-healing functions.

[0088] Secondly, each functional module is initialized by calling the program. When each functional module is initialized, it registers the corresponding self-check module and builds its own self-check rule set and self-healing rule set to perform self-check operations and repair operations later.

[0089] Thirdly, the self-check framework obtains at least one other functional module having a dependency relationship with each functional module according to the module call records of each functional module.

[0090] Taking a functional module as an example, at least one other functional module that has a dependency relationship with the functional module is obtained in the following manner: a module call record of a functional module is obtained, the module call record includes at least one call data, and each call data represents: a call process between the functional module and another functional module in response to a device service triggered for a target device; then, at least one other functional module included in the module call record is used as at least one other functional module that has a dependency relationship with the functional module.

[0091] In actual business scenarios, there may be situations where function module a calls function module b, and there may be situations where function module c calls function module a. Therefore, in this application, call data of a function module may be any of the following: the first is the call data generated when the function module calls another function module; the second is the call data generated when another function module calls the function module.

[0092] For example, the payment device associates the preferred module with the identification module, and obtains the module call records of the two modules respectively. The module call record of the preferred module includes: the call data of the preferred module calling the camera module in response to the face payment service triggered on the payment device, and the call data of the preferred module calling the algorithm module; the module call record of the identification module includes: the call data generated when the identification module performs local recognition, and the call data generated when the identification module performs cloud recognition.

[0093] Based on the module call records of the preferred modules, the dependency set shown in Table 1 is constructed, and based on the module call records of the identified modules, the dependency set shown in Table 2 is constructed.

[0094] Table 1

[0095] Serial number Dependencies 1 Face payment - preferred module - camera module 2 Face payment - optimization module - algorithm module

[0096] Table 2

[0097] Serial number Dependencies 1 Face payment - recognition module - local recognition 2 Face payment - recognition module - cloud recognition

[0098] Finally, the self-check framework generates at least one operating status parameter for each functional module according to the self-check rule set of each functional module.

[0099] Taking a functional module as an example, at least one operating status parameter of the functional module is generated in the following manner: a self-check rule set of a functional module is obtained, where the self-check rule set is constructed by the functional module when the functional module is initialized; the judgment conditions contained in at least one self-check rule in the self-check rule set are respectively extracted, and at least one judgment condition is used as the corresponding operating status parameter of the functional module.

[0100] For example, one of the judgment conditions of the algorithm module is "whether the model of the algorithm module is loaded normally", then the running status parameter of the algorithm module is "whether the model is loaded normally". After the algorithm module performs the self-check operation, the running status parameter of "the model can be loaded normally" or "the model cannot be loaded normally" will be sent to the self-check framework.

[0101] However, the table can only show the direct dependency between functional modules. When there are many functional modules associated with the target device, the troubleshooting efficiency is low. Therefore, in order to further improve the troubleshooting speed, the present application proposes a better implementation method, which generates at least one tree structure (such as dependency tree, decision tree, fault tree, etc.) based on the module call records and self-check rule sets of each functional module. The root node of each tree is the device service triggered for the target device, the parent node is the functional module associated with the target device, and the leaf node is at least one operating status parameter of the underlying parent node.

[0102] For example, the payment device associates the preferred module with the identification module, obtains the module call records and self-check rule sets of the two modules respectively, and generates the following based on the module call records and self-check rule sets of the two functional modules: Figure 3C The dependency tree shown in the figure. The root node of the dependency tree is the face payment service, the parent nodes are the various functional modules such as the optimization module, camera module, and algorithm module, and the child nodes are at least one operating status parameter of the underlying parent node.

[0103] The present application can adopt a top-down order traversal of each node in the tree, or a bottom-up order traversal of each node in the tree. Regardless of the traversal order adopted, the target device can be troubleshooted and fault located, providing a decision-making basis for subsequent fault handling.

[0104] During the troubleshooting stage, the calling program of the equipment troubleshooting device captures a trigger event for the target device. When it is determined that the trigger event satisfies a preset trigger mode, the self-check framework of the equipment troubleshooting device responds to the self-check operation for the target device, and sends a self-check request to each functional module associated with the target device, so that each functional module calls the corresponding self-check module, and each self-check module runs the registered self-check program, and checks each operating status parameter of the corresponding functional module in turn according to each self-check rule set set in the preset self-check rule set, determines the operating status parameter at this time, and sends the self-check result including at least one operating status parameter to the self-check framework.

[0105] In order to improve the efficiency of self-checking, the self-checking operation of each functional module and the operation of sending the results are performed asynchronously. That is, each functional module performs the self-checking operation while returning the generated self-checking results to the self-checking framework. After multiple transmissions, the self-checking framework finally obtains all the self-checking results of the corresponding module.

[0106] S302: Loop the following operations until all functional modules have been processed: read at least one operating status parameter of a functional module from the self-test result of a functional module that is not currently determined to have a fault, and perform a status evaluation on the functional module based on the at least one operating status parameter to obtain a corresponding status evaluation result; when the status evaluation result represents an abnormal state, use the functional module as a target fault module, and use at least one other functional module that has a dependency relationship with the functional module as a potential fault module, where the dependency relationship is constructed based on the module call record of the functional module.

[0107] At least one operating status parameter of a functional module is read from a self-test result of a functional module that is not currently determined to have a fault, and then, an inference judgment is performed based on a rule engine to obtain a status evaluation result of the functional module.

[0108] The rule engine uses a matching rule representation language and knowledge base representation language to build a set of evaluation rules suitable for evaluating the operating status of IoT devices by analyzing the IoT knowledge base. Among them, the evaluation rules can be written as regular expressions. As a string matching rule, this expression is composed of a series of common and special characters and is used to describe text rules. It can be understood as a language that describes the composition rules of a piece of text. Compared with long text rules, regular expressions are short and powerful. When used in this application, they can quickly and accurately complete the status evaluation of various functional modules associated with IoT devices.

[0109] The specific reasoning process is: based on at least one operating status parameter and a judgment rule preset for the functional module, a status evaluation result of the functional module is generated.

[0110] Among them, the status assessment results include operating status, fault type and fault severity. The operating status can be subdivided into: a normal state where the system can work normally, and an abnormal state where a fault exists. The fault type can be subdivided into: self-healing faults that can recover by themselves, and non-self-healing faults that require manual intervention to repair. In this application, the fault severity defaults to three levels: mild, moderate and severe. However, the fault severity can also be personalized according to the needs of the actual business scenario.

[0111] It should be noted that when the operating status is displayed as normal, the fault type and fault severity in the status assessment result are both empty values.

[0112] When the status assessment result represents an abnormal state, the functional module is used as the target fault module, and at least one other functional module that has a dependency relationship with the functional module is used as a potential fault module. This is helpful to identify potential fault problems in the target device, solve existing fault problems and potential fault problems in the device at one time, and ensure the reliability and operation efficiency of the equipment.

[0113] The self-check framework passes the status evaluation results to the calling program, which then passes the status evaluation results to the front end, and finally displays them to the target device users in the front end self-check interface. Figure 3D The troubleshooting report shown makes it easy for the user of the target device to understand the device status.

[0114] The present application obtains other functional modules that are dependent on the functional module based on the module call record of the functional module. When it is determined that a functional module has a fault, at least one other functional module that is dependent on the functional module is used as a potential fault module. This can not only quickly locate other functional modules affected by it and improve the efficiency of fault location, but also help to troubleshoot potential fault problems in the target device, solve existing fault problems and potential fault problems in the device at one time, and ensure the reliability and operation efficiency of the equipment.

[0115] After finding the target faulty module and at least one potential faulty module, the self-check framework triggers the self-healing framework to repair the faulty module and handle the faulty problem in a timely manner to avoid long equipment downtime and large delays.

[0116] The self-check framework triggers the execution of corresponding repair operations for the target fault module based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for the target fault module; and then performs the following operations for at least one potential fault module: based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for a potential fault module, triggers the execution of corresponding repair operations for a potential fault module.

[0117] For faulty modules that can be self-healed, the self-check framework calls the corresponding repair strategy according to the severity of the fault, and triggers the self-healing framework to perform repair operations such as module restart and APP restart on the faulty module according to the repair operations recorded in the repair strategy; for faulty modules that cannot be self-healed, the self-check framework calls the corresponding repair strategy according to the severity of the fault, and triggers the self-healing framework to provide prompt information such as status display and recovery guidance according to the repair operations recorded in the repair strategy, and then displays the above prompt information through the self-check interface to guide the users of the target device to take correct fault handling measures to avoid additional losses due to incorrect operations.

[0118] Among them, the following method is adopted to generate a repair strategy for a functional module regarding a self-healable fault: the self-check framework obtains a self-healing rule set of a functional module, and the self-healing rule set is constructed by the functional module when a functional module is initialized; then, based on the fault type and repair operation contained in at least one self-healing rule in the self-healing rule set, a repair strategy is generated for a functional module with a specified fault type, which triggers the execution of a corresponding repair operation.

[0119] However, before resolving the fault problem of the functional module, performing the following operations can ensure that the key working data of the faulty module is properly handled in the operating state, avoiding data loss, inconsistent operating status, and other situations that affect the normal operation of the equipment.

[0120] Since the operations performed on each fault module are the same, for ease of description, the target fault module is used as an example:

[0121] Call the self-healing detector of the notification module to send a notification request to the target fault module, so that the target fault module performs at least one of a cleanup operation and a save operation on its own working data and operating status; or, call the interceptor of the notification module to temporarily intercept the repair operation of the self-healing framework on the target fault module, and when it is detected that the target fault module has completed the corresponding module operation, notify to continue to execute the repair operation on the target fault module.

[0122] In addition, before resolving the fault problem of the functional module, you can also call the interceptor to directly intercept the repair operation of the self-healing framework for the target fault module and not perform the repair operation.

[0123] The self-healing framework performs corresponding repair operations on the faulty module according to the preset repair strategy, and returns the repair results to the self-check framework, which passes the repair results to the calling program, and then the calling program passes the repair results to the front end, and finally displays them to the target device users in the front-end self-check interface. Figure 3E The fault handling report shown not only helps users understand the device status, but also provides guidance information such as status display and recovery guidance for faulty modules that cannot heal themselves, thereby guiding users of IoT devices to take correct fault handling measures to avoid aggravating device failures and causing additional losses due to incorrect operations.

[0124] The equipment fault troubleshooting method proposed in this application has strong adaptability and scalability, and can flexibly adjust the self-check and repair strategies according to the actual needs of different scenarios, which helps to improve the reliability and operation efficiency of the equipment.

[0125] In addition to adopting centralized self-inspection and self-healing solutions, you can also adopt decentralized self-inspection and self-healing solutions based on functional module autonomous detection. Each functional module determines whether there is an abnormality in its own module. When an abnormality occurs in the running status, the self-inspection framework is notified, triggering the self-healing framework to perform corresponding repair operations on the functional module.

[0126] In addition to reasoning analysis based on a rule engine or a tree model traversal algorithm, other machine learning algorithms may also be used to predict, locate, and repair faults, which is not limited in this application.

[0127] A decentralized self-checking and self-healing solution based on functional module autonomous detection is adopted, and the equipment fault detection device is deployed in each functional module associated with the target device, and each functional module is self-checked and self-healed. Figure 4 As shown in the figure, a functional module is used as an example to illustrate the process of self-checking and self-healing of the functional module as follows:

[0128] S401: In response to a self-check operation triggered for a functional module, the operating status of the module itself is checked to obtain a corresponding self-check result.

[0129] Before executing S401, the device troubleshooting apparatus starts the calling program of the scheduler, and initializes each functional module associated with the self-check framework and the target device through the calling program. The specific initialization process is as follows:

[0130] First, the equipment fault troubleshooting device starts the calling program in the scheduler, and initializes the self-check framework by calling the program, providing basic support for the subsequent implementation of self-check and self-healing functions.

[0131] Secondly, each functional module is initialized by calling the program. When each functional module is initialized, it registers the corresponding self-check module and builds its own self-check rule set and self-healing rule set to perform self-check operations and repair operations later.

[0132] Thirdly, the self-check framework obtains at least one other functional module that has a dependency relationship with each functional module according to the module call records of each functional module. The module call record includes at least one call data, each call data represents: a call process between the functional module and another functional module in response to a device service triggered for a target device.

[0133] Finally, the self-check framework generates at least one operating status parameter for each functional module according to the self-check rule set of each functional module.

[0134] In the initialization phase, the self-check module, self-check rule set and self-healing rule set of the functional module have been registered. Therefore, in the troubleshooting phase, the functional module responds to the self-check operation triggered on the functional module and calls the self-check module, which checks each operating status parameter of its own module in turn according to each self-check rule set in the self-check rule set, determines the operating status parameter at this time, and sends the self-check result including at least one operating status parameter to the self-check framework.

[0135] S402: When it is determined that the own module has not been determined to have a fault, based on each operating status parameter recorded in the self-test result, a status evaluation is performed on the own module to obtain a corresponding status evaluation result.

[0136] A functional module calls a state assessment model based on a machine learning algorithm to perform multi-scale feature extraction on the input operating state parameters to obtain the initial state features at each scale. Since low-level features undergo fewer convolutions, they contain more noise and have lower semantics; high-level features are just the opposite, with stronger semantic information, but poorer perception of details.

[0137] In order to take advantage of its strengths and discard its weaknesses, this application fuses initial state features of different scales to obtain fused state features with more semantic information and stronger detail perception to improve the detection performance of the model. Finally, based on the obtained fused state features, it is determined whether the module itself has state abnormalities and generates corresponding state evaluation results.

[0138] Among them, the status assessment results include operating status, fault type and fault severity. The operating status can be subdivided into: a normal state where the system can work normally, and an abnormal state where a fault exists. The fault type can be subdivided into: self-healing faults that can recover by themselves, and non-self-healing faults that require manual intervention to repair. In this application, the fault severity defaults to three levels: mild, moderate and severe. However, the fault severity can also be personalized according to the needs of the actual business scenario.

[0139] It should be noted that when the operating status is displayed as normal, the fault type and fault severity in the status assessment result are both empty values.

[0140] S403: When the status assessment result represents an abnormal state, the own module is taken as a target fault module, and at least one other functional module having a dependency relationship with the own module is taken as a potential fault module, wherein the dependency relationship is constructed based on a module call record of a functional module.

[0141] When a functional module is determined to be a faulty target fault module, at least one other functional module that has a dependency relationship with it may also be affected, resulting in new fault problems. Therefore, the present application will also treat at least one other functional module that has a dependency relationship with the functional module as a potential fault module, which is conducive to troubleshooting potential fault problems in the target device, solving existing fault problems and potential fault problems in the device at one time, and ensuring the reliability and operating efficiency of the equipment.

[0142] Moreover, for functional modules that have been determined to be potential fault modules, this application will not repeat the inspection, which saves some self-inspection time and reduces the fault handling cost to a certain extent. Especially when there are many functional modules associated with the target device, this method can be used for self-inspection and self-healing, which can further shorten the fault recovery time and reduce equipment downtime.

[0143] S404: A functional module calls a corresponding self-healing rule set through a self-check framework, and repairs the fault problem of its own module according to the self-healing operation recorded in the self-healing rule set.

[0144] A functional module serving as a target fault module and at least one other functional module serving as a potential fault module trigger a self-healing framework through a self-check framework of the equipment fault troubleshooting device to obtain their respective self-healing rule sets, and repair the fault problems of each functional module respectively according to the repair strategies recorded in each self-healing rule set.

[0145] For ease of understanding, Figures 5A-5B As shown, the device fault troubleshooting method is applied in an actual scenario, and the process of troubleshooting and handling multiple functional modules associated with the payment device is as follows:

[0146] S501: Start the calling program in the scheduler and initialize the self-check framework by calling the program;

[0147] S502: Initialize each functional module by calling a program;

[0148] S503: When each functional module is initialized, it registers its own self-checking module and builds its own self-checking rule set and self-healing rule set;

[0149] S504: The self-check framework generates a Figure 5C The dependency tree shown;

[0150] S505: When it is detected by calling the program that the payment device is to be powered on for self-test, the self-test framework sends a self-test request to each functional module associated with the payment device;

[0151] S506: Each functional module performs a self-check operation according to the registered self-check program, checks the operation status of each module according to the preset self-check rule set, and sends the self-check result to the self-check framework;

[0152] S507: the self-check framework runs the dependency tree, and concurrently traverses the leaf nodes of each branch in the dependency tree in a bottom-up order. Each time a leaf node of a branch is traversed, a corresponding running status parameter is read from the self-check result of the functional module to which the branch belongs, and a status evaluation is performed on the corresponding functional module based on the at least one obtained running status parameter to obtain a corresponding status evaluation result.

[0153] S508: When the status evaluation result of the short connection indicates an abnormal state, the short connection is used as a target fault module, and the network request, cloud identification, and identification modules that have a direct or indirect dependency relationship with the short connection are used as potential fault modules;

[0154] S509: Display in the self-check interface Figure 5D Troubleshooting report shown;

[0155] S510: The self-check framework triggers the self-healing framework to perform corresponding repair operations on the corresponding faulty modules based on the status evaluation results of each faulty module and the respective repair strategies;

[0156] S511: The self-healing framework sends a notification request to each faulty module through the repair detector, and saves the working data and operating status of its own module;

[0157] S512: The self-healing framework performs corresponding repair operations on each faulty module and transmits the repair result to the front end;

[0158] S513: Display in the self-check interface Figure 5E Troubleshooting report shown.

[0159] Based on the same inventive concept as the above method embodiment, the present application embodiment also provides a device for troubleshooting equipment failures. Figure 6 As shown, the device fault troubleshooting apparatus 600 may include:

[0160] The self-test unit 601 is used to send a self-test request to each functional module associated with the target device in response to the self-test operation triggered for the target device, and obtain the self-test results returned by each functional module;

[0161] The troubleshooting unit 602 is used to perform the following operations in a loop until all functional modules are processed: read at least one operating status parameter of a functional module from the self-test result of a functional module that is not currently determined to have a fault, and based on the at least one operating status parameter, perform a status evaluation on the functional module to obtain a corresponding status evaluation result; when the status evaluation result represents an abnormal state, use the functional module as a target fault module, and use at least one other functional module that has a dependency relationship with the functional module as a potential fault module, where the dependency relationship is constructed based on a module call record of the functional module.

[0162] Optionally, the self-checking unit 601 obtains at least one other functional module that has a dependency relationship with a functional module by:

[0163] Acquire a module call record of a functional module, the module call record comprising at least one call data, each call data representing: a call process between a functional module and another functional module in response to a device service triggered for a target device;

[0164] At least one other functional module included in the module call record is regarded as at least one other functional module having a dependency relationship with a functional module.

[0165] Optionally, each call data includes any of the following:

[0166] The calling data generated when a function module calls another function module, and the calling data generated when another function module calls a function module.

[0167] Optionally, the self-checking unit 601 generates at least one operating status parameter of a functional module in the following manner:

[0168] Get a self-check rule set of a functional module, the self-check rule set is constructed by a functional module when initializing a functional module;

[0169] The judgment conditions contained in at least one self-check rule in the self-check rule set are respectively extracted, and the at least one judgment condition is used as a corresponding running state parameter of a functional module.

[0170] Optionally, the fault troubleshooting unit 602 is used to:

[0171] Based on at least one operating status parameter and a preset judgment rule for a functional module, a status evaluation result of a functional module is generated.

[0172] Optionally, after the target fault module and at least one potential fault module are obtained through troubleshooting, the device fault troubleshooting apparatus 600 further includes a fault repair unit 603, which is used to:

[0173] Based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for the target fault module, trigger the execution of corresponding repair operations for the target fault module;

[0174] For at least one potential fault module, the following operations are performed respectively: based on the fault type and fault severity recorded in the state evaluation result of the target fault module and the repair strategy for a potential fault module, trigger a corresponding repair operation for a potential fault module.

[0175] Optionally, when a corresponding repair operation for a target faulty module is triggered, the device fault troubleshooting apparatus 600 further includes a notification unit 604, which is used to:

[0176] When a corresponding repair operation for a target faulty module is detected to be triggered, a notification request is sent to the target faulty module, so that the target faulty module performs at least one of a cleanup operation and a save operation on its own working data and operating status;

[0177] or,

[0178] When it is detected that a corresponding repair operation for a target faulty module is triggered, the repair operation for the target faulty module is intercepted, and when it is detected that the target faulty module completes the corresponding module operation, a notification is given to continue to execute the repair operation for the target faulty module.

[0179] For the convenience of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, when implementing this application, the functions of each module (or unit) can be implemented in the same or multiple software or hardware.

[0180] After introducing the device fault troubleshooting method and apparatus according to an exemplary embodiment of the present application, next, a computer device according to another exemplary embodiment of the present application is introduced.

[0181] Those skilled in the art will appreciate that various aspects of the present application may be implemented as a system, method or program product. Therefore, various aspects of the present application may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to as "circuit", "module" or "system" herein.

[0182] Based on the same inventive concept as the above method embodiment, the present application embodiment also provides a computer device. In one embodiment, the computer device may be a server, such as Figure 2B In this embodiment, the structure of the computer device 700 is as follows: Figure 7 As shown, it may include at least a memory 701 , a communication module 703 , and at least one processor 702 .

[0183] The memory 701 is used to store computer programs executed by the processor 702. The memory 701 may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system and programs required for running the instant messaging function, etc.; the data storage area may store various instant messaging information and operation instruction sets, etc.

[0184] The memory 701 may be a volatile memory, such as a random-access memory (RAM); the memory 701 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD); or the memory 701 may be any other medium that can be used to carry or store a desired computer program in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 701 may be a combination of the above memories.

[0185] The processor 702 may include one or more central processing units (CPU) or a digital processing unit, etc. The processor 702 is used to implement the above-mentioned device fault troubleshooting method when calling the computer program stored in the memory 701 .

[0186] The communication module 703 is used to communicate with terminal devices and other servers.

[0187] The specific connection medium between the memory 701, the communication module 703 and the processor 702 is not limited in the embodiment of the present application. Figure 7 In the embodiment, the memory 701 and the processor 702 are connected via a bus 704. The bus 704 is connected to the processor 702 via a bus 704. Figure 7 The connections between the other components are only for illustration and are not intended to be limiting. The bus 704 can be divided into an address bus, a data bus, a control bus, etc. For ease of description, Figure 7 The diagram shows that only one thick line is used, but this does not mean that there is only one bus or only one type of bus.

[0188] The memory 701 stores a computer storage medium, and the computer storage medium stores computer executable instructions, and the computer executable instructions are used to implement the device fault troubleshooting method of the embodiment of the present application. The processor 702 is used to execute the above-mentioned device fault troubleshooting method, such as Figure 3A shown.

[0189] In another embodiment, the computer device may also be other computer devices, such as Figure 2B The terminal device 210 shown in FIG. 1 is a terminal device 210 shown in FIG. 1 . In this embodiment, the structure of the computer device can be as follows: Figure 8 As shown, it includes: a communication component 810, a memory 820, a display unit 830, a camera 840, a sensor 850, an audio circuit 860, a Bluetooth module 870, a processor 880 and other components.

[0190] The communication component 810 is used to communicate with the server. In some embodiments, a wireless fidelity (WiFi) module may be included. The WiFi module belongs to a short-range wireless transmission technology. The electronic device can help the object to send and receive information through the WiFi module.

[0191] The memory 820 can be used to store software programs and data. The processor 880 executes various functions and data processing of the terminal device 210 by running the software programs or data stored in the memory 820. The memory 820 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, or other volatile solid-state storage device. The memory 820 stores an operating system that enables the terminal device 210 to run. In the present application, the memory 820 can store an operating system and various application programs, and can also store a computer program for executing the device troubleshooting method of the embodiment of the present application.

[0192] The display unit 830 can also be used to display information input by the object or information provided to the object and a graphical user interface (GUI) of various menus of the terminal device 210. Specifically, the display unit 830 may include a display screen 832 disposed on the front of the terminal device 210. The display screen 832 may be configured in the form of a liquid crystal display, a light emitting diode, etc. The display unit 830 may be used to display a defect detection interface, a model training interface, etc. in the embodiment of the present application.

[0193] The display unit 830 can also be used to receive input digital or character information and generate signal input related to the object setting and function control of the terminal device 210. Specifically, the display unit 830 may include a touch screen 831 set on the front of the terminal device 210, which can collect touch operations of objects on or near it, such as clicking a button, dragging a scroll box, etc.

[0194] The touch screen 831 can be covered on the display screen 832, or the touch screen 831 and the display screen 832 can be integrated to realize the input and output functions of the terminal device 210, and the integrated display screen can be referred to as a touch display screen. In this application, the display unit 830 can display the application and the corresponding operation steps.

[0195] The camera 840 can be used to capture static images, and the subject can publish the images taken by the camera 840 through the application. The camera 840 can be one or more. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the processor 880 to convert it into a digital image signal.

[0196] The terminal device may further include at least one sensor 850, such as an acceleration sensor 851, a distance sensor 852, a fingerprint sensor 853, and a temperature sensor 854. The terminal device may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, a light sensor, and a running sensor.

[0197] The audio circuit 860, the speaker 861, and the microphone 862 can provide an audio interface between the object and the terminal device 210. The audio circuit 860 can transmit the electrical signal converted from the received audio data to the speaker 861, which is converted into a sound signal for output. The terminal device 210 can also be configured with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 862 converts the collected sound signal into an electrical signal, which is received by the audio circuit 860 and converted into audio data, and then the audio data is output to the communication component 810 to be sent to, for example, another terminal device 210, or the audio data is output to the memory 820 for further processing.

[0198] The Bluetooth module 870 is used to exchange information with other Bluetooth devices having Bluetooth modules through the Bluetooth protocol. For example, the terminal device can establish a Bluetooth connection with a wearable electronic device (such as a smart watch) that also has a Bluetooth module through the Bluetooth module 870 to exchange data.

[0199] The processor 880 is the control center of the terminal device. It uses various interfaces and lines to connect various parts of the entire terminal. It executes various functions of the terminal device and processes data by running or executing software programs stored in the memory 820 and calling data stored in the memory 820. In some embodiments, the processor 880 may include one or more processing units; the processor 880 may also integrate an application processor and a baseband processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the baseband processor mainly processes wireless communications. It is understandable that the above-mentioned baseband processor may not be integrated into the processor 880. In the present application, the processor 880 can run the operating system, application programs, user interface display and touch response, as well as the device troubleshooting method of the embodiment of the present application. In addition, the processor 880 is coupled to the display unit 830.

[0200] In addition, it should be noted that in the specific implementation of this application, object data related to equipment troubleshooting, etc. is involved. When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain the object's permission or consent, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0201] In some possible implementations, various aspects of the device fault troubleshooting method provided in the present application may also be implemented in the form of a program product, which includes a computer program. When the program product is run on a computer device, the computer program is used to enable the computer device to execute the steps of the device fault troubleshooting method according to various exemplary embodiments of the present application described above in this specification. For example, the computer device may execute the following steps: Figure 3A Follow the steps shown in .

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

[0203] The program product of the embodiment of the present application may adopt a portable compact disk read-only memory (CD-ROM) and include a computer program, and can be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium containing or storing a program, which can be used by or in combination with a command execution system, apparatus, or device.

[0204] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein a readable computer program is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with a command execution system, apparatus, or device.

[0205] The computer program embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0206] The computer program for performing the operations of the present application may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The computer program may be executed entirely on the user's computer device, partially on the user's computer device, as a separate software package, partially on the user's computer device and partially on a remote computer device, or entirely on the remote computer device. In the case of a remote computer device, the remote computer device may be connected to the user's computer device through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer device (e.g., via the Internet using an Internet service provider).

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

[0208] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0209] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain a computer-usable computer program.

[0210] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program commands. These computer program commands can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the commands executed by the processor of the computer or other programmable data processing device generate commands for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0211] These computer program commands may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the commands stored in the computer readable memory produce an article of manufacture comprising a command device, the command device implementing the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0212] These computer program commands can also be loaded onto a computer or other programmable data processing device so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the commands executed on the computer or other programmable device provide the instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0213] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0214] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A device fault troubleshooting method, characterized in that: include: In response to a self-test operation triggered for a target device, a self-test request is sent to each functional module associated with the target device, and a self-test result returned by each functional module is obtained; The following operations are performed in a loop until all functional modules are processed: from a self-test result of a functional module that is not currently determined to have a fault, at least one operating status parameter of the functional module is read, and based on the at least one operating status parameter, a status evaluation is performed on the functional module to obtain a corresponding status evaluation result, and when the status evaluation result represents an abnormal state, the functional module is used as a target fault module, and at least one other functional module that has a dependency relationship with the functional module is used as a potential fault module, wherein the dependency relationship is constructed based on a module call record of the functional module.

2. The method according to claim 1, characterized in that At least one other functional module having a dependency relationship with the one functional module is obtained in the following manner: Acquire a module call record of the one functional module, the module call record comprising at least one call data, each of the call data representing: a call process between the one functional module and another functional module in response to a device service triggered for the target device; The at least one other functional module included in the module call record is used as the at least one other functional module having a dependency relationship with the one functional module.

3. The method according to claim 2, characterized in that Each of the call data includes any of the following: The calling data generated when the one functional module calls the other functional module, and the calling data generated when the other functional module calls the one functional module.

4. The method according to claim 1, characterized in that At least one operating status parameter of the functional module is generated in the following manner: Acquire a self-check rule set of the one functional module, where the self-check rule set is constructed by the one functional module when the one functional module is initialized; The judgment conditions contained in at least one self-check rule in the self-check rule set are respectively extracted, and the at least one judgment condition is used as the corresponding running state parameter of the one functional module.

5. The method according to claim 4, characterized in that The step of performing a status evaluation on the one functional module based on at least one operating status parameter to obtain a corresponding status evaluation result includes: Based on the at least one operating status parameter and a preset judgment rule for the one functional module, a status evaluation result of the one functional module is generated.

6. The method according to any one of claims 1 to 5, characterized in that: After the target fault module and at least one potential fault module are obtained through troubleshooting, the method further includes: Based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for the target fault module, triggering execution of a corresponding repair operation for the target fault module; For the at least one potential fault module, the following operations are performed respectively: based on the fault type and fault severity recorded in the status evaluation result of the target fault module and the repair strategy for a potential fault module, trigger the execution of a corresponding repair operation for the potential fault module.

7. The method according to claim 6, characterized in that Before performing a corresponding repair operation on the target faulty module, the method further includes: Sending a notification request to the target fault module, so that the target fault module performs at least one of a cleanup operation and a save operation on its own working data and operating status; or, The repair operation for the target faulty module is intercepted, and when it is detected that the target faulty module has completed the corresponding module operation, a notification is given to continue to perform the repair operation for the target faulty module.

8. A device for troubleshooting equipment, characterized in that: include: A self-test unit, configured to, in response to a self-test operation triggered on a target device, send a self-test request to each functional module associated with the target device, and obtain a self-test result returned by each functional module; A troubleshooting unit is used to perform the following operations in a loop until all functional modules are processed: from a self-test result of a functional module that is not currently determined to have a fault, read at least one operating status parameter of the functional module, and based on the at least one operating status parameter, perform a status evaluation on the functional module to obtain a corresponding status evaluation result; when the status evaluation result represents an abnormal state, use the functional module as a target fault module, and use at least one other functional module that has a dependency relationship with the functional module as a potential fault module, wherein the dependency relationship is constructed based on a module call record of the functional module.

9. The device according to claim 8, characterized in that The self-checking unit obtains at least one other functional module that has a dependency relationship with the one functional module in the following manner: Acquire a module call record of the one functional module, the module call record comprising at least one call data, each of the call data representing: a call process between the one functional module and another functional module in response to a device service triggered for the target device; The at least one other functional module included in the module call record is used as the at least one other functional module having a dependency relationship with the one functional module.

10. The device according to claim 9, characterized in that Each of the call data includes any of the following: The calling data generated when the one functional module calls the other functional module, and the calling data generated when the other functional module calls the one functional module.

11. The device according to claim 8, characterized in that The self-checking unit generates at least one operating status parameter of the functional module in the following manner: Acquire a self-check rule set of the one functional module, where the self-check rule set is constructed by the one functional module when the one functional module is initialized; The judgment conditions contained in at least one self-check rule in the self-check rule set are respectively extracted, and the at least one judgment condition is used as the corresponding running state parameter of the one functional module.

12. The device according to claim 11, characterized in that The troubleshooting unit is used for: Based on the at least one operating status parameter and a preset judgment rule for the one functional module, a status evaluation result of the one functional module is generated.

13. A computer device, characterized in that: It comprises a processor and a memory, wherein the memory stores program codes, and when the program codes are executed by the processor, the processor executes the steps of the method according to any one of claims 1 to 7.

14. A computer-readable storage medium, characterized in that: It includes program codes. When the program codes are run on a computer device, the program codes are used to enable the computer device to execute the steps of the method according to any one of claims 1 to 7.

15. A computer program product, characterized in that The method comprises computer instructions, which, when executed by a processor, implement the steps of the method according to any one of claims 1 to 7.

Images