X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=results.arch.tex;h=c4c2b22222b75fb59d2ffddc6bb1dd6c7011d9a8;hb=8c96bdcdd19c4c3cbe9f86357508f5efb7169cc5;hp=cbef26c9625b6c41eec04c7fc4b34fa6bd1da409;hpb=7b0fe8509016c0841d35239dc87150e945cfd960;p=msc-thesis1617.git

diff --git a/results.arch.tex b/results.arch.tex
index cbef26c..c4c2b22 100644
--- a/results.arch.tex
+++ b/results.arch.tex
@@ -1,4 +1,4 @@
-\section{Devices}
+/section{Devices}
 The client code for the devices is compiled from one codebase. For a device to
 be eligible for \glspl{mTask}, it must be able to compile the shared codebase
 and implement (part of) the device specific interface. The shared codebase only
@@ -34,7 +34,7 @@ the device software.
 \section{Specification}
 Devices are stored in a record type and all devices in the system are stored in
 a \gls{SDS} containing all devices. From the macro settings in the interface
-file a profile is created for the device that describes the specification. When
+file, a profile is created for the device that describes the specification. When
 a connection between the server and a client is established the server will
 send a request for specification. The client will serialize his specification
 and send it to the server so that the server knows what the client is capable
@@ -68,16 +68,18 @@ device type the \gls{Task} is just a simple wrapper around the existing
 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
-\glspl{Task} currently on the device and the according \glspl{SDS}. Finally it
-stores the specification of the device that is received when connecting.
-All of this is listed in Listing~\ref{lst:mtaskdevice}. The definitions of the
-message format are explained in the following section.
+Besides all the communication information, the record also keeps track of the
+\glspl{Task} currently on the device, the compiler state (see
+Section~\ref{sec:compiler}) and the according \glspl{SDS}. Finally it stores
+the specification of the device that is received when connecting.  All of this
+is listed in Listing~\ref{lst:mtaskdevice}. The definitions of the message
+format are explained in the following section.
 
 \begin{lstlisting}[caption={Device type},label={lst:mtaskdevice}]
 deviceStore :: Shared [MTaskDevice]
 
 :: Channels :== ([MTaskMSGRecv], [MTaskMSGSend], Bool)
+:: BCState = ... // Compiler state, explained in later sections
 :: MTaskResource 
 	= TCPDevice TCPSettings
 	| SerialDevice TTYSettings
@@ -86,6 +88,7 @@ deviceStore :: Shared [MTaskDevice]
 		, deviceError :: Maybe String
 		, deviceChannels :: String
 		, deviceName :: String
+		, deviceState :: BCState
 		, deviceTasks :: [MTaskTask]
 		, deviceData :: MTaskResource
 		, deviceSpec :: Maybe MTaskDeviceSpec
@@ -149,6 +152,7 @@ the server with their device specification. This is detected by the processing
 function and the record is updated accordingly.
 
 \begin{figure}[H]
+	\centering
 	\begin{sequencediagram}
 		\newthread{s}{Server}
 		\newinst[4]{c}{Client}
@@ -158,6 +162,63 @@ function and the record is updated accordingly.
 	\caption{Connect a device}\label{fig:handshake}
 \end{figure}
 
-\subsection{\glspl{Task}}
-\subsection{\glspl{SDS}}
-\todo{Connectie, hoe gaat dat in zijn werk}
+\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}.
+
+\begin{figure}[H]
+	\centering
+	\begin{sequencediagram}
+		\newthread{s}{Server}
+		\newinst[4]{c}{Client}
+		\begin{call}{s}{MTSDS}{c}{MTSDSAck}
+		\end{call}
+		\begin{call}{s}{MTTask}{c}{MTTaskAck}
+		\end{call}
+	\end{sequencediagram}
+	\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
+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} 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}]
+makeTask :: String Int -> Task MTaskTask
+makeTask name ident = get currentDateTime @ \dt->{MTaskTask | name=name,ident=ident,dateAdded=dt}
+
+makeShare :: String Int BCValue -> MTaskShare
+makeShare withTask identifier value = {MTaskShare |withTask=[withTask], identifier=identifier,value=value}
+
+sendTaskToDevice :: String (Main (ByteCode a Stmt)) (MTaskDevice, MTaskInterval) -> Task [MTaskDevice]
+sendTaskToDevice wta mTask (device, timeout)
+# (msgs, newState) = toMessages timeout mTask device.deviceState
+# shares = [makeShare wta sdsi sdsval\\{sdsi,sdsval}<-newState.sdss, (MTSds sdsi` _)<-msgs | sdsi == sdsi`] 
+= updateShares device ((++) shares)
+	>>| sendMessages msgs device
+	>>| makeTask wta -1
+	>>= withDevices device o addTaskUpState newState
+	where
+		addTaskUpState :: BCState MTaskTask MTaskDevice -> MTaskDevice
+		addTaskUpState st task device = {MTaskDevice | device &
+			deviceState=st, deviceTasks=[task:device.deviceTasks]}
+\end{lstlisting}
+
+\subsection{Miscellaneous Messages}
+There exists one special type of message that is sent to the device only when
+it needs to reboot. When the server wants to stop the bond with the device it
+sends the \CI{MTShutdown} message. The device will then clear his memory, thus
+losing all the \glspl{SDS} and \glspl{Task} that were stored and reset itself.
+Shortly after the shutdown message a new server can connect to the device
+because the device is back in listening mode.