Wireless sensor networks software development University of Karlsruhe Institut for Telematics Telecooperation Office (TecO) www.teco.uni-karlsruhe.de
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Wireless sensor networks software
development
University of Karlsruhe Institut for Telematics Telecooperation Office (TecO) www.teco.uni-karlsruhe.de
TecO 2
Central vs. Collaborative
TecO 3
Central vs. Collaborative Event detection
Central processing
Collaborative processing
Event (yes/no)?
Event (yes/no)?
Event (yes/no)?
Event (yes/no)?
Event: yes
TecO 4
Central vs. Collaborative Cost Model Linear cost model
Includes parameter such as
Communication period communication costs
Execution time execution costs
Event rate detection frequency
Sampling period sampling costs
Sensor node energy budget energy units
Packet processing time comm. stack delay
Realtime requirement: event rate < communication rate (!)
Parameters derived empirically for wireless sensor network (Particle sensor nodes running Java) and standard desktop PC
Investigated criteria
Energy consumption
Network load
Message loss recovery
TecO 5
Central vs. Collaborative Energy Consumption
Small advantage for collaborative processing due to communication at event detection
10 20 30 40 50 60 701
2
3
4
5
6
7
8
9
10x 10
4
Node Count
Ove
rall E
ne
rgy C
on
su
mp
tio
n [
en
erg
y u
nit
s]
Central
Collaborative
TecO 6
Central vs. Collaborative Network Load
Assumption: constant communication period, no losses, no bursts
What happens at irregular traffic? next slide
10 20 30 40 50 60 700
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Node Count
Ne
two
rk L
oa
d [
%]
Central
Collaborative
TecO 7
Central vs. Collaborative Network Load (irregular traffic)
Load metric moves on a cost surface for irregular traffic
Bursts account for non-linear behavior
0
20
40
60
80020
4060
80
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
Node countCommunication period
Ne
two
rk L
oa
d [
%]
TecO 8
Central vs. Collaborative Message Loss Recovery
Assumed loss rate: 30%
Fast recovery for collaborative due to low network delay and lower communication rate
10 20 30 40 50 60 700
1000
2000
3000
4000
5000
6000
7000
Node Count
Tim
e u
nit
s t
o r
ec
ov
er
fro
m l
os
sCentral
Collaborative
TecO 9
Central vs. Collaborative Results and Discussion
Results
Energy consumption: comparable
Network load: advantage collaborative approach
Loss recovery: advantage collaborative approach
Critiques and discussion
Simplicity
Cost model is only linear
Still too few parameters
Coverage
There is more than energy, network load, loss recovery
Business aspects missing
TecO 10
Central vs. Collaborative Conclusion and Future Directions
Conclusion
Trend appears positive for collaborative approach
Worth to further look into it
Future directions
Extend cost model, adjust parameters (PhD thesis!)
Real-world trials using sensor nodes
Do the next step beyond CoBIs
TecO 11
eSeal
TecO 12
eSeal Idea
Access integrity (Valid or broken)
Authenticity
Conditional integrity
Active, autonomous monitoring
Electronic authenticity
Valid or broken
Transfer of the idea of a classical wax seal to (perishable) goods.
TecO 13
eSeal System
TecO 14
System Run
TecO 15
eSeal Device
Key component providing a trustworthy statement about the eSeal state – valid or broken
MPU computes the eSeal‘s state
Sensors serves as external input
RF Communication for eSeal‘s state queries (authenticated)
Power source
TecO 16
Wireless sensor networks software development
TecO 17
State-of-the-Art
SOA = architecture paradigm for developing heterogenous software systems, e.g. SAP <–> Wireless sensor networks
No standard, systematic way to develop services for wireless sensor networks
Current:C-code / assembler hacking, rule engines, propriatary languages
Java is one of the dominant language for realizing SOA
Modern language, lots of developers, very good tool support (safe development), used for business applications
So, why not using Java?
service-oriented application
Service
Interface specified
?
TecO 18
Goal and Method
Goal
Add support for the programming of wireless sensor nodes to the SAP software process
Method
Stay with Java, no new language, but API support, e.g. a class hierachy supporting functions for wireless sensor nodes (runtime environment)
Utilize complete SAP Java tool chain
TecO 19
Advantages
Re-use and exploit software design pattern for WSN, e.g. visitor pattern
Highly optimizable Java interface to sensor nodes
Exception support in the same language (hard to realize in a SOA approach)
SAP software developer needs only little additional knowledge on sensor networks, but utilizes common tools
TecO 20
Particle Computer
What is it?
Wireless sensor node
Tiny: size matters, e.g. in automation industries
Executes business logic ( EU funded project CoBIs)
Hardware
Low-power 16bit microcontroller (cost efficient)
128KB ROM, 4KB RAM
Sophisticated radio protocol for highly mobile, adhoc setting
Sensors: accelerometer,light temperature sensor
IR location system
TecO 21
Java on Particle Computers
Subset of Java VM on Particle computer
Java Source
Java ByteCode
Java ByteCode for Particles
javac compiler
Strip down, optimization, versioning
Particle Computer
Java Virtual Machine
Wireless Transfer
Versioning control, Selective updates, Mass programming
TecO 22
Particle VM
Features
All java language features except for reflection and exception handling
Automatic garbage collection
Object de-/serialization
Usage of 32bit arithmetic operation on low-end (16bit and 8bit) microcontrollers
Guarentees type safeness
Java Native Interface (JNI) for time critical or performance critical execution, e.g. sensor sampling, communication
Executes byte code generated by standard Sun‘s javac compiler
Novel features
Automatic version control for java classes
Version‘ed upload mechanism for over-the-air programming
Mass programming in field
TecO 23
ParticleVM Runtime Library
Functionality
Provides basic platform support
Java classes for
Object de-/serialization
Binding to hardware
Communication and message passing
Sensor abstraction interfaces
Size of all .class files 12,87 KB
Size of transformed .pclass files 1,76 KB
# classes 20
Factor of code size reduction by transformation 7,3
Memory consumption (int. Flash) 7,8 %
Table: Evaluation of runtime library
TecO 24
Sensor Abstraction
Decouples logic and algorithm from concrete sensing hardware
Enables late binding at runtime to concrete sensor
Particle VMs „instance of“ operator allows tests for concrete interface (simple form of reflection)
concrete sensor has not to be known apriori
Complete object-oriented encapsulation of sensor hardware
TecO 25
ParticleVM Codesize reduction
Usage of Java byte code reduces code size of programs
Reason: Java VM is stack machine, no register addressing necessary complete opcode is 8bit wide
Program Size absolute Size relative
Native, 32bit 372 byte 702 %
Native, 16bit 228 byte 430 %
Native, 8bit 144 byte 272 %
Java byte code 53 byte 100 %
Table: Code size comparison for prime number calculation test program
TecO 26
Particle VM Memory consumption
Low memory consumption
executable on low-end microcontrollers (cost efficient)
RAM ParticleVM (1.5 KB) VM-Heap ParticleOS
(3.5 KB) Interpreter Stack, buffers,... (1.5 KB) (0.5KB)
Program Flash
(128KB) Particle VM ParticleOS Free
(60KB) (45KB) (23KB)
External Flash
(max. 512KB) Storage for Application
Java classes
512KB for user java application
May allow even complex business logic
TecO 27
ParticleVM Over-the-Air programming
Version control
Automatic versioning within class files
Version control on PC and Particle sensor node (!)
Transfer only new classes or updated classes
small code updates
very fast
Mass programming
RF is inherently broadcast
Code junks on air received by several Particle devices
Only missed chunks are re-transmitted
Measured results on Particle sensor nodes
Class update: 2-4 seconds
Runtime library (20 classes): 50-60 seconds
Update time is sublinear regarding number of Particle nodes (due to mass programming)
TecO 28
ParticleVM Execution Speed
Avg. interpretation overhead: 3000 % (factor 30)
Flash overhead: slowdown caused by access to flash for new byte code instructions
>50% slowdown due to flash overhead (and not Java)
0
20
40
60
80
100
120
140
160
Audio sampling Prime number
calculation
Sum calculation
Slo
wd
ow
n f
acto
r
Program execution
Flash overhead
Measurement platform: Particle Sensor node 5MIPS@20Mhz
TecO 29
Sun SPOT
What is it?
SPOT = Small Programmable Object Technology
„Sun SPOT: Simplified Development of Wireless Transducers Using JavaTM Technology“ (source: http://research.sun.com/)
Hardware
Strong processor: 32 bit ARM7 256K RAM/2M Flash – runs Java
Comm: 802.15.4 radio for medium access (MAC)
Sensors: 3D accelerometer, Temperature, Light
Focus is on development support, not hardware, not energy efficiency, not cost efficiency...
TecO 30
Squawk 1.1
Squawk
Java VM on Sun SPOT
As little as possible in native C, almost all in Java
requires lots of ressources and a strong processor
Size
VM Binary 149 KB
VM Suite (Java) 363 KB
Java Libraries 156 KB
Sum 668 KB
Size
Page tables 16 KB
C Stack 8KB 8 KB
GC Stack 8KB 8 KB
C Heap 16KB 16 KB
C Data 5KB 5 KB
Java Heap KB min. 14 KB
Sum 67 KB
Flash Memory
RAM
Particle VM
Flash Memory: 60KB
RAM: 3KB