Date post: | 29-Dec-2015 |
Category: |
Documents |
Upload: | shona-phelps |
View: | 215 times |
Download: | 0 times |
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