1. A Dynamic Operating System for Sensor Nodes (SOS) Source:The 3 rd International Conference on Mobile Systems, Applications, and Service (MobiSys 2005) Authors:Simon Han, Ram Kumar, Roy Shea, Eddie Kohler and Mani Srivastava Presented by Yoonjae Jeong and Sunjun Kim October 12, 2009CS542 @ 2009 1

2. Contents Introduction System Architecture PROS vs. CONS PROS (including Evaluation) Conclusion October 12, 2009CS542 @ 2009 2

3. Introduction The Characteristics Low-power, poor performance device Ex) AtMega128 – 128Kb Flash, 4K SRAM, 10Mhz In-situ update Need to be re-programmed during use Tradeoff between flexibility & Concise update Robustness Need to deal with various failures * failures examples: - function call during module update(or after module removal) - Memory curruptions October 12, 2009CS542 @ 2009 3

4. Introduction Base Work TinyOS – Application specific OS App, OS, and drivers are NesC components, are integrated in single static binary Statically analyze and optimized Supports full binary upgrades Maté Domain specific bytecode interpreter on TinyOS Programs are small scripts containing VM instructions Better suited for application specific tuning October 12, 2009CS542 @ 2009 4

5. Introduction SOS Design Goals A general-purpose, application independent sensor OS In TinyOS and Maté, app and OS are tightly linked Towards traditional kernel space/user space model Re-programming via binary modules Risk : lose safety provided by static analysis or dynamic interpreter Design Challenges Resources-constrained embedded sensor nodes October 12, 2009CS542 @ 2009 5

6. System Architecture Architecture Overview October 12, 2009CS542 @ 2009 6 Dynamic Memory Dynamic Memory Message Scheduler Message Scheduler Dynamic Linker Dynamic Linker Kernel Components Sensor Manager Sensor Manager Messaging I/O Messaging I/O System Timer System Timer SOS Services Radio* I2C ADC* Device Drivers Tree Routing Module Tree Routing Module Data Collector Application Data Collector Application Photo-sensor Module Photo-sensor Module Dynamically Loaded modules Static SOS Kernel * - Drivers adapted from TinyOS for Mica2

7. System Architecture SOS Kernel Kernel Components Dynamic memory Dynamic Linker Message Scheduler SOS Services Sensor Manager System Timer Messaging I/O Device drivers October 12, 2009CS542 @ 2009 7

8. System Architecture SOS Module Modules implement specific function or task Modules can be dynamically loaded and unloaded Position independent binary Modules can communicate with other modules or kernel with messaging or dynamic linking October 12, 2009CS542 @ 2009 8

9. System Architecture Inter-module Communication Dynamic Linking Synchronous Should return promptly Message Passing Asynchronous Long running operations October 12, 2009CS542 @ 2009 9 Module Function Pointer Table Dynamic Linking Module A Module B Message Passing Message Buffer Module A Module B

10. System Architecture Inter-module Communication ( detail ) Dynamic Linking Each module publishes their function address FCB(Function Control Block) in kernel stores published function information FCB subscribes functions to other modules Message Passing Each message is stored in priority message queue No dynamic priority assign/change: - programmer should set the priority when they send a message Messages can carry parameters, or more complex data between modules October 12, 2009CS542 @ 2009 10

11. System Architecture Module-Kernel Communication October 12, 2009CS542 @ 2009 11 Kernel services available as system calls Jump table redirects system calls to handlers Update kernel independent of modules System Call Overhead - 12 clock cycles Data Collector Module System Jump table Priority Scheduler SOS Kernel Hardware System Call HW specific APIInterrupt Service System Messages

12. System Architecture Safety Concerns Dynamic Linking Run-time type checking Message passing Watchdog support High priority messaging (by priority queue) Dynamic Memory Allocation Memory overflow detection Owner tagging Garbage Collection October 12, 2009CS542 @ 2009 12

13. PROS vs. CONS Brief Analysis (1/2) PROS Well motivated and constructed paper in term of system architecture. SOS provides a framework for reusable binary modular architecture in sensor network operation system. SOS shows not-bad performance in term of CPU overhead, code size and energy consumption, while their framework provides more functionalities. October 12, 2009CS542 @ 2009 13

14. PROS vs. CONS Brief Analysis (2/2) CONS Authors did not justify why dynamic modules are important in sensor network operating system well. We needs actually useful application scenarios for sensor network environments. There is no evaluation for the safety. It still contains the limitation of event-driven system. Long-run tasks can reduce the overall system performance. October 12, 2009CS542 @ 2009 14

15. PROS (including Evaluation) Contribution of This Paper Framework for binary modular re-programming Dynamic linking Message passing Dynamic memory Inexpensive safety mechanisms for an embedded OS Type safe linking Monitored memory allocation Garbage collecting scheduler and error stub Watchdog mechanism General purpose OS semantics on sensor nodes October 12, 2009CS542 @ 2009 15 What about Performance?

16. PROS Evaluation Design Goal of SOS Provide general purpose OS semantics Low resource utilization Hypothesis Performance no worse TinyOS Update cost closer to Maté Experiment Setup Surge data collection and tree routing on 3 hop network Low duty cycle application Mica2 motes: AVR 8-bit microcontroller October 12, 2009CS542 @ 2009 16

17. PROS Evaluation: Macro Benchmarks Application performance is nearly identical for TinyOS, SOS and Maté October 12, 2009CS542 @ 2009 17 Different Boot Routine Different Protocols for Code Dissemination Fluctuating Wireless Link Quality & Different Code Update Protocols

18. PROS Evaluation: CPU Overhead CPU Active Time - Metric to measure OS overhead Measured by profiling Surge for 1 min on real nodes Examining the CPU active tie when running Surge on each of SOS, TinyOS, and Maté. SOS has 1% overhead relative to TinyOS Surge has minimal application level processing (“worst” case OS overhead) October 12, 2009CS542 @ 2009 18 TinyOSSOSMaté Percent Active Time4.58 ± 0.02 %4.64 ± 0.08 %5.13 ± 0.02 %

19. PROS Evaluation: Code Updates October 12, 2009CS542 @ 2009 19

20. PROS Possible Applications October 12, 2009CS542 @ 2009 20 Dynamically installing new behavior modules on ragobot Ragobot - Mobile Sensor NodeBuilding Automation Remote operation and management of the sensor network infrastructure Mobile agent applications and a lot more …

21. Conclusion SOS enables dynamic binary modular upgrades Design choices minimize resource utilization Run-time checks for safe code execution Ported to AVR, ARM, TI MS October 12, 2009CS542 @ 2009 21