Lecture 2: Software Platforms

Anish Arora
CIS788.11J Introduction to Wireless Sensor Networks

Lecture uses slides from tutorials prepared by authors of these platforms

Outline
Discussion includes OS and also prog. methodology
some environments focus more on one than the other

Focus is on node centric platforms (vs. distributed system centric platforms)

composability, energy efficiency, robustness
reconfigurability and pros/cons of interpreted approach

Platforms
TinyOS
EmStar SOS Contiki

(applies to XSMs)
(applies to XSSs)

slides from UCB

slides from UCLA slides from UCLA slides from Upsaala

Virtual machines (Mat)

slides from UCB

References

NesC, Programming Manual, The Emergence of Networking Abstractions and Techniques in TinyOS, TinyOS webpage EmStar: An Environment for Developing Wireless Embedded Systems Software, Sensys04 Paper, EmStar webpage SOS Mobisys paper, SOS webpage Contiki Emnets Paper, Sensys06 Paper, Contiki webpage Mate ASPLOS Paper, Mate webpage, (SUNSPOT)
3

Traditional Systems

Application Application

Well established layers of abstractions Strict boundaries Ample resources Independent applications at endpoints communicate pt-pt through routers

User

System
Network Stack Threads Address Space Transport Network Data Link Physical Layer Drivers

Files

Well attended
Routers

Sensor Network Systems

Highly constrained resources

processing, storage, bandwidth, power, limited hardware

parallelism, relatively simple interconnect

Applications spread over many small nodes

self-organizing collectives highly integrated with changing environment and network diversity in design and usage

Concurrency intensive in bursts

streams of sensor data &

Need a framework for: Resource-constrained concurrency Defining boundaries Appln-specific processing allow abstractions to emerge
5

network traffic

Robust
inaccessible, critical operation

Unclear where the

Choice of Programming Primitives

Traditional approaches
command processing loop (wait request, act, respond) monolithic event processing full thread/socket posix regime

Alternative
provide framework for concurrency and modularity never poll, never block interleaving flows, events
6

TinyOS
Microthreaded OS (lightweight thread support) and efficient network interfaces

Two level scheduling structure

Long running tasks that can be interrupted by hardware

events

Small, tightly integrated design that allows crossover of software components into hardware

Tiny OS Concepts

Scheduler + Graph of Components

power(mode) send_msg (addr, type, data)

model: threads + events

Commands
Event Handlers Frame (storage) Tasks (concurrency)

init

Component:

Messaging Component init Power(mode) TX_packet(buf)

internal thread Internal State

frame per component, shared stack,

no heap

Very lean multithreading

Efficient Layering

TX_packet_done (success)

RX_packet_done (buffer)

Constrained Storage Model

msg_rec(type, data) msg_send_done)

constrained two-level scheduling

Commands

Events

Application = Graph of Components

application

Route map

Router

Sensor Appln

Active Messages

Radio Packet

Serial Packet

Temp

Photo

SW

Example: ad hoc, multi-hop routing of photo sensor readings

3450 B code 226 B data

packet

byte

Radio byte

UART

ADC

HW

bit

RFM

clock

Graph of cooperating state machines on shared stack

TOS Execution Model

commands request action
ack/nack at every boundary call command or post task

application comp

data processing

message-event driven active message event-driven packet-pump

packet Radio Packet

events notify occurrence

HW interrupt at lowest level may signal events call commands

crc event-driven byte-pump

byte

Radio byte

encode/decode event-driven bit-pump

post tasks

tasks provide logical concurrency

preempted by events
10

bit

RFM

Event-Driven Sensor Access Pattern

