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 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."JiTS: Just-in- Time Scheduling for Real-Time Sensor Data Dissemination" 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.htmlhttp://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. “Securing the Deluge network programming”, –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)Secure Data Aggregation in Wireless Sensor Networks: A Survey –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?