LiteOS: Unix Like Operating System for WSN

1
LiteOS Unix Like Operating System for WSN

• Presenter Jay
• Author - Qing Cao qcao2_at_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.ht
  ml
• 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 CompatibilityDifferential 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

51
Performance Evaluation
52
Conclusion

• Unix like multi threaded operating system
• Ease of programming
• Exposes Sensor networks to wider audience

53
Critical Review

• Power consumption