Projects:2018s1-111 IoT Connectivity Investigation

From Projects
Revision as of 19:56, 23 August 2018 by A1688675 (talk | contribs) (MQTT)
Jump to: navigation, search

Project Team

Sponsor

Soniclean

Honours Students

Edward Gray

Jack Mansfield

Supervisor

Andrew Allison


Introduction

As computers and network connectivity has become cheaper, more and more devices have been connected to the internet for a wide variety of purposes. These devices which are not used by a human in the way a traditional computer is are known as the "Internet of Things" (IoT.)

This project is sponsored by Soniclean Pty Ltd. "Soniclean® is amongst the world's foremost manufacturers of innovative medical grade ultrasonic cleaners, with over two decades of leadership experience in the ultrasonic industry. Soniclean® ultrasonic cleaners provide a faster, safer alternative to conventional cleaning methods and, using Soniclean's unique Pulse Swept Power® technology, give a superior cleaning performance."[1]

This project seeks to add IoT capability to Soniclean’s ultrasonic cleaning machines to enable new monitoring and auditing functionality. The project aims to develop a system to enable Soniclean's ultrasonic cleaning machines to report their operational status back to a central server. While there are IoT solutions commercially available on the market, Soniclean has determined that they need at least a partially custom solution as they have a unique set of requirements.

Abstract

To meet requirements outlined by Soniclean, we develop a prototype device on top of the existing and widely available Raspberry Pi hardware platform and the MQTT IoT data transmission protocol that will collect data from sensors embedded within Soniclean’s ultrasonic cleaners all over the world and send that data to a central server operated by Soniclean. This will enable Soniclean to offer new auditing and monitoring services for their products and thus grow their business.

We do not implement sensor or back end server systems, that being the responsibility of Soniclean. We only develop a means to collect sensor data and transmit that data back to Soniclean.

Background

About Ultrasonic Cleaning

The operation of Ultrasonic cleaners is not relevant to the rest of this project, except as context for why Soniclean seeks to measure and report the particular parameters on their machines.

In ultrasonic cleaning, items to be cleaned are placed in a solvent bath of mildly alkaline water. Transducers then blast sound waves through this bath at frequencies above human hearing, hence ultrasonic cleaning. These high frequency, high intensity sound waves cause cavitation- at the trough of the sound wave, there is a region of low pressure, which causes the solution to boil, forming a bubble. As the wave moves on, to it causes this bubble to compress with great force- over 20,000 PSI. This forcefully removes any contaminants from the surface of the objects being cleaned on a microscopic level.[2]

System Design

System Overview

A high level overview of the system is shown below. Sensors (yellow) collect data on the performance of the Ultrasonic cleaner. The compute system (green) collects that data, performs any required processing and saves that data locally. It then sends the data off across the Internet (blue) to the Soniclean server (red.)

SystemOverview111.png

Hardware

Compute Platform

To meet the needs of this project, a computing platform is required to be able to acquire, process, store and transmit sensor data. There are a number of requirements for whatever platform this system is to use, outlined below:

• The platform shall be low cost, to allow for adaption to economic use at scale

• The platform shall be widely available, to allow for adaption to use at scale

• The platform shall be well supported, both to assist in development and usage

• The platform shall have the required I/O- RS-232 serial and connectivity to a cellular modem

• The device shall have local storage

Considering, these requirements, and on recommendation from Soniclean, the Raspberry Pi 3 Model B was selected as the computing platform for this project. The Raspberry Pi is available for US $35 globally, has rich I/O including GPIO, UART, SPI, I2C, USB, Ethernet, WiFi, Bluetooth and having sold millions of units, has a broad and active community forum.

The Raspberry Pi also runs a full Linux environment, which makes developing one device very easy, making software development fast and simple. Storage on the Raspberry Pi is provided by a micro SD card, which can provide many gigabytes of storage for low prices, allowing for storage of many log files locally.

Networking Hardware

Modem hardware is required to communicate with the local cellular network to give the device internet access. The requirements for this are outlined below.

• The modem shall support multiple frequencies for worldwide operation

• The modem shall support for 3G networks

• The modem should have a reasonable cost

• The modem shall be software and hardware compatible with the Raspberry Pi

• The modem shall have support for an external antenna

Other Hardware

Rs485 adapter, mounting, antenna, interface

Software

Python

That software in this project is written in the Python programming language. We chose to use Python as Python has in built code for most common functions, including good support for third party applications and for its high level nature, allowing complex code to be written in relatively few lines of code.

We also chose Python as we have prior experience with the language, and wish to avoid having to learn a new language.

Python is also well supported on the Raspberry Pi, with many forum topics about the language.

MQTT

A protocol is sought to do much of the low level work to handle network communications in the system without coding an implementations from scratch. The protocol would ideally meet the following requirements:

• The protocol shall be able to reliably handle communications from one node to another across the internet with minimal additional coding

• The protocol shall have good documentation

• The protocol shall have good Python libraries and, if required good Linux tools

• The protocol shall be able to run on the Raspberry Pi

• The protocol shall be able to operate with limited network bandwidth and data usage

• The protocol shall be open source or otherwise free

Research was conducted and the Message Queueing Telemetry Transport protocol (MQTT) was identified as likely meeting all these requirements. MQTT is an ISO standard support by the OASIS consortium, designed as “an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. For example, it has been used in sensors communicating to a broker via satellite link, over occasional dial-up connections with healthcare providers, and in a range of home automation and small device scenarios. It is also ideal for mobile applications because of its small size, low power usage, minimised data packets, and efficient distribution of information to one or many receivers.”[3]

MQTT uses as publisher-subscriber model, with a broker acting as an intermediary, shown in the figure below

MQTT111.png

Publishers send data to a broker, and subscribers receiver data from a broker, meaning the only thing about the network an individual device must know is the broker. We use Mosquitto as the broker in this system. Mosquitto is open source software from the Eclipse foundation.[4]

To talk to the Mosquitto broker, we use the Python module Paho-MQTT, also open source and by Eclipse.[5] This allows us to write a Python program to send messages to our Mosquitto broker, and then another Python program to receive messages from the broker. This second program can be run on the same computer as the broker, meaning there are only two physical computing devices involved.

MQTT also breaks down communications into topics, which allow for the separation of unrelated data, or to allow an individual device to send different data to different other devices on the network.

Testing

Conclusions