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
+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
+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 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}.
+\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.
-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.
+The separation of \gls{IoT} in layers is one of the causes of an integration
+problem in \gls{IoT}. The different layers are built with different paradigms,
+programming languages and different architectures which is difficult to
+connect. Rolling out updates is also complicated since reprogramming
+microcontrollers in the field is very expensive.
\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.
+through an \gls{EDSL} hosted in \gls{Clean} and modeled as the basic blocks of
+the paradigm called \glspl{Task}. The system will generate a multi-user web
+application from the code. 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} chaining can be modelled in
+the language.
-\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.
+\Gls{iTasks} has proven to be useful in many fields of operation such as
+incident management~\cite{lijnse_top_2013}. \Gls{iTasks} is highly type driven
+and depends heavily on generic function for generating function for arbitrarily
+given types. This results in the programmer having to do very little
+programming on the details such as user interfaces.
repositories / msc-thesis1617.git / blobdiff