me4awsn - a modeling environment for architecting wsns

51
Università degli Studi dell’Aquila ME4AWSN Ivano Malavolta DISIM Department, University of L’Aquila [email protected]

Upload: ivano-malavolta

Post on 07-May-2015

455 views

Category:

Technology


0 download

DESCRIPTION

Advanced Software Engineering course - Guest Lecture ME4AWSN - a Modeling Environment for Architecting WSNs Here you can find the research paper presenting the concepts described in this lecture: http://goo.gl/XBB4k This presentation has been developed in the context of the Advanced Software Engineering course at the DISIM Department of the University of L’Aquila (Italy). http://www.di.univaq.it/malavolta

TRANSCRIPT

Page 1: ME4AWSN - a Modeling Environment for Architecting WSNs

Università degli Studi dell’Aquila

ME4AWSN

Ivano Malavolta

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

Page 2: ME4AWSN - a Modeling Environment for Architecting WSNs

The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved.

Ivano Malavolta

Page 3: ME4AWSN - a Modeling Environment for Architecting WSNs

Problem Definition

ME4AWSN

Software Architecture

Nodes Configuration

Physical Environment

Keeping Models Integrated

Example

Page 4: ME4AWSN - a Modeling Environment for Architecting WSNs

A software application that provides comprehensive facilities for developing models

• model creation, deletion

• model editing (graphical, textual, ...)

• syntax rules enforcing

• ...

What is a Modeling Environment?

... what about modeling frameworks?

Page 5: ME4AWSN - a Modeling Environment for Architecting WSNs

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

Page 6: ME4AWSN - a Modeling Environment for Architecting WSNs

by masking the complexity of low-level, hardware details

by clearly separating SW, 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

Page 7: ME4AWSN - a Modeling Environment for Architecting WSNs

Abstraction Separation of

concerns Model-Based

Analysis

in this lecture we focus on this part

Page 8: ME4AWSN - a Modeling Environment for Architecting WSNs
Page 9: ME4AWSN - a Modeling Environment for Architecting WSNs

Problem Definition

ME4AWSN

Software Architecture

Nodes Configuration

Physical Environment

Keeping Models Integrated

Example

Page 10: ME4AWSN - a Modeling Environment for Architecting WSNs

It is composed of 3 modeling languages

Software Architecture

Details about WSN nodes

Physical environment

Page 11: ME4AWSN - a Modeling Environment for Architecting WSNs

Structure

components

ports

application data

messages

Behaviour

events

conditions

actions

Page 12: ME4AWSN - a Modeling Environment for Architecting WSNs

Component. A unit of computation with internal state and well defined interface. Each component can contain a behaviour specification and a set of application data.

MessagePort. Specifies the interaction point between a component and its external environment.

Incoming messages arrive at InMessagePorts

Outgoing messages are sent via OutMessagePorts

Connection. It is a unidirectional communication channel between two message ports.

Page 13: ME4AWSN - a Modeling Environment for Architecting WSNs

Application Data. Local variables declared in the scope of the component. It is manipulated by actions defined in the behaviour of the component.

There are two types of application data:

• Primitive

• integer, string, real, boolean

• Structured

• Enumeration

• Structure

Page 14: ME4AWSN - a Modeling Environment for Architecting WSNs

Operations on Application Data:

• arithmetic

• + - / *

• boolean

• AND, OR, NOT

• relational

• > >= < <= !=

Application data reference

Structure Member reference

Assignment is done via a dedicated Action in

the behaviour

Page 15: ME4AWSN - a Modeling Environment for Architecting WSNs

Each Component can contain a description of its behaviour

The behaviour is based on:

1. Events-conditions-actions

2. Modes

Page 16: ME4AWSN - a Modeling Environment for Architecting WSNs

Each Component can perform 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

Page 17: ME4AWSN - a Modeling Environment for Architecting WSNs

SendMessage sends a message via a specific message port

Optionally, the payload of the message can be specified by passing an application data as parameter

Types of available messages:

Unicast to a single receiver

Multicast to a set of receivers

Broadcast to every node containing the target component

Page 18: ME4AWSN - a Modeling Environment for Architecting WSNs

StartTimer starts a timer which can be triggered later

cyclic: true if the timer must be periodic

delay: the time (in millisecs) that must pass before the first activation

period: the period of the timer (in millisecs), if it is a cyclic one

StopTimer stops a previously started timer

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

Page 19: ME4AWSN - a Modeling Environment for Architecting WSNs

SyncServiceCall calls an external service (ex. web service)

data: optional, it is the parameters that can be passed to the service

