1. Wireless sensor networks software
development
University of Karlsruhe
Institut for Telematics
Telecooperation Office (TecO)
www.teco.uni-karlsruhe.de
3. Central vs. Collaborative
Event detection
Central processing
Event
(yes/no)?
Collaborative processing
Event
(yes/no)?
Event: yes
Event Event
(yes/no)? (yes/no)?
TecO 3
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 4
5. Central vs. Collaborative
Energy Consumption
4
Overall Energy Consumption [energy units]
x 10
10
Central
9
Collaborative
8
7
6
5
4
3
2
1
10 20 30 40 50 60 70
Node Count
Small advantage for collaborative processing due to
communication at event detection
TecO 5
6. Central vs. Collaborative
Network Load
0.35
Central
0.3
Collaborative
0.25
Network Load [%]
0.2
0.15
0.1
0.05
0
10 20 30 40 50 60 70
Node Count
Assumption: constant communication period, no losses,
no bursts
What happens at irregular traffic? next slide
TecO 6
7. Central vs. Collaborative
Network Load (irregular traffic)
0.35
0.3
Network Load [%]
0.25
0.2
0.15
0.1
0.05
0
0
20 80
40 60
40
60 20
80
0
Communication period Node count
Load metric moves on a cost surface for irregular traffic
Bursts account for non-linear behavior
TecO 7
8. Central vs. Collaborative
Message Loss Recovery
7000
Central
Time units to recover from loss
6000 Collaborative
5000
4000
3000
2000
1000
0
10 20 30 40 50 60 70
Node Count
Assumed loss rate: 30%
Fast recovery for collaborative due to low network delay and
lower communication rate
TecO 8
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 9
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 10
12. eSeal Idea
Transfer of the idea of a classical wax seal to
(perishable) goods.
Access integrity Conditional integrity
(Valid or Active, autonomous
broken) monitoring
Authenticity Electronic
authenticity
Valid or broken
TecO 12
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 15
17. State-of-the-Art
SOA = architecture paradigm for developing service-oriented
heterogenous software systems, application
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
Interface
Java is one of the dominant language for specified
realizing SOA
Modern language, lots of developers, very good
tool support (safe development), used for
business applications
So, why not using Java?
? Service
TecO 17
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 18
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 19
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 20
21. Java on Particle Computers
Subset of Java VM on Particle computer
Java Source
javac compiler
Java ByteCode
Strip down, optimization, versioning
Wireless Java
Java ByteCode Transfer Virtual Machine
for Particles
Versioning control,
Selective updates, Particle Computer
Mass programming
TecO 21
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 22
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 23
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 24
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 25
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 26
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 27
28. ParticleVM
Execution Speed
Avg. interpretation overhead: 3000 % (factor 30)
160
Program execution
140 Flash overhead
120
Measurement
Slowdown factor
100
platform:
80 Particle Sensor
node
60 5MIPS@20Mhz
40
20
0
Audio sampling Prime number Sum calculation
calculation
Flash overhead: slowdown caused by access to flash for
new byte code instructions
>50% slowdown due to flash overhead (and not Java)
TecO 28
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 29
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 Size
VM Binary 149 KB Page tables 16 KB
VM Suite (Java) 363 KB C Stack 8KB 8 KB
Java Libraries 156 KB GC Stack 8KB 8 KB
Sum 668 KB C Heap 16KB 16 KB
Flash Memory C Data 5KB 5 KB
Java Heap KB min. 14 KB
Sum 67 KB
Particle VM
Flash Memory: 60KB RAM
RAM: 3KB
TecO 30