introduction.tex

   1 \section{Introduction}
   2 \Gls{IoT} technology is emerging very quickly and offers myriads of solutions
   3 and transforms the way we interact with technology. Initially the term was
   4 coined to describe \gls{RFID} devices and the communication between them.
   5 However, currently the term \gls{IoT} encompasses all small devices that
   6 communicate with each other and the world often containing sensors, \gls{GPS}
   7 and actuators\cite{da_xu_internet_2014}. With these new technologies
   8 information can be tracked very accurately using very little power and
   9 bandwidth. Moreover, \gls{IoT} technology is coming into people's homes,
  10 clothes and in healthcare\cite{riazul_islam_internet_2015}. For example, for a
  11 couple of tens of euros a consumer ready fitness tracker watch can be bought
  12 that tracks heartbeat and respiration levels.
  13
  14 The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
  15 high abstraction level for real life workflow tasks%
  16 \cite{plasmeijer_itasks:_2007}. These workflow tasks can be described through
  17 an \gls{EDSL} and modeled as \glspl{Task} From the specification the system
  18 will then generate a multi-user web service.  This web service is accessed
  19 through a browser and used to complete these \glspl{Task}. Familiar workflow
  20 patterns like sequence, parallel and conditional tasks can be modelled using
  21 combinators.
  22
  23 \gls{iTasks} has been shown to be useful in many fields of operation such as
  24 incident management~\cite{lijnse_top_2013}. Interfaces are automatically
  25 generated for the types of data which makes rapid development possible.
  26 \Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
  27 tasks but the modelling is applied on a very high level. Therefore it is
  28 difficult to connect \gls{iTasks} tasks to the real world tasks and let them
  29 interact. A lot of the actual tasks could be \emph{performed} by small
  30 \gls{IoT} devices. Nevertheless, adding such devices to the current system is
  31 difficult to say the least as it was not designed to cope with these devices.
  32
  33 In the current system such adapters, in principle, can be written as
  34 \glspl{SDS}\footnote{Similar as to resources such as time are available in
  35 the current \gls{iTasks} implementation} but this requires a very specific
  36 adapter to be written for every device and functionality. However, this forces
  37 a fixed logic in the device that is set at compile time. A lot of the small
  38 \gls{IoT} devices have limited processing power but can still contain decision
  39 making. Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a
  40 distributed server architecture that is also runnable on smaller devices like
  41 \acrshort{ARM} devices\cite{oortgiese_distributed_2017}. However, this is
  42 limited to fairly high performance devices that are equipped with high speed
  43 communication channels. Devices in \gls{IoT} often only have \gls{LTN}
  44 communication with low bandwidth and a very limited amount of processing power
  45 and are therefore not suitable to run an entire \gls{iTasks} core.
  46
  47 \section{Problem statement}
  48 The updates to the \gls{mTask}-system will bridge this gap by introducing a new
  49 communication protocol, device application and \glspl{Task} synchronizing the
  50 formers. The system can run on devices as small as \gls{Arduino}
  51 microcontrollers% \cite{noauthor_arduino_nodate} and operates via the same
  52 paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
  53 Devices in the \glspl{mTask}-system can run small imperative programs written
  54 in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
  55 device at runtime, avoiding recompilation and thus write cycles on the program
  56 memory.
  57
  58 \section{Document structure}
  59 The structure of the thesis is as follows.
  60 Chapter~\ref{chp:introduction} contains the problem statement, motivation,
  61 literature embedding and the structure of the document.
  62 Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
  63 \gls{iTasks}.
  64 Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
  65 methods to create \gls{EDSL}.
  66 Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
  67 extended on in this dissertation.
  68 Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
  69 are a part of the new \gls{mTask}-system.
  70 Chapter~\ref{chp:mtaskcont} shows the extension added to the
  71 \gls{mTask}-\gls{EDSL} that were needed to make the system function.
  72
  73 \todo{Vul aan}
  74
  75 Chapter~\ref{chp:conclusion} concludes by answering the research questions
  76 and discusses future research.
  77 Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
  78 communicating between the server and client.
  79 Appendix~\ref{app:device-interface} shows the concrete interface for the
  80 devices.
  81
  82 \section{Relevant research}
  83 Several types of similar research has been conducted of these matters.
  84 Microcontrollers such as the \gls{Arduino} can be remotely controlled by the
  85 \gls{Firmata}-protocol\footnote{``firmata/protocol: Documentation of the
  86 Firmata protocol.'' (\url{https://github.com/firmata/protocol}). [Accessed:
  87 23-May-2017].}. This protocol
  88 is designed to expose the peripherals such as sensors to the server. This
  89 allows very fine grained control but with the cost of a big communication
  90 overhead since no code is executed on the device, only the peripherals are
  91 queried. A \gls{Haskell} implementation of the protocol has been created%
  92 \footnote{``hArduino by LeventErkok.'' (\url{%
  93 https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}
  94
  95 \Gls{Clean} has a history of interpretation and there is a lot of research
  96 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
  97 functional intermediate language that has interpreters written in
  98 \gls{C++}\cite{jansen_efficient_2007} and \gls{Javascript}%
  99 \cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
 100 backends\cite{domoszlai_compiling_2012}. However, interpreting the resulting
 101 code is still heap-heavy therefore not directly suitable for devices with as
 102 few as $2K$ of RAM such as the \gls{Arduino}. It might be possible to compile
 103 the \gls{SAPL} code into efficient machine language or \gls{C} but then the
 104 system would lose the dynamic properties since the microcontroller then has to
 105 be reprogrammed every time a new \gls{Task} is sent to the device.
 106
 107 \Gls{EDSL} have been used to generate \gls{C} code a lot for microcontroller
 108 environment. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
 109 that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
 110 \cite{plasmeijer_shallow_2016}.\cite{koopman_type-safe_nodate}.
 111 Again, this requires a reprogramming cycle every time the
 112 \gls{Task}-specification is changed.
 113
 114 Another \gls{EDSL} designed to generate low-level high-assurance programs is
 115 called \gls{Ivory} and uses \gls{Haskell} as a host language%
 116 \cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
 117 make unsafe language type safe. \gls{Ivory} has been used in for example the
 118 automotive industry to program parts of an autopilot%
 119 \cite{pike_programming_2014}\cite{hickey_building_2014}. A dialect of the
 120 \gls{Ivory} called \gls{Tower} has also been created by the same authors which
 121 is has specific backends for \glspl{RTOS}.