MAHIVE Hub for IoT Sensors

The MAHIVE project's primary goal is to have IoT-enabled smart building sensors to form a system of cyberphysical protection. The sensors would send their events to a server, using a hub device as a middleman.
Eventually, the server would be able to correlate events together as part of a defense against physical and digital attack.
Our team's helped develop a the hub device to interface with each individual IoT-enabled sensor and relay their data to the server. It will handle JSON formatting and encryption, to ensure that each piece of sensor data makes it reliably to the server. In addition, we are developing individual IoT-enabled sensors to integrate in with the hub device. We are using AWS IoT Greengrass libraries, along with Amazon FreeRTOS, to enable the connection between hub and server, and between sensor and hub.
=Problem Definition=
Hacking is an ever increasing threat, and industry needs a way to defend itself physically and digitally. Sites like universities are a vulnerable target due to the large amounts of computer equipment contained within the various buildings. Using IoT-enabled sensors would allow for a modular, easily expandable security system to protect valuable equipment and data. 
==Background==
In the past, cyber security has been limited to the digital world, without a way to defend against physical attacks. While digital threats are still a relevant concern, special attention must also be paid to physical security of devices and data. If someone with enough knowledge or expertise were afforded physical access to a computer system, server, or data storage, they could cost an organization several thousands of dollars in damages. 
The MAHIVE project has the goal of correlating physical and digital events into a system that can provide total security. It will utilize multiple elements to accomplish this. The main feature of the overall project is an AI-enabled server to correlate events together to identify an intruder or malicious actor. Our project is a smaller part; it covers the individual sensors that will act as the initial data collection.
Recent advances in microcontrollers and microprocessors now allow for sensors to be connected as IoT devices. This would be similar to a smart home setup, with a modular network of sensors reporting data to a single hub device. This hub would then relay all sensor data back to the server. Utilizing IoT devices like this would allow for a modular system that could be adapted to any number of buildings and situations.
==Deliverables==
===Final Course deliverables included===
* Final Hardware/Software
** Final Tech Demo Setup
* Design Report/Project Portfolio
* Completed Wikipage
* Electronic Archive
** Google Drive Folder
** Github Repository
===Project deliverables requested by the client===
* Github Repository
** Commented Code and Documention
** Link to repository
* Expense Report
** Items Purchased for Tech Demo
==Specifications==
===Main specifications for project===
* The device must be able to authenticate with the server.
* The device must format the sensor data into JSON.
* The device must encrypt the JSON and send it to the server for decryption.
==Design Considerations==
===Physical Considerations===
* Design must be low-cost (goal for sensors: <$50)
** No elaborate solutions that take large amounts of money to implement.
* Design must use off-the-shelf parts/boards.
** Raspberry Pi, Arduino, etc.
** No custom-designed boards or parts.
** Utilize simple sensor parts readily available online.
* Sensors should ideally run off battery.
** Board used for sensors should be built for low power consumption.
** Device not constantly polling; use interrupts if possible.
* Sensor device should be small and easily placed inside buildings.
** Should not attract attention to prevent tampering.
=Project Learning=
Much of the project learning consisted of research into various devices and platforms that would suit our purposes. We brainstormed whether to use individual, self-sufficient devices, or to have a hub device collecting and sending data from smaller leaf devices. Research was performed on the pros and cons of various microcontroller devices, such as Arduino Uno, Raspberry Pi 3, Espressif ESP32, and others. Finally, we looked into the time costs of setting up our own authentication and encryption from scratch, versus utilizing an existing IoT platform.
In the end, we decided to use AWS IoT Greengrass as the platform, since at the time it seemed like it would solve some of the other logistics and allow us to focus on the sensor devices themselves. We believed that using Greengrass would save time and allow for a product that incorporates a hub device with smaller leaf nodes scattered throughout a room. For the hub device, we chose to use a Raspberry Pi 3, as it was the most cost-effective device explicitly supported by Greengrass. For the leaf devices, we decided to run Amazon FreeRTOS on an ESP32 microcontroller. This would be able to receive sensor input, and send it back to the Amazon Cloud via the Raspberry Pi.
== Device Research ==
=== Arduino Uno ===
Info Page:
Price: $19 (Official Model)
::$11 (Off-brand equivalent)
Pros:
* Relatively low power consumption (~15mA minimum, could run off 9V battery for about 1 day)
* Highly supported with detailed documentation of libraries and IDE
* Support for many add-ons (shields) that add functionality such as Wi-Fi, ethernet connectivity, etc.
Cons:
* Low CPU power (only basic encryption supported)
* No built-in internet connectivity (Wi-Fi or ethernet) or Bluetooth (shields must be used)
* Extra shields may cost as much as the board itself
* Higher power consumption than other microcontrollers due to extra components on board
=== Arduino Mega ===
Info Page:
Price: $28 (Official Model)
::$14 (Off-brand equivalent)
Pros:
* Larger board, greater number of GPIO pins than Arduino Uno
* Uses ATmega2560 for greater processing power, can run basic encryption libraries and have enough resources as a sensor device
* Same level of support with libraries and IDE as Arduino Uno
Cons:
* Cheaper than Raspberry Pi, but still more expensive than almost any other microcontroller
* Greater power consumption, would not be able to run off battery
* Larger size may not be as suitable for IoT device
* No built-in internet or Bluetooth (same as Arduino Uno)
=== ESP32 ===
Info Page:
Price: $11
Pros:
* Designed to have very low power consumption
* Built-in Wi-Fi and Bluetooth connectivity
* More processing power and larger memory size than ATmega328p in Arduino Uno
* Small board size ideal for IoT devices
* Supports Amazon FreeRTOS, can be used with AWS IoT Greengrass
Cons:
* Limited support and documentation compared to Arduino
* Development/programming may be more complicated than Arduino or Raspberry Pi
* If multiple units are needed, the cost may still be high
=== Raspberry Pi 3 ===
Info Page:
Price: $35
Pros:
* Much greater processing power than other boards
* Low powered computer rather than microcontroller, much more functionality in terms of software
* Many supported libraries, excellent documentation and online resources
* Large variety of open-source software available
Cons:
* Costs more than any other device researched
* Much larger power consumption, would almost have to use AC power
* Overkill for a simple sensor device
=== Raspberry Pi Zero W ===
Info Page:
Price: $10 (without headers)
::$14 (with headers)
Pros:
* Costs much less than Raspberry Pi 3
* Has all the processing power and functionality of 1st-generation Raspberry Pi, but in a much smaller size
* Nearly the same level of support and documentation as the full-size Raspberry Pi 3
* Nearly the same availability of open-source software
Cons:
* Still too overkill for a sensor, but not enough physical I/O to be used as a hub device (e.g. no built-in ethernet)
* Less CPU and memory resources compared to the full-size Raspberry Pi 3, meaning not all programs/software would be supported
* May still need to use AC power, could not run off battery
== IoT Platform Comparison ==
=== AWS IoT Greengrass ===
AWS IoT Greengrass website
* IoT Greengrass core device acts as a hub; it communicates with FreeRTOS-enabled devices
* Enables local execution of AWS Lambda code (Python code/functions)
* Messaging, data caching, and security built-in
* Would satisfy all 3 requirements with minimal coding
:*Time and energy could be spent on sensor devices themselves rather than the complexities of authentication and authorization
=== Azure IoT Hub/Edge ===
Azure IoT Edge website
* Main difference from AWS IoT Greengrass: core edge service is open-source
* Runs in cloud, integrates w/ IoT edge
* Raspberry Pi can act as gateway device
* Arduino/ESP32 connects/authenticates w/ hub
* Open-source runtime runs on Raspberry Pi, which acts as middle man between sensors and Azure cloud service
=== No Platform (Authentication/Authorization from Scratch) ===
* Not tied to a single third-party company
* No need for special authorization to use
* Very involved process to program authentication, authorization, and messaging
* Much more time spent on communication and authentication
* Very little time spent on sensors themselves
* Much smaller likelihood of finishing project with proper deliverables
=Final Design=
==Tech Demo==
Due to the nature of our project as more of a research project, our final design was less of a finished project and more of a final tech demo. The final tech demo setup that was used is shown here:
Shown in the image, clockwise from left: Raspberry Pi hub device with battery pack, mock door sensor, breadboard with kill switch, and light switch sensor.
The original plan was to build a more elaborate demo setup, but that changed to a more minimal setup due to social distancing rules making it more difficult to collaborate on a physical demo. Each sensor could easily be replaced by different hardware, with slight changes to the code. While not representative of a full implementation, this tech demo shows how the sensors could work, and how the messages are logged. In the future, this would be more fleshed out and polished, but for now the functionality is visible. 
==AWS Test MQTT Client==
To test out the message sending capability, we used the MQTT Test Client included in AWS IoT Core. It serves as an endpoint for receiving MQTT messages, and displays the contents as either UTF-8 strings or JSON. The MQTT client subscribes to the topic to which the Hub device publishes. It then receives all messages published to that topic.The MQTT client was used for testing and demo purposes; in the future it could be replaced with another device or service acting as a dedicated endpoint. AWS allows for data streams to be managed and exported either to local storage destinations or to the AWS cloud for storage and processing. In the future, the data from the sensors should be able to be exported to a server, or at the very least to local storage for analysis and machine learning.
=Team Members=
	
Major: Computer Science 
Hometown: Coeur d'Alene, ID 
Responsibility: Python/other software knowledge, Meeting notes, documentation 
Email: claw9831@vandals.uidaho.edu		
Major: Computer Engineering 
Hometown: Rathdrum, ID
Responsibility: Hardware research, Wikipage 
Email: grad6352@vandals.uidaho.edu
=Additional Documentation=
Additional documentation for this project can be found in either the GitHub repository or in the Google Drive folder. Initially, Google Drive was used, but at present all files are migrated to the GitHub repository.
Github Repository (Most Up-to-Date)
TEAM TBD Hub Device
Team TBD Google Drive Folder
Team TBD
=Marks for Future Expansion=
The most obvious area for future expansion would be in the realm of sensors. In the current iteration of the project, the sensors are not on individual IoT-connected devices. Currently, this Hub device will allow for that, but it is not fully implemented. One of the first ways to expand would be to add this functionality and make the sensors completely wireless.
Another area of expansion would be data storage. The project currently does not have a method to store the data in the cloud, as we were unable to get quite that far. AWS allows the data to be streamed to the cloud for data analytics, so that could be an option. Another route for expansion would entail creating some sort of endpoint server as a stand-in for a future MAHIVE server.