\subsection{Internet of Things}
\Gls{IoT} technology is emerging rapidly. It offers myriads of solutions
and is transforming the way people interact with technology.

The term \gls{IoT} was coined around 1999 to describe \gls{RFID} devices and
the communication between them. After a small slumber of the term, it
resurfaced recently and has changed definition slightly. In the current day and
age, \gls{IoT} encompasses all small devices that communicate with each other
and --- most of all --- with the world. It has been estimated that there will
be around 30 billion \gls{IoT} devices online in 2020. Even today, \gls{IoT}
devices are already in everyone's household in the form of smart electricity
meters, smart fridges, smartphones, smart watches.  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, bandwidth and money.  Moreover, \gls{IoT} technology is coming into
healthcare as well~\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 architecture of \gls{IoT} systems is often divided into layers. A very
popular division is the four layer architecture but there are also proponents
of a five layer structure. The first layer of the four layer architecture is
the sensing layer. This layer contains the actual sensing and acting hardware.
In a smart electricity meter, this layer would contains the sensors detecting
the current drawn. There are myriads of device available to use in this layer
and they can be programmed using a variety of different low level programming
languages such as \gls{C++}, \gls{C} but also higher level languages such as
\gls{Python} and \gls{LUA}.

The second layer of \gls{IoT} is the networking layer and is
responsible for connecting the first layer with the outer world. In the
electricity meter example, this would be the \textsc{GSM} modem connecting the
meter to a server. Existing networking techniques --- such as WiFi and GSM ---
are used to convey \gls{IoT} information but there are also specialized
communication techniques devised for \gls{IoT} such as ZigBee, LoRa and
Bluetooth Low Energy.

The third layer is the service layer. This layer is responsible for all the
servicing and business rules surrounding the application. It provides
\glspl{API} and interfaces to the data. Finally there is the application layer.
This final layer provides the applications that the user can use to interact
with the \gls{IoT} devices. In the electricity example, this layer would be the
app that can be used to monitor the electricity consumption. These tools on the
application layer can again be created into a wide variety of programming
languages and different paradigms.

\subsection{Task Oriented Programming}
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} hosted in \gls{Clean} 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. 

\subsection{Integration}
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.
