Some Project Ideas…

1. Some Project Ideas…

2. 1. Biometric Sensor Board (two-lead EKG system) for Mica • Deescription: Design and fabricate a biometric sensor board and software driver for Mica/SOS platform to measure vital signals of human body, especially EKG. • References • http://www.eecs.harvard.edu/~mdw/papers/ekg-embs04.pdf • http://vadim.www.media.mit.edu/Hoarder/Biometrics.htm • Baseline goal: • Duplicate the MIT design, develop driver, collect data • Needed skill: PCB schematic + routing, C programming • Additional credit: • for students with analog circuit background can focus on circuit improvement • for students with system or networking background can focus on reliable protocol to deliver collected data • for students with signal processing background can focus ondata compression mechanism • Team size: 2 • Mentors • David Jea dcjea@ee.ucla.edu • Jonathan Friedman jf@ee.ucla.edu

3. 2. Flash File System for Mica/SOS • Description: develop a file system for external flash on Mica2 on top of SOS • References: • http://www.cs.colorado.edu/~rhan/Papers/sensys_elf_external.pdf • TinyOS Matchbox • Baseline goal: • Select a suitable existing scheme and port to SOS • Additional credit: • Optimization of the file system for the image of SOS kernel, SOS modules and pure data • Team size: 1 • Mentors • David Jea dcjea@ee.ucla.edu • Simon Han simonhan@ee.ucla.edu

4. 3. Simulation Study of Wide Area Mobile Sensor Networks • Goal: Simulation modeling to study various design options for mobile sensor networks consisting of groups of sensor-equipped people engaged in outdoor activity • Mobility, latency, data rate • Need familiarity with some suitable simulation platform such as QualNet or OMNet++ simulator • Team size: 1 • Mentors • David Jea dcjea@ee.ucla.edu • Mani Srivastava mbs@ucla.edu

5. 4. Hardware Architectural Extensions for Reliable Sensor Node Software • Description: Explore simple extensions to the architecture of the sensor nodes to enable seamless recovery from software faults • Module hogs CPU, watchdog timer reboots • But reboot is costly… how about watchdog interrupt? • Memory corruption of data or program segment • How about ability to retrieve or restore memory contents of a sensor node without executing any code on the node? Remote DMA? • All recovery mechanisms fail • How about a remote reboot? • Baseline goal • Identify suitable architectural extensions • Build a sensor node with architectural extensions • TI MSP430 seems to have minimal support (DMA, NMI) • Okay to prototype using evaluation boards etc. • Develop needed software hooks to demonstrate the idea • Extra credit: build a custom board • PCB experience desirable • Team: 2, or 1who continues this as MS project • Mentor: • Ram Kumar ram@ee.ucla.edu

6. 5. Time Synchronization Middleware for Distributed Embedded Systems • Description: There exist many different types of time sync algorithms. Devise a unified interface that can be used by the applications without caring about the underlying details. • Goal: • port RATS (Rate Adaptive Time Synchronization protocol) and TPSN (Timing-sync Protocol for Sensor Networks) to SOS and integrate them to provide a comprehensive time synchronization middleware service • Skill needed: systems programming in C • Team size: 2 • Mentor: • Saurabh Ganeriwal saurabh@ee.ucla.edu

7. 6. Securing Data in Zigbee-based Systems • Description: Security is essential in many embedded applications. Zigbee/802.15.4 is a networking technology for wireless embedded systems, and uses the so called AES standard. Zigbee products provide support for AES in hardware. Try to use this in- built hardware component to provide data confidentiality and integrity, when it is transmitted on the open wireless communication medium. • Goal: • Develop a software driver in SOS that exploits AES encryption/decryption engine on the CC2420 radio chip, to provide data confidentiality and integrity. • Integrate this with an available key establishment and management protocol to develop a comprehensive security mechanism for Zigbee-based distributed embedded systems • Skill: systems programming in C • Team size: 2 • Mentor: • Saurabh Ganeriwal saurabh@ee.ucla.edu

