-The goal of the system as a whole is to offer a framework of functions with
+The system provides a framework of functions with
which an \gls{iTasks}-system can add, change and remove devices at runtime.
Moreover, the \gls{iTasks}-system can send \gls{mTask}-\glspl{Task} ---
compiled at runtime to bytecode by the \gls{mTask}-view --- to the device. The
-device runs an interpreter which can execute the \gls{Task}'s bytecode. Device
-profiles should be persistent during reboots of the \gls{iTasks}-system. The
-methods of interacting with \gls{mTask}-\gls{Task} should be analogous to
-interacting with \gls{iTasks}-\glspl{Task}. This means that programmers can
-access the \glspl{SDS} made for a device in the same way as regular \glspl{SDS}
-and they can execute \gls{mTask}-\glspl{Task} as if they where normal
+device runs an interpreter which executes the \gls{Task}'s bytecode following
+the scheduling strategy given. Devices added to the system are stored and get a
+profile for identification. These profiles are persistent during reboots of
+the \gls{iTasks}-system to allow for easy reconnecting with old devices. The
+methods of interacting with \gls{mTask}-\gls{Task} is analogous to interacting
+with \gls{iTasks}-\glspl{Task}. This means that programmers can access the
+\glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
+can execute \gls{mTask}-\glspl{Task} as if they where normal
\gls{iTasks}-\glspl{Task}.
-The following terms will be used throughout the following chapter:
-\begin{itemize}
- \item Device, Client
-
- These terms denotes the actual device connected to the system. This can
- be a real device such as a microcontroller but it can also just be a
- program on the same machine as the server functioning as a client.
- \item Server, \gls{iTasks}-System
-
- This is the actual executable serving the \gls{iTasks} application. The
- system contains \glspl{Task} taking care of the communication with the
- clients.
- \item System
-
- The system describes the complete ecosystem, containing both the server
- and the clients including the communication between them.
- \item Engine
-
- The runtime system of the client is called the engine. This program
- handles communicating with the server and runs the interpreter for the
- \glspl{Task} on the client.
-\end{itemize}
-
\section{Devices}
\input{arch.devices}
\gls{mTask} and the generated messages followed by the actual bytecode in a
readable form.
-\begin{lstlisting}[caption={Faculty as an \gls{mTask}-\gls{Task}}]
+\begin{lstlisting}[caption={Factorial as an \gls{mTask}-\gls{Task}}]
factorial :: Int -> Main (ByteCode () Stmt)
factorial i = sds \y=i In
namedsds \x=1 Named "result" In
)}
//Generating the actual messages with:
-//toMessages (OnInterval 500) (factorial 5) zero
+Start = fst $ toMessages (OnInterval 500) (factorial 5) zero
+
+//The output will be
//[MTSds 2 (BCValue 5), MTSds 1 (BCValue 1), MTTask (OnInterval 500) ...]
\end{lstlisting}
\begin{lstlisting}[label={lst:actualbc},%
- caption={The resulting bytecode for the factorial function},language=c]
+ caption={The resulting bytecode for the factorial function},language=C]
0-2 : BCSdsFetch 1
- 3-6 : BCPush i\d0\d1
+ 3-6 : BCPush (Int 1)
7 : BCLeq
8-9 : BCJmpF 16 //Jump to else
10-12: BCSdsPublish 2 ("result")
22 : BCMul
23-25: BCSdsStore 2 ("result")
26-28: BCSdsFetch 1
-29-32: BCPush i\d0\d1
+29-32: BCPush (Int 1)
33 : BCSub
34-36: BCSdsStore 1
37 : //Endif label
The proposed system provides a bridge between the gap present in the current
system. It provides a framework to offer functionality for an \gls{iTasks}
server to outsource \glspl{Task} to \gls{IoT}-devices without needing to
-recompile the code. The \glspl{Task} are compiled to bytecode and interpreted
-on the client.
+recompile the code. The \glspl{Task} targeted at \gls{IoT} devices are compiled
+at runtime to bytecode which is sent to the device for interpretation.
The following terms will be used throughout the following chapters:
\begin{itemize}