From: Mart Lubbers Date: Wed, 12 Jul 2017 19:21:38 +0000 (+0200) Subject: update even more X-Git-Tag: final X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=5e2e016768ff6575b400955a573ca1ed9fec1b6b;p=msc-thesis1617.git update even more --- diff --git a/conclusion.conclusion.tex b/conclusion.conclusion.tex index 03d9af5..9a706b6 100644 --- 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 -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 --- 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 diff --git a/intro.intro.tex b/intro.intro.tex index 7a9bae4..e8602b3 100644 --- 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 -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 @@ -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. -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. diff --git a/intro.problem.tex b/intro.problem.tex index 921e0e5..1488b9e 100644 --- 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 -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. @@ -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 -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} @@ -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 -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.