8. 7. Remote Code Attestation • Description: Low-end embedded systems are hard to make tamper-proof and thus an adversary can modify the memory contents. There exist recently proposed software-based approaches but remain susceptible to attacks where adversary colludes with external devices to compromise the attestation process. Explore minimal hardware support for deterministic code attestation. • Goal: • The problem with existing approaches is the fact that the attacker has the control over the system, even when the verification procedure is being carried out. In our approach, we try to create a secure and non-interruptible path from the verifier to the client. This is feasible by the NMI handler support that is already available in the current sensor networking platforms such as Telos etc. In this project, we will be creating a prototype implementation of this approach. • Skill: programming, architecture • Team size: 2 • References • http://www.ee.ucla.edu/~saurabh/upload/Code_Attestation.ppt • A. Perrig, A, Seshadri, L. V. Doorn, P. Khosla, ﾒSWATT: SoftWare-based ATTestation for Embedded Devicesﾓ, 2004 IEEE Symposium on Security and Privacy • Mentor: • Saurabh Ganeriwal saurabh@ee.ucla.edu

9. 8. Comparison of Kernel and Application Level Threads • Description: Threads provide a nice abstraction to programmers relative to event model. This project seeks to examine two techniques for threads on top of SOS: application level threading (e.g. Contiki OS’s protothreads) and kernel-based threads. • Goal: Compare application-level protothreads vs. kernel-level dynamic non-preemptive threads by implementing and benchmarking them. • Team size: 1 • Skill: prior OS course, programming • Mentors: • Simon Han simonhan@ee.ucla.edu • Roy Shea roy@cs.ucla.edu

10. 9. Static Verification of Dynamic Intra and Inter-Module Interfaces • Description: Extend a set of static checkers that can be used by embedded software developers to help catch common bugs that are difficult to locate at runtime. E.g. SOS has dynamic modules and uses "function pointer pointer" (fpp) toimplement a flexible dynamic linking mechanism with minimal overhead. These fpps require users to specify prototype information in a format that is not very user friendly. A mistake in this prototyping will not cause a compile time error, but will cause failure of an SOS module at run time. • Goal: • This project will aim to develop a tool that eases this process for developers, while exposing the type of tools that can be used to accomplish this task. Use CIL (based on Ocaml, which you will need to learn) to develop a static checker for this. • Team size: 1 • Mentor: • Roy Shea roy@cs.ucla.edu

11. [TAKEN] 10. Dynamic Reconfiguration of Cyclops Image Processing using SOS • Description: Cyclops is an image sensor board for Mica2/MicaZ motes, with an on-board CMOS imager, framebuffer, and AVR microcontroller. It currently is based on TinyOS with a fixed set of software modules wired together. Project seeks to provide the ability to exploit SOS’s dynamic modules to provide the ability to remotely configure image processing functionality. • Goal • Modify SOS’s I/O system so that it can work “radio-less” using I2C as the alternative (I2C driver already exists) • Modify SOS’s module distribution protocol to work with Mica motes with attached Cylcops • Port existing Cyclops modules from TinyOS to SOS • Demonstrate capability to dynamically load and wire image processing blocks • Team Size: 2 • Mentor: • For SOS: Ram Kumar ram@ee.ucla.edu • For Cyclops: Mohammad Rahimi mhr@cens.ucla.edu

12. 11. Stargate2 as USB Client • Description: Stargate is a 32b embedded platform from Intel, used in a variety of application. Currently one connects to it from a host via a network link (ethernet, WiFi). Goal is to make it appear to a host as a USB client, perhaps by just mounting it as a USB storage or serial or network device, to enormously simplify working with it. • Goal • Study USB, figure out the right abstract, and then implement it on Stargate. The neatest seem to be the ability to mount Stargate like a disk. Do this with the newer Stargate2 devices (Slauson) • Team Size: 1 • Skill: Linux programming • Mentor: • Mani Srivastava mbs@ee.ucla.edu • Trevor Pering (Intel)

13. 12. Exploit Stargate2 SRAM for Super Low-power Sleep State • Description: Stargate2 has some SRAM on the board itself. The idea is that this could be used to put the device into a super low-power state (no DRAM refresh). • Goal: Get the SRAM working, and then figure out how to use it for super low-power sleep state. • Team Size: 1 • Skill: Linux kernel and application programming • Mentor: • Mani Srivastava mbs@ee.ucla.edu • Trevor Pering (Intel)

14. 13. Maintaining time across reboots on Stargate2 • Description: Duty cycling is essential for low power, but unfortunately on Stargate the time is not preserved across reboot. However, Stargate2 has a real-time clock (RTC) with an ultracapacitor to keep RTC running while power is off for some time. • Goal: Get the RTC timer working so that the device can maintain a consistent clock across reboots, and use it to implement a duty-cycling mechanism. • Team Size: 1 • Skill: Linux kernel and application programming • Mentor: • Mani Srivastava mbs@ee.ucla.edu • Trevor Pering (Intel)

