introduces the reader to the basics of \gls{TOP} and \gls{iTasks}.
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
methods to create \gls{EDSL}. Chapter~\ref{chp:mtask} shows the existing
-\gls{mTask}-\gls{EDSL} on which is extended upon in this dissertation.
-Chapter~\ref{chp:system} gives an overview of the proposed system.
-Chapter~\ref{chp:mtaskcont} describes the view and functionality for the
+\gls{mTask}-\gls{EDSL} which is extended upon in this dissertation.
+Chapter~\ref{chp:system} gives an overview of the proposed system in the
+broadest sense.
+Chapter~\ref{chp:mtaskcont} describes the added view and functionality for the
\gls{mTask}-\gls{EDSL} that were added and used in the system.
Chapter~\ref{chp:arch} shows the implementation and considerations for entire
system. It covers the client software running on the device and the server
-written in \gls{iTasks}. Chapter~\ref{chp:conclusion} concludes by answering
-the research questions and discusses future research.
+written in \gls{iTasks}.
+Chapter~\ref{chp:conclusion} concludes by answering the research questions and
+discusses future research.
Appendix~\ref{app:communication-protocol} shows the concrete protocol used for
communicating between the server and client.
Appendix~\ref{app:device-interface} shows the concrete interface for the
devices.
+Some conventions have been kept throughout the document.
Text written using the \CI{Teletype} font indicates code and is often
-referring to a listing. \emph{Emphasized} text is used for proper nouns and
-words that have an unexpected meaning.
+referring to section of a listing. \emph{Emphasized} text is used for proper
+nouns and words that have an unexpected meaning. \textsc{Small caps} is
+used for branded acronyms. When the word Tasks is emphasized and capitalized,
+it refers to the task-entities from either the \gls{mTask} or the \gls{iTasks}
+system.
The complete source code of this thesis can be found in the following git
repository:\\
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.
+\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 tasks and allow them
+to interact. A lot of the actual tasks could very well 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 in two ways.
+
+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.
+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.
+
+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
+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.
+
+To solve this integration problem, a novel system is devised that bridges the
+gap between the aforementioned solutions.%TODO
+
The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will
bridge this gap in the current system by introducing a new communication
protocol, device application and \glspl{Task} synchronizing the two. The system
repositories / msc-thesis1617.git / commitdiff