A fault report checking method, device, equipment and storage medium

Abstract

The application discloses a fault report checking method and device, equipment and a storage medium, the method comprises the following steps: obtaining the fault type of an elevator, obtaining the first fault information associated with the fault type, obtaining the fault report, extracting the second fault information from the fault report, determining the accuracy of the second fault information based on the first fault information, and determining that the fault report checking is successful when the accuracy is greater than a specified threshold, realizing automatic auditing of the fault report, reducing the input of human cost, reducing the dependence on artificial knowledge reserves, improving the auditing efficiency, and quantifying the authenticity of the fault report by using probability, so that the fault report can be evaluated more intuitively and accurately.

Description

Technical Field

[0001] This invention belongs to the technical field of data processing, and particularly relates to a method, apparatus, device and storage medium for verifying fault reports. Background Technology

[0002] A fault report is a process record document issued by maintenance personnel after an accident or malfunction of certain equipment, such as an elevator fault report. Fault reports are an important basis for determining the cause of a fault.

[0003] For elevator malfunction reports, elevator repair and maintenance are generally handled by the same company. This means that the same personnel are likely to perform both the repair and maintenance of the same elevator. Companies can use the information provided in the elevator malfunction reports to assess the daily work performance of these personnel.

[0004] Therefore, the data in the fault reports submitted by operators may have a certain degree of personal bias, and the collected information may not necessarily reflect the actual cause of the fault. The content filled in the fault reports may contain false information and may not match the actual fault.

[0005] Currently, to verify the accuracy of the information in elevator malfunction reports submitted by operators, companies typically rely on experienced verifiers who, based on the malfunction symptoms, the stated causes, and their own understanding of the malfunction, determine the report's authenticity. This verification method demands a high level of experience from the verifiers and is inefficient in both review and management. Summary of the Invention

[0006] This invention provides a method, apparatus, device, and storage medium for verifying fault reports, in order to solve the problem that the current method can only rely on manual verification of elevator fault reports. By extracting information from the fault reports and determining the accuracy rate, the method can achieve the goal of verifying elevator fault reports without relying on manual labor.

[0007] According to one aspect of the present invention, a method for verifying fault reports is provided, characterized in that the method includes:

[0008] Obtain the elevator's fault type, and obtain the first fault information associated with the fault type;

[0009] Obtain a fault report and extract second fault information from the fault report;

[0010] Based on the first fault information, determine the accuracy of the second fault information;

[0011] When the accuracy rate is greater than the specified threshold, the fault report is deemed to have been successfully verified.

[0012] According to one aspect of the present invention, a fault report verification device is provided, the device comprising:

[0013] The fault type acquisition module is used to acquire the fault type of the elevator;

[0014] The first fault information acquisition module is used to acquire first fault information associated with the fault type;

[0015] The second fault information extraction module is used to obtain a fault report and extract second fault information from the fault report.

[0016] An accuracy determination module is used to determine the accuracy of the second fault information based on the first fault information;

[0017] The verification success determination module is used to determine that the fault report has been successfully verified when the accuracy rate is greater than a specified threshold.

[0018] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0019] At least one processor; and

[0020] A memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform a fault report verification method according to any embodiment of the present invention.

[0022] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement a fault report verification method according to any embodiment of the present invention.

[0023] The technical solution of this invention provides a method for verifying fault reports. The method includes: obtaining the fault type of the elevator, obtaining first fault information associated with the fault type, obtaining a fault report, extracting second fault information from the fault report, determining the accuracy rate of the second fault information based on the first fault information, and determining that the fault report verification is successful when the accuracy rate is greater than a specified threshold. This achieves automatic review of fault reports, reduces the input of human resources, reduces reliance on human knowledge reserves, and improves review efficiency. By using probability to quantify the authenticity of fault reports, fault reports can be evaluated more intuitively and accurately.

[0024] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart of a fault report verification method provided according to Embodiment 1 of the present invention;

[0027] Figure 2 This is a schematic diagram of a device assembly according to Embodiment 1 of the present invention;

[0028] Figure 3 This is a schematic diagram of the structure of a fault report verification device according to Embodiment 2 of the present invention;

[0029] Figure 4 This is a schematic diagram of the structure of an electronic device that implements a fault report verification method according to an embodiment of the present invention. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] Example 1

[0033] Figure 1 This is a flowchart of a fault report verification method provided in Embodiment 1 of the present invention.

