Device running state detection method and device, computer device, and storage medium

Abstract

The application relates to a device operation state detection method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring real-time alarm logs of a to-be-detected device, calling a device process model, determining a target library link from candidate library links according to the real-time alarm logs, and determining a device operation state corresponding to the real-time alarm logs from the target library link as the device operation state of the to-be-detected device. The method can determine the operation state of the to-be-detected device according to the real-time alarm data of the to-be-detected device and the candidate library links by using the device process model, realizes automatic detection of the to-be-detected device, further improves the real-time performance, accuracy and efficiency of detection, and reduces the labor cost.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for detecting the operating status of a device. Background Technology

[0002] With the advancement of urbanization in my country, the scale of urban power grids is growing, and the level of informatization of power grid equipment is improving, the amount of power grid information that needs to be processed is also increasing day by day.

[0003] Currently, the detection of the operating status of various devices under test in a substation is usually based on real-time monitoring of the alarm logs of the devices under test by personnel to determine their operating status. Although this method can detect the operating status of the devices under test, it suffers from problems such as incomplete and untimely detection of the operating status of the devices under test, and low detection efficiency due to the limited energy of the monitoring personnel and the large number of devices and complex information in the substation. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, computer-readable storage medium, and computer program product for detecting equipment operating status that can improve the comprehensiveness, accuracy, and efficiency of equipment detection, in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a method for detecting the operating status of a device. The method includes:

[0006] Obtain the real-time alarm logs of the device under test;

[0007] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operation status corresponding to the real-time alarm logs of the target storage link is then determined as the device operation status of the device to be detected.

[0008] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0009] In one embodiment, the device process model is invoked to determine the target warehouse link from the candidate warehouse links based on real-time alarm logs, including:

[0010] The device process model is invoked to determine the currently held token corresponding to the real-time alarm log. Based on the matching relationship between the currently held token and the candidate held token corresponding to the initial state library in the candidate library link, the target library link is determined from the candidate library links.

[0011] In one embodiment, determining the device operating status corresponding to the real-time alarm log from the target library link includes:

[0012] The candidate holding tokens corresponding to the initial state library in the target library link are migrated to the subsequent libraries in the target library link. Based on the candidate holding tokens migrated to the subsequent libraries, the target library is determined from each of the subsequent libraries according to the matching relationship between the real-time alarm logs and the historical alarm logs corresponding to each of the subsequent libraries of the initial state library in the target library link.

[0013] The device operating status corresponding to the target database is used as the device operating status corresponding to the real-time alarm log.

[0014] In one embodiment, the method further includes:

[0015] Obtain the historical alarm logs of the device under test;

[0016] Based on the log type and log generation time of historical alarm logs, historical alarm logs are divided into different device events;

[0017] A candidate library link is generated based on historical alarm logs under the same device event. In one embodiment,

[0018] In one embodiment, a candidate library link is generated based on historical alarm logs under the same device event, including:

[0019] For each device event, generate a candidate holding token for the candidate library link corresponding to the device event, create an initial state library for the candidate library link, and add the candidate holding token to the initial state library.

[0020] Based on the historical alarm logs under each device event, determine the successor repository corresponding to each historical alarm log under the same device event, as well as the order of the successor repository; wherein, each successor repository records the historical alarm log corresponding to the successor repository, the device operating status corresponding to the historical alarm log, and the identifier of the next successor repository.

[0021] Based on the successor repository locations corresponding to each historical alarm log under each device event, and the order in which each successor repository location is arranged, a candidate repository location link corresponding to each device event is generated.

[0022] In one embodiment, the method for determining the device operating status corresponding to historical alarm logs includes:

[0023] Each historical alarm log is segmented to obtain at least two candidate words;

[0024] Based on preset interval words, locate equipment words and operating status words from candidate words;

[0025] Based on the device terminology and operating status terminology, determine the operating status of the device corresponding to the historical alarm log.

[0026] Secondly, this application also provides a device for detecting the operating status of equipment. The device includes:

[0027] The log acquisition module is used to acquire real-time alarm logs of the device under test;

[0028] The status detection module is used to call the device process model, determine the target warehouse link from the candidate warehouse links based on the real-time alarm logs, and determine the device operating status corresponding to the real-time alarm logs of the target warehouse links as the device operating status of the device to be detected; among them, the candidate warehouse links are generated based on the historical alarm logs under different device events.

