From 3bc980446b86f187a2af8b4a679f15c58bdca8f2 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Mon, 8 May 2017 13:45:52 +0200 Subject: [PATCH] small introduction update --- abstract.tex | 4 ++-- introduction.tex | 53 ++++++++++++++++++++++++------------------------ 2 files changed, 29 insertions(+), 28 deletions(-) diff --git a/abstract.tex b/abstract.tex index 5030daf..c4bb5e4 100644 --- a/abstract.tex +++ b/abstract.tex @@ -1,7 +1,7 @@ This thesis presents a way to connect small \gls{IoT} devices with high level \gls{TOP} implementations languages. It shows how a new frontend for the class -based shallowly \glspl{EDSL} called \gls{mTask} written in \gls{Clean} -can be used to compile \gls{IoT}-tasks on the fly and send them to the device +based shallowly \gls{EDSL} called \gls{mTask} written in \gls{Clean} +can be used to compile \gls{IoT}-tasks on the fly and send them to devices as interpretable bytecode. All of this adheres to the \gls{TOP} philosophy where familiar concepts such as \glspl{SDS} and task-combinators are available at ease. diff --git a/introduction.tex b/introduction.tex index 6ec3e65..c2ee7bc 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,42 +1,43 @@ \section{Introduction} The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a -high abstraction level of real life workflow tasks. Through an \gls{EDSL} that -programmers can model workflow tasks. The system will then generate a -multi-user web service. This web service can be accessed through a browser and -used to complete these \glspl{Task}. Familiar workflow patterns like sequence, -parallel and conditional tasks can be modelled. From the \gls{Task} description -the system will generate an multi-user web application for real life tasks. +high abstraction level for real life workflow tasks. These workflow tasks can be +described through an \gls{EDSL} and modeled as \glspl{Task} +From the specification the system will then generate a multi-user web service. +This web service can be accessed through a browser and used to complete these +\glspl{Task}. Familiar workflow patterns like sequence, parallel and +conditional tasks can be modelled using combinators. -\gls{iTasks} has been shown 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. However, while the -tasks in the \gls{iTasks} system model after real life workflow tasks the -modelling is very high level. It is difficult to connect actual tasks to the -real tasks and let them interact. A lot of the actual tasks can be -\emph{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. +\gls{iTasks} has been shown 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. +However, while the tasks in the \gls{iTasks} system model after real life +workflow tasks the modelling is very high level. It is difficult to connect +actual tasks to the real tasks and let them interact. A lot of the actual tasks +can be \emph{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, in principle, can be written as \glspl{SDS}\footnote{Similar as to resources such as time are available in the current \gls{iTasks} implementation} but this requires a very specific -adapter to be written for every device and functionality. Moreover, this does -not allow you to build in logic into the device. A lot of the 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 +adapter to be written for every device and functionality. However, this forces +a fixed logic in the device that is set at compile time. A lot of the 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~\cite{oortgiese_distributed_2017} that is also -runnable on smaller devices like \acrshort{ARM}. However, this is limited to -fairly high performance devices that are equipped with high speed communication -lines. Devices in \gls{IoT} often only have \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. +runnable on smaller devices like \acrshort{ARM} devices. However, this is +limited to fairly high performance devices that are equipped with high speed +communication channels. Devices in \gls{IoT} often only have \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. \glspl{mTask} will bridge this gap by introducing a new communication protocol, -device server application and \glspl{Task} synchronizing the formers. +device application and \glspl{Task} synchronizing the formers. The system can run on devices as small as Arduino microcontrollers and operates via the same paradigms and patterns as regular \glspl{Task}. \glspl{mTask} can run small imperative programs written in a \gls{EDSL} and -have access to \glspl{SDS}. +have access to \glspl{SDS}. In this way \glspl{Task} can be sent to the device +at runtime and information can be exchanged. \section{Document structure} The structure of the thesis is as follows. -- 2.20.1