IoT cloud laboratory: Internet of Things architecture for cellular biology

Abstract

The Internet of Things (IoT) provides a simple framework to control online devices easily. IoT is now a commonplace tool used by technology companies but is rarely used in biology experiments. IoT can benefit cloud biology research through alarm notifications, automation, and the real-time monitoring of experiments. We developed an IoT architecture to control biological devices and implemented it in lab experiments. Lab devices for electrophysiology, microscopy, and microfluidics were created from the ground up to be part of a unified IoT architecture. The system allows each device to be monitored and controlled from an online web tool. We present our IoT architecture so other labs can replicate it for their own experiments.

Keywords: Cloud biology; Cloud computing; Electrophysiology; Internet of things; Microfluidics; Microscopy.

Fig. 1.

IoT Cloud Laboratory. Experiments are automated through cloud connected devices to allow scalability, reproducibility, and online monitoring.

Fig. 2.

Inter-device MQTT message broker. The MQTT message broker provides integration and control over multiple internet-connected instruments. The functionality supports clients, data acquisition modules or software applications, to connect and subscribe to topics set by a publisher, such as the user interface (UI), with the proper authentication protocols. By doing so, clients subscribed to the topic will be informed of the state of each data acquisition module (e.g., start, stop, etc.) and parameter changes throughout an experiment.

Fig. 3.

Data storage architecture. Data storage is buffered to the local device before being delivered to cloud S3 storage. Network and cloud service disruptions are expected. With the real-time data feed, interruptions only impact active visualizations of the data, which is acceptable, but the loss of experimental data is not. Each device buffers data to its local storage before making a best-effort attempt to upload it to the S3 distributed object store. Data may be buffered until the local storage is exhausted (typically enough for at least a day). The S3 distributed store is backed up to AWS Glacier to guard against user error (accidental deletion) and the loss of the S3 service. Cloud providers like AWS, GCP, and Azure have strong S3 service level agreements, unlike academic clusters such as the PRP.

Fig. 4.

Real-time data visualization. (1) Electrophysiology, Microscopy, and Fluidic IoT devices produce real-time data streams on-demand only when a user is connected to a visualization that utilizes that stream. (2) Data transformations process raw data into a variety of helpful forms. Each independently containerized transformation reads a data stream and produces a new data stream. (3) Visualization and alerts notify IoT devices via MQTT that data streams are needed.

Fig. 5.

Example data processing workflow for an electrophysiology experiment. In Job 1, a subset of the data is analyzed to determine which channels are active. Next, in Job 2, raw data for each active channel is converted into the form necessary for data analysis (this step takes advantage of cluster parallelism, splitting tasks by data file). Finally, in Job 3, the data analysis, including spike sorting and other custom analysis tasks, is performed in parallel per active channel.

Fig. 6.

An outline of existing tools that utilize the IoT Cloud Laboratory platform described in this paper. (Device) shows Picroscope [32,33] for microscopy, Piphys [34] for electrophysiology recording, and Autoculture [35] for fluidic media exchange and liquid biopsy. (Infrastructure) shows the primary suite of tools introduced in Sections 3.2, 3.4 and 3.5. (Control) shows a snapshot of existing web-based control interfaces. These web pages are running on a server in the UCSC Genomics Institute. (Analysis) demonstrates some of the reports produced by workflows that run as data post-processing jobs. “Picroscope” and “Piphys” figures are adapted from Ly et al. [32], Baudin et al. [33], Voitiuk et al. [34].

Fig. 7.

Monthly resource utilization requirements given three use cases: Science, Student, and National scales. The assumed distribution of device functions under each use case is displayed in circular gauge charts above. Resource utilization for CPU, network and storage are displayed in bar graphs below. An estimate of Cloud Pricing is provided at the bottom. The number of active devices varies from fewer devices in the Science Use Case to many in the National Use Case. We define “% Imaging” as the percentage of devices actively recording and storing microscopy images; “% Metrics”, as the percentage of devices actively recording measurements such as media concentrations and temperatures; “% Raw voltage trace”, as the percentage of devices recording and storing full raw voltage traces across all electrophysiology channels; “% Spike Raster”, as the percentage of devices registering only neural spikes events (estimated to be 10% of the raw voltage data); “% User Interface”, as the number of active users on the web interface relative to the total number of devices; and “% Stimulation”, as the percentage of devices that are actively executing electrode stimulation requests.