\Gls{IoT} technology is emerging rapidly. It offers myriads of solutions
and transforms the way we interact with technology.

Initially the term was coined to describe \gls{RFID} devices and the
communication between them. However, currently the term \gls{IoT} encompasses
all small devices that communicate with each other and the world. These devices
are often equipped with sensors, \gls{GNSS} modules\footnote{e.g.\ the American
\gls{GPS} or the Russian \gls{GLONASS}.} and
actuators~\cite{da_xu_internet_2014}. With these new technologies information
can be tracked accurately using little power and bandwidth. Moreover, \gls{IoT}
technology is coming into people's homes, clothes and
healthcare~\cite{riazul_islam_internet_2015}. For example, for a few euros a
consumer ready fitness tracker watch can be bought that tracks heartbeat and
respiration levels.

The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer
a high abstraction level for real world workflow
tasks~\cite{plasmeijer_itasks:_2007}. These workflow tasks can be described
through an \gls{EDSL} and modeled as \glspl{Task}. The system will generate a
multi-user web app from the specification. This web service can be accessed
through a browser and is used to complete these \glspl{Task}. Familiar workflow
patterns like sequential, parallel and conditional \glspl{Task} can be modelled
using combinators.

\gls{iTasks} has proven to be useful in many fields of operation such as
incident management~\cite{lijnse_top_2013}. Interfaces are automatically
generated for the types of data which makes rapid development possible.
\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
tasks but the modelling is applied on a high level. Therefore it is difficult
to connect \gls{iTasks}-\glspl{Task} to real world \glspl{Task} and allow them
to interact. A lot of the actual tasks could be performed by small \gls{IoT}
devices. Nevertheless, adding such devices to the current system is difficult
to say the least as it was not designed to cope with these devices. 

In the current system such adapters connecting devices to \gls{iTasks} --- in
principle --- can be written as \glspl{SDS}\footnote{Similar as to resources
such as time are available in the current \gls{iTasks} implementation.}.
However, this requires a very specific adapter to be written for every device
and function.  This forces a fixed logic in the device that is set at compile
time. Many small \gls{IoT} devices have limited processing power but are still
powerful enough for decision making. Recompiling the code for a small
\gls{IoT} device is expensive and therefore it is difficult to use a device
dynamically for multiple purposes. Oortgiese et al.\ lifted \gls{iTasks} from a
single server model to a distributed server architecture that is also runnable
on small devices such as those powered by
\gls{ARM}~\cite{oortgiese_distributed_2017}. However, this is limited to
fairly high performance devices that are equipped with high speed communication
channels because it requires the device to run the entire \gls{iTasks} core.
Devices in \gls{IoT} often have only Low Throughput Network communication with
low bandwidth and a very limited amount of processing power and are therefore
not suitable to run an entire \gls{iTasks} core.
