Definition of complex phenomena

Appropriate combinations of heterogeneous sensor features enable more precise and complex event detection facilities [62]. Almost all sensor network applica-tions define threshold values for certain measurements, called primitive events, and fire an event if current sensor readings match or exceed these values. The ESL provides means to easily combine several sensing capabilities and respec-tive primirespec-tive events to complex ones within the <SENSORDATA> element.

30 CHAPTER 3. COMPLEX FAULT TOLERANT EVENT DEFINITION

Primitive events can be defined as the sensor reading matching an exact value or through single-bounded intervals the sensor reading falls into by using the following relational elements:

ˆ <EQUAL>,

ˆ <LESS>,

ˆ <GREATER>,

ˆ <LESSOREQUAL>,

ˆ <GREATEROREQUAL>.

These elements define respective binary relations between two elements, which are variables, constants and/or mathematical functions defined on top of these.

The result of a relation is of Boolean type. The usage of these elements is dis-cussed in the next Section. Please note, except for the equality relation these elements are not commutative and hence, require correct order of the assigned el-ements. It is quite obvious that (temperature <10) is semantically different from (10< temperature), for example. To support definition of complex phenomena, configured thresholds can be composed by logic operations. Logic operations are specified by own tags, namely:

ˆ <AND>,

ˆ <OR>,

ˆ <NOT>.

Similar to the relational elements, the elements<AND>and<OR>define a respective logic operation between two relational or two logic elements or a mix of both. Since these operations are commutative, the order of the linked elements is irrelevant. The <NOT>element specifies an unary operation and can only be used on top of one relational or logic element. As known from Boolean algebra, it inverses the Boolean result of the underlying element. Of course, it is also possible to link several logic operations together. Logic elements further allow to define 2-bounded intervals for certain sensing capability by combining several primitive events. For example, measuring a temperature between 20 and 25 results in a combination of two primitive events, i.e., (temp > 20) AND (temp

<25). A respective<SENSORDATA>is exemplarily given in Listing 3.2. This event configuration evaluates to TRUE if temperature readings are between 20 and 25 centigrade.

To simplify matters only three logic elements are available, but these are quite enough to define every possible logic combination. Supporting more language elements may slightly increase the usability for end-users but even implies to implement more complex interpretation means on the sensor nodes. This would require to use more processing and memory resources. For this reason and to keep the language quite simple, the integration of further logic elements like NAND or NOR, is omitted. This is vitally important for implementing a language interpreter on sensor nodes, which usually provide scarce resources only.

3.2. SPECIFYING COMPLEX EVENT DETECTION 31

<SENSORDATA>

<AND>

<GREATER>

<VARIABLE> t e m p e r a t u r e </VARIABLE>

<CONSTANT u n i t=” c e n t i g r a d e ”> 20 </CONSTANT>

</GREATER>

<LESS>

<VARIABLE> t e m p e r a t u r e </VARIABLE>

<CONSTANT u n i t=” c e n t i g r a d e ”> 25 </CONSTANT>

</LESS>

</AND>

</SENSORDATA>

Listing 3.2: Example sensor data element of a composite event, which detects temperature between 20 and 25 centigrade.

Mapping of sensing capabilities, thresholds and mathematical functions Configuring events primarily requires to set thresholds for certain sensor read-ings using relational elements. As mentioned above, relational elements enable to define respective relations between two variables, constants and/or mathemat-ical functions. A variable identifies a sensing capability and is defined by the

<VARIABLE> element. Thus, the value of a variable is given at run-time by sensor readings. In contrast to that, the <CONSTANT>element defines a con-stant value, which can be used as a threshold. Concon-stants usually require to set an additional measuring unit. The “unit” attribute allows to assign different units to constants, e.g., time and distance units like “seconds”, “minutes”, “meters”

etc. In certain cases constants may not require a unit, for example if a pure quantity is in demand. Such a constant is specified without the “unit” attribute.

Conversion of the specified constants with respect to the hard- and software used on the sensor nodes, e.g., converting seconds to milliseconds if necessary, is task of the language interpreter and is not of concern for the user. That allows for straightforward event definition, even practicable for the non-professional user.

Whereas relational and logic elements generate Boolean results, variables and constants apply numerical values. To support a broad usability as well as to enable conversion of values, theESLenables to define binary mathematical func-tions using variables, constants or results of further funcfunc-tions as parameters.

Consequently, functions result in numerical values. TheESLprovides the follow-ing functions:

ˆ <SUM>,

ˆ <DIFFERENCE>,

ˆ <PRODUCT>,

ˆ <QUOTIENT>,

ˆ <MODULO>.

32 CHAPTER 3. COMPLEX FAULT TOLERANT EVENT DEFINITION

Please take note, differences, quotients or modulo functions are not commuta-tive. Just as mentioned at relational elements, even here the order of the applied parameters is crucial.

By design, theESLalso allows to define relations between two sensor readings or intermediate results of equal type. Since this is feasible for variables and func-tions, e.g., for comparing inside and outside temperature readings of a building, its application is rather useless for two constants. The result of such relation is of constant Boolean type, too. In that case, the event specification is redesigned and the Boolean result of such relation is directly inserted instead.

3.2.3 Addition of execution constraints and associated handlers