You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
122 lines
12 KiB
122 lines
12 KiB
\section{Requirements}
|
|
The device under test will be referred to as \textbf{appliance}. The requirements for the final \textbf{measuring device} are grouped to the three categories. Mandatory requirements are bound to be met at any cost. Some of the high importance requirements can be skipped or slightly modified, if unpredictable obstacles are found. However, they are all assumed to be completed for well being of the project. Optional requirements will be completed only if the resources allow it.
|
|
|
|
They are also divided to a hardware part and software part. Software is easier to change than hardware and requires hardware to be run on. Software is also limited by the resources provided by the hardware. Therefore, hardware needs to be logically completed first and are also highlighted in figures \ref{f:client_node} and \ref{f:serv_node}.
|
|
|
|
|
|
\subsection{Hardware requirements}
|
|
|
|
\renewcommand{\theenumi}{\Alph{enumi}}
|
|
\textbf{Mandatory:}
|
|
\begin{enumerate}
|
|
\item Measure current, voltage and phase angle simultaneously to calculate the real power and the power factor
|
|
\item More measuring devices can be added to the system by user without \gls{hw} or \gls{sw} modifications
|
|
\item Devices under test run at nominal 230 V, 50 Hz that use two-way or three-way EU plug
|
|
\item Protection against the electrical shock, fire hazard and damage caused by power surges
|
|
\end{enumerate}
|
|
|
|
\textbf{High importance:}
|
|
\begin{enumerate}[resume]
|
|
\item Store the measured data in server's node available non-volatile local \gls{memory}
|
|
\item Completely shut the appliance off or back on
|
|
\item Indicate that the measuring device is active (configured and working) with a \gls{led}
|
|
\item Handle maximum of 8 A currents drawn by the appliance
|
|
\end{enumerate}
|
|
|
|
\textbf{Optional:}
|
|
\begin{enumerate}[resume]
|
|
\item Store the measured data on an \gls{usb} flash disk
|
|
\item Provide \gls{hw} support for some crossed support signalisation (i.e. by sound)
|
|
\item Internet and Ethernet connection on server node
|
|
\end{enumerate}
|
|
|
|
\begin{figure}[ht]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{client_node_diag}
|
|
\caption{The proposed block diagram of a \textit{client node}, including HW requirements}\label{f:client_node}
|
|
\end{figure}
|
|
|
|
|
|
\subsection{Software requirements}
|
|
\textbf{Mandatory:}
|
|
\begin{itemize}
|
|
\item The \gls{gui} running on the web-server
|
|
\item Add, edit (configure) and remove measuring devices to/from the system
|
|
\item Present the instantaneous (real) power consumed for each appliance
|
|
\end{itemize}
|
|
|
|
\textbf{High importance:}
|
|
\begin{itemize}
|
|
\item Graphs of all measured quantities over time
|
|
\item Authentication mechanism
|
|
\item Automatic configuration of the new connected measuring devices
|
|
\end{itemize}
|
|
|
|
\textbf{Optional:}
|
|
\begin{itemize}
|
|
\item Access to \gls{gui} outside of local network
|
|
\item Control Wi-Fi repeater mode to strengthen the signal for client nodes
|
|
\item Send measured data to the cloud storage
|
|
\item Separate administrator (view and change) and user (view only) privileges
|
|
\item Ability to set thresholds for measured data and notify user about crossing them via text based message
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{server_node_diag}
|
|
\caption{The proposed block diagram of a \textit{server node}, including HW requirements}\label{f:serv_node}
|
|
\end{figure}
|
|
|
|
|
|
\clearpage
|
|
\section{System design}
|
|
|
|
The first mandatory software requirement asks for a web server. It is entirely possible for every measuring device to contain its own web server. However, multiple points are requiring separate parts to work as a \textbf{system}. Two common system structures are \textit{centralised} and \textit{decentralised}.
|
|
Decentralised (peer-to-peer) systems\cite{vu2009peer} are harder to build but are more fail-proof. Since fail-proofness is not mentioned in the requirements, centralised system might suffice.
|
|
|
|
Using centralised system means, that the measuring devices will use one separate accessory, from now called the \textbf{server node}, to do most of the work on the software side. The work includes, but is not limited to, receiving the measured data, storing them, hosting the web server with the \gls{gui} containing all necessary options and information, handling the \gls{usb} or communication with a \gls{cloud} and so on. The block diagram for a server node, depicting required blocks can be seen in the figure \ref{f:serv_node})
|
|
|
|
Where there are at least two nodes in a system, they have to communicate together in a particular way, known to both of them. The web server naturally operates over \gls{tcpip}. Therefore, same networking stack (the way of comunication), that is used for communication between the server node and user can be used to communicate to client nodes as well. \Gls{tcpip} hardware is ready to be used and is supporting a full-blown networking \gls{stack}, powering communication over today's networks.
|
|
|
|
The measuring devices, from now on called \textbf{client nodes}, will consist of blocks of the remaining hardware requirements. The resulting block diagram can be seen in the figure \ref{f:client_node})
|
|
|
|
|
|
\subsection{Hardware components breakdown}
|
|
For the \textbf{server node}, a complete working solution already exists, ready to be employed. The \textbf{GL.inet board}, described in more detail in the chapter \ref{s:glinet}, is greatly sufficient in all required aspects, and thus should be used for this purpose.
|
|
|
|
Luckily, a particular part of the required functionality for the client is already integrated as a \textbf{ESP-8266 module}, described in more detail in the chapter \ref{s:esp8266}. The module contains the \gls{tcpip} stack, micro-controller (application processor) running the user program, \gls{wlan} and light indication, all in one piece, so this greatly simplifies the design process and allows for more focus on the actual measurement circuitry. The actual ESP-12E module should be used, because of the available certification\cite{online:2ADUIESP-12}, which allows it to be introduced on the market later. It was shown in the figure \ref{f:esp-12e}. The \gls{pwm} is present there too, so sound indication requires just an additional sound emitting device.
|
|
|
|
Talking about the measurement circuitry, the viable candidate is MAX78615 \cite{online:MAX78615} with the companion \gls{ic} MAX78700 \cite{online:MAX78700}. The couple \ref{f:schem_block} should be used, because it provides multiple ways of same voltage level communication with the processor, galvanic isolation via the pulse transformer for improved circuitry protection, great precision, accuracy and utility. The shunt resistor is utilised as a way of obtaining measurements, described in the sub-chapter \ref{ss:pmic}.
|
|
|
|
\begin{figure}[ht!]
|
|
\centering
|
|
\includegraphics[width=.7\textwidth,angle=0]{schematic_block}
|
|
\caption{The proposed block diagram of a schematic of a \textit{client node} focusing on measuring part of the circuit}\label{f:schem_block}
|
|
\end{figure}
|
|
|
|
For the protection against fire a standard electric fuse or a resettable \gls{ptc} fuse\cite{wright2004electric} should be used. The circuit protection against high voltage should be solved with an isolated DC-to-DC converter\cite{carr1996linear} or with the linear transformer coupled with the linear voltage regulator\cite{2008linear}. Since the former one is either expensive or hard to design, the choice should fall on the latter.
|
|
|
|
The remaining part of the client node block diagram \ref{f:client_node} not yet mentioned is switching. Either a mechanical relay or a semiconductor device, such as a thyristor or a \gls{ssr} isolated by an opto-coupler\cite{trzynadlowski2015introduction} will do. Mechanical relays tend to be larger and produce sound noise, have slow response time, but have inbuilt separate isolation and are capable of switching higher currents without additional thermal issues than their semiconductor counterparts\cite{blume2008electric}. The disadvantages of the mechanical relay are not relevant here, thus the choice is obvious.
|
|
|
|
|
|
\subsection{Software components breakdown}
|
|
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}.
|
|
|
|
As far as a choice for the 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 solution are relatively mature and open-source, so the programmer can refer to them easily.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
|