% !TeX root = main.tex
\iffalse
# It is impossible to optimise all system parameter values concurrently.
# Trade-offs $quantify$ the benefits a designer would gain in optimising one 
performance metric at the expense of degrading a different performance metric.

Have you considered $and quantified$ the cost (you will incur) versus the gain 
(you will obtain) when you modify different parameters in your system? For example:
* Local vs. Cloud processing.
* Range vs. Power consumption (battery life).
* Throughout vs. Power consumption.
* Latency /Delay vs. Accuracy.
* Performance vs. Security.
* Generic vs. Bespoke hardware.
* Price vs. Functionality.
* Price vs. Usability.
* Price vs. Robustness / Reliability.
* Functionality vs. Usability.
* Functionality vs. Rapid development (time to market).
* Functionality vs. Backward compatibility.
\fi

\section{Engineering Trade-offs}
This section will discuss what and why certain characteristics and performance metrics were prioritized in our system at the expense of other factors. 

\subsection{Sensor selection}
In the case of sensors to measure each factor that composes ambience, different sensor options were taken into consideration. This section will, therefore, justify the choices made for the sensors used for the Coffee Time device.

\subsubsection{Temperature and Humidity}
A simple thermistor was not used as humidity sensor is also required and most of the module solutions have integrated both sensors. Three $I^2C$ modules were considered: \texttt{HTU21D}, \texttt{Si7021} and \texttt{HDC2080} as these were the only modules that meet requirements and were available from the supplier. All of the modules have a similar accuracy of $\pm2-3\%$ for relative humidity and $\pm 0.2-0.4~^\circ C$. All sensors had relatively similar sleep current however, different measuring current and time as shown in \autoref{tab:temp_power}. \texttt{HDC2080} was chosen due to the lowest measuring time which means it's the most power-efficient and does not delay microprocessor as long further saving energy.

\begin{center}
	\begin{tabular}{c|c|c|c|c|c}
		\multirow{2}{*}{Sensor}	& \multicolumn{2}{c|}{Sleep Current} & \multicolumn{2}{c|}{Measuring Current} & Measuring Time \\\cline{2-6}
					& Typ. & Max & Typ. & Max & Typ. \\
		\hline
		HDC2080 & 50 nA	& 100 nA 	& 550$\mu A$ & 730$\mu A$ & 1.27ms \\
		Si7021  & 60 nA & 62 nA 	& 150$\mu A$ & 180$\mu A$ & 28ms \\
		HTU21D  & 20 nA & 140 nA 	& 450$\mu A$ & 500$\mu A$ & 58ms \\
		BME280  & 100 nA & 300 nA 	& 350$\mu A$ & 370$\mu A$ & 8ms \\
	\end{tabular}
	\captionof{table}{Power consumption of temperature and humidity sensors \autocite{HDC2080,SI7021,HTU21D,BME280}.}
	\label{tab:temp_power}
\end{center}

Unfortunately, after system setup, \texttt{HDC2080} sensor failed to respond and a new replacement sensor was needed. Because of slow delivery services and due to availability from an alternative supplier and relatively good specification, \texttt{BME280} was chosen, which in addition included atmospheric pressure readings which were recorded but not used for analysis as they were irrelevant. Therefore, to meet the deadline, the lowest measuring time in the sensor was sacrificed. 

\subsubsection{Air Quality}
For air quality, three sensors where considered, \texttt{MQ135}, \texttt{SGP30} and \texttt{CCS811}. \texttt{MQ135} lacked $I^2C$ interface, had poor efficiency and required an additional circuit to control heater \autocite{MQ135}. \texttt{CCS811} had 1.2mW average power draw measuring once every 60 seconds, whereas \texttt{SGP30} took 6.5mW at minimum which is significantly more. \texttt{SGP30} had a higher maximum measurement range of up to 60000ppm $CO_2$ and 60000ppb TVOC comparing to 8192ppm and 1187ppb that \texttt{CCS811} can provide \autocite{SGP30,CCS811}. \texttt{SGP30} was selected due supplier unavailability to provide \texttt{CCS811} sensor.

\subsection{Cryptography Choice}
A number of different cryptography algorithms have been considered. Arduino library repository provides a library with most of chryptographic algorithm implemented including their benchmarks. Results are shown in \autoref{tab:crypto}. Used ESP8266 does not have most commonly used AES hardware acceleration therefore this table should be relevant even when it was produced using much less capable AVR processor. Software implemented AES is outperformed by ChaCha and Speck, the best result showing Speck with ECB mode. However, as ECB mode lacks of diffusion ChaCha20 was chosen instead. 20 over 12 round ChaCha was selected due to a relatively low time penalty over a much higher system lifetime despite losing sleep time by talking to the microprocessor. 
\begin{center}
	\begin{tabular}{c|c|c}
		Algorithm & Encryption time per byte & Key Setup \\
		\hline
		AES192 ECB 	& 39.94$\mu s$ 		& 165.34$\mu s$ \\
		AES256 ECB 	& 46.61$\mu s$ 		& 217.79$\mu s$ \\
		AES192 GCM 	& 116.38$\mu s$ 	& 1485.56$\mu s$ \\
		AES256 GCM 	& 123.04$\mu s$ 	& 1760.28$\mu s$ \\
		ChaCha12 	& 10.38$\mu s$ 		& 43.74$\mu s$ \\
		ChaCha20 	& 14.87$\mu s$ 		& 43.74$\mu s$ \\
		ChaChaPoly  & 41.20$\mu s$ 		& 902.36$\mu s$ \\
		Speck 192 ECB	& 10.03$\mu s$ 	& 264.63$\mu s$ \\
		Speck 256 ECB	& 10.31$\mu s$ 	& 275.26$\mu s$ \\
		Speck 256 GCM	& 86.74$\mu s$ 	& 646.88$\mu s$ \\
		
	\end{tabular}
	\captionof{table}{Benchark result for various encryption algorithms perfromed on Atmel ATmega328P microprocessor at 16MHz  \autocite{cryptolib}.}
	\label{tab:crypto}
\end{center}

\subsection{Cloud computing}
In this section a local versus cloud computing is discussed. The only processing that is done locally on microcontroller is absolute humidity calculation as it not a complicated function. Data analysis could possibly be done directly on microcontroller, however that would require being implemented on low level code which is expensive. In addition, as gather data is quite small in size, it has little benefit on processing data locally.
However, if computer vision would be used with a more powerful microprocessor, such as ARM, a local processing would much more suitable solution due to high bandwidth requirement for video streaming. It would be a trade-off of accessible bandwidth and local IoT device price. Another trade-off would need to be considered between price of microprocessor power consumption as newer processors consume less power but are more expensive; and battery size.

\subsection{Wireless Power consumption}
This section will go over trade-offs of wireless power consumption versus range and throughput.

As data sent to server requires very low bandwidth, two other options were considered to be used for data transmission: Bluetooth LE and LoRaWAN. Both methods would consume significantly less power as both transmission requires less energy; and it takes less time to establish connection and transmit data. Bluetooth has a negative side of requiring nearby local gateway that would connect IoT device to the cloud. This defeats the purpose of IoT device and one of such gateways would need to be placed in every café eliminating the need of IoT device itself. Same argument applies to ZigBee or other low range wireless communication. LoRaWAN was strongly considered as a candidate as it would eliminate the need of existing local WiFi infrastructure as there might be difficulties getting WiFi access for an IoT device. In addition a single LoRa gateway could serve numerous cafés in 2-3km radius, assuming urban environment. The choice of not using LoRa was made due to WiFi capabilities required to be present to measure WiFi activity, therefore another communication method is redundant and just increase expenses. 
