process the rest of george's comments
[msc-thesis1617.git] / results.arch.tex
index f9b6725..e276010 100644 (file)
@@ -65,7 +65,7 @@ the device software.
 \end{itemize}
 
 \section{Specification}
-The servers stores a description for every device available in a record type
+The server stores a description for every device available in a record type
 which are stored in a \gls{SDS}. From the macro settings in
 the interface file, a profile is created for the device that describes the
 specification. When a connection between the server and a client is established
@@ -90,17 +90,17 @@ a list of \CI{MTaskDevice}s. The exact specification is defined as in
 Listing~\ref{lst:mtaskdevice} with the accompanying classes and types.
 
 The \CI{deviceResource} component of the record must implement the
-\CI{MTaskDuplex} interface that provides a function that launches a task used
-for synchronizing the channels.  The \CI{deviceTask} stores the \gls{Task}-id
-for this \gls{Task} when active so that it can be checked upon. This top-level
-task has the duty to report thrown exceptions and occuring errors by setting
-the \CI{deviceError} field.  All communication goes via these channels. If the
-system wants to send a message to the device it just puts it in the channels.
-Messages sent from the client to the server are also placed in there. In the
-case of the \gls{TCP} device type the \gls{Task} is just a simple wrapper
-around the existing \CI{tcpconnect} function in \gls{iTasks}. In case of a
-device connected by a serial connection it uses the newly developed serial port
-library of \gls{Clean}\footnote{\url{%
+\CI{MTaskDuplex} interface that provides a function that launches a \gls{Task}
+used for synchronizing the channels.  The \CI{deviceTask} stores the
+\gls{Task}-id for this \gls{Task} when active so that it can be checked upon.
+This top-level task has the duty to report exceptions and errors as they are
+thrown by setting the \CI{deviceError} field. All communication goes via these
+channels. If the system wants to send a message to the device, it just puts it
+in the channels.  Messages sent from the client to the server are also placed
+in there. In the case of the \gls{TCP} device type, the \gls{Task} is just a
+simple wrapper around the existing \CI{tcpconnect} function in \gls{iTasks}. In
+case of a device connected by a serial connection, it uses the newly developed
+serial port library of \gls{Clean}\footnote{\url{%
 https://gitlab.science.ru.nl/mlubbers/CleanSerial}}.
 
 Besides all the communication information, the record also keeps track of the
@@ -207,8 +207,8 @@ function and the record is updated accordingly.
 \subsection{\glspl{Task} \& \glspl{SDS}}
 When a \gls{Task} is sent to the device it is added to the device record
 without an identifier. The actual identifier is added to the record when the
-acknowledgement of the task by the device is received. The connection diagram
-is shown in Figure~\ref{fig:tasksend}.
+acknowledgement of the \gls{Task} by the device is received. The connection
+diagram is shown in Figure~\ref{fig:tasksend}.
 
 \begin{figure}[H]
        \centering
@@ -223,17 +223,18 @@ is shown in Figure~\ref{fig:tasksend}.
        \caption{Sending a \gls{Task} to a device}\label{fig:tasksend}
 \end{figure}
 
-The function for sending a task to the device is shown in
-Listing~\ref{lst:sendtask}. First the task is compiled into messages. The
+The function for sending a \gls{Task} to the device is shown in
+Listing~\ref{lst:sendtask}. First the \gls{Task} is compiled into messages. The
 details of the compilation process are given in Section~\ref{sec:compiler}.
-The new shares that were made during compilation are added to the deviceshares
-that were made during the compilation are merged with the existing shares on
-the device. Furthermore the messages are placed in the channel share of the
-device. This will result in sending the actual \gls{SDS} specification and
-\gls{Task} specifications to the device. A \gls{Task} record is created with
-the identifier $-1$ to denote a \gls{Task} not yet acknowledged. Finally the
-device itself is updated with the new state and with the new \gls{Task}. When
-the device returns an acknowledgement the \gls{Task} is updated accordingly.
+The new \glspl{SDS} that were made during compilation are added to the
+deviceshares that were made during the compilation are merged with the existing
+shares on the device. Furthermore the messages are placed in the channel share
+of the device. This will result in sending the actual \gls{SDS} specification
+and \gls{Task} specifications to the device. A \gls{Task} record is created
+with the identifier $-1$ to denote a \gls{Task} not yet acknowledged. Finally
+the device itself is updated with the new state and with the new \gls{Task}.
+When the device returns an acknowledgement the \gls{Task} is updated
+accordingly.
 
 \begin{lstlisting}[label={lst:sendtask},%
        caption={Sending a \gls{Task} to a device}]