Information Technology Reference
In-Depth Information
where the first argument of event objects is the wave type, the second is a timestamp
giving the occurrence time of the events and the third qualifies the wave shape.
6
Diagnosis by Chronicle Recognition
In model-based diagnosis, a model of either normal or faulty behavior is used to detect
and identify faults or diseases [28,5]. If a normal behavioral model is used, the val-
ues reflecting the patient state are fed into the model and the diagnoser generates an
alarm if the model outputs are different from the values observed on the patient. With a
faulty causal model, the diagnoser reasons abductively from observations to faults and
attempts to generate disease hypotheses that could have produced the actual observa-
tions. Sometimes, such a model can be compiled into sets of discriminant patterns that
can be efficiently searched for on the input stream. This method is very suited to online
monitoring: the input data stream is analyzed continuously and an alarm is emitted in
case a set of events that can be related to a disease have been observed in some time
window.
In many situations, such as in the case of dynamic systems, time is crucial [4]. The
events related to the course of a disease must happen in a specific order and have to
respect delay constraints. Moreover, sometimes it is easier to describe a disease by a
set of successive or synchronous events respecting temporal constraints than to extract
discriminant features from a vector of values recorded by several sensors. This is true
in the cardiac domain: the symptom related to some disease, e.g. bigeminy, is described
more naturally by the properties of several cardiac beats than by the particular features
of a QRS, for instance. Chronicles are particularly suited for the representation of such
temporal patterns. Fig. 4 shows the graphical representation of an example of chronicle
related to bigeminy and an example of match on two types of signal.
Fig. 5 gives the textual specification of the same chronicle. The syntax is very intu-
itive. Events are specified by the keyword
event
which have two arguments, the event
type with optional attributes enclosed in square brackets and a time variable represent-
ing the instant at which the event will occur. Such a variable is instantiated at runtime
when an event of the corresponding type is observed on the input stream. Set constraints
can be put on attribute variables. Temporal variables can be linked by binary temporal
constraints, e.g. in line 4: this constraint says that the delay between the occurrence of
a P wave at P1 and the occurence of the following QRS complex at R1 is at least 80
ms and at most 120 ms. All the temporal variables of a chronicle are organized in an
STP [6] that can be efficiently processed at runtime. Finally, the overall duration of the
episode matched by the chronicle can be specified by a temporal constraint involving
the special instants
start
and
end
.
Since input data streams can be huge, recognizing chronicles on the fly must be
very efficient. We have used a system called CRS (Chronicle Recognition System) [10]
which manages chronicle models, chronicle instances created after detecting events
specified in the associated chronicle model and temporal constraints between events
belonging to some instance. CRS tries to associate each incoming event with some
uninstantiated event of a chronicle instance which satisfies the temporal constraints. It
generates also new chronicle instances containing an event that can match the observed
Search WWH ::
Custom Search