introduction.tex

   1 \section{Introduction}
   2 The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
   3 high abstraction level of real life workflow tasks. Through an \gls{EDSL} that
   4 programmers can model workflow tasks. The system will then generate a
   5 multi-user web service. This web service can be accessed through a browser and
   6 used to complete these \glspl{Task}. Familiar workflow patterns like sequence,
   7 parallel and conditional tasks can be modelled. From the \gls{Task} description
   8 the system will generate an multi-user web application for real life tasks.
   9
  10 \gls{iTasks} has been shown to be useful in many fields of operation such as incident
  11 management~\cite{lijnse_top_2013}. Interfaces are automatically generated for
  12 the types of data which makes rapid development possible. However, while the
  13 tasks in the \gls{iTasks} system model after real life workflow tasks the
  14 modelling is very high level. It is difficult to connect actual tasks to the
  15 real tasks and let them interact. A lot of the actual tasks can be
  16 \emph{performed} by small \gls{IoT} devices. Nevertheless, adding such devices
  17 to the current system is difficult to say the least as it was not designed to
  18 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. Moreover, this does
  24 not allow you to build in logic into the device. A lot of the small \gls{IoT}
  25 devices have limited processing power but can still contain decision making.
  26 Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a
  27 distributed server architecture~\cite{oortgiese_distributed_2017} that is also
  28 runnable on smaller devices like \acrshort{ARM}. However, this is limited to
  29 fairly high performance devices that are equipped with high speed communication
  30 lines. Devices in \gls{IoT} often only have \gls{LTN} communication with low
  31 bandwidth and a very limited amount of processing power and are therefore not
  32 suitable to run an entire \gls{iTasks} core.
  33
  34 \glspl{mTask} will bridge this gap by introducing a new communication protocol,
  35 device server 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}.
  40
  41 \section{Document structure}
  42 The structure of the thesis is as follows.
  43 Chapter~\ref{chp:introduction} contains the problem statement, motivation and
  44 the structure of the document.
  45 Chapter~\ref{chp:methods} describes the foundations on which the implementation
  46 is built together with the new techniques introduced.
  47 Chapter~\ref{chp:results} shows the results in the form of an example
  48 application accompanied with implementation.
  49 Chapter~\ref{chp:conclusion} concludes by answering the research questions
  50 and discusses future research.
  51 Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
  52 communicating between the server and client.
  53 Appendix~\ref{app:device-interface} shows the concrete interface for the
  54 devices.