JP6060584B2 - Program abnormality detection device and program thereof - Google Patents

Description

  The present invention relates to an apparatus for detecting a program abnormality.

  As a method for detecting an abnormality of a program, a method of detecting an abnormality using a WDT (watchdog timer) is generally known. In this case, if the timer reset (clear) is not performed from the program within a certain time with respect to the WDT, it is assumed that an abnormality has occurred in the program, and the CPU is reset or stopped.

As such a program abnormality detection method, for example, conventional techniques described in Patent Documents 1 and 2 are known.
Patent Document 1 discloses a program abnormality detection circuit that receives a monitoring timer reset signal sent from a central processing unit that executes program processing and detects a program abnormality based on this signal. The program abnormality detection circuit includes a monitoring timer, an OR circuit, a flip-flop, and the like, and when the monitoring timer reset signal is received by the monitoring timer count time T1 (T1 ≠ 0) or from the count time T1 If it is not received before T2 (T1 <T2), it is detected as a program error.

  Further, Patent Document 2 proposes a method of extending the WDT function with software to increase the detection accuracy of a program abnormality. This is because the application program (AP) notifies the WDT of the set time, and the set time notified by the WDT is set in the timer and restarted, but the set time notified from the AP is different every time. This is a method for detecting an abnormality in the program. According to this method, even when a timer reset routine is included in a portion where the program runs away and is repeatedly executed, the program runaway can be detected.

JP 59-83438 JP 2007-287096 A

However, the conventional method described above has the following problems.
That is, Patent Document 1 has the following problems.
The program abnormality detection circuit is realized by hardware, and it is difficult to deal with when the software is composed of a plurality of fixed-cycle processes (fixed-cycle tasks).

  For example, if there is a program (fixed cycle task) that does not perform WDT reset processing, it may not be detected even if an abnormality occurs in the fixed cycle task. On the other hand, when the WDT reset process is performed for all the fixed-cycle tasks, for example, the monitoring timer reset signal is output as each fixed-cycle task is executed. Whether the signal is a reset signal by a periodic task cannot be distinguished, and naturally, normality / abnormality cannot be determined for each fixed-period task. Alternatively, when a fixed-cycle task that performs WDT reset processing runs away and becomes an infinite loop including the reset processing, there is a possibility that an abnormality cannot be detected.

Also, Patent Document 2 has the following problems.
-Abnormality detection when the software is composed of multiple fixed-cycle processes (fixed-cycle tasks) is not considered. Therefore, nothing is conceived regarding the abnormality detection of software composed of a plurality of periodic tasks. Furthermore, when a program having a WDT reset process (fixed-cycle task) runs out of control and becomes an infinite loop including the reset process, it may not be possible to detect an abnormality.

  As described above, conventionally, when software is composed of a plurality of fixed-cycle processes (fixed-cycle tasks), detection of a program abnormality is not conceived and cannot be realized.

  Here, the plurality of fixed-cycle tasks are, for example, tasks on a real-time OS. As is well known, the real-time OS is a scheduling function for each process (task), and is used to perform time-related operations such as calling and executing each task at a certain period or stopping the task process for a certain period of time. Has a time management function. It also has an interrupt management function. Alternatively, in a programmable controller (PLC) in the control field, a plurality of fixed-cycle tasks are sequentially executed to control some device to be controlled.

  The problem of the present invention is that it is possible to detect anomalies even in software composed of a plurality of fixed-cycle tasks, and furthermore, it is possible to detect anomalies even when a program of an arbitrary task runs away and becomes an infinite loop including a refresh process. It is to provide a program abnormality detection device and the like.

  The program abnormality detection device according to the present invention is a program abnormality detection device that detects an abnormality of a program composed of a plurality of periodic tasks, and in which predetermined refresh information is stored corresponding to each of the periodic tasks Information storage means, and condition registration means for registering a temporal condition related to refresh processing executed by the fixed-cycle task corresponding to each fixed-cycle task, each of the fixed-cycle tasks, As refresh processing, it has a refresh means for updating the refresh information corresponding to the fixed-cycle task, and periodically meets the temporal condition with reference to the corresponding refresh information for each fixed-cycle task. If the time condition is not satisfied, or if the time condition is continuously repeated a plurality of times If not satisfied includes a determining monitoring means and abnormality of the periodic task.

  The temporal condition is, for example, a monitoring timeout period and a refresh prohibition period. And, for example, the monitoring means, for each of the periodic tasks, when the next refresh process is not executed until the monitoring timeout period elapses after the execution of the arbitrary refresh process, or the refresh prohibition period If the refresh process is executed, it is determined that the temporal condition is not satisfied.

  According to the program abnormality detection apparatus and the like of the present invention, even software composed of a plurality of periodic tasks can detect an abnormality, and further, a program of an arbitrary task including a refresh process runs out of control and becomes an infinite loop. Anomaly can be detected even if

It is a hardware structural example of the program abnormality detection apparatus of this example. It is a block diagram concerning a program abnormality detection function. (A), (b) is a figure which shows the specific example of a monitoring condition setting table. (A), (b) is a figure which shows the specific example of a refresh order setting table. (A), (b) is a figure which shows the specific example of a refresh recording table. (A), (b) is a figure which shows the specific example of a refresh order recording table. It is a process flowchart figure of a refresh process part. It is a process flowchart figure of a monitoring part. It is a figure for demonstrating a monitoring timeout and a prohibition period. It is a process flowchart figure (order check) of a monitoring part.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a hardware configuration example of the program abnormality detection device of this example.
This may be regarded as a hardware configuration example of some computer / information processing apparatus (a personal computer, an embedded device, a programmable controller, etc.) having the function of the program abnormality detection apparatus of this example.

