Service-Oriented Software Architecture for Sensor Networks Jan Blumenthal University of Rostock IMC Rostock, 17 th June 2003.

Service-Oriented Software Architecture for Sensor Networks

Jan BlumenthalUniversity of Rostock

IMCRostock, 17th June 2003

2

Outline

• Introduction to sensor networks

• Requirements

• Software Engineering

• Approach

• Conclusion

3

Evolution of sensor nodes

Smart

Dust

(UCB)

Piece of

Silicon

Sensor,Actuator

Battery

Processor HF

Picoradio

(UCB)

WINS

(UCLA)

PC

Blue-Node (UoR)

4

Characteristics of Sensor Nodes

• Limited capacity of– Battery (Lifetime: days – 10 years)– Processing capabilities– Transmission range (5…20

meters)

• Data rates: Bit/s … KB/s• Transmission methods:

– Bluetooth– ZigBee– nanoNET

• One specific application• Price: some cents

Coming up sensor nodes

5

Characteristics of Sensor Networks

Properties:• Wireless sensor nodes connect together autonomously• Distributed organization• Contain one or more data sinks • Huge number of nodes to compensate transmission range (density: 0.1

- 20 nodes/m2)• Nodes may move around

Tasks:• Cooperative data acquisition:

– Cooperative data collection and preprocessing– Running distributed applications regionally– Forwarding of results to higher application levels

• Adaptive reactions on environment modifications• Network has to behave robustly and fault-tolerant to:

– Failure on single nodes– Transmission errors and distortion through obstacles– Intrusion and jamming

6

Applications

Stress Monitoring

Measurements in FluidsIntra Corporal Measurements

Sensor Node

Protecting flood dam with sandbags

7

Requirements of Sensor Networks

1. Self-Organization– Ad hoc network formation– Autonomous connection establishment

2. Network Maintenance– Addressing of nodes– Routing facilities– Compensation of network failures

3. Cooperative Processing– Context awareness– Location positioning and location awareness– Preprocessing of collected raw data

4. Security Mechanisms5. Energy Optimizations

8

Context Awareness

• Infrastructure context– Refers to the infrastructure around the node– Example: Perception of bandwidth and reliability

• Domain context– Refers to the current environment of the node– Example: Knowledge of next data sink in the network

Data sink node

Simple node

Transmission range

Context Awareness: Adapts the behavior of the node to the current environment

9

• Transfer to

• Measurement the field strengths of and

• Triangulation / multilateration• Transfer of determined

positions to data sink• Max. 6 transmissions• Decentralized positioning

Cooperative Algorithms

• Reduction of data by preprocessing and aggregation • Minimization of data stream to data sinks

Example: Positioning

3E

3N

1E

2E

1E

2E

3E

3N

1N2N

10

Network Maintenance

• Attribute based addressing– Assignment of data to location of data mining– Location awareness necessary– ID based addressing unfavorable

• Random node distribution • Routes become obsolete quickly due to mobility

– Example: Temperature at location (x, y) ?• Cooperative network behavior

– Data aggregation– Address resolution / location awareness– Adaptive routing strategy depends on mobility of nodes

• Communication reduction / avoidance– Connectionless transmission– Prevent network traffic through data aggregation– Event based communication in contrast to request / reply– Polling avoidance

11

Software Engineering

• Hides the complexity of the distributed system• Standardized API to node application• Provides access to services on remote nodes

Network MaintenanceServices

Hardware AbstractionCooperative Algorithms

Context Awareness

Middleware

Common Middleware:

Goal: Same middleware on different platforms

12

Middleware Properties

Scalable Middleware• Customization of data types during compile time• Removing of unused components

Generic Middleware• Platform independent middleware leads to increased number of

complex interfaces• Adaption of interfaces instead of programs

void setBaudrate(int handle, int baudrate){ hardware_addr=getIOAddress(handle); hardware_addr->BTR0=baudrate;}

