Download here - PerLa - PERvasive LAnguage

SHORT INTRODUCTION TO
PerLa MIDDLEWARE
M. Fortunato, M. Marelli
Politecnico di Milano,
Dipartimento di Elettronica e Informazione,
Milano, Italy
LOW LEVEL
QUERIES
(LLQ)
HIGH LEVEL
QUERIES
(HLQ)
ACTUATION
QUERIES
(AQ)
FULL DECLARATIVE SQL-LIKE
HIGH LEVEL LANGUAGE
to query
PERVASIVE SYSTEMS
hiding the complexity
of handling
DIFFERENT TECHNOLOGIES
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
PILOT JOIN OPERATION
•
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
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:
–
Events
Attributes
Meta
description
LOGICAL
OBJECT
CHANNEL
(Serial,
Socket)
Physical
device
ATTRIBUTES
(id, temperature, pressure, power level,
last sensed RFID reader, …)
–
EVENTS (last sensed RFID reader changed, …)
–
META-DESCRIPTION (name, data type, … for each attribute)
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
MIDDLEWARE
• A MIDDLEWARE is needed to provide an implementation of
the logical object abstraction.
Textual queries
Queries results
Upper interface
QUERY PARSER
QUERY ANALYZER
HIGH LEVEL QUERY EXECUTOR
LOGICAL OBJECTS
REGISTRY
LOW LEVEL QUERY
EXECUTOR
LOW LEVEL QUERY
EXECUTOR
LOW LEVEL QUERY
EXECUTOR
LOGICAL OBJECT
IMPLEMENTATION
LOGICAL OBJECT
IMPLEMENTATION
LOGICAL OBJECT
IMPLEMENTATION
Lower interface
Physical
device
Physical
devices
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
WSN
MIDDLEWARE GOALS (1)
• 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
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
MIDDLEWARE GOALS (2)
1. providing an ABSTRACTION for each device
• The FPC (Functionality Proxy Component) is defined as a
Java object representing a physical device.
FPC
• The FPC must be instantiated on a node:
– running a Java Virtual Machine (JVM)
– connected to the TCP-IP network
JAVA + TCP/IP
Physical device
• The middleware should manage the COMMUNICATION
PROTOCOL between FPC and physical device
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
MIDDLEWARE GOALS (3)
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.
• An
LLQE
should
support
the
simultaneous execution of all the low
level queries running on the node.
D. Viganò, Low Level Query Executor architecture
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
LLQE
FPC
MIDDLEWARE GOALS (4)
3. allowing devices to automatically start query execution
when they are powered on (PLUG & PLAY)
• 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
G. Rota, FPC Factory and devices self-description
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
MIDDLEWARE GOALS (5)
4. making the DEFINITION and the ADDITION of new
devices (and new technologies) easy, reducing the
amount of the needed low level code
• 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, …)
G. Rota, FPC Factory and devices self-description
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
MIDDLEWARE ARCHITECTURE
FPC
REGISTRY
LLQE
FPC FACTORY
FPC
JAVA + TCP/IP
R. Camplani: A proposal
for the Low Level C
library architecture
HLD
LLD
Physical device
SELFDESCRIPTION
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
PerLa MIDDLEWARE
ARCHITECTURE
G. Rota
Politecnico di Milano,
Dipartimento di Elettronica e Informazione,
Milano, Italy
PerLa MIDDLEWARE ARCHITECTURE
• 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 GOALS
• 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
LOGICAL OBJECTS AND FPCs
• 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
BOUDARIES OF THE MIDDLEWARE:
HLD and LLD (1)
PerLa
SWORD
User level
PerLa Language
XML over HTTP
Network level
Support for network
heterogeneity
Device level
HLD
LLD
BOUDARIES OF THE MIDDLEWARE:
HLD and LLD (2)
• 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, …)
FACTORY AND FPCs ASSEMBLING (1)
• Device Binding process: PLUG & PLAY
• Once started up the HLD sends its DEVICE DESCRIPTOR
towards the nearest Java device suitable to host a FPC
FPC Factory
Register
Desc.
Java environment
Desc.
HLD
Device
FACTORY AND FPCs ASSEMBLING (2)
• 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
Message format for an idraulic actuator
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"
FACTORY AND FPCs ASSEMBLING (3)
• The Factory proceed assembling the FPC and registering it in
the Register
FPC Registration
FPC Factory
Register
Desc.
FPC
Java environment
Desc.
HLD
Device
FACTORY AND FPCs ASSEMBLING (4)
• The newly created FPC acknowledges the device of its creation
• The device is ready to be used
FPC Factory
Register
FPC
Java environment
Desc.
HLD
Device
FACTORY AND FPCs ASSEMBLING (5)
• 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
DEVICE MULTIPLEXING
• 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
NETWORK HETEROGENEITY
• 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
OPEN POINTS
• The FPC Factory has yet to be implemented
• The Device Descriptor needs to be completed
LOW LEVEL QUERY EXECUTOR
(LLQE)
D. Viganò
Politecnico di Milano,
Dipartimento di Elettronica e Informazione,
Milano, Italy
LOW LEVEL QUERY EXECUTOR
• Brief introduction to LLQ Executor (LLQE)
– GOALS, FUNCTIONALITIES and positioning within PerLa
infrastructure
• LLQE: PROPOSED ARCHITECTURE and future
developments
– Testing of expressions
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
LOW LEVEL QUERY EXECUTOR
LLQ Executor
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
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
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
HOW LLQE WORKS
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
LLQE PROPOSED ARCHITECTURE (1)
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
LLQE PROPOSED ARCHITECTURE (2)
Pointer to QUERY DATA STRUCTURE, as
received from the parser.
SINGLE QUERY
LOCAL
BUFFER
RECORD
STRUCTURE
LOCAL
BUFFER
OUTPUT
BUFFER
Buffer records are Java Classes
OUTPUT BUFFER
RECORD STRUCTURE
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
LLQE PROPOSED ARCHITECTURE (3)
QUERY REGISTER
• 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?
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
EXAMPLE
Output record structure
Time information needed to
compute query results
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
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.
A DATA LANGUAGE FOR
PERVASIVE SYSTEMS
TESTING OF EXPRESSION CLASSES (2)
Every expression is composed of single elements called “nodes” which
are Java Classes.
TESTING OF EXPRESSION CLASSES (3)
A test tool has been developed and implemented in order to quickly
and efficiently test the existing expressions nodes.
EXAMPLE
N NodeAddition ConstantInteger 2 ConstantInteger 4 ConstantInteger ConstantInteger
6
N NodeDivision ConstantInteger 50 ConstantInteger 0 ConstantInteger ConstantInteger
-
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 ANALYSIS
State of art – Step 1
M. Marino
Politecnico di Milano,
Dipartimento di Elettronica e Informazione,
Milano, Italy
WHAT IS THE PILOT JOIN?
“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
PILOT JOIN EXAMPLE
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)
Photo by Patrick Boury (CC)
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
PILOT JOIN EXAMPLE
CREATE SNAPSHOT UnderTheSun (sensorID ID, light FLOAT, containerID ID)
WITH DURATION 1 h AS
LOW:
SELECT ID, light, containerID
SAMPLING EVERY 1 h
WHERE light > [threshold]
EXECUTE IF deviceType = “LightSensor”
CREATE OUTPUT STREAM Temperatures (sensorID ID, temp FLOAT, containerID ID) AS
LOW:
EVERY ONE
SELECT ID, temp, containerID
SAMPLING EVERY 1 m
PILOT JOIN UnderTheSun ON UnderTheSun.containerID = containerID
EXECUTE IF EXISTS (ALL)
PILOT JOIN DEFINITION
“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? <
WHO IS WORKING ON THE TOPIC?
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.
BRIEF COMPARISON
w.r.t. Integration of context-awareness and Intelligence level (e.g. Context Discovery)
4
3
10
Intelligence level
6
12
5
7
9
2
1
PerLa
8
11
TinyDB
Context-awareness integration level
KEY IDEAS
• Context Reification
Explicit location for context information enables a reliable crosscontext usage (e.g. Context node [2][3])
• Context Nesting
The capability of nesting different contexts allows to define
subcontexts which validity depends on the upper context
• Context Temporal Management
A context may be valid only in a given time interval, keeping it explicit
allows an easier management of time
• Context Discovery
By 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 Priority
When 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?
IMPLEMENTATION
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])
SOME EXAMPLE
Some conceptual schemata of various systems are presented here:
From [2]
SOME EXAMPLE
Some conceptual schemata of various systems are presented here:
From [4]
SOME EXAMPLE
Some conceptual schemata of various systems are presented here:
From [3]
SOME EXAMPLE
Some conceptual schemata of various systems are presented here:
From [7]
CONTEXT-AWARE 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)
Photo by Patrick Boury (CC)
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)
Photo by Patrick Boury (CC)
• 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)
CONTEXT-AWARE EXAMPLE
• 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!)
Photo by Patrick Boury (CC)
IMPLEMENTATION IN PERLA
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)
FUTURE WORKS
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
R. Camplani
Politecnico di Milano,
Dipartimento di Elettronica e Informazione,
Milano, Italy
FUTURE WORKS
• 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
HLD and LLD
• 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
nanoQUERY EXECUTOR (1)
• The execution of nanoQueries needs the addition of new
components in the HLD
HLD
nanoQuery
Executor
nanoQuery Buffer
Hardware Abstraction Layer
MacroOperations
TimerTable
Interrupt Manager
Scheduler
LLD
Hardware Drivers
nanoQUERY EXECUTOR (2)
• 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
Low Level
Query
nano
Query
Device
capabilities
nanoQUERY EXECUTOR
• 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
nanoQuery
I1
nanoQuery
F :
Executor
Zk
S01
…
S0
In
S1
…
S
…
Z
…
I
Z1
Sm
S0m
AGGREGATION
• 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
Aggregator
Node
N0
N1
N2
N3
N4
Bibliography
[1] A Middleware Architecture for Data Management and Integration in Pervasive
Heterogeneous Systems
F.A. Schreiber, R. Camplani, M. Fortunato, M. Marelli
Politecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy
[2] Scoping in Wireless Sensor Networks
Jan Steffan Ludger Fiege Mariano Cilia Alejandro Buchmann
Department of Computer Science, Darmstadt University of Technology
[3] A Context-Aware Approach to Conserving Energy in Wireless Sensor Networks
Chong, Krishnaswamy, Loke
School of Computer Science and Software Engineering
Monash University,Melbourne, Australia
[4] Proactive Context-Aware Sensor Networks
Sungjin Ahn and Daeyoung Kim
Real-time and Embedded Systems Laboratory,
Information and Communications University (ICU)
[5] Energy Efficient Spatial Query Processing in Wireless Sensor Networks
Kyungseo Park, Byoungyong Lee, Ramez Elmasri
Computer Science and Engineering, University of Texas at Arlington
[6] Context-Aware Sensors
Eiman Elnahrawy and Badri Nath
Department of Computer Science, Rutgers University
Bibliography
[7] A Self-Adaptive Context Processing Framework for Wireless Sensor Networks
Amirhosein Taherkordi, Romain Rouvoy, Quan Le-Trung, and Frank Eliassen
University of Oslo, Department of Informatics
[8] A spatial extension of TinyDB for wireless sensor networks
Paolino Di Felice, Massimo Ianni, Luigi Pomante
DlEI DEWS - Universita dell'Aquila, Italy
[9] Efficient and Practical Query Scoping in Sensor Networks
Henri Dubois-Ferri`ere
School of Computer and Communication Sciences
EPFL Lausanne, Switzerland - Department of Computer Science UCLA, Los Angeles, CA
[10] Adaptive middleware for contextaware applications in smarthomes
Markus C. Huebscher DSE Group, Department of Computing Imperial College London
Julie A. McCann DSE Group, Department of Computing Imperial College London
[11] TinyDB: An Acquisitional Query Processing System for Sensor Networks
SAMUEL R. MADDEN Massachusetts Institute of Technology
MICHAEL J. FRANKLIN and JOSEPH M. HELLERSTEIN UC Berkeley
WEI HONG Intel Research, Berkeley
[12] Context Discovery in Sensor Networks
Chia-Hsing HOU, Hung-Chang Hsiao, Chung-Ta King, Chun-Nan Lu
Computer Science, National Tsing-Wua University, Hsinchu, Taiwan,