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