Final_Report/src/design_methodology_and_implementation.tex

% !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

\newpage
\section{Design Methodology and Implementation}

\subsection{The Problem}
UCL currently has many cafes: George Farha, Engineering Café, IoE, Gordon’s Café, Bloomsbury, Print Room, to name a few.
 These establishments are open to the student and academic
body during working hours and due to their proximity to lecture rooms and libraries, they are
often used for as a grab and go, but many students also use it 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,
therefore, the cafés can become an unpleasant area to stay at. UCL students usually have limited time to buy coffee and just can not 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 given time. To address this problem we have developed a phone application (app) that shows 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=0.4]{graphics/simplified.eps}
	\caption{A simplified overall system diagram.}
	\label{fig:simplified}
	\end{figure}

Currently, there seem to be a lack of solutions on detecting crowds or how busy an indoor place is. Some solutions have been proposed by using complicated computer vision to analyse people count \autocite{8473458}. However, such solution would require complex and sophisticated program, and powerful hardware, which brings other problems with battery life and overall project expenses. This project has proposed a simpler solution, detecting how busy indoor environment is by measuring air quality which include $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 $CO_2$ and TVOC increase from people and 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 may of these versions will agree on many areas. However, there is no formal standard IoT stack. \autoref{fig:iot_model1} and \autoref{fig:iot_model2} and 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 sensors, the middle layer is for connectivity and finally the top layer is for data analytics. In this model each layer is quite specific as to what should exist.
	
	\textbf{{\small Model 2}}
	
	This model is more generalised 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 database storage, real time streaming. This also encapsulates data analytics. Thus called application layer. The middle layer is for the gateway. The bottom layer is known as the object layer, this does not only cover the sensors but this also could be motes.

	% talk about which model was chosen for the project

	\textbf{{\small Chosen Model}}
	
	For this project the first model is chosen as the IoT stack. This is a more specific for this project. 

\subsubsection{Characteristics of Sensors}
	
	\textbf{{\small Range}}
	
	Maximum and minimum value range over which a sensor works well. Sensors may work well outside this range, but require additional calibration. e.g. the output may no longer be linear. \\
	
	\textbf{{\small Accuracy}}
	
	How well the sensor measures the environment in an absolute sense, i.e. how good the data is when compared with a recognized standard. e.g. a temperature sensor accurate to 0.001oC is expected to agree within 0.001oC with a known temperature standard. This is what you want to compare results with other observations. \\
	
	\textbf{{\small Resolution}}
	
	The ability of a sensor to see small differences in readings. e.g. a temperature sensor may have a resolution of $\mbox{0.000,01}^{o}\mbox{C}$, but only be accurate to $\mbox{0.001}^{o}\mbox{C}$. Can detect relatively small changes in temperature, smaller than the accuracy of the sensor. Resolution in often controlled by the quantisation in digitising the signal so is not a function of the sensor itself, but of the sampling process. \\
	
	\textbf{{\small Repeatability}}
	
	This is the ability of a sensor to repeat a measurement when put back in the same environment. It is often directly related to accuracy, but a sensor can be inaccurate, yet be repeatable in making observations. \\
	
	\textbf{{\small Drift/Stability}}
	
	This is the low frequency change in a sensor with time, i.e., with a given input you always get the same output. It is often associated with electronic aging of components or reference standards in the sensor. \\
	
	\textbf{{\small Response time}}
	
	A simple estimate of the frequency response of a sensor assuming a change in the measurement. \\
	
	\textbf{{\small Output}}
	
	What output is given for a change in the parameter being measured. For example, a voltage range e.g. 0 to 5 volts for an input range of 0 to $\mbox{30}^{o}\mbox{C}$. \\ 
	
	\textbf{{\small Power Consumption}}
	
	What is needed to power the sensor, quite often specified as the current draw. \\
	
	\textbf{{\small Setting Time}}
	
	After being switched on, how long before a valid measurement is ready. \\
	
	\textbf{{\small Sampling time required}}
	
	How often do we need to repeat measurements to get an accurate picture of the phenomenon being measured. \\

\subsubsection{Communication Protocol for sensor data}

	% Give a small general introduction to the topic
	
	\textbf{SPI}
	
	% SPI - image
	
	\textbf{$\mbox{I}^{2}\mbox{C}$}
	
	% I2C - image

\subsubsection{Methods for accessing external devices}

	Below two methods for accessing an external device will be described. The methods are used to see if there is a change in the state of an external device. \\

	% Polling
	
	\textbf{{\small Polling}}
	
	Polling checks for the change in state in an external device by simply checking if the state of the device has changed in a loop. 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 code 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 and the processor will go back to executing the main code. \\
	
	\textbf{{\small Chosen method}}
	
	For this project interrupts was chosen. This was because the main code will not have to check continuously. In addition to this polling will have a delay when checking if there is a change to the state of an external device since the loop will contain other code which is not responsible for checking the state of the external device.

\subsubsection{Low Power Mode}


\subsubsection{WiFi Activity}\label{subsec:wifi}
	IEEE 802.11 standard describes that WiFi modules has eight operation modes. Monitor mode allows WiFi module capturing WiFi packets that are transmitted around it. These packets can provide information such as source and destination MAC addresses, data rate, SNR and a number of other fields about 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 unique 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 cryptographic key is installed directly into IoT device's ROM, this key is never sent over non-secure media and therefore no need for asymmetric encryption is needed. An unpredictable random nonce is provided by server upon new connection as shown in \autoref{fig:crypto}. It is used as input by chiper which ensures that identical message with different nonce would yield a completely different encrypted data. The same nonce value is then reused inside the cloud again to decrypt a message. Without such mechanism a reply attack is possible. If malicious source capture an encrypted message and resend it to the cloud, it could not 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 very simple and fast algorithm that creates seemingly a random result from provided input. A message can be processed with this algorithm which result attached to the message before sending it. When this message is received, it can be processed again with same algorithm and new result is compared to attached CRC result. If results are different, it indicates that error has happened during transmission. 
	
	\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 our IoT device.
	
\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}

	% We need to talk about why we chose to use these sensors. For example talk about why use an air quality sensor. What information will that give to show if the cafe is busy or not. We need to do this for all the sensors

	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 interrupt routine 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 payload is composed. One second delay before composing the payload is used to give enough time to capture an average WiFi activity. During a small test, while continuously measuring packets it was concluded that one second is sufficient to represent average activity. 
	
	After program enables WiFi monitoring routine, it follows serial and sensor initialisation. Serial block represents UART connection setup which is used for debugging purposes. Sensor checks include connecting them via $I^2C$, retrieving their parameters, 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. 
	
	% I sort of understand this on an abstract level. It will definately be better if more information is added so that the reader understands
	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 deauthentication instruction to WiFi. 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 \\
		&& WiFi Managed packets & 16bit unsigned integer \\
		&& WiFi Control packets & 16bit unsigned integer \\
		&& WiFi 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}. 
	
	% It will be better to expand more on this
	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. 
	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 recieving 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.