LiteOS: Unix Like Operating System for WSN

1. LiteOS: Unix Like Operating System for WSN Presenter – Jay Author - Qing Cao [qcao2@cs.uiuc.edu] http://www.cs.uiuc.edu/homes/qcao2/index.html

2. Various Flavors • TinyOS • http://www.tinyos.net/ • SOS • https://projects.nesl.ucla.edu/public/sos-2x/doc/ • Mantis • http://mantis.cs.colorado.edu/index.php/tiki-index.php • Contiki • http://www.sics.se/nes • http://www.sics.se/contiki/ • t-Kernel • http://www.cs.virginia.edu/~stankovic/sensornet.html • Best Paper Sensys 2006 • Lite OS • Being presented at Sensys 2007

3. Tiny OS • Event Based • Components : Modules and Wirings • Written at Berkeley • Works on state diagrams • Ultra low power • nesC

4. SOS • Kernel provides • messaging, • dynamic memory, • module loading, • simple garbage collection, • Priority scheduling • Reconfigure individual components of a deployed system. • C Language

5. MANTIS • Developer friendly C API with Linux and Windows development environments • Automatic preemptive time slicing for fast prototyping • Diverse platform support including MICA2, MICAz, and TELOS motes • Energy-efficient scheduler for duty-cycle sleeping of sensor node • Small footprint (less than 500B RAM, 14KB flash)

6. Contiki • Contiki consists of an event-driven kernel on top of which application programs are dynamically loaded and unloaded at runtime. • Contiki processes use light-weight protothreads that provide a linear, thread-like programming style on top of the event-driven kernel. • Contiki also supports per-process optional preemptive multi-threading, interprocess communication using message passing through events, as well as an optional GUI subsystem with either direct graphic support for locally connected terminals or networked virtual display with VNC or over Telnet. • Contiki contains two communication stacks: uIP and Rime. uIP is a small RFC-compliant TCP/IP stack that makes it possible for Contiki to communicate over the Internet.

7. t-Kernel • OS protection from Application • Virtual Memory • Pre emptive Scheduler • Extensive code modification at load time. • Has overhead • Energy efficiency

8. Lite OS • Built in Hierarchical File System • Wireless Shell to interact using Unix like commands • Kernel support for dynamic loading • Native execution of multi threaded applications • Obj Oriented Language , subset of C++

9. Lite OS : Introduction • What? • A new WSN Operating System • Why? • Expand the network of application developers • Where? • UIUC • Who? • Qing Cao • When? • Sensys 2006 – Demo, Sensys 2007 Paper

10. Differences • Vs. Current WSN OS • Familiar environment, Familiar OS • Vs. Traditional Embedded system OS • Smaller footprint • VxWorks, eCos, embedded Linux, Windows CE

11. Footprint • Lite OS Kernel • 8300 lines of C Code • Binary size: 30822 bytes or 30K • Consumes 1633 bytes of Ram or 1.6K • Lite OS Shell • 2200 lines of Java Code • LiteC++ Compiler • 12100 lines of C Code • 1200 lines of Perl Code • Disclaimer • Device drivers ( CC2420 from TinyOS ) not counted • Release • 2007 under open source

12. LiteOS : Architectural View

13. Lite OS : Architectural View • Provides wireless node mounting • Node looks like file directory to base system. • Lite shell supports Unix like commands such as cp, mv etc. • Basic version takes Trusted Environments into consideration.

14. Lite Shell • Unix commands such as cp, mv • Some new ones such as foreach, $ • Command Types • File • Process • Group • Environment • Security

15. Command Listing

16. File Operation Commands • Multi Level control access • 0, 1, 2 ( highest ) • Chmod to change permissions • Cp to copy files from base station to node and vice versa.

17. Process Operation Commands • Four commands to control process behaviour • Install • Only instructions that have programmed into the programming space can be executed • Uninstall • Ps • Kill

18. Group commands

19. Environment Commands • History • Who • Man • Echo

20. Security Commands • Login • Logout • Passwd • MD5 digest. • Computing is expensive, hence nodes store the digest instead of values. • Administrator username/pwd stored at boot time. • Cannot prevent replay attacks.

21. Lite Shell Implementation

22. Lite Shell Implementation • Nodes are stateless • Data cache • Ls command run repeatedly will fetch from cache • -u ( update ) option available • Invalidate cache

23. Lite Shell : Performance Eval

24. Lite Shell : Performance

25. Lite FS • Previous file systems • Matchbox • ELF • Capsule • Hierarchical • Most APIs resemble “stdio.h” in C • fcheckEEPROM • fcheckFlash

26. LiteFS : API

27. LiteFS : Design Choices • EEPROM • Update at byte level • 1 CPU cycle to read, CPU blocks for 4 cyles • Writing takes 8848 cycles • Serial Flash • Page level ( 256 bytes ) • 2 * 264 SRAM buffers • Reading : 250 micro seconds • Writing : 14-20 milli seconds

28. LiteFS : Decisions • Serial Flash : Sequential Data updates • EEPROM : Granular level updates.

29. Lite FS Architecture

30. LiteFS : Implementation • RAM • Open files • Allocation information for EEPROM , Flash • EEPROM • Hierarchical directory information • Flash • Store files. • File Types • Data, Application binaries, DEVICE DRIVERS

31. LiteFS : Implementation • RAM • 8 handles ( 8 byte each ) • 8 files opened simultaneously • Bit vector for EEPROM • 8 bytes • Bit vector for Flash • 32 btytes • Total space used is 104 bytes

32. LiteFS : Implementation • EEPROM • File is represented by 32 byte control block • 65 blocks • Uses 2080 bytes • First block is root block, 64 application needs • Four types of control blocks • File, Directory, binary application, device driver • File name 12 bytes ( 8.3) • Addresses 10 flash pages ( 2K each ) • More than 20K bytes, control block has pointer to next block

33. Wear level optimization • EEPROM • Periodic cylic permutation • Relative addresses • ( B – A + 64 ) mod 64. • During permutations, relative distance between blocks remains constant • Cost : 2048 bytes written.

34. Lite FS: Performance

35. LiteOS : Kernel • Thread based • Priority Scheduling, Round Robin • Eight threads are supported • Kernel Thread every 0.1 seconds • User threads are not malicious • Dynamic loading of threads

36. LiteOS • Kernel allows dynamic loading of user threads • Maintains a map of system resource allocation • Copies thread info such as entry address and priority in a control block. • Closes file handles and deallocates on unloading.

37. Previous Work • Dynamic loading • TinyOS • XNP : boot load to flash and then jump there • SOS • Loads modules • Contiki • ELF file to patch symbolic links

38. LiteOS Mem Org

39. LiteOS • Multi Threaded • Each thread owns separate memory segments and stack.

40. Software Compatibility:Differential Patching • Vector (S, M, T) • S : Start address of binary • M : Start addres of memory allocation • T : Stack top.

41. Differential Instructions

42. Example

43. Mathematical Model

44. LiteOS Hex Format

45. System Calls • Call Gates • 4 bytes • 256 allowed in 1024 byte space • 52 exist

46. Lite C++ • Static language • Subset of C++ • Base classes • Integrates system calls • File name same as class name

47. Sample program

48. Sample Program

49. Base classes

50. Performance Evaluation