\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.
+\Gls{IoT} technology is emerging very quickly. It offers myriads of solutions
+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
+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
+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
-patterns like sequence, parallel and conditional tasks can be modelled using
+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
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 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
-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 with low bandwidth and a very limited amount of processing power
-and are therefore not suitable to run an entire \gls{iTasks} core.
+In the current system such adapters connecting devices to \gls{iTasks} --- in
+principle --- can be written as \glspl{SDS}\footnote{Similar as to resources
+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.
\section{Problem statement}
-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
-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
-device at runtime, avoiding recompilation and thus write cycles on the program
-memory.
+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
+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 device at runtime, avoiding recompilation and thus write cycles
+on the program 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.
+related work and the structure of the document.
Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
\gls{iTasks}.
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
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.
-
-\todo{Vul aan}
-
+Chapter~\ref{chp:itasksint} shows the integration with \gls{iTasks} that was
+built to realise the system.
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.
-\section{Relevant research}
-Several types of similar research has been conducted of these matters.
+\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 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{%
-https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}
+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
\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 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.
+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.
-\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}.
+\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
-make unsafe language 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}. A dialect of the
-\gls{Ivory} called \gls{Tower} has also been created by the same authors which
-is has specific backends for \glspl{RTOS}.
+\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
+code is transformed into an \gls{AST} that is sent to a backend. The
+\gls{mTask} \gls{EDSL} transforms the embedded code during compile-time
+directly into the backend which is often a state transformer that will execute
+on runtime.
repositories / msc-thesis1617.git / blobdiff