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
  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 \glspl{Task} 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 \glspl{Task} and
  32 allow them to 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. Many
  42 small \gls{IoT} devices have limited processing power but can still contain
  43 decision making. Oortgiese et al.\ lifted \gls{iTasks} from a single server
  44 model to a distributed server architecture that is also runnable on small
  45 devices such as those powered by \acrshort{ARM}~\cite{%
  46 oortgiese_distributed_2017}. However, this is limited to fairly high
  47 performance devices that are equipped with high speed communication channels.
  48 Devices in \gls{IoT} often have only \gls{LTN} communication with low bandwidth
  49 and a very limited amount of processing power and are therefore not suitable to
  50 run an entire \gls{iTasks} 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 upon 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 Text written using the \CI{Teletype} font indicates code and is often
  88 referring to a listing. \emph{Emphasized} text is used for proper nouns and
  89 words that have a unexpected meaning.
  90
  91 The complete source code of this thesis can be found in the following git
  92 repository:\\
  93 \url{https://git.martlubbers.net/msc-thesis1617.git}
  94
  95 The complete source code of the \gls{mTask}-system can be found in the
  96 following git repository:
  97 \url{https://git.martlubbers.net/mTask.git}
  98
  99 \section{Related work}
 100 Similar research has been conducted concerning these matters.
 101 For example, microcontrollers such as the \gls{Arduino} can be remotely
 102 controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol:
 103 Documentation of the Firmata protocol.''
 104 (\url{https://github.com/firmata/protocol}). [Accessed: 23-May-2017].}. This
 105 protocol is designed to expose the peripherals such as sensors to the server.
 106 This allows very fine grained control but with the cost of excessive
 107 communication overhead since no code is executed on the device, only the
 108 peripherals are queried. A \gls{Haskell} implementation of the protocol is
 109 also available\footnote{``hArduino by LeventErkok.'' (\url{%
 110 https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
 111
 112 \Gls{Clean} has a history of interpretation and there is a lot of research
 113 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
 114 functional intermediate language that has interpreters written in
 115 \gls{C++}~\cite{jansen_efficient_2007} and \gls{Javascript}%
 116 ~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
 117 backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
 118 code is still heap-heavy and therefore not directly suitable for devices with
 119 as little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
 120 possible to compile the \gls{SAPL} code into efficient machine language or
 121 \gls{C} but then the system would lose its dynamic properties since the
 122 microcontroller then would have to be reprogrammed every time a new \gls{Task}
 123 is sent to the device.
 124
 125 \Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
 126 environments. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
 127 that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
 128 ~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}.
 129 Again, this requires a reprogramming cycle every time the
 130 \gls{Task}-specification is changed.
 131
 132 Another \gls{EDSL} designed to generate low-level high-assurance programs is
 133 called \gls{Ivory} and uses \gls{Haskell} as a host language%
 134 ~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
 135 make unsafe languages type safe. For example, \gls{Ivory} has been used in the
 136 automotive industry to program parts of an autopilot%
 137 ~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
 138 is deeply embedded but the type system is shallowly embedded. This requires
 139 several \gls{Haskell} extensions that offer dependent type constructions. The
 140 process of compiling an \gls{Ivory} program happens in stages. The embedded
 141 code is transformed into an \gls{AST} that is sent to a backend. The
 142 \gls{mTask} \gls{EDSL} transforms the embedded code during compile-time
 143 directly into the backend which is often a state transformer that will execute
 144 on runtime.