[0029] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0030] Obtain the real-time alarm logs of the device under test;

[0031] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operation status corresponding to the real-time alarm logs of the target storage link is then determined as the device operation status of the device to be detected.

[0032] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0033] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0034] Obtain the real-time alarm logs of the device under test;

[0035] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operation status corresponding to the real-time alarm logs of the target storage link is then determined as the device operation status of the device to be detected.

[0036] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0037] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0038] Obtain the real-time alarm logs of the device under test;

[0039] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operation status corresponding to the real-time alarm logs of the target storage link is then determined as the device operation status of the device to be detected.

[0040] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0041] The aforementioned equipment operation status detection method, apparatus, computer equipment, and storage medium acquire real-time alarm logs of the device under test, invoke the equipment process model, determine the target storage link from candidate storage links based on the real-time alarm logs, and determine the equipment operation status corresponding to the real-time alarm logs from the target storage link, which is then used as the equipment operation status of the device under test. This application, through the equipment process model, determines the operation status of the device under test based on the real-time alarm data and candidate storage links, achieving automated detection of the device under test, further improving the real-time performance, accuracy, and efficiency of the detection, and reducing labor costs. Attached Figure Description

[0042] Figure 1 This is an application environment diagram of a device operation status detection method provided in this embodiment;

[0043] Figure 2 This is a flowchart illustrating the first device operation status detection method provided in this embodiment;

[0044] Figure 3 This is a schematic diagram of the first method for generating candidate libraries provided in this embodiment;

[0045] Figure 4 This embodiment provides a schematic diagram of a link for generating candidate libraries;

[0046] Figure 5 This is a schematic diagram of the second method for generating candidate libraries provided in this embodiment;

[0047] Figure 6 This is a schematic diagram of a process for determining the operating status of a device, as provided in this embodiment.

[0048] Figure 7 This is a flowchart illustrating the second device operation status detection method provided in this embodiment;

[0049] Figure 8 This is a structural block diagram of the first type of equipment operation status detection device provided in this embodiment;

[0050] Figure 9 This is a structural block diagram of the second type of equipment operation status detection device provided in this embodiment;

[0051] Figure 10 This is a structural block diagram of the third type of equipment operation status detection device provided in this embodiment;

[0052] Figure 11 This is a structural block diagram of the fourth type of equipment operation status detection device provided in this embodiment;

[0053] Figure 12 This is an internal structural diagram of a computer device provided in this embodiment. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0055] The device operating status detection method provided in this application embodiment can be applied to, for example... Figure 1 In the application environment shown, in one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 1 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data such as alarm logs, warehouse links, and device operating status. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a device operating status detection method.

[0056] The aforementioned equipment operation status detection method, device, computer equipment, and storage medium acquire the real-time alarm logs of the device under test, call the device process model, determine the target storage link from the candidate storage links based on the real-time alarm logs, and then determine the equipment operation status corresponding to the real-time alarm logs from the target storage link as the equipment operation status of the device under test.

[0057] In one embodiment, such as Figure 2 As shown, a method for detecting the operating status of a device is provided, which can be applied to... Figure 1 Taking the server in the example, the following steps are included:

[0058] S201 acquires the real-time alarm logs of the device under test.

[0059] The device to be tested can be any device that requires operational status testing. Optionally, the device to be tested can be electrical equipment, mechanical equipment, or conveying equipment, etc. This application does not limit this.

[0060] The alarm log can be a log recording the operating status of the device under test at a certain moment. The alarm log includes the log type, log generation time, log generation device, and log content. Optionally, the real-time alarm log can be an alarm log generated in real time.

[0061] Optionally, the real-time alarm logs of the device under test can be obtained by periodically receiving real-time alarm logs reported by the device under test, or by the server sending an alarm log retrieval command to the device under test. After receiving the alarm log retrieval command, the device under test will retrieve the real-time alarm logs maintained locally and send the real-time alarm logs to the server. The server will receive the real-time alarm logs and use them as the real-time alarm logs of the device under test.

[0062] S202 calls the device process model, determines the target warehouse link from the candidate warehouse links based on the real-time alarm log, and determines the device operating status corresponding to the real-time alarm log from the target warehouse link as the device operating status of the device to be tested.

[0063] The device process model can be a model that parses alarm logs to obtain the device operating status corresponding to the alarm logs. Optionally, the device process model can be a Petri Net (PN) model, which is a mathematical model used to describe distributed systems.

