-\section{Motivation}
-\Gls{TOP} and \gls{iTasks} have been designed to offer a high abstraction level
-through a \gls{DSL} that describes workflows as \glspl{Task}. \gls{iTasks} has
-been shown to be useful in fields such as incident
-management~\cite{lijnse_top_2013}. However, there still lacks support for small
-devices to be added in the workflow. In principle such adapters can be written
-as \glspl{SDS}\footnote{Similar as to resources such as time are available in
-the current system} but this requires a very specific adapter to be written for
-every device and functionality. Oortgiese et al.\ lifted \gls{iTasks} from a
-single server model to a distributed server architecture~\todo{Add cite} that
-is also runnable on smaller devices like \acrshort{ARM}. However, this is
+\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.
+
+The \gls{TOP} paradigm and the according \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
+combinators.
+
+\gls{iTasks} has been shown 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
+\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 lines. Devices in \gls{IoT} often only have LPLB communication
-with low bandwidth and a very limited amount of processing power. \glspl{mTask}
-will bridge this gap. It can run on devices as small as Arduino
-microcontrollers and operates via the same paradigms as regular \glspl{Task}.
-The \glspl{mTask} have access to \glspl{SDS} and can run small imperative
-programs.
+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.
\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.
\section{Document structure}
The structure of the thesis is as follows.
-Chapter~\ref{chp:introduction} contains the problem statement, motivation and
-the structure of the document
-Chapter~\ref{chp:theoretical-framework} introduces the reader with all the
-terminology and techniques lying at the foundation of the study.
-Chapter~\ref{chp:methods} will describe the actual techniques used for the
-integration.
-Chapter~\ref{chp:results} shows the results in the form of an example
-application accompanied with implementation.
-Chapter~\ref{chp:conclusion} concludes by answering the research question (s)
+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
+\gls{iTasks}.
+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.
+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:conclusion} concludes by answering the research questions
and discusses future research.
Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
communicating between the server and client.
+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.
+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
+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].}
+
+\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 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.
+
+\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}
+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.
+
+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
+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}.
repositories / msc-thesis1617.git / blobdiff