new layout
[msc-thesis1617.git] / introduction.tex
1 \section{Introduction}
2 The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
3 high abstraction level for real life workflow tasks. These workflow tasks can be
4 described through an \gls{EDSL} and modeled as \glspl{Task}
5 From the specification the system will then generate a multi-user web service.
6 This web service is accessed through a browser and used to complete these
7 \glspl{Task}. Familiar workflow patterns like sequence, parallel and
8 conditional tasks can be modelled using combinators.
9
10 \gls{iTasks} has been shown to be useful in many fields of operation such as
11 incident management~\cite{lijnse_top_2013}. Interfaces are automatically
12 generated for the types of data which makes rapid development possible.
13 \Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
14 tasks but the modelling is applied on a very high level. Therefore it is
15 difficult to connect \gls{iTasks} tasks to the real world tasks and let them
16 interact. A lot of the actual tasks can be \emph{performed} by small \gls{IoT}
17 devices. Nevertheless, adding such devices to the current system is difficult
18 to say the least as it was not designed to cope with these devices.
19
20 In the current system such adapters, in principle, can be written as
21 \glspl{SDS}\footnote{Similar as to resources such as time are available in
22 the current \gls{iTasks} implementation} but this requires a very specific
23 adapter to be written for every device and functionality. However, this forces
24 a fixed logic in the device that is set at compile time. A lot of the small
25 \gls{IoT} devices have limited processing power but can still contain decision
26 making. Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a
27 distributed server architecture that is also runnable on smaller devices like
28 \acrshort{ARM} devices\cite{oortgiese_distributed_2017}. However, this is
29 limited to fairly high performance devices that are equipped with high speed
30 communication channels. Devices in \gls{IoT} often only have \gls{LTN}
31 communication with low bandwidth and a very limited amount of processing power
32 and are therefore not suitable to run an entire \gls{iTasks} core.
33
34 \glspl{mTask} will bridge this gap by introducing a new communication protocol,
35 device application and \glspl{Task} synchronizing the formers.
36 The system can run on devices as small as Arduino microcontrollers and
37 operates via the same paradigms and patterns as regular \glspl{Task}.
38 \glspl{mTask} can run small imperative programs written in a \gls{EDSL} and
39 have access to \glspl{SDS}. In this way \glspl{Task} can be sent to the device
40 at runtime and information can be exchanged.
41
42 \section{Document structure}
43 The structure of the thesis is as follows.
44 Chapter~\ref{chp:introduction} contains the problem statement, motivation,
45 literature embedding and the structure of the document.
46 Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
47 \gls{iTasks}
48 Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
49 methods to create \gls{EDSL}.
50 Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
51 extended on in this dissertation.
52 Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
53 are a part of the new \gls{mTask}-system.
54 Chapter~\ref{chp:mtaskcont} shows the extension added to the
55 \gls{mTask}-\gls{EDSL} that were needed to make the system function.
56
57 \todo{Vul aan}
58
59 Chapter~\ref{chp:conclusion} concludes by answering the research questions
60 and discusses future research.
61 Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
62 communicating between the server and client.
63 Appendix~\ref{app:device-interface} shows the concrete interface for the
64 devices.
65
66 \section{Relevant research}
67 \todo{Hier alle citaten en achtergrond doen}
68 Ivory, firmata, dsl spul, etc.