[0064] The candidate database link is generated based on historical alarm logs under different device events and is used to store the different device operating states of the device under different device events. In this embodiment, each time a device experiences a fault until the fault ends can be called a device event, and a device event can be associated with multiple consecutive alarm logs within the corresponding time period.

[0065] Among them, the target library link can be a candidate library link corresponding to the alarm log of the device under test that belongs to the same device event.

[0066] Optionally, the acquired real-time alarm logs of the device under test are input into the invoked device process model. The device process model will search for the target library link corresponding to the real-time alarm log from the candidate library links pre-set in the device process model, and determine the device operating status corresponding to the real-time alarm log based on the target library link. Then, the determined device operating status is used as the device operating status of the device under test.

[0067] Optionally, the method of calling the device process model to determine the target storage location link from candidate storage location links based on real-time alarm logs can be implemented as follows: The device process model is called to determine the currently held token corresponding to the real-time alarm log. Based on the matching relationship between the currently held token and the candidate held tokens corresponding to the initial state storage location in the candidate storage location links, the target storage location link is determined from the candidate storage location links. Here, the token can be an identification code generated based on keywords in the alarm log and pre-set generation rules corresponding to the alarm log. The currently held token can be a token generated based on the real-time alarm log, and the candidate held token can be a token generated based on historical alarm logs under the same device event. The initial storage location can be a database located at the beginning of the storage location link used to store the candidate held tokens corresponding to that storage location link. Specifically, the real-time alarm logs of the device under test are input into the invoked device process model. The device process model generates a current holding token corresponding to the alarm log based on the real-time alarm log and according to the pre-set generation rules. Based on the current holding token and the candidate holding token corresponding to the initial state library in each candidate link, the matching relationship between the current holding token and the candidate holding token is obtained through the pre-set token matching rules. Based on the matching relationship, the candidate library link corresponding to the candidate holding token matched by the current holding token is determined, and the candidate library link is determined as the target library link of the real-time alarm log.

[0068] Optionally, the device operating status corresponding to the real-time alarm log is determined from the target database link. The method for determining the device operating status of the device to be detected can be as follows: Candidate holding tokens corresponding to the initial state database in the target database link are migrated to subsequent databases in the target database link. Based on the migrated candidate holding tokens in the subsequent databases, the target database is determined from each subsequent database according to the matching relationship between the real-time alarm logs and the historical alarm logs corresponding to each subsequent database of the initial state database in the target database link. The device operating status corresponding to the target database is then used as the device operating status corresponding to the real-time alarm log. The subsequent database can be a database configured after the initial state database, used to store alarm logs, the device operating status corresponding to the alarm logs, and the identifier of the next subsequent database.

[0069] Specifically, based on the determined target repository link, the candidate holding token corresponding to the initial state repository in the target repository link is migrated to the successor repository of the initial repository using pre-set transition instructions and the subsequent repository order in the target repository link. Based on the migrated candidate holding token, the real-time alarm log is transferred to the successor repository. Then, based on the real-time alarm log and the historical alarm log corresponding to the successor repository, a pre-set log matching rule is used to determine whether a matching relationship exists between the real-time alarm log and the historical alarm log. If a match exists, the successor repository... The system identifies the target location corresponding to the real-time alarm log and determines the device operating status stored in that target location as the device operating status corresponding to the real-time alarm log. If no such location exists, the candidate holding token is migrated to the next successor location corresponding to that successor location based on the identifier of the next successor location in the subsequent location, and the above operation of determining the matching relationship between the real-time alarm log and the historical alarm log is re-executed. If there is no matching relationship between the real-time alarm log and the historical alarm log in any successor location, the device process model will eventually output abnormal information and feed it back to the monitoring personnel.

[0070] The aforementioned equipment operation status detection method, apparatus, computer equipment, and storage medium acquire real-time alarm logs of the device under test, invoke the equipment process model, determine the target storage link from candidate storage links based on the real-time alarm logs, and determine the equipment operation status corresponding to the real-time alarm logs from the target storage link, which is then used as the equipment operation status of the device under test. This application, through the equipment process model, determines the operation status of the device under test based on the real-time alarm data and candidate storage links, achieving automated detection of the device under test, further improving the real-time performance, accuracy, and efficiency of the detection, and reducing labor costs.

