1 / 68

SHORT INTRODUCTION TO PerLa MIDDLEWARE

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). A DATA LANGUAGE FOR PERVASIVE SYSTEMS. FULL DECLARATIVE SQL-LIKE

duff
Télécharger la présentation

SHORT INTRODUCTION TO PerLa MIDDLEWARE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SHORT INTRODUCTION TO PerLa MIDDLEWARE M. Fortunato, M. MarelliPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy

  2. LOW LEVEL QUERIES(LLQ) HIGH LEVEL QUERIES(HLQ) ACTUATION QUERIES(AQ) A DATA LANGUAGE FOR PERVASIVE SYSTEMS FULL DECLARATIVE SQL-LIKE HIGH LEVEL LANGUAGE to query PERVASIVE SYSTEMS hiding the complexity of handling DIFFERENT TECHNOLOGIES

  3. PILOT JOIN OPERATION A DATA LANGUAGE FOR PERVASIVE SYSTEMS • 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 BYOTHER 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

  4. LOGICAL OBJECT ABSTRACTION Events Metadescription Attributes LOGICAL OBJECT CHANNEL(Serial, Socket) Physicaldevice A DATA LANGUAGE FOR PERVASIVE SYSTEMS • 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)

  5. MIDDLEWARE Textual queries Queries results Upper interface QUERY PARSER QUERY ANALYZER LOGICAL OBJECTS REGISTRY HIGH LEVEL QUERY EXECUTOR A DATA LANGUAGE FOR PERVASIVE SYSTEMS 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 WSN • A MIDDLEWARE is needed to provide an implementation of the logical object abstraction.

  6. MIDDLEWARE GOALS (1) A DATA LANGUAGE FOR PERVASIVE SYSTEMS • The main goals of the middleware are: • providing an ABSTRACTION for each device • supporting the EXECUTION OF PERLA QUERIES • allowing devices to automatically start query execution when they are powered on (PLUG & PLAY) • making the DEFINITION and the ADDITION of new devices (and new technologies) easy, reducing the amount of the needed low level code

  7. MIDDLEWARE GOALS (2) A DATA LANGUAGE FOR PERVASIVE SYSTEMS 1. providing an ABSTRACTION for each device • The FPC (Functionality Proxy Component) is defined as a Java object representing a physical device. • The FPCmust 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 JAVA + TCP/IP Physical device

  8. MIDDLEWARE GOALS (3) A DATA LANGUAGE FOR PERVASIVE SYSTEMS 2. supporting the EXECUTION OF PERLA QUERIES • TheLLQE (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 LLQE FPC

  9. MIDDLEWARE GOALS (4) A DATA LANGUAGE FOR PERVASIVE SYSTEMS 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

  10. MIDDLEWARE GOALS (5) A DATA LANGUAGE FOR PERVASIVE SYSTEMS 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 LIBRARYcan 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

  11. MIDDLEWARE ARCHITECTURE LLQE FPC R. Camplani: A proposal for the Low Level C library architecture SELF-DESCRIPTION A DATA LANGUAGE FOR PERVASIVE SYSTEMS FPC REGISTRY FPC FACTORY JAVA + TCP/IP HLD LLD Physical device

  12. PerLa MIDDLEWARE ARCHITECTURE G. RotaPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy

  13. 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

  14. 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

  15. PerLa MIDDLEWARE GOALS

  16. 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

  17. 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

  18. 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, …)

  19. FACTORY AND FPCs ASSEMBLING (1) FPC Factory Register Java environment Desc. Desc. HLD Device Device Binding process: PLUG & PLAY Once started up the HLD sends its DEVICE DESCRIPTOR towards the nearest Java device suitable to host a FPC

  20. FACTORY AND FPCs ASSEMBLING (2) Message format for an idraulic actuator • 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

  21. FACTORY AND FPCs ASSEMBLING (3) FPC Registration FPC Registration FPC Factory Register FPC FPC Java environment Desc. Desc. HLD Device The Factory proceed assembling the FPC and registering it in the Register

  22. FACTORY AND FPCs ASSEMBLING (4) FPC Factory Register FPC Java environment Desc. HLD Device The newly created FPC acknowledges the device of its creation The device is ready to be used

  23. 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

  24. 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

  25. 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

  26. OPEN POINTS The FPC Factory has yet to be implemented The Device Descriptor needs to be completed

  27. LOW LEVEL QUERY EXECUTOR (LLQE) D. ViganòPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy

  28. LOW LEVEL QUERY EXECUTOR A DATA LANGUAGE FOR PERVASIVE SYSTEMS • Brief introduction to LLQ Executor (LLQE)‏ • GOALS, FUNCTIONALITIES and positioning within PerLa infrastructure • LLQE: PROPOSED ARCHITECTURE and future developments • Testing of expressions

  29. LOW LEVEL QUERY EXECUTOR A DATA LANGUAGE FOR PERVASIVE SYSTEMS LLQ Executor

  30. LLQE: GOALS AND FUNCTIONALITIES A DATA LANGUAGE FOR PERVASIVE SYSTEMS • It receives a PARSED LOW LEVEL QUERY (Java Objects) as input • 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

  31. HOW LLQE WORKS A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  32. LLQE PROPOSED ARCHITECTURE (1) A DATA LANGUAGE FOR PERVASIVE SYSTEMS

  33. LLQE PROPOSED ARCHITECTURE (2) A DATA LANGUAGE FOR PERVASIVE SYSTEMS SINGLE QUERY Pointer to QUERY DATA STRUCTURE, as received from the parser. LOCAL BUFFERRECORDSTRUCTURE LOCAL BUFFER OUTPUT BUFFER OUTPUT BUFFER RECORD STRUCTURE Buffer records are Java Classes

  34. LLQE PROPOSED ARCHITECTURE (3) A DATA LANGUAGE FOR PERVASIVE SYSTEMS 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?

  35. EXAMPLE A DATA LANGUAGE FOR PERVASIVE SYSTEMS Output record structure Information to compute query results Time information needed to compute query results

  36. TESTING OF EXPRESSION CLASSES (1) A DATA LANGUAGE FOR PERVASIVE SYSTEMS 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.

  37. TESTING OF EXPRESSION CLASSES (2) Every expression is composed of single elements called “nodes” which are Java Classes.

  38. TESTING OF EXPRESSION CLASSES (3) A test tool has been developed and implemented in order to quickly and efficiently test the existing expressions nodes.

  39. EXAMPLE N NodeAddition ConstantInteger 2 ConstantInteger 4 ConstantInteger ConstantInteger 6 N NodeDivision ConstantInteger 50 ConstantInteger 0 ConstantInteger ConstantInteger -

  40. 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).

  41. PILOT JOIN ANALYSISState of art – Step 1 M. MarinoPolitecnico di Milano, Dipartimento di Elettronica e Informazione, Milano, Italy

  42. 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

  43. 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

  44. 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)

  45. 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? <

  46. 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.

  47. BRIEF COMPARISON 5 1 3 2 6 4 8 9 10 11 12 7 w.r.t. Integration of context-awareness and Intelligence level (e.g. Context Discovery) Intelligence level PerLa Context-awareness integration level TinyDB

  48. KEY IDEAS • Context Reification • Explicit location for context information enables a reliable cross-context 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

  49. 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?

  50. 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])

More Related