-\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
+\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{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 can 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. 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 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.
+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.
-\section{Problem statement}
-Therefore the problem statement is as follows:
+\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{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:methods} describes the foundations on which the implementation
-is built together with the new techniques introduced.
-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}
+\todo{Hier alle citaten en achtergrond doen}
+Ivory, firmata, dsl spul, etc.
repositories / msc-thesis1617.git / blobdiff