Prof. George Papadopoulos [email protected] Applied Electronics Laboratory (APEL), ECE Dept. University of Patras Industrial Systems Institute,

Prof. George [email protected]

Applied Electronics Laboratory (APEL), ECE Dept. University of PatrasIndustrial Systems Institute, RIC “ATHENA”

4th Mediterranean Conference on Embedded ComputingMECO 2015, Budva, Montenegro, June 14-18, 2015

Challenges in the Design and Implementation of Wireless Sensor Networks: A Holistic Approach

Development and Planning Tools, Middleware,Power Efficiency, Interoperability

Keynote Speaker Presentation

Outline

Challenges for Demanding WSNsMiddleware Level FocusDevelopment Level FocusDeployment Level Focus

4th Mediterranean Conference on Embedded Computing (MECO), June 14-18, 2015, Budva, Montenegro 2

Developing and Deploying WSNs

Wireless Sensor Networks (WSNs) constitute a rapidly evolving and nearing maturity networking area with impact on various domains (i.e. environment, health, industry) Different requirements about QoS and system performance

These domains require different levels of knowledge about the mechanisms residing over the HW, i.e. Sensors, Actuators, Radio Tx/Rx, such as: Scheduling policies, algorithms, OS, security mechanismsRouting and MAC protocols

Special knowledge is required regarding characteristics such as:Constrained energy, CPU and memory resourcesMulti-hop communication


Developing and Deploying WSNs

Incorporation of user friendliness, practicality and efficiency to boost WSN widespread use:Tools are needed to integrate all appropriate features for the

design of a WSNNeed for profiling and modeling of SW-HW in order to:

Identify critical featuresEvaluate/verify against application requirementsProvide design indications and suggestions

Achieve long life-cycle by componentizing SW, thus ensuring: FlexibilityExtendabilityReusability


Desirable WSN features leading to Sustainability

Low power consumption Long operational lifetime for

battery-powered unattended WSN nodes

Joint optimization of connectivity and energy efficiency Best-effort utilization of constrained

radios in WSNs & min energy cost Self-calibration and self-healing

Recovering from failures and errors to which WSNs are prone

Efficient data aggregation Lessening the traffic load in

constrained WSNs


Short development time Short time-to-market for

WSN systems

Programmable and reconfigurable stations Allowing for long life-cycle

development System security

Enabling protection of data and system operation

Simple installation and maintenance procedures Widespread use of WSNs

Targeting Large Scale Applications (LSK)

Despite of considerable research and important advances in WSNs, the technology for LSA is hindered by high complexity and cost

Ongoing R&D is addressing these shortcomings by focusing on energy harvesting, MW, interoperability, standardization, reliability, intelligence adaptability and scalability

For efficient WSN development, deployment, testing and maintenance, a holistic unified approach is needed to address the above WSN challenges by developing an integrated versatile platform

This platform will enable the user to evaluate and verify his development at design-time


Holistic Approach Methodology (1)

To develop an integration tool that provides a multiple level framework of functionality composition and adaptation for a complex WSN environment consisting of:heterogeneous platform technologiesdemanding constraints

To establish a software infrastructure which couples the different views and engineering disciplines involved in the development of such a complex system, by means of: the accurate definition of all necessary rules for interconnection

of various building blocks the design of the ‘glue-logic’ which will guarantee the correctness

of the various building blocks compositions


Holistic Approach Methodology (2)

To facilitate consistency control and evaluate the selections made by a Development Tool, and based on specific criteria provide: feedback on errors concerning consistency and compatibility warnings on potentially less optimal user selections suggestions for improving final system characteristics

To implement a planning tool that will provide answers to fundamental issues such as: the number of nodes needed to meet overall system objectives the deployment of these nodes to optimize network performance the adjustment of network topology and sensor node placement

in case of changes in data sources and network malfunctioning


Holistic Approach Methodology - Development Flow


Focus on core processes

Holistic Approach Methodology - Basic Entities to Attain Targets


Middleware Level seamless connectivity and interoperability issues over widely

heterogeneous device and communication technologiesDevelopment Level

establishing a framework that encompasses components built or adapted in this endeavor and providing synthesis capabilities

