As with the hardware components, again, starting with the server node, the board should work alongside the \textbf{OpenWRT}\gls{os}, again, described in a deeper detail in the sub-chapter \ref{ss:openwrt}. It allows for relatively easily configurable network connections\cite{rosen2013linux} and the web-server.
The web-server should be handled by some package already available for installation into the OpenWRT distribution. There are various choices. Ordered in an ascending order by their complexity, the most common ones are: \texttt{uhttpd}, \texttt{lighttpd}, \texttt{Apache} and \texttt{nginx}. The resource requirements are proportional to the complexity, and since GL.inet is not an extremely powerful machine, the choice should fall on the more lightweight one from the beginning of the list, with just as many features as absolutely necessary\cite{adelstein2007linux}. The \texttt{lighttpd} was chosen for this task after some research, as it is the best fit for the given criteria.
As far as a choice for the web interface programming/scripting language goes, there are three rather good choices: \texttt{Python}, \texttt{PHP} and \texttt{Lua}. There is no exact way to choose - it all depends on the confidence and the efficiency of the implementer, which one fits the best. Any available language will do. However, it should be noted, that \texttt{Lua}, is somewhat superior choice, since two influential software solutions for the proposed system are written in it. On the side of the OpenWRT, we are speaking about the web configuration interface called \texttt{LuCi}\cite{weidner2013linux}, while \texttt{NodeMCU}\cite{kurniawannodemcu} is a \texttt{Lua} eco-system based on ESP-8266. Both solutions are relatively mature and open-source and can be referenced easily. However, the \texttt{PHP} language was chosen, because it is the easiest way to develop the required functionality in it.
Another choice lies in the way of storing the measured data on the server. For a local storage, one can either use plain text format for very simple data, or a data-base of some sort, preferably a \gls{rdbms}\cite{sumathi2007fundamentals}. If a data-base is to be chosen, the \texttt{SQLite}\cite{allen2011definitive} is a good choice - it was already noted, that the computational resources are at premium. Everything marketed as lightweight has an edge here. For a remote storage, there is a plethora of cloud-based solutions, ready to employ and use, so this is a very good choice, if an internet connection is available. Because there is nothing preventing us from using the Internet connection in the design, the cloud storage is chosen as a primary one and \texttt{SQLite} in stored in a local memory is used only as a backup, in case the connection cannot be established.
Another choice lies in the way of storing the measured data on the server. For a local storage, one can either use plain text format for very simple data, or a data-base of some sort, preferably a \gls{rdbms}\cite{sumathi2007fundamentals}. If a data-base is to be chosen, the \texttt{SQLite}\cite{allen2011definitive} is a good choice - it was already noted, that the computational resources are at premium. Everything marketed as lightweight has an edge here. For a remote storage, there is a plethora of cloud-based solutions, ready to employ and use, so this is a very good choice, if an internet connection is available. Because there is nothing preventing us from using the Internet connection in the design, the cloud storage for a data stream named \texttt{phant.io}is chosen as a primary one and \texttt{SQLite} in stored in a local memory is used only as a backup, in case the connection cannot be established.
On a client side of a proposed system, there are again three main language options. The first one is the already mentioned \texttt{Lua}. This language is simple, yet not terribly popular. The availability of the design resources might be limited. Second one is the ruler of the micro-controller world\cite{van2001programming}, plain \texttt{C}, suited for more experienced programmer, but providing the highest flexibility. The third choice is to use \texttt{C++} based eco-system, derived from \Gls{arduino}. This choice is far more superior, because it provides access to enormous resources and libraries\cite{seneviratne2015internet} readily available on the Internet with and addition to (mostly) cross-compatible code, which is a nice bonus. This option has been chosen, because it is, again, the easiest way to accomplish the task.
%
%\subsection{External components}
%One entity, that was already mentioned, but still not depicted in the design considerations is the \gls{usb} storage. It requires both \gls{hw} and \gls{sw} to work, and is externally connected to the server node.
%
%Should the \gls{usb} storage be applied for a local data storage capability, in case when the server node cannot connect to the internet for a cloud upload and available non-volatile local memory is depleted, either a \Gls{flash} stick or an external \gls{hdd} should be used. Both require additional \gls{kernel} modules to work, in addition to the \gls{daemon}, that will handle the mounting process. In case of the \gls{hdd}, the capable power supply is needed to power both GL.inet board and the \gls{hdd} at the same time.
\caption{The block diagram of a data flow in the proposed software architecture, including a client node, a server node, the cloud storage for measurements and an external \gls{ddns} server for providing the \gls{ip} of the server to the client nodes}\label{f:sw_architecture}
\end{figure}
One of the \gls{sw} requirements is to provide the ability to add another measuring nodes without modifications of the existing infra-structure. As it is common in a \gls{sw} world, there are again multiple solution to do this. Since there are so many ways, only the two most viable ones are described. The first is to use automatic configuration sequence, that would be initialized from the server node to communicate to freshly booted up client node. This would work without the Internet connection, but would require additional actions on the side of the user. Another way is to use external \gls{ddns} server to provide the \gls{ip} of the server to the clients. Since it is a centralised resource, all clients get updated simultaneously. It also provides outside of \gls{nat} (local network) access to the server node, which is one of the optional requirements. Since the cloud storage has been already chosen as a primary storage, which requires the Internet connection, external \gls{ddns} server has been chosen for this task. Additional positive side-effect of this choice is, that entire process is invisible to the user, thus simpler to use.
All the mentioned SW components are included in a block diagram \ref{f:sw_architecture}. The arrows help indicate which way the data are flowing around the the system, to get the better idea.
Peter Babič
8 years ago