SHORT INTRODUCTION TO PerLa MIDDLEWARE

SHORT INTRODUCTION TO PerLa MIDDLEWARE

M. Fortunato, M. Marelli

Politecnico di Milano, Dipartimento di Elettronica e Informazione,

Milano, Italy

A DATA LANGUAGE FOR

PERVASIVE SYSTEMS

FULL DECLARATIVE SQL-LIKE HIGH LEVEL LANGUAGE

to query

PERVASIVE SYSTEMS

hiding the complexityof handling

DIFFERENT TECHNOLOGIES

HIGH LEVEL QUERIES

(HLQ)

LOW LEVEL QUERIES

(LLQ)

ACTUATION QUERIES

(AQ)

• The PILOT JOIN operation was introduced to activate the execution of a certain low level query on a device, only when some conditions on DATA SAMPLED BY OTHER NODES are satisfied.

• The pilot join operation seems to be strictly related to the concept of CONTEXT AWARE DATA TAILORING.

M.Marino, PILOT JOIN ANALYSIS

PILOT JOIN OPERATION

A DATA LANGUAGE FOR PERVASIVE SYSTEMS

LOGICAL OBJECT ABSTRACTION

• The LANGUAGE SEMANTICS is defined on the concept of LOGICAL OBJECT


• Each device is abstracted as a logical object:

– ATTRIBUTES (id, temperature, pressure, power level, last sensed RFID reader, …)

– EVENTS (last sensed RFID reader changed, …)

– META-DESCRIPTION (name, data type, … for each attribute)

CHANNEL

(Serial, Socket)

LOGICAL OBJECT

Physicaldevice

AttributesEvents

Metadescription

• A MIDDLEWARE is needed to provide an implementation of the logical object abstraction.

MIDDLEWARE


WSN

QUERY PARSER

LOGICAL OBJECTS REGISTRY

HIGH LEVEL QUERY EXECUTOR

Physical device

Physical devices

Textual queries Queries results

LOW LEVEL QUERY EXECUTOR

LOGICAL OBJECT IMPLEMENTATION

QUERY ANALYZER





Lower interface

Upper interface

• The main goals of the middleware are:

1. providing an ABSTRACTION for each device

2. supporting the EXECUTION OF PERLA QUERIES

3. allowing devices to automatically start query execution when they are powered on (PLUG & PLAY)

4. making the DEFINITION and the ADDITION of new devices (and new technologies) easy, reducing the amount of the needed low level code

MIDDLEWARE GOALS (1)




1. providing an ABSTRACTION for each device

• The FPC (Functionality Proxy Component) is defined as a Java object representing a physical device.

• The FPC must be instantiated on a node:

– running a Java Virtual Machine (JVM)

– connected to the TCP-IP network

• The middleware should manage the COMMUNICATION PROTOCOL between FPC and physical device

FPC

Physical device

JAVA + TCP/IP



2. supporting the EXECUTION OF PERLA QUERIES

• The LLQE (Low Level Queries Executor) is a Java component placed on the FPC.

• It is charged to retrieve needed data from the underlying FPC and to compute QUERY RESULTS.

FPC

LLQE• An LLQE should support the simultaneous execution of all the low level queries running on the node.

D. Viganò, Low Level Query Executor architecture



3. allowing devices to automatically start query execution when they are powered on (PLUG & PLAY)

G. Rota, FPC Factory and devices self-description

• A PLUG & PLAY behavior at device start-up requires that:

– An FPC object (providing a Java proxy to interact with the physical node) have to be DYNAMICALLY GENERATED and instantiated

– The CONNECTION between FPC and physical node have to be established

– The generated FPC have to be REGISTERED in the FPC registry, in order to allow the parser to consider also the new device



4. making the DEFINITION and the ADDITION of new devices (and new technologies) easy, reducing the

amount of the needed low level code

G. Rota, FPC Factory and devices self-description

• A device SELF-DESCRIPTION file can be introduced to allow a complete automatic generation of the Java FPC

• A low level C LIBRARY can be introduced to reduce the amount of required C code needed to manage the new technology

– HLD: middleware provided C code (FPC-device communication, timer multiplexing, sampling scheduling, …)

– LLD: user provided C code (low level sampling routines, communication channel initialization, …)

MIDDLEWARE ARCHITECTURE


Physical device

JAVA + TCP/IP

FPC

LLQE

HLD

LLD

FPC FACTORYFPC

REGISTRY