evaluating system performance, in conjunction with simulation tools and HW-in-the-loop at design-time

delivering the final codeDeployment level

connectivity evaluation, critical node detection and provides techniques for links reduction

Pictorial representation of the Holistic Approach


DesignerUser Developer DeployerField Tester

Tester

Development DeploymentWireless Sensor

NetworkMiddleware

Middleware Level Focus


Middleware (MW)-1

Motivation:Great “programming complexity gap” between development of

WSN applications and handling of underlying system operation, in order to cope with:dynamic changes of the operational environmentdifferent user-application requirementsheterogeneityThese WSN operation specificities result to special knowledge

requirementsApplication development in most common cases turns out to be

a rather low-level programming procedure, resulting to: relatively decreased energy efficiency and QoShigh resource consumption and time-cost

Lack of a unified basis of development to handle:


interoperability with other systems reusability of implementations

system adaptation system extendability

Middleware (MW)-2

Main Objectives:Implement a MW architecture which combines the state of the art in disjoint or loosely coupled research directions:Adoption of a uniform MDE approach which maps well through existing standard notations and SW modeling constructsUse of generalized high level application programming abstraction definitionsDeployment over a generic service/component execution framework, supporting system component reconfiguration and reprogrammingSupport of configurable resource consumption awareness both at design-time and at run-timeEnsuring interoperability based on mappings according to existing international standards and industry driven specifications


Middleware (MW)-3

High-level Functional Abstractions: Appear on top of lower level abstractions, in order to hide

functionalities corresponding to platform and network interfaces:CPU, memory storage, radio, network stack protocols

Encapsulate functionality of system or application level components:Processing

representing application level algorithms and logic Transducer (i.e. Sensors/Actuators),

Storage and Communicationhiding underlying

heterogeneity and corresponding access mechanisms

Parameterdefining the employed

data model


application-level abstraction

Middleware (MW)-4

Component Framework support: Combines CBD principles of accessing functionality implementations

in composing WSN systems/applications through interface contracts: IEC-61499: event-driven & data-flow process orientation SCA: typical synchronous method for call semanticsSysML covers ports representation for both event/data flow and

service-reference-properties features


Basic MW component elements and interfaces

Function Block

Parameter

Event Value type

Interface

Property

Middleware (MW)-5

Target application development example (temperature sensing): Local node-level composition of the application:

Displays the current temperature in a local device Turns-on an alarm when the temperature exceeds a threshold


The middleware provides the support for the function blocks interconnection

Temperature Sensing App

Timer KeyPad Custom Process Alarm

Display

Temperature Sensor

ADC

Middleware (MW)-6

Target application development example (temperature sensing): Distributed composition of the application:

Display, keypad, alarm and sensor parts exist on separate devices and exchange control and data seamlessly over the network


Device 1

Device 2

Device 4Device 3


Timer

Temperature Sensor

ADC

KeyPad

Display

Custom Process

Alarm

Development Level Focus


Development-1

Motivation:Existing development procedures of WSNs impede in some way

adequate widespread use because: In-depth knowledge is required at various levels: OSs, protocols,

platforms, programming etc.There are no fully integrated environments facilitating all phases of

development: design, develop, test, validate, maintain, extendWSN Simulation study suffers from various shortcomings:

Lack of accurate modelsUncertainties of hardware influence performance and behavior

Result: Inefficient cycles of development and unreliable system behavior estimation


Development-2

Main Objectives: Offer useful and practical tools enhancing the following aspects of

DT for both experts and non-experts:Employ standard SW development models and methods that

correspond to final implementation architecture Increase efficiency and decrease development complexityAdopt drag-and-drop approach for component synthesis

Offer HW-in-the-Loop techniques and propose approaches that will enhance simulation-based features of prominent simulators: Increase simulation accuracyTake hardware features into considerationProvide accurate power consumption estimation


Implementation methodology of the Development Tool

Identify key semantics from Middleware components:The MDE approach is applied, in conjunction with the Modeling

Language (SysML) for semantics description Develop a reference model (in SysML) in order to define primitive