[0034] When an elevator malfunctions, it is often caused by a combination of different states of multiple devices, and different malfunctions are associated with different devices. In the existing method of relying on manual verification, the verifier mainly checks the current malfunction phenomenon against the equipment information recorded in the malfunction report. If the equipment information recorded in the malfunction report clearly cannot cause the current malfunction phenomenon, the malfunction report can be considered to have low authenticity and may contain fabricated information, thus the verification is deemed a failure.

[0035] This method can be performed by a fault reporting verification device, which can be implemented in hardware and / or software.

[0036] like Figure 1 As shown, the method includes the following steps:

[0037] S110, obtain the elevator's fault type, and obtain the first fault information associated with the fault type.

[0038] When an elevator malfunctions, its operating status record code changes. The elevator can use an IoT terminal to record and save the cached status data of all devices at the moment the operating status record code changes. The IoT terminal can upload fault events to a designated data center. These fault events include fault types, such as "door opening / closing abnormality" or "main computer failure." Therefore, the elevator's fault type can be obtained from the data center designated by the IoT system in which the elevator is located.

[0039] The first fault information can refer to information in the fault event other than the fault type, such as the equipment status of all devices at the time of the fault. In addition, the first fault information can also include historical data information related to the fault type, for example, the equipment status of all devices corresponding to the fault type when it occurred in the historical data.

[0040] In one embodiment, obtaining first fault information associated with the fault type includes the following steps:

[0041] S110-1, Obtain multiple first device names associated with the fault type;

[0042] S110-2, Combine the device status corresponding to the first device name to obtain multiple first device combinations, wherein the device status is normal or abnormal;

[0043] S110-3, the obtained first equipment combination is used as the first fault information.

[0044] Different fault types are associated with different equipment in the elevator, and some are not. For example, when the fault type is "abnormal door opening and closing", it is obvious that "abnormal door opening and closing" is unrelated to the status of the lighting equipment in the elevator.

[0045] Because elevators have many devices, and different devices have different states under different circumstances, such as normal and abnormal states, it would consume a lot of computing power if each check were to be performed based on the analysis of all devices in the elevator. For example, suppose there are 100 elevator devices (the actual number of elevator devices is more than 100), and each device has two states, such as normal and abnormal states. Then, the combination of the device states of 100 devices would result in 2^100 possible combinations.

[0046] Therefore, based on historical data of devices that have caused this type of fault in the past, a pre-established association between different fault types and their associated devices can be created. It's important to note that the associations with fault types can include not only hardware devices like elevator doors, but also certain command reception statuses. For example, the following can be pre-set parameters associated with the fault type "abnormal door opening / closing": door operator status, door opening limits, door closing limits, and door opening commands.

[0047] After identifying the devices associated with the fault type, different device states can be combined. (Reference) Figure 2 A schematic diagram of a device combination is provided. For example, when the fault type is associated with the door operator status, door opening limit, door closing limit, and door opening command, the following parameters are defined: Door operator status: 1 indicates normal, 0 indicates abnormal; Door opening limit: 1 indicates the door can be opened to its limit, 0 indicates the door has not been opened to its limit; Door closing limit: 1 indicates the door can be closed to its limit, 0 indicates the door has not been closed to its limit; Door opening command: 1 indicates the door opening / closing command exists, 0 indicates no door opening / closing command exists. With four associated devices, each corresponding to two device states, combining these device states yields 4^2 = 16 combinations, such as... Figure 2 There are 16 equipment combinations, from combination 1 to combination 16.

[0048] The device status corresponding to all the first device names can be combined to obtain the first device combination as the first fault information. For example, Figure 2 The device combinations of combinations 1 to 16 can be used as the first fault information.

[0049] S120, obtain the fault report and extract the second fault information from the fault report.

[0050] When operators write fault reports, they use natural language, meaning the reports are in text format. Keyword extraction can be performed on the fault report text to extract the equipment names mentioned in the report and their corresponding equipment statuses as secondary fault information. When extracting secondary fault information, a specialized thesaurus for the elevator industry can be pre-built, and the secondary fault information can be derived by matching the text with words in the thesaurus.

[0051] In one embodiment, extracting the second fault information from the fault report in step S120 includes the following steps:

[0052] S120-1, Identify the text in the fault report, segment the text into words, and obtain multiple candidate key sentences;

[0053] S120-2, Match the candidate key statements with multiple pre-determined sample key statements, and determine the similarity between each candidate key statement and each sample key statement.

