T2: A Second Generation OS For Introduction Embedded Sensor - - PDF document

t2 a second generation os for
SMART_READER_LITE
LIVE PREVIEW

T2: A Second Generation OS For Introduction Embedded Sensor - - PDF document

Outline T2: A Second Generation OS For Introduction Embedded Sensor Networks TinyOS-2.x Core Comparison to other mote OSs Critique Presented by: Kevin Klues Department of Computer Science and Engineering 2 TinyOS Development


slide-1
SLIDE 1

1 T2: A Second Generation OS For Embedded Sensor Networks

Presented by: Kevin Klues

Department of Computer Science and Engineering

2

Outline

Introduction TinyOS-2.x Core Comparison to other mote OSs Critique

3

TinyOS Development Trends

Platform development

  • Mica family, Telos, eyes, TinyNode, iMote…
  • Commonalities: micaZ and Telos
  • Need system support for introduction of new platforms

Emergence of basic system abstractions

  • Timers, communication, collection routing
  • New work addresses mostly higher layers
  • Need for stable, robust implementations

4

What is T2?

Complete rewrite of the TinyOS operating system

  • Many similar principles, but not necessarily compatible
  • Revisit basic abstractions: remove historical artifacts

Designed to meet three goals:

  • Simplify/improve platform support
  • Support higher level abstractions
  • Improve system robustness and reliability

5

Why Not Adapt TinyOS 1.x?

It has a well established code base, lots of users Why not slowly ease in improvements?

  • Some improvements are not backwards compatible
  • Task model
  • Result: a periodic compatibility battle

Regularly breaking code is contrary to the benefit of an established code base…

  • Didn’t want to disrupt existing work and systems

6

T2 Design Principles

  • Telescoping Abstractions
  • Layered implementation of device drivers
  • Lowest layers allow for fine grained control of device
  • Higher layers more portable
  • Virtualized Services
  • Hide complexity of sharing resources
  • Arbitration of shared devices (exclusive virtualization)
  • Timers (concurrent virtualization)
  • Static Binding and Allocation
  • All memory allocated at compile time
  • All resources/services bound at compile time
slide-2
SLIDE 2

2

7

Major differences from TinyOS-1.x

  • More restrictive concurrency model
  • Task scheduler has changed
  • Allows for custom task scheduler to be inserted
  • Different boot sequence
  • StdControl split into two separate interfaces (Init, StdControl)
  • Boot interface with single event indicating mote has booted
  • New set of interfaces
  • Send/Receive interfaces have changed
  • Interfaces designed around use of virtualized services
  • Requires the use of nesC 1.2
  • Relies heavily on the use of generic components
  • Allows compile time wiring checks (@exactlyonce, etc.)
  • http://csl.stanford.edu/~pal/pubs/tinyos-programming-1-0.pdf

8

Outline

Introduction TinyOS-2.x Core Comparison to other mote OSs Critique

9

Decomposition of Components

Telescoping abstractions (Design Principle 1)

  • Vertical vs. Horizontal decomposition
  • Hardware Abstraction Architecture (HAA)
  • Chip abstractions (MCU, radio, flash, etc.)
  • Chips composed together to build up platform

Chip dependent vs. platform dependent code

10

Hardware Abstraction Architecture

Hardware Interface Layer (HI L)

  • Provides platform independent interface
  • Used to write cross platform applications

Hardware Presentation Layer (HPL)

  • Exposes full capabilities of the hardware
  • Pulls low level C library calls into nesC
  • Never used directly by components other than HAL

Hardware Adaptation Layer (HAL)

  • Uses HPL to provide “useful” chip dependent interface
  • Used to write chip dependent applications

11

Virtualized Services

Implemented at the HIL layer Hides resource sharing from user

  • Instantiate generic components using “new” keyword
  • Indirectly removes errors with using “unique”

configuration BlinkAppC{} implementation { components MainC, BlinkC, LedsC; components new TimerMilliC() as Timer; BlinkC -> MainC.Boot; BlinkC.Timer -> Timer; BlinkC.Leds -> LedsC; }