dataRecipient: the application data which will be filled with the result

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

data: optional, it is the parameters that can be passed to the service

Fork and Join are used to sync the control flow

Page 20: ME4AWSN - a Modeling Environment for Architecting WSNs

Each component can react to specific kinds of events:

ServiceCallback is triggered when the result of an AsyncServiceCall is available

dataRecipient: the application data which will be filled with the result

ReceiveMessage is triggered when the component receives a message

dataRecipient: the application data which will contain the payload

fromMessagePort: the port that received the message

TimerFired is triggered when a previously started timer is activated

Page 21: ME4AWSN - a Modeling Environment for Architecting WSNs

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

Page 22: ME4AWSN - a Modeling Environment for Architecting WSNs

A mode is a specific status of the component

ex. sleeping mode, energy saving mode, etc.

Initial Mode is the first mode which is active when the component starts up

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

Page 23: ME4AWSN - a Modeling Environment for Architecting WSNs

A component can switch from a mode to another by means of mode transitions

Mode transitions link together modes by passing...

from a special kind of action called ExitMode

to a special kind of event called EnterMode

in this way actions and events can be linked to modes entry and exit points, creating a continuous flow among modes

Page 24: ME4AWSN - a Modeling Environment for Architecting WSNs

Problem Definition

ME4AWSN

Software Architecture

Nodes Configuration

Physical Environment

Keeping Models Integrated

Example

Page 25: ME4AWSN - a Modeling Environment for Architecting WSNs

Types of nodes

OS

MAC protocol

routing protocol

installed sensors

installed actuators

energy sources

communication devices

Page 26: ME4AWSN - a Modeling Environment for Architecting WSNs

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, ...

Page 27: ME4AWSN - a Modeling Environment for Architecting WSNs

Node

Energy Source Energy Source Energy Sources

Sensors Sensors Sensors

Actuators Actuators Actuators

Microcontroller Memory Memory Memory

RF RF RF

CPU ADC

DAC Timer

RF

CPU CPU

Memory Program memory

Page 28: ME4AWSN - a Modeling Environment for Architecting WSNs

The following elements can be attached to a WSN node:

• energy sources (one or more)

• continuous

• degradable (initialStoredEnergy in Joule)

• harvested (initialStoredEnergy in Joule, harvestingEnergyRate in Joule)

• sensors (zero or more)

energyConsumptionPerSample (mJ), idleEnergyConsumption (mJ)

ex. light sensor, temperature sensor, radio sensor, ...

• actuators (zero or more)

energyConsumptionPerSample (mJ), idleEnergyConsumption (mJ)

ex. water sprinkler, leds, lights, heating system switch, ...

Page 29: ME4AWSN - a Modeling Environment for Architecting WSNs

A node can contain the following elements:

• RF Communication Device (zero or more)

represents the radio device to communicate with other nodes

Attributes:

float transmissionPower in dBm

float receiveSensitivity in dBm

float[1] frequency in MHz

float antennaGain in dBd

String modulation // name of the modulation method

String encryption // name of the enc. algorithm

Page 30: ME4AWSN - a Modeling Environment for Architecting WSNs

A node can contain the following elements:

• Memories (one or more)

represents external storage memories of the node

Attributes:

float averageReadingEnergyConsumption in mW

float averageWritingEnergyConsumption in mW

int[1] size in Kb

Page 31: ME4AWSN - a Modeling Environment for Architecting WSNs

Microcontroller (one)

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

Microcontroller

CPU ADC

DAC Timer

RF

CPU CPU

Memory Program memory

1_* 0_*

0_*

0_1

1_*

1_1 1_1

Page 32: ME4AWSN - a Modeling Environment for Architecting WSNs

• ADC (zero or more)

Attributes:

int resolution // # discrete values it can produce

int bits // 8 bits, 16 bits

int channels // #channels

• DAC (zero or more)

Attributes:

int resolution // # discrete values it can produce

int bits // 8 bits, 16 bits

Page 33: ME4AWSN - a Modeling Environment for Architecting WSNs

• Processor (one or more)

Attributes:

int[1] frequency in MHz

float[1] cpi // cycles per instruction

• Timer (one or more)

Attributes:

int bits // 8 bits, 16 bits

• RF Communication Device (0_1) – internal radio transceiver

• Memory (one) – same role as RAM memory in PCs

• Program Memory (one) – stores the program running on the node

Page 34: ME4AWSN - a Modeling Environment for Architecting WSNs

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

Mode A Mode B

Page 35: ME4AWSN - a Modeling Environment for Architecting WSNs

Problem Definition