[0071] Figure 3 This is a flowchart illustrating the process of generating candidate library links in one embodiment. The accuracy of the generated candidate library links directly affects the subsequent detection of the operating status of the device under test based on the library links in the device invocation process model. Therefore, to ensure the accuracy of the detection of the operating status of the device under test, this embodiment provides an optional method for generating candidate library links, including the following steps:

[0072] S301 retrieves the historical alarm logs of the device under test.

[0073] Among them, historical alarm logs can be historical alarm logs stored in the device under test.

[0074] Optionally, the server sends a historical alarm log retrieval instruction to the device under test. After receiving the instruction, the device under test retrieves the historical alarm logs within a preset time period maintained locally and sends the historical alarm logs to the server. The server receives the historical alarm logs and uses them as the historical alarm logs of the device under test.

[0075] S302 categorizes historical alarm logs into different device events based on the log type and log generation time.

[0076] The log types include recovery logs and action logs. Recovery logs indicate that the device under test has recovered from an abnormal operating state to a normal operating state, while action logs indicate that the device under test has changed from a normal operating state to an abnormal operating state, meaning that the device under test is currently in an abnormal operating state.

[0077] Optionally, based on the acquired historical alarm logs, the log type, log generation time, and log generation device are parsed from the historical alarm logs. Simultaneously, the first moment when the locally maintained active device set (current_active_equipments) is in an empty set state is recorded. Then, each acquired historical alarm log is sorted according to its log generation time. Based on the sorted order of the historical alarm logs, the type of each historical alarm log is judged. If the log type of the historical alarm log is an action log, the log generation device corresponding to the historical alarm log is added to the active device set. If the historical alarm log is a recurrence log, the log generation device corresponding to the historical alarm log is deleted from the active device set. When the active device set changes from the empty set state corresponding to the first moment to an empty set state again, the second moment of this change is recorded. All historical alarm logs that have undergone judgment processing between the first and second moments are also recorded. These historical alarm logs are divided into the same device event based on the log type and connected according to the order of their generation time to form a set of historical alarm data under the same device event.

[0078] In addition, since the device event classification method cannot completely cover all situations, for the action log of the same device and the same fault, there is no corresponding regression log of the same device and the same fault. This embodiment can further add device event classification rules based on the log generation time. That is, if the time interval between the log generation times of two adjacent historical alarm logs is greater than the preset time interval, the two historical alarm logs will be classified into different device events.

[0079] S303 generates a candidate library link based on historical alarm logs under the same device event.

[0080] Optionally, based on the historical alarm logs under the same device event, an initial state storage location is created, and for each historical alarm log under the same device event, a subsequent storage location corresponding to that historical alarm log is generated. A candidate storage location link is generated based on each generated subsequent storage location.

[0081] The above method for generating candidate storage links obtains the historical alarm logs of the device to be tested. The large amount of historical alarm logs provides a guarantee for generating more comprehensive storage links in the future. Then, based on the log type and log generation time of the historical alarm logs, the historical alarm logs are divided into different device events, which improves the rationality of device event division. Based on the historical alarm logs under the same device event, a candidate storage link is generated, which further improves the rationality of generating candidate storage links.

[0082] Figure 4 This is a flowchart illustrating the process of generating candidate library links in one embodiment. In this embodiment, each device event corresponds to a candidate library link. Based on the above embodiments, this embodiment provides a specific implementation method for generating a candidate library link based on historical alarm logs under a single device event, including the following steps:

[0083] For each device event, S401 generates a candidate holding token for the candidate storage link corresponding to the device event, creates an initial state storage for the candidate storage link, and adds the candidate holding token to the initial state storage.

[0084] Optionally, for each device event, based on any historical alarm log in the device event, a candidate holding token (takon) for the candidate warehouse link corresponding to the device event is generated according to a pre-set generation rule. At the same time, an initial state warehouse of the candidate warehouse link is created, and the candidate holding token is added to the initial state warehouse.

[0085] S402 determines the successor database corresponding to each historical alarm log under the same device event, as well as the order of the successor databases, based on the historical alarm logs under each device event.

[0086] Each successor storage facility records the historical alarm logs corresponding to that facility, the equipment operating status corresponding to the historical alarm logs, and the identifier of the next successor storage facility.

[0087] Optionally, based on each historical alarm log under each device event, the device event corresponding to the historical alarm log is compared with the device event corresponding to each initial state database. The target initial database is determined from each initial state database. At the same time, a subsequent database (place) corresponding to the historical alarm log is created and associated with the target initial database. Then, based on the log generation time of the historical alarm log corresponding to each subsequent database associated with the target initial database, the order of each subsequent database connected to the target initial database is determined.