development tool types (i.e. Function Block, Event, Parameter etc.) addressing the targeted MW architecture

Develop an application composition using the modeled primitive types

Validate the produced model by identifying errors/inconsistencies and proposing suggestions via a Synthesis Evaluation-Validation Module (SEVM)

Produce a configuration file which defines the interconnections between MW components at the implementation level and delivers the final code


Identification of key elements comprising MW architecture

Identify all key middleware architecture elements to define a proper, well-mapped component-based synthesis model


Property

Function Block

Value TypeEventInterface

Parameter

Function Block Event

Parameter Value Type

Interface Property

Identification of key MW elements’ relationships

Identify relationships and hierarchies between MW elementsA Function Block has one or more:

EventInputPorts and EventOutputPortsDataInputPorts and DataOutPortsActions bound with

ConditionsDataInputPort and

DataOutputPort are(= follow the structure/definition of)

ParametersEventInputPort and

EventOutputPort are EventPorts

EventPorts accept Events


Func

tion

Bloc

kParameter

DataInputPort DataOutputPort

Action

Condition

EventOutputPortEventInputPort

EventPort

Event

Development of a SysML reference model

Componentize middleware modules as SysML reusable reference blocks Timer, Sensor, Flash and Network Protocol, FFT algorithm

The example of a Timer SysML block, describing how a simple configurable MW module timer is represented in SysML, defining: Input event ports:

“STOP”, “START”, “START_ONESHOT”, “START_PERIODIC”

Output event ports:“FIRED”

Input data ports:“BASE”, “MODE”,

“INTERVAL” Output data ports:

“NOW”4th Mediterranean Conference on Embedded Computing (MECO), June 14-18, 2015, Budva, Montenegro 25

Internal state parameters

Input data Ports

The Timer block

Output data ports

Input event ports

Input event ports

Output dEvent ports

Development of an application using the SysML model

The example of Temperature Sensing Application designed/developed using SysML blocks and interconnection constructs. The user/developer may drag n’ drop elements and draw connections between them using a well-featured Graphical User Interface (GUI) An XML file is produced (i.e. using open-source Papyrus Plug-in of Eclipse IDE)

describing blocks and interconnections4th Mediterranean Conference on Embedded Computing (MECO), June 14-18, 2015, Budva, Montenegro 26


Timer KeyPad Custom Process

Alarm

Display

Temperature Sensor

ADC

The produced configuration and code for the employed application’s Function Block elements (after being validated) are injected in the WSN


SysML Development Tool

parse

.xm

l file

Mid

dlew

are

Application

FB1 FB2 FB4

FB3 FB5

Configuration chunk

FB2

FB3

FB4 FB8

FB5

FB6

FB1

FB7

FB services

Mid

dlew

are

FB3

FB5

FB7 FB8

FB2

FB4

FB1

FB6

MiddlewareOS

configchunk

WSN node

Based on the configuration MW establishes the

interconnections between the appropriate FBs

FB inter-connections indicated by the configuration file

Code chunks

Code of FBs included in the

application

FB1 code

FB1 code

FB1 code

FB1 code

Synthesis Evaluation-Validation Module (SEVM) Rationale

Validation is a crucial entity of the development process: The system synthesis described by the XML file is subjected to evaluation

and validation The meta-data that accompany the blocks in the XML file are evaluated

for consistencies against system requirements and specificationsThe consistency control ensures interoperability among different

platforms, protocols, implementations i.e. consistency of Bluetooth radio against network protocols

Evaluation of user selections regarding a particular WSN system synthesis based on criteria Feedback on errors (consistency/compatibility) Feedback on warnings (inefficiencies)

Best-Fit synthesis approach based on user requirements, letting the SEVM machine make decisions Pre-defined templates (“auto-complete” notion)


Synthesis Evaluation-Validation Module Objectives

Component-based structure/development perfectly match SEVM Rationale Quality attributes describe the components Components can be flexibly connected Generic approach followed (independently of the level of components’

functionality)

Answered questions Given primary system quality attributes, what about the component ones? Given a set of component attributes, what about the whole system ones? Accuracy of the predicted attributes? Any special conditions and constraints? Should components concern all types of modules, from low (i.e.

communication modules) to high-level ones (i.e. application-oriented ones)?


