introduction.tex

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