The program abnormality detection apparatus 10 of this example is composed of a CPU 11, a RAM 12, a ROM 13, an external I / F (interface) 14 and the like, and each is connected by a bus.
The ROM 13 is a memory in which program codes executed by the CPU 11 and the like (application program group 40 described later) are stored. Further, the ROM 13 stores in advance other application programs (not shown) for realizing various processing functions of the program abnormality detection function unit 20 described later. When the CPU 11 reads and executes this application program, for example, the processing of various flowcharts (FIGS. 7, 8, and 10) described later is realized.

  The RAM 12 is a rewritable memory, and allocates, for example, a refresh processing information storage area 30 to be described later. Each setting table 21, 22, etc., which will be described later, may be stored in either the RAM 12 or the ROM 13.

  The external I / F 14 is an interface for connecting to some external device (not shown), and is connected to a communication device such as a serial controller or a LAN controller. The external I / F 14 may be connected to a storage device such as a CF card or a USB memory. For example, the setting tables 21 and 22 may be changed via this interface.

FIG. 2 is a configuration diagram relating to a program abnormality detection function in the information processing apparatus of FIG.
First, the ROM 13 stores in advance an application program group 40 that is software configured by the above-described plurality of fixed-cycle processes (fixed-cycle tasks; hereinafter abbreviated to be simply referred to as tasks). .

  The application program group 40 includes a plurality of programs (task A program to task X program) 41 divided for each task. Each of these task programs 41 (tasks) performs a periodic operation at a predetermined fixed period. Each task program 41 is, for example, a task on a real-time OS, but is not limited to this example.

  Each task program 41 executes a certain predetermined process at a fixed period, but in addition to that, a refresh processing unit 42 that executes a refresh process corresponding to the above-described timer reset process at regular intervals for the conventional WDT described above. Is incorporated. In this method, a timer is not used, and a function corresponding to “abnormality detection using a conventional WDT” is realized by software processing.

  The storage area 30 stores a refresh recording table 31, a refresh order recording table 32, and the like, which are examples of the refresh processing information. Basically, at least the contents of the refresh recording table 31 are updated every time the refresh processing is performed by each refresh processing unit 42. In this example, the refresh order record table 32 is also used, but this is not always necessary (thus, in FIG. 10 described later, the process using the refresh order record table 32 and the process related thereto are also indispensable). is not). However, by executing these, the effects described later are further obtained.

The program abnormality detection function unit 20 includes a monitoring condition setting table 21, a refresh order setting table 22, a setting unit 23, a monitoring unit 24, and the like.
The setting unit 23 sets the monitoring condition setting table 21 and the refresh order setting table 22. For example, the setting unit 23 displays a setting screen (not shown) on a display (not shown), causes the user to set arbitrary information, and stores the setting information in the setting tables 21 and 22 (the user is This is not limited to this example). For example, the setting unit 23 performs a process of taking in the setting tables 21, 22 and the like arbitrarily created by the user or the like outside in some form (via a network or via a portable storage medium) and storing them in the RAM 12 / ROM 13. It may be a thing. In any case, the contents of the setting tables 21 and 22 may be arbitrarily set by the user or the like.

  In the monitoring condition setting table 21, for example, temporal conditions relating to refresh processing executed by the fixed-cycle task corresponding to each fixed-cycle task (each task / program 41) are set and registered. The temporal conditions are a monitoring timeout period and a refresh prohibition period. For example, the monitoring unit 24 performs the next refresh for each task program 41 until the monitoring timeout period elapses from the execution of an arbitrary refresh process. When the process is not executed, or when the refresh process is executed within the refresh prohibition period, it is determined that the temporal condition is not satisfied. Details will be described later.

For example, predetermined refresh information is stored in the refresh recording table 31 corresponding to each task program 41.
The refresh processing unit 42 of each of the task programs 41 refers to the refresh recording table 31 and the refresh processing while referring to the setting contents of the monitoring condition setting table 21 and the refresh order setting table 22 as the periodic refresh processing. Various stored contents (referred to as refresh information) to be described later in the order recording table 32 are updated. Details will be described later with reference to FIG.

  The monitoring unit 24 periodically reads the data recorded in the refresh recording table 31 and the refresh order recording table 32, refers to the setting contents of the monitoring condition setting table 21 and the refresh order setting table 22, and performs the above described regular cycle. It is determined whether there is an abnormality for each task (task program 41).

Hereinafter, the various tables will be described with specific examples.
3A and 3B show specific examples of the monitoring condition setting table 21. FIG.
4A and 4B show specific examples of the refresh order setting table 22. FIG.

5A and 5B show specific examples of the refresh recording table 31. FIG.
6A and 6B show specific examples of the refresh order recording table 32. FIG.
Hereinafter, first, a specific example of the monitoring condition setting table 21 will be described with reference to FIG.

As shown in FIG. 3A, the monitoring condition setting table 21 is generally composed of the number of monitoring condition setting data 211 and each monitoring condition setting data ((1) to (n)) 212.
The monitoring condition setting data number 211 stores the number (number of records) of the monitoring condition setting data 212, and n is stored in the illustrated example.

