A special note should be made about how the counting of events is performed.
Since many monitoring systems produce a reading every minute, if each reading is
counted separately, a biased result would be achieved due to the existence of long
events and short events. For example, if (as an extreme case) a situation with a wrong
measurement (due to instrument dropouts or calibration drift, etc.) produces a FP
condition which lasts for several days (until the measuring device is fixed), a large
amount of records classified as FP will be counted and will adversely affect the result
of the model accuracy. In order to avoid such a situation, counting of events should
be referenced to events and not to single records. Hence, an event needs to be
defined.
An event is a situation in which the value of RBF crossed the HRL to the high
side for a substantial amount of time (this amount of time should be set by the
users) after being located below the HRL for a substantial amount of time (also
this amount of time should be set by the user).
The above definitions imply that two time lags should be defined. The first one is
how long the algorithm should wait, when the process crosses the HRL to the upper
side, to declare an event. This one will be called a Delay On time. The second one is
how long the algorithm should wait when a process crosses the HRL to the lower
side before an end of event should be declared. This one will be called a Delay Off
time. Based on the two delay time definitions, the algorithm classification method
should be updated with the following additional rules:
Rule 1 In case of a long period of no event, the process crosses the HRL to the upper
side and then goes back to the lower side of the HRL, and a TN event will be
declared. See Fig. 5 as an example of Delay On.
Figure 5 is a representation of a TN since in this case the system (the algorithm)
did not generate an alarm even if a violation of the HRL occurred. This is due to the
Delay On mechanism.
Rule 2 In the case that, after an event has started, the process oscillates above and
below the HRL without achieving either the Delay On or Delay Off amount of time,
the counting of the events will not be incremented. See Fig. 6 for an example.
The values of the Delay On time and the Delay Off time should also be added to
the process of algorithm parameter selection. Thus, the target of the algorithm tuning
is a selection of the values of W(s), HRL, Delay On, and Delay Off in order to
optimize the results described in Table 1. Once again it should be noted that
optimizing the values in Table 1 means optimizing the Cohen’s kappa, the sensitivity
and specificity.
Using Radial Basis Function for Water Quality Events Detection
149
Since many monitoring systems produce a reading every minute, if each reading is
counted separately, a biased result would be achieved due to the existence of long
events and short events. For example, if (as an extreme case) a situation with a wrong
measurement (due to instrument dropouts or calibration drift, etc.) produces a FP
condition which lasts for several days (until the measuring device is fixed), a large
amount of records classified as FP will be counted and will adversely affect the result
of the model accuracy. In order to avoid such a situation, counting of events should
be referenced to events and not to single records. Hence, an event needs to be
defined.
An event is a situation in which the value of RBF crossed the HRL to the high
side for a substantial amount of time (this amount of time should be set by the
users) after being located below the HRL for a substantial amount of time (also
this amount of time should be set by the user).
The above definitions imply that two time lags should be defined. The first one is
how long the algorithm should wait, when the process crosses the HRL to the upper
side, to declare an event. This one will be called a Delay On time. The second one is
how long the algorithm should wait when a process crosses the HRL to the lower
side before an end of event should be declared. This one will be called a Delay Off
time. Based on the two delay time definitions, the algorithm classification method
should be updated with the following additional rules:
Rule 1 In case of a long period of no event, the process crosses the HRL to the upper
side and then goes back to the lower side of the HRL, and a TN event will be
declared. See Fig. 5 as an example of Delay On.
Figure 5 is a representation of a TN since in this case the system (the algorithm)
did not generate an alarm even if a violation of the HRL occurred. This is due to the
Delay On mechanism.
Rule 2 In the case that, after an event has started, the process oscillates above and
below the HRL without achieving either the Delay On or Delay Off amount of time,
the counting of the events will not be incremented. See Fig. 6 for an example.
The values of the Delay On time and the Delay Off time should also be added to
the process of algorithm parameter selection. Thus, the target of the algorithm tuning
is a selection of the values of W(s), HRL, Delay On, and Delay Off in order to
optimize the results described in Table 1. Once again it should be noted that
optimizing the values in Table 1 means optimizing the Cohen’s kappa, the sensitivity
and specificity.
Using Radial Basis Function for Water Quality Events Detection
149