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
 \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},
 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.
 \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.
 
 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
 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.
 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
 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
 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{%
 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
 
 \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