Cloud-Based Lab Instrumentation System

The goal of the project is to build a lab instrumentation system that allows for remote management of devices used in a lab setting, which includes both parameter monitoring as well as control over these devices. We want to build a system that can control a lab while using state-of-the-art security protections to safeguard lab data.

=Problem Definition=

Background
A previous project, [|0 App Controlled Poinsettia Covering System] was completed in 2018 that allowed for remote control over a covering system at one of the University of Idaho's greenhouses. We want to expand on this project in creating a system that can respond to event triggers as well as handle more types of data for monitoring. Additionally, there is a growing problem with security in IoT enabled devices, as many of them have been developed and rushed to the market without information assurance in mind, or the devices are incapable of implementing standard security features. We want to gather measurement data for research and agricultural purposes and do this securely to prevent unauthorized access.

Deliverables
A web application that can manage lab instrumentation.

Specifications
 See and visualize lab data in real time via a web browser Record and store lab data in a database Upload/download data Control lab equipment Support multiple sites as well as multiple users at each site 

=Design Considerations=
 * A Raspberry Pi will be used to collect all data from the lab to be monitored.
 * We decided on using the Google Cloud Platform to create/manage our backend part of the project.
 * Data will be accessible through a web interface via a browser.
 * Google Pub/Sub, a cloud messaging service from GCP will be used to handle ingress data from the Pi, which then is stored in a database, also running on GCP.

Original Plan
Once data is received from the Pi via Pub/Sub, it will be stored in Google BigQuery. Google Cloud Run, a serverless computing platform gets input from Pub/Sub and moves it to BigQuery to be stored. The dataflow diagram below depicts how data is to move through the system.



End of Semester 1 Design
An image of our initial prototype is shown below.
 * We decided against using Google BigQuery and instead are using Google Cloud SQL to store sensor data, which is a MySQL Database that runs on Google's servers.
 * Google Cloud Functions are triggered from the Pi publishing a message to a Pub/Sub topic. These functions connect to Cloud SQL to store the data. Originally Cloud Run would be used to handle this, but Cloud Functions were determined to be an simpler implementation. We may still use Cloud Run to handle the video stream.
 * A Cloud Function is also invoked via HTTP requests from the web interface to return sensor data from the database.
 * Google Firebase is used to handle the sign in of users

=Project Learning= Using Cloud SQL vs. Big Query
 * Cloud SQL is simpler to implement
 * No read/write limits exist with Cloud SQL
 * More cost-effective for our needs
 * Big Query is designed to handle/process massive amounts of data, which will not be necessary for this project.

=Final Design=

=Validation Plan= =Team Members=

=Additional Documentation=

[|0 Project Schedule]

[|0 Meeting Minutes]

Presentations

[|0 Snapshot Presentation 1] [|0 Snapshot Presentation 2] [|0 Concept Design Review]

Client Interview