JP3449470B2 - How to analyze event records - Google Patents

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of analyzing the state of a plant from event records such as alarms detected by DCS (Distributed Control System) and operators' operations.

[0002]

2. Description of the Related Art A DCS (Distributed Control System) has a function of recording the time of occurrence, the type of event such as an input process alarm or operation, a notification message, etc. as an event record regarding an alarm (warning) that has occurred or the operation of an operator. There is. That is, when an abnormality occurs during the operation of the plant, an alarm is issued, and the operator takes some action according to the alarm. In such a case, information regarding these alarms and operator's operations is recorded as an event record.

These event records can be displayed retrospectively on the console. That is, it has a filter function that can narrow down events based on the event attributes such as time, tag name, and batch ID.
The operator uses this filter function to search past event records, check the plant status, identify problem areas, and verify whether the response to the alarm was appropriate.

In addition to the search by the filter function, the plant may be analyzed by a statistical method. FIG. 8 shows an example of such an analysis method. In FIG. 8, the event records of one day are aggregated for each alarm tag, and the tag with many alarms is focused on. The fact that there are many alarms is because there is a high possibility that there is a problem with the equipment or control method related to the tag. After that, the location and number of occurrences of the alarm are displayed, and the facility or control logic related to the tag is investigated to identify the problem. In this way, the problematic points are found and improved, and accidents are prevented in advance.

[Problems to be Solved by the Invention]

However, such an event record analysis method has the following problems. The method of searching past event records using the filter function has a function to search for events by event attributes such as time, tag name, batch ID, etc., but each search condition is set individually. It was not possible to search for mutual relevance. Therefore, if the analyst who analyzes the event record does not understand and be aware of factors such as the location and type of the problem in advance, the problem cannot be fully identified and skill is required.
There is also a problem that it is difficult to predict in advance what will be narrowed down when setting the filter condition.

Further, the method of paying attention to the tag in which the alarm frequently occurs is an effective method because the alarm tends to occur frequently from a problem location in the plant. However, (1) it is not possible to distinguish between an alarm that is issued merely for confirmation and an alarm that is based on an abnormality that should not occur. (2) How often the operator became busy or the work volume overflowed due to frequent alarms,
Information cannot be grasped. There was a problem. Therefore, it has been difficult to specify the problem location of the plant or the true cause of the problem, which is changing every moment, even if attention is paid only to the frequent occurrence of alarms. In other words, whether the alarms are concentrated and the amount of work that exceeds the operator's allowable amount is generated, whether the abnormal state has occurred due to improper operation of the operator, or there are many alarms that can be ignored by the operator. In many cases, there is a problem that it is not possible to specify whether the actual work load of the operator is low.

[Means for Solving the Problems]

[0007]

The present invention is an event record analysis method having the following configuration. (1) A trend display of the frequency of each input event record, a display in which each event type is classified and arranged in order of frequency, and a display in which each event source is classified and arranged in order of frequency
By displaying the types of display at the same time and specifying the display location of each item on the screen where these three types are displayed, the time of occurrence,
The selection conditions of the generation type and the generation source can be individually set, and only the event records that match all of the set three types of conditions are set as the input event records, and the three types of displays are updated. How to analyze the event record. (2) Screen that displays the trend of frequency at each occurrence time
If an occurrence time range is specified above, the specified time range
Events that are included are displayed by being classified according to the type of occurrence.
And the event within the specified time range
The display according to claim 1, wherein the images are classified and displayed separately.
How to analyze the recorded event .

