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

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

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

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

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

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

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

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

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

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

Virtual Controller VS VC CRS VS

Virtual Controller VS VC CRS VS query

Virtual Controller VS VC CRS VS Causality

Virtual Sensor VS VC CRS

Virtual Sensor VS VC CRS

Virtual Sensor VS VC CRS Ask to CRS for interpretation

Virtual Sensor VS VC CRS

Virtual Sensor VS VC CRS Advance Sensing Satisfying Query Requirements

Virtual Sensor VS VC CRS Advance Sensing Satisfying Query Requirements

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

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

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

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

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

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

Virtual Sensor VS VC CRS VC

Virtual Sensor VS VC CRS VC

Virtual Sensor VS VC CRS VC

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

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

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

Virtual Sensor VS VC CRS VC

Virtual Sensor VS VC CRS VC

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

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

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”

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!!!

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

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

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

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

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!!

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

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

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

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 …

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

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

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

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

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

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