process rinus' comments chp 1-4

[msc-thesis1617.git] / introduction.tex

diff --git a/introduction.tex b/introduction.tex
index 1060cb3..9243d2a 100644 (file)
--- a/introduction.tex
+++ b/introduction.tex
@@ -1,61 +1,84 @@
 \section{Introduction}
 \section{Introduction}

-The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
-high abstraction level for real life workflow tasks. 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{IoT} technology is emerging rapidly. It offers myriads of solutions
+and transforms the way we interact with technology.

 
 

-\gls{iTasks} has been shown to be useful in many fields of operation such as
+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} modules\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 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 world workflow
+tasks~\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described
+through an \gls{EDSL} and modeled as \glspl{Task}. The system will generate a
+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 sequential, parallel and conditional \glspl{Task} can be modelled
+using combinators.
+
+\gls{iTasks} has 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
 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 can be \emph{performed} by small \gls{IoT}
+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. 
 
 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. Many small \gls{IoT} devices have limited processing power but are still
+powerful enough for decision making. Recompiling the code for a small
+\gls{IoT} device is expensive and therefore it is difficult to use a device
+dynamically for multiple purposes. 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 because it requires the device to run the entire \gls{iTasks} core.
+Devices in \gls{IoT} often have only Low Throughput Network communication with
+low bandwidth and a very limited amount of processing power and are therefore
+not suitable to run an entire \gls{iTasks} core.

 
 

-\glspl{mTask} 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 Arduino microcontrollers and
-operates via the same paradigms and patterns as regular \glspl{Task}.
-\glspl{mTask} can run small imperative programs written in a \gls{EDSL} and
-have access to \glspl{SDS}. In this way \glspl{Task} can be sent to the device
-at runtime and information can be exchanged.
+\section{Problem statement}
+The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will
+bridge this gap in the current system by introducing a new communication
+protocol, device application 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} are sent to the
+device at runtime, avoiding recompilation and thus write cycles on the program
+memory.

 
 \section{Document structure}
 
 \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,
 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
 Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and

-\gls{iTasks}
+\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
 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.
+extended upon in this dissertation.
+Chapter~\ref{chp:mtaskcont} describes the view and functionality for
+the \gls{mTask}-\gls{EDSL} that were added and used in the system.

 Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
 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}
-
+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
 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


@@ -63,6 +86,61 @@ communicating between the server and client.
 Appendix~\ref{app:device-interface} shows the concrete interface for the
 devices.
 
 Appendix~\ref{app:device-interface} shows the concrete interface for the
 devices.
 

-\section{Relevant research}
-\todo{Hier alle citaten en achtergrond doen}
-Ivory, firmata, dsl spul, etc.
+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}
+Similar research has been conducted on the subject.
+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}, \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. 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
+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
+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. In the new
+system, 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.