Comp 1 Comp 2

quality attrs quality attrs

Component LibrariesCode & metadata (xml)

Classification of typical Component Properties


Specification/SW module Application Routing MAC

Memory (Static/Dynamic) + + +Execution Delay + + +

Operating Environment restricts + + +WSN Platform restricts + + +MAC Protocol restricts +

Communication Approach Suitability +

Synchronization + +Control Traffic Overhead + +

Routing restricts +Density-adequacy +

Mean Medium Access Delay +

High-Level Synthesis Evaluation-Validation Module (SEVM)

Application Requirements:Communication traffic

specificationsCommunication approachNode densityPacket lossReal-Time requirements

Properties of SW modules in different levels(i.e. network stack)


Classification of Component Properties Relations

Restrictions and guidelines on user choices produce:


Failures related to Logic and Code generation

Derived fromCompatibility checks and properties’ correlation

Memorye.g.

Delay

Warnings related to Performance degradation and Operational failures

Derived fromExcessive resource utilization (e.g. Memory)Not efficient protocol selection (e.g. Routing)

Suggestions related toPredefined SW modules compositions and Specific SW/HW components

Hardware-in-the-Loop Rationale

Integrate aspects of the a real WSN operation into dominant WSN simulation environments

Omnet++ is selected as one of the most prominent network simulator providing High modularity and flexibility Component based

architecture Various WSN oriented

frameworks focusing on different aspectsCastalia: Focusing mostly on

Physical layerMiXiM: Focusing on

Communication protocols


OMNET++

Middleware

WSN OS HAL(i.e. TinyOS, Contiki)

Application Configuration

system call for HW-in-the-Loop

Virtual WSN

Development Tool

Real WSN

Hardware-in-the-Loop Rationale: 1st Example-Aspect


Simulation taking into consideration real wireless transmission characteristics

Hardware-in-the-Loop Rationale: 2nd Example-Aspect

Simulation taking into consideration processing capabilities

Typical example measurements


Application Layer

Application Layer

RoutingLayer

RoutingLayer

MACLayer

MACLayer

PHYLayer

PHYLayer

Simulated Channel

OMNET ++

Case1: All Software stack is by-passed

through HIL

Case2: Routing layer is by-passed

through HIL

RoutingLayer

MACLayer

PHYLayer

Real Mote

ApplicationLayer

RoutingLayer

MACLayer

PHYLayer

Real Mote

ApplicationLayer

Full Stack (sim)

MAC - less HIL

Full Stack HIL

Encryption HIL

Rx delay - ~1.01ms ~8.61ms ~10.46ms

Tx delay - ~0.09ms ~0.46ms ~0.47ms

end to end

delay~7.69ms ~8.7ms ~9.07ms ~10.82ms

MAC delay (sim)

~7.68ms ~7.68ms - -

Deployment Level Focus


Deployment-1

Motivation:Deployment is a cornerstone for adequate and energy efficient WSN

performanceWSN simulation suffers from various shortcomings such as insufficient

propagation models

Main Objectives:Optimal sensing coverage of an areaRealistic representation of signal propagation considering all

environmental and HW particularitiesOptimal and energy efficient connectivityConstruction of network topology based on application-driven network

requirementsSimple installation and maintenance


Deployment-2

Of paramount importance are the aspects of:Connectivity: seamless capability of getting data from the source

to the appropriate destinationTopology: nodes and links that allow direct communication

Objectives of a Planning Tool:Connectivity evaluation and identification of critical nodes

Critical nodes determine the reliable operation of the network, since possible malfunction or removal leads to partition

Topology controlTopology construction and link-reduction topologies

Neighbor-based link reductionRoute-related link reductionGateway association


The parking


Parking for >2000 cars, 500m x 150m 11 potential GW posts, 480 wireless nodes GW height: 2m, Nodes height: 0.2m Tx Power: 0dBm

Assumptions for the simulation

Parking 500m x 150m, for more than 2000 cars 11 potential GW posts: any number of GWs, up to 11, can be