SELF-DESCRIPTION

R. Camplani: A proposal for the Low Level C library architecture

PerLa MIDDLEWARE ARCHITECTURE

G. Rota


Milano, Italy

• PerLa Middleware Goals

• Global overview of the PerLa middleware

• Logical objects and FPC

• Boundaries of the Middleware: HLD and LLD

• Factory and FPC assembling

• Device multiplexing

• Network heterogeneity

• Open points

PerLa MIDDLEWARE ARCHITECTURE

• Ensure the PerLa language can work in spite of the underlying hardware heterogeneity

– Provide a REGULAR APPROACH to access different devices

– Provide a REGISTRY to keep track of the devices’ state

• Enable the system to automatically recognize and hook-up new devices in a PLUG & PLAY FASHION

– The system adapts itself to new devices

– Reduce the end user’s programming effort as much as possible

• Support for new modules and extensions

PerLa MIDDLEWARE GOALS

PerLa MIDDLEWARE GOALS

• The LOGICAL OBJECTS are a HIGH-LEVEL ABSTRACTION of the physical devices. They have to provide:

– A list of the supported attributes and events

– An interface to set or retrieve attributes on the device

– Notifications to the system in response to events sensed by the devices

• The FPC (Functional Proxy Component) is a JAVA IMPLEMENTATION of the Logical Object functionalities

– The communication between the Low Level Query Executor and the hardware devices are mediated by the FPC

– Every FPC is tailored to fit a single sensor (or a group of them)

– The system is provided with a FPC Factory, which automatically assembles FPCs on behalf of the user

LOGICAL OBJECTS AND FPCs

PerLa SWORD

XML over HTTP

Device level

Network level

User level

HLD

LLD

Support for network

heterogeneity

PerLa Language

BOUDARIES OF THE MIDDLEWARE: HLD and LLD (1)

• PerLa Middleware C portable library (HLD, High Level Driver)

– Communications with other PerLa Middleware components

– General device management components (Timers, signal handling, Input/Output management…)

• The user is just required to write the missing software needed to access his device’s hardware (LLD, Low Level Driver)

– Standard library of device drivers (CAN bus, Digital-IO, …)

BOUDARIES OF THE MIDDLEWARE: HLD and LLD (2)

• Device Binding process: PLUG & PLAY

• Once started up the HLD sends its DEVICE DESCRIPTOR towards the nearest Java device suitable to host a FPC

Java environment

Device

HLD Desc.

FPC Factory Register

Desc.

FACTORY AND FPCs ASSEMBLING (1)

• The device descriptor is a text file which describes CAPABILITIES and FEATURES of a device

• Main sections of the descriptor:

– Attributes and events of the device

– Device features (available memory, uptime, available commands)

– Network features (contact method, uptime, address format)

– Message format expected by the LLD

Device status Bit 0 = 1 "AUT Mode" Bit 1 = 1 "MAN Mode" Bit 3 = 1 "Local Operation”Bit 4 = 0 "Positioner Function”Bit 4 = 1 "Controller Function”Bit 5 = 0 "Adjustment Completed"Bit 6 = 1 "Collective Alarm"

Message format for an idraulic actuator


• The Factory proceed assembling the FPC and registering it in the Register

Java environment

Device

HLD Desc.


Desc.

FPC Registration

FPC


FPC Registration

FPC

• The newly created FPC acknowledges the device of its creation

• The device is ready to be used

Java environment

Device

HLD Desc.


FPC


• The FPC is AD-HOC CREATED for every physical device

– The Factory, after parsing the Descriptor, combines different modules and configures them

– New modules can be added if not present in the default library

• The Low Level Query Executor communicates with the FPCs of the nodes to be queried

– Every FPC is responsible for translating the requests in the format accepted by the controlled device

– Given the device’s capabilities, the FPC has to check whether a particular request is feasible or not

• The FPC tries to DELEGATE as much elaboration as possible to the physical device

– The results of the partial ELABORATION need to be added to the outcome of the Low Level Query Executor


• Multiple devices can communicate over the same physical communication link

• All network components in the PerLa Middleware implement a 2 layer stack

– CHANNEL MANAGER: manages a point-to-point communication between two devices

– ADAPTER: multiplexes different virtual channels on a physical one

DEVICE MULTIPLEXING

• Network heterogeneity is a feature of WSNs

• PerLa Middleware supports network heterogeneity by means of PerLa enabled Gateway

