up
authorMart Lubbers <mart@martlubbers.net>
Wed, 12 Jul 2017 10:31:25 +0000 (12:31 +0200)
committerMart Lubbers <mart@martlubbers.net>
Wed, 12 Jul 2017 10:31:25 +0000 (12:31 +0200)
arch.example.tex
conclusion.conclusion.tex
intro.problem.tex
intro.related.tex

index 7b773ba..9dced25 100644 (file)
@@ -5,7 +5,7 @@ the user --- and they are then connected. When all devices are registered, the
 \gls{mTask}-\glspl{Task} can be sent and \gls{iTasks}-\glspl{Task} can be
 started to monitor the output. When everything is finished, the devices are
 removed and the system is shut down. To illustrate this, a demo blinking
-application is shown in Listing~\ref{lst:frameword}. The application is a
+application is shown in Listing~\ref{lst:framework}. The application is a
 complete \gls{iTasks} application.
 
 \begin{lstlisting}[language=Clean,label={lst:framework},
index 6845813..0491db8 100644 (file)
@@ -26,3 +26,11 @@ device suddenly becomes unusable, the \gls{iTasks} system can reassign a new
 \gls{Task} without needing to recompile the code. It also showed that adding
 peripherals is not a time consuming task and does not even requires
 recompilation of clients not having the peripheral.
+
+The new functionality extends the reach of \gls{iTasks} by adding \gls{IoT}
+functionality and allowing devices to run \gls{mTask}-\glspl{Task}. With this
+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. Components can be updated individually without causing
+integration problems. Devices can be repurposed just by sending new
+\glspl{Task} to it.
index 5664a6f..921e0e5 100644 (file)
@@ -30,16 +30,14 @@ 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
-can run on devices as small as \gls{Arduino}
+The novel system that has been devised that bridges the gap between the
+aforementioned solutions. 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}
 microcontrollers~\cite{noauthor_arduino_nodate} and operates via the same
 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
-an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
+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.
index e2af6e2..bca403f 100644 (file)
@@ -3,12 +3,16 @@ For example, microcontrollers such as the \gls{Arduino} can be remotely
 controlled by the \gls{Firmata}-protocol\footnote{``firmata/protocol:
 Documentation of the Firmata protocol.''
 (\url{https://github.com/firmata/protocol}). [Accessed: 23-May-2017].}. This
-protocol is designed to expose the peripherals such as sensors to the server.
+protocol is designed to expose the peripherals such as sensors to a server.
 This allows very fine grained control but with the cost of excessive
-communication overhead since no code is executed on the device, only the
+communication overhead since no code is executed on the device itself, only the
 peripherals are queried. A \gls{Haskell} implementation of the protocol is
 also available\footnote{``hArduino by LeventErkok.'' (\url{%
-https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}.
+https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}. The
+hardware requirements for running a \gls{Firmata} client are very low. However,
+the communication requirements are high and therefore it is not suitable for
+\gls{IoT} applications that operate through specialized \gls{IoT} networks
+which often have low bandwidth and low power properties.
 
 \Gls{Clean} has a history of interpretation and there is a lot of research
 happening on the intermediate language \gls{SAPL}. \Gls{SAPL} is a purely