INRIA Sophia Antipolis-Méditerranée
2004 route des lucioles
BP93 06902 Sophia Antipolis France

The SAM project


In the design process of most systems supervising people or goods, part of the work required deals with the automatic recognition of activities. The application areas for activities recognition systems are mostly surveillance and safety. But they are also gaining importance in the healthcare field. Such systems listen to heterogeneous environmental sensors and provide an accurate report about the behavior of observed targets.

The purpose is to develop systems to design and analyze activities in real time, in order to improve the Scene Understanding Platform (SUP) being designed in our team. Typical examples of activities we aim to recognize are spatio-temporal activities in the physical world performed by human beings, animals and/or vehicles.

here is an example of SUP platform use in the domain of healthcare for elderly.

Particularly, we are interested in the design of activity recognition engine generators ensuring genericity, modularity, reusability, extensibility, dependability, and maintainability. To tackle this challenge, we rely on the correct theoretical foundations of formal methods, and on state of the art in Software Engineering practices.

Activity Recognition

We are studying and developing a module to analyze activities. Scenarios are mostly used to specify the way a system may react to input events coming from different kinds of sensors. We are designing a recognition module (sam) to define, analyze, simulate, and prove scenarios. Our models of scenarios deal with both real time (to be realistic and efficient in the analysis phase) and logical time (to benefit from well-known mathematical models providing re-usability, easy extension and verification). Our purpose 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.

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 and we apply general modeling methods 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

Pratical Issues

The sam-l Language

sam is developed around a language sam-l devoted to design activities. This latter expressive enough to define all kinds of spatio-temporal scenario models and also user-friendly, for users of different applicative domains. sam-l allows to define an activity as a set of scenario models. Primitive scenarios concern basic events listened from the environment. Composite scenarios allow to express temporal combinations of sub scenarios. A scenario model is designed in a declarative way: it takes typed arguments representing physical entities it deals with.

Scenarios handle external data (types, functions, events and constants) declared in a data declaration part and provided by the user in an external code (or pre defined libraries). Data are useful to express basic events coming from sensors, they ensure the language to be general. Composite scenarios are composed of (1) components which are sub scenario calls; (2) a set of temporal relations between components; (3) a set of temporal forbidden relations and (4) a set of spatio-temporal constraints. Temporal relations specify how scenario components occur with respect to a logical time. They are described with the help of specific temporal relations ( before, overlap, during, meets ) native in sam-l.

In addition, an exclusive or relation (|) helps user to express choice between sub scenarios. The analysis process has in charge to verify that these relations hold. On the opposite hand, forbidden relations stop the recognition process when they are verified.

Finally, our constraints are able to define spatio-temporal relationships between sub scenarios we cannot pinpoint with the temporal operators of the language. The language offers primitives to express them:

Moreover, usual Boolean functions and user data Boolean functions provide also means to define spatio constraints. Relations differ from temporal constraints because they express requirements on the temporal evolution of a scenario, while constraints must hold at each instant. Notice also that sam-l Here is an example extracted from an application in the domain of healthcare for elderly.

Activity Recognition Engine Generation

The sam module has in charge to generate recognition engine for scenarios described with the sam-l language. Relying on a theoretical approach, we defined a constructive behavioral semantics for the language sam-l. Then Boolean equation systems for scenarios are computed following the rules of this semantics. These equation systems represent scenario models and support simulation, verification and generation of scenario analysis engine in C/C++ languages.

sam code generation

To carry out our approach, we rely on the Lustre synchronous language which helps us to define and validate activities. It is a data flow language offering two main advantages:

  1. It is a functional language with no complex side effects. This makes it well adapted to formal verification and safe program transformation, since functional relations over data flows may be seen as time invariant properties. Also, reuse is made easier, which is an interesting feature for reliable programming concerns;
  2. )
  3. Its equational nature offers us straightaway representation of both Boolean equations and non Boolean equations related to physical constraints. Thus, the call to an external constraint solver is avoided.

Moreover, it offers simulation and verification facilities as well as a C generation code. To perform validation we use the Lesar model checker, back end of the Lustre language. In Lesar, the observer technique applies. According to this technique, a safety property &rho can be mapped to a program &Omega which runs in parallel with a program P and observes its behavior, in the sense that at each instant &Omega reads both inputs and outputs of P. If &Omega detects that P has violated &rho then it raises an alarm. For instance, on the previously mentioned example , to verify the scenario useMicrowave we defined an observer in Lustre designing the safety property: if termination flag occurs then termination flag of m_used component has been true in some previous instant and we verified it with Lesar

return top