\newacronym{SDS}{SDS}{Shared Data Source}
\newacronym{IoT}{IoT}{Internet of Things}
\newacronym{TOP}{TOP}{Task Oriented Programming}
-\newacronym{EDSL}{(E)DSL}{(Embedded) Domain Specific Language}
+\newacronym{EDSL}{EDSL}{Embedded Domain Specific Language}
\newacronym{RISC}{RISC}{Reduced Instruction Set Computer}
\newacronym{ARM}{ARM}{Acorn \acrshort{RISC} Machine}
\newacronym{LTN}{LTN}{Low Throughput Network}
\newacronym{IDE}{IDE}{Integrated Development Environment}
\newacronym{TCP}{TCP}{Transmission Control Protocol}
\newacronym{RFID}{RFID}{Radio-Frequency Identification}
-\newacronym{GPS}{GPS}{Global Positioning System}
+\newacronym{GNSS}{GNSS}{Global Navigation SAtellite System}
\newacronym{LCD}{LCD}{Liquid Crystal Display}
\newacronym{AST}{AST}{Abstract Syntax Tree}
+\newacronym{GPS}{GPL}{Global Positioning System}
+\newacronym{GLONASS}{GLONASS}{Global Navigationo Satellite System}
\section{General message format}
Messages are delimited by newlines to make processing by line based devices
-more easy. Message exchanges have a \emph{Request} and \emph{Response} header.
+easier. Message exchanges have a \emph{Request} and \emph{Response} header.
The \emph{Request} header means that the server is sending to the client. The
\emph{Response} header means that the client is sending to the server. In some
cases either the \emph{Request} or \emph{Response} is empty. This means that
The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
as close as possible.
-The host language has a very efficient compiler and code generator the
-\gls{mTask}-system is also relatively fast because the compilation of
+The host language has a very efficient compiler and code generator. Therefore,
+the \gls{mTask}-system is also relatively fast because the compilation of
\glspl{mTask} is nothing more than running some functions in the host language.
The dynamic nature allows the microcontroller to be programmed once and used
generating \gls{C} code are not usable for dynamic \gls{Task} environments.
The dynamic nature also allows the programmer to design fail-over mechanisms.
When a device is assigned a \gls{Task} but another device suddenly becomes
-unusable the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
+unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
the first device that possibly takes over some of the functionality of the
broken device without needing to recompile the code.
\section{Introduction}
\Gls{IoT} technology is emerging very quickly and offers myriads of solutions
-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 all small devices that
-communicate with each other and the world often containing sensors, \gls{GPS}
-and actuators\cite{da_xu_internet_2014}. With these new technologies
-information can be tracked very accurately using very little power and
-bandwidth. Moreover, \gls{IoT} technology is coming into people's homes,
-clothes and in healthcare\cite{riazul_islam_internet_2015}. For example, for a
-couple of tens of euros a consumer ready fitness tracker watch can be bought
-that tracks heartbeat and respiration levels.
+and transforms the way we interact with technology.
-The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
-high abstraction level for real life workflow tasks%
+Initially the term was coined to describe \gls{RFID} devices and the
+communication between them. However, currently the term \gls{IoT} encompasses
+all small devices that communicate with each other and the world. These devices
+often contain 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 can be tracked very accurately using very little
+power and bandwidth. Moreover, \gls{IoT} technology is coming into people's
+homes, clothes and in healthcare\cite{riazul_islam_internet_2015}. For example,
+for a few euros a 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} From the specification the system
-will then generate a multi-user web service. This web service is accessed
-through a browser and used to complete these \glspl{Task}. Familiar workflow
+an \gls{EDSL} and modeled as \glspl{Task}. The system will generatea multi-user
+web service 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 tasks can be modelled using
combinators.
-\gls{iTasks} has been shown to be useful in many fields of operation such as
+\gls{iTasks} has been 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 very high level. Therefore it is
-difficult to connect \gls{iTasks} tasks to the real world tasks and let them
-interact. A lot of the actual tasks could be \emph{performed} by small
+difficult to connect \gls{iTasks}-\glspl{Task} to real world tasks and let
+them interact. A lot of the actual tasks could 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. However, this forces
+adapter to be written for every device and function. 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 that is also runnable on smaller devices like
\acrshort{ARM} devices\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 only have \gls{LTN}
+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.
The updates to the \gls{mTask}-system will bridge this gap by introducing a new
communication protocol, device application and \glspl{Task} synchronizing the
formers. The system can run on devices as small as \gls{Arduino}
-microcontrollers% \cite{noauthor_arduino_nodate} and operates via the same
+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 \glspl{mTask}-system can run small imperative programs written
in an \gls{EDSL} and have access to \glspl{SDS}. \Glspl{Task} are sent to the
memory.
\section{Document structure}
-The structure of the thesis is as follows.
+The structure of this thesis is as follows.
+
Chapter~\ref{chp:introduction} contains the problem statement, motivation,
literature embedding and the structure of the document.
Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and
devices.
\section{Relevant research}
-Several types of similar research has been conducted of these matters.
+Several types of similar research has been conducted concerning these matters.
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. This
-allows very fine grained control but with the cost of a big communication
+allows very fine grained control but with the cost of excessive communication
overhead since no code is executed on the device, only the peripherals are
queried. A \gls{Haskell} implementation of the protocol has been created%
\footnote{``hArduino by LeventErkok.'' (\url{%
code is still heap-heavy therefore not directly suitable for devices with as
few as $2K$ of RAM such as the \gls{Arduino}. It might be possible to compile
the \gls{SAPL} code into efficient machine language or \gls{C} but then the
-system would lose the dynamic properties since the microcontroller then has to
-be reprogrammed every time a new \gls{Task} is sent to the device.
+system would lose its dynamic properties since the microcontroller then would
+has to be reprogrammed every time a new \gls{Task} is sent to the device.
-\Gls{EDSL} have been used to generate \gls{C} code a lot for microcontroller
-environment. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
+\Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller
+environments. For starters, this work is built upon the \gls{mTask}-\gls{EDSL}
that generates \gls{C} code to run a \gls{TOP}-like system on microcontrollers%
\cite{plasmeijer_shallow_2016}.\cite{koopman_type-safe_nodate}.
Again, this requires a reprogramming cycle every time the
Another \gls{EDSL} designed to generate low-level high-assurance programs is
called \gls{Ivory} and uses \gls{Haskell} as a host language%
\cite{elliott_guilt_2015}. The language uses the \gls{Haskell} type-system to
-make unsafe languages type safe. \gls{Ivory} has been used in for example the
+make unsafe languages type safe. For example, \gls{Ivory} has been used in the
automotive industry to program parts of an autopilot%
\cite{pike_programming_2014}\cite{hickey_building_2014}. \Gls{Ivory}'s syntax
is deeply embedded but the type system is shallowly embedded. This requires
| Eq DSL
\end{lstlisting}
Deep embedding has the advantage that it is very simple to build and the views
-are easy to make and add. However, there are also a few downsides. The
-expressions created with this language are not type-safe. In the given language
-it is possible an expression such as \CI{Plus (LitI 4) (LitB True)} which to
-add a boolean to an integer. Evermore so, extending the \gls{ADT} is easy and
-convenient but extending the views accordingly is tedious and has to be done
-individually for all views.
+are easy to make and add. To the downside, the expressions created with this
+language are not type-safe. In the given language it is possible an expression
+such as \CI{Plus (LitI 4) (LitB True)} which to add a boolean to an integer.
+Evermore so, extending the \gls{ADT} is easy and convenient but extending the
+views accordingly is tedious and has to be done individually for all views.
The first downside of the type of \gls{EDSL} can be overcome by using
\glspl{GADT}\cite{cheney_first-class_2003}. Listing~\ref{lst:exdeepgadt} shows
supported in the current version of \gls{Clean} and therefore the syntax is
artificial. However, it has been shown that \glspl{GADT} can be simulated using
bimaps or projection pairs\cite{cheney_lightweight_2002}. Unfortunately the
-lack of extendability stays a problem. If a language construct is added no
+lack of extendability remains a problem. If a language construct is added, no
compile time guarantee is given that all views support it.
\begin{lstlisting}[language=Clean,label={lst:exdeepgadt},%
Eq x y = \e->x e + y e
\end{lstlisting}
-The advantage of shallowly embedding a language in a host language is the
+The advantage of shallowly embedding a language in a host language is its
extendability. It is very easy to add functionality and compile time checks
-guarantee that the functionality is available. Moreover, the language is type
-safe as it is directly typed in the host language.
+of the host language guarantee whether the functionality is available when used.
+Moreover, the language is type safe as it is directly typed in the host
+language.
-The downside of this method is extending the language with views. It is near
+The downside of this method is extending the language with views. It is nearly
impossible to add views to a shallowly embedded language. The only way of
achieving this is by decorating the datatype for the \gls{EDSL} with all the
information for all the views. This will mean that every component will have to
-implement all views. This makes it slow for multiple views and complex to
+implement all views rendering it slow for multiple views and complex to
implement.
\section{Class based shallow embedding}
The third type of embedding is called class based shallow embedding and has the
-best of both shallow and deep embedding. In class based shallow embedding the
-language constructs are defined as type classes. The same language is shown
+advantages of both shallow and deep embedding. In class based shallow embedding
+the language constructs are defined as type classes. The same language is shown
with the new method in Listing~\ref{lst:exclassshallow}.
This type of embedding inherits the easiness of adding views from shallow
type as is necessary. Lastly, extensions can be added easily, just as in
shallow embedding. When an extension is made in an existing class, all views
must be updated accordingly to prevent possible runtime errors. When an
-extension is added in a new class this problem does not arise and views can
+extension is added in a new class, this problem does not arise and views can
choose to implement only parts of the collection of classes.
\begin{lstlisting}[language=Clean,label={lst:exclassshallow},%
boolean expressions and arithmetic expressions. The class of arithmetic
language constructs also contains the function \CI{lit} that lifts a
host-language value in to the \gls{EDSL} domain. All standard arithmetic
-functions are included but are omitted for brevity. Moreover the class
-restrictions are only shown in the first functions and are later omitted. Both
-the boolean expression and arithmetic expression classes are shown in
-Listing~\ref{lst:arithbool}.
+functions are included in the \gls{EDSL} but are omitted in the example for
+brevity. Moreover, the class restrictions are only shown in the first functions
+and omitted in subsequent funcitons. Both the boolean expression and arithmetic
+expression classes are shown in Listing~\ref{lst:arithbool}.
\begin{lstlisting}[language=Clean,label={lst:arithbool},
caption={Basic classes for expressions}]
\section{Control flow}
Looping of \glspl{Task} happens because \glspl{Task} are launched at regular
intervals or relaunch themselves. Therefore there is no need for loop control
-flow functionality such as \CI{While} or \CI{For} constructions. The main
-control flow is the sequence operator and the \CI{If} statement. Both are shown
-in Listing~\ref{lst:control}. The first class of \CI{If} statements describe
-the regular if statement. The expressions given can have any role. The
-functional dependency on \CI{s} determines the return type of the statement.
-The sequence operator is very straightforward and just ties the two expressions
-together in sequence.
+flow functionality such as \emph{while} or \emph{for} constructions. The main
+control flow is the sequence operator and the \emph{if} statement. Both are
+shown in Listing~\ref{lst:control}. The first class of \emph{If} statements
+describe the regular \emph{if} statement. The expressions given can have any
+role. The functional dependency on \CI{s} determines the return type of the
+statement. The sequence operator is very straightforward and just ties the two
+expressions together in sequence.
\begin{lstlisting}[%
language=Clean,label={lst:control},caption={Control flow operators}]
\end{lstlisting}
A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve
-as variables in the \gls{mTask} and will keep their value across executions.
+as variables in the \gls{mTask} and maintain their value across executions.
The classes associated with \glspl{SDS} are listed in
Listing~\ref{lst:sdsclass}. The \CI{Main} class is introduced to box an
\gls{mTask} and make it recognizable by the type system.
\section{Example mTask}
\todo{Also explain semantics about running tasks}
-Some example \glspl{mTask} using almost all of the functionality are show in
+Some example \glspl{mTask} using almost all of the functionality are shown in
Listing~\ref{lst:exmtask}. The \glspl{mTask} shown in the example do not belong
to a particular view and therefore are of the type \CI{View t r}. The
\CI{blink} \gls{mTask} show the classic \emph{Arduino} \emph{Hello World!}
-application that blinks a certain LED every interval. The \CI{thermostat}
+application that blinks a certain LED at each interval. The \CI{thermostat}
\gls{mTask} will enable a digital pin powering a cooling fan when the analog
pin representing a temperature sensor is too high. \CI{thermostat`} shows the
same program but now using the assignment style \gls{GPIO}.
\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just
-a function that, given some state, returns the observable \CI{TaskValue}. The
+a function that --- given some state --- returns the observable \CI{TaskValue}. The
\CI{TaskValue} of a \CI{Task} can have different states. Not all state
transitions are possible as shown in Figure~\ref{fig:taskvalue}. Once a value
is stable it can never become unstable again. Stability is often reached
filled in and therefore the \CI{TaskValue} remains \CI{Unstable}. In the third
image all fields are entered and the \CI{TaskValue} transitions to the
\CI{Unstable} state. When the user presses \emph{Continue} the value becomes
-\CI{Stable} and can not be changed any further.
+\CI{Stable} and cannot be changed any further.
\begin{figure}[H]
\centering
\Glspl{Task} can be combined using so called \gls{Task}-combinators.
Combinators describe relations between \glspl{Task}. \Glspl{Task} can be
combined in parallel, sequenced and their result values can be converted to
-\glspl{SDS}. Moreover, a very important combinator is the step combinator that
-starts a new task according to the \CI{TaskValue}. The type signatures of the
-basic combinators are shown in Listing~\ref{lst:combinators}.
+\glspl{SDS}. Moreover, a very important combinator is the step combinator which
+starts a new task according to specified predicates on the \CI{TaskValue}.
+Type signatures of the basic combinators are shown in
+Listing~\ref{lst:combinators}.
\begin{itemize}
\item Step:
The step combinator is used to start \glspl{Task} when a predicate on
- the \CI{TaskValue} holds or an action has been taken place. The bind
+ the \CI{TaskValue} holds or an action has taken place. The bind
operator can be written as a step combinator.
\begin{lstlisting}[language=Clean]
(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
\section{Devices}
The client code for the devices is compiled from one codebase. For a device to
-be eligible for \glspl{mTask} it must be able to compile the shared codebase
+be eligible for \glspl{mTask}, it must be able to compile the shared codebase
and implement (part of) the device specific interface. The shared codebase only
uses standard \gls{C} and no special libraries or tricks are used. Therefore
the code is compilable for almost any device or system. Note that it is not
-needed to implement a full interface. The full interface excluding the device
-specific settings is listed in Appendix~\ref{app:device-interface}. The
-interface works in a similar fashion as the \gls{EDSL}. Devices do not have to
-implement all functionality, this is analogous to the fact that views do not
+needed to implement a full interface. The full interface --- excluding the
+device specific settings --- is listed in Appendix~\ref{app:device-interface}.
+The interface works in a similar fashion as the \gls{EDSL}. Devices do not have
+to implement all functionality, this is analogous to the fact that views do not
have to implement all type classes in the \gls{EDSL}. When the device connects
for the first time with a server the specifications of what is implemented is
communicated.
device has a specific resource that is used to connect to the device. The
current system supports connecting devices via a serial connection and via a
\gls{TCP} connection. Every device has the type \CI{MTaskDevice} and which
-is listed in Listing~\ref{lst:mtaskdevice}. When a device is added a background
-task is started that runs the \CI{synFun}. The \CI{synFun} is the task that
+is listed in Listing~\ref{lst:mtaskdevice}. When a device is added, a background
+\gls{Task} is started that runs the \CI{synFun}. The \CI{synFun} is the task that
synchronizes the channel \gls{SDS} with the actual device. For the \gls{TCP}
device this is a simple \CI{tcpconnect}. The \CI{TaskId} of the background task
is saved to be able to stop the task in the future. When the task is unable to
, deviceTasks :: [MTaskTask]
, deviceData :: MTaskResource
, deviceSpec :: Maybe MTaskDeviceSpec
+ , deviceShares :: [MTaskShare]
}
class MTaskDuplex a where
\glsaddall{}
%Abstract
+\addcontentsline{toc}{chapter}{Abstract}
\chapter*{\centering Abstract}
\begin{quotation}
\centering\noindent
\input{abstract}
\end{quotation}
+\addcontentsline{toc}{chapter}{Acknowledgements}
\chapter*{\centering Acknowledgements}
\begin{quotation}
\centering\it\noindent
%Table of contents
\tableofcontents
+\addcontentsline{toc}{chapter}{Glossaries \& Acronyms}
+\printglossaries%
+
\mainmatter{}
\glsresetall{}
\chapter{Introduction}\label{chp:introduction}
\lstlistoflistings{}
\endgroup
-\cleardoublepage{}
-\phantomsection{}
-\addcontentsline{toc}{chapter}{Glossaries \& Acronyms}
-\begingroup
-\let\clearpage\relax
-\let\cleardoublepage\relax
-\printglossaries%
-\endgroup
-
\end{document}
repositories / msc-thesis1617.git / commitdiff