The present invention will be described in detail below with reference to the drawings. FIG. 1 shows a display screen of a console showing an embodiment of the present invention. In this embodiment, three types of information, that is, the time when an event occurs, the type of event occurrence, and the event source, are displayed simultaneously on one screen, and they can be narrowed down in association with each other. In FIG. 1, reference numeral 1 denotes an event counted every predetermined time (in the case of this embodiment, one day every 10 minutes), and the occurrence frequency thereof is trend-displayed. Reference numeral 11 is a summary screen displayed below the trend display 1, and displays the event at the specified time in detail. This screen allows you to see at a glance at which times events occur frequently. The trend display 1 is also used as a screen for narrowing down the time. That is, it is possible to display only the events within a specific time range of the day. In order to perform this narrowing down, a mouse pointer (not shown) is used to point to a predetermined position on the trend display screen, and the start time and end time of the narrowing down are designated. The shaded area 13 indicates a state in which this narrowing range is designated.

In FIG. 1, reference numeral 2 indicates the frequency of each event for each type of occurrence (alarm type, event type, etc.), and the percentages thereof are displayed in a pie chart in descending order of frequency. This screen allows you to see at a glance which types of events are occurring frequently. Further, the type of occurrence can be narrowed down on this screen. When the mouse pointer is used to point to the portion (or more than one) of the occurrence type that you want to narrow down in the pie graph, the events of only that occurrence type are further classified into detailed types, and a pie chart in which the frequencies are arranged in descending order is displayed. By performing this narrowing down a plurality of times, it is possible to carry out narrowing down in multiple stages.

In FIG. 1, reference numeral 3 indicates the frequency of events, which are counted according to their sources such as tags, annunciator elements, and message generation control stations, and the sources are displayed in descending order of frequency. This screen allows you to see at a glance which event source is generating the most events. Also, this screen can be narrowed down like the former two. When the generation source portion to be narrowed down is selected with the mouse pointer, only the generation source events are further classified and the occurrence frequencies are displayed in descending order of frequency.
The time, the type of occurrence, and the narrowing down of the source are synchronized with each other. That is, when the occurrence time range is designated in 1 of FIG. 1, only the events falling within the time range are classified into occurrence types and displayed in the pie chart of 2, and also classified into occurrence sources and displayed in the screen of 3. To be done. If you further narrow down by the occurrence type in that state, only the events that satisfy all of the previously specified time range, occurrence source, and occurrence type specified this time are selected, and the trend display is 1
The pie chart for each occurrence type is 2, and the display by source is 3
Is displayed in.

Next, a method of narrowing down using the screen of FIG. 1 will be described with reference to FIG. In FIG. 2, first, event data is input from an event record database of DCS (Distributed Control System). Next, a narrowing (filter) process is performed. That is, the data to be totaled is selected according to the initial filter condition. As the initial filter condition, for example, data of a predetermined day can be used. This initial filter condition may be set in advance or may be input from the screen. Next, frequency tabulation display processing is performed. In this frequency aggregation display processing, the event data that has been narrowed down is aggregated by time range, occurrence type, and origin, and as shown in FIG. Display a pie chart and a table sorted by source. Reference numerals 41, 42, and 43 in FIG. 2 correspond to the time range trend display 1, the occurrence type pie chart display 2, and the occurrence source table 3 in FIG. 1, respectively. If it can be confirmed from this display that the expected result is obtained, the process ends there. If you do not get the expected results, specify the narrowing conditions next. That is, as described with reference to FIG. 1, the trend display 41 narrows down the time range, the pie chart 42 narrows down the generation type, and the generation source display 43 narrows down the generation source. Of course, all of these narrowing downs may be performed, or only one of the narrowing downs may be performed. A new condition by this narrowing down is added, and the process returns to the narrowing down filtering process again. In this way, the narrowing process is repeated on the screen until the expected result is obtained.

In order to improve a process, potential problems in the process must be identified. “Identifying the problem” means 5W1H, that is, when and what
(What), where (Where), in what process (How), who originally (what is the true cause) (Who), and why (Why). The DCS (Distributed Control System) event record records alarm data and operation data during operation, and it is considered that the problem is recorded in this event record with a certain tendency. The event record records include the time of occurrence (When), event type (What), and source (Wher)
Since the information in e) is recorded, the true cause (Who), cause (Why), and occurrence process (How) of the problem can be determined from these three types of information.
If you can derive, you can say that you have identified the problem. This concept is shown in FIG. In other words, the information of When, What, Where recorded in the event record of DCS is 3W.
Fill in the filter to display event information about the cause of the problem, derive Who, Why, How, and display the event about the cause of the problem. This embodiment is effective as this 3W filter.