[0088] S403 generates candidate repository links for each device event based on the successor repository corresponding to each historical alarm log under each device event and the order in which the successor repository is arranged.

[0089] Optionally, based on the successor repository corresponding to each historical alarm log under each device event, and the arrangement order of each successor repository, the successor repository is sorted using the arrangement order of each successor repository. Then, based on each historical alarm log, the device operating status corresponding to that historical alarm log is determined, and each historical alarm log and the device operating status corresponding to that historical alarm log are added to the successor repository corresponding to each historical alarm log. Then, the successor repository identifier of each successor repository is obtained from each successor repository, and the successor repository identifier is added to the previous successor repository corresponding to that successor repository. Finally, based on each sorted successor repository with added historical alarm logs, their corresponding device operating status, and the next successor repository identifier, a candidate repository link corresponding to each device event is generated.

[0090] For example, such as Figure 5 The diagram illustrates a storage location link. Circles represent the initial storage location, diamonds represent candidate holding tokens generated by device events corresponding to that initial storage location, and squares represent subsequent storage locations. Each subsequent storage location stores historical alarm logs, their corresponding device operating status, and the identifier of the next subsequent storage location. Taking subsequent storage location 1 as an example, it stores historical alarm log 1, the device operating status corresponding to historical alarm log 1, and the identifier of subsequent storage location 2. Since subsequent storage location 3 is the last subsequent storage location in this link, and there are no other storage locations after it, it only stores historical alarm log 3 and the device operating status corresponding to historical alarm log 3.

[0091] The above-described method for generating candidate library links generates a candidate holding token for each device event, creates an initial state library for the candidate library link, adds the candidate holding token to the initial state library, determines the successor library corresponding to each historical alarm log under the same device event and the order of the successor libraries based on the historical alarm logs under the same device event, and generates the candidate library link for each device event based on the successor libraries corresponding to each historical alarm log under the same device event and the order of the successor libraries. This method provides a new approach to generating candidate library links, making the determined candidate library links more comprehensive, reasonable, and accurate.

[0092] Optionally, in the process of determining the successor repository corresponding to the historical alarm logs in the above embodiments, the running status of the alarm logs recorded in the successor repository can be determined based on the historical alarm logs. For example... Figure 6 As shown in the figure, this embodiment provides an optional method for determining the running status of alarm logs based on historical alarm logs, including the following steps:

[0093] S601 performs word segmentation on each historical alarm log to obtain at least two candidate words.

[0094] Among them, word segmentation can be a method of dividing the content in historical alarm logs into words.

[0095] Among them, candidate words can be words extracted from historical alarm logs.

[0096] Optionally, each historical alarm log is segmented, and each segmented candidate word is extracted from the segmented historical alarm log, and the segmented candidate words are stored in a JSON file. For example, if the historical alarm log is "Ping'an Station Qianping Line 2891 Switch A Phase Closed", then the candidate words obtained are "Ping'an Station", "Qianping Line 2891", "Switch", "A Phase", and "Closed".

[0097] S602 locates device terms and operating status terms from candidate terms based on preset interval words.

[0098] The interval word can be a pre-set word that includes the behavior of the equipment. For example, if the equipment to be tested is substation equipment, the interval word can be a fixed verb word such as "closing", "opening", "segmented protection", or "overcurrent protection".

[0099] Among them, device terms can be the names of the devices that correspond to the historical alarm logs.

[0100] Among them, the operational status terms can be terms that represent the operational status of the devices corresponding to the historical alarm logs.

[0101] Optionally, an interval word is found from multiple candidate words obtained through a pre-set interval vocabulary list (stop_list), and this word is used as the dividing line between device vocabulary and operation status vocabulary. That is, at least one word before the interval word belongs to device vocabulary, and at least one word after the interval word belongs to operation status vocabulary. The determined device vocabulary and operation status vocabulary are stored in a pre-set CSV file to make its format closer to the alarm information log format.