FIG. 3B shows an example of data items of the monitoring condition setting data 212 (record).
The monitoring condition setting data 212 includes a refresh monitoring time 212a, a refresh delay minimum time 212b, a refresh delay maximum time 212c, a monitoring time time up continuous occurrence allowable number 212d, a monitoring time time up operation 212e, and a monitoring time time up call function 212f. The prohibited period refresh continuous occurrence allowable number 212g, the prohibited period refresh operation 212h, and the prohibited period refresh call function 212i.

  The contents of these data items can be arbitrarily set by a developer or the like via the setting unit 23, for example. That is, although not particularly illustrated, the setting unit 23 displays a screen that allows the user to arbitrarily set and input the contents of the data items 212a to 212i, for example. Then, data set / input regarding an arbitrary fixed-cycle task (task program 41) is stored as monitoring condition setting data 212 of the monitoring condition setting table 21. At this time, an identifier or the like of the corresponding task program 41 may be given to the monitoring condition setting data 212 to be stored. Then, the monitoring condition setting data number 211 is updated (+1 increment or the like).

  The “refresh monitoring time” 212a is an allowable waiting time from the execution of any refresh to the next refresh. In other words, it is a time corresponding to a certain time for the conventional WDT. Regarding any task program 41, if the time from refresh execution to the next refresh (refresh interval) exceeds the “refresh monitoring time” 212a, the task program 41 is suspected of abnormal. .

  However, in this example, it is not determined that there is an abnormality only once, but when a situation where the refresh interval exceeds the “refresh monitoring time” 212a continues for a plurality of times (“monitoring time timeout continuous occurrence count” 312e described later). However, it is determined to be abnormal if the threshold value (“monitoring time time up continuous occurrence allowable number” 212d) is exceeded. However, the present invention is not limited to this example, and an abnormality may be determined only once.

  The “refresh delay minimum time” 212b and the “refresh delay maximum time” 212c are for setting a refresh inhibition period. This is for detecting an abnormality corresponding to the above-described abnormality (which is referred to as an infinite loop for simplification) “the program runs away and becomes an infinite loop including WDT reset processing”. As described above, when such an infinite loop occurs, refresh processing may be frequently performed. Thus, for example, when the time from execution of an arbitrary refresh process to the execution of the next refresh process is too short (less than “minimum refresh delay time” 212b), it is determined as abnormal.

  In the past, this kind of infinite loop could be detected when the software was not composed of multiple fixed-cycle tasks, but in the past it was realized in the case of software composed of multiple fixed-cycle tasks. could not.

  On the other hand, in this method, for example, at least the monitoring condition setting table 21 and the refresh recording table 31 are used to perform the processing of FIGS. 7 and 8 (however, processing related to the refresh order is not essential). Thus, even software composed of a plurality of fixed-cycle tasks can detect not only the abnormality relating to the monitoring timeout (corresponding to the WDT timeout) but also the infinite loop for each task.

  Regarding the detection of the infinite loop, for example, by setting the prohibition period corresponding to each task, if a certain task program 41 is refreshed during the prohibition period, the task program 41 Anomalies such as runaway (infinite loop) were suspected.

  The “minimum refresh delay time” 212b is the minimum time related to the time (refresh interval) from the arbitrary refresh execution time to the next refresh. If any task program 41 is refreshed at a time interval shorter than the “minimum refresh delay time” 212b, occurrence of an abnormality such as a runaway (infinite loop) of the task program 41 is suspected.

  However, in this example, it is not determined that there is an abnormality only once, and when the refresh interval is shorter than the “minimum refresh delay time” 212b, it is counted as “the number of consecutive occurrences of prohibition period refresh” 312f described later. When the number of consecutive occurrences 312f exceeds a predetermined threshold (212g), it is determined that there is an abnormality. However, the present invention is not limited to this example, and an abnormality may be determined only once.

  On the other hand, the “maximum refresh delay time” 212c is the maximum time related to the time (refresh interval) from the time of arbitrary refresh execution until the next refresh is performed. If the refresh interval for an arbitrary task program 41 exceeds the “refresh delay maximum time” 212c, the task program 41 is suspected of having an abnormality even if it does not exceed the “refresh monitoring time” 212a.

  However, in this example, it is not determined that there is an abnormality only once, and when the refresh interval is longer than the “maximum refresh delay time” 212c, it is counted as the “prohibition period refresh occurrence count” 312f. As described above, when the number of consecutive occurrences 312f exceeds a predetermined threshold (212g), it is determined that there is an abnormality. However, the present invention is not limited to this example, and an abnormality may be determined only once.

Further, regarding the prohibition period, the “maximum refresh delay time” 212c is not necessarily used, and only the “minimum refresh delay time” 212b may be used.
As described above, in this example, for any task program 41, when the “monitoring time timeout continuous occurrence count” 312e or “prohibition period refresh occurrence count” 312f exceeds a predetermined threshold, the task It is determined that an error has occurred in the program 41 (task). This threshold is the above-mentioned supervision “permissible number of continuous occurrences of visual time time-up” 212d or “prohibited continuous number of occurrences of prohibited period refresh” 212g.

  That is, the “monitoring time time-up continuous occurrence allowable number” 212d is the number of times that the monitoring time time-up continuous occurrence number is allowed. For any task program 41, the “monitoring time time-up continuous occurrence number” 312e When the “monitoring time time-up continuous occurrence allowable number” 212d is exceeded, it is determined that an abnormality such as a runaway (infinite loop) of the task program 41 has occurred. If it is determined that the program is abnormal, for example, the operation set in “operation when the monitoring time expires” 212e is executed. The operation set in the “operation when the monitoring time is up” 212 e is, for example, CPU reset, system stop, task stop, task restart, function call, etc. Specified.

  The “monitoring time time-up call function” 212f is a function to be called when “function call” is specified in the “monitoring time time-up operation” 212e. Although the storage address is set, the present invention is not limited to this example.

  The “prohibited period refresh occurrence allowable number of times” 212 g is the allowable number of times that refresh is continuously performed during the prohibited period, and the “prohibited period refresh continuous number of occurrences” for an arbitrary task program 41. When “312f” exceeds the “prohibited number of times of prohibited continuous refresh occurrence” 212g, it is determined that an infinite loop abnormality has occurred in the task program 41. If it is determined that the loop is infinite, the operation set in the “prohibition period refresh operation” 212h is executed. The operation set in the “prohibition period refresh operation” 212h is, for example, CPU reset, system stop, task stop, task restart, function call, etc. It is a thing.

  The “invocation function during prohibition period refresh” 212i is a function that is called when “function call” is specified in the “operation during refresh during prohibition period” 212h. For example, the storage address of the function is stored. However, the present invention is not limited to this example.

