% !TeX root = main.tex \iffalse This should include background theory, justification for the design choices and any assumptions made. These should relate to each IoT layer under consideration. Block diagrams, schematic diagrams and flowcharts are excellent illustration tools. This section should not include screenshots nor detailed “how-to” operations (these should appear in an Appendix if necessary) * Have you identified the problem you are addressing? * Have you provided an overview of how you are addressing this problem? * Have you provided detailed steps of what you did in a logical order? * Have you described the methods you used to solve the problem and their purpose? * Have you identified the parameters for designing your system? * Have you identified the metrics for evaluating the performance of your system? * Have you used illustrations to give the reader a visual interpretation of your system? \fi \section{Design Methodology and Implementation} \subsection{The Problem} Universities with medium or large campuses offer many cafes to their students. For example, UCL’s has the George Farha Café, Engineering Café, IoE, Gordon’s Café, Bloomsbury, Print Room, to name a few. These establishments are open during working hours to the student and academic body and are used to grab a drink on the go due to their proximity to lecture rooms and libraries, or as a place to sit down and have a break, eat lunch or conduct group meetings. As a result, these places tend to get quite crowded, creating long queues, and a loud ambiance therefore creating an unpleasant area to be in. UCL students usually have limited time to buy coffee and just cannot go through all the cafés until they find one that has the shortest queue. The problem is that the students and staff do not know how busy the cafés are at a given time. Similarly, the cafe does not know when students will be most free during the day and can be understaffed at peak times and over staffed during more calm hours. To address this problem we have developed Coffee Time, an IoT package that offers a phone application (app) showing how busy cafés are or will be in near future. An IoT device collects multiple metrics from café’s environment which is sent to the cloud system. Inside the cloud raw information is analysed and processed to be represented on the app. \begin{figure}[H] \centering \includegraphics[scale=1]{graphics/system.png} \caption{A simplified overall system illustration.} \label{fig:simplified} \end{figure} Some previous studies to detect crowds and people count have been proposed by using complicated computer vision to analyse people count \autocite{8473458}. However, such a solution would require complex and sophisticated programs, and powerful hardware, which brings other problems with battery life and overall project expenses. Furthermore, this project was not only aiming to measure how crowded an establishment was but also the overall ambiance of the place. Since ambience is quite an abstract concept, it was important to define what factors can determine and measure the ambience of an environment. These factors were determined through the use of literature and can be seen on \autoref{fig:ambiance}. \begin{figure}[H] \centering \includegraphics[scale=1]{graphics/ambiance.png} \caption{Environment.} \label{fig:ambiance} \end{figure} Therefore, Coffee Time will be measuring air quality which includes $CO_2$, TVOC, $H_2$, Ethanol, Temperature and Humidity readings; and WiFi activity. We expect to see correlation between air quality and café’s activity due to CO2 and TVOC increase from people and the coffee making process. WiFi activity should correlate with amount of people staying inside and using their phones or laptops. \subsection{Background Theory} \subsubsection{IoT Stack} % explain the IoT stack and each layer \begin{figure}[H] \centering \begin{subfigure}[b]{0.45\textwidth} \centering \includegraphics[scale=0.55]{graphics/iot_model1.eps} \caption{Model 1} \label{fig:iot_model1} \end{subfigure} \begin{subfigure}[b]{0.45\textwidth} \centering \includegraphics[scale=0.55]{graphics/iot_model2.eps} \caption{Model 2} \label{fig:iot_model2} \end{subfigure} \caption{IoT conceptual models}\label{fig:iot_models} \end{figure} There are different versions for the IoT stack and many of these versions will agree in many areas. However, there is no formal standard for the IoT stack. \autoref{fig:iot_model1} and \autoref{fig:iot_model2} are two such examples of the IoT stack. These models may seem similar but they are different. Below an explanation into both the models will be done and which model was chosen for this project. \\ \textbf{{\small Model 1}} This model contains three layers. The bottom layer is used for the sensors connected to the IoT device. The middle layer is for connectivity. Finally, the top layer is for data analytics. In this model each layer is specific as to what should take place in each layer. \\ \textbf{{\small Model 2}} This model is more generalised or abstracted than the other model. Like the other model this model also has three layers. The top layer of the model is for cloud services such as real time streaming or database storage. This also encapsulates data analytics. Thus called the application layer. The middle layer is for the gateway. The bottom layer is known as the object layer and it can be for sensors or motes. \\ % talk about which model was chosen for the project \textbf{{\small Chosen Model}} For this project the model 1 was chosen as the IoT stack. This was more specific for this project as we looked at the sensors that can be used to get the data for each metric. The connectivity layer looks at sending the data to the server over Wi-Fi. Finally, data analytics will be done on the collected data to see if there is any correlation and to give predications as to which cafe to go to. \subsubsection{Communication Protocol for sensor data} % Give a small general introduction to the topic \textbf{SPI} — Serial Peripheral Interface benefits from full duplex communication and high throughput, up to 10Mbps. It is excellent for peripheral such as screens, ADC, flash memory and similar low latency and high throughput requiring components. However, it requires four wires (six with power and ground) to communicate, and one extra wire for each additional peripheral.\\ \textbf{$\mbox{I}^{2}\mbox{C}$} — Inter-Integrated Circuit is only half duplex and operate on master-slave serial bus. Single master can communicate with up to 127 peripherals that connect the same common bus. It has lower throughput of 10-1000kbps and due to nature of half duplex, to get response from a peripheral the master has to send a request first. This is ideal for this project as sensors only require few hundred bits to communicate with microprocessor, and sensor does not send continuous data stream. In addition, it is much easier to set up at hardware level as it only requires all peripherals to be connected with the same two wire bus (four with power and ground). \subsubsection{Methods for checking changes in state for devices connected to processor} Polling and interrupts are two methods that can be used to see if a device has reached a state. These are useful techniques that are used by the microcontroller to detect a change in state for a device that is connected to the processor. Below the two methods will be described. \\ % Polling \textbf{{\small Polling}} Polling checks for the change in state of the connected device by simply checking if the state of the device has changed to the set value in a loop. This section of code ill be a subset of the main program. For example there can be a loop where there will be some code to carry out a certain operation, then code to check if the state has changed and what to do if that is the case and then there can be some other code for some other operation. This entire code will be repeated until an exit condition is met. \\ % Interrupts \textbf{{\small Interrupts}} Interrupts work differently. Instead of always checking if the state of the external device has changed or not, the processor will carry out the main program but when a change does occur then the processor is interrupted or notified that there is a change. Once the current instruction has finished executing the interrupt is handled by the processor using a Interrupt Service Routine (ISR) and the processor will go back to executing the main program. \\ \textbf{{\small Chosen method}} For this project interrupts was chosen as the method for seeing if the state of the device has changed. This was because the main program will not have to check continuously if the value has changed, it will be notified when it does. In addition to this polling will have a delay when checking if there is a change to the state of the device since the loop will contain other code which is not responsible for checking the state of the device. \subsubsection{Low Power Mode} \subsubsection{Wi-Fi Activity}\label{subsec:wifi} IEEE 802.11 standard describes that Wi-Fi modules has eight operation modes. Monitor mode allows Wi-Fi module capturing Wi-Fi packets that are transmitted around it. These packets can provide information such as source and destination MAC addresses, data rate, Signal-to-noise ratio (SNR) and a number of other fields about the network. Packets are grouped into three types: management, control and data. Management and control packets are dedicated for coordination, access point authentication and any other operation that does not include user sent data. These packets can be used to detect how many uniquely connected devices are in the surrounding area. \subsubsection{Cryptography}\label{subsec:crypto} This project uses symmetric encryption which uses one and the same key to encrypt and decrypt a message. As a cryptographic key is flashed into IoT device's ROM, this key is never sent over non-secure media, therefore, no need for asymmetric encryption. An unpredictable random nonce is provided by the server upon new connection as shown in \autoref{fig:crypto}. It is used as an input to the chiper which ensures that identical messages with different nonce would yield a completely different encrypted data. The same nonce value is then reused inside the cloud to decrypt the message that was encrypted at the IoT device. Without such a mechanism a replay attack is possible. If a malicious source captures an encrypted message and resends it to the cloud, the cloud will not be able to differentiate between legitimate and repeated messages. \begin{figure}[H] \centering \includegraphics[scale=0.4]{graphics/ecrypto.eps} \caption{Diagram representing cryptographic nonce and encrypted message exchange between the could and the thing.} \label{fig:crypto} \end{figure} \subsubsection{Checksum} This project uses cyclic redundancy check (CRC) error-detecting code. This is a very simple and fast algorithm that creates seemingly a random result from provided input. A message can be processed with this algorithm where the result is attached to the message before sending it. When this message is received, it can be processed again with the same algorithm and the calculated result will be compared to attached CRC result. If the results are different then there was an error when the data was transmitted. \begin{figure}[H] \centering \includegraphics[scale=0.4]{graphics/checksum.eps} \caption{Block diagram of CRC checksum logic} \label{fig:checksum} \end{figure} \subsection{System Design} This section describes the overall design of the implemented IoT device. The description starts from explaining the implementation of the sensor layer and then moving on to the connectivity layer and finally the data analytics layer. \\ \subsubsection{Layer 1} The IoT core component is \texttt{Feather HUZZAH ESP8266} module containing a \texttt{ESP8266} microcontroller with built-in Wi-Fi. This module also has a built-in Lithium Polymer (LiPo) battery charging circuit, USB connectivity with serial converter to charge and program microcontroller and linear converter to supply 3.3V rail. The air quality \texttt{SGP30} and temperature-humidity \texttt{BME280} sensors were both connected via $I^2C$ bus. An additional \texttt{IO16} pin was connected to the reset pin, which enables deep-sleep mode wakeup timer. \autoref{fig:thing_diagram} shows the circuit diagram connecting all the components of the IoT device. \begin{figure}[H] \centering \includegraphics[scale=0.55]{graphics/thing_diagram.eps} \caption{Circuit of IoT device.} \label{fig:thing_diagram} \end{figure} With this configuration, even in deep-sleep mode both sensor modules are still powered as 3.3V bus is not affected. This is intentional as both sensors have low-power modes. \texttt{BME280} sensor outputs temperature, humidity and pressure readings. This sensor has three modes, sleep which does no operation and is at the lowest power, forced which perform one measurement, stores the results and returns to sleep and normal mode for perpetual cycling of measurements. Additional oversampling and IIR filter settings can be set. The weather monitoring configuration that was recommended by the datasheet was used, this uses forced mode with one sample per minute without oversampling and IIR filter. This achieved reasonable noise and performance with average current consumption of $160nA$. \\ \texttt{SGP30} sensor was equipped to measure carbon dioxide (from 400 ppm), total volatile organic compounds (in ppb range), relative $H_2$ and ethanol values. After the sensor has been powered it goes into low power sleep mode. When the microcontroller sends a measurement request the high current measurement mode is activated. Internally the sensor takes a sample at 1Hz. This was used to calculate a baseline. During experimentation, it was seen that it takes around 16 seconds since booting to read an accurate value. This lead to the decision of not disconnecting the power from this sensor during sleep as it will not be able to give an accurate value when requested by the microcontroller. This sensor also features an on-chip humidity compensation calculation, however, it requires the absolute humidity value to be provided by the microcontroller. This value was calculated from the \texttt{BME280} sensor readings using the following equation (\autoref{eq:ah}). \begin{equation}\label{eq:ah} AH = 216.7 \times \frac{\frac{RH}{100} \times 6.112^{\frac{17.62t}{243.12+t}}}{273.15+t} \end{equation} Where AH is absolute humidity in $g/m^3$, RH is relative humidity in percent, and t is temperature in $^{\circ} C$.\\ \begin{figure}[h] \centering \includegraphics[width=\linewidth]{graphics/program.eps} \caption{Functional diagram of IoT device program. Dashed line indicates data taken by logic block.} \label{fig:program} \end{figure} \autoref{fig:program} shows a flowchart for the implemented software on the IoT device. The program starts by enabling the Wi-Fi monitor mode which executes an ISR every time the microcontroller's Wi-Fi module receives a Wi-Fi packet. This packet is processed and the Wi-Fi packet type counter is increased as described in \autoref{subsec:wifi}. This stores three count for each packet type that has been captured during the period before the payload was composed. A one second delay before composing the payload was used to give enough time to capture the average Wi-Fi activity. During a small experiment, while continuously measuring packets, it was concluded that one second is sufficient to represent average Wi-FI activity. \\ After the main program enables the Wi-Fi monitoring routine, the serial and the sensors are initialised. Serial block represents Universal Asynchronous Receiver-Transmitter (UART) connection setup which is used for debugging purposes. Sensor initialisation include connecting them via $I^2C$, retrieving their parameter correcting if they are not right. If either of the sensors do not respond or indicate a problem, an error flag is set high for that sensor. \\ The program then goes onto gathering sensor readings and composes a payload message with CRC32 checksum. If \texttt{BME280} sensor is faulty, setting absolute humidity for \texttt{SGP30} is skipped. Then the Wi-Fi mode is changed to connect to an access point which allowed the IoT device to be connected to the server. Upon a new TCP connection, server sends a cryptographic nonce which microcontroller uses to encrypt payload and send it to server, this logic is explained in \autoref{subsec:crypto}. Afterwards the server and Wi-Fi connections are gradually disconnected, meaning it sends end of connection packet to TCP and de-authentication instruction to Wi-Fi. Then a timer and deep sleep mode is set. When timer time expires, program is reset. \subsubsection{Layer 2} \begin{center} \begin{tabular}{r@{}l@{}ll} && \textbf{Content Name} & \textbf{Size and type} \\ \hline && Device ID & 8bits \\ && Payload length* & 8bit unsigned integer\\ \multirow{13}{2cm}{Encrypted Payload \textbf{24-bytes}} & \ldelim\{{13}{*} & Temperature Reading& 32bit float \\ && Humidity Reading& 32bit float \\ && Pressure Reading& 32bit float \\ && Wi-Fi Managed packets & 16bit unsigned integer \\ && Wi-Fi Control packets & 16bit unsigned integer \\ && Wi-Fi Data packets & 16bit unsigned integer \\ && $CO_2$ Reading& 16bit unsigned integer \\ && $H_2$ Reading& 16bit unsigned integer \\ && TVOC Reading& 16bit unsigned integer \\ && Ethanol Reading& 16bit unsigned integer \\ && Status Flags& 8bits \\ && \textit{reserved.} & 8bits \\ && CRC32 Checksum & 32bits \\ \end{tabular} \captionof{table}{List of message content sent from IoT device to server via TCP socket. \textbf{*} Payload length is represented in multiples of 12bits, value of 2 in this case.} \label{tab:message_content} \end{center} The breakdown of the message that will be sent to the server is shown in \autoref{tab:message_content}. \\ Sending data in raw binary was chosen as suppose to encoded with data interchange format such as JSON or XML due to bandwidth efficiency, computation time and simplicity of implementation with C language. ChaCha20 cipher was used for encryption with 12 byte nonce. This nonce size requires payload to be in multiples of 12 bytes blocks which is the reason for having "reserved" byte in payload. \\ Each IoT device is designed to have a unique built-in symmetric key. Device ID is not encrypted and used by server to lookup key dictionary and decrypt the payload. Checksum is also crucial in this case to ensure that used key is correct, because when using an incorrect key resulting message would be "garbage" meaning that the message and CRC would not match. \\ Since this IoT device will not be sending any sensitive information and encryption may seem unnecessary. However, this solution ensures that received information was authenticated. This also prevents malicious parties from sending false readings to show that certain cafe is more or less busy, which could have financial advantage. \subsubsection{Layer 3} \begin{figure}[H] \centering \includegraphics[scale=0.4]{graphics/cloud.eps} \caption{General flow diagram of whole system connectivity.} \label{fig:cloud} \end{figure} % this section needs to be expanded. It is hard for a reader to follow. Mor information is required The cloud contains four main parts: connector, database, API and Grafana User Interface, general block diagram is shown in \autoref{fig:cloud}. Connector is responsible for receiving raw TCP packets, decrypting payload and sending formatted content to Influx Database. This database is chosen because of its time series nature, real-time monitoring, rich documentation and advanced capabilities to analyse data. Data from database is then used by Grafana UI for this platform administrators to perform analysis and monitoring. API block is a simple HTTP server that formats and serves all necessary data from database to user application, such as day predictions and current readings. These responses are formatted with JSON. This block also acts as a security layer so database could not be accessed directly.