4 to 7 show another embodiment of the present invention.
FIG. 4 is a diagram showing the concept of this embodiment. In this figure, a control device such as DCS detects an abnormality or event generated by the process, and a tag alarm,
The operation monitoring terminal is notified by notification of annunciator or guidance message. This is an operation request component that prompts the operator to take measures. The operator recognizes this and performs operations such as tag data entry and tag mode change. These are the operating components. As a result of this operation, the abnormal state is released, and an alarm is returned or a tag mode change notification is given. These are the recording components. Alternatively, the operation may cause a new abnormality, and the process of notification and operation may be repeated. In this way, the operation request amount (the number of operation request components) notified by the control device and the operation amount (the number of operation components) operated by the operator such as setting value change and monitoring confirmation increase and decrease in relation to each other, It tries to grasp the process status based on the hypothesis that a properly adjusted system is balanced within a certain range. When the balance between the operation request amount and the operation amount is lost, it is considered that there is some problem to be solved. Record components are considered to be neutral to the balance relationship. It should be noted that, in this figure, the events enclosed by the solid lines are the events that are the subject of event recording, and the events enclosed by the broken lines inside the process are the events that are the actual entities inside the process that are unrelated to the event recording. Further, since the monitoring confirmation and the message confirmation are often not recorded in the event record, they are surrounded by a broken line and excluded from the operation components.

Next, the process of quantifying the balance relationship will be described with reference to FIG. In FIG. 5, first, event data is input from an event recording database of DCS (Distributed Control System). Next, this event data is subjected to component classification processing based on the event classification table. That is, the operation request component and the operation component are classified according to the type of event. The classified operation request component and operation component are aggregated for each unit time and quantified in time series. This digitized data is converted into a balance graph. That is, the time series change of the operation request amount is displayed on the upper side and the time series change of the operation amount is displayed on the lower side in the form of a graph. The displayed balance graph allows you to grasp the status of the process.

Next, the process of creating a balance graph will be described.
This will be described in more detail with reference to FIG. In FIG. 6, 5
Reference numeral 1 represents an event record input from the DCS (Distributed Control System). This event record is composed of the time of occurrence, the content of the event, and the type of event. Next, the input event record is subjected to event component classification processing. That is, the event is classified into three components, an operation request component, an operation component, and a recording component. Operation request components include alarm status notifications, annunciator messages, operation command messages, dialog (input request) notifications, and operation components include instrument setting value changes, tag operations such as opening and closing, and message confirmation operations. . Further, the recording component includes a change in the state of a functional block, a change record of a batch input parameter, and an alarm reset. Of these, the recording component is considered to be neutral in the balance relationship between the operation request amount and the operation amount, so it is excluded, and only the operation request component and the operation component are extracted and the transition of the number thereof is quantified. Reference numeral 52 is the digitized time-series data, which is the time-series data of the operation request amount (the number of operation request components) and the operation amount (the number of operation components) every 10 minutes. This time series data is displayed as a balance graph. Reference numeral 53 represents the displayed balance graph. In this balance graph, the horizontal axis represents time, and the operation request amount is displayed on the upper side and the occurrence frequency of the operation amount is displayed on the lower side in a line graph. In this graph, the center is 0,
The operation request amount is displayed such that the higher the operation request amount and the lower the operation amount, the higher the occurrence frequency.

