Post on 03-Jan-2016
description
SNALSensor Networks Application
LanguageAlvise Bonivento
Mentor: Prof. Sangiovanni-Vincentelli
290N project, Fall 04
Specs
Synthesis
Formal description of system requirements
Platform
ImplementationVerification
Formal description of hardware performance
Refine constraintsAbstract performance
Meet in the middleOptimize
MATHEMATICAL MODEL
CLEAR SEMANTIC
Describe Application
Independent from network architecture
Design Flow
Design Flow
Specs
Synthesis
Formal description of system requirements
Platform
ImplementationVerification
Formal description of hardware performance
Refine constraintsAbstract performance
Meet in the middleOptimize
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
PlatformDesignExport
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
ApplicationInterface SNSP
Command Service
Controller
Command Service
A1
A2
int CSRequestWriteint CSAckRead
CS allows a controller to set the state of a group of components
Application
ApplicationInterface 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
ImplementationVerification
Formal description of hardware performance
Refine constraintsAbstract performance
Meet in the middleOptimize
MATHEMATICAL MODEL
CLEAR SEMANTIC
Describe Application
Independent from network architecture
SNALSensor 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 SensingSatisfying Query Requirements
Virtual Sensor
VS
VC
CRS
Advance SensingSatisfying Query Requirements
Virtual Sensor
VS
VC
CRS
VC
1.Humidity samplesRate R1 until T1
query1
Virtual Sensor
VS
VC
CRS
VC
1.Humidity samplesRate R1 until T1
Virtual Sensor
VS
VC
CRS
VC
1.Humidity samplesRate R1 until T1
query2 2.Humidity samplesRate R2 until T2
Virtual Sensor
VS
VC
CRS
VC
Sensor keeps advancing
1.Humidity samplesRate R1 until T1
2.Humidity samplesRate R2 until T2
Virtual Sensor
VS
VC
CRS
VC
1.Humidity samplesRate R1 until T1
2.Humidity samplesRate R2 until T2
Query3
3.Humidity samplesRate R3 until T3
AndR3>R2>R1T2>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 samplesRate R1 until T1
3.Humidity samplesRate R3 until T3
AndR3>R1T3>T1
Virtual Sensor
VS
VC
CRS
VC
1.Humidity samplesRate R1 until T1
3.Humidity samplesRate R3 until T3
AndR3>R1T3>T1
Advance Sensing ConservativelySense at R3 until T1
Intersection of Requirements
Virtual Sensor
VS
VC
CRS
VC
1.Humidity samplesRate R1 until T1
3.Humidity samplesRate R3 until T3
AndR3>R1T3>T1
Advance Sensing ConservativelySense 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 VS1Else don’t send …
If (reply ==x)Then send Query to VS2Else don’t send …
Reactive Network
VC1 VC2
VS1 VS2
If (reply ==x)Then send Query to VS1Else don’t send …
If (reply ==x)Then send Query to VS2Else don’t send …
Capture branching
Reactive Network
VC1 VC2
VS1 VS2
If (reply ==x)Then send Query to VS1Else don’t send …
If (reply ==y)Then send Query to VS2Else don’t send …
Capture branching
Extra connection to separate branches
Reactive Network
VC1 VC2
VS1 VS2
If (reply ==x)Then send Query to VS1Else don’t send …
If (reply ==y)Then send Query to VS2Else 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
VCTask
VCIntfc
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