12

Virtualized Services (con’t)

Implementation of TimerMilliC

generic configuration TimerMilliC() { provides interface Timer<TMilli>; } implementation { components TimerMilliP; Timer = TimerMilliP.TimerMilli[unique(UQ_TIMER_MILLI)]; }

slide-3
SLIDE 3

3

13

Core Components

  • Platform Independent
  • Task Scheduler
  • Resource Arbiters
  • Resource Power Managers
  • Collection and Dissemination routing
  • Deluge/Trickle (over the air code propagation)
  • Platform/Chip Dependent
  • Timers
  • Radio Stacks
  • Serial Stacks
  • ADCs
  • Sensor Drivers
  • Non-volatile storage (Flash)

14

Task Scheduler

Implemented in nesC as a TinyOS component

  • Tinyos-1.x scheduler written in C and not easily changed
  • Allows new schedulers to be created as desired

Reserves a single slot for each individual task

  • Doesn’t allow new posts from same task to be made until

previous one has started running

  • Possible because of static binding

Runs tasks in FIFO order without preemption

15

Task Scheduler (con’t)

  • Provides provisions for performing mcu power management
  • Whenever empty, try and go to sleep
  • Uses mcu-chip specific McuSleepC component

command void Scheduler.taskLoop(){ for (;;){ uint8_t nextTask; atomic{ while((nextTask = popTask()) == NO_TASK){ call McuSleep.sleep(); } } signal TaskBasic.runTask[nextTask](); } }

16

Timer Abstraction

Follows telescoping abstraction principle

  • Bottom layer provides microcontroller specific interfaces

to dedicated hardware timer

  • Upper layers virtualize the use of these timers, providing

a platform independent interface

17

Radio Communication

Packet formats defined by platform

  • Radio chips define own packet header formats
  • Platform maps these into that platforms packet type

Headers added at each level of networking stack Default Data Link abstraction (Active Messages)

18

Radio Communication (con’t)

Virtualized Send Service

  • As far as each user is concerned he is the only sender
  • Calls to send don’t fail just because other users are

trying to send at the same time (they get queued)

  • Guaranteed slot per sender (similar to Task Scheduler)
  • Calls to send guaranteed to succeed as long as two

consecutive calls aren’t made before previous runs

Different from tinyos-1.x model

  • GenericComm component had queue of fixed length
  • When that queue filled, calls to send would fail
  • Had to be careful to try and resend due to failure
  • Same user could put multiple packets in queue
slide-4
SLIDE 4

4

19

Resource Arbitration

  • Coordinates use of shared resources
  • ADC, system buses, timers, peripheral sensors, flash, etc.
  • Performed using dedicated Arbiter components
  • Can implement different policies (Fcfs, Round Robin)
  • Keeps implementation of granting access to a resource separate

from implementation of using it

  • Default Arbiter implementations
  • Have ability to queue incoming requests
  • Guarantee requests will be fulfilled using dedicated slot in queue for

each resource user (similar to default task scheduler, virtualized send service)

  • Exports interfaces useful for other services (i.e. runtime checks of
  • wnership, configuration, power management)

20

Resource Arbitration (con’t)

generic module ArbiterP(uint8_t controller_id) { provides { interface Resource[uint8_t id]; interface ResourceRequested[uint8_t id]; interface ResourceController; interface ArbiterInfo; } uses { interface ResourceConfigure[uint8_t id]; interface ResourceQueue as Queue; } }

interface Resource { async command error_t request(); async command error_t immediateRequest(); event void granted(); async command error_t release(); async command bool isOwner(); } interface ResourceController { async event void granted(); async command error_t release(); async command bool isOwner(); async event void requested(); async event void immediateRequested(); } interface ResourceRequested { async event void requested(); async event void immediateRequested(); } interface ArbiterInfo { async command bool inUse(); async command uint8_t userId(); } interface ResourceConfigure { async command void configure(); async command void unconfigure(); } interface ResourceQueue { async command bool isEmpty(); async command bool isEnqueued(uint8_t id); async command uint8_t dequeue(); async command error_t enqueue(uint8_t id); }