– Every gateway replicates the Adapter – Channel Manager stack

– At the moment just static routing is possible

– The path between FPC and the device is created during the binding procedure

NETWORK HETEROGENEITY

• The FPC Factory has yet to be implemented

• The Device Descriptor needs to be completed

OPEN POINTS

LOW LEVEL QUERY EXECUTOR (LLQE)

D. Viganò


Milano, Italy

• Brief introduction to LLQ Executor (LLQE)

– GOALS, FUNCTIONALITIES and positioning within PerLa infrastructure

• LLQE: PROPOSED ARCHITECTURE and future developments

– Testing of expressions



LLQ Executor



LLQE: GOALS AND FUNCTIONALITIES


1. It receives a PARSED LOW LEVEL QUERY (Java Objects) as input

2. It has to allocate proper structures to manage received queries:

• LOCAL BUFFER: in order to store sampled data, needed to execute the query

• OUTPUT BUFFER: in order to store query results before they're sent to the application level

3. It finally computes QUERY RESULTS using the above mentioned structures

HOW LLQE WORKS


LLQE PROPOSED ARCHITECTURE (1)




Pointer to QUERY DATA STRUCTURE, as received from the parser.

LOCALBUFFER

Buffer records are Java Classes

SINGLE QUERY

OUTPUTBUFFER

LOCAL BUFFERRECORD

STRUCTURE

OUTPUT BUFFER RECORD STRUCTURE



• The Query Register is the set of Query objects currently running in the node

A Query object must be created for each query received from upper levels:

How many records the local buffer should be able to store?

How is every local buffer record composed?

When every query needs to be executed?

QUERY REGISTER

EXAMPLE


Output record structure

Time information needed to compute query results

Information to compute query

results

TESTING OF EXPRESSION CLASSES (1)


Thus LLQ has to deal with statements composed of SQL-like OPERATORS and EXPRESSIONS

While operators classes has been already tested, this work still had to be completed on expressions classes.


Every expression is composed of single elements called “nodes” which

are Java Classes.

A test tool has been developed and implemented in order to quickly

and efficiently test the existing expressions nodes.


EXAMPLE

N NodeDivision ConstantInteger 50 ConstantInteger 0 ConstantInteger ConstantInteger -

N NodeAddition ConstantInteger 2 ConstantInteger 4 ConstantInteger ConstantInteger 6

CONCLUSION

All expressions nodes have been tested and some errors have

been detected and corrected

LLQExecutor architecture has been defined

The next steps will be the implementation of the proposed

architecture and the testing of its functionalities (within the

rockfall scenario).

PILOT JOIN ANALYSISState of art – Step 1

M. MarinoPolitecnico di Milano,

Dipartimento di Elettronica e Informazione, Milano, Italy

“A special operation that allows dynamic changes in the set of logical objects executing a specific Low Level Query, based on the results produced by another running query.”

...“...it forces each involved logical object to start (or stop) the query execution if the joined stream contains (or not) a record that matches the current value of logical object attributes...” [1]

<Pilot Join Clause> PILOT JOIN <Correlated Table List>

<Correlated Table List> <Correlated Table> { ‘,’ <Correlated Table> }*

<Correlated Table> <Data Structure Name> ON <Condition>

E.g.:

PILOT JOIN BaseStationList ON currentBaseStation = baseStationList.baseStationID

WHAT IS THE PILOT JOIN?

Suppose we want to monitor the temperature of some containers inside a container ship [2]

BUT

We are more interested in those containers exposed at direct sunlight (sampled every hour)

Every container has a light sensor on the outside, and a temperature sensor in the inside, not directly connected to each other.

Light sensor

Temperature sensor

Photo by Patrick Boury (CC)

PILOT JOIN EXAMPLE

CREATE SNAPSHOT UnderTheSun (sensorID ID, light FLOAT, containerID ID)WITH DURATION 1 h ASLOW:

SELECT ID, light, containerIDSAMPLING EVERY 1 hWHERE light > [threshold]EXECUTE IF deviceType = “LightSensor”

CREATE OUTPUT STREAM Temperatures (sensorID ID, temp FLOAT, containerID ID) ASLOW:

EVERY ONESELECT ID, temp, containerIDSAMPLING EVERY 1 mPILOT JOIN UnderTheSun ON UnderTheSun.containerID = containerID

EXECUTE IF EXISTS (ALL)

PILOT JOIN EXAMPLE

