introduction.tex

   1 \section{Introduction}
   2 \Gls{IoT} technology is emerging rapidly. 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 accurately using little power and bandwidth. Moreover, \gls{IoT}
  12 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 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 \gls{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 two. 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:mtaskcont} shows the extension added to the
  75 \gls{mTask}-\gls{EDSL} that were needed to make the system function.
  76 Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
  77 are a part of the new \gls{mTask}-system. It covers the client software running
  78 on the device and the server written in \gls{iTasks}.
  79 Chapter~\ref{chp:conclusion} concludes by answering the research questions
  80 and discusses future research.
  81 Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
  82 communicating between the server and client.
  83 Appendix~\ref{app:device-interface} shows the concrete interface for the
  84 devices.
  85
  86 Text written using the \CI{Teletype} font indicates code and is often
  87 referring to a listing. \emph{Emphasized} text is used for proper nouns and
  88 words that have a unexpected meaning.
  89
  90 The complete source code of this thesis can be found in the following git
  91 repository:\\
  92 \url{https://git.martlubbers.net/msc-thesis1617.git}
  93
  94 The complete source code of the \gls{mTask}-system can be found in the
  95 following git repository:
  96 \url{https://git.martlubbers.net/mTask.git}
  97
  98 \section{Related work}
  99 Similar research has been conducted concerning these matters.
 100 For example, microcontrollers such as the \gls{Arduino} can be remotely
 101 controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol:
 102 Documentation of the Firmata protocol.''
 103 (\url{https://github.com/firmata/protocol}). [Accessed: 23-May-2017].}. This
 104 protocol is designed to expose the peripherals such as sensors to the server.
 105 This allows very fine grained control but with the cost of excessive
 106 communication overhead since no code is executed on the device, only the
 107 peripherals are queried. A \gls{Haskell} implementation of the protocol is
 108 also available\footnote{``hArduino by LeventErkok.'' (\url{%
 109 https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
 110
 111 \Gls{Clean} has a history of interpretation and there is a lot of research
 112 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
 113 functional intermediate language that has interpreters written in
 114 \gls{C++}~\cite{jansen_efficient_2007}, \gls{Javascript}%
 115 ~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
 116 backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
 117 code is still heap-heavy and therefore not directly suitable for devices with
 118 as little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be
 119 possible to compile the \gls{SAPL} code into efficient machine language or
 120 \gls{C} but then the system would lose its dynamic properties since the
 121 microcontroller then would have to be reprogrammed every time a new \gls{Task}
 122 is sent to the device.
 123
 124 \Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
 125 environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which
 126 generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
 127 ~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}.  Again, this
 128 requires a reprogramming cycle every time the \gls{Task}-specification is
 129 changed.
 130
 131 Another \gls{EDSL} designed to generate low-level high-assurance programs is
 132 called \gls{Ivory} and uses \gls{Haskell} as a host language%
 133 ~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
 134 make unsafe languages type safe. For example, \gls{Ivory} has been used in the
 135 automotive industry to program parts of an autopilot%
 136 ~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
 137 is deeply embedded but the type system is shallowly embedded. This requires
 138 several \gls{Haskell} extensions that offer dependent type constructions. The
 139 process of compiling an \gls{Ivory} program happens in stages. The embedded
 140 code is transformed into an \gls{AST} that is sent to a backend. The
 141 \gls{mTask} \gls{EDSL} transforms the embedded code during compile-time
 142 directly into the backend which is often a state transformer that will execute
 143 on runtime.