JP6280862B2 - Event analysis system and method - Google Patents

Description

  The present invention relates to an event analysis system and an event analysis method in social infrastructure systems such as railways and electric power, maintenance of facilities thereof, response to failures, and the like.

  In recent years, social infrastructures are becoming larger and more complex, such as the introduction of railways and power interchange, and problems such as increased costs for failure handling and maintenance, and lack of skilled workers are becoming problems. Moreover, as a result of the generalization of systems related to social infrastructure being connected to public communication networks such as the Internet, new threats such as cyber attacks are also born. Against this background, in addition to failure analysis in units of components such as turbines that have been developed and put to practical use in the past, system levels such as failures caused by computers controlling components and failures that can be analyzed from data output by computers There is a need to expedite the response to various obstacles.

  In general, computers do not use time-series numerical data that is measured regularly, such as sensor values that measure the state of social infrastructure, but OS / middleware warnings and errors that occur irregularly, and command execution results. Alternatively, time-series character string data relating to application internal state transitions and operation history, so-called logs, occupies most of the analysis target.

  In order to deal with a system level failure, Patent Document 1 defines in advance the cause of occurrence of an event such as a failure, models the transition between the occurrence causes with a finite automaton, and has the highest probability of the observed event generation. A technique for outputting a state transition of an occurrence cause is disclosed. As a result, it is possible to present to the user cause analysis using the occurrence process of the defined occurrence cause and prediction of future event occurrence.

JP 2011-175504 A

  However, in order to apply the technique described in Patent Document 1, it is necessary for the device developer to appropriately define the cause of the event in advance. However, in a system in which multiple computers are connected to multiple components (elements that make up social infrastructure such as devices and equipment), the event (such as the cause of a failure that occurred in one computer is caused by other components on the network) There are a large number of candidates for the causes of system conditions such as failures, and it is difficult to define all of them in advance. Therefore, not only the cause of occurrence of an event cannot be specified, but also an event for which the cause of occurrence cannot be specified may be determined to have occurred from another cause of occurrence, so that the accuracy of estimating the cause of occurrence may be deteriorated.

  On the other hand, although the cause of occurrence is properly defined, there are situations where the event corresponding to the cause of the occurrence cannot actually be observed. For example, although a log is output, an event cannot be observed when the output log is discarded due to disk storage capacity or network resource restrictions. In such a case, the event corresponding to the cause of occurrence that is opposite to the above cannot be observed, so other events will be associated, and even if the cause of the analysis is analyzed, it may not be possible to correctly interpret the event that occurs. is there.

  In such a situation, the time and cost required for failure detection and analysis, etc., related to the start and repair of the system become large. Therefore, there is a need for an event analysis system and method that does not require a predefined cause of failure in the monitored system.

  The disclosed event analysis system includes a local prediction model learning process that learns in advance a local prediction model that predicts a first event based on a first event sequence during operation of the monitored system, and a second event sequence of the monitored system To detect a second event in which the observation result of the second event included in the monitored second event sequence does not match the prediction result of the first event predicted using the local prediction model In response to the detection process and the extraction of the second event, the third event occurred immediately before the second event, which is included in the monitored second event sequence and produces the observation result, is started. A failure analysis support process for creating a traced first event graph;

  According to the disclosed event analysis system, it is possible to analyze events corresponding to the occurrence of abnormalities in the monitored system using a local prediction model based on events from the monitored system. Renovation time and cost can be reduced.

