a4wsn: an architecting environment 4 wireless sensor networks

Università degli Studi dell’Aquila

Ivano Malavolta

DISIM Department, University of L’Aquila [email protected]

Software Architecture & Model-Driven Engineering

applied to

Wireless Sensor Networks

Mobile Applications

Autonomous Quadrotors

Who is Ivano?

If you think good architecture is expensive, try bad architecture.

... Brian Foote and Joseph Yoder

Roadmap

Problem Definition

A4WSN

Modeling Environment

Software Architecture

Nodes Configuration

Physical Environment

Keeping Models Integrated

Programming Framework

Tool Support

Problem Definition

From the SESENA* 2012CfP:

“the development of WSN software is still carried out in a rather primitive fashion, by building software directly atop the OS and by relying on an individuals hard-earned programming skills”

“WSN developers must face not only the functional application requirements but also a number of challenging, non-functional requirements and constraints resulting from scarce resources”

Abstraction

Separation of concerns

Model-based Analysis

* International Workshop on Software

Engineering for Sensor Network Applications

Main Drivers of A4WSN

by masking the complexity of low-level, hardware details

by clearly separating application, HW, and deployment aspects of a WSN

by facilitating the analysis of both functional and non-functional properties

Abstraction

Separation of concerns

Model-based Analysis

Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support

The A4WSN Framework

Abstraction Separation of

concerns Model-Based

Analysis

third-parties can contribute with code generation or

analysis plugins

Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support

A4WSN

3 modeling languages


WSN nodes configurations

Physical environment


Structure

components

ports

application data

messages

Behaviour

events

conditions

actions

SA: Structure

Components. Units of computation with internal state and well defined interface

Ports. Interaction points with the external environment

Connections. Message-based communication channels between ports

Application data. Variables in the scope of the component

SA: Behaviour

Each Component can contain a description of its behaviour

The behaviour is based on:

1. Events-conditions-actions

2. Modes

SA: Actions

Sense gets some data from a sensor and stores the read value into a specific application data

ex: get current temperature

Actuate activates and actuator, optionally an application data can be used to pass a parameter to the actuator

ex: actuate a water sprinkler

SendMessage sends a message via a specific message port Unicast, Multicast and broadcast supported

SA: Actions

StartTimer starts a timer which can be triggered later. Cyclyc, delay and period properties supported

StopTimer stops a previously started timer

StoreData puts some (manipulated) data into an application data of the component

SyncServiceCall calls an external service (ex. web service)

AsyncServiceCall calls an external service, the result of the call will be available via a dedicated event

Fork and Join are used to sync the control flow

SA: Events

ServiceCallback is triggered when the result of an AsyncServiceCall is available

ReceiveMessage is triggered when the component receives a message

TimerFired is triggered when a previously started timer is activated

SA: Behavioural Flow

Behavioural flow is specified by means of Links

A link can exist:

1. from an event E to an action A: in this case after the event E is triggered, A will be executed

2. from an action A1 to another action A2: in this case, A2 is executed immediately after A1

Conditions are boolean expressions (optionally) associated to links

The execution flow goes through a link only if its condition

evaluates to true

E A

A2 A1

E A t > 30

SA: Modes

A specific status of the component

ex. sleeping mode, energy saving mode, etc.

At any given time, one and only one mode can be active in a component

The component reacts only to those events which are defined within its currently active mode

Example*

*This example is taken from our journal paper...

Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support

Nodes Configuration

Types of nodes

OS

MAC protocol

routing protocol

installed sensors

installed actuators

energy sources

communication devices

Node

A nodes specification is composed of a set of WSN node types

Node Attributes:

• OS

• ex. TinyOS, Contiki, Mantis, LiteOS, ...

• macProtocol

• ex. T-MAC, S-MAC, WiseMAC, SIFT, ...

• routingProtocol

• ex. GEAR, LEACH, HEED, ...

Node

Node

Energy Source Energy Source Energy Sources

Sensors Sensors Sensors

Actuators Actuators Actuators Microcontroller

Memory Memory Additional memories

RF RF RFs

ex. light sensor, temperature sensor, smoke sensor...

ex. sprinklers, leds, lights, switches...

can be either continuous, degradable, or harvested

Microcontroller

CPU ADC

DAC Timer

RF

CPU CPUs

Memory Program memory

Storage memory

Microcontroller