[0054] S120-3, Identify candidate key statements with a similarity greater than a specified similarity threshold as key statements;

[0055] S120-4, Identify the sample key statement with the highest similarity to each key statement;

[0056] S120-5, Based on the sample key statement with the highest similarity to each key statement, determine the second fault information.

[0057] When extracting secondary fault information from a fault report, the text can first be segmented using punctuation marks such as periods and commas to obtain multiple candidate key sentences based on punctuation. Specifically, Natural Language Processing (NLP) technology can be applied to identify and segment the fault report. NLP technology is currently a mature technology for text processing and will not be elaborated on here.

[0058] A large number of historical fault reports can be used as training samples to obtain multiple sample key sentences that describe the device name and the corresponding device status. Specifically, sample key sentences can be obtained by training a large number of fault reports using a shallow neural network.

[0059] After identifying candidate keywords, they can be matched with multiple pre-defined sample keywords obtained through training. The similarity between each candidate keyword and each sample keyword is then determined. Candidate keywords with a similarity greater than a specified similarity threshold are identified as keywords, while keywords lacking key information such as device names or device status are filtered out. Similarity can be determined using statistical methods such as edit distance calculation or Jaccard coefficient calculation.

[0060] Each statement may have a similarity score higher than a similarity threshold with multiple sample key statements. The sample key statement with the highest similarity to each key statement can be identified, and the second fault information can be determined from this highest similarity sample key statement. The second fault information can be the device name and device status extracted from the highest similarity sample key statement. Since this sample key statement has the highest similarity to the key statements, the second fault information determined from it can also be considered as information contained within that key statement.

[0061] In one embodiment, determining the similarity between each candidate key statement and each sample key statement in S120-2 includes the following steps:

[0062] Convert candidate key phrases into first word vectors;

[0063] Obtain the second word vector of the key sentences in the sample;

[0064] Based on the first word vector and the second word vector, the similarity between each candidate key statement and each sample key statement is determined.

[0065] Candidate and sample key phrases belonging to the text can be converted into computer language, i.e., word vectors, using discrete or distributed representation methods. Discrete representation does not consider word order during encoding; representative implementations include one-hot encoding, bag of words, and TF-IDF. Distributed representation uses neighboring words to represent a word; representative implementations include co-occurrence matrices, NNLM neural network language models, and CBOW (continued bag of words). This invention does not limit the specific method used to convert candidate and sample key phrases into vectors. To reduce computational effort and speed up the process, the second word vector of the sample key phrase can be determined in advance.

[0066] After the candidate key phrases are converted into first word vectors, the second word vectors of each sample key phrase can be obtained in advance. The cosine similarity can be used to calculate the cosine value of the angle between the second word vector and each first word vector, which is the dot product divided by the magnitude of the two. The cosine value between the vectors can be used to determine the similarity between each candidate key phrase and each sample key phrase.

[0067] In one embodiment, S120-5 includes the following steps:

[0068] The sample key statement with the highest similarity to each key statement is identified as the target key statement;

[0069] Extract the second device name and the corresponding second device status from the target key statement;

[0070] The second device name and the second device status are combined to form a second device combination, and the second device combination is used as the second fault information.

[0071] After determining the similarity between each key statement and each sample key statement, the sample key statement with the highest similarity to the key statement can be regarded as expressing the information of the key statement. Since the sample key statements are obtained through training with a large number of samples, they will be more complete in expressing information. Therefore, the sample key statement with the highest similarity to each key statement can be determined as the target key statement. Then, the second device name and the second device status corresponding to the second device name are extracted from the target key statement as the second fault information.

[0072] S130, based on the first fault information, determine the accuracy of the second fault information.

[0073] Having identified all combinations of device states corresponding to the first device name associated with the fault type, prior experience can be used to determine the likelihood of each device combination causing that fault type. Figure 2 In combination 16, assuming the door operator is functioning normally, can open and close the door to its maximum limits, and can receive opening commands, the likelihood of it causing the "abnormal door opening / closing" fault type is low. By combining the fault types caused by various equipment combinations from a large sample of prior fault events, the probability of each equipment combination causing a specific fault type can be determined. The probability of the equipment combination corresponding to the second fault information causing that fault type can be used as the accuracy rate of the second fault information.

[0074] In one embodiment, S130 includes the following steps:

[0075] S130-1, Based on Bayesian principles, determine the probability of fault occurrence corresponding to the fault type caused by the first equipment combination;

[0076] S130-2, Identify from the first equipment combination the same as the second equipment combination as the target equipment combination;

