Merge branch 'master' of git.martlubbers.net:msc-thesis1617
[msc-thesis1617.git] / intro.intro.tex
index fd7f265..e8602b3 100644 (file)
@@ -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 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.
+The separation of \gls{IoT} in layers is a difficulty when developing \gls{IoT}
+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 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.
+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.