command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 200); } event result_t Timer.fired() { return call sensor.getData(); } event result_t sensor.dataReady(uint16_t data) { display(data) return SUCCESS; Timer Photo LED SENSE

clock event handler initiates data collection sensor signals data ready event data event handler calls output command

device sleeps or handles other activity while waiting

conservative send/ack at component boundary
11

TinyOS Commands and Events

{ ... status = call CmdName(args) ... } command CmdName(args) { ... return status; }

event EvtName(args) { ... return status; }

{ ... status = signal EvtName(args) ... }

12

TinyOS Execution Contexts

Tasks

events

commands
Interrupts

Hardware

Events generated by interrupts preempt tasks Tasks do not preempt tasks Both essentially process state transitions
13

Handling Concurrency: Async or Sync Code

Async methods call only async methods (interrupts are async) Sync methods/tasks call only sync methods Potential race conditions: any update to shared state from async code any update to shared state from sync code that is also updated from async code Compiler rule: if a variable x is accessed by async code, then any access of x outside of an atomic statement is a compile-time error Race-Free Invariant: any update to shared state is either not a potential race condition (sync code only) or is within an atomic section

14

Tasks
provide concurrency internal to a component
longer running operations

are preempted by events not preempted by tasks

able to perform operations beyond event context

may call commands may signal events
{ ... post TskName(); ... } task void TskName { ... }

15

Typical Application Use of Tasks

event driven data acquisition

schedule task to do computational portion

event result_t sensor.dataReady(uint16_t data) { putdata(data); post processData(); return SUCCESS;

}
task void processData() { int16_t i, sum=0; for (i=0; i maxdata; i++)
128 Hz sampling rate simple FIR filter dynamic software tuning for centering the magnetometer signal (1208 bytes) digital control of analog, not DSP ADC (196 bytes)

sum += (rdata[i] 7);

display(sum shiftdata); }

16

Task Scheduling
Typically simple FIFO scheduler Bound on number of pending tasks When idle, shuts down node except clock

Uses non-blocking task queue data structure

Simple event-driven structure + control over complete application/system graph

instead of complex task priorities and IPC
17

Maintaining Scheduling Agility

Need logical concurrency at many levels of the graph While meeting hard timing constraints
sample the radio in every bit window

Retain event-driven structure throughout application Tasks extend processing outside event window All operations are non-blocking

18

The Complete Application

SenseToRfm

generic comm
AMStandard

IntToRfm

RadioCRCPacket

UARTnoCRCPacket

packet

CRCfilter

noCRCPacket Timer photo

MicaHighSpeedRadioM phototemp RadioTiming

byte

SecDedEncode

ChannelMon

SW HW

SPIByteFIFO

RandomLFSR

UART

ClockC

ADC

bit

SlavePin

19

Programming Syntax

TinyOS 2.0 is written in an extension of C, called nesC Applications are too

just additional components composed with OS components

Provides syntax for TinyOS concurrency and storage model

commands, events, tasks
local frame variable

Compositional support
separation of definition and linkage
robustness through narrow interfaces and reuse interpositioning

Whole system analysis and optimization

20

Component Interface

logically related set of commands and events

StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); }

Clock.nc

interface Clock {
command result_t setRate(char interval, char scale); event result_t fire(); }

21

Component Types
Configuration
links together components to compose new component configurations can be nested complete main application is always a configuration

Module
provides code that implements one or more interfaces and

internal behavior

22

Example of Top Level Configuration

configuration SenseToRfm { // this module does not provide any interface } implementation { components Main, SenseToInt, IntToRfm, ClockC, Photo as Sensor; Main.StdControl -> SenseToInt; Main.StdControl -> IntToRfm; SenseToInt.Clock -> ClockC; SenseToInt.ADC -> Sensor; SenseToInt.ADCControl -> Sensor; SenseToInt.IntOutput -> IntToRfm;

Main
StdControl

SenseToInt
Clock ADC ADCControl IntOutput

ClockC

Photo

IntToRfm

23

Nested Configuration
includes IntMsg; configuration IntToRfm { provides { interface IntOutput; interface StdControl; } } implementation
SubControl StdControl IntOutput

IntToRfmM
SendMsg[AM_INTMSG];

GenericComm

{
components IntToRfmM, GenericComm as Comm; IntOutput = IntToRfmM; StdControl = IntToRfmM;

IntToRfmM.Send -> Comm.SendMsg[AM_INTMSG];

IntToRfmM.SubControl -> Comm; }

24

IntToRfm Module
includes IntMsg; module IntToRfmM { uses { interface StdControl as SubControl; interface SendMsg as Send; } provides { interface IntOutput; interface StdControl; } } implementation { bool pending; struct TOS_Msg data; command result_t StdControl.init() { pending = FALSE; return call SubControl.init(); }

command result_t StdControl.start()

{ return call SubControl.start(); } command result_t StdControl.stop() { return call SubControl.stop(); }

command result_t IntOutput.output(uint16_t value) { ... if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg), &data) return SUCCESS; ... }

event result_t Send.sendDone(TOS_MsgPtr msg, result_t success) {

...
} }

25

Atomicity Support in nesC

Split phase operations require care to deal with pending operations Race conditions may occur when shared state is accessed by premptible executions, e.g. when an event accesses a shared state, or when a task updates state (premptible by an event which then uses that state) nesC supports atomic block
implemented by turning of interrupts for efficiency, no calls are allowed in block access to shared variable outside atomic block is not allowed
26

Supporting HW Evolution

Distribution broken into

apps: tos: lib: system: platform:
o

top-level applications
shared application components hardware independent system components hardware dependent system components

interfaces tools: contrib beta

includes HPLs and hardware.h

development support tools

Component design so HW and SW look the same

example: temp component

may abstract particular channel of ADC on the microcontroller may be a SW I2C protocol to a sensor board with digital sensor or ADC

HW/SW boundary can move up and down with minimal changes27

Example: Radio Byte Operation

Pipelines transmission: transmits byte while encoding next byte Trades 1 byte of buffering for easy deadline

