-The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will
-bridge this gap in the current system by introducing a new communication
-protocol, device application and \glspl{Task} synchronizing the two. The system
-can run on devices as small as \gls{Arduino}
+\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
+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
+\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.
+
+In the current system such adapters connecting devices to \gls{iTasks} --- in
+principle --- can be written in two ways.
+
+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 communication with any type of device.
+However, this requires a tailor-made \gls{SDS} for every specific device and
+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 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 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}
microcontrollers~\cite{noauthor_arduino_nodate} and operates via the same
paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
Devices in the \gls{mTask}-system can run small imperative programs written in
-an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
+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