Sample Project Ideas

1. Sample Project Ideas KD Kang

2. 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)

3. 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

4. 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?

5. 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

6. 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

7. 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

8. The nesC Language: A Holistic Approach to Networked Embedded Systems D. Gay, P. Levis, R. Behren, M. Welsh, E. Brewer, D. Culler

9. 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

10. 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

11. Challenges • Event-driven • Driven by interaction with environments • Limited resoruces • Reliability • Soft real-time requirements

12. 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

13. 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

14. Interface • Bidirectional interfaces support split-phase execution

15. 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

16. Module • Surge: Get a sensor reading and send a message every second

17. Configuration • Wire TimerM and HWClock components together

18. Example: SurgeC configuration

19. Abstract component • Sometimes useful to create several instances of a component optional parameter used to specify #max retransmissions

20. 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

21. 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

22. 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

23. 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

24. Effect of inlining • Impact of inlining on footprint and performance

25. 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

26. Questions?