selected. When the number of hops to a GW is more than 4-5 it is advisable another GW to be included to minimize the packet loss due to many number of hops

480 wireless nodes each serving 3 to 6 car-slots with magnetic or ultrasound sensors mounted on the node package or connected via wire

GW height: 2m, Nodes height: 0.2m, Tx Power: 0dBm 2-ray ground based propagation model biased with an extra

signal loss due to the presence of cars The output of the simulation is connected to Google Earth


Connectivity evaluation and detection of critical nodes (1)

Motivation: To evaluate the connectivity, against various design

parameters such as transmitted power, link quality, number of gateways and more, and provide design guidance regarding potential network partitions

To identify network sections with high probability of being disconnected and group the nodes belonging in these partitions. Suggest the judicious placement of GWs and/or relay nodes

To evaluate the existence of critical nodes, in the case of a connected network, which can potentially cause partition



Algorithms:Algebraic Graph Theory (AGT) approach:

AGT is based on representing the network topology as a graph and using linear algebra and matrix theory in studying of the graph

Depth First Search (DFS) approachDFS is an algorithm for traversing a graph from the GW of the

search tree until a node that has no children



Screen shot: max Tx power 0dBm, connected


5 GWs, 480 nodes, TxP = 0dBm Links 8844 Average number of neighbors: 17 Max hops to the GWs: 3


Screen shot: Tx power -10dBm, connected 23 critical nodes


5 GWs, 480 nodes, TxP = -10dBm Links 2212 Average number of neighbors: 4 Max hops to the GWs: 10 23 critical nodes


Critical questions and tradeoffs to tackle: When reducing Tx power

Number of hops increase Delay increase, more effort by the nodes to contend for medium access

The number of 1-hop neighboring nodes contending for the medium decrease Decreased congestion per each hop

Delay Wise Increased Tx power leads to less number of relays but higher possibility for packet

collision and retransmission delay Packet Loss Wise

Higher number of forwarding effort by the nodes means that in each hop less congestion will be encountered but numerically higher number of access contentions must be made

Power Wise Reducing Tx power means that each hop costs less but many more hops must be

madeA nexus of highly dynamic questions relative tools could tackle


Topology construction and link-reduction topologies (1)

Motivation:Propose reduced topology alternatives, which preserve the

connectivity and reduce the links between the nodes according to certain criteria, such as:predefined number of neighbors

Pertaining to degree of congestionspredefined n-connected topology

Pertaining to degree of robustnesspreliminary association to a gateway

Pertaining to application specific requirement



Two algorithms:Algorithm 1: K-ROUTE

Use MST (Minimum Spanning Tree) algorithm and reduce the number of the communication links by creating K-route connected topologies. Only the strongest links will be part of the new topology

Algorithm 2: N-NEIGHBThe algorithm is based on the idea to ensure N-number of

neighbors, thus providing a handle on the degree of contention



Screen shot: K-Route, 4-route



Screen shot: N-NEIGHB, 6 neighbors




Gateway association (1)

Motivation:To associate the nodes to the closest GWs to ensure 1 hop

direct communication when possible, at a Tx power of 0 dBmTo select, if 1-hop communication is possible to more than one

GW, the one with the better RSS linkWhen 1-hop direct communication is not possible, to evaluate

the multi-hop connection, based on the weight of the link, and associate the node with the GW, providing better overall link weight


Screen shot 1: after the association to 5 GWs



5 GWs, 480 nodes, TxP = 0dBm Max hops to the GW: 3

Screen shot 2: after the association to 3 GWs



3 GWs, 480 nodes, TxP = 0dBm Max hops to the GW: 7

Thank you for your attention

George Papadopoulos, Professor EmeritusIndustrial Systems Institute, RIC “ATHENA”, Patras

Applied Electronics Laboratory, ECE Dept., University of [email protected]

http://www.apel.ece.upatras.gr/papadopoulosTel.: 0030-2610-996423

Acknowledgement:ARTEMIS Joint Undertaking Project no 269389 WSN-DPCM


Documents

Prof. George Papadopoulos [email protected] Applied Electronics Laboratory (APEL), ECE Dept. University of Patras Industrial Systems Institute,