\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
-tasks but the modelling is applied on a high level. Therefore it is difficult
+tasks but the modelling is applied on a high level. Therefore, it is difficult
to connect \gls{iTasks}-\glspl{Task} to real world tasks and allow them
-to interact. A lot of the actual tasks could very well be performed by small
+to interact. A lot of the actual tasks could very well be performed by
\gls{IoT} devices. Nevertheless, adding such devices to the current system is
difficult to say the least as it was not designed to cope with these devices.
First, an adapter for a specific device can be written as a
\glspl{SDS}\footnote{Similar as to resources such as time are available in the
current \gls{iTasks} implementation.}. \glspl{SDS} can interact with the world
-and thus with hardware, allowing it to communicate with any type of device.
+and thus with hardware, allowing communication with any type of device.
However, this requires a tailor-made \gls{SDS} for every specific device and
-does not allow logic to be changed. Once a device is programmed to serve as an
-\gls{SDS}, it has to behave like that forever. Thus, this solution is not
-suitable for dynamic systems.
+functionality and does not allow logic to be changed. Once a device is
+programmed to serve as an \gls{SDS}, it has to behave like that forever. Thus,
+this solution is not suitable for systems that can send \glspl{Task} to
+the device dynamically.
The second method uses the novel contribution to \gls{iTasks} by Oortgiese et
al. They lifted \gls{iTasks} from a single server model to a distributed server
architecture~\cite{oortgiese_distributed_2017}. As a proof of concept, an
android app has been created that runs an entire \gls{iTasks} core and is able
to receive \glspl{Task} from a different server and execute them. While android
-often runs on small \gls{ARM} devices, they are a lot more powerful that the
-average \gls{IoT} microcontroller. Running the entire \glspl{iTasks} core on a
+often runs on small \gls{ARM} devices, they are a lot more powerful than the
+average \gls{IoT} microcontroller. The system is suitable for dynamically
+sending \glspl{Task} but running the entire \gls{iTasks} core on a
microcontroller is not feasible. Even if it would be possible, this technique
would still not be suitable because a lot of communication overhead is needed
to transfer the \glspl{Task}. \gls{IoT} devices are often connected to the
server through \emph{Low Power Low Bandwidth} which is unsuitable for
transferring a lot of data.
-The novel system that has been devised that bridges the gap between the
-aforementioned solutions. The system consists of updates to the
+The novel system that has been devised bridges the gap between the
+aforementioned solutions for adding \gls{IoT} to \gls{iTasks}. The system
+consists of updates to the
\gls{mTask}-\gls{EDSL}~\cite{koopman_type-safe_nodate}, a new communication
protocol, device application and an \gls{iTasks} server application. The system
supports devices as small as \gls{Arduino}
Devices in the \gls{mTask}-system can run small imperative programs written in
the \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
device at runtime, avoiding recompilation and thus write cycles on the program
-memory.
+memory. This solution extends the reach of \gls{iTasks} and allows closer
+resemblance of \glspl{Task} to actual tasks. Moreover, it tries to solve some
+integration problems in \gls{IoT} by allowing all components to be programmed
+from one source.
repositories / msc-thesis1617.git / blobdiff