Next, a specific example of the refresh order setting table 22 will be described with reference to FIG.
The table 22 is processed (refreshed) in the determined order when there are a plurality of task programs 41 whose operation order is determined among the plurality of task programs 41 (tasks). In the case where the refresh is not performed in the determined order, even if each task program 41 does not have the above-described abnormality (such as an infinite loop), Judge as a program error.

  For example, among task A program, task B program,..., Task X program shown in FIG. 1 (assuming that there are A to X), suppose task B → task D → task E → task B. If the tasks are determined to be executed in this order, the refresh processing is also executed in accordance with the execution of these tasks. Therefore, if normal, the refresh processing should be executed in this order.

  The refresh order setting table 22 enables a plurality of group settings, and “refresh order setting group data” 222 is set and registered for each group. As shown in FIG. 4A, the refresh order setting table 22 is roughly composed of “refresh order setting group number” 221 and “refresh order setting group data” ((1) to (m)) 222. The In the “refresh order setting group number” 221, the number of “refresh order setting group data” 222 is registered, which is m in the illustrated example.

FIG. 4B shows an example of data items of “refresh order setting group data” 222.
The “refresh order setting group data” 222 includes an abnormal operation 222a, an abnormal call function 222b, an order setting data number 222c, a monitoring condition setting data identifier ((1) to (r)) 222d, and the like.

  In the “abnormal operation” 222a, an operation when it is determined that the program is abnormal because the refresh has not been performed in the set order is designated (set). The set operation is, for example, CPU reset, system stop, function call, etc., but is not limited to these examples.

  In the “abnormal function call function” 222b, a function to be called when the “function call” is specified in the “abnormal operation” 222a is set, for example, a storage address of the function is set. However, it is not limited to this example.

In the “order setting data number” 222c, the number of “monitoring condition setting data identifiers” 222d is registered, and in the example illustrated, r pieces are registered.
The “monitoring condition setting data identifier” 222d is identification information (identifier) of a task (task program 41) belonging to the group. These identifiers are registered in an arbitrarily determined execution order. That is, “monitoring condition setting data identifier” (1) → “monitoring condition setting data identifier” (2) →... → “monitoring condition setting data identifier” (r) → “monitoring condition setting data identifier” (1 The tasks should be executed in the order of) →... If it is detected that the tasks are not executed in this order, it is determined that the program is abnormal.

Next, a specific example of the refresh recording table 31 will be described with reference to FIG.
As shown in FIG. 5A, the refresh recording table 31 is generally composed of a refresh recording data number 311 and refresh recording data ((1) to (n)) 312.

  The “number of refresh recording data” 311 stores the number of “refresh recording data” 312 and is n in the illustrated example. This is the same (n) as the “monitoring condition setting data” 212 in the monitoring condition setting table 21. The n pieces may be considered as the number of task programs 41 basically. In this example, it is desirable that the order of each “refresh recording data” 312 has a corresponding relationship with the order of the “monitoring condition setting data” 212 for processing to be described later. That is, for example, if “monitoring condition setting data” (1) which is the first record is setting data related to the task A program in FIG. 1, “refresh recording data” (1) which is also the first record is task A program. It is desirable to set so that the recording data becomes.

Unlike the “monitoring condition setting data identifier” 222d, this need not be in the order of execution.
In addition, it is desirable that the identifier of the corresponding task program 41 is also registered in each “refresh recording data” 312 and each “monitoring condition setting data” 212.

FIG. 5B shows an example of data items of the refresh recording data 312.
The refresh recording data 312 includes a refresh counter current value 312a, a time stamp current value 312b, a refresh counter previous value 312c, a time stamp previous value 312d, a monitoring time time-up consecutive occurrence count 312e, and a prohibited period refresh consecutive occurrence count 312f. .

  Each “refresh recording data” 312 is provided corresponding to each task program 41 (particularly, its refresh processing unit 42), and the refresh processing unit 42 of an arbitrary task program 41 is provided for each refresh process. The content of the “refresh recording data” 312 corresponding to the self is updated.

  That is, each refresh processing unit 42 stores data such as “refresh counter current value” 312 a and “time stamp current value” 312 b of “refresh recording data” 312 corresponding to itself in the monitoring condition setting table 21. Update by referring to the corresponding “monitoring condition setting data” 212 or the like. In this update process, for example, each counter value is incremented by +1, and the time stamp uses the current date and time as a new current value.

  On the other hand, regarding the “refresh counter previous value” 312c and the “timestamp previous value” 312d, the monitoring unit 24 updates the current value as a new previous value. In addition, the monitoring unit 24 also updates the “monitoring time timeout continuous occurrence count” 312e and the “prohibition period refresh consecutive occurrence count” 312f. The monitoring unit 24 updates (+1 increments) the “monitoring time time-up continuous occurrence count” 312e when it detects the occurrence of the monitoring time time-up in the process described later, and when it detects the occurrence of the prohibited period refresh. The number of consecutive occurrences of prohibition period refresh “312f” is updated (+1 increment).

  In addition, when the monitoring unit 24 does not detect the occurrence of the monitoring time time-up in the process described later, the “monitoring time time-up consecutive occurrence count” 312e is cleared to “0” and the occurrence of the prohibition period refresh is detected. If not, the “prohibited period refresh occurrence count” 312f is cleared to “0”. Since these literally count the number of times of continuous occurrence, they are reset to “0” when the continuous occurrence is interrupted.

Next, a specific example of the refresh order recording table 32 will be described with reference to FIG.
First, as shown in FIG. 6A, the refresh order recording table 32 is generally composed of a refresh order recording data number 321 and refresh order recording data ((1) to (m)) 322.

  The “refresh order record data number” 321 stores the number of “refresh order record data” 322, and m is stored in the illustrated example. This is the same (m number) as the “number of refresh setting groups” 221 in the refresh order setting table 22. The m pieces may be basically considered as the number of groups. The grouping and the execution order within each group may be arbitrarily determined and set by a programmer, for example. In this case, it is desirable that the order of each “refresh order recording data” 322 corresponds to the order of the “refresh order setting group data” 222. That is, for example, if the “refresh order setting group data” (1) that is the first record is setting data related to an arbitrary group α, the refresh order recording data (1) that is also the first record is also recorded as to the group α. It is desirable to set it to be data.