“PILOT JOIN is the key feature enabling the execution of context dependent queries: the content of the joined stream is a description of the current environmental situation, while the join condition defines

the context-aware data tailoring the user is interested in.” [1]

This function adds context-awareness to the system, but some questions arise:

• Is it the best way to model context-awareness?

• Is it easy to be used in some complex cases?

• Is there another (more powerful) way to implement a context-aware WSN using a declarative language?

> Is someone else working on the same topic? <

PILOT JOIN DEFINITION

An extended survey was made, analyzing about 15 related papers from 2004 to 2008 coming from different research laboratories around the world.

An analysis of similarities with PerLa was also performed.

WHO IS WORKING ON THE TOPIC?

w.r.t. Integration of context-awareness and Intelligence level (e.g. Context Discovery)In

telli

gen

ce le

vel

Inte

llig

ence

leve

lIn

telli

gen

ce le

vel

Inte

llig

ence

leve

l

Context-awareness integration levelContext-awareness integration levelContext-awareness integration levelContext-awareness integration level

1

3

2

4

5

6

7

8

9

10

11

12

PerLa

TinyDB

BRIEF COMPARISON

• Context ReificationExplicit location for context information enables a reliable cross-context usage (e.g. Context node [2][3])

• Context NestingThe capability of nesting different contexts allows to define subcontexts which validity depends on the upper context

• Context Temporal ManagementA context may be valid only in a given time interval, keeping it explicit allows an easier management of time

• Context DiscoveryBy analyzing sensor data it is also possible to discover new

contexts, not previously defined• Multiple Contexts per sensor

A sensor may join different contexts at the same time (eg. low battery sensor and exposed to sunlight) [4]

• Context PriorityWhen orders to sensors interfere for active contexts, use priority information for each context

KEY IDEAS

The Pilot Join operation could be rethought in terms of explicit context, allowing PerLa to become a full context-aware system

But how to practically implement such a system?

KEY IDEAS

The context awareness in WSN is implemented in very different ways, but the key factor is to keep it work under a declarative language.

As an example, in [4][8][9][5] the concept of a declarative language is present, in other works is mentioned but no further detail is given (e.g. [10][7])

IMPLEMENTATION

Some conceptual schemata of various systems are presented here:

From [2]

SOME EXAMPLE


From [4]

SOME EXAMPLE


From [3]

SOME EXAMPLE


From [7]

SOME EXAMPLE

• Monitor the tampering sensor of the accessible containers when the ship is docked (GPS): if tampering is detected monitor nearby containers at higher frequency

(Four contexts may be involved, but the last one is created only after the other ones)

Tampering sensor


CONTEXT-AWARE EXAMPLE

• Every container with low sensor batteries must be monitored at a lower frequency, but if it is exposed to direct sunlight, it must be monitored at a higher frequency

(Two concurrent contexts are involved, but the last one has a higher priority and overrides the sampling frequency defined by the first one)


• Every container with fresh food must be monitored after one hour since direct sunlight is detected, for a maximum time of three hours. Every 30 sec.

(Temporal dependent context is involved: the context is created after the sunlight detection, but it is activated after one hour)


• Monitor the data correlation between temperatures, if an unexpected situation is detected (e.g. outliers detection) create a new context and raise an alarm

(e.g. a fire is spreading on the ship, but this event wasn’t defined!)



How would it be possible to extend the Pilot Join in PerLa to enhance context-awareness, given the results of the other research teams?

Some ideas:

• Add data structures for explicit context (just like the SNAPSHOT)

• Create a Context Manager which enables active management of contexts

• Formally define the behavior of context tables

• Think about intelligent Context Discovery (for the future)

IMPLEMENTATION IN PERLA

This presentation was just the first step

The next step will deal about the definition of suitable data structures to enable the context awareness in PerLa, in order to enhance the PILOT JOIN with a

more powerful and general approach

BUT

...always keeping in mind the trade-off between a simple implementation and a powerful, yet usable,

system

FUTURE WORKS

FUTURE WORKS

R. CamplaniPolitecnico di Milano,

Dipartimento di Elettronica e Informazione, Milano, Italy

• Current situation: the Java implementation of the Low Level Query Executor takes completely care of the query

– The FPC is just used as a proxy to the end device, transmitting sampling commands and receiving the data

• Improvements: DELEGATE PART OF THE COMPUTATION to the sensor devices

– The FPC recomputes Low Level Queries in nanoQueries, accordingly to the capabilities of the single device