FIG. 7 shows an example of a balance graph and an example of what can be understood from this balance graph. FIG. 7A is an example of a balance graph, which is a balance graph in which event records for one day are frequency-collected every 10 minutes. Since the operation request amount and the operation amount for the same time are graphed vertically, it is possible to grasp the balance relationship between the two at a glance. The figure (B) is a summary of the operating conditions assumed by the balance graph and the countermeasures to be considered. Five situations are illustrated in this figure. (1) When both the operation request amount and the operation amount are low, it is assumed that an appropriate operation command is issued and the operator is operating accordingly. Therefore, no special countermeasure is required in the short term. (2) When the operation request amount is large but the corresponding operation amount does not increase so much, it is estimated that there are many redundant alarm notifications with low necessity. Therefore, improvements should be made to reduce unnecessary messages. Also, when there are many confirmation alarms, it may be better to consider an advanced guidance system by introducing an expert system or the like. (3) If the operation amount increases and then the operation request amount increases and the operation amount continues to be large, the abnormal state continues due to improper operation or the system becomes unstable. is assumed. Therefore, it is necessary to consider a higher degree of automation in order to stabilize the system. (4) When the amount of operation demand increases and the state of large amount of operation continues for a long time, the operator's response becomes insufficient due to an unexpected error in a short period of time, and the abnormal condition does not easily settle. State is assumed. Therefore, it is conceivable that the operation amount is too large for the number of operators, or the operation efficiency and automation are insufficient. (5) If the operation amount is large but the operation request amount is not so large, it is assumed that the operation system is complicated and the operation for one event extends to other stages. Therefore, it is necessary to consider whether there is room for automation of the operation sequence. In this way, it is possible to estimate the operating status and to formulate countermeasures against it, simply by examining the balance graph.

【The invention's effect】

According to the present invention, the following effects can be expected.
According to the first and second aspects of the present invention, the event record is selected and displayed by the time of occurrence, the type of occurrence, and the source of the event, and the result can be displayed by further narrowing down the corresponding screen. Therefore, more intuitive narrowing down can be realized. Further, since the result of narrowing down is immediately obtained on the same screen, it is possible to more intuitively predict / understand the target of narrowing down, and it is possible to effectively narrow down the problem by trial and error.

[0018]

[Brief description of drawings]

FIG. 1 is a diagram showing a screen display according to an embodiment of the present invention.

FIG. 2 is a flow chart showing a method of narrowing down according to an embodiment of the present invention.

FIG. 3 is a diagram for explaining the concept of an embodiment of the present invention.

FIG. 4 is a diagram for explaining the concept of another embodiment of the present invention.

FIG. 5 is a flowchart showing a procedure for creating a balance graph according to another embodiment of the present invention.

FIG. 6 is a diagram showing a procedure for creating a balance graph according to another embodiment of the present invention.

FIG. 7 is a diagram illustrating an example of a balance graph according to another embodiment of the present invention and a plant operating condition and a countermeasure that are supposed from the balance graph.

FIG. 8 is a diagram showing an example of a conventional plant analysis method.

[Explanation of symbols]

1 Trend display of event record occurrence frequency 2 Frequency display classified by the type of event record occurrence 3 Frequency display classified by the source of the event record 51 Example of event recording 52 Table exemplifying changes in operation request amount and operation amount 53 Example of balance graph

Claims (2)

(57) [Claims] Claims: 1. Three types of input event records: frequency trend display for each occurrence time, display classified by occurrence type and arranged in order of frequency, and display classified by occurrence source and arranged in order of frequency. Is displayed at the same time, and it is possible to individually set the selection conditions for the time of occurrence, the type of occurrence, and the source of occurrence on these three types of displayed screens, so that all of the three types of set conditions are met. A method of analyzing an event record, wherein only the event record is used as the input event record and the three types of displays are updated. 2. A trend display of frequency at each occurrence time is displayed.
When the occurrence time range is specified on the screen, the specified time
Events that fall within the time range are categorized according to the type of occurrence and displayed.
Events within the specified time range
Claims characterized by being displayed according to origin
The method of analyzing the event record according to 1 .