EECS582 - W15 - Project Ideas Prabal Dutta 9-Mar-2015 ====================================================================== Project Proposal [Due: 13-Mar-2015] After deciding on your project (see some ideas below), must write a one page proposal that addresses the following questions: 1. What is the problem you are solving? 2. Why is this problem important and difficult? 3. How you propose to solve it and why your approach is new? 4. What is the related work? 5. Research plan with milestones and dates. 6. Any resources that you will need. ====================================================================== Project Report You must write a project report, not to exceed 10 pages, using LaTeX, and no smaller than 11 pt font. We will provide a template and repository for both project code and report. ====================================================================== Some Project Ideas: 1. An Operating System Kernel Interface for the Internet of Things. Study the interfaces supported by UNIX's syscalls, TinyOS, SOS, Contiki, RIoT, FreeRTOS, Nano-RK, mbed OS, and other embedded operating systems to identify the key OS services needed and design a suitable interface for offering these services. Implement a skeleton version of the interface and write sample programs against it. 2. CoAP Reverse Gateway. The Constrained Application Protocol (CoAP) is a protocol that offers similar abstractions as HTTP but with a much more compact encoding. The idea is that a resource-constrained embedded IP device might not run a full HTTP server but might instead run a CoAP server. A CoAP gateway, running nearby on a more capable device, compresses HTTP requests into CoAP requests, and CoAP responses into HTTP responses. This approach is fine as long as we imagine the IoT device as the server, but imagine if the IoT device were viewed as the client that wanted to make a CoAP request out to a real server on the Internet? We would need a reverse CoAP gateway for that--one that takes a CoAP request and turns it into an HTTP request, and takes an HTTP response and turns it into a CoAP response. The goal of this project would be to design, implement, and evaluate such a thing, and perhaps write an IETF RFC around it. 3. Running BLE Services/Profiles over CoAP. Design an adaptation framework that maps BLE Services and Profiles so that they map to CoAP. Identify protocol elements that map directly and ones that do not map directly, and for the latter, identify mechanisms that would support the equivalent functionality. Implement an automatic translation system that takes a BLE profile and converts it into a CoAP-compliant service. 4. Intermittently-Powered Operating System Scheduler. Many future embedded systems will experience power intermittency. Design a power-aware scheduler for the ATUM device that detects when power is about to be lost and saves the system context to FRAM, restoring it upon sufficient energy harvested, and continuing operation without rebooting. 5. Secure Code Update for Embedded IoT Devices. Port and benchmark standard cryptographic primitives on embedded processors like the CC2538 (ATUM) or nRF51822 (Squall) to determine their time and energy footprints. Determine how much performance improvement is possible using crypto accelerators through a literature search. Use these benchmarks to guide the design and implementation of a secure code update facility for Cortex-Mx class devices that include an MPU for storing crypto keys. 6. Security Model for IoT Devices at Home. Wireless is a broadcast medium so it is difficult to protect against an adversary mounting certain classes of attacks, like jamming. Ignoring such attacks, and focusing on a different standard for security, design and implement a system in which: (i) all IoT devices must be authenticated, (ii) all communications between nodes must be authorized, (iii) any unauthorized communications must be discarded; (iv) all communications must be confidential, (v) the integrity of all communications must be ensured, and (vi) it must not be possible to repudiate any communication that results in an externalized action. Specifically, explore: (i) the extent to which such a security paradigm is viable using current embedded computing resources (e.g. by benchmarking embedded 16- and 32-bit processors); (ii) how to include cloud cryptographic resources for highly-challenged devices; (iii) how such security systems could be made easy to use (i.e. how to naturally express trust relationships); and (iv) a reference implementation. 7. Estimating Driver Workload in the Car using Wearable and Embedded Sensors. This project seeks to explore how the car could be made more aware of a driver's cognitive state, or workload, by monitoring a variety of physiological and physical sensor streams. For example, drivers may wearables like smart watches that monitor heart rate, or continuous glucose monitors that track blood sugar (e.g. http://www.dexcom.com/dexcom-g4-platinum), or galvanic skin resistance sensors that can measure sweat, or smart phones that can detect erratic driving. Meanwhile, OBD devices can track hundreds of internal parameters of a car and smart phones can access traffic, weather, and myriad other parameters over the network. Imagine you could fuse all of this information. Would it be possible to estimate a driver's cognitive state? Buy a bunch of sensors, gather a bunch of data, and see what you can find... 8. Establishing Context with Cyber-Physical Hyperlinks. Bluetooth Smart (aka BLE) advertisements can be used to establish a physical context for a mobile device within the physical space that it occupies. Proposed techniques for doing so include iBeacons, Gimball, and UriBeacons. Compare and contrast these various techniques, creating a taxonomy of space, and implement each of the protocols on the Squall platform. Finally, place Squalls in a variety of locations (e.g. CSE conference rooms) and work through an application that allows room reservation using just the beacons. 9. Buildings (or campuses) should have mobile apps. Such apps can help fingerprint buildings (for example, every mobile device can participate in a "war-driving" campaign that fingerprints a building, collecting time, GPS location, magnetic fields, and visible WiFi, Bluetooth, and FM basestations, beacons, and stations, respectively, and their signal strengths. (Some version of the system might collect acceleration and gyroscope data as well.) These data would be "anonymized" and entered into a database in real time (or perhaps buffered). Over time, as in increasing amounts of data are collected, they must be labeled. One possibility is to ask some people, so of the time, to label the data, perhaps by asking them what room they're currently in. This project will define a namespace for buildings, define a web service for reporting this data, identify visualization methods for clustering and displaying the multi-dimensional data, and determine when to query users to minimize user disruptions while maximizing the opportunities for labeling data sets. Finally, using the labeled datasets, can your app estimate what room it is in? 10. Or your favorite idea...software-defined hardware...IoT gateways...or something else.