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
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.
\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.''
~\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}
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.
repositories / msc-thesis1617.git / commitdiff