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} modules\footnote{e.g.\ the American
   9 \gls{GPS} or the Russian \gls{GLONASS}.} and
  10 actuators~\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 world workflow
  19 tasks~\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described
  20 through an \gls{EDSL} and modeled as \glspl{Task}. The system will generate a
  21 multi-user web app from the specification. This web service can be accessed
  22 through a browser and is used to complete these \glspl{Task}. Familiar workflow
  23 patterns like sequential, parallel and conditional \glspl{Task} can be modelled
  24 using combinators.
  25
  26 \gls{iTasks} has 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 difficult
  31 to connect \gls{iTasks}-\glspl{Task} to real world \glspl{Task} and allow them
  32 to interact. A lot of the actual tasks could be performed by small \gls{IoT}
  33 devices. Nevertheless, adding such devices to the current system is difficult
  34 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 requires a very specific adapter to be written for every device
  40 and function.  This forces a fixed logic in the device that is set at compile
  41 time. Many small \gls{IoT} devices have limited processing power but are still
  42 powerful enough for decision making. Recompiling the code for a small
  43 \gls{IoT} device is expensive and therefore it is difficult to use a device
  44 dynamically for multiple purposes. Oortgiese et al.\ lifted \gls{iTasks} from a
  45 single server model to a distributed server architecture that is also runnable
  46 on small devices such as those powered by
  47 \gls{ARM}~\cite{oortgiese_distributed_2017}. However, this is limited to
  48 fairly high performance devices that are equipped with high speed communication
  49 channels because it requires the device to run the entire \gls{iTasks} core.
  50 Devices in \gls{IoT} often have only Low Throughput Network communication with
  51 low bandwidth and a very limited amount of processing power and are therefore
  52 not suitable to run an entire \gls{iTasks} core.
  53
  54 \section{Problem statement}
  55 The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will
  56 bridge this gap in the current system by introducing a new communication
  57 protocol, device application and \glspl{Task} synchronizing the two. The system
  58 can run on devices as small as \gls{Arduino}
  59 microcontrollers~\cite{noauthor_arduino_nodate} and operates via the same
  60 paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
  61 Devices in the \gls{mTask}-system can run small imperative programs written in
  62 an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
  63 device at runtime, avoiding recompilation and thus write cycles on the program
  64 memory.
  65
  66 \section{Document structure}
  67 The structure of this thesis is as follows.
  68
  69 Chapter~\ref{chp:introduction} contains the problem statement, motivation,
  70 related work and the structure of the document.
  71 Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
  72 \gls{iTasks}.
  73 Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
  74 methods to create \gls{EDSL}.
  75 Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
  76 extended upon in this dissertation.
  77 Chapter~\ref{chp:mtaskcont} describes the view and functionality for
  78 the \gls{mTask}-\gls{EDSL} that were added and used in the system.
  79 Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that
  80 are a part of the new \gls{mTask}-system. It covers the client software running
  81 on the device and the server written in \gls{iTasks}.
  82 Chapter~\ref{chp:conclusion} concludes by answering the research questions
  83 and discusses future research.
  84 Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
  85 communicating between the server and client.
  86 Appendix~\ref{app:device-interface} shows the concrete interface for the
  87 devices.
  88
  89 Text written using the \CI{Teletype} font indicates code and is often
  90 referring to a listing. \emph{Emphasized} text is used for proper nouns and
  91 words that have a unexpected meaning.
  92
  93 The complete source code of this thesis can be found in the following git
  94 repository:\\
  95 \url{https://git.martlubbers.net/msc-thesis1617.git}
  96
  97 The complete source code of the \gls{mTask}-system can be found in the
  98 following git repository:
  99 \url{https://git.martlubbers.net/mTask.git}
 100
 101 \section{Related work}
 102 Similar research has been conducted on the subject.
 103 For example, microcontrollers such as the \gls{Arduino} can be remotely
 104 controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol:
 105 Documentation of the Firmata protocol.''
 106 (\url{https://github.com/firmata/protocol}). [Accessed: 23-May-2017].}. This
 107 protocol is designed to expose the peripherals such as sensors to the server.
 108 This allows very fine grained control but with the cost of excessive
 109 communication overhead since no code is executed on the device, only the
 110 peripherals are queried. A \gls{Haskell} implementation of the protocol is
 111 also available\footnote{``hArduino by LeventErkok.'' (\url{%
 112 https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
 113
 114 \Gls{Clean} has a history of interpretation and there is a lot of research
 115 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely
 116 functional intermediate language that has interpreters written in
 117 \gls{C++}~\cite{jansen_efficient_2007}, \gls{Javascript}%
 118 ~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler
 119 backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting
 120 code is still heap-heavy and therefore not directly suitable for devices with
 121 as little as $2K$ of RAM such as the \gls{Arduino} \emph{Uno}. It might be
 122 possible to compile the \gls{SAPL} code into efficient machine language or
 123 \gls{C} but then the system would lose its dynamic properties since the
 124 microcontroller then would have to be reprogrammed every time a new \gls{Task}
 125 is sent to the device.
 126
 127 \Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
 128 environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which
 129 generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
 130 ~\cite{plasmeijer_shallow_2016}~\cite{koopman_type-safe_nodate}.  Again, this
 131 requires a reprogramming cycle every time the \gls{Task}-specification is
 132 changed.
 133
 134 Another \gls{EDSL} designed to generate low-level high-assurance programs is
 135 called \gls{Ivory} and uses \gls{Haskell} as a host language%
 136 ~\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
 137 make unsafe languages type safe. For example, \gls{Ivory} has been used in the
 138 automotive industry to program parts of an autopilot%
 139 ~\cite{pike_programming_2014}~\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
 140 is deeply embedded but the type system is shallowly embedded. This requires
 141 several \gls{Haskell} extensions that offer dependent type constructions. The
 142 process of compiling an \gls{Ivory} program happens in stages. The embedded
 143 code is transformed into an \gls{AST} that is sent to a backend. In the new
 144 system, the \gls{mTask}-\gls{EDSL} transforms the embedded code during
 145 compile-time directly into the backend which is often a state transformer that
 146 will execute on runtime.