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
+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
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
+In a smart electricity meter, this would be the \textsc{GSM} modem connecting
+the meter to a server. Existing networking techniques --- such as WiFi and
+\textsc{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
+and Bluetooth Low Energy. The third layer is called 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.
+application. It provides \glspl{API} and interfaces to, and storage of the
+data. Finally, the fourth layer is the application layer. This final layer
+provides the applications that the user can use to interact with the \gls{IoT}
+devices and their data. In a smart electricity meter, this layer would be the
+app that can be used to monitor the electricity consumption.
The separation of \gls{IoT} in layers is a difficulty when developing \gls{IoT}
-applications. All layers use different paradigms, languages and architecture.
-Rolling out changes to the system is also complicated since reprogramming
-microcontrollers in the field is very expensive. Even the simple repurposing of
-a device requires often a full reprogram.
+applications. All layers use different paradigms, languages and architectures
+which leads to isolated logic which makes it difficult to integrate. Rolling
+out changes to the system is also complicated since reprogramming
+microcontrollers in the field is very expensive. Even the changing a few
+parameters on a device requires often a full reprogram.
\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 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.
+through an \gls{EDSL} hosted in the purely functional programming language
+\gls{Clean}. \glspl{Task} are the basic building blocks of the language and
+they resemble actual workflow tasks. For the specification, the system will
+generate a multi-user web application. 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.
-\Gls{iTasks} has proven to be useful in many fields of operation such as
+\Gls{iTasks} has shown 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 functions for generating function for
-the given types. This results in the programmer having to do very little
-implementation work on details such as user interfaces.
+and is built on generic functions that generate functionality for the given
+types. This results in the programmer having to do very little implementation
+work on details such as user interfaces. It is possible to change the derived
+functions and adapt them to needs.
\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
+tasks but the modelling is applied on a high level. Therefore, it is difficult
to connect \gls{iTasks}-\glspl{Task} to real world tasks and allow them
-to interact. A lot of the actual tasks could very well be performed by small
+to interact. A lot of the actual tasks could very well be performed by
\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.
First, an adapter for a specific device can be written as a
\glspl{SDS}\footnote{Similar as to resources such as time are available in the
current \gls{iTasks} implementation.}. \glspl{SDS} can interact with the world
-and thus with hardware, allowing it to communicate with any type of device.
+and thus with hardware, allowing communication with any type of device.
However, this requires a tailor-made \gls{SDS} for every specific device and
-does not allow logic to be changed. Once a device is programmed to serve as an
-\gls{SDS}, it has to behave like that forever. Thus, this solution is not
-suitable for dynamic systems.
+functionality and does not allow logic to be changed. Once a device is
+programmed to serve as an \gls{SDS}, it has to behave like that forever. Thus,
+this solution is not suitable for systems that can send \glspl{Task} to
+the device dynamically.
The second method uses the novel contribution to \gls{iTasks} by Oortgiese et
al. They lifted \gls{iTasks} from a single server model to a distributed server
architecture~\cite{oortgiese_distributed_2017}. As a proof of concept, an
android app has been created that runs an entire \gls{iTasks} core and is able
to receive \glspl{Task} from a different server and execute them. While android
-often runs on small \gls{ARM} devices, they are a lot more powerful that the
-average \gls{IoT} microcontroller. Running the entire \glspl{iTasks} core on a
+often runs on small \gls{ARM} devices, they are a lot more powerful than the
+average \gls{IoT} microcontroller. The system is suitable for dynamically
+sending \glspl{Task} but running the entire \gls{iTasks} core on a
microcontroller is not feasible. Even if it would be possible, this technique
would still not be suitable because a lot of communication overhead is needed
to transfer the \glspl{Task}. \gls{IoT} devices are often connected to the
server through \emph{Low Power Low Bandwidth} which is unsuitable for
transferring a lot of data.
-The novel system that has been devised that bridges the gap between the
-aforementioned solutions. The system consists of updates to the
+The novel system that has been devised bridges the gap between the
+aforementioned solutions for adding \gls{IoT} to \gls{iTasks}. The system
+consists of updates to the
\gls{mTask}-\gls{EDSL}~\cite{koopman_type-safe_nodate}, a new communication
protocol, device application and an \gls{iTasks} server application. The system
supports devices as small as \gls{Arduino}
Devices in the \gls{mTask}-system can run small imperative programs written in
the \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
device at runtime, avoiding recompilation and thus write cycles on the program
-memory.
+memory. This solution extends the reach of \gls{iTasks} and allows closer
+resemblance of \glspl{Task} to actual tasks. Moreover, it tries to solve some
+integration problems in \gls{IoT} by allowing all components to be programmed
+from one source.
repositories / msc-thesis1617.git / commitdiff