From: Mart Lubbers Date: Tue, 11 Jul 2017 12:28:24 +0000 (+0200) Subject: helicopter X-Git-Tag: final~7 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=dc8920a5b44e56e1c2dd941f1833bb03aa4da28e;p=msc-thesis1617.git helicopter --- diff --git a/intro.doc.tex b/intro.doc.tex index e311372..d3f66a1 100644 --- a/intro.doc.tex +++ b/intro.doc.tex @@ -5,22 +5,28 @@ related work and the structure of the document. Chapter~\ref{chp:top} 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:\\ diff --git a/intro.intro.tex b/intro.intro.tex index 4738d85..fd7f265 100644 --- a/intro.intro.tex +++ b/intro.intro.tex @@ -9,11 +9,11 @@ age, \gls{IoT} encompasses all small devices that communicate with each other 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. @@ -26,60 +26,40 @@ In a smart electricity meter, this layer would contains the sensors detecting 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. diff --git a/intro.problem.tex b/intro.problem.tex index cfb8494..5664a6f 100644 --- a/intro.problem.tex +++ b/intro.problem.tex @@ -1,3 +1,38 @@ +\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