requirements reworked again, added block diagrams

master
Peter Babič 9 years ago
parent 73aac99fb3
commit 72c85b43c9
  1. 85
      analytical.tex
  2. BIN
      figures/client_node_diag.odg
  3. BIN
      figures/client_node_diag.pdf
  4. BIN
      figures/server_node_diag.odg
  5. BIN
      figures/server_node_diag.pdf
  6. 10
      glossaries.tex
  7. 2
      problemexpres.tex
  8. BIN
      tukethesis.pdf
  9. 6
      tukethesis.tex

@ -1,53 +1,85 @@
\section{Requirements}
The requirements for the final 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 unreasonable obstacles are found. However, they are all assumed to be completed for well being of the project. Optional requirements will be completed only if possible, given the resources will 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.
\subsection{Hardware requirements}
\renewcommand{\theenumi}{\Alph{enumi}}
\textbf{Mandatory:}
\begin{itemize}
\item Incorporate enough hardware components to measure current, voltage and phase angle simultaneously to calculate the real power
\item Make the system scalable in the means of number of measured devices
\item Make sure the device is compatible with European powerline grid system as well as with the European mains plug connector
\item Provide suitable enclosures for a protection against the electrical shock
\end{itemize}
\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 physically to the system later
\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{itemize}
\item Store the measured data for a further analysis
\item Provide a way to switch off/on the appliance under measurement by the device
\item Include one or more \gls{led} to indicate status and/or activity to the observing user
\item Make sure the device is capable of handling at least 16 A currents at nominal voltage of 230 V, to match the common safety circuit-breakers
\end{itemize}
\begin{enumerate}[resume]
\item Store the measured data for a minimum of one week
\item Completely shut the device under test off or back on
\item Indicate that the device is active (configured and working) with a \gls{led}
\item Handle maximum of 16 A currents drawn by the device under test
\end{enumerate}
\textbf{Optional:}
\begin{itemize}
\item Store the measured data for a further analysis \textit{on an USB flash disk}
\item Equip a device with a sound signalization of a crossed threshold
\end{itemize}
\begin{enumerate}[resume]
\item Store the measured data on an \gls{usb} flash disk
\item Signalize some crossed threshold using sound
\item Ethernet connection
\end{enumerate}
\newpage
\subsection{Software requirements}
\textbf{Mandatory:}
\begin{itemize}
\item Configure and run a web-server where the \gls{gui} will be held
\item Provide a way to present the instantaneous (real) power consumed
\item The \gls{gui} running on the web-server
\item Add, edit (configure) and remove measurement devices to/from the system
\item Present the instantaneous (real) power consumed for each device under test
\end{itemize}
\textbf{High importance:}
\begin{itemize}
\item Make the presented measurements available as graphs of all measured quantities over time
\item Incorporate an authentication mechanism
\item If multiple multiple devices exist in the same household, make sure, that they can automatically identify among themselves
\item Graphs of all measured quantities over time
\item Authentication mechanism
\item Automatic configuration of the new connected measurement devices
\end{itemize}
\textbf{Optional:}
\begin{itemize}
\item Provide a way to switch off/on the appliance under measurement by the user \textit{remotely} (outside of \gls{lan})
\item Include a possibility in a \gls{gui} to set a threshold for a consumed (real) power
\item If possible, configure provided device as a wi-fi repeater
\item Provide at least two separate levels of privileges (admin, user, \dots)
\item Access to \gls{gui} outside of local network
\item Fully functional wi-fi repeater included
\item Send measured data to the cloud
\item Separate administrator (view and change) and user (view only) privileges
\end{itemize}
\subsection{System description}
\begin{figure}[ht!]
\centering
\includegraphics[width=.75\textwidth,angle=0]{server_node_diag}
\caption{The block diagram of a \textit{server} node of a proposed system, including hardware requirements}\label{f:serv_node}
\end{figure}
The first mandatory software requirement asks for a web server. It is entirely possible for every measurement device to contain its own web server. However, multiple points are requiring devices to work as a \textbf{system}. Two common system structures are \textit{centralised} and \textit{decentralised}.
Decentralised (peer-to-peer) systems 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 measurement devices will use one separate device, 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.
\begin{figure}[ht!]
\centering
\includegraphics[width=.75\textwidth,angle=0]{client_node_diag}
\caption{The block diagram of a \textit{client} node of a proposed system, including hardware requirements}\label{f:client_node}
\end{figure}
The measurement 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})
%The centralised system proposal appears to be more economical, than a decentralised system, which would require a separate copy of hardware for doing all the things for every client node, plus some clever way for communication between them.
%\item Split the device to the server (separate GL-inet router running a web-server, data processing and data storage) and to measurement nodes (electronics powered by an ESP8266 wi-fi module) to create a unique, replicable and efficient solution
%\item If reasonably accurate, use the inbuilt \gls{adc} of the ESP8266 for the voltage measurement in combination with a linear transformer (the transformer also powers the entire node)
%\item Use hall-effect sensor for a current measurement
@ -55,3 +87,4 @@ The requirements for the final device are grouped to the three categories. Manda
%\item Include advanced configuration options (\gls{pwm} for lighting appliances or or periodic turn on/off function)
%\item Make the web-server accessible remotely via \gls{ddsn} service
%\item Make the server automatically discover all nodes and configure them

BIN
figures/client_node_diag.odg (Stored with Git LFS)

Binary file not shown.

BIN
figures/client_node_diag.pdf (Stored with Git LFS)

Binary file not shown.

BIN
figures/server_node_diag.odg (Stored with Git LFS)

Binary file not shown.

BIN
figures/server_node_diag.pdf (Stored with Git LFS)

Binary file not shown.

@ -59,6 +59,8 @@
\newacronym{ac}{AC}{Alternating Current}
\newacronym{dc}{DC}{Direct Current}
\newacronym{rms}{RMS}{Root-mean square}
\newacronym{tcp}{TCP}{Transmission Control Protocol}
\newacronym{tcpip}{TCP/IP}{\acrlong{tcp}/\acrlong{ip}}
\newglossaryentry{ethernet}{
@ -159,3 +161,11 @@
name=current,
description={(electric) is the flow of charged particles through a conducting medium}
}
\newglossaryentry{stack}{
name=stack,
description={(protocol) is an implementation of a computer networking protocol suite, used interchangeably}
}
\newglossaryentry{cloud}{
name=cloud,
description={(computing) is a model for enabling ubiquitous, convenient, on-demand access to a shared pool of configurable computing resources}
}

@ -265,7 +265,7 @@ The Atheros AR9331 is a highly integrated and cost effective \gls{ieee} 802.11n
\begin{figure}[ht!]
\centering
\includegraphics[width=.8\textwidth,angle=0]{AR9331_block}
\includegraphics[width=.9\textwidth,angle=0]{AR9331_block}
\caption{The block diagram of the Atheros AR9331 \gls{soc} used as a main processing unit on GL.inet board}\label{f:ar_block}
\end{figure}

BIN
tukethesis.pdf (Stored with Git LFS)

Binary file not shown.

@ -46,9 +46,9 @@
\titlespacing*{\section} {0pt}{0cm}{0cm}
\titlespacing*{\subsection} {0pt}{-.15cm}{-.15cm}
\linespread{1.3}
\let\tempone\itemize
\let\temptwo\enditemize
\renewenvironment{itemize}{\tempone\addtolength{\itemsep}{-.3\baselineskip}}{\temptwo}
\usepackage{enumitem}
\setlist[itemize]{itemsep=-.3\baselineskip}
\setlist[enumerate]{itemsep=-.3\baselineskip}
% prevent breaking \item b/w pages
\usepackage{needspace}
\let\svitem\item

Loading…
Cancel
Save