Encoding task must complete before byte transmission completes

Decode must complete before next byte arrives

Separates high level latencies from low level real-time rqmts

Encode Task

Byte 1

Byte 2

Byte 3

Byte 4

Bit transmission
RFM Bits

start

Byte 1

Byte 2

Byte 3

28

Dynamics of Events and Threads

bit event => end of byte => end of packet => end of msg send

thread posted to start

send next message

bit event filtered at byte layer

radio takes clock events to detect recv 29

Sending a Message
bool pending; struct TOS_Msg data; command result_t IntOutput.output(uint16_t value) { IntMsg *message = (IntMsg *)data.data; if (!pending) { pending = TRUE; message->val = value; message->src = TOS_LOCAL_ADDRESS; if (call Send.send(TOS_BCAST_ADDR, sizeof(IntMsg), &data)) return SUCCESS; pending = FALSE; } return FAIL; } destination

length

Refuses to accept command if buffer is still full or network refuses to

accept send command

User component provide structured msg storage

30

Send done Event

event result_t IntOutput.sendDone(TOS_MsgPtr msg, result_t success) { if (pending && msg == &data) { pending = FALSE; signal IntOutput.outputComplete(success); } return SUCCESS; }

Send done event fans out to all potential senders Originator determined by match
free buffer on success, retry or fail on failure

Others use the event to schedule pending communication

31

Receive Event

event TOS_MsgPtr ReceiveIntMsg.receive(TOS_MsgPtr m) {

IntMsg *message = (IntMsg *)m->data;

call IntOutput.output(message->val); return m; }

Active message automatically dispatched to associated handler

knows format, no run-time parsing performs action on message event

Must return free buffer to the system

typically the incoming buffer if processing complete
32

Tiny Active Messages

Sending
declare buffer storage in a frame request transmission name a handler handle completion signal

Receiving
declare a handler
firing a handler: automatic

Buffer management
strict ownership exchange
tx: send done event

reuse
33

rx: must return a buffer

Tasks in Low-level Operation

transmit packet
send command schedules task to calculate CRC task initiates byte-level data pump events keep the pump flowing

receive packet
receive event schedules task to check CRC task signals packet ready if OK

byte-level tx/rx
task scheduled to encode/decode each complete byte must take less time that byte data transfer
34

TinyOS tools

TOSSIM: a simulator for tinyos programs

ListenRaw, SerialForwarder: java tools to receive raw packets on PC from base node
Oscilloscope: java tool to visualize (sensor) data in real time

Memory usage: breaks down memory usage per component (in contrib)
Peacekeeper: detect RAM corruption due to stack overflows (in lib) Stopwatch: tool to measure execution time of code block by timestamping at entry and exit (in osu CVS server) Makedoc and graphviz: generate and visualize component hierarchy

Surge, Deluge, SNMS, TinyDB

35

Scalable Simulation Environment

target platform: TOSSIM

whole application compiled for host native instruction set event-driven execution mapped into event-driven simulator

machinery storage model mapped to thousands of virtual nodes

radio model and environmental model plugged in

bit-level fidelity

Sockets = basestation Complete application

including GUI
36

Simulation Scaling

37

TinyOS 2.0: basic changes

Scheduler: improve robustness and flexibility

Reserved tasks by default ( fault tolerance) Priority tasks

New nesC 1.2 features:

Network types enable link level cross-platform interoperability Generic (instantiable) components, attributes, etc.

Platform definition: simplify porting

Structure OS to leverage code reuse Decompose h/w devices into 3 layers: presentation, abstraction, device-independent Structure common chips for reuse across platforms so platforms are a collection of chips: msp430 + CC2420 +

Power mgmt architecture for devices controlled by resource reservation Self-initialisation App-level notion of instantiable services
38

TinyOS Limitations

Static allocation allows for compile-time analysis, but can make programming harder No support for heterogeneity

Support for other platforms (e.g. stargate) Support for high data rate apps (e.g. acoustic beamforming) Interoperability with other software frameworks and languages

Limited visibility

Debugging Intra-node fault tolerance

Robustness solved in the details of implementation

nesC offers only some types of checking

44

Em*

Software environment for sensor networks built from Linux-class devices Claimed features:
Simulation and emulation tools

Modular, but not strictly layered architecture

Robust, autonomous, remote operation Fault tolerance within node and between nodes Reactivity to dynamics in environment and task High visibility into system: interactive access to all services

45

Contrasting Emstar and TinyOS

Similar design choices programming framework Component-based design Wiring together modules into an application

event-driven reactive to sudden sensor events or triggers

robustness Nodes/system components can fail hardware platform-dependent constraints Emstar: Develop without optimization TinyOS: Develop under severe resource-constraints

Differences