FIG. 6B shows an example of items of the refresh order record data 322.
The “refresh order record data” 322 includes a “refresh common counter” 322a and a “counter” ((1) to (r)) 322b. Each “counter” 322b corresponds to one of the task programs 41 belonging to the group, and therefore, the number is “r”, similar to the “monitoring condition setting data identifier” 222d. The order of each “counter” 322b preferably corresponds to the order of “monitoring condition setting data identifier” 222d. That is, for example, the “counter” (1) which is the first record is a counter corresponding to the “monitoring condition setting data identifier” (1) which is also the first record. The count value of the “counter” (1) is updated every time the task program 41 corresponding to the identifier (1) executes the refresh process. The update method uses the refresh common counter 322a as described below. It becomes.

  The “refresh common counter” 322a is a counter that is used in common within the group, and every time the refresh processing unit 42 of any task program 41 belonging to the group executes the refresh processing, the refresh processing unit 42 is updated (counted up by 1). Then, the updated count value is stored in the “counter” 322 b corresponding to the refresh processing unit 42.

  Further, as described later, the monitoring unit 24 determines whether or not the “counter” 322b is updated in the set order based on each “counter” 322b and the like, and the “counter” is set in the set order. If “322b” has not been updated, it is determined that the program is abnormal.

  Next, processing of the various processing function units (refresh processing unit 42, monitoring unit 24) will be described with reference to the flowcharts of FIGS. This will be described using a data configuration example shown in FIGS. 3 to 6 as a specific example.

FIG. 7 is a processing flowchart of the refresh processing unit 42.
Each task program 41 constituting the application program group 40 calls its own refresh processing unit 42, for example, periodically. At that time, the self identifier is passed as a parameter. Each task program 41 is assigned unique identification information (identifier) in advance.

  When the called refresh processing unit 42 starts executing the processing of FIG. 7, it first acquires the identifier (step S11). As described above, each storage information of each setting table and each recording table is managed using an identifier, and the storage information (its storage position, etc.) corresponding to itself is determined by using the acquired identifier. be able to.

  Next, the refresh processing unit 42 acquires the current time stamp (step S12). Note that this may simply be to acquire the current time from a clock function or the like in the apparatus. Then, the corresponding refresh recording data 312 in the refresh recording table 31 is determined based on the identifier acquired in step S11, and for example, the record position is set (set as a processing target record) (step S13). As described with reference to FIG. 5A, each refresh record data 312 corresponds to, for example, an arbitrary task program 41, and an identifier thereof is registered.

  Then, the data content of the corresponding refresh record data 312 (corresponding record) is updated. That is, first, the refresh counter current value 312a of the corresponding record is updated, and the time stamp current value 312b is updated (step S15). For updating the refresh counter current value 312a, for example, a value obtained by adding 1 to the current value (= the value of the new previous value 312c) is set as a new current value. For updating the current time stamp value 312b, the current time stamp acquired in step S12 is set.

  When the data content of the corresponding refresh recording data 312 is updated as described above, the fresh order recording table 32 is further updated in this example. The use of the fresh order recording table 32 (update or determination of abnormality by reference) is not essential, but the effect of doing this can also be obtained.

  First, the refresh order setting table 22 is referred to and searched to determine whether or not the identifier acquired in step S11 is set (steps S16 and S17). That is, as described above, the identifier of the task program 41 belonging to the group is registered as the “monitoring condition setting data identifier” 222d for each group in the refresh order setting table 22. It is the process of step S16 to determine whether or not there is an identifier identical to the identifier acquired in step S11 among the plurality of “monitoring condition setting data identifiers” 222d.

  From the above, when there is an identifier identical to the identifier acquired in step S11, not only the relevant “refresh order setting group data” 222 and the relevant “monitoring condition setting data identifier” 222d are known, The corresponding “refresh order recording data” 322 and the corresponding “counter” 322b can also be determined.

  From this, when there is a setting of the corresponding identifier (step S17, YES), the “refresh common counter” 322a in the corresponding “refresh order record data” 322 is updated (for example, incremented by +1) (step S18). Further, the value of the updated refresh common counter 322a is set in the corresponding “counter” 322b (step S19). Then, this process ends.

On the other hand, if there is no corresponding identifier setting (step S17, NO), this process is terminated.
FIG. 8 is a process flowchart of the monitoring unit 24.

  The monitoring unit 24 executes the processing of FIG. 8 at regular intervals, for example, and operates at a higher priority than each task program 41 and operates at a shorter cycle interval than each task program 41. Shall.