15. 14. Sensor-less Traffic-condition-based Car Navigation • Description: We are seeing the emergence of navigation units in cars that make use of information from traffic sensors on roads to decide optimal route to destination (e.g. Acura RL). The information is obtained wirelessly from web services such as www.traffic.com. The problem is that such traffic sensors are not ubiquitous - they are available only on major freeways in major cities. The idea in this project is to use emerging vehicular ad hoc networks (802.11p) and disseminate traffic speed information from car-to-car (after all, a car is the best speed sensor - it knows its location, speed, and heading) • Goal: • Realize the above concept • A simple 1-person project might be a simulation study using traffic data • A more ambitious 2 or 3 person project might seek to implement this using Stargate, GPS, and 802.11 radios • Issues to consider: How to aggregate information from nearby car? • Team Size: 1-3 depending on exact project • Mentor • Mani Srivastava mbs@ucla.edu

16. 15. Dynamic Modules for Processors without PIC Support • Description: Embedded OS such as SOS seek to provide dynamically loadable binary modules. Usually this is done with module written in position-independent code (PIC), and the module loader simply allocating memory for it. Unfortunately processors such as MSP430 don’t have ISA support for PIC. Goal of this project is to provide SOS dynamic module support on processors without support for PIC. E.g. on MSP430: • PC relative jumps are restricted to the address range -1024 to +1022. • No relative branches - Branches can be done by a move to the PC only • No relative call instruction - There is a cryptic way to do relative • See http://mspgcc.sourceforge.net/manual/x223.html • Goal • Extend SOS module format to include metadata relating to module program and data relocation • Write a module relocator for MSP430 (Telos) • Similar support in Contiki can be starting point • Team Size: 1 • Mentor: • Ram Kumar ram@ee.ucla.edu • Simon Han simonhan@ee.ucla.edu

17. 16. Ultra-low duty cycle using Low-power Listen and Rate-adaptive Time Sync in SOS • Description: Recent work at UCLA (paper at SenSys 2005) has resulted in a framework called U-BMAC for ultra-low duty cyle based on two concepts: Low-power Listen (from Berkeley) and Rate Adaptive Time Sync (from UCLA). The goal of this project is to implement this is SOS. • Goal: Implement LPL + RATS in SOS, by porting the code from TinyOS implementation • Overlap with project 5 • Team Size: 1 • Mentor: • Saurabh Ganeriwal saurabh@ee.ucla.edu

18. 17. Inferno OS on Stargates or XYZ • Description: Inferno is an interesting embedded OS out of Bell Labs (EmStar has shades of Inferno but arguably in a far less clean fashion) • Everything is a device • Devices can be accessed and shared across network • Virtual machine • Goals • Port it to Stargate+mote and/or XYZ • Easy as port to processors already exist • Will need to create board-specific modules • Create radio protocol stack to network (borrow stuff from TinyOS/SOS/EmStar) • Show some simple applications • Team Size: 1-2 • Mentor: • Mani Srivastava mbs@ucla.edu

19. 18. Sensor Board Model for Avrora Mote Simulator • Description: Avrora is a detailed clock-cycle accurate simulator for Mica 2. Avrora gives pretty good energy consumption values for CPU and radio and LEDs, but sensor board itself, and the attached sensors, consume relatively significant energy also. To make good decisions about where to invest in energy conservation exploration, one needs to understand the broader picture. [eg, not much value in squeezing the last joule out of the link estimator code if a thousand joules is consumed by the humidity sensor] • Goal: • Enhance the existing Avrora model of the MDA300 sensor board to include a finer-grained measurement of energy consumption in the board sub-systems, especially the analog and digital channel systems. Further enhance the model to model the energy used by individual channels for specific sensor excitation. Compare/contrast model-based results with direct measurement of operating mote, sensor board, and sensor. • Team Size: 1 • Mentors: • Mohammad Rahimi mhr@cens.ucla.edu • Richard Guy rguy@cs.ucla.edu

