Energy Management in Tiny OS 2 Learning Objectives

Energy Management in Tiny. OS 2

Learning Objectives • Understand the basic ideas of Integrated Concurrency and Energy Management (ICEM) • Understand representive ICEM examples in Tiny. OS 2

Prerequisites • Basic concepts of Operating Systems • Basic concepts of Object-oriented design and analysis

Motivation • If the application must explicitly invoke power control operations, this will introduce application code complexity • Let the OS automatically minimize energy consumption - Integrated Concurrency and Energy Management (ICEM) [Energy_1] 4

ICEM (Integrated Concurrency and Energy Management) • Most WSN OS are completely event-driven • Diverse peripherals • An application simply needs to make a set of asynchronous system calls and let OS schedule the underlying operations • Power locks – When a client acquires a driver’s power lock: ICEM has powered and configured the hardware for the client – When a power lock is idle, ICEM powers down the underlying hardware

Example Implementations in T 2 • Lock Interface is named Resource in T 2 • Arbiter Configure Interface is named Resource. Configure in T 2 • Default. Owner Interface is named Resource. Default. Owner in T 2

Example Applications based on Telos. B • Every five minutes, the application samples four sensors (photo active, total solar, temperature, and humidity) and logs the readings in flash with a sequence number • Every twelve hours, the application retrieves new readings from the flash and sends them to the gateway • Five Operations – Sampe its four sensors – Log the record to flash

Motivation Example – Pseudocode for hand -tuned implementation without ICEM

Telos. B

Five Operations • Humidity and Temperature are digital sensors • Total Solar and Photo Active are analog sensors • The OS can concurrently sample one digital and one analog sensor • The OS must arbitrate sensors of the same kind

ICEM Drivers – Resource Arbitration • Virtualized – – Simplest for a client to use Virtualized drivers buffer client requests Provide implicit concurrency Usually buffer functional requests (e. g. send a packet) • Dedicated – Support a single user • Shared – Provide explicit concurrency – Support multiple users, but users must contend for the driver through a lock – Usually buffer lock requests also see TEP 108 at http: //tinyos. cvs. sourceforge. net/* 11

ICME Drivers - Virtualized • Oval: Client • Example: – Data Link Packet Sender • Round Robin policy – Application-level millisecond timers • Maintain per-client state • Schedule underlying hardware timer

Virtualized Example • ADC (Analog-Digital-Converter) – A shared resource usually multiplexed between several clients – Adc. Read. Client. C. nc, Adc. Read. Now. Client. C. nc and Adc. Read. Stream. Client. C. nc provide virtualized access to the HIL – Adc. Read. Client. C. nc: tos/chips/msp 430/adc 12/Adc. Read. Client. C. nc