Creation of event descriptions

After adaptation, all elements are successively transformed into minimised de-scriptions before being deployed as an event description. An event description consecutively lists all five basic elements of the respective event specification.

44 CHAPTER 3. COMPLEX FAULT TOLERANT EVENT DEFINITION

ESL-element Description element

<AND> &

<OR> |

<NOT> !

<EQUAL> =

<GREATER> >

<LESS> <

<GREATEROREQUAL> >=

<LESSOREQUAL> <=

<SUM> +

<DIFFERENCE> #

<PRODUCT> *

<QUOTIENT> /

<MODULO> %

<TIMEINTERVAL> I

<NUMBEROFVOTES> V

<DEADLINE> D

<NODEVICES> N

<CIRCLE> C

<SQUARE> S

<BALL> B

<CUBE> K

<HOPS> H

Table 3.1: Conversion table containing event specification elements and respective event description elements. Elements of the event specification that are not listed here need not be converted since these are represented by the fixed structure of the event description.

Keeping a given order allows to describe these elements by their content only.

More precisely, each description lists the event header, followed by the sensor data element, the event handlers, the execution constraint, the dimension con-straint and finally the voting concon-straints in exactly that order.

In the shortened form, all parameters of the event header are associated to one string. Whereas lease and version numbers as well as the event id are directly taken, the attributes priority and reliableMode are represented by their first character only. For the given example, the short event header fire.1h6y represents version 1 of the event fire, which assigns a high priority and a lease factor of 6 while enabling the reliable mode (y).

The sensor data element is converted to a minimised prefix (or polish) notation of the respectiveXMLsubtree. The prefix notation places operators to the left of their operands. Since the arity of theESLoperators is fixed, which is here one for the NOT and two for all other elements, the result is a syntax without brackets

3.5. GENERATION OF DEPLOYABLE EVENT DESCRIPTIONS 45

Figure 3.5: Final event description of the introduced fire detection example.

This description contains all necessary information for configuring sensing de-vices according to the event specification. The numbers displayed on top of the description represent the respective offset addresses in the byte stream.

that can still be parsed without ambiguity. Consecutively listed variables and constants can in principle not be distinguished. Variable names are allowed to contain numbers. Hence, an implicit delimitation from the following constant (numbers only) cannot be achieved. Therefore, a constant that follows a variable is additionally separated by a comma. In contrast to that, the case of a variable following a constant is implicitly identified and allows to omit the comma, since variables have to begin with an alphabetic character while constants contain numbers only. To minimise the final description size, the tags of theESLelements are represented by short symbols, see Table 3.1. These symbols are assigned via the hardware abstraction layer and may differ depending on the target platform.

Additionally please note, usually the - or the ∆ symbolise the mathematical difference operation. Herein, the # is used to symbolise the difference operation.

Automatic distinction of the-symbol when being used for signed constants and differences as well, is unsuitable since it increases the parsing complexity. The ∆ symbol is not used because it is not contained in the standard ASCII character set and may be not supported by each sensor platform. For the same reason, the use of symbols ≤and≥is deprecated. The character sequences <= and >= are used to describe the respective operations.

As the next part, the event handlers are added to the description, which are consecutively listed and separated by comma. Finally, the event constraints are minimised. An event constraint consists of its short identifier, followed by the symbolised relation attribute and one or two constants respectively. The event description is completed by adding the remaining elements containing constraints only, these are the execution element, the dimension element and the voting element. The voting element consists of at most four constraints, i.e., the voting region, the number of votes, the deadline and the no-devices element, theses elements are additionally separated by semicolons. Since event constraints have a fixed structure these are not parsed by the introducedEDT-engine to keep the GFSMsimple. Event constraints are described as infix notation and are evaluated by string matching operations according to the regular expression given in (3.1).

[A−Za−z]⁺[<|>|=|<=|>=|<>]^{1}[0−9]⁺([,]^{1}[0−9]⁺)^{0,1} (3.1)

46 CHAPTER 3. COMPLEX FAULT TOLERANT EVENT DEFINITION

Event descriptions are transmitted as Byte-Streams to the sensor nodes where-by the basic elements are separated where-by colons. Unspecified elements, or omitted optional ones respectively, are represented by an empty placeholder. Hence, an omitted basic element result in two consecutively listed colons. Ensuring such strict layout reduces the size of event descriptions compared to the XML-styled event specification by an average factor of ten. For instance, that allows to scale the size of the introduced event specification for fire detection by a factor of 13 from 949 Bytes plus white-spaces down to 69 Bytes provided as event description.

Figure 3.5displays the respective event description.

Chapter 4

Deployment on Sensor Nodes as Event Decision Tree (EDT)

This Chapter presents how sensor nodes are configured according toESL-designed event specifications. More precisely, it describes the conversion of event descrip-tions into their processable form as Event Decision Tree (EDT) [48,49]. It pro-vides details about configuration and maintenance of those, which are performed by the EDT-engine on each sensor node. This includes implementation features of the generation and evaluation of the EDT as well as dividing complex events into less complex ones based on the sensing facilities of individual sensor nodes.

It further introduces efficient means to detect nodes for collaboration, which can provide missing information to evaluate the complete EDT. Finally, simulation results of a prototype implementation applied to various failure scenarios under-line the cost-efficiency of the presented approaches.

4.1 Architecture of the EDT-engine

On the sensor nodes, the EDT-engine configures the sensor node with respect to each received event description. The architecture of theEDT-engine is displayed in Figure 4.1. First, the EDT generator processes the sensor data element of every incoming event description in a tiny GFSM with eight states. As a result it generates the respective event representation (phenomenon to be sensed) as an EDT. Depending on the sensing features and resources provided by the node, theEDTadaptation splits thisEDTinto local and remote parts. Local parts can be evaluated by the node itself, whereas remote parts have to be requested from external sources, e.g., from neighbouring nodes. The EDT adaptation further adapts and configures event related constraints as parameters of the EDT, i.e.,

47

48 CHAPTER 4. DEPLOYMENT ON SENSOR NODES ASEDT

event regions, handlers, voting constraints etc.

The final EDT is integrated to the EDT processing unit that maintains the compliance with all parameters of the configured EDTs. The EDT processing unit consists of theEDT evaluation, anEDT scheduler and aHandler box. The EDTscheduler autonomously schedules allEDTs with respect to their configured evaluation intervals. This schedule is currently implemented by timers assigned to each EDT. On timer wakeup, the respective EDT is enqueued into a queue that holds all EDT pending for execution. That guaranties the evaluation of all EDT, even if several of them are triggered simultaneously or with short lags.

This queue is in principle a First In First Out (FIFO) queue, but as a second cri-teria for scheduling the enqueued EDTs are sorted with respect to their assigned priority. The priority can be low, normal or high respectively. EDTs with a high priority are ranked first of course. Similarly the EDTs with a low priority are added to the end of the queue. Future implementations are supposed to use avail-able schedulers of the underlyingOS, such as the Earliest Deadline First (EDF) scheduler ofREFLEX[70], to provide a more precise and fair scheduling.

On dispatching anEDT into the EDT evaluation for execution, the sensing devices are triggered to deliver actual sensor readings required to decide about the existence of the described phenomenon by evaluation of the EDT. In case of a positive evaluation result, either a voting is triggered or the Handler box is called to execute respective associated handle methods. The EDT evaluation also manages collaboration with other sensor node if necessary. Details about collaboration are given later in this Chapter.

Finally, the timer of theEDTis set up to the next evaluation interval and the EDT is returned to the EDT scheduler. In addition to the configured evaluation interval, EDTs are also be triggered on demand by voting and collaboration re-quests from other devices. In that case,EDT evaluation is executed as usual but consequently triggers answering the request, too. After finishing an unscheduled evaluation, the corresponding timer is set to a full detection interval again. On the one hand, that assures a sufficient detection interval as required by the spec-ification. On the other hand, it simultaneously reduces the number of evaluation processes to a certain minimum to save energy resources.