20. 19. Magnetic Sensor Data Integrity and Calibration • Description: Magnetic sensors are notoriously susceptible to drift and other problems due to ambient condition and change in magnetic flux. Consequently, they need periodic recalibration (a reset pulse). Study the nature of this calibration problem, and develop techniques to address them • Goals • Systematically characterize the calibration problem with magnetic sensors (perhaps on Motes) and the variances across sensors and drifts • Develop technique on deciding how and when to relcalibrate. Ideas include making use of other modalities (temperature?) as well as adaptive control of calibration frequency • Develop techniques on making detection resilient to such calibration. A possibility might be for nearby magnetic sensors to exchange information and cancel common mode error • Team Size: 1-2 • Mentor: • Mani Srivastava mbs@ucla.edu • Simon Han simonhan@ee.ucla.edu • David Jea dcjea@ee.ucla.edu

21. 20. Human Interaction with Embedded Wireless Systems • Description: Wireless and networked embedded systems have been proposed for use in home automation and several pervasive computing applications. In this project, we design a method for the user to control a large number of embedded nodes in her immediate environment, such as the home, without complex scripting on a console. We will consider data entry and control based on accelerometer inputs rather than keyboards and pointing devices. • Goals: • Mount one or more accelerometer equipped motes on a data glove and then develop a gesture recognition algorithm on a host that gets the data. • Use these gestures to send simple commands to specific motes in a network z(e.g. on/off commands to motes controlling appliances, lights etc.) • Team Size: 1-2 • Mentor: • Aman Kansal kansal@ee.ucla.edu

22. 21. Hierarchical Sensor Resource Allocation • Description: In several applications, it is possible to detect activity using cheap and low power sensors while useful recognition or processing of the activity requires more sophisticated sensing and data processing. A common sensor network design paradigm to optimize the system in such cases is to use a high density of low power nodes which monitor the entire area of interest and a much smaller number of sophisticated nodes, which are allocated to regions of interest based on inputs from the higher density sensors. • Goals: The aim of this project is to use light sensors as high density nodes, and a camera as the limited resource which will be allocated selectively to regions of interest. Design this hierarchical sensing system using the embedded tools available to you. Treat changes in light values at a light sensor (such as due to people passing by) as an activity of interest and the camera mounted on a pan-title unit is required to take a picture of each region where light values show significant changes (such as keeping a picture-blog of everyone who walked through your sensor network). What happens when two motes in different regions request the camera to take a picture simultaneously? Devise and implement an alogorithm for that case. • Team Size: 1-2 • Mentor: • Aman Kansal kansal@ee.ucla.edu

23. 22. Architecture-Independent 802.15.4 Stack • Description: IEEE 802.15.4 is a MAC protocol standard for low-power wireless personal area networks (WPAN). The MAC protocol can be implemented across multiple combinations of radios and micro-controllers. The current implementations are optimized for a particular architecture and hence are not easily portable. • Goal • The goal of this project is to implement an architecture independent MAC protocol. The primitive operations need to be identified and defined as a hardware abstraction layer (HAL) API. The MAC protocol needs to be implemented using the primitives. • Starting points • Current IEEE 802.15.4 MAC implementations for MicaZ and XYZ sensor nodes • Test of architecture-independence • The MAC protocol should work on the Telos sensor nodes • Demo of a heterogeneous network of Telos, MicaZ and XYZ • Team – 2 students • Desirable Skill-set: Prior experience in system programming • Mentors • Ram Kumar ram@ee.ucla.edu • Tad Dreir tjdreir@ucla.edu

24. 23. Tuple-space Middleware Service for Sensor Node Collaboration • Description: Sensor networks OS such as TinyOS, SOS, and Contiki rely on inter-node interaction using messaging. Recent work on so called Macroprogramming systems suggest that a shared memory type approach is more friendly to application programmers. The goal would be to create a data sharing service for SOS based on the Tuple-space paradigm (essentially a network level associative memory), similar to that done by Washington University’s Agilla system (a mobile agent and VM framework on top of TinyOS) • Goal • Study Agilla, Kairos, Hood, Regions, and EIP systems • Devise the architecture for a Tuple-space service for SOS as a module which offers this service to other SOS modules via a suitable API • Implement the service • Skill: systems programming in C • Team Size: 2 • Mentors: • Simon Han simonhan@ee.ucla.edu

