1 / 52

SNAL Sensor Networks Application Language

SNAL Sensor Networks Application Language. Alvise Bonivento Mentor: Prof. Sangiovanni-Vincentelli 290N project, Fall 04. Design Flow. Describe Application. Independent from network architecture. Specs. Formal description of system requirements. CLEAR SEMANTIC. MATHEMATICAL MODEL.

gonzalezdaniel
Télécharger la présentation

SNAL Sensor Networks Application Language

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. SNALSensor Networks Application Language Alvise Bonivento Mentor: Prof. Sangiovanni-Vincentelli 290N project, Fall 04

  2. Design Flow Describe Application Independent from network architecture Specs Formal description of system requirements CLEAR SEMANTIC MATHEMATICAL MODEL Synthesis Refine constraints Abstract performance Meet in the middle Optimize Platform Formal description of hardware performance Implementation Verification

  3. Design Flow Describe Application Independent from network architecture Specs Formal description of system requirements CLEAR SEMANTIC MATHEMATICAL MODEL Synthesis Refine constraints Abstract performance Meet in the middle Optimize Platform Formal description of hardware performance Implementation Verification

  4. Application Space Application Instance Platform Mapping AI Platform Application Interface (AI) Platform Design Export Platform Instance Architecture Space A Service-based Application Interface • Universal: independent on the Implementation on any present and future Sensor Network Platform • Service-based: standard set of Services and Interface Primitives available to Applications • Analogy with Internet Sockets

  5. Query Service Application Controller • Query Parameters (temperature, light, sound...) • Query Class (accuracy, resolution, maximum latency, tagging requirements, priority, quantifiers, operations, security) • QueryID (descriptor) • Response type (one-time, periodic, notification of events) • Reliability Application Interface SNSP Query Service S1 S2 QS allows a controller to obtain the state of a group of components int QSRequestWrite int QSResponseRead

  6. Command Service Application Controller Application Interface SNSP Command Service A1 A2 CS allows a controller to set the state of a group of components int CSRequestWrite int CSAckRead

  7. Concept Repository Service temperature, pressure… kitchen, hall, yard… PG&E, Police... C Concepts • Attributes (used for naming) • Regions (zone, neighborhood) • Organizations • Selectors, Logic operators, Quantifiers C CRS maintains a repository containing the lists of capabilities of the network and the concepts that are supported • Allows to maintain agreement on concepts also in dynamic network operation • Network interoperability

  8. Design Flow Describe Application Independent from network architecture Specs Formal description of system requirements CLEAR SEMANTIC MATHEMATICAL MODEL Synthesis Refine constraints Abstract performance Meet in the middle Optimize Platform Formal description of hardware performance Implementation Verification

  9. SNAL Sensor Network Application Language • Goals • Allow user to describe the network in terms of logical components queries and services • Capture these specifications and produce a set of constraints • Simulate WSN applications • Whenever an abstraction of the protocol stack and the hardware platform is available • Characteristics • Publish/Subscribe • Scenario Based • Component Oriented • Composition • MoC • Primitives

  10. Components and Connections • Three types of “Logical Components”: • Virtual Controller • Virtual Sensor • Virtual Actuator • One “Service Component” • CRS: Concept Repository Service • Connections • From VC to VC • From VC to VS • From VC to VA

  11. Virtual Controller CRS VC VS VS

  12. Virtual Controller CRS VC query VS VS

  13. Virtual Controller CRS VC Causality VS VS

  14. Virtual Sensor CRS VC VS

  15. Virtual Sensor CRS VC VS

  16. Virtual Sensor CRS VC Ask to CRS for interpretation VS

  17. Virtual Sensor CRS VC VS

  18. Virtual Sensor CRS VC VS Advance Sensing Satisfying Query Requirements

  19. Virtual Sensor CRS VC VS Advance Sensing Satisfying Query Requirements

  20. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC query1 VS VC

  21. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC VS VC

  22. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC query2 2.Humidity samples Rate R2 until T2 VS VC

  23. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC 2.Humidity samples Rate R2 until T2 VS Sensor keeps advancing VC

  24. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC 2.Humidity samples Rate R2 until T2 VS 3.Humidity samples Rate R3 until T3 And R3>R2>R1 T2>T3>T1 VC Query3

  25. Virtual Sensor CRS VC VS Too late !! Backtrack sensing VC BLOCK READ

  26. Virtual Sensor CRS VC VS VC

  27. Virtual Sensor CRS VC VS VC

  28. Virtual Sensor CRS VC VS VC

  29. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC 3.Humidity samples Rate R3 until T3 And R3>R1 T3>T1 VS VC

  30. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC 3.Humidity samples Rate R3 until T3 And R3>R1 T3>T1 VS VC Advance Sensing Conservatively Sense at R3 until T1 Intersection of Requirements

  31. Virtual Sensor CRS 1.Humidity samples Rate R1 until T1 VC 3.Humidity samples Rate R3 until T3 And R3>R1 T3>T1 VS VC Advance Sensing Conservatively Sense at R3 until T1 Intersection of Requirements

  32. Virtual Sensor CRS VC VS VC

  33. Virtual Sensor CRS VC VS VC

  34. Virtual Sensor CRS VC VS VC • What if there is no token coming? • The VC does not need to query the VS anymore • The VC never had to query the VS

  35. Virtual Sensor CRS VC • The VC does not need to query the VS anymore: VS VC

  36. Virtual Sensor CRS VC • The VC does not need to query the VS anymore: VS VC Meaning “any behavior from now on it’s ok”

  37. Virtual Sensor CRS VC • The VC does not need to query the VS anymore: VS VC Meaning “any behavior from now on it’s ok” It is never consumed!!!

  38. Virtual Sensor CRS VC • The VC does not need to query the VS anymore: VS VC Meaning “any behavior from now on it’s ok” It is never consumed!!! When all the input channel have the VS stops executing

  39. Virtual Sensor CRS VC • The VC never needed to send a Query VS VC

  40. Virtual Sensor CRS VC • The VC never needed to send a Query VS VC No need for this connection

  41. Virtual Actuator • Same as the Virtual Sensor !! • Commands instead of Queries • Responds with Acknowledgements (if required)

  42. Implications of Block Read • Block Read • Allows to capture all the scenarios correctly • Generates sensing requirements • Overhead • Captures specifications, no communication overhead • No delay introduced • Expressivity • Forces the logical architecture to have the VC as the Master and VS and VA as slaves. But that is what we wanted!!

  43. Reactive Network VS2 VS1 VC1 VC2 Waits for the reply from VS2 to decide if sending a query to VS1 Waits for the reply from VS1 to decide if sending a query to VS2

  44. Reactive Network VS2 VS1 VC1 VC2 Waits for the reply from VS2 to decide if sending a query to VS1 Waits for the reply from VS1 to decide if sending a query to VS2 Deadlock

  45. Reactive Network VS2 VS1 VC1 VC2 Waits for the reply from VS2 to decide if sending a query to VS1 Waits for the reply from VS1 to decide if sending a query to VS2 Deadlock We need to capture this scenario

  46. Reactive Network VS2 VS1 VC1 VC2 If (reply ==x) Then send Query to VS1 Else don’t send … If (reply ==x) Then send Query to VS2 Else don’t send …

  47. Reactive Network VS2 VS1 VC1 VC2 If (reply ==x) Then send Query to VS1 Else don’t send … If (reply ==x) Then send Query to VS2 Else don’t send … Capture branching

  48. Reactive Network Extra connection to separate branches VS2 VS1 VC1 VC2 If (reply ==x) Then send Query to VS1 Else don’t send … If (reply ==y) Then send Query to VS2 Else don’t send … Capture branching

  49. Reactive Network Extra connection to separate branches VS2 VS1 Eventually VC1 VC2 If (reply ==x) Then send Query to VS1 Else don’t send … If (reply ==y) Then send Query to VS2 Else don’t send … Capture branching

  50. Formulation • Tiered MoC • Complex tag system • KPN flavor • Publish/Subscribe • Components as threaded processes • Serving a Query … consuming a token • TSM description

More Related