Represents the entity which performs tasks, processes data and controls the functionality of other components in the sensor node

1_* 0_*

0_*

0_1

1_*

1_1 1_1

1_1

Power Modes

A Node can specify a set of Power Modes

Each power mode identifies a set of node elements (such as memory, DAC, RF comm. device, etc.) and distinguishes between which elements are active and which elements are disabled

Communication Mode Sensing Mode

Example*


Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support


A 2D space with:

• obstacles

freely positioned

with their own shape

with attenuation coefficients

•deployment areas

freely positioned

with their own shape

Example*


As

Am

Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support


Two special models weave together SA, nodes and environment specifications

Actually, they are WEAVING MODELS

The Mapping Model

Links together an SAML model and a NODEML model

It defines how components are deployed into each configured nodes

Separation of Concerns

It helps in clearly separating the application layer of a WSN from all the other lower levels

Architects can focus on the application from a functional point of view in SAML, and only later they will focus on low-level aspects

this aspect is new in the WSN domain

The Deployment Model

Weaves together a NODEML model and an ENVML model

It defines how node types are

1. instantiated, and

2. virtually deployed in the physical environment

A DEPML model presents a single type of link: Deployment Link

A deployment link considers a node in the NODEML model, and assigns it to an area in the ENVML model

Area and Nodes Distribution

Nodes can be distributed in three different ways:

Random

each node is placed

randomly within the area

Grid

nodes are placed on a

grid with a certain

number of rows and

columns

Custom

each node can be manually

placed within the area

BS

N1 N2

N3

N1

The Deployment Model

Each node type can be instantiated ”n” times within a specific area

this allow architects to focus on generic components and node types in SAML and NODEML, while in DEPML we consider the final shape of the network

DEPML models are the only place in which we reason about the final node instances, in the other models we reason about types

Example*


As

Am

NODEML ENVML DEPML

oxymeter

monitor

custom distributed nodes

Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support


Validation

Models Parameters Provider

Messages Manager

UI Manager

Model Adapter

Code Generation Manager

Analysis Manager

C1 Cn A1 An



Code Generation Manager

Defines the extension point for code generation engines

It checks which plugins are currently extending its extension point and makes their facilities available to the end user

Analysis Manager acts similarly, but it is for analysis engines

Exposes a common Java API to plugin developers, so that they can easily interact with all the other components of A4WSN (validation, model adapters, etc.)


Models

Stores all the WSN models developed by architects and designers

Models can be stored:

- in the file system*

- in some server in the cloud

- in some in-memory representation

Model Adapter

Exposes a common interface to the other components of A4WSN to access the models in an homogeneous way

*currently, this is the only available solution in the A4WSN prototype


Validation

Executes all the operations to validate A4WSN models:

- predefined checks

- user-defined checks (via a plugin)

Messages Manager

Graphically shows informative messages to the user.

Supports three kind of informative messages: information

warning error


UI Manager

Responsible for the main facilities interacting with the user

interface:

- Code Generation Engines View

- Analysis Engines View

- Code Generation Contextual Menu

- Analysis Contextual Menu

- Validation Trigger

- Progress Feedback

- Additional Parameters View


Parameter Provider

Manages the additional parameters that a code generation or analysis plugin may require

Makes user-provided parameters available and easily accessible to the plugin requiring them

Supported types:

string, integer, float, boolean, local resource, remote resource accessible over HTTP

Anatomy of a Plugin

To contribute to A4WSN, each plugin must adhere to the following “signature”, A4WSN will take care of the rest

Anatomy of a Plugin

Code generation-specific

Analysis-specific

Anatomy of a Plugin

Roadmap

Problem Definition

A4WSN



Nodes Configuration




Tool Support

Tool Support

SAML – NODEML – ENVML:

Dedicated Graphical and Tree-based editors

bird view

graphical editor

properties

palette

models

Work-in-Progress Components

MAPML: Tree-based editor

DEPML: Tree-based editor

Programming Framework as Eclipse plugins

with defined extension points

First version of prototype available at http://www.di.univaq.it/malavolta/files/ME4AWSN_v0.1.zip

http://www.di.univaq.it/malavolta/files/ME4AWSN_v0.1.zip

Conclusions & Future Work

programming framework development

languages refinement

code generators analysis engines

node configurations marketplace?

We are looking for Plugin Contributions!

a4wsn: an architecting environment 4 wireless sensor networks

Technology