25. 24. Modeling of Cyclops Image Sensor in Avrora • Description: Avrora is a detailed clock-cycle accurate simulator for Mica 2. Cyclops is an image sensor board for Mica2/MicaZ motes, with an on-board CMOS imager, framebuffer, and AVR microcontroller. Goal is to extend Avrora so as to model motes with Cyclops sensor board. • Goals • First create an Avrora model for Cyclops board • Then figure out how to connect Mote and Cyclops model within Avrora • Eventual goal is to show a network of Mote+Cyclops nodes • Team Size: 2 • Skills: Java, TinyOS, ability to understand hardware specifications • Mentors • Mohammad Rahimi mhr@cens.ucla.edu

26. 25. Over-the-air programming ofTinyOS-based Cyclops • Description: Cyclops is an image sensor board for Mica2/MicaZ motes, with an on-board CMOS imager, framebuffer, and AVR microcontroller. Currently it runs with TinyOS. The programming pins of Cyclops are controlled by the mote. The goal is to create a system for over-the-air programming of TinyOS flash images on Cyclops in a network setting • Goals • Create mote software to program the flash on an attached Cyclops • Extend TinyOS flash image distribution protocol Deluge, and associated reprogramming framework, so as to reprogram flash image on a Cyclop attached to the mote (as opposed to the flash image of the mote) • Team Size: 1 • Desirable Skill-set: TinyOS programming • Mentors • Mohammad Rahimi mhr@cens.ucla.edu • Simon Han simonhan@ee.ucla.edu

27. 26. & 27. Cyclops + Pan/Tilt • Description: Cyclops is an image sensor board for Mica2/MicaZ motes, with an on-board CMOS imager, framebuffer, and AVR microcontroller. Cyclops philosophy is “lots of low resolution sensors”. Idea is this project would be to explore actuation (pan-tilt) with Cylcops. • Goals • Variant 1 (#26): Prototype a low-power pan-tilt platform for Cylcops and make it controllable by Cyclops/Mote. Since the whole thing is pretty light weight, the design would be quite easy and one could use Lego or some such system for making the platform. Develop algorithm so that multiple actuated Cyclops coordinate to improve coverage of a physical space that has obstructions (self-configuration, coverage hole) • Variant 2 (#27): Here Cyclops remain static but we introduce a higher resolution pan-zoom-tilt camera (a web cam, for example) and have it be triggered and suitably tasked and scheduled by the Cyclops network. • Team Size: 2 • Desirable Skill-set: TinyOS programming for both, Mechantronic aptitude for #26, Linux programming for #27 • Mentors • Mohammad Rahimi mhr@cens.ucla.edu • Aman Kansal kansal@ee.ucla.edu

28. 28. Zigbee Sensor Node for Wearable Applications • Description: Many emerging sensor applications involve human beings or animals wearing the sensor node, perhaps more than one of them. Usually sensing modalities of interest relate to motion and physiological parameter. Unfortunately platforms such as Mica2, MicaZ and Tmote are too large. There are smaller platforms, but they use either crappy radio (Mica2dot) or non-standard radios (UC Irvine’s really tiny Eco). The idea here would be to leverage emerging chips that integrate microcontroller and standard Zigbee radio on a small chip, e.g. Chipcon’s CC2430. • Goal • Design a sensor node around CC2430 with on-board 3D accelerometer, light, and temperature sensor (like in Eco), and a flex connector to connect external physiological sensors • Write the minimal software drivers to show its functionality • Team Size: 2, or 1 if you wish to continue on this as a MS project on sensor nodes for wearable/medical applications • Skill: digital system and PCB design • Mentors • David Jea dcjea@ee.ucla.edu • Ram Kumar ram@ee.ucla.edu

29. 29. Investigation of Impact of Software Faults in Embedded Systems • Description: The goal is to conduct a systematic study of the impact of software faults in embedded software. There is currently no such study in this domain and it would be useful to see how often they occur and how much impact they have. Focus on memory corruption faults: Buffer Overflows (all systems), Memory use upon free (systems with dynamic memory), Memory use upon giving up ownership (for message passing systems), Stack Corruption (all systems) • Goal • Systematically analyze the system-level impact of such memory corruption faults • Corruption in routing data structures could lead to packet loss • Corruption in time synch data structures (esp. RATS as it maintains history in a data-structure) could impact operation of MAC protocol • How long do these faults last ? • Is there a pattern that these faults exhibit that can you be used to devise intelligent fault detection schemes? • The project will involve simulation, analysis and measurements. • Team Size: 1 • Skill: C programming • Mentors: • Ram Kumar ram@ee.ucla.edu