ME4AWSN

Software Architecture

Nodes Configuration

Physical Environment

Keeping Models Integrated

Example

Page 36: ME4AWSN - a Modeling Environment for Architecting WSNs

A 2D space with obstacles

freely positioned

with their own shape

with attenuation coefficients

Page 37: ME4AWSN - a Modeling Environment for Architecting WSNs

The Environment represents the overall area in the 2D space in which the WSN will be deployed

Attributes:

string name // the name of the area

float [1] width // the width of the bounding box of the area

float [1] height // the height of the bounding box of the area

imagePath // the image used as background in the editor

The environment contains a set of Obstacles

Page 38: ME4AWSN - a Modeling Environment for Architecting WSNs

An Obstacle specifies any kind of relevant element which can be placed in the environment

Attributes:

string material // the name of the material of the obstacle

(ex. concrete wall, wooden door, glass, ...)

float [1] attenuation // the “thickness” of the obstacle

// it ranges from 0 to 1

Coordinate [2_*] shell // the perimeter of the obstacle in the 2D space

Page 39: ME4AWSN - a Modeling Environment for Architecting WSNs

Problem Definition

ME4AWSN

Software Architecture

Nodes Configuration

Physical Environment

Keeping Models Integrated

Example

Page 40: ME4AWSN - a Modeling Environment for Architecting WSNs

Two special models that link together SA, nodes and environment specifications

Page 41: ME4AWSN - a Modeling Environment for Architecting WSNs

Weaves together an SAML model and a NODEML model

It defines how components are deployed into each configured nodes

Types of link:

• Mapping maps a component to its corresponding node configuration

• Sensor Mapping maps a Sense action in a component to a Sensor in a node

• Actuator Mapping similar to the Sensor Mapping, but for actuators

• Communication Device Mapping maps a Message Port in a component to an RFCommunicationDevice in a node

• Mode Mapping maps a Mode in a component to a Power Mode in a node

Page 42: ME4AWSN - a Modeling Environment for Architecting WSNs

MAPML models semantically represent the classical notion of deployment of software components onto HW nodes

Separation of Concerns

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

this aspect is new in the WSN domain

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

Page 43: ME4AWSN - a Modeling Environment for Architecting WSNs

Weaves together a NODEML model and an ENVML model

It defines how node configuration 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 configuration in the NODEML model, and assigns it to an area within the physical environment

Page 44: ME4AWSN - a Modeling Environment for Architecting WSNs

An area is a portion of physical environment (i.e., the environment element defined in the ENVML 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

An area has two properties:

1. Shape: the perimeter of the area defined as a set of coordinates

2. NodesDistribution: how the “n”nodes are positioned in the area

Page 45: ME4AWSN - a Modeling Environment for Architecting WSNs

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

Page 46: ME4AWSN - a Modeling Environment for Architecting WSNs

1. its name

2. the coordinates of its position

A nodes name pattern cane be given to an area independently from the distribution type

they are used to have a way to refer to the names used as targets of Send

Message actions in SAML models

Available patterns:

name<number>, name<Letter>, name

BS

N1 N2

N3

N1

In custom distribution, each node can be individually specified in the area by:

Page 47: ME4AWSN - a Modeling Environment for Architecting WSNs

Graphical and Tree-based editor for SAML

bird view

graphical editor

properties

palette

models

Page 48: ME4AWSN - a Modeling Environment for Architecting WSNs

NODEML: Graphical and Tree-based editor

DEPML: Graphical editor with background image

MAPML: Tree-based editor

DEPML: Tree-based editor

Page 49: ME4AWSN - a Modeling Environment for Architecting WSNs

programming framework definition

languages refinement

modeling editors

code generators model-based

analysis tools

Page 50: ME4AWSN - a Modeling Environment for Architecting WSNs
Page 51: ME4AWSN - a Modeling Environment for Architecting WSNs

The fire alarm system considered is composed of two types of sensors that are temperature and smoke sensors. There are also sprinkler actuators that are used to enable the water flow in case of fire.

Temperature sensors monitor the temperature at regular intervals (every 30 seconds). When a temperature sensor reads a value that exceeds a specified threshold, it sends an alert message to the base station.

Each smoke sensor receives the alert and checks for smoke. When a smoke sensor detects smoke it sends an alarm message to the sprinklers to activate the water flow.

The automatic heating system is composed of the same temperature sensors of the fire alarm system, a base station and various heaters.

Temperature sensors send readings every 30 seconds to a base station. This is placed at the centre forming a star topology.

The base station averages the readings and decides whether or not the central heating system should be on.