\section{Introduction}
-\Gls{IoT} technology is emerging very quickly. It offers myriads of solutions
+\Gls{IoT} technology is emerging rapidly. It offers myriads of solutions
and transforms the way we interact with technology.
Initially the term was coined to describe \gls{RFID} devices and the
all small devices that communicate with each other and the world. These devices
are often equipped with sensors, \gls{GNSS}\footnote{e.g.\ the American
\gls{GPS} or the Russian \gls{GLONASS}} and actuators%
-\cite{da_xu_internet_2014}. With these new technologies information
-can be tracked very accurately using very little power and bandwidth. Moreover,
-\gls{IoT} technology is coming into people's homes, clothes and in
-healthcare\cite{riazul_islam_internet_2015}. For example, for a few euros a
+~\cite{da_xu_internet_2014}. With these new technologies information
+can be tracked accurately using little power and bandwidth. Moreover, \gls{IoT}
+technology is coming into people's homes, clothes and
+healthcare~\cite{riazul_islam_internet_2015}. For example, for a few euros a
consumer ready fitness tracker watch can be bought that tracks heartbeat and
respiration levels.
The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer
a high abstraction level for real life workflow tasks%
-\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through
+~\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through
an \gls{EDSL} and modeled as \glspl{Task}. The system will generate multi-user
web app from the specification. This web service can be accessed through a
browser and is used to complete these \glspl{Task}. Familiar workflow patterns
-like sequence, parallel and conditional tasks can be modelled using
+like sequence, parallel and conditional \glspl{Task} can be modelled using
combinators.
\gls{iTasks} has been proven to be useful in many fields of operation such as
incident management~\cite{lijnse_top_2013}. Interfaces are automatically
generated for the types of data which makes rapid development possible.
\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
-tasks but the modelling is applied on a very high level. Therefore it is
-difficult to connect \gls{iTasks}-\glspl{Task} to real world tasks and let
-them interact. A lot of the actual tasks could be performed by small
+tasks but the modelling is applied on a high level. Therefore it is
+difficult to connect \gls{iTasks}-\glspl{Task} to real world \glspl{Task} and
+allow them to interact. A lot of the actual tasks could be performed by small
\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.
such as time are available in the current \gls{iTasks} implementation}.
However, this
requires a very specific adapter to be written for every device and function.
-This forces a fixed logic in the device that is set at compile time. A
-lot of the small \gls{IoT} devices have limited processing power but can still
-contain decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single
-server model to a distributed server architecture that is also runnable on
-smaller devices like \acrshort{ARM} devices\cite{oortgiese_distributed_2017}.
-However, this is limited to fairly high performance devices that are equipped
-with high speed communication channels. Devices in \gls{IoT} often have only
-\gls{LTN} communication with low bandwidth and a very limited amount of
-processing power and are therefore not suitable to run an entire \gls{iTasks}
-core.
+This forces a fixed logic in the device that is set at compile time. Many
+small \gls{IoT} devices have limited processing power but can still contain
+decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single server
+model to a distributed server architecture that is also runnable on small
+devices such as those powered by \gls{ARM}~\cite{%
+oortgiese_distributed_2017}. However, this is limited to fairly high
+performance devices that are equipped with high speed communication channels.
+Devices in \gls{IoT} often have only \gls{LTN} communication with low bandwidth
+and a very limited amount of processing power and are therefore not suitable to
+run an entire \gls{iTasks} core.
\section{Problem statement}
-The updates to the \gls{mTask}-system\cite{koopman_type-safe_nodate} will
+The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will
bridge this gap by introducing a new communication protocol, device application
-and \glspl{Task} synchronizing the formers. The system can run on devices as
-small as \gls{Arduino} microcontrollers\cite{noauthor_arduino_nodate} and
+and \glspl{Task} synchronizing the two. The system can run on 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}
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
methods to create \gls{EDSL}.
Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
-extended on in this dissertation.
-Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
-are a part of the new \gls{mTask}-system.
+extended upon in this dissertation.
Chapter~\ref{chp:mtaskcont} shows the extension added to the
\gls{mTask}-\gls{EDSL} that were needed to make the system function.
-Chapter~\ref{chp:itasksint} shows the integration with \gls{iTasks} that was
-built to realise the system.
+Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
+are a part of the new \gls{mTask}-system. It covers the client software running
+on the device and the server written in \gls{iTasks}.
Chapter~\ref{chp:conclusion} concludes by answering the research questions
and discusses future research.
Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
Appendix~\ref{app:device-interface} shows the concrete interface for the
devices.
+Text written using the \CI{Teletype} font indicates code and is often
+referring to a listing. \emph{Emphasized} text is used for proper nouns and
+words that have a unexpected meaning.
+
+The complete source code of this thesis can be found in the following git
+repository:\\
+\url{https://git.martlubbers.net/msc-thesis1617.git}
+
+The complete source code of the \gls{mTask}-system can be found in the
+following git repository:
+\url{https://git.martlubbers.net/mTask.git}
+
\section{Related work}
-Several types of similar research have been conducted concerning these matters.
-Microcontrollers such as the \gls{Arduino} can be remotely controlled by the
-\gls{Firmata}-protocol\footnote{``firmata/protocol: Documentation of the
-Firmata protocol.'' (\url{https://github.com/firmata/protocol}). [Accessed:
-23-May-2017].}. This protocol
-is designed to expose the peripherals such as sensors to the server. This
-allows very fine grained control but with the cost of excessive communication
-overhead since no code is executed on the device, only the peripherals are
-queried. A \gls{Haskell} implementation of the protocol has been created%
-\footnote{``hArduino by LeventErkok.'' (\url{%
+Similar research has been conducted concerning these matters.
+For example, microcontrollers such as the \gls{Arduino} can be remotely
+controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol:
+Documentation of the Firmata protocol.''
+(\url{https://github.com/firmata/protocol}). [Accessed: 23-May-2017].}. This
+protocol is designed to expose the peripherals such as sensors to the server.
+This allows very fine grained control but with the cost of excessive
+communication overhead since no code is executed on the device, only the
+peripherals are queried. A \gls{Haskell} implementation of the protocol is
+also available\footnote{``hArduino by LeventErkok.'' (\url{%
https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
\Gls{Clean} has a history of interpretation and there is a lot of research
happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
functional intermediate language that has interpreters written in
-\gls{C++}\cite{jansen_efficient_2007} and \gls{Javascript}%
-\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
-backends\cite{domoszlai_compiling_2012}. However, interpreting the resulting
-code is still heap-heavy and therefore not directly suitable for devices with as
-little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
+\gls{C++}~\cite{jansen_efficient_2007}, \gls{Javascript}%
+~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
+backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
+code is still heap-heavy and therefore not directly suitable for devices with
+as little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
possible to compile the \gls{SAPL} code into efficient machine language or
\gls{C} but then the system would lose its dynamic properties since the
microcontroller then would have to be reprogrammed every time a new \gls{Task}
is sent to the device.
\Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
-environments. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
-that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
-\cite{plasmeijer_shallow_2016}\cite{koopman_type-safe_nodate}.
-Again, this requires a reprogramming cycle every time the
-\gls{Task}-specification is changed.
+environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which
+generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
+~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}. Again, this
+requires a reprogramming cycle every time the \gls{Task}-specification is
+changed.
Another \gls{EDSL} designed to generate low-level high-assurance programs is
called \gls{Ivory} and uses \gls{Haskell} as a host language%
-\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
+~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
make unsafe languages type safe. For example, \gls{Ivory} has been used in the
automotive industry to program parts of an autopilot%
-\cite{pike_programming_2014}\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
+~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
is deeply embedded but the type system is shallowly embedded. This requires
several \gls{Haskell} extensions that offer dependent type constructions. The
process of compiling an \gls{Ivory} program happens in stages. The embedded