operating system and language choices Emstar: easy to use C language, tightly coupled to linux (devfs,redhat,) TinyOS: an extended C-compiler (nesC), not wedded to any OS

46

Em* Transparently Trades-off Scale vs. Reality

Em* code runs transparently at many degrees of reality: high visibility debugging before low-visibility deployment

Pure Simulation

Deployment
Data Replay Ceiling Array Portable Array Reality
47

Scale

Em* Modularity
Dependency DAG Each module (service)
Manages a resource &

Collaborative Sensor Processing Application

resolves contention
Has a well defined interface Has a well scoped task Encapsulates mechanism Exposes control of policy
Neighbor Discovery Leader Election Topology Discovery

State Sync

3d MultiLateration

Acoustic Ranging

Reliable Unicast

Time Sync

Minimizes work done by client

library

Hardware

Radio

Audio

Sensors

Application has same structure as services

48

Em* Robustness
Fault isolation via multiple processes Active process management (EmRun) Auto-reconnect built into libraries
Crashproofing prevents cascading failure
scheduling

Soft state design style

Avoid diff protocols

depth map EmRun

path_plan

Services periodically refresh clients

camera motor_x motor_y

49

Em* Reactivity

Event-driven software structure

React to asynchronous notification e.g. reaction to change in neighbor list
scheduling

Notification through the layers

Events percolate up Domain-specific filtering at every level

path_plan

notify filter
motor_y

e.g.

neighbor list membership hysteresis time synchronization linear fit and outlier rejection
50

EmStar Components
Tools
EmRun
EmProxy/EmView EmTOS

Standard IPC
FUSD Device patterns

Common Services
NeighborDiscovery TimeSync

Routing

51

EmRun: Manages Services

Designed to start, stop, and monitor services EmRun config file specifies service dependencies Starting and stopping the system
Starts up services in correct order
Can detect and restart unresponsive services Respawns services that die Notifies services before shutdown, enabling graceful

shutdown and persistent state

Error/Debug Logging
Per-process logging to in-memory ring buffers

Configurable log levels, at run time

52

EmSim/EmCee

Em* supports a variety of types of simulation and emulation, from simulated radio channel and sensors to emulated radio and sensor channels (ceiling array) In all cases, the code is identical Multiple emulated nodes run in their own spaces, on the same physical machine

53

EmView/EmProxy: Visualization

Emulator
emproxy neighbor linkstat motenic

emview

nodeN nodeN nodeN

Mote

Mote

Mote
54

Inter-module IPC : FUSD

Creates device file interfaces

Client Server

Text/Binary on same file

Standard interface
Language independent
No client library required

User
/dev/servicename /dev/fusd

Kernel
kfusd.o

55

Device Patterns

FUSD can support virtually any semantics

What happens when client calls read()?

But many interfaces fall into certain patterns Device Patterns

encapsulate specific semantics take the form of a library:

objects, with method calls and callback functions priority: ease of use

56

Status Device

Designed to report current state

no queuing: clients not guaranteed to see

every intermediate state

Supports multiple clients Interactive and programmatic interface

ASCII output via cat binary output to programs

Server
Config Handler State Request Handler

Supports client notification

notification via select()

O
Status Device

Client configurable
client can write command string server parses it to enable per-client

Client1

Client2

Client3
57

behavior

Packet Device

Designed for message streams Supports multiple clients Supports queuing

Round-robin service of output

Server
Packet Device

queues Delivery of messages to all/ specific clients

F O I O

F I O

Client-configurable:
Input and output queue lengths Input filters Optional loopback of outputs to

Client1

Client2

Client3
58

other clients (for snooping)

Device Files vs Regular Files

Regular files:

Require locking semantics to prevent race conditions between readers and writers
Support status semantics but not queuing No support for notification, polling only

Device files:

Leverage kernel for serialization: no locking needed Arbitrary control of semantics:

queuing, text/binary, per client configuration

Immediate action, like an function call:

system call on device triggers immediate response from service, rather than
setting a request and waiting for service to poll

59

Interacting With em*

Text/Binary on same device file

Text mode enables interaction from shell and scripts

Binary mode enables easy programmatic access to data as C structures, etc.

EmStar device patterns support multiple concurrent clients

IPC channels used internally can be viewed concurrently for debugging Live state can be viewed in the shell (echocat w) or using emview
60

SOS: Motivation and Key Feature

Post-deployment software updates are necessary to

customize the system to the environment

upgrade features
remove bugs re-task system

Remote reprogramming is desirable

Approach: Remotely insert binary modules into running kernel

software reconfiguration without interrupting system operation

no stop and re-boot unlike differential patching

Performance should be superior to virtual machines

61

Architecture Overview
Dynamically Loadable Modules

Tree Routing

Application

Light Sensor

Dynamic Memory
Timer Clock Serial Framer UART

Scheduler
Comm. Stack ADC

