Project
| # | Title | Team Members | TA | Documents | Sponsor |
|---|---|---|---|---|---|
| 15 | USB Controlled Appliances |
Nagarjun Kumar Peter Jin Riley Baker |
Dean Biskup | design_document3.pdf final_paper1.pdf other1.pdf photo1.jpg presentation1.pdf proposal3.pdf |
|
| Peter Jin (peterhj2), Riley Baker (rileymb3), Nagarjun Kumar (nk7) Title: USB Controlled Appliances Problem: There are many kinds of IoT devices, ranging from smart plugs, thermostats, washers and dryers, garage doors, and refrigerators. However, the main issue with these kinds of devices is that the embedded systems that run on those devices are closed-source, out of date, or simply have glaring security and privacy issues. Furthermore, since they usually connect via Wi-Fi to a home network, the attack surface of many of those devices is very large since any computer on the network could access it in some way, allowing attackers on the network to potentially control these devices maliciously. Building a smart plug or appliance by yourself also has challenges. For example, some appliances require switching of high voltages, which may not be safe on a breadboard. This effectively makes a “DIY” version of a smart plug that doesn’t connect to the Internet very difficult to create safely. Solution: Separate the part that connects to the Internet with the part that actually switches the appliance, and connect them with a safe and well-defined wired protocol. This is what our “USB Controlled Appliances” project intends to do. Instead of connecting to the Internet via Wi-Fi, this “smart plug” connects to a computer via USB. In this way, the computer can be used to control the smart plug, without inherently relying on wireless network protocols. Since this smart plug does not have any Wi-Fi capabilities, the attack surface will be greatly reduced. The main competitor to our project is the Digital Loggers IoT relay (https://dlidirect.com/products/iot-power-relay). However, the main difference between that and our project is that the former is just the relay itself (with logic level input), whereas our project focuses on being a complete yet separatable kit. Solution Components: Appliance Subsystems: These are the actual “smart” appliances. Ideally, these appliances should not have any complex “computer” logic in them. They may have transistors, resistors, capacitors, and simple logic gates. The use of ATMEGA or similar chips are also allowed, but nothing wireless is allowed, and they must be removable from the circuit board by the end user. Currently, we intend to create the following appliances for this project: * A door opener, using a solenoid. It can be a normal door to a room, or it can be the door to a safe. * A motion detector, as an example of an "input" device that can be connected to the hub. * Due to its novelty and simplicity (since it is so generic), the optocoupler switcher will be kept. (The TA originally proposed the use of a garage door opener, which we subsume under this heading, as the mechanism will still be very similar, whether it's the physical button or the remote control.) * We will still do simple switches with one or more LEDs, just to show the overall proof of concept in a simple manner. (This appliance can still be extended in some way to become a smart plug, for example, and is still meaningful by itself.) * Finally, even with these appliances in mind, we will design the circuit such that the microcontroller can be safely removed (ideally by putting the IC in a DIP socket or switch, rather than SMD) and the actual terminals that control the appliances are broken out on internal headers, such that alternative logic can be used without having to build a whole new appliance. Hub Subsystem: This is a device that connects to the computer via USB and also to the appliances themselves. The reason why we need this is because 1) we intend for the appliances to be simple, and so they can be used in other “generic” IoT projects without this hub, 2) it relieves us from having to implement a USB protocol on all four types of appliances directly, and 3) allows multiple appliances to be connected to one USB port, which very few exist on many modern computers. Computer Subsystem (not formally part of the hardware design): This is the computer that actually controls the “smart devices.” This may be an actual desktop or laptop computer, or it can be a Raspberry Pi or other single-board computer. The software should be able to run on any computer with a USB port regardless of characteristics like the CPU architecture or operating system. When used with software that allows the appliances to be controlled remotely, the computer here is also known as a “bastion host” for the appliances. Each subsystem will be its own unit with its own circuit board and enclosure. The appliance-to-hub connection will use a protocol that is convenient for the appliance, and the computer-to-hub connection will use USB. Criterion for success: * The appliance subsystems will be able to control various types of appliances (remote control, door lock, etc.) electrically using protocols that are simple to implement and are only as complex as necessary for the appliance. * The hub subsystem will convert between USB and the simple protocols used by the appliances, such that the simple protocols for the appliances don’t need to be broken out on the computer, and each of the appliances doesn’t need to implement USB by itself. * The appliances, hub, and computer communicate between each other using simple, well-defined protocols. * The system is designed such that no wireless communications is necessary for any purpose, except those which may be implemented on the computer. * All components are "separatable" i.e. the microcontroller must be able to be safely removed, and all components which are built into their own enclosures must be independently usable without any of the other components. |
|||||