When the monitoring unit 24 starts executing the process of FIG. 8, first, the current time stamp is acquired and substituted into the variable “TIMcur” (step S51).
Next, the first record of the monitoring condition setting table 21 and the first record of the refresh recording table 31 are set as processing target records (steps S52 and S53). Note that setting means, for example, designating a pointer, which indicates the current processing target record.

  In addition, the top record is the top (“monitoring condition setting data (1)” in the example of FIG. 3) of the plurality of “monitoring condition setting data” 212 in the monitoring condition setting table 21, and the refresh recording table 31. Of the plurality of “refresh recording data” 312 (in the example of FIG. 5, “refresh recording data (1)” is meant. In this example, the first record to be processed is the above-mentioned first record. Of course, the present invention is not limited to this example.

  Then, the following data is read from the processing target record and assigned to a variable. In addition, the update / clearing of the number of occurrences described below is also performed on the corresponding data item of the processing target record.

  First, “Refresh monitoring time” 212a, “Refresh delay minimum time” 212b, and “Refresh delay maximum time” 212c of the processing target record in the monitoring condition setting table 21 are read, and the variables “Tout”, “Tmin”, “Variable” are read out. Substitute for Tmax '(step S54). Further, the “refresh counter current value” 312a, “refresh counter previous value” 312c, “time stamp current value” 312b, and “time stamp previous value” 312d of the processing target record of the refresh recording table 31 are read, and the variable “CNTa” is read. , Variable 'CNTb', variable 'TIMa', and variable 'TIMb' are substituted (step S55).

  Next, the difference (CNTa−CNTb) between the current value (CNTa) and the previous value (CNTb) of the refresh counter is calculated, and this difference is substituted into the variable “CNTdif” (step S56). Further, the difference (TIMa−TIMb) between the current value (TIMa) and the previous value (TIMb) of the time stamp is calculated, and this difference is substituted into the variable “TIMdif” (step S57).

  In general, it is determined whether or not a monitoring timeout has occurred, and even if the monitoring timeout has not occurred, it is further confirmed whether or not the refresh process has been executed during the prohibited period. Basically, it is regarded as normal when there is no monitoring timeout and refresh is not executed during the prohibited period.

That is, first, based on the difference value (CNTdif) of the refresh counter, it is determined whether there is a counter update (whether CNTdif> 0) (step S58).
When the counter is not updated (CNTdif ≦ 0) (step S58, NO), the process proceeds to the monitoring timeout determination process (steps S63 to S68). On the other hand, if there is a counter update (CNTdif> 0) (step S58, YES), the value of “refresh counter current value” 312a is set in the “refresh counter previous value” 312c of the processing target record. Furthermore, after setting the value of “time stamp current value” 312b in the “time stamp previous value” 312d of the processing target record (step S72), the process proceeds to the prohibition period refresh determination processing after step S59.

  In the monitoring time-up determination process, first, a difference (TIMcur−TIMa) between the current time stamp (TIMcur) and the current time stamp value (TIMa) is calculated, and this difference is substituted into the variable “TIMdif2” (step S63). ). Next, the difference value (TIMdif2) is compared with the refresh monitoring time (Tout) to determine whether or not the monitoring time is up (TIMdif2> Tout) (step S64).

  When the monitoring time is not up (TIMdif2 ≦ Tout) (step S64, NO), the “monitoring time up continuous occurrence count” 312e of the processing target record is cleared (step S66), and the process proceeds to step S59 and subsequent steps.

  On the other hand, when the monitoring time is up (TIMdif2> Tout) (step S64, YES), the “monitoring time time-up consecutive occurrence count” 312e of the processing target record is updated (+1 increment or the like) (step S65). Further, the updated “monitoring time time-up continuous occurrence count” 312e is compared with the “monitoring time time-up continuous occurrence count” 212d of the processing target record, and whether or not the continuous occurrence count 312e exceeds the allowable count 212d. Is determined (step S67).

  If the number of consecutive occurrences 312e exceeds the allowable number 212d (step S67, YES), the task program 41 corresponding to the processing target record is considered to be abnormal, and the operation when the abnormality occurs is performed. That is, in this example, for example, the operation set in the “monitoring time up operation” 212e of the processing target record is performed (step S68). At this time, if the “function call” is set in the “operation when the monitoring time expires” 212e, the function registered in the “call function when the monitoring time expires” 212f is called.

  And it transfers to the process after step S59. However, in this case, if “CPU reset, system stop, etc.” is specified in the “operation when the monitoring time is up” 212e, these are executed, and the process does not proceed to step S59 and subsequent steps. Initialization processing and the like are performed.

On the other hand, if the number of consecutive occurrences 312e is less than or equal to the allowable number 212d (step S67, NO), the process proceeds to step S59 and subsequent steps.
Hereinafter, the processing after step S59 will be described.

  First, in step S59, based on the time stamp difference value (TIMdif), the refresh delay minimum time (Tmin), and the refresh delay maximum time (Tmax), the time stamp difference value (TIMdif) is within the refresh delay range. It is determined whether or not (Tmin ≦ TIMdif ≦ Tmax) (step S59). In other words, it is determined whether refresh has not been performed within the refresh prohibition period.

  When the time stamp difference value (TIMdif) is within the refresh delay range (Tmin ≦ TIMdif ≦ Tmax) (step S59, YES), the operation of the task program 41 corresponding to the processing target record is considered normal. Alternatively, the “prohibition period refresh occurrence count” 312f of the processing target record is cleared (step S60). Then, the process proceeds to step S61.

  On the other hand, when the time stamp difference value (TIMdif) is not within the refresh delay range (Tmin> TIMdif or TIMdif> Tmax) (step S59, NO), the operation of the task program 41 corresponding to the processing target record is performed. Assuming that there is a possibility of abnormality (runaway), the “prohibition period refresh continuous occurrence count” 312f of the record to be processed is updated (+1 increment or the like) (step S69). Further, the updated “prohibition period refresh occurrence count” 312f after the update is compared with the “prohibition period refresh occurrence allowable count” 212g of the processing target record to determine whether or not the consecutive occurrence count 312f exceeds the allowable count 212g. (Step S70).

  If the continuous occurrence count 312f exceeds the allowable count 212g (step S70, YES), the task program 41 corresponding to the processing target record is regarded as abnormal (runaway), and the operation at the occurrence of the abnormality is performed. In other words, in this example, for example, the operation set in the “prohibition period refresh operation” 212h of the processing target record is performed (step S71). When the “function call” is set in the “prohibition period refresh operation” 212h, the function registered in the “prohibition period refresh call function” 212i is called.

  And if operation | movement of step S71 is completed, it will transfer to step S61. However, in this case, if the CPU reset or the system stop is specified in the “prohibition period refresh operation” 212h, these are executed, so that the initialization process does not proceed to step S61. Etc. will be performed.

On the other hand, if the continuous occurrence count 312f is equal to or less than the allowable count 212g (step S70, NO), the process proceeds to step S61 as it is.
In step S61, the process target record is updated. That is, the processing target records in the monitoring condition setting table 21 and the refresh recording table 31 are respectively set to the next record of the current processing target record (the first record is the second record) and the variable “number of processing records”. Is updated (such as +1 increment). The variable “number of process records” is assumed to be “1” in the initialization process at the start of the process of FIG.

  If the “number of processing records” exceeds the “number of monitoring condition setting data” 211, it is determined that the monitoring processing has been executed for a predetermined number of records (YES in step S62). That is, the monitoring process is terminated assuming that the operation abnormality check has been completed for all the task programs 41.

  If the “number of processed records” is equal to or smaller than the set number (step S62, NO), there is an unprocessed record, so the process returns to step S54 and the same monitoring process as described above is performed for the new process target record To continue.

