+\subsection{Internet of Things}
\Gls{IoT} technology is emerging rapidly. It offers myriads of solutions
-and transforms the way we interact with technology.
+and is transforming the way people interact with technology.
-Initially the term was coined to describe \gls{RFID} devices and the
-communication between them. However, currently the term \gls{IoT} encompasses
-all small devices that communicate with each other and the world. 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 and bandwidth. Moreover, \gls{IoT}
-technology is coming into people's homes, clothes and
-healthcare~\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 term \gls{IoT} was coined around 1999 to describe \gls{RFID} devices and
+the communication between them. After a small slumber of the term, it
+resurfaced recently and has changed definition slightly. In the current day and
+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
+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
+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 architecture of \gls{IoT} systems is often divided into layers. A very
+popular division is the four layer architecture but there are also proponents
+of a five layer structure. The first layer of the four layer architecture is
+the sensing layer. This layer contains the actual sensing and acting hardware.
+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}. The second layer of \gls{IoT} is the networking
+layer and is responsible for connecting the first layer with the outer world.
+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 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, 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 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} 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 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.
-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 shown to be useful in many fields of operation such as
+incident management~\cite{lijnse_top_2013}. \Gls{iTasks} is highly type driven
+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.
repositories / msc-thesis1617.git / blobdiff