Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Wireless sensor networks softwaredevelopment University of Karlsruhe Institut for Telematics Telecooperation Office (TecO)
  2. 2.  Central vs. CollaborativeTecO 2
  3. 3. Central vs. CollaborativeEvent detection Central processing Event (yes/no)? Collaborative processing Event (yes/no)? Event: yes Event Event (yes/no)? (yes/no)?TecO 3
  4. 4. Central vs. CollaborativeCost ModelLinear 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 recoveryTecO 4
  5. 5. Central vs. CollaborativeEnergy 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 detectionTecO 5
  6. 6. Central vs. CollaborativeNetwork 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 slideTecO 6
  7. 7. Central vs. CollaborativeNetwork 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 behaviorTecO 7
  8. 8. Central vs. CollaborativeMessage 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 rateTecO 8
  9. 9. Central vs. CollaborativeResults and DiscussionResults Energy consumption: comparable Network load: advantage collaborative approach Loss recovery: advantage collaborative approachCritiques 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. 10. Central vs. CollaborativeConclusion and Future DirectionsConclusion Trend appears positive for collaborative approach Worth to further look into itFuture directions Extend cost model, adjust parameters (PhD thesis!) Real-world trials using sensor nodes Do the next step beyond CoBIsTecO 10
  11. 11.  eSealTecO 11
  12. 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 brokenTecO 12
  13. 13. eSeal SystemTecO 13
  14. 14. System RunTecO 14
  15. 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 sourceTecO 15
  16. 16.  Wireless sensor networks software developmentTecO 16
  17. 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? ? ServiceTecO 17
  18. 18. Goal and MethodGoal Add support for the programming of wireless sensor nodes to the SAP software processMethod 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 chainTecO 18
  19. 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 toolsTecO 19
  20. 20. Particle ComputerWhat 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 systemTecO 20
  21. 21. Java on Particle Computers  Subset of Java VM on Particle computer Java Source javac compilerJava ByteCode Strip down, optimization, versioning Wireless JavaJava ByteCode Transfer Virtual Machine for Particles Versioning control, Selective updates, Particle Computer Mass programming TecO 21
  22. 22. Particle VMFeatures 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 compilerNovel features Automatic version control for java classes Version‘ed upload mechanism for over-the-air programming Mass programming in fieldTecO 22
  23. 23. ParticleVM Runtime Library Functionality  Provides basic platform support  Java classes for  Object de-/serialization  Binding to hardware  Communication and message passing  Sensor abstraction interfacesSize of all .class files 12,87 KBSize of transformed .pclass files 1,76 KB# classes 20Factor of code size reduction by transformation 7,3Memory consumption (int. Flash) 7,8 %Table: Evaluation of runtime library TecO 23
  24. 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 hardwareTecO 24
  25. 25. ParticleVMCodesize 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 programTecO 25
  26. 26. Particle VMMemory 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 logicTecO 26
  27. 27. ParticleVMOver-the-Air programmingVersion 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 fastMass programming RF is inherently broadcast Code junks on air received by several Particle devices Only missed chunks are re-transmittedMeasured 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. 28. ParticleVMExecution 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. 29. Sun SPOTWhat is it? SPOT = Small Programmable Object Technology „Sun SPOT: Simplified Development of Wireless Transducers Using JavaTM Technology“ (source: Strong processor: 32 bit ARM7 256K RAM/2M Flash – runs Java Comm: 802.15.4 radio for medium access (MAC) Sensors: 3D accelerometer, Temperature, LightFocus is on development support, not hardware, not energy efficiency, not cost efficiency...TecO 29
  30. 30. Squawk 1.1Squawk 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 SizeVM Binary 149 KB Page tables 16 KBVM Suite (Java) 363 KB C Stack 8KB 8 KBJava Libraries 156 KB GC Stack 8KB 8 KBSum 668 KB C Heap 16KB 16 KB Flash Memory C Data 5KB 5 KB Java Heap KB min. 14 KB Sum 67 KBParticle VM Flash Memory: 60KB RAM RAM: 3KBTecO 30