Here, the monitoring time-up in step S64 and the refresh delay range in step S59 (conversely, the refresh inhibition period) will be described with reference to FIG.
FIG. 9 is a diagram for explaining the monitoring timeout and the prohibition period.

  In FIG. 9, it is assumed that the refresh process (process of FIG. 7) is normally performed by the refresh processing unit 42 of the arbitrary task program 41 at the illustrated arbitrary timing t1.

  In this example, if the next refresh process is not executed before the refresh monitoring time (Tout) elapses from this timing t1 (before the timing t4 shown in the figure), the determination in step S64 is YES (monitoring timeout). ) Should be. That is, for example, when the monitoring process of FIG. 8 is performed at an arbitrary timing t5 after the illustrated timing t4 (further, when the next refresh process has not yet been performed at that time), the calculation is performed in step S63. The difference “TIMdif2” is “t5−t1”, and naturally “′ TIMdif2”> Tout ”(YES in step S64).

  Further, the period from the time point t1 to the time point (t2 in the figure) after the elapse of Tmin is defined as the refresh prohibition period. Further, the period from the timing t3 to the timing t4 shown in the figure is also the refresh prohibition period. Note that the timing t3 is the time when the above Tmax has elapsed from the timing t1.

  The reason why such a refresh prohibition period is provided is that the refresh process is frequently performed as shown in the figure when an arbitrary task program 41 loops infinitely, so that the refresh process is also performed during the refresh prohibition period. This is likely to be performed, and it can be determined that an infinite loop of the task has occurred.

  The refresh delay range in step S59 is, for example, the period shown in FIG. That is, it is a period from the timing t1 to before the refresh monitoring time (Tout) elapses, and is a period other than the refresh prohibition period. For example, if the task program 41 is normal, the refresh delay range is set by a developer or the like in consideration of a period during which the next refresh process is considered to be performed within the refresh delay range. Accordingly, a period outside the set refresh delay range becomes the refresh prohibition period.

  The monitoring process shown in FIG. 8 by the monitoring unit 24 detects an individual abnormality for each task program 41. On the other hand, even if it is not determined as abnormal in the process of FIG. 8, for example, it may be determined as abnormal by the process of FIG. That is, when there are a plurality of task programs 41 that are determined to be processed in a predetermined order, these are grouped so that the plurality of task programs 41 in the group are processed in a predetermined order. If not, it is determined as abnormal.

An example of processing for detecting such an abnormality is shown in FIG.
FIG. 10 is a flowchart for explaining the processing order monitoring operation of the monitoring unit 24.
Here, when the information processing apparatus shown in FIG. 1 is, for example, a computer (PLC; programmable controller) for a control system, a plurality of periodic tasks often operate. Furthermore, there are many cases where these plural periodic tasks are sequentially executed in a predetermined order. In such a case, the refresh processing for each of the periodic tasks is also sequentially executed in a predetermined order. Furthermore, there may be a plurality of groups in which a plurality of fixed-cycle tasks with such execution order determined as one group.

  For example, for each such group, it is checked whether or not a plurality of task programs 41 in the group are executed in a predetermined order. If they are not executed, it is determined as abnormal. For this purpose, an example in which the above-described check / abnormality determination is performed by the processing of FIG. 10 using the above-described refresh order setting table 22 and the refresh order recording table 32 will be described.

The process of FIG. 10 may be performed every time the process of FIG. 8 is executed, or may be performed at a fixed cycle regardless of the process of FIG.
In any case, when the monitoring unit 24 starts executing the processing of FIG. 10, first, the first record of the refresh order setting table 22 and the first record of the refresh order recording table 32 are set as processing target records (Step S81, S82).

  Note that the top record is the top of the “refresh order setting group data” 222 in the refresh order setting table 22 (“refresh order setting group data (1)” in FIG. 4), the refresh order recording table 32. Of the plurality of “refresh order record data” 322 (“refresh order record data (1)” in FIG. 6) in this example. Although it is a record, of course, it is not limited to this example.

Then, while sequentially changing the processing target records, the processing of steps S83 to S86 is performed on the processing target records at that time.
That is, first, each counter 322b (counter (1), counter (2),..., Which is recorded in the processing target record in the refresh order recording table 32 (initially “refresh order recording data (1)” as described above). -By comparing the counters (r)), it is confirmed whether the counter update order is in a predetermined order (step S83).

  Here, it is assumed that the predetermined order is the same as the order of the counter 322b (set as such). Therefore, in the illustrated example, the order is “counter (1) → counter (2) →... → counter (r−1) → counter (r) → counter (1) →. First, the counter 322b in which the latest update has been performed is identified. This means that the counter 322b with the latest update is the one whose counter 322b has the same value as the refresh common counter 322a.

  Then, the counter 322b of the latest update is viewed in the reverse order to check whether the counter value is decreased by one. For example, if the latest updated counter 322b is the counter (3) and its value is '100', if it is normal, the counter (2) is '99' and the counter (1) is '98'. The counter (r) should be '97' and the counter (r-1) should be '96'. It is checked whether or not each counter value is in this way. If it is, the order is normal (step S84, YES), and if not, the order is abnormal (step S84, NO). Is determined.

  When it is determined that the order is abnormal (when it can be considered that the processing is not executed in the set order) (step S84, NO), the above “operation at the time of abnormality” of the processing target record in the refresh order setting table 22 is performed. The operation according to 222a is executed (step S85). When the “function call” is set in the “abnormal operation” 222a, the function registered in the “abnormal call function” 222b is called.

  And if the process of step S85 is completed, it will transfer to step S86. However, if the CPU reset or the system stop is specified in the “operation when abnormal” 222a, these are executed, so that the initialization process is performed without proceeding to step S86. Become.