It is a block diagram of an event analysis system. It is an example of an event sequence. It is an example of a local prediction model parameter. It is an example of model prediction accuracy data. It is an example of event graph data. It is an example of a node event. It is an example of case data. It is an example of feature function definition. It is a processing flowchart of a local prediction model learning process. It is a processing flowchart of learning of a local prediction model. It is a processing flowchart of a failure analysis support process. It is a processing flowchart of creation of an event graph. It is a processing flowchart of a case registration process. It is a processing flowchart of a case presentation process. It is an example of an event graph display screen. It is an example of a case data display screen.

  In this embodiment, an event (monitoring target system) for fault detection, response support, and case presentation based on a log output during operation of a social infrastructure system (referred to as a monitoring target system) such as railways and electric power It is an example of the system which analyzes (state of). Prior to detailed description, an outline of the event analysis system of this embodiment will be described.

  The event analysis system has three functions (processes): model learning, failure analysis support, and case presentation. Model learning learns a local prediction model that locally predicts a change in an event from an event sequence obtained by collecting and analyzing a normal log from a monitored system.

  The failure analysis support detects an abnormal state of the monitored system, analyzes the process leading to the abnormal state, and presents the analysis result to maintenance personnel and engineers. Specifically, the failure analysis is supported as follows. The event analysis system predicts a change in an event using a local prediction model, and monitors the deviation (presence / absence of coincidence) between the prediction result and the observed event. If there is a divergence (mismatch), the event analysis system determines that the observed event is a failure and extracts it. This judgment is based on the state transition of general monitoring target systems such as social infrastructure, and the state transition process is the same even if the timing is different. Based on the high probability. Next, an event graph is generated by tracing back events (back tracing) starting from the event that occurred immediately before the extracted event, extracting related events, and concatenating the extracted events. Then, this event graph is presented to maintenance personnel and engineers corresponding to the failure. Since this event graph is a concatenation of events that are likely to have contributed to the occurrence of a failure, it is useful for maintenance personnel and engineers to grasp the flow leading to the occurrence of the failure and discover the root cause.

  Case presentation searches for case data related to failure causes and countermeasures registered in advance by maintenance personnel and engineers using the event graph generated by failure analysis support that can lead to failure occurrence as a key. Based on the above, present countermeasures for obstacles. When a maintenance staff or engineer registers case data, an event related to the case data is designated. The event analysis system generates an event graph from the specified event and registers it in association with the case data. In addition, the event analysis system generates an event graph based on the event extracted from the monitored system, and monitors the similarity with the registered event graph. When the event analysis system finds a similar event graph, it presents case data corresponding to the generated event graph to maintenance personnel and engineers. That is, using the event graph as a key of the case data, the case data is searched based on the event graph generated when the monitored system is operating, and the searched case data is presented in correspondence with the generated event graph. As a result, if the failure is similar to the known failure, the maintenance staff and the engineer can take measures without taking time for analysis.

  FIG. 1 is a configuration diagram of an event analysis system. The event analysis system includes an event monitoring device 2 that monitors an event of the monitoring target system 1, an analysis computer 3, and an operation terminal 4. The monitoring target system 1 and the event monitoring apparatus 2 are connected via a control network 14 such as a control LAN (Local Area Network) in the monitoring target system 1. The event monitoring device 2, the analysis computer 3, and the operation terminal 4 are connected via a network 5 such as the Internet or a private network.

  As shown in FIG. 1, in a typical event analysis system, the event monitoring device 2 is placed at a local site where the monitoring target system 1 is installed, and the analysis computer 3 is installed at a data center or the like. On the other hand, the operation terminal 4 is installed at both the local site and the maintenance base for use by maintenance personnel at the local site and engineers at the maintenance base. These configurations and arrangements are merely examples, and all of them can be placed on the local site, and are consolidated at the maintenance base except for some functions (collection analysis unit, transfer unit) of the event monitoring device 2 described later. It is also possible. Further, in the case of a system in which the event monitoring device 2, the analysis computer 3, and the operation terminal 4 are not connected via a network, parameters of events and local prediction models (described later) via a storage medium such as a USB (Universal Serial Bus) memory. ) May be used.

  The monitoring target system 1 is a variety of systems, and the forms thereof are also various. The equipment 11 having sensors and actuators, the controller 12 that monitors the state of the equipment 11 through the sensors, and controls the equipment 11, and A control computer 13 that controls the controller 12 is provided, and these are connected via a control network 14. Note that the illustrated components are examples, and the number of elements such as equipment 11 may be increased or decreased, and even though they are connected by a single control network 14, they are connected by a hierarchical control network 14. May be.

  The configuration of each apparatus will be described with reference to FIG. The event monitoring device 2 is a computer that includes the processing units of the collection analysis unit 21, the abnormality detection unit 22, and the case search unit 23, and the storage units of the short-term event storage unit 24 and the parameter storage unit 25.

  The collection analysis unit 21 collects logs from the controller 12 of the monitoring target system 1, the control computer 13, and the control network 14 (network device for log output), analyzes the collected logs, and generates a time-series event sequence. It is generated and transmitted to the computer 3 for analysis. The abnormality detection unit 22 detects an abnormal state of the monitoring target system 1 based on the parameters of the local prediction model received from the analysis computer 3. The case search unit 23 searches for case data corresponding to the event graph received from the analysis computer 3. The short-term event storage unit 24 stores events. The short-term event storage unit 24 is a buffer that temporarily stores events until they are transmitted to the analysis computer 3. The parameter storage unit 25 stores parameters of the local prediction model, case data, and the like.

  The analyzing computer 3 includes processing units such as a model learning unit 31, an event graph creation unit 32, and an operation management unit 33, and storage units such as an event storage unit 34, a model storage unit 35, and a case storage unit 36. It is a computer.

  The model learning unit 31 generates a local prediction model when the monitoring target system 1 is normal from the event sequence generated by the event monitoring device 2. The event graph creation unit 32 goes back (back traces) from the event that is the starting point, and the occurrence of an event indicating the abnormal state of the monitored system 1 until the occurrence of the abnormal state on the local prediction model of the monitored system 1. An event graph is created by extracting events that contribute to the occurrence and concatenating the extracted events. The operation management unit 33 creates display information on the operation terminal 4 and registers case data from the operation terminal 4.

  The event storage unit 34 stores events received from the event monitoring device 2. The model storage unit 35 stores parameters of the local prediction model. The case storage unit 36 stores case data and an event graph corresponding to the case data.

  The operation terminal 4 inputs display information generated by the analysis computer 3 and case data.

  The arrangement of each processing unit and each storage unit described above is an example, and may be arranged on another device or a plurality of devices. For example, the abnormality detection unit 22 may be in the analysis computer 3, and the event graph creation unit 32 may be arranged in the event monitoring device 2.

  FIG. 2 is an example of an event sequence 100 (also referred to as an event sequence when there is one event) stored in the short-term event storage unit 24 and the event storage unit 34. The event string 100 is obtained by analyzing a log collected from the monitoring target system 1 and includes a site ID 101, a time 102, an event ID 103, and detailed data 104. The site ID 101 and the event ID 103 are identifiers for identifying the local site and the event, respectively. FIG. 2 shows “2014/9/21 12: 23: 14.1034 SEND TYPE = xxx DATA = yyy” in the detailed data 104 as an example of the communication log of the communication middleware at a certain local site Site1. In the case of a log that generates such an event sequence 100, the event sequence 100 stores Site1 in the site ID 101, stores the time portion included in the log (the time portion of the detailed data 104) at the time 102, and “device name Predetermined identifier corresponding to “Communication middleware name.Log name.SEND” is stored in the event ID 102, and the entire log or a part of the character string of the log with unnecessary portions deleted is stored in the detailed data 104. Store.

  In this way, a series of events (records in FIG. 2) in time series is an event string. As described above, even when there is one event, it is called an event string. The short-term event storage unit 24 stores local site events, but the event storage unit 34 stores all local site events connected to the analysis computer 3.

  FIG. 3 is an example of the local prediction model parameter 200 stored in the parameter storage unit 25 and the model storage unit 35. As will be described in detail later, a logistic regression model (logarithmic linear model in the case of binary) is used as a local prediction model for events. For this reason, a weight vector for an event feature (described later with reference to FIG. 8) is a parameter of the local prediction model. The local prediction model parameter 200 includes a site ID 201, an event ID 202, a feature ID 203, and a weight 204. The site ID 201 and the event ID 202 are identifiers for identifying the local site and the event, respectively, and the feature ID 203 is an identifier for identifying the feature of the event corresponding to the local prediction model. The local prediction model is specified by a pair of site ID 201 and event ID 202.

  When other models are used, the parameters are changed as appropriate. The parameter storage unit 24 stores parameters related to its own site, while the model storage unit 35 stores parameters of all local sites connected to the analysis computer.

  FIG. 4 is an example of model prediction accuracy data 300 stored in the model storage unit 35. The model prediction accuracy data 300 includes a site ID 301, an event ID 302, and a prediction accuracy 303. The site ID 301 and the event ID 302 are identifiers for identifying the local site and the event, respectively. Although details will be described later, the prediction accuracy 303 represents the prediction accuracy of the local prediction model calculated from the event sequence.

  FIG. 5 is an example of event graph data 400 stored in the parameter storage unit 25 and the case storage unit 36. The event graph data 400 is edge information of an event graph that represents an event generation process, and includes a graph ID 401, a parent node ID 402, a child node ID 403, a connection type 404, and a weight 405. A graph ID 401 is an identifier for identifying an event graph. The parent node ID 402 and the child node ID 403 are identifiers for identifying the node, and the occurrence of the event is backtraced. Therefore, the event of the child node ID 403 means that the event of the parent node ID 402 is generated. Each child node ID 403 is defined by a node event 500 in FIG. The connection type 404 is set based on the edge derivation process (state transition from the event of the child node ID 403 to the event of the parent node ID 402). The weight 405 is used for prediction of the local prediction model. Details of the event graph data 400 will be described later in the explanation of the operation of the event analysis system.

  FIG. 6 is an example of a node event 500 that is a node of an event graph stored in the parameter storage unit 25 and the case storage unit 36. The node event 500 is data indicating the correspondence between the event graph node and the event, and includes a node ID 501, a site ID 502, a time 503, and an event ID 504. The node ID 501 corresponds to the parent node ID 402 or child node ID 403 of the event graph 400, and the site ID 502, time 503, and event ID 504 correspond to the site ID 101, time 102, and event ID 103 of the event sequence 100.

  FIG. 7 is an example of the case data 600 stored in the parameter storage unit 25 and the case storage unit 36. The case data 600 is data that a maintenance staff or engineer inputs via the operation terminal 4 after finding, analyzing, and taking measures for the trouble, that is, regarding the trouble that has occurred. The case ID 601, the site ID 602, the graph ID 603, and the content data 604. including. The case ID 601, the site ID 602, and the graph ID 603 are identifiers for identifying the case data, the local site, and the event graph, respectively. Case data is specified by a pair of case ID 601 and site ID 602. The content data 604 is data input by maintenance personnel or engineers. Typically, “[Status] The process of machine 2 ends abnormally, [Cause] The performance of the added machine exceeds the HUB performance, packet loss, [Countermeasure] Change the HUB to the latest version ", information about the situation, cause, and countermeasure are entered. Note that the format including this input item is appropriately changed according to the target system. Since the graph ID 603 represents an event graph corresponding to the content data 604, the event graph of the monitoring target system 1 in operation (corresponding to the event graph identified by the graph ID 603) is set using the event graph identified by the graph ID 603 as a key. Case data is retrieved from the event sequence leading to the failure to be performed).

  FIG. 8 shows an example of the feature function definition 700 stored in the model storage unit 35. The feature function definition 700 is feature function definition data for generating a feature quantity to be input to the local prediction model, and includes a feature ID 701 and a feature function definition 702. The feature ID 701 is an identifier for identifying the definition of the feature function definition 702.

  In the present embodiment, the occurrence of a specific event or the generation order or generation timing of a specific event sequence is used as a feature amount. In general, a feature function is a function that returns a numerical value (1 or 0) for an event sequence as an argument (or input), and other definitions than those described above, for example, not only the occurrence of a composite event or event ID, It is possible to define a function that takes into account specific keywords included in the detailed data of the event.

  Hereinafter, the processing of each process will be described by the cooperation of the event monitoring device 2 and the analysis computer 3, but in order to simplify the description, the processing for storing each data of FIGS. Not done.

  FIG. 9 is a process flowchart of the local prediction model learning process. The process of the local prediction model learning process is executed by cooperation of the collection analysis unit 21 and the model learning unit 31.

  The collection analysis unit 21 collects logs, which are time-series character string data related to OS and middleware warnings and errors, command execution results, application internal state transitions, operation history, and the like, from the monitored system 1 (S101). . The collection analysis unit 21 analyzes the collected log, associates it with the site ID 101 of its own site, and sets the time 102, event ID 103, and detailed data 104 according to the contents of the log (in the case of an alarm, the error level and its ID). Is extracted and stored in the short-term event storage unit 24 (S102). Note that the event sequence 100 stored in the short-term event storage unit 24 is deleted when transmission to the analysis computer 3 is completed (storage completed in the event storage unit 34).

  The model learning unit 31 collects the event sequence 100 from the short-term event storage unit 24 of the event monitoring apparatus periodically (such as once a day) and stores it in the event storage unit 34 (S103). The model learning unit 31 learns a local prediction model for locally predicting a change in an event using the normal event sequence 100 of the monitoring target system 1, creates a local prediction model parameter 200, and creates the created local prediction The model parameter 200 is stored in the model storage unit 35 (S104). This process will be described later.

  The model learning unit 31 calculates the prediction accuracy of the local prediction model created using cross-validation or the like, creates model prediction accuracy data 300, and stores it in the model storage unit 35 (S105). The model learning unit 31 transmits the created local prediction model parameter 200 and model prediction accuracy data 300 to the event monitoring device 2. The event monitoring device 2 stores the received local prediction model parameter 200 and model prediction accuracy data 300 in the parameter storage unit 25, and ends the process (S106).

  In addition, although the example which learns a model from the event sequence at the time of the operation (normal time) of the monitoring target system 1 was described, actually, it is collected by the pre-shipment test of the monitoring target system 1 or on-site test operation after shipping. Learning may be performed using the event sequence.

  FIG. 10 is a processing flowchart of local prediction model learning (S104) by the model learning unit 31. Here, logistic regression with L1 regularization is used as the local prediction model. Prior to the explanation, the definition will be explained.

  The event set E corresponds to the event sequence 100 and is described as E = {E_i, t | i = 1,2,3,..., I, t = 1,2,3,. Here, E_i, t is an element of the event set, i indicates a pair of the site ID 101 and the event ID 103 (hereinafter, the event ID 103 is represented as “event ID is i”, etc.), and t Indicates time 102. When an event with an event ID i does not occur at time t, the value Empty is associated with E_i, t. If not (if it has occurred), E_i, t is associated with the record of the event string 100 corresponding to the site ID 101, the event ID 103, and the time 102.

  Let E [ts: te] = {E_i, t | i = 1,2,3,…, I, t = ts,…, te} as a subset of events from one time ts to another time te-1 Describe.

  The event change C (i, t) represents a discrete time like K time (tK: t-1, t-2, etc.), where E_i, t is not Empty. The function that returns 1 if the event ID is not the same as the latest event E_i, t 'among non-Empty events that occurred up to this point, and 0 otherwise. Here, K is a constant defined in advance, and in this embodiment, it is set to twice the average occurrence interval of E_i for each event ID. However, other values such as a constant such as 3 minutes may be used.

  A feature vector Φ (E ([ts: te])) represents a feature in E [ts: te], and Φ (E [ts: te]) = [φ_1 (E ([ts: te])), ... , φ_k (E ([ts: te])), ..., φ_K (E ([ts: te]))]. Here, φ_k (•) is a feature quantity function, and φ_k (E [ts: te]) represents the kth feature quantity of E [ts: te].

  The weight vector W_i is a weight vector of the local prediction model whose event ID is i, and is described as W_i = [W_i, 0, W_i, 1,..., W_i, K].

  The process of learning the local prediction model will be described according to the above definition. The model learning unit 31 assigns 0 to the counter cnt of the number of learning times, and sets a random number for each W_i (S201). The model learning unit 31 randomly sets a value from 1 to T in the time variable t (S102). The model learning unit 31 calculates a feature quantity Φ ([E [t−τ, t]). Here, τ is a constant, and is an average occurrence interval of E_i for each event ID (S203). The model learning unit 31 substitutes 0 for the variable i corresponding to the event ID (S204).

  The model learning unit 31 is a local prediction model of the event i expressed as a logistic regression model with L1 regularization, where the input is a feature quantity Φ ([E [t−τ, t]) and the output is C (i, t). The weight vector W_i is updated (S205). Here, in order to generate the feature quantity Φ ([E [t−τ, t]), the definition 702 of the feature function φ_k registered in the feature function definition 700 is used. Specifically, for example, a feature based on the relationship of a single event such as 1 if an event with an event ID occurs, 0 otherwise, or within 2 seconds after an event with an event ID occurs A feature based on the order relation between a plurality of events such as 1 if an event with another event ID occurs, and 0 otherwise. For updating the weight vector W_i, Forward Backward Splitting is used in which the final weight vector is determined by optimizing the weight vector updated by the gradient method or the subgradient method and the regularization term. Thereby, a sparse weight vector W_i can be obtained.

  The model learning unit 31 increments the variable i by 1 (S206). The model learning unit 31 determines whether S205 to S206 have been executed for all i, and if executed, moves to S208, otherwise returns to S205 (S207).

  In S207, when all i are executed, the model learning unit 31 increments the counter cnt by 1 (S208). The model learning unit 31 determines whether cnt is less than a predetermined number N. If it is less, the process returns to S202, and if not (or more), the process ends (S209).

  The described local prediction model does not need to deal with an explicit causal relationship or cause of an event, and the model learning unit 31 uses an event sequence acquired from the monitoring target system 1 via the event monitoring device 2. Even a person who has little knowledge about the monitoring target system 1 can construct a local prediction model. In addition, the event graph generated by the process described later can be simplified by making the weight vector sparse. As a result, an easy-to-understand event graph can be presented to maintenance personnel and engineers. In addition, it is possible to reduce the calculation amount for obtaining the correlation between the event graph and the event string for the case search.

  The above is an example using a logistic regression model. However, when dealing with multi-value changes, feature functions (feature functions) expressed as combinations of input feature quantities and multi-value event changes as described above. A log-linear model for) can be used. Furthermore, other prediction models, for example, models capable of structure prediction such as identification models CRF (Conditional Random Fields) such as CW (Confidence-Weighted) and AROW (Adaptive Regularization of Weight Vectors) may be used. As for the model update method, a simple gradient method or a subgradient method may be used, or other methods may be used.

  FIG. 11 is a process flowchart of the failure analysis support process. The processing of the failure analysis support process is executed by cooperation of the collection analysis unit 21, the abnormality detection unit 22, the event graph creation unit 32, and the operation management unit 33. The processing of the failure analysis support process is executed in response to a new event or periodically. The collection analysis unit 21 collects logs from the monitoring target system 1 and stores the latest event sequence 100 in the short-term event storage unit 24 as in the above-described processing (S101, S102). Here, to simplify the explanation, it is assumed that the stored (observed) event string 100 is event ID = 100 and time t. The anomaly detector 22 predicts an event at time t using a local prediction model based on the event observed at time t−1 (S301).

  The abnormality detection unit 22 determines whether or not the predicted result of the event at the predicted time t matches the event ID = 100 (observed result) at the observed time t. If they match, the process ends. If they do not match, the process proceeds to S303 (S302). When the prediction result and the observation result do not match, the abnormality detection unit 22 notifies the analysis computer 3 of the abnormality of the monitoring target system 1 (S303). The event graph creation unit 32 collects the latest event sequence 100 from the event monitoring device 2 that has notified the abnormality (S304). When the latest event sequence 100 is already stored in the event storage unit 34, the event graph creation unit 32 collects the latest event sequence 100 from the event storage unit 34.

  The event graph creation unit 32 starts the event (the observed event at the time t-1 in the above example) immediately before the observed event (the event at the time t-1 in the above example) that is notified of the abnormality. Are traced back in time (backtraced) to extract related events, and an event graph is created by connecting the extracted events (S305). Details of this processing will be described later. The operation management unit 33 transmits an abnormality occurrence notification and the created event graph to the operation terminal 4. The department operation terminal 4 displays the received content and ends the processing of the failure analysis support process (S306).

  In the above description, the anomaly detection unit 22 detects an anomaly based on the difference between the prediction result and the observation result. However, the anomaly detection unit 22 detects an event that can be clearly determined to be an anomaly leading to a failure, or other methods such as 1Class SVM ( Anomaly detection using Support Vector Machine) or SVM may be used together.

  FIG. 12 is a process flowchart of event graph creation (S305 in FIG. 11) by the event graph creation unit 32. The event graph creation unit 32 stores the node event 500 corresponding to the event notified of the abnormality in the case storage unit 36. Then, the event graph data 400 has the parent node ID 402 as “Empty”, the child node ID 403 as the node ID 500 of the node event 500 stored in the case storage unit 36, the connection type 404 as “none”, and the weight 405 as “Empty”. The graph data 400 is created and stored in the case storage unit 36. (S401).

  The event graph creation unit 32 extracts events that occurred before M times of the notified event from the event sequence 100 of the event management unit 34, creates a node event 500, and registers it in the case storage unit 36. Further, the event graph creating unit 32 adds a tuple of the node ID (parent node) of the notified event and the node ID (child node) of each extracted event to the stack (Last-in First-out). The stack is provided in the work area (working storage area) of the analysis computer 3. If there are a plurality of events that occurred before time M, they are added separately to the stack (S402). In this embodiment, M is the average occurrence interval of notified events. Note that M may be freely changed depending on the object, such as up to one minute before.

  The event graph creating unit 32 determines whether or not the stack is empty. If the stack is empty, the process is terminated, and if not, the process proceeds to S404 (S403). The event graph creation unit 32 extracts a tuple of a parent node and a child node from the stack (S404), creates event graph data 400 corresponding to the extracted parent node and child node, and registers them in the case management unit 36. At this time, if the parent node ID 402 of the event graph data 400 is the notified node, the connection type 404 is “abnormal transition”, the weight 405 is “Empty”, and if it is not the notified node, the connection type 404 is In “normal transition” and weight 405, the event ID weight corresponding to the child node in the local prediction model of the event ID corresponding to the parent node is registered (S405).

  The event graph creating unit 32 determines whether or not the prediction accuracy 303 of the local prediction model of the extracted child node is less than a preset threshold value α (for example, α = 0.6), and if it is less than α, the process proceeds to S403. If not, the process proceeds to S407 (S406). When the prediction accuracy is not less than α, the event graph creation unit 32 determines whether the prediction result of the child node by the local prediction model is not different from the observation result (child node) (that is, True-Positive or False-Negative Is determined). If not, the process moves to S408, and if not, the process moves to S409 (S407).

  When the prediction result and the observation result do not deviate, the event graph creation unit 32 uses the observation result (child node) as a new parent node and a constant weight of the local prediction model in order to recursively create the event graph. The event (event contributing to prediction) used in the above feature function (event that contributes to prediction) is added as a new child node to the stack, and the process returns to S403 (S408).

  When the prediction result and the observation result are different from each other, the event graph creation unit 32 extracts an event that occurred before M times of the observation result (child node), creates a node event 500, and registers it in the case management unit 36 To do. The event graph creation unit 32 creates the event graph data 400 using the observation result as a new parent node and the node corresponding to the registered node event as a new child node, and stores the event graph data 400 in the case storage unit 36. At this time, the event graph creation unit 32 sets “abnormal transition” in the connection type 404 and “Empty” in the weight 405 of the event graph data 400. Then, the process returns to step 1 S403 (S409).

  As described above, it is possible to analyze and extract the occurrence process of a certain event based on the local prediction model.

  FIG. 13 is a process flowchart of the case registration process. The process of the case registration process is executed by the operation manager 33 and the case search unit 23 in cooperation after maintenance personnel and engineers use the above-described failure analysis support process to determine the cause of the failure and take countermeasures. . The maintenance staff or engineer inputs the case ID, the site ID, the cause of the identification, and the countermeasures taken through the operation terminal 4 (S501).

  The maintenance staff or engineer uses the operation terminal 4 to associate the event graph related to the failure with the input cause and countermeasure. The operation terminal 4 transmits the case data 600 in which the event graph is associated with the cause and the countermeasure to the operation management unit 33. The operation management unit 33 stores the received case data 600 in the case storage unit 36 (S502).

  The case management unit 36 stores stored case data 600, event graph data 400 referred to as the graph ID 603 of the case data 600, and node events referred to as the parent node ID 402 and child node ID 403 of the event graph data 400. 500 is distributed to the case search unit 23 of the event monitoring apparatus 2. The case search unit 23 stores the received case data 600, event graph data 400, and node event 500 in the parameter storage unit 25, and ends the process (S503).

  When an example of a site is distributed to another site, events that do not exist in the system configuration or operation are deleted from the event graph.

  Although an example of registering a case related to a failure that occurred during operation has been described, actually, a failure that occurred in a pre-shipment test of the monitored system 1 or a test run on site after shipment may be registered in the same manner. .

  FIG. 14 is a process flowchart of the case presentation process. The processing of the case presentation process is periodically executed by the cooperation of the case search unit 23 and the operation management unit 33. The case presentation process will be described on the assumption that the short-term event storage unit 24 stores the latest event sequence.

  The case matching unit 23 acquires the event sequence 100 from the current time (t) stored in the short-term event storage unit 24 to the previous τ time (t−τ to t). Then, the case search unit 23 calculates a correlation (or similarity, distance) between the event string 100 and the event graph data 400 stored in the parameter storage unit 25 and the node event 500 (S601). For example, considering that the occurrence sequence of the event sequence 100 is often important, Spearman's rank correlation coefficient, which is a correlation coefficient that can reflect the occurrence order, can be used. If the detailed data 104 of the event sequence 100 is considered, an event graph is generated from the event sequence near the latest time of the event sequence 100 acquired from the short-term event storage unit 24 based on the event graph generation process described above. Similarity can be achieved by a graph kernel (tree kernel) between event graphs. This makes it possible to search for a case corresponding to a similar event graph by using an active event sequence by using an event graph based on the observed event sequence as a key.

  The case search unit 23 determines whether there is a case where the correlation is equal to or greater than a preset threshold value γ (for example, γ = 0.8). If there is a case, the process proceeds to S603, otherwise the process ends. (S602).

  When there is a case where the correlation between the event graphs corresponds to the threshold value γ or more, the case search unit 23 notifies the case management unit 33 of the analysis computer 3 of the case data 600. The operation management unit 33 transmits the event graph data 400 corresponding to the notified case data 600 and the node event 500 corresponding to the parent node ID 402 and the child node ID 403 of the event graph data 400 to the operation terminal 4. The operation terminal 41 displays each received data (notifies maintenance personnel and engineers), and ends the processing (S603).

  As described above, by using the event graph, it is possible to search for cases in real time from the event sequence of the monitoring target system 1 that is operating. In addition, since the event graph is generated by back-tracing from the event at the time of the failure, it is possible to search for cases before the final failure occurs and present it to maintenance personnel and engineers. .

  In the present embodiment, the method of using an event graph to search for cases in real time has been described. However, cases can be classified based on the similarity between event graphs, organized, and presented to maintenance personnel and engineers.

  FIG. 15 is an example of the event graph display screen 1100. The event graph display screen 1100 displays the event ID and event graph related to the abnormality detected by the abnormality detection unit 22 of the event monitoring device 2 on the screen of the operation terminal 4. The event graph display screen 1100 includes a site display box 1101, a date / time display box 1102, an abnormal event ID display box 1103, and an event graph monitor 1104.

  The site display box 1101 displays the site of the monitoring target system 1 in which an abnormality has occurred. The date and time display box 1102 displays the time when the abnormality occurred. The abnormal event ID display box 1103 displays the notified event ID. The event graph monitor 1104 displays, based on the event graph data 400, a tree-shaped directed graph in which the event 1104a displayed in the abnormal event ID display box 1103 is a root node, and event IDs corresponding to descendant nodes are arranged on the left side. . In addition, at the lower part of the event graph monitor 1104, the event occurrence time corresponding to each displayed node is displayed.

  As in the example shown in FIG. 15, an event may contribute to the occurrence of the other two events (two parent nodes may exist in a certain node, and event ID 67 and event ID 67 in the figure) There is a parent node of event ID 108), and not exactly a tree in which each node forms a partial order set.

  Further, the display method is changed as follows according to the connection type 404 of the event graph data 400. When the connection type 404 is “abnormal transition”, sibling nodes having the same parent node are surrounded by a broken line frame 1104b, and the parent node and the broken line frame 1104b are connected by an edge 1104c. Further, “! (1104c)” is displayed on the edge to clearly indicate “abnormal transition”. When the connection type 404 is “normal transition”, the parent node and the child node are directly connected by an edge. Furthermore, “◯ (1104d)” is displayed on the edge to clearly indicate “normal transition”. Further, the weight (1104e) of the corresponding local prediction model is displayed based on the weight 204 of the local prediction model parameter 200. In addition, when normal transition continues many steps, you may abbreviate | omit and display the node and edge in between. By displaying as described above, a maintenance worker or an engineer can visually grasp an event indicating a failure occurrence process. Further, “!” And “◯” are examples of symbols, and any display that can be visually recognized may be used, and other symbols or character strings may be used.

  FIG. 16 is an example of a case data display screen 1200. The case data display screen 1200 is displayed on the operation terminal 4 of case data searched by the case search unit 23 of the event monitoring device 2, given search time, and notified to the analysis computer 3. The case data display screen 1200 includes a site display box 1201, a date and time display box 1202, a case list 1203, an operation status list 1204, and a case event graph monitor 1205.

  In the site display box 1201, the site ID 601 of the case data 600 notified to the analysis computer 3 is displayed. The date / time display box 1202 displays the search time of the notified case data 600. In the case list 1203, the case ID 601 of the notified case data 600, correlation (correlation between event graphs when searching for case data), and content data 604 are displayed. In the operation status list 1204, the time 102, event ID 103, and detailed data 104 of the recent event sequence 100 that occurred in the site displayed in the site display box 1201 are displayed. The case event graph monitor 1205 displays an event graph of the case data 600 selected in the case list 1203.

  When the event ID displayed in the operation status list 1204 is displayed as a node of the event graph, the node is characterized (displayed in a different manner from the others by changing the display color of the node). By displaying the case data as described above, it is possible to grasp cases that are close to the event sequence generated by maintenance personnel or engineers.

  In the above description of the processing, all data displayed in the display screen examples of FIGS. 15 and 16 are transmitted from the event monitoring device 2 to the operation terminal 4 via the analysis computer 3 or from the analysis computer 3. Although not described in detail, details are omitted for the sake of brevity.

  As described above, according to the present embodiment, it is not necessary to define the cause of an event in advance, and a local prediction model can be constructed using an event sequence acquired from a monitored system. By using the model, it is possible to reduce the time and cost required to start or repair the system such as failure detection and analysis.

  In addition, according to the present embodiment, an abnormality can be detected in real time from the log of the monitored system that is in operation, and the generated event graph can be searched as a case key. However, it is possible to grasp abnormalities and cases of monitored systems.

  Furthermore, according to the present embodiment, even if a failure occurs due to the interaction between devices, the local prediction model is constructed from the actual operation of the monitored system, so the noise included in the event sequence specific to the failure that occurs There are few (events unrelated to the monitored system), and the time required to estimate the cause of the failure can be reduced.

  1: Monitoring target system, 2: Event monitoring device, 3: Computer for analysis, 4: Operation terminal, 5: Network, 11: Equipment, 12: Controller, 13: Computer for control, 14: Network for control, 21: Collection Analysis unit 22: Abnormality detection unit 23: Case search unit 24: Short-term event storage unit 25: Parameter storage unit 31: Model learning unit 32: Event graph creation unit 33: Operation management unit 34: Event Storage unit, 35: model storage unit, 36: case storage unit.

Claims (15)

A local prediction model learning process for learning in advance a local prediction model for predicting a first event based on a first event sequence during operation of the monitored system;
The second event sequence of the monitored system is monitored, the observation result of the second event included in the monitored second event sequence, and the prediction of the first event predicted using the local prediction model An anomaly detection process for extracting the second event that is inconsistent with a result, and in response to the extraction of the second event, included in the monitored second event sequence to generate the observation result, An event analysis system comprising: a failure analysis support process for creating a first event graph backtraced from a third event that occurs immediately before a second event.   The event analysis system according to claim 1, wherein the prediction using the local prediction model is predicted based on one of an occurrence order and an occurrence timing of the first events included in the first event sequence. .   The failure analysis support process has a high prediction accuracy of the local prediction model for the third event, and when the prediction result of the third event matches the observation result of the third event, The event sequence included in the second event sequence is extracted recursively using the fourth event included in the second event sequence that contributed to the prediction of the event 3 as a new starting point. The event analysis system according to claim 1, wherein the first event graph is generated by combining the event sequences. The failure analysis support process has high prediction accuracy of the local prediction model for the fourth event included in the event sequence extracted recursively, and the prediction result of the fourth event and the observation of the fourth event If the result does not match, the event sequence immediately before the fourth event is extracted, the recursive extraction is terminated, and the prediction accuracy of the local prediction model for the fourth event is low. 4. The event analysis system according to claim 3, wherein the recursive extraction is terminated.   The event analysis system according to claim 1, wherein the local prediction model learning process sparses the weight vector of the local prediction model.   The second event graph having a case corresponding to the second event graph and having a strong correlation with the second event string is searched, and the case corresponding to the searched second event graph is operated as the operation terminal. The event analysis system according to claim 1, further comprising a case presentation process to be displayed on the screen.   The event analysis system according to claim 6, wherein the case presentation process calculates the correlation using a correlation coefficient that reflects an occurrence order of the second events included in the second event sequence. . The case presentation process displays the background of the back trace of the second event sequence so as to be visually recognized, and when the transition between events included in the second event sequence is a normal transition, 7. The event analysis system according to claim 6, wherein a weight is applied to the local prediction model used for predicting transition between events, and the graph is displayed. The abnormality detection process is used, the local predictive model, the monitored system event analyzing system according to claim 1, characterized in that previously stored in event monitoring apparatus installed in sites related to site. An event analysis method in an event analysis system of a monitored system, wherein the event analysis system includes:
Learning in advance a local prediction model that predicts a first event based on a first event sequence during operation of the monitored system,
The second event sequence of the monitored system is monitored, the observation result of the second event included in the monitored second event sequence, and the prediction of the first event predicted using the local prediction model Extracting the second event whose result does not match,
In response to the extraction of the second event, a back trace is started from the third event that occurs in the monitored second event sequence and that causes the observation result and that occurs immediately before the second event. An event analysis method characterized by creating a first event graph.   In the event analysis system, when the prediction accuracy of the local prediction model for the third event is high, and the prediction result of the third event matches the observation result of the third event, the third event The event sequence included in the second event sequence is recursively extracted using the fourth event included in the second event sequence that contributed to the prediction of the event as a new starting point, and the recursively extracted The event analysis method according to claim 10, wherein an event graph is generated by combining event sequences. The event analysis system has high prediction accuracy of the local prediction model for the fourth event included in the recursively extracted event sequence, the prediction result of the fourth event and the observation result of the fourth event. Is not matched, the event sequence immediately before the fourth event is extracted, the recursive extraction is terminated, and the prediction accuracy of the local prediction model for the fourth event is low. 12. The event analysis method according to claim 11, wherein the recursive extraction is terminated.   The event analysis system has a case corresponding to a second event graph, searches the second event graph having a strong correlation with the second event sequence, and corresponds to the searched second event graph The event analysis method according to claim 10, wherein the case is displayed on an operation terminal.   14. The event analysis method according to claim 13, wherein the event analysis system calculates the correlation using a correlation coefficient that reflects the occurrence order of the second events included in the second event sequence. . The event analysis system displays the background of the back trace of the second event sequence so as to be visually recognized, and when the transition between events included in the second event sequence is a normal transition, 14. The event analysis method according to claim 13, wherein the local prediction model used for prediction of transition between events is weighted and displayed in a graph.

Images