From 7d430f47a575566d56625b3e8641fb78171a1f08 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 26 Jun 2017 13:19:08 +0200 Subject: [PATCH] Camil's comments: chapter 1 --- glossaries.tex | 1 - introduction.tex | 91 +++++++++++++++++++++++++----------------------- 2 files changed, 47 insertions(+), 45 deletions(-) diff --git a/glossaries.tex b/glossaries.tex index 2707992..6c3d258 100644 --- a/glossaries.tex +++ b/glossaries.tex @@ -51,7 +51,6 @@ \newglossacr{IoT} {Internet of Things} \newglossacr{JSON} {JavaScript Object Notation} \newglossacr{LCD} {Liquid Crystal Display} -\newglossacr{LTN} {Low Throughput Network} \newglossacr{RFID} {Radio-Frequency Identification} \newglossacr{RISC} {Reduced Instruction Set Computer} \newglossacr{RWST} {Reader Writer State Transformer Monad} diff --git a/introduction.tex b/introduction.tex index 83fca1e..64cdc92 100644 --- a/introduction.tex +++ b/introduction.tex @@ -3,11 +3,11 @@ and transforms the way we 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 +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}\footnote{e.g.\ the American -\gls{GPS} or the Russian \gls{GLONASS}} and actuators% -~\cite{da_xu_internet_2014}. With these new technologies information +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 @@ -15,50 +15,53 @@ consumer ready fitness tracker watch can be bought that tracks heartbeat and respiration levels. The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer -a high abstraction level for real life 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 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 sequence, parallel and conditional \glspl{Task} can be modelled using -combinators. +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 been proven to be useful in many fields of operation such as +\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. +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. 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 can still contain -decision making. 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. -Devices in \gls{IoT} often have only \gls{LTN} communication with low bandwidth -and a very limited amount of processing power and are therefore not suitable to -run an entire \gls{iTasks} core. +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 +powerfull 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. \section{Problem statement} The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will -bridge this gap 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} 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 device at runtime, avoiding recompilation and thus write cycles -on the program memory. +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} +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 +device at runtime, avoiding recompilation and thus write cycles on the program +memory. \section{Document structure} The structure of this thesis is as follows. @@ -96,7 +99,7 @@ following git repository: \url{https://git.martlubbers.net/mTask.git} \section{Related work} -Similar research has been conducted concerning these matters. +Similar research has been conducted on the subject. 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.'' @@ -115,7 +118,7 @@ functional intermediate language that has interpreters written in ~\cite{domoszlai_implementing_2011} and \gls{Clean} and \gls{Haskell} compiler backends~\cite{domoszlai_compiling_2012}. However, interpreting the resulting code is still heap-heavy and therefore not directly suitable for devices with -as little as $2K$ of RAM such as the \gls{Arduino} \emph{UNO}. It might be +as little as $2K$ of RAM such as the \gls{Arduino} \emph{Uno}. It might be possible to compile the \gls{SAPL} code into efficient machine language or \gls{C} but then the system would lose its dynamic properties since the microcontroller then would have to be reprogrammed every time a new \gls{Task} @@ -137,7 +140,7 @@ automotive industry to program parts of an autopilot% is deeply embedded but the type system is shallowly embedded. This requires several \gls{Haskell} extensions that offer dependent type constructions. The process of compiling an \gls{Ivory} program happens in stages. The embedded -code is transformed into an \gls{AST} that is sent to a backend. The -\gls{mTask} \gls{EDSL} transforms the embedded code during compile-time -directly into the backend which is often a state transformer that will execute -on runtime. +code is transformed into an \gls{AST} that is sent to a backend. In the new +system, the \gls{mTask} \gls{EDSL} transforms the embedded code during +compile-time directly into the backend which is often a state transformer that +will execute on runtime. -- 2.20.1