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