1. SNAL Sensor Networks Application Language Alvise Bonivento Mentor: Prof. Sangiovanni-Vincentelli 290N project, Fall 04

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

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

4. A Service-based Application Interface Application Interface (AI) AI Platform Application Space Architecture Space Platform Mapping Platform Design Export Application Instance Platform Instance 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 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 Query Service Controller Query Service S1 S2 int QSRequestWrite int QSResponseRead QS allows a controller to obtain the state of a group of components Application Interface SNSP

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

7. Concepts –Attributes (used for naming) –Regions (zone, neighborhood) –Organizations –Selectors, Logic operators, Quantifiers Concept Repository Service 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 temperature, pressure… kitchen, hall, yard… PG&E, Police... C C

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

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 Composition MoC Primitives Characteristics Publish/Subscribe Scenario Based Component Oriented

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 VS VC CRS VS

12. Virtual Controller VS VC CRS VS query

13. Virtual Controller VS VC CRS VS Causality

14. Virtual Sensor VS VC CRS

15. Virtual Sensor VS VC CRS

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

17. Virtual Sensor VS VC CRS

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

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

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

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

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

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

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

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

26. Virtual Sensor VS VC CRS VC

27. Virtual Sensor VS VC CRS VC

28. Virtual Sensor VS VC CRS VC

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

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

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

32. Virtual Sensor VS VC CRS VC

33. Virtual Sensor VS VC CRS VC

34. Virtual Sensor VS VC CRS 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 VS VC CRS VC 1.The VC does not need to query the VS anymore:

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

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

38. Virtual Sensor VS VC CRS VC 1.The VC does not need to query the VS anymore: 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 VS VC CRS VC 2.The VC never needed to send a Query

40. Virtual Sensor VS VC CRS VC 2.The VC never needed to send a Query 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 VC1 VC2 VS1 VS2 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 VC1 VC2 VS1 VS2 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 VC1 VC2 VS1 VS2 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 VC1 VC2 VS1 VS2 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 VC1 VC2 VS1 VS2 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 VC1 VC2 VS1 VS2 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 Extra connection to separate branches

49. Reactive Network VC1 VC2 VS1 VS2 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 Extra connection to separate branches Eventually

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

51. Refinement Task and Interface Process VC Task VC Intfc Orthogonalization of concerns: Computation vs. Communication Simplify synthesis

52. Conclusions MoC to support SNAL –Domain specific for WSN –Captures all scenarios introducing multiports –Publish/Subscribe –First step for synthesis Future Work –Integrating into Metropolis