[0077] S130-3, obtain the probability of triggering the target device combination, and use the triggering probability as the accuracy of the second fault information.

[0078] The probability of a fault of this type caused by a first combination of equipment can be determined using Bayes' theorem, that is, the likelihood of different combinations of equipment causing this type of fault.

[0079] Specifically, Bayes' theorem is: P(B│A)=(P(A│B)P(B)) / (P(A)). Here, A represents the equipment combination causing the fault type; P(A) is the total probability that equipment combination A causes the fault type in a large sample, also known as the standardized constant. P(B) is called the prior probability, which is the probability that the content of a fault report is correct, generally assumed to be 50%. P(A|B) is the proportion of fault reports where equipment combination A is the cause, assuming the fault report is correct, called the likelihood. P(B|A) is called the posterior probability, which is the probability that equipment combination A causes the corresponding fault type, and can be used as the accuracy rate of fault reports containing information related to equipment combination A.

[0080] The probability of a fault occurring for each combination of first devices can be calculated using Bayes' theorem.

[0081] After determining the second device combination in the second fault information, a device combination identical to the second device combination is identified from the first device combination as the target device combination. Then, the trigger probability of the target device combination is obtained, and the trigger probability is used as the accuracy of the second fault information.

[0082] For example, the current fault type is "door opening / closing malfunction", while the second fault information records... Figure 2 In the case of combination 16, if the probability of combination 16 causing "abnormal door opening and closing" is calculated in advance using Bayes' theorem, then the accuracy of the second fault information can be determined to be 8%.

[0083] S140: When the accuracy rate is greater than the specified threshold, the fault report is determined to be successfully verified.

[0084] A specified threshold can be preset. When the accuracy rate is greater than the specified threshold, it can be considered that the probability of the equipment combination in the second fault information causing the corresponding fault type is high. The fault report is then determined to be successfully verified, which means that the fault report for this fault is written according to the actual situation.

[0085] In one embodiment, the method further includes the following steps:

[0086] When the accuracy rate is less than the specified threshold, the fault report verification is deemed to have failed.

[0087] When the accuracy rate is less than a specified threshold, it can be considered that the probability of the device combination in the second fault information causing the corresponding fault type is very low. Therefore, the fault report verification can be determined as a failure, meaning that the fault report recording this fault does not reflect the actual fault information and contains fabricated information. This embodiment of the invention can realize real-time review of fault reports and can provide real-time feedback on the review results.

[0088] This invention proposes a method for verifying fault reports. The method includes: obtaining the fault type of the elevator, obtaining first fault information associated with the fault type, obtaining a fault report, extracting second fault information from the fault report, determining the accuracy rate of the second fault information based on the first fault information, and determining that the fault report verification is successful when the accuracy rate is greater than a specified threshold. This achieves automatic review of fault reports, reduces the input of human resources, reduces reliance on human knowledge reserves, and improves review efficiency. By using probability to quantify the authenticity of fault reports, fault reports can be evaluated more intuitively and accurately.

[0089] Example 2

[0090] Figure 3 This is a schematic diagram of a fault report verification device provided in Embodiment 2 of the present invention. The device includes:

[0091] The fault type acquisition module 310 is used to acquire the fault type of the elevator;

[0092] The first fault information acquisition module 320 is used to acquire first fault information associated with the fault type;

[0093] The second fault information extraction module 330 is used to obtain a fault report and extract second fault information from the fault report.

[0094] The accuracy determination module 340 is used to determine the accuracy of the second fault information based on the first fault information;

[0095] The verification success determination module 350 is used to determine that the fault report verification is successful when the accuracy rate is greater than a specified threshold.

[0096] In one embodiment, the first fault information acquisition module 320 includes the following sub-modules:

[0097] The first device name acquisition submodule is used to acquire multiple first device names associated with the fault type;

[0098] The first device combination acquisition submodule is used to combine the device status corresponding to the first device name to obtain multiple first device combinations, wherein the device status is normal and abnormal.

[0099] The first fault information determination submodule is used to combine the obtained first device information as the first fault information.

[0100] In one embodiment, the second fault information extraction module 330 includes the following sub-modules:

[0101] The candidate key statement submodule is used to identify the text in the fault report, segment the text into words, and obtain multiple candidate key statements.

[0102] The similarity determination submodule is used to match the candidate key statements with a plurality of pre-determined sample key statements and determine the similarity between each candidate key statement and each sample key statement.

