+The \verb/Login_Handler/ function is called in the main thread when a HTTP request for authentication is received. This function checks the user's credentials and will give them access to the system if they are valid.
+
+
+Whilst we had originally planned to include only a single username and password, changing client requirements forced us to investigate many alternative authentication methods to cope with multiple users.
+
+Several authentication methods are supported by the server; the method to use can be specified as an argument when the server is started.
+\begin{enumerate}
+ \item {\bf Unix style authentication}
+
+
+ Unix like operating systems store a plain text file (/etc/shadow) of usernames and encrypted passwords. To check a password is valid, it is encrypted and then compared to the stored encrypted password. The actual password is never stored anywhere. The /etc/shadow file must be maintained by shell commands run directly from the beaglebone. Alternatively a web based system to upload a similar file may be created.
+
+ \item {\bf Lightweight Directory Access Protocol (LDAP)}
+
+ LDAP is a widely used data base for storing user information. A central server is required to maintain the LDAP database; programs running on the same network can query the server for authentication purposes.
+
+ The UWA user management system (pheme) employs an LDAP server for storing user information and passwords. The software has been designed so that it can interface with an LDAP server configured similarly to the server on UWA's network. Unfortunately we were unable to gain permission to query this server. However an alternative server could be setup to provide this authentication mechanism for our system.
+
+
+ \item {\bf MySQL Database}
+
+ MySQL is a popular and free database system that is widely used in web applications. The ability to search for a user in a MySQL database and check their encrypted password was added late in the design as an alternative to LDAP. There are several existing online user management systems which interface with a MySQL database, and so it is feasable to employ one of these to maintain a list of users authorised to access the experiment. UserCake is recommended, as it is both minimalistic and open source, so can be modified to suit future requirements.
+
+
+ MySQL and other databases are vulnerable to many different security issues which we did not have sufficient time to fully explore. Care should be taken to ensure that all these issues are addressed before deploying the system.
+
+
+
+\end{enumerate}
+
+\subsection{Safety Mechanisms}
+
+Given the inexperienced nature of the software team, the limited development time, and the unclear specifications, it is not wise to trust safety aspects of the system to software alone. It should also be mentioned that the correct functioning of the system is reliant not only upon the software written during this project, but also the many libraries which are used, and the operating system under which it runs. We found during development that many of the mechanisms for controlling BeagleBone hardware are unreliable and have unresolved issues. We attempted to incorporate safety mechanisms into the software wherever possible.
+
+Sensors and Actuators should define an initialisation and cleanup function. For an actuator (eg: the pressure regulator), the cleanup function must set the actuator to a predefined safe value (in the case of pressure, atmospheric pressure) before it can be deinitialised. In the case of a software error or user defined emergency, the \verb/Fatal/ function can be called from any point in the software; this will lead to the cleanup functions of devices being called, which will in turn lead to the pressure being set to a safe value. The cleanup functions will also be called if the software exits unexpectedly.
+
+Sensors and Actuators are designed to include a \verb/sanity/ function which will check a reading or setting is safe respectively. These checks occur whenever a sensor value is read or an actuator is about to be set. In the case of a sensor reading failing the sanity check, \verb/Fatal/ is called immediately and the software shuts down the experiment. In the case of an actuator being set to an unsafe value the software will simply refuse to set the value.
+
+
+\subsection{Performance}
+
+Figure \ref{} shows the CPU and memory usage of the server program with different numbers of dummy sensor threads. This gives an idea of how well the system would scale if all sensors were run on the same BeagleBone.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\textwidth]{figures/server_overview.png}
+ \caption{Server overview}
+ \label{server_overview.png}
+\end{figure}
+
+
+\pagebreak
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.1\textwidth]{figures/sensor_thread.pdf}
+ \caption{Flow chart for a sensor thread}
+ \label{sensor_thread.pdf}
+\end{figure}
+\pagebreak
+\pagebreak
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.1\textwidth]{figures/actuator_thread.pdf}
+ \caption{Flow chart for an actuator thread}
+ \label{actuator_thread.pdf}
+\end{figure}
+\pagebreak