intro.problem.tex

   1 \Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
   2 tasks but the modelling is applied on a high level. Therefore, it is difficult
   3 to connect \gls{iTasks}-\glspl{Task} to real world tasks and allow them
   4 to interact. A lot of the actual tasks could very well be performed by
   5 \gls{IoT} devices. Nevertheless, adding such devices to the current system is
   6 difficult to say the least as it was not designed to cope with these devices.
   7
   8 In the current system such adapters connecting devices to \gls{iTasks} --- in
   9 principle --- can be written in two ways.
  10
  11 First, an adapter for a specific device can be written as a
  12 \glspl{SDS}\footnote{Similar as to resources such as time are available in the
  13 current \gls{iTasks} implementation.}. \glspl{SDS} can interact with the world
  14 and thus with hardware, allowing communication with any type of device.
  15 However, this requires a tailor-made \gls{SDS} for every specific device and
  16 functionality and does not allow logic to be changed. Once a device is
  17 programmed to serve as an \gls{SDS}, it has to behave like that forever. Thus,
  18 this solution is not suitable for systems that can send \glspl{Task} to
  19 the device dynamically.
  20
  21 The second method uses the novel contribution to \gls{iTasks} by Oortgiese et
  22 al. They lifted \gls{iTasks} from a single server model to a distributed server
  23 architecture~\cite{oortgiese_distributed_2017}. As a proof of concept, an
  24 android app has been created that runs an entire \gls{iTasks} core and is able
  25 to receive \glspl{Task} from a different server and execute them. While android
  26 often runs on small \gls{ARM} devices, they are a lot more powerful than the
  27 average \gls{IoT} microcontroller. The system is suitable for dynamically
  28 sending \glspl{Task} but running the entire \gls{iTasks} core on a
  29 microcontroller is not feasible. Even if it would be possible, this technique
  30 would still not be suitable because a lot of communication overhead is needed
  31 to transfer the \glspl{Task}. \gls{IoT} devices are often connected to the
  32 server through \emph{Low Power Low Bandwidth} which is unsuitable for
  33 transferring a lot of data.
  34
  35 The novel system that has been devised bridges the gap between the
  36 aforementioned solutions for adding \gls{IoT} to \gls{iTasks}. The system
  37 consists of updates to the
  38 \gls{mTask}-\gls{EDSL}~\cite{koopman_type-safe_nodate}, a new communication
  39 protocol, device application and an \gls{iTasks} server application. The system
  40 supports devices as small as \gls{Arduino}
  41 microcontrollers~\cite{noauthor_arduino_nodate} and operates via the same
  42 paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
  43 Devices in the \gls{mTask}-system can run small imperative programs written in
  44 the \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
  45 device at runtime, avoiding recompilation and thus write cycles on the program
  46 memory. This solution extends the reach of \gls{iTasks} and allows closer
  47 resemblance of \glspl{Task} to actual tasks. Moreover, it tries to solve some
  48 integration problems in \gls{IoT} by allowing all components to be programmed
  49 from one source.