void setBaudrate(int baudrate){ // getIOAddress(handle); BTR0=baudrate;}

Non Generic Middleware Generic Middleware

Savings: parameter delivery, function call, stack operation, return value assignment, field operation

Valid only, if one interface present

13

Middleware Properties II

Adaptive Middleware• Mobility and changes in infrastructure require adaptions to the

software– Cluster head selection requires additional routing software– Changing measurement methods leads to new programs

• Exchange and run components dynamically– Start of new services

Reflective Middleware• Ability to understand and influence itself• Application layers are not affected• Inspection: Analyze behavior via logging / debugging• Adaptation: Changing behavior of internal layers.• Example: Customizing routing strategy depending on mobility

To overcome all the mentioned requirements we designed a software model! !

14

Our Approach

• Adaption of program to the application taskinsteadadaption of application task to the program

• Adaption of interfaces to the programinsteadadaption of the program to the interfaces

• Application-dependent customized software componentsinsteadmultipurpose software on each node

15

Definitions

• Measurements and storage of data

• Hardware dependant• Example:

– Software driver for temperature sensor

Sensor Application

• Application specific parts

• Middleware (routing, discovering nodes)

• Contains sensor application

Node Application

Sensor Network Application

• Describes main tasks of the entire network• Contains several node applications• Optional administration interface

16

Node Application

Internal interface (generic middleware)

Operating System

CPU

Sensor Driver

ServicesModulesAlgorithms

Host Middleware

Middleware Management

VM

Sensor

No individual high level application, because:• Nodes provide services only to the network• Focus: Success of sensor network application instead of

node application• Cooperative behavior of nodes

Sensor application

Dynamic components

17

Sensor Network Application

systemwide interfaces

• Middleware and Operating System are compiled and optimized to each hardware

• Sensor Network Application– Composition of all node services

• Optional administration terminal to manage the entire network

Middleware

Operating System

Hardware

Distributed Middleware

Middleware

Operating System

Hardware

Administration Terminal

Node A Node B Node C

Sensor Network Application

Middleware

Operating System

Hardware different node hardware

boot, logging

customized node‘s software

18

Sensor Network Design

Compile/Link

Design & Edit

Distribute

Execute/Administrate

Development Studio

ResourceHardware

driven

Monitoring

Evaluation Optimization

Components

Changes to common design methods.

• Create hardware-optimized software components (driver, operating system)• Create hardware-independent software components (middleware, services)• Combining of predefined components• Source code generation• Removing unused components• Optimization of interfaces• Optimization to node‘s hardware

• Distribution of nodes in different environments

• Monitoring the execution• Creation of logfiles

• Evaluation of logfiles

19

Conclusion

• New challenges of software development in sensor networks

• Optimization of node‘s software based on– Interface design– Adaptive and reflective middleware

• Design of service-oriented middleware in sensor networks

• Future work– Realization of presented software concept– Development studio

Thank youAny questions ?

21

Services

• Discovering and using services• Cascading of services without previous knowledge of each

other

Definition: Little program accessed by standardized interfaces over the network.

Service infrastructure for remote access:

Service Proxy

PhysicalPhysical

LANBluetooth

Surrogate Host

Proprietary protocol

Sensor ASensor B

Sensor C

Surface profile service

Surface profile ?

Client

RequestRequest

TCP/IPReply Reply

22

Software ArchitectureDesktop Model Resource optimized

Application SpecificOS Modules

Middleware

Application

Middleware

Application

Operating System

Hardware Hardware

Sensor Node

Middleware

SensorDriver

NodeSpecific

OS Modules

Hardware Sensor

• Independent applications

• Standardized middleware

• Standardized operating system

• Example: Jini

• Independent applications

• Standardized middleware

• Standardized interfaces

• Unused components removed

• No independent applications

• Customized middleware

• Proprietary interfaces• Optimized driver

software

Not optimized (Partly) optimized modules

23

Example

Middleware

SensorDriver

NodeSpecific

OS Modules

Hardware Sensor

Middleware

ARMTemperature

Sensor

SensorDriver

NodeSpecific OS

Modules

68HC11

NodeSpecific

OS Modules

Middleware

68HC11PressureSensor

NodeSpecific

OS Modules

SensorDriver

Middleware

Sensor Node Model

• ARM Microcontroller• Temperature Sensor

• 68HC11 Microcontroller• Pressure Sensor

• 68HC11 µC• No Sensor