\section{Introduction}
\Gls{IoT} technology is emerging very quickly and offers myriads of solutions
-and transforms the way we interact with technology. Initially the term was
-coined to describe \gls{RFID} devices and the communication between them.
-However, currently the term \gls{IoT} encompasses all small devices that
-communicate with each other and the world often containing sensors, \gls{GPS}
-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
-couple of tens of euros a consumer ready fitness tracker watch can be bought
-that tracks heartbeat and respiration levels.
+and transforms the way we interact with technology.
-The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
-high abstraction level for real life workflow tasks%
+Initially the term was coined to describe \gls{RFID} devices and the
+communication between them. However, currently the term \gls{IoT} encompasses
+all small devices that communicate with each other and the world. These devices
+often contain 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 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
-an \gls{EDSL} and modeled as \glspl{Task} From the specification the system
-will then generate a multi-user web service. This web service is accessed
-through a browser and used to complete these \glspl{Task}. Familiar workflow
+an \gls{EDSL} and modeled as \glspl{Task}. The system will generatea multi-user
+web service 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
combinators.
-\gls{iTasks} has been shown to be useful in many fields of operation such as
+\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} tasks to the real world tasks and let them
-interact. A lot of the actual tasks could be \emph{performed} by small
+difficult to connect \gls{iTasks}-\glspl{Task} to real world tasks and let
+them interact. A lot of the actual tasks could be \emph{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.
In the current system such adapters, in principle, can be written as
\glspl{SDS}\footnote{Similar as to resources such as time are available in
the current \gls{iTasks} implementation} but this requires a very specific
-adapter to be written for every device and functionality. However, this forces
+adapter to be written for every device and function. However, 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 only have \gls{LTN}
+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.
The updates to the \gls{mTask}-system 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 operates via the same
+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 \glspl{mTask}-system can run small imperative programs written
in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
memory.
\section{Document structure}
-The structure of the thesis is as follows.
+The structure of this thesis is as follows.
+
Chapter~\ref{chp:introduction} contains the problem statement, motivation,
literature embedding and the structure of the document.
Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
devices.
\section{Relevant research}
-Several types of similar research has been conducted of these matters.
+Several types of similar research has 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 a big communication
+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{%
code is still heap-heavy therefore not directly suitable for devices with as
few as $2K$ of RAM such as the \gls{Arduino}. It might be possible to compile
the \gls{SAPL} code into efficient machine language or \gls{C} but then the
-system would lose the dynamic properties since the microcontroller then has to
-be reprogrammed every time a new \gls{Task} is sent to the device.
+system would lose its dynamic properties since the microcontroller then would
+has to be reprogrammed every time a new \gls{Task} is sent to the device.
-\Gls{EDSL} have been used to generate \gls{C} code a lot for microcontroller
-environment. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
+\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
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
-make unsafe languages type safe. \gls{Ivory} has been used in for example the
+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
is deeply embedded but the type system is shallowly embedded. This requires
repositories / msc-thesis1617.git / blobdiff