Function Pointer Control Blocks Sensor Manager I2C

Kernel Services Low-level Device Drivers Hardware Abstraction Layer

SPI

Static Kernel

Dynamic Modules

Provides hardware abstraction & common services Maintains data structures to enable module loading Costly to modify after deployment

Drivers, protocols, and applications Inexpensive to modify after deployment Position independent
62

SOS Kernel

Hardware Abstraction Layer (HAL)

Clock, UART, ADC, SPI, etc.

Low layer device drivers interface with HAL

Timer, serial framer, communications stack, etc.

Kernel services

Dynamic memory management Scheduling Function control blocks

63

Kernel Services: Memory Management

Fixed-partition dynamic memory allocation

Constant allocation time Low overhead

Memory management features

Guard bytes for run-time memory overflow checks Ownership tracking Garbage collection on completion

pkt = (uint8_t*)ker_malloc(hdr_size + sizeof(SurgeMsg), SURGE_MOD_PID);

64

Kernel Services: Scheduling

SOS implements non-preemptive priority scheduling via priority queues Event served when there is no higher priority event

Low priority queue for scheduling most events

High priority queue for time critical events, e.g., h/w interrupts &
sensitive timers

Prevents execution in interrupt contexts

post_long(TREE_ROUTING_PID, SURGE_MOD_PID, MSG_SEND_PACKET, hdr_size + sizeof(SurgeMsg), (void*)packet, SOS_MSG_DYM_MANAGED);

65

Modules
Each module is uniquely identified by its ID or pid

Has private state

Represented by a message handler & has prototype:

int8_t handler(void *private_state, Message *msg)

Return value follows errno

SOS_OK for success. -EINVAL, -ENOMEM, etc. for failure

66

Kernel Services: Module Linking

Orthogonal to module distribution protocol Kernel stores new module in free block located in program memory and critical information about module in the module table

Kernel calls initialization routine for module

Publish functions for other parts of the system to use

char tmp_string = {'C', 'v', 'v', 0}; ker_register_fn(TREE_ROUTING_PID, MOD_GET_HDR_SIZE, tmp_string, (fn_ptr_t)tr_get_header_size);

Subscribe to functions supplied by other modules

char tmp_string = {'C', 'v', 'v', 0}; s->get_hdr_size = (func_u8_t*)ker_get_handle(TREE_ROUTING_PID, MOD_GET_HDR_SIZE, tmp_string);

Set initial timers and schedule events

67

ModuletoKernel Communication
Module A

System Call

System Messages High Priority Message Buffer Interrupt

System Jump Table

HW Specific API

SOS Kernel

Hardware

Kernel provides system services and access to hardware

ker_timer_start(s->pid, 0, TIMER_REPEAT, 500); ker_led(LED_YELLOW_OFF);

Kernel jump table re-directs system calls to handlers

upgrade kernel independent of the module

Interrupts & messages from kernel dispatched by a high priority message buffer

low latency concurrency safe operation

68

Inter-Module Communication
Module A Module B Module A Module B

Indirect Function Call

Post Module Function Pointer Table Message Buffer

Inter-Module Function Calls

Inter-Module Message Passing

Synchronous communication
Kernel stores pointers to functions registered by modules

Asynchronous communication Messages dispatched by a twolevel priority scheduler Suited for services with long latency

Blocking calls with low latency

Type-safe runtime function binding

Type safe binding through publish / subscribe interface

69

Synchronous Communication
Module can register function for low latency blocking call (1) Modules which need such function can subscribe to it by getting function pointer pointer (i.e. **func) (2) When service is needed, module dereferences the function pointer pointer (3)

Module A

Module B

2 Module Function Pointer Table

70

Asynchronous Communication
3
2 Network
Module A

Msg Queue

Module B

Send Queue

Module is active when it is handling the message (2)(4) Message handling runs to completion and can only be interrupted by hardware interrupts

Module can send message to another module (3) or send message to the network (5)

Message can come from both network (1) and local host (3)
71

Module Safety

Problem: Modules can be remotely added, removed, & modified on deployed nodes

Accessing a module

If module doesn't exist, kernel catches messages sent to it & handles dynamically allocated memory If module exists but can't handle the message, then module's default handler gets message & kernel handles dynamically allocated memory

Subscribing to a modules function

Publishing a function includes a type description that is stored in a function control block (FCB) table

Subscription attempts include type checks against corresponding FCB

Type changes/removal of published functions result in subscribers being redirected to system stub handler function specific to that type Updates to functions w/ same type assumed to have same semantics 72

Module Library

Some applications created by combining already written and tested modules SOS kernel facilitates loosely coupled modules

Passing of memory ownership Efficient function and messaging interfaces

Surge Photo Sensor

Surge Application with Debugging

Tree Routing

Memory Debug

73

Module Design
#include <module.h>

