Section: New Results

Scenario Analysis Module

Participants : Sabine Moisan, Annie Ressouche, Jean Paul Rigault.

To generate activity recognition systems we supply a scenario analysis module (SAM) to express and recognize complex events from primitive events generated by SUP or others sensors. In this framework, this year we focus on recognition algorithm improvement in order to face the problem of large number of scenario instances recognition.

The purpose of this research axis is to offer a generic tool to express and recognize activities. Genericity means that the tool should accommodate any kind of activities and be easily specialized for a particular framework. In practice, we propose a concrete language to specify activities in the form of a set of scenarios with temporal constraints between scenarios. This language allows domain experts to describe their own scenario models. To recognize instances of these models, we consider the activity descriptions as synchronous reactive systems  [69] and we apply general modeling methods  [62] to express scenario behaviors. This approach facilitates scenario validation and allows us to generate a recognizer for each scenario model. The sam module thus provides users with (1) a simulation tool to test scenario behaviors; (2) a generator of a recognizer for each scenario model; (3) an exhaustive verification of safety properties relying on model checking techniques our approach allows. The latter offers also the possibility to define safety properties to prove as “observers”  [63] expressed in the scenario language.

Last year we have completed sam in order to address the life cycle of scenario instances. For a given scenario model there may exist several (possibly many) instances at different evolution states. These instances are created and deleted dynamically, according to the input event flow. The challenge is to manage the creation/destruction of this large set of scenario instances efficiently (in time and space), to dispatch events to expecting instances, and to make them evolve independently. This year, to face this challenge we first replace some operators of the language, by others having a more strict semantics. For instance, we replace the before operator whose semantics allowed that events can meet, by two operators , a strict before and a meet. Hence, the number of events a scenario instance reacts to decreases. Second, we now generate within the recognition engine, the expected events of the next step. This avoids to run the engine automatically with events that are not relevant for the recognition process.

Presently, we still rely on the existing synchronous language (Lustre  [62] ) to express the equational semantics of scenario models and to generate recognizers because this language offers simulation and verification means. But, to improve efficiency, we plan to build our own compiler and to generate recognizers directly from the Boolean equation systems modeling scenario models. This implies that we must supply our own simulation tool and that we interface with a model checking tool as NuSMV  [57] .

Now the challenge is to take into account some uncertainty on the primitive events due to input sensor errors. In the family of synchronous languages, the Lutin language (http://www-verimag.imag.fr/Lutin.html ) could be able to automate the generation of realistic input sequences of events, taking into account probabilistic distributions over primitive events. In other words, it could generate a set of input events for which a set a constraints can be verified. In complement, it offers also means to compute the real values verifying these constraints. Thus, we think to rely on Lutin to express uncertainty on primitive events and get input events to feed scenario recognition engines.