--- /dev/null
+\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.
repositories / msc-thesis1617.git / blobdiff