21

Resource Power Management

Power management of Peripheral devices

  • Used by shared resources in conjunction with an arbiter
  • Used to control power state of peripheral devices
  • Use ResourceController interface provided by an arbiter to

take control of a resource when no one is using it and power it down

  • Powers a resource back up when a user requests it
  • Deferred vs. Non-deferred powerdown

22

Resource Power Management (con’t)

configuration MyResourceC{ provides { interface Resource[uint8_t]; interface DoStuff[uint8_t]; } } implementation { components MyResourceP, new FcfsArbiterC(unique(“MyResource”)) as Arbiter, new StdControlDeferredPowerManagerC(750) as PowerManager; Resource = Arbiter; MyResourceP.DoStuff -> DoStuff; PowerManager.StdControl -> MyResourceP.StdControl; PowerManager.ResourceController -> Arbiter.ResourceController; PowerManager.ArbiterInfo -> Arbiter.ArbiterInfo; } Used to Perform Arbitration Used to perform operations provided the resource Implements DoStuff interface for performing operations on the resource Default arbiter implementation using Fcfs queuing policy Power Manager implementation Deferring powerdown by 750 milliseconds Resource interface of MyResource exported directly from arbiter Implementation of operations to be performed on MyResource done in private module Power Control interface of MyResource provided to PowerManager Interface provided to PowerManager so it will become

  • wner of resource whenever

it goes idle Interface provided to PowerManager so it can verify resource is actually idle before shutting it off

23

Resource Virtualization

Hides use of Resource interface from the user

  • Allows a user to simply call commands provided by a

resource resource, rather than explicitly requesting and releasing its use

  • Implementation of each command performs the request,

waits for granted to come back, then actually makes the call

  • When call completes, the resource is released, and an event

is sent back to the user

  • Example: ADC.read() -> ADC.readDone()

Only practical when precise timing not necessary

24

Outline

Introduction TinyOS-2.x Core Comparison to other mote OSs Critique

slide-5
SLIDE 5

5

25

Design Differences

  • Sensor OS (SOS)
  • Support for loading/unloading programs after deployment
  • Dynamic memory allocation
  • Mantis OS (MOS)
  • Multi-threaded
  • Dynamic memory allocation
  • Contiki
  • Preemptive multithreading
  • Support for loading/unloading programs after deployment
  • Dynamic memory allocation
  • Native TCP/IP support

26

Discussion of differences

Dynamic memory allocation

  • Can be problematic and often not necessary
  • Static allocation still requires dynamic management

Multi-Threading

  • Can cause concurrency issues
  • Blocked threads hold up memory
  • When preemption is important, TinyOS-2.x can be adapted to

include different task scheduler

Native TCP/IP support

  • This feature is very nice, but requires a lot of resources
  • Not essential for all sensornet deployments

27

Outline

Introduction TinyOS-2.x Core Comparison to other mote OSs Critique

28

Critique

While ideas behind abstractions are good, implementations don’t always follow design No high level radio abstractions exist

  • Writing platform independent power management protocols

for the radio is difficult

Work is in progress to correct these problems, and a full release is planned for November of this year

29

Where to learn more…

  • Overview
  • Install Instructions
  • Upgrade Instructions
  • Tutorials
  • TinyOS Enhancement Proposals
  • Source Code Documentation
  • Java Toolchain Source Code Documentation
  • http://www.tinyos.net/tinyos-2.x/doc/
  • TinyOS Programming Manual
  • http://csl.stanford.edu/~pal/pubs/tinyos-programming-1-0.pdf

30

Questions?

Philip Levis, David Gay, Vlado Handziski, Jan Hauer, Ben Greenstein, Jonathan Hui, Kevin Klues, Joe Polastre, Cory Sharp, Robert Szewczyk, Gilman Tolle, Lama Nachman, Martin Turon, David Culler, Adam Wolisz, and a few more...

2 2 . .0