typedef struct { uint8_t pid; uint8_t led_on; } app_state;

DECL_MOD_STATE(app_state); DECL_MOD_ID(BLINK_ID); int8_t module(void *state, Message *msg){ app_state *s = (app_state*)state; switch (msg->type){ case MSG_INIT: { s->pid = msg->did; s->led_on = 0; ker_timer_start(s->pid, 0, TIMER_REPEAT, 500); break; } case MSG_FINAL: { ker_timer_stop(s->pid, 0); break; } case MSG_TIMER_TIMEOUT: { if(s->led_on == 1){ ker_led(LED_YELLOW_ON); } else { ker_led(LED_YELLOW_OFF); } s->led_on++; if(s->led_on > 1) s->led_on = 0; break; } default: return -EINVAL; } return SOS_OK;

Uses standard C
Programs created by wiring modules together

74

Sensor Manager
Module A
Periodic Access Signal Data Ready

Module B
Polled Access

Enables sharing of sensor data between multiple modules Presents uniform data access API to diverse sensors

Sensor Manager

getData

dataReady

Underlying device specific drivers register with the sensor manager Device specific sensor drivers control

MagSensor

Calibration Data interpolation

ADC

I2C

Sensor drivers are loadable: enables

post-deployment configuration of sensors hot-swapping of sensors on a running node

75

Application Level Performance

Comparison of application performance in SOS, TinyOS, and MateVM

Surge Tree Formation Latency

Platform
SOS Core Dynamic Memory Pool TinyOS with Deluge Mate VM

Surge Forwarding Delay

RAM

Surge Packet Delivery Ratio

ROM

20464 B 1163 B 1536 B 21132 B 597 B 39746 B 3196 B

Memory footprint for base operating system with the ability to distribute and update node programs.

System TinyOs SOS Mate VM

Active Time Active Time Overhead relative to (in 1 min) (%) TOS (%) 3.31 sec 5.22% NA 3.50 sec 5.84% 5.70% 3.68 sec 6.13% 11.00%

CPU active time for surge application.

76

Reconfiguration Performance
Code Size Write Cost Write System (Bytes) (mJ/page) Energy (mJ) SOS 1316 0.31 1.86 TinyOS 30988 1.34 164.02 Mate VM NA NA NA

Module Name sample_send tree_routing photo_sensor Energy (mJ) Latency (sec)

Code Size (Bytes) 568 2242 372 2312.68 46.6

Energy cost of light sensor driver update

Code Size W rite Cost W rite System (Bytes) (mJ/page) Energy (mJ) SOS 566 0.31 0.93 TinyOS 31006 1.34 164.02 Mate VM 17 0 0

Module size and energy profile for installing surge under SOS

Energy cost of surge application update

Energy trade offs

SOS has slightly higher base operating cost

TinyOS has significantly higher update cost

SOS is more energy efficient when the system is updated

one or more times a week

77

Platform Support

Supported micro controllers

Supported radio stacks

Atmel Atmega128

4 Kb RAM 128 Kb FLASH

Chipcon CC1000

BMAC

Oki ARM

Chipcon CC2420

32 Kb RAM 256 Kb FLASH

IEEE 802.15.4 MAC (NDA required)

78

Simulation Support

Source code level network simulation

Pthread simulates hardware concurrency UDP simulates perfect radio channel Supports user defined topology & heterogeneous software configuration Useful for verifying the functional correctness

Instruction level simulation with Avrora

Instruction cycle accurate simulation Simple perfect radio channel Useful for verifying timing information See http://compilers.cs.ucla.edu/avrora/

EmStar integration under development

79

Contiki

Dynamic loading of programs (vs. static)

Multi-threaded concurrency managed execution (in addition to event driven)

Available on MSP430, AVR, HC12, Z80, 6502, x86, ...

Simulation environment available for BSD/Linux/Windows

81

Key ideas
Dynamic loading of programs

Selective reprogramming
Static/pre-linking (early work: EmNets) Dynamic linking (recent work: SENSYS)

Key difference from SOS:

no assumption of position independence

Concurrency management mechanisms

Events and threads Trade-offs: preemption, size

82

Loadable programs
One-way dependencies

Core resident in memory

Language run-time, communication

If programs know the core

Can be statically linked And call core functions and reference core variables freely

Core

Individual programs can be loaded/unloaded

Need to register their variable and function information with core

83

84

Loadable programs (contd.)

Programs can be loaded from anywhere

Radio (multi-hop, single-hop), EEPROM, etc.

Core

During software development, usually change only one module

85

Core Symbol Table

Registry of names and addresses of

all externally visible variables and functions

of core modules and run-time libraries

Offers API to linker to search registry and to update registry Created when Contiki core binary image is compiled
multiple pass process

86

Linking and relocating a module

1.

Parse payload into code, data, symbol table, and list of relocation entries which
correspond to an instruction or address in code or data that needs to be
updated with a new address consist of
o

o
o

a pointer to a symbol, such as a variable name or a function name or a pointer to a place in the code or data address of the symbol a relocation type which specifies how the data or code should be updated

2.

Allocate memory for code & data is flash ROM and RAM Link and relocate code and data segments
for each relocation entry, search core symbol table and module symbol table if relocation is relative than calculate absolute address

3.

4.

Write code to flash ROM and data to RAM

87

Contiki size (bytes)

Module
Kernel
Program loader Multi-threading library

Code MSP430

Code AVR
1044
678

RAM
10 + e + p 8 8+s 0 0

810
658 582 60 170

Timer library
Memory manager

90
226

Event log replicator

IP TCP/IP stack

1656 4146

1934 5218

200
18 + b

88

Revisiting Multi-threaded Computation

Thread Thread

Threads blocked, waiting for events

Thread

Kernel unblocks threads when event occurs

Thread runs until next blocking statement

Kernel

Each thread requires its

own stack

Larger memory usage

90

Event-driven vs multi-threaded

Event-driven
- No wait() statements - No preemption - State machines + Compact code + Locking less of a problem + Memory efficient

Multi-threaded
+ wait() statements

+ Preemption possible + Sequential code flow - Larger code overhead - Locking problematic - Larger memory requirements

How to combine them?

91

Contiki: event-based kernel with threads

Kernel is event-based

Most programs run directly on top of the kernel

Multi-threading implemented as a library Threads only used if explicitly needed

Long running computations, ...

Preemption possible

Responsive system with running computations

92

Responsiveness

Computation in a thread

93

Threads implemented atop an event-based kernel

Event Thread

Thread

Event Kernel Event

Event

94

Implementing preemptive threads 1

Thread

Event handler Timer IRQ

95

Implementing preemptive threads 2

Event handler

yield()
96

Memory management
Memory allocated when module is loaded

Both ROM and RAM

Fixed block memory allocator

Code relocation made by module loader

Exercises flash ROM evenly

97

Protothreads: light-weight stackless threads

Protothreads: mixture between event-driven and threaded

A third concurrency mechanism

Allows blocked waiting Requires per-thread no stack Each protothread runs inside a single C function 2 bytes of per-protothread state

98

Mate: A Virtual Machine for Sensor Networks

Why VM? Large number (100s to 1000s) of nodes in a coverage area Some nodes will fail during operation Change of function during the mission Related Work PicoJava assumes Java bytecode execution hardware K Virtual Machine requires 160 512 KB of memory XML too complex and not enough RAM Scylla VM for mobile embedded system
99

Mate features

Small Concise

(16KB instruction memory, 1KB RAM) (limited memory & bandwidth)

Resilience (memory protection) Efficient (bandwidth)

Tailorable (user defined instructions)

10

Mate in a Nutshell

Stack architecture Three concurrent execution contexts Execution triggered by predefined events Tiny code capsules; self-propagate into network Built in communication and sensing instructions

10

When is Mate Preferable?

For small number of executions GDI example: Bytecode version is preferable for a program running less than 5 days In energy constrained domains

Use Mate capsule as a general RPC engine

10

Mate Architecture

Stack based architecture Single shared variable

gets/sets
Subroutines Events

Three events:

Receive

Clock

Clock timer Message reception

Send

Message send

gets/sets
Operand Stack Return Stack

Hides asynchrony

Simplifies programming Less prone to bugs

PC

Code

10

Instruction Set

One byte per instruction Three classes: basic, s-type, x-type

basic: arithmetic, halting, LED operation

s-type: messaging system

x-type: pushc, blez

8 instructions reserved for users to define

Instruction polymorphism

e.g. add(data, message, sensing)

10

Code Example(1)

Display Counter to LED

gets pushc 1 add copy sets pushc 7 and putled halt

# # # # # # # # #

Push heap variable on stack Push 1 on stack Pop twice, add, push result Copy top of stack Pop, set heap Push 0x0007 onto stack Take bottom 3 bits of value Pop, set LEDs to bit pattern

10

Code Capsules

One capsule = 24 instructions Fits into single TOS packet Atomic reception Code Capsule
Type and version information

Type: send, receive, timer, subroutine

10

Viral Code

Capsule transmission: forw Forwarding other installed capsule: forwo (use within clock capsule)

Mate checks on version number on reception of a capsule -> if it is newer, install it

Versioning: 32bit counter Disseminates new code over the network

10

Component Breakdown

Mate runs on mica with 7286 bytes code, 603 bytes RAM

10

Network Infection Rate

42 node network in 3 by 14 grid

Radio transmission: 3 hop network

Cell size: 15 to 30 motes

Every mote runs its clock capsule every 20 seconds Self-forwarding clock capsule

10

Bytecodes vs. Native Code

Mate IPS: ~10,000 Overhead: Every instruction executed as separate TOS task

11

Installation Costs

Bytecodes have computational overhead But this can be compensated by using small packets on upload (to some extent)

11

Customizing Mate

Mate is general architecture; user can build customized VM User can select bytecodes and execution events Issues:
Flexibility vs. Efficiency
Customizing increases efficiency w/ cost of changing requirements

Javas solution:
General computational VM + class libraries

Mates approach:
More customizable solution -> let user decide

11

How to

Select a language

-> defines VM bytecodes

Select execution events -> execution context, code image

Select primitives -> beyond language functionality

11

Constructing a Mate VM

This generates a set of files -> which are used to build TOS application and to configure script program

11

Compiling and Running a Program

Send it over the network to a VM

VM-specific binary code

Write programs in the scripter

11

Bombilla Architecture

Once context: perform operations that only need single execution 16 word heap sharing among the context; setvar, getvar Buffer holds up to ten values; bhead, byank, bsorta
11

Bombilla Instruction Set

basic: arithmetic, halt, sensing m-class: access message header v-class: 16 word heap access j-class: two jump instructions x-class: pushc
11

Enhanced Features of Bombilla

Capsule Injector: programming environment Synchronization: 16-word shared heap; locking scheme Provide synchronization model: handler, invocations,

resources, scheduling points, sequences

Resource management: prevent deadlock Random and selective capsule forwarding Error State

11

Discussion

Comparing to traditional VM concept, is Mate platform independent? Can we have it run on heterogeneous hardware? Security issues: How can we trust the received capsule? Is there a way to prevent version number race with adversary?

In viral programming, is there a way to forward messages other than flooding? After a certain number of nodes are infected by new version capsule, can we forward based on need? Bombilla has some sophisticated OS features. What is the size of the program? Does sensor node need all those features?
11

.NET MicroFramework (MF) Architecture

.NET MF is a bootable runtime environment tailored for embedded development MF services include:
Boot Code Code Execution Thread Management Memory Management Hardware I/O

12

.NET MF Hardware Abstraction Layer (HAL)

Provides an interface to access hardware and peripherals
Relevant only for system, not application developers

Does not require operating system

Can run on top of one if available

Interfaces include:
Clock Management Core CPU Communications External Bus Interface Unit (EBIU) Memory Management

Power

12

.NET MF Platform Abstraction Layer (PAL)

Provides hardware independent abstractions
Used by application developers to access system resources
Application calls to PAL managed by Common Language

Runtime (CLR)
In turn calls HAL drivers to access hardware

PAL interfaces include:

Time PAL Memory Management Input/Output Events Debugging Storage
12

Threading Model

User applications may have multiple threads

Represented in the system as Managed Threads serviced by

the CLR
Time sliced context switching with (configurable) 20ms

quantum
Threads may have priorities

CLR has a single thread of execution at the system level

Uses cooperative multitasking
12

Timer Module

MF provides support for accessing timers from C# Enables execution of a user specified method

At periodic intervals or one-time

Callback method can be selected when timer is

constructed

Part of the System.Threading namespace

Callback method executes in a thread pool thread provided

by the system

12

Timer Interface

Callback: user specified method to be executed State: information used by callback method
May be null

Duetime: delay before the timer first fires

Period: time interval between callback invocations

Change method allows user to stop timer
Change period to -1
12

ADC Extension to the HAL

Extended MF HAL to support ADC APIs

High-precision, low latency sampling using hardware clock

Critical for many signal processing applications

Supported API functions include

Initialize: initialize ADC peripheral registers and the clocks UnInitialize: reset ADC peripheral registers and uninitialize clocks ConfigureADC: select ADC parameters (mode, input channels, etc)

StartSampling: starts conversion on selected ADC channel

GetSamplingStatus: whether in progress or complete GetData: returns data stored in ADC data register
12

Radio Extension to the HAL

Extended the MF HAL to support radio APIs Supported API functions include
On: powers on radio, configures registers, SPI bus, initializes clocks Off: powers off radio, resets registers, clocks and SPI bus Configure: sets radio options for 802.15.4 radio BuildFrame: constructs data frame with specified parameters

destination address, data, ack request

SendPacket: sends data frame to specified address ReceivePacket: receives packet from a specified source address

12

MAC Extension to PAL

Built-in, efficient wireless communication protocol

OMAC (Cao, Parker, Arora: ICNP 2006)

Receiver centric MAC protocol Highly efficient for low duty cycle applications
Implemented as a PAL component natively on top of HAL

radio extensions for maximum efficiency

Exposes rich set of wireless communication interfaces

OMACSender OMACReceiver OMACBroadcast

Easy, out-of-the-box Wireless Communication

Complete abstraction of native, platform or protocol specific

code from application developers
12