Sample Project Ideas

KD Kang

Project Idea 1: Real-time task scheduling in TinyOS

• EDF in TinyOS 2.x– Description is available at http://www.tinyos.net/tinyos-2.x/doc/html/tep106.html– Prototype implementation is available at

http://csl.stanford.edu/~pal/tinyos/edf-sched.tgz– Is this a good implementation? Can we improve it?

• Can it deal with multiple resources?

– Implement another real-time task scheduling algorithm in TinyOS

– Implement an overload protection mechanism, for example, aggregate two sensor readings and set the new deadline = max(D1, D2)

Project Idea 2: Just-in-time packet scheduling

• ASAP forwarding can actually increase E2E delay and deadline miss ratio

• Exploit slack time to improve real-time performance– K. Liu, N. Abu-Ghazaleh, K. D. Kang,

"JiTS: Just-in-Time Scheduling for Real-Time Sensor Data Dissemination", 4th Annual IEEE International Conference on Pervasive Computing and Communications (PerCom 2006), Pisa, Italy, Mar. 13-17, 2006.

• Extend JiTS

Project Idea 3: Resource Management for Multiple

Queries• Most WSN work assumes a single

query• What if multiple queries are executed

simultaneously?• Which queury should receive more

resources? Why?• Can similar queries can be

combined? How?

Project Idea 4: Virtual Machine for WSNs

• Maté– http://www.cs.berkeley.edu/~pal/research/mate.html

• Extend Mate to support– Real-time task/packet scheduling;– Multiple concurrent queries; or – Overload protection

Project Idea 5: Security• Trust-based routing

– Overhearding-based trust level computation– Does overhearing always work? There are collisions, overloads,

interferences, etc.– “Practical” trust-based routing– More feedback or probing? Introduce new security holes? Terrible

performance?• Secure sensor network reprogramming

– Prabal K. Dutta, Jonathan W. Hui, David C. Chu, and David E. Culler, “Securing the Deluge network programming”, 5th Internaltional Conference on Information Processing in Sensor Networks (IPSN'06), April 25-27, 2006.

– Improve the security or performance of reprogramming• Secure data aggregation

– Y. Sang, H. Shen, Y. Inoguchi, Y. Tan, N. Xiong, “Secure Data Aggregation in Wireless Sensor Networks: A Survey”, Seventh International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT'06)

– Extend to support multiple streams for concurrent queries

Project Idea 6: Sensor Network Applications

• For EngiNet students only• Applications related to your work, e.g., medical, defense, structural

monitoring, habitat monitoring, smart-* applications• Not only wireless sensors, e.g., MICA motes, but any other sensors, e.g.,

medical sensors– Describe the functionalities of important sensors

• Specify application requirements• What’s the expected advantage of networking these sensors together with

computational systems such as medical databases?– Explain how sensor networks can improve your application

• Specify the system architecture and reason why this architecture is desirable for the specific application

• Specify the required network services such as routing, MAC, or security protocols

• Show how the existing sensor network protocols should be changed to support the specific application of yours

– Propose a new protocol– The final outcome is a report

• Take advantage of your domain knowledge

The nesC Language: A Holistic Approach to Networked

Embedded Systems

D. Gay, P. Levis, R. Behren, M. Welsh, E. Brewer, D. Culler

What is nesC?• Extension of C

– C has direct HW control– Many programmers already know C– nesC provides safety check missing in C

• Whole program analsys at compile time– Detect race conditions -> Eliminate potential bugs– Agressive function inlining -> Optimization

• Static language– No dynamic memory allocation– No function pointers– Call graph and variable access are fully known at compile time

• Supports and refelcts TinyOS’s design– Based on the component concept – Directly supports envet-driven concurrency model– Addresses the issue of concurrent access to shared via atomic

section and norace keyword

Key Properties

• All resources are known statically• No general purpose OS, but applications

are built from a set of reusable system components coupled with application-specific code

• HW/SW boundaries may vary depending on the application & HW platform -> Flexible decomposition is required

Challenges

• Event-driven– Driven by interaction with environments

• Limited resoruces• Reliability• Soft real-time requirements

Reminder: TinyOS

• Component-based architecture– An application wires reusable components

together in a customized way

• Tasks and event-driven concurrency– Tasks & events run to completion, but an event

can preempt the execution of a task or an event– Tasks can’t preemt another task or event

• Split-phase operations (for non-blocking operations)– A command will return immediately and an

event signals the completion

Component• A component provides and uses interfaces

– The interfaces are the only point of access to the component• An interface models some service, e.g., sending a msg• The provider of a command implements the commands,

while the user implements the events

Interface

• Bidirectional interfaces support split-phase execution

Component implementation

• Two types of components: modules & configurations

• Modules provide application code and implements one or more interfaces

• Configurations wire components together– Connect interfaces used by components

to interfaces provided by others

Module• Surge: Get a sensor reading and send a

message every second

Configuration

• Wire TimerM and HWClock components together

Example: SurgeC configuration

Abstract component

• Sometimes useful to create several instances of a component

optional parameter used to specify #max retransmissions

Parameterized interfaces

• Used to model Active Messages in TinyOS– In active

messages, a packet contains a numeric identifier to specify which event handler should be executed

Concurrency and Atomicity

• Asynchronous code (AC): reachable from at least one interrupt handler

• Synchronous code (SC): only reachable from tasks– Synchronous code is atomic w.r.t. other synchronous

code

• Still potential races between AC and SC– Any update to shared state from AC– Any update to shared state from SC that is also updated

from AC

• Solution: Race-Free Invariant– Any update to a shared variable is by SC or occurs inside

an atomic section

atomic & norace• Atomic

– Disable interrupts– Atomic statements are not

allowed to call commands or signal events

– If a variable x is accessed by AC, any access of x outside of an atomic section is a compile time error

– An atomic section should be short!

• norace– If a programmer knows a

potential race is not an actual race, declare norace

Disable interrupts

Enable interrupts

Evaluation• Tested for three TinyOS applications

– Surge, Mate, TinyDB• Core TinyOS consists of 172 components

– 108 modules & 64 configurations• Group necessary components, via nesC’s bidirectional

interfaces, for a specific application

Effect of inlining

• Impact of inlining on footprint and performance

Remaining issues

• Static memory allocation– Advantages

• Offline analysis of memory requirements

– No problem?• No dynamic allocation

• Short code only in atomic sections & command/event handlers

• Little language support for real-time programming

Questions?