On the other hand, when it is determined that the order is normal (when it can be considered that the processing is being executed in the set order) (step S84, YES), the process directly proceeds to step S86.
In step S86, the next processing target record is determined for both the refresh order setting table 22 and the refresh order recording table 32. As described above, the first record is the processing target record at the beginning, so the second record is the next processing target record.

  However, if there is no next process target record (step S87, YES), the order monitoring process ends. If there is an unprocessed record (step S87, NO), the process returns to step S83, and the same processing as described above is performed for the next processing target record.

  As described above, according to this method, even in a program composed of a plurality of fixed-cycle processes (fixed-cycle tasks), it is possible to detect the occurrence of abnormality such as runaway for each task. In particular, it is possible to perform abnormality determination using an abnormality detection monitoring time and a refresh prohibition period for each task. Therefore, for example, even when a program of a certain periodic task is in the “infinite loop”, a program abnormality can be detected, and improvement in detection accuracy of program runaway can be expected.

Further, the process of FIG. 10 can also detect an abnormality in which a plurality of periodic tasks are not executed in a predetermined order.
Furthermore, it is possible to flexibly configure the operation after detecting an abnormality on the application side.

10 Program abnormality detection device 11 CPU
12 RAM
13 ROM
14 External I / F (interface)
20 Program Abnormality Detection Function Unit 21 Monitoring Condition Setting Table 22 Refresh Order Setting Table 23 Setting Unit 24 Monitoring Unit 30 Storage Area 31 Refresh Recording Table 32 Refresh Order Recording Table 40 Application Program Group 41 Program (Task)
42 Refresh processing unit 211 Number of monitoring condition setting data 212 Each monitoring condition setting data ((1) to (n))
212a Refresh monitoring minimum time 212b Refresh delay minimum time 212c Refresh delay maximum time 212d Monitoring time time-up continuous occurrence allowable number 212e Monitoring time time-up operation 212f Monitoring time time-up calling function 212g Prohibition period refresh continuous occurrence allowable number 212h Prohibition period refresh Time operation 212i Calling function 221 during refresh period prohibited Refresh number setting group number 222 Refresh order setting group data ((1) to (m))
222a Abnormal operation 222b Abnormal call function 222c Order setting data number 222d Monitoring condition setting data identifier ((1) to (r))
311 Number of refresh record data 312 Refresh record data ((1) to (n))
312a Refresh counter current value 312b Time stamp current value 312c Refresh counter previous value 312d Time stamp previous value 312e Monitoring time time-up consecutive occurrence count 312f Prohibited period refresh occurrence count 321 Refresh recording data count 322 Refresh sequence recording data ((1) to) (M))
322a Refresh common counter 322b Counter ((1) to (r))

Claims (6)

A program abnormality detection device for detecting an abnormality of a program composed of a plurality of periodic tasks,
Refresh information storage means for storing predetermined refresh information corresponding to each fixed-cycle task;
Condition registration means for registering a temporal condition related to refresh processing executed by the fixed-cycle task corresponding to each fixed-cycle task,
Each of the periodic tasks has refresh means for updating the refresh information corresponding to the periodic tasks as the refresh processing,
Periodically, for each of the periodic tasks, it is determined whether or not the temporal condition is satisfied by referring to the corresponding refresh information, and if the temporal condition is not satisfied, or continuous multiple times When the time condition is not satisfied, the monitoring means determines that the periodic task is abnormal ,
The temporal conditions are a monitoring timeout period and a refresh prohibition period,
The monitoring means, for each of the periodic tasks, when the next refresh process is not executed from when any refresh process is executed until the monitor timeout period elapses, or within the refresh prohibition period A program abnormality detection apparatus , wherein when the process is executed, it is determined that the time condition is not satisfied . The refresh prohibition period is a period from the execution of any of the refresh processes to the elapse of the monitoring timeout period, and from the execution of any of the refresh processes to a time when a predetermined first time elapses. The program abnormality detection device according to claim 1, wherein: The refresh prohibition period is within a period from the execution of any of the refresh processes until the monitoring timeout period elapses, and from the time when a predetermined second time elapses from the execution of any of the refresh processes, 2. The program abnormality detection apparatus according to claim 1 , wherein the program abnormality detection period is a period until a time has elapsed. In the condition registration means, an operation corresponding to a case where the periodic task is determined to be abnormal is registered for each of the periodic tasks.
Said monitoring means, if it is decided that an abnormality for any periodic task, the program according to any one of claims 1 to 3, characterized in that performing an operation that is the registration corresponding to the periodic task Anomaly detection device. A counter value provided in accordance with the execution order corresponding to each fixed-cycle task that is the execution order monitoring target, with a plurality of fixed-period tasks having an execution order determined among the plurality of fixed-cycle tasks as execution order monitoring targets Storage means;
A common counter that is a counter common to a plurality of periodic tasks to be monitored for execution order;
The refresh means for each periodic task to be monitored for execution order updates the common counter during the refresh process, and stores the counter value in the counter value storage means corresponding to itself,
The monitoring means further executes a process of determining whether or not a plurality of periodic tasks to be monitored for execution order are being executed in the execution order by referring to the counter value storage means. The program abnormality detection device according to any one of claims 1 to 4 . A computer of a program abnormality detection device that detects a program abnormality composed of a plurality of periodic tasks,
Refresh information storage means for storing predetermined refresh information corresponding to each fixed-cycle task;
As a time condition regarding the refresh process executed by the fixed-cycle task corresponding to each fixed-cycle task, it has a condition registration means for registering a monitoring timeout period and a refresh prohibition period ,
Each of the periodic tasks has refresh means for updating the refresh information corresponding to the periodic tasks as the refresh processing,
Periodically, for each of the periodic tasks, it is determined whether or not the temporal condition is satisfied by referring to the corresponding refresh information, and if the temporal condition is not satisfied, or continuous multiple times If the time condition is not satisfied, it is means for determining that the periodic task is abnormal, and the monitoring timeout period elapses from the execution of any of the refresh processes for each of the periodic tasks. Monitoring means for determining that the temporal condition is not satisfied if the next refresh process has not been executed before or if the refresh process is executed within the refresh inhibition period ,
Program to function as.

Images