1 / 26

Sample Project Ideas

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

betrys
Download Presentation

Sample Project Ideas

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related