[0103] The key statement determination submodule is used to determine candidate key statements with a similarity greater than a specified similarity threshold as key statements;

[0104] The sample key statement determination submodule is used to determine the sample key statement with the highest similarity to each of the key statements.

[0105] The second fault information determination submodule is used to determine the second fault information based on the sample key statement with the highest similarity to each of the key statements.

[0106] In one embodiment, the similarity determination submodule is specifically used for:

[0107] Convert the candidate key statements into first word vectors;

[0108] Obtain the second word vector of the key statement in the sample;

[0109] Based on the first word vector and the second word vector, the similarity between each candidate key statement and each sample key statement is determined.

[0110] In one embodiment, the second fault information determining submodule is specifically used for:

[0111] The sample key statement with the highest similarity to each of the aforementioned key statements is identified as the target key statement;

[0112] Extract the second device name and the second device status corresponding to the second device name from the target key statement;

[0113] The second device name and the second device status are combined to form a second device combination, and the second device combination is used as the second fault information.

[0114] In one embodiment, the accuracy determination module 340 includes the following sub-modules:

[0115] The probability determination submodule is used to determine the probability of the first device combination causing the fault corresponding to the fault type based on Bayesian principles.

[0116] The target device combination determination submodule is used to determine, from the first device combination, a device combination that is the same as the second device combination, as the target device combination;

[0117] The accuracy determination submodule is used to obtain the trigger probability of the target device combination and use the trigger probability as the accuracy of the second fault information.

[0118] In one embodiment, the device is further configured to:

[0119] When the accuracy rate is less than a specified threshold, the fault report verification is deemed to have failed.

[0120] The fault report verification device provided in this embodiment of the invention can realize the fault report verification method provided in Embodiment 1 of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0121] Example 3

[0122] Figure 4 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0123] like Figure 4As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0124] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0125] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a fault report verification method.

[0126] In some embodiments, a fault report verification method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the fault report verification method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a fault report verification method by any other suitable means (e.g., by means of firmware).

[0127] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0128] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0129] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0130] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0131] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0132] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0133] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0134] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for verifying fault reports, characterized in that, The method includes: Obtain the elevator's fault type, and obtain multiple first device names associated with the fault type; combine the device states corresponding to the first device names to obtain multiple first device combinations, wherein the device states are normal and abnormal; use the obtained first device combinations as first fault information; A fault report is obtained; the text in the fault report is identified; the text is segmented to obtain multiple candidate key phrases; the candidate key phrases are matched with multiple pre-determined sample key phrases, and the similarity between each candidate key phrase and each sample key phrase is determined; the candidate key phrases with a similarity greater than a specified similarity threshold are determined as key phrases; the sample key phrase with the highest similarity to each key phrase is determined; the sample key phrase with the highest similarity to each key phrase is determined as the target key phrase; a second device name and a second device status corresponding to the second device name are extracted from the target key phrase; the second device name and the second device status are combined to form a second device combination, and the second device combination is used as second fault information. Based on Bayesian principles, the probability of the first device combination triggering the fault corresponding to the fault type is determined; a device combination identical to the second device combination is identified from the first device combination as the target device combination; the triggering probability of the target device combination is obtained, and the triggering probability is used as the accuracy of the second fault information. When the accuracy rate is greater than the specified threshold, the fault report is deemed to have been successfully verified.

2. The method according to claim 1, characterized in that, Determining the similarity between each candidate key statement and each sample key statement includes: Convert the candidate key statements into first word vectors; Obtain the second word vector of the key statement in the sample; Based on the first word vector and the second word vector, the similarity between each candidate key statement and each sample key statement is determined.

3. The method according to claim 1 or 2, characterized in that, The method further includes: When the accuracy rate is less than a specified threshold, the fault report verification is deemed to have failed.

4. A fault report verification device, characterized in that, The device includes: The fault type acquisition module is used to acquire the fault type of the elevator; The first fault information acquisition module is used to acquire first fault information associated with the fault type; The second fault information extraction module is used to obtain a fault report and extract second fault information from the fault report. An accuracy determination module is used to determine the accuracy of the second fault information based on the first fault information; The verification success determination module is used to determine that the fault report verification is successful when the accuracy rate is greater than a specified threshold. The fault report verification device is used to perform a fault report verification method according to any one of claims 1-3.

5. An electronic device, characterized in that, The electronic device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a fault report verification method according to any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement a method for verifying fault reports according to any one of claims 1-3.

Images