[0102] Preferably, for situations where multiple equipment systems exist, and different equipment systems may contain devices with the same device name, this implementation further categorizes the system names of the devices to determine the faulty device, its operating status, and the equipment system to which it belongs. This allows monitoring personnel to quickly identify the equipment system to which the faulty device belongs and the nature of the fault. Specifically, based on the identified candidate words, system name words are extracted from these candidate words using pre-set system name extraction rules. Then, using the remaining candidate words, a pre-set stop list is used to find stop words from these remaining candidate words. These stop words are then used as the boundary between device words and operating status words to further determine the device words and operating status words. Finally, the system name words, device words, and operating status words from the candidate words are obtained. For example, the historical alarm log is "Ping'an Station Qianping Line 2891 Switch A Phase Closed". The candidate words are "Ping'an Station", "Qianping Line 2891", "Switch", "A Phase" and "Closed". Among them, the system name word is "Ping'an Station" and the interval word is "Closed". Then, the remaining candidate words other than the system name word are "Qianping Line 2891", "Switch", "A Phase" and "Closed". The candidate words before the interval word are "Qianping Line 2891", "Switch" and "A Phase". Therefore, "Qianping Line 2891", "Switch" and "A Phase" are equipment words, and "Closed" is the operating status word.

[0103] S603 determines the device operating status corresponding to the historical alarm log based on device terminology and operating status terminology.

[0104] Optionally, based on the determined device vocabulary, the normal operation status vocabulary (i.e., the operation status vocabulary corresponding to the normal operation of the device) is retrieved from the pre-set device operation status vocabulary table, and the normal operation status vocabulary is compared with the determined operation status vocabulary. If they are consistent, the device operation status in the historical alarm log corresponding to the operation status vocabulary is determined to be normal operation status. If they are inconsistent, the device operation status in the historical alarm log corresponding to the operation status vocabulary is determined to be abnormal operation status.

[0105] The above-mentioned method for determining the operating status of equipment involves segmenting each historical alarm log to obtain at least two candidate words. Based on preset interval words, equipment words and operating status words are located from the candidate words, which can improve the accuracy and comprehensiveness of the identification of equipment words and operating status words. Then, based on the equipment words and operating status words, the operating status of the equipment corresponding to the historical alarm log is determined, which further improves the accuracy of determining the operating status of the equipment corresponding to the historical alarm log.

[0106] In one embodiment, this embodiment provides an optional method for detecting device operating status, using the application of this method to a server as an example for illustration. For example... Figure 7 As shown, the method includes the following steps:

[0107] S701 retrieves the historical alarm logs of the device under test.

[0108] Based on the log type and log generation time, the S702 classifies historical alarm logs into different device events.

[0109] For each device event, S703 generates a candidate holding token for the candidate storage link corresponding to the device event, creates an initial state storage for the candidate storage link, and adds the candidate holding token to the initial state storage.

[0110] S704 determines the successor database for each historical alarm log under the same device event, as well as the order in which the successor databases are arranged, based on the historical alarm logs under each device event.

[0111] S705 generates candidate repository links for each device event based on the successor repository locations corresponding to each historical alarm log under each device event and the order in which the successor repository locations are arranged.

[0112] S706 acquires the real-time alarm logs of the device under test.

[0113] S707 calls the device process model to determine the currently held token corresponding to the real-time alarm log. Based on the matching relationship between the currently held token and the candidate held token corresponding to the initial state library in the candidate library link, the target library link is determined from the candidate library links.

[0114] S708 migrates the candidate holding tokens corresponding to the initial state library in the target library link to the subsequent library in the target library link, and based on the candidate holding tokens migrated to the subsequent library, determines the target library from each subsequent library according to the matching relationship between the real-time alarm log and the historical alarm logs corresponding to each subsequent library of the initial state library in the target library link.

[0115] S709 uses the device operating status corresponding to the target library as the device operating status corresponding to the real-time alarm log.

[0116] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0117] Based on the same inventive concept, this application also provides a device for detecting the operating status of equipment to implement the aforementioned device operating status detection method. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more device operating status detection embodiments provided below can be found in the limitations of the device operating status detection method described above, and will not be repeated here.

[0118] In one embodiment, such as Figure 8 As shown, a device for detecting the operating status of an equipment is provided, comprising: a log acquisition module and a status detection module, wherein:

[0119] Log acquisition module 10 is used to acquire real-time alarm logs of the device under test.

[0120] The status detection module 11 is used to invoke the device process model, determine the target storage link from the candidate storage links based on the real-time alarm logs, and determine the device operating status corresponding to the real-time alarm logs of the target storage link as the device operating status of the device to be detected. The candidate storage links are generated based on historical alarm logs under different device events.

[0121] In one embodiment, such as Figure 9 As shown, Figure 8 The status detection module 11 includes: a target link determination unit 110 and a running status determination unit 111, wherein:

[0122] The target link determination unit 110 is used to call the device process model, determine the currently held token corresponding to the real-time alarm log, and determine the target library link from the candidate library links based on the matching relationship between the currently held token and the candidate held token corresponding to the initial state library in the candidate library links.

[0123] The operation status determination unit 111 is used to migrate the candidate holding tokens corresponding to the initial state library in the target library link to the subsequent library in the target library link, and based on the candidate holding tokens migrated to the subsequent library, determine the target library from each subsequent library according to the matching relationship between the real-time alarm log and the historical alarm logs corresponding to each subsequent library of the initial state library in the target library link; and use the device operation status corresponding to the target library as the device operation status corresponding to the real-time alarm log.

[0124] In one embodiment, such as Figure 10 As shown, Figure 8 The equipment operation status detection device 1 includes:

[0125] The historical log acquisition module 12 is used to acquire the historical alarm logs of the device under test.

[0126] The event segmentation module 13 is used to segment historical alarm logs into different device events based on the log type and log generation time of the historical alarm logs.

[0127] The link generation module 14 is used to generate a candidate library link based on the historical alarm logs under the same device event.

[0128] In one embodiment, such as Figure 11 As shown, Figure 10 The link generation module 14 in the middle includes:

[0129] The initial storage creation unit 140 is used to generate a candidate holding token for the candidate storage link corresponding to each device event, create an initial state storage for the candidate storage link, and add the candidate holding token to the initial state storage.

[0130] The subsequent storage location determination unit 141 is used to determine the subsequent storage location corresponding to each historical alarm log under the same device event, as well as the order of the subsequent storage locations, based on each historical alarm log under each device event. Each subsequent storage location records the historical alarm log corresponding to that subsequent storage location, the device operating status corresponding to the historical alarm log, and the identifier of the next subsequent storage location.

[0131] The link generation unit 142 is used to generate candidate library links corresponding to each device event based on the successor library locations corresponding to each historical alarm log under each device event and the order of the successor library locations.

[0132] In one embodiment, Figure 11 The subsequent library determined unit 151 includes:

[0133] The candidate word determination subunit is used to perform word segmentation on each historical alarm log to obtain at least two candidate words.

[0134] The target vocabulary determination sub-unit is used to locate equipment vocabulary and operating status vocabulary from candidate vocabulary based on preset interval words.

[0135] The operating status determination subunit is used to determine the operating status of the device corresponding to the historical alarm log based on the device terminology and operating status terminology.

[0136] Each module in the aforementioned equipment operation status detection device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0137] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 12 As shown. The computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a method for detecting the device's operating status. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0138] Those skilled in the art will understand that Figure 12 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0139] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0140] Obtain the real-time alarm logs of the device under test.

[0141] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operating status corresponding to the real-time alarm logs of the target storage link is then determined as the device operating status of the device to be detected.

[0142] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0143] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0144] The device process model is invoked to determine the currently held token corresponding to the real-time alarm log. Based on the matching relationship between the currently held token and the candidate held token corresponding to the initial state library in the candidate library link, the target library link is determined from the candidate library links.

[0145] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0146] The candidate holding tokens corresponding to the initial state library in the target library link are migrated to the subsequent libraries in the target library link. Based on the candidate holding tokens migrated to the subsequent libraries, the target library is determined from each subsequent library according to the matching relationship between the real-time alarm log and the historical alarm logs corresponding to each subsequent library of the initial state library in the target library link.

[0147] The device operating status corresponding to the target database is used as the device operating status corresponding to the real-time alarm log.

[0148] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0149] Obtain the historical alarm logs of the device under test.

[0150] Based on the log type and log generation time of historical alarm logs, historical alarm logs are divided into different device events.

[0151] A candidate library link is generated based on the historical alarm logs of the same device event.

[0152] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0153] For each device event, generate a candidate holding token for the candidate library link corresponding to the device event, create an initial state library for the candidate library link, and add the candidate holding token to the initial state library.

[0154] Based on the historical alarm logs under each device event, determine the successor database corresponding to each historical alarm log under the same device event, as well as the order of the successor databases. Each successor database records the historical alarm log corresponding to that successor database, the device operating status corresponding to the historical alarm log, and the identifier of the next successor database for that successor database.

[0155] Based on the successor repository locations corresponding to each historical alarm log under each device event, and the order in which each successor repository location is arranged, a candidate repository location link corresponding to each device event is generated.

[0156] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0157] Each historical alarm log is segmented to obtain at least two candidate words.

[0158] Based on preset interval words, equipment words and operating status words are located from candidate words.

[0159] Based on the device terminology and operating status terminology, determine the operating status of the device corresponding to the historical alarm log.

[0160] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0161] Obtain the real-time alarm logs of the device under test.

[0162] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operating status corresponding to the real-time alarm logs of the target storage link is then determined as the device operating status of the device to be detected.

[0163] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0164] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0165] Obtain the real-time alarm logs of the device under test.

[0166] The device process model is invoked, and the target storage link is determined from the candidate storage links based on the real-time alarm logs. The device operating status corresponding to the real-time alarm logs of the target storage link is then determined as the device operating status of the device to be detected.

[0167] Among them, the candidate library link is generated based on historical alarm logs under different device events.

[0168] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0169] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0170] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for detecting the operating status of equipment, characterized in that, The method includes: Obtain the real-time alarm logs of the device under test; The device process model is invoked to determine the currently held token corresponding to the real-time alarm log. Based on the matching relationship between the currently held token and the candidate held token corresponding to the initial state library in the candidate library link, the target library link is determined from the candidate library link. The candidate holding tokens corresponding to the initial state library in the target library link are migrated to the subsequent libraries in the target library link. Based on the candidate holding tokens migrated to the subsequent libraries, the target library is determined from each of the subsequent libraries according to the matching relationship between the real-time alarm logs and the historical alarm logs corresponding to each of the subsequent libraries of the initial state library in the target library link. The device operating status corresponding to the target library is used as the device operating status corresponding to the real-time alarm log; The candidate library link is generated based on historical alarm logs under different device events.

2. The method according to claim 1, characterized in that, The currently held token is a token generated based on real-time alarm logs; The token is an identification code generated based on keywords in the alarm log and pre-set generation rules, corresponding to the alarm log.

3. The method according to claim 1, characterized in that, The successor repository is configured after the initial repository and is used to store alarm logs, the operating status of the devices corresponding to the alarm logs, and the identifier of the next successor repository.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: Obtain the historical alarm logs of the device under test; Based on the log type and log generation time of the historical alarm logs, the historical alarm logs are divided into different device events; A candidate library link is generated based on the historical alarm logs of the same device event.

5. The method according to claim 4, characterized in that, The step of generating a candidate library link based on historical alarm logs under the same device event includes: For each device event, generate a candidate holding token for the candidate library link corresponding to the device event, create an initial state library for the candidate library link, and add the candidate holding token to the initial state library; Based on the historical alarm logs under each device event, determine the successor repository corresponding to each historical alarm log under the same device event, as well as the order of the successor repository; wherein, each successor repository records the historical alarm log corresponding to the successor repository, the device operating status corresponding to the historical alarm log, and the identifier of the next successor repository. Based on the successor repository locations corresponding to each historical alarm log under each device event, and the order in which each successor repository location is arranged, a candidate repository location link corresponding to each device event is generated.

6. The method according to claim 5, characterized in that, The method for determining the device operating status corresponding to the historical alarm logs includes: Each historical alarm log is segmented to obtain at least two candidate words; Based on preset interval words, device words and operating status words are located from the candidate words; Based on the device vocabulary and interval words, determine the device operating status corresponding to the historical alarm log.

7. A device for detecting the operating status of equipment, characterized in that, The device includes: The log acquisition module is used to acquire real-time alarm logs of the device under test; The status detection module is used to invoke the device process model, determine the currently held token corresponding to the real-time alarm log, and determine the target library link from the candidate library links based on the matching relationship between the currently held token and the candidate held token corresponding to the initial state library in the candidate library link; migrate the candidate held token corresponding to the initial state library in the target library link to the subsequent library of the target library link, and determine the target library from each subsequent library based on the candidate held token migrated to the subsequent library according to the matching relationship between the real-time alarm log and the historical alarm logs corresponding to each subsequent library of the initial state library in the target library link; and use the device operating status corresponding to the target library as the device operating status corresponding to the real-time alarm log; wherein, the candidate library links are generated based on historical alarm logs under different device events.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images