\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
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
+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.
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
+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
+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
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 \acrshort{ARM}~~\cite{%
+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
\section{Problem statement}
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
+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
methods to create \gls{EDSL}.
Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
extended upon 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.
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
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}%
+\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
+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%
repositories / msc-thesis1617.git / blobdiff