summaryrefslogtreecommitdiffstats
path: root/notFinishedCode/Report/test.tex.backup
diff options
context:
space:
mode:
authorRefik Hadzialic2011-10-23 14:02:56 +0200
committerRefik Hadzialic2011-10-23 14:02:56 +0200
commit5cfee1ed8aa603c956793f29a41c87e85892ceff (patch)
tree1f2c6d2eb46f192e97932cc6831f0d5e58a9cfc6 /notFinishedCode/Report/test.tex.backup
parentReport writing (diff)
downloadgsm-selftest-5cfee1ed8aa603c956793f29a41c87e85892ceff.tar.gz
gsm-selftest-5cfee1ed8aa603c956793f29a41c87e85892ceff.tar.xz
gsm-selftest-5cfee1ed8aa603c956793f29a41c87e85892ceff.zip
Report writing
Diffstat (limited to 'notFinishedCode/Report/test.tex.backup')
-rw-r--r--notFinishedCode/Report/test.tex.backup38
1 files changed, 32 insertions, 6 deletions
diff --git a/notFinishedCode/Report/test.tex.backup b/notFinishedCode/Report/test.tex.backup
index a872c59..e3068a8 100644
--- a/notFinishedCode/Report/test.tex.backup
+++ b/notFinishedCode/Report/test.tex.backup
@@ -188,6 +188,22 @@ However, all the test tasks even after deleting them from \emph{TempTaskTable} a
\newpage
\section{Software design} % section 2.1
+Software design was the next step after we analyzed the problem and developed a plan how to proceed further. Good analysis and planning with poor algorithmic implementation is valueless.
+During the work on the project, we had spent most of our time for software design.
+We kept in mind that our software should satisfy major paradigms of software engineering,
+like compatibility, extensibility, maintability, modularity, relliability, security, fault-tolerance and usability.
+The software engineering design concepts were achieved following way:
+\begin{itemize}
+\item Compatibility - we used Python and MySQL which are multiplatform and work on major OS
+\item Extensibility - new parts of code can be easily added by just modifying the classes
+\item Maintability - the test software can recognize new added cell phones to the system and dynamically
+\item Mudalarity - the components are independent black boxes, they are tested and validated independently
+\item Reliability - we use mutex locks to perform tests and database transaction operations to insert data into the database
+\item Security - all communication channels are encrypted with asymmetric key cryptography
+\item Fault-tolerance - the classes were designed to continue operating even if error events appear and handlers are logging everything
+\end{itemize}
+
+
\begin{figure}[ht!]
\centering
\includegraphics[width=140mm]{activityControllerEdited.png}
@@ -297,7 +313,13 @@ At the start we did not have a cable supplied for the Siemens S55 phone. We cont
\subsection{Cables for the cell phones}
Due to the fact that we had used 5 cell phones on a single computer, the best solution was to order 5 USB cables.
-Konrad bought 5 cables for 5 Siemens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them.
+Konrad bought 5 cables for 5 Sie\begin{itemize}
+\item Triangles represent BTS stations
+\item Cellphones represent the external networks (E-Plus, Vodaphone, T-Mobile and O2)
+\item Telephone represents the landline and a telephone with a mortarboard the University telephone network
+\item Servers represent the OpenBSC and LsfKs-Asterisk
+\item Two monitors represent the SIP system
+\end{itemize} mens S55 cell phones. All of the cables have an USB2Serial chip converter inside of them.
Once they were plugged into the USB port, Ubuntu automatically recognized the cables and installed the drivers.
The virtual serial ports were created and could be found on \emph{/dev/ttyUSBx}, where $x$ is the automatically assigned number for the port.
Some of the cables had the capability to charge the Siemens S55 phones.
@@ -311,7 +333,9 @@ A communication protocol represents a set of well defined rules by whose help tw
When defining these rules, it is important to define a limited state space for every possible event, no matter did we get the appropriate
response from the other side. Our approch to this problem was to build a simple synchronous protocol, where every expected message is
confirmed or otherwise the connection between two sides is immediatelly terminated. Since designing protocols is a demanding and challenging
-topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum protocol.
+topic which requires years of experience and verification, we do not expect that we had developed the best possible and an optimum
+protocol\footnote{Design concepts and paradigms for the protocol design have been used from the
+``Network Protocol Design and Evaluation'' course, lectured by Dr. Stefan R\"{u}hrup}.
In the following paragraphs we will try to clarify how our protocol works. Before we start to go into detail how the protocol works,
it is important to remember that we differentiate two sides, handler and the controller side. The handler side represent the device
that physically handles the call (e.g. the BeagleBoard) whereas the controller (i.e. the main test software), is the test software
@@ -340,25 +364,27 @@ established a physical connection with the other handler, or of the form \emph{C
not successfully established on the given handler. The controller considers only a test successful if both handlers report
with \emph{CALL OK}. The test software ends the established connection with the handlers by sending them the \emph{TERMINATE CONNECTION}
command. After the handlers have terminated the connection, they enter the waiting for a new connection state and the process starts
-from begining again.
+from begining again. If the states are not entered in the specified order the connection is immediatelly terminated and
+the state machine is in the waiting for a new connection state\footnote{It cannot be seen in the protocol flowchart but one should
+keep in mind it works like a well defined state machine.}.
\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{protocolCommunicationHandler.png}
- \caption[]{Flowchart of the protocol, on the handler side}
+ \caption[]{Flowchart of the protocol on the handler side without the state representation}
\end{figure}
\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{protocolCommunicationcControllerReceiver.png}
- \caption[]{Flowchart of the protocol, on the controller side for the caller}
+ \caption[]{Flowchart of the protocol on the controller side for the caller without the state representation}
\end{figure}
\begin{figure}[ht!]
\centering
\includegraphics[width=130mm]{protocolCommunicationcControllerCaller.png}
- \caption[]{Flowchart of the protocol, on the controller side for the receiver}
+ \caption[]{Flowchart of the protocol on the controller side for the receiver without the state representation}
\end{figure}
\subsection{Verification of the protocol}