1. Wireless sensor networks software
development
University of Karlsruhe
Institut for Telematics
Telecooperation Office (TecO)
www.teco.uni-karlsruhe.de

2.  Central vs. Collaborative
TecO 2

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

11.  eSeal
TecO 11

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

13. eSeal System
TecO 13

14. System Run
TecO 14

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

16.  Wireless sensor networks software development
TecO 16

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