update even more

diff --git a/conclusion.conclusion.tex b/conclusion.conclusion.tex
index 03d9af5..9a706b6 100644 (file)
--- a/conclusion.conclusion.tex
+++ b/conclusion.conclusion.tex
@@ -33,4 +33,5 @@ extension, a programmer can create an entire \gls{IoT} system from one source
 that reaches all layers of the \gls{IoT} architecture. However, this does not
 limit the applications and makes them static. Components can be updated
 individually without causing integration problems. Devices can be repurposed
 that reaches all layers of the \gls{IoT} architecture. However, this does not
 limit the applications and makes them static. Components can be updated
 individually without causing integration problems. Devices can be repurposed

-just by sending new \glspl{Task} to it.
+just by sending new \glspl{Task} to it. Most importantly, it gives an insight
+in the possibilities of adding \gls{IoT} to \gls{TOP} programs.

diff --git a/conclusion.discussion.tex b/conclusion.discussion.tex
index 90a91d3..49f59ac 100644 (file)
--- a/conclusion.discussion.tex
+++ b/conclusion.discussion.tex
@@ -1,5 +1,6 @@
-The system is still a crude prototype and a proof of concept. Improvements and
-extension for the system are amply available in several fields of study.
+The novel system is functional but still a crude prototype and a proof of
+concept. The system shows potential but improvements and extensions for the
+system are amply available in several fields of study.

 
 \subsection{Simulation}
 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
 
 \subsection{Simulation}
 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that

diff --git a/intro.intro.tex b/intro.intro.tex
index 7a9bae4..e8602b3 100644 (file)
--- a/intro.intro.tex
+++ b/intro.intro.tex
@@ -12,7 +12,7 @@ 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
 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
 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


@@ -28,38 +28,40 @@ 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.
 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
 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
 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}
 
 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
 
 \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
 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.

diff --git a/intro.problem.tex b/intro.problem.tex
index 921e0e5..1488b9e 100644 (file)
--- a/intro.problem.tex
+++ b/intro.problem.tex
@@ -1,7 +1,7 @@
 \Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow
 \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 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.
 
 \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.
 


@@ -11,27 +11,30 @@ 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
 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
 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
 
 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.
 
 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}
 \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}


@@ -40,4 +43,7 @@ paradigms and patterns as regular \glspl{Task} in the \gls{TOP} paradigm.
 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
 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.