– Every nanoQuery is executed directly by the device

– The results, partially elaborated by the sensor itself, are transmitted back to the FPC and joined to obtain the outcome of the original Low Level Query

To achieve this we need a common, PORTABLE, Low Level framework

FUTURE WORKS

• PerLa provides a portable framework which completely abstract the hardware of the single device called HLD (High Level Driver)

• HLD is a set of common components which takes care of:– Timer– Communications with the FPC– Scheduling– …

• The LLD (Low Level Driver) is the software needed by the HLD to access the hw features of the sensor – It has to be written by the user

HLD and LLD

• The execution of nanoQueries needs the addition of new components in the HLD

HLD nanoQuery

Executor

MacroOperations TimerTable

SchedulerInterrupt Manager

Hardware Abstraction Layer

LLD Hardware Drivers

nanoQUERY EXECUTOR (1)

• The FPC has full knowledge about the device’s capabilities

– The nanoQuery is created taking into account the Low Level Query to execute and the functionalities available on the sensor

Device

capabilities

Low Level

Querynano

Query

nanoQUERY EXECUTOR (2)

• nanoQuery Executor can be implemented as a FSM

– nanoQueries can be thought as a program that describes how to process the inputs

– Inputs are the data collected by the sensors

– Outputs are sent back to the FPC

F :

I1

In

S1

Sm

……

Z1

Zk

S01

S0m

……

ZI

S S0

nanoQuery

Executor

nanoQuery

nanoQUERY EXECUTOR

• A node that routes the information coming from different devices can execute nanoQueries to perform aggregations

– Example: the mean of the temperatures coming from a cluster of different nodes

• The nanoQuery running on the aggregator node takes as input the outputs of the underlying nodes

N0 N1 N2 N3 N4

AggregatorNode

AGGREGATION

[1] A Middleware Architecture for Data Management and Integration in Pervasive Heterogeneous SystemsF.A. Schreiber, R. Camplani, M. Fortunato, M. MarelliPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy

[2] Scoping in Wireless Sensor NetworksJan Steffan Ludger Fiege Mariano Cilia Alejandro BuchmannDepartment of Computer Science, Darmstadt University of Technology

[3] A Context-Aware Approach to Conserving Energy in Wireless Sensor NetworksChong, Krishnaswamy, LokeSchool of Computer Science and Software EngineeringMonash University,Melbourne, Australia

[4] Proactive Context-Aware Sensor NetworksSungjin Ahn and Daeyoung KimReal-time and Embedded Systems Laboratory,Information and Communications University (ICU)

[5] Energy Efficient Spatial Query Processing in Wireless Sensor NetworksKyungseo Park, Byoungyong Lee, Ramez ElmasriComputer Science and Engineering, University of Texas at Arlington

[6] Context-Aware SensorsEiman Elnahrawy and Badri NathDepartment of Computer Science, Rutgers University

Bibliography

[7] A Self-Adaptive Context Processing Framework for Wireless Sensor NetworksAmirhosein Taherkordi, Romain Rouvoy, Quan Le-Trung, and Frank EliassenUniversity of Oslo, Department of Informatics[8] A spatial extension of TinyDB for wireless sensor networksPaolino Di Felice, Massimo Ianni, Luigi PomanteDlEI DEWS - Universita dell'Aquila, Italy

[9] Efficient and Practical Query Scoping in Sensor NetworksHenri Dubois-Ferri`ereSchool of Computer and Communication SciencesEPFL Lausanne, Switzerland - Department of Computer Science UCLA, Los Angeles, CA

[10] Adaptive middleware for contextaware applications in smarthomesMarkus C. Huebscher DSE Group, Department of Computing Imperial College LondonJulie A. McCann DSE Group, Department of Computing Imperial College London

[11] TinyDB: An Acquisitional Query Processing System for Sensor NetworksSAMUEL R. MADDEN Massachusetts Institute of TechnologyMICHAEL J. FRANKLIN and JOSEPH M. HELLERSTEIN UC BerkeleyWEI HONG Intel Research, Berkeley

[12] Context Discovery in Sensor NetworksChia-Hsing HOU, Hung-Chang Hsiao, Chung-Ta King, Chun-Nan LuComputer Science, National Tsing-Wua University, Hsinchu, Taiwan,

Bibliography

SHORT INTRODUCTION TO PerLa MIDDLEWARE

Documents

Transcript of SHORT INTRODUCTION TO PerLa MIDDLEWARE