output/*
img/fig-*
+*.acn
+*.acr
+*.alg
+*.aux
+*.bbl
+*.blg
+*.fmt
+*.glg
+*.glo
+*.gls
+*.ist
+*.lof
+*.log
+*.lol
+*.lot
+*.out
+*.pdf
+*.tdo
+*.toc
LATEXFLAGS:=\
-file-line-error\
-halt-on-error\
- -no-shell-escape\
- -output-directory=./output/
+ -no-shell-escape
FIGURES:=$(addsuffix .png,$(addprefix img/,$(notdir $(basename $(wildcard fig/*.dot)))))
LISTINGS:=$(wildcard listings/*)
.PHONY: all clean
.SECONDARY: $(addsuffix .fmt,$(DOCS)) $(FIGURES)
-all: $(addprefix output/,$(addsuffix .pdf,$(DOCS)))
+all: $(addsuffix .pdf,$(DOCS))
-output/%.fmt: %.pre
+%.fmt: %.pre
$(LATEX) $(LATEXFLAGS) -ini -jobname="$(basename $<)" "&$(LATEX) $<\dump"
-output/%.pdf: %.mlog
- if $(GREP) -iFq 'Rerun' $<; then $(LATEX) $(LATEXFLAGS) $(basename $<); fi
+%.pdf: %.mlog
+ if grep -Fiq "Rerun" $<; then $(LATEX) $(LATEXFLAGS) $(basename $<); fi
-%.mlog: %.tex output/%.fmt $(BIBS) $(TEXS) $(FIGURES) $(LISTINGS)
+%.mlog: %.tex %.fmt $(BIBS) $(TEXS) $(FIGURES) $(LISTINGS)
$(LATEX) $(LATEXFLAGS) $<
if $(GREP) -q '^\\bibdata{' $(basename $<).aux; then $(BIBTEX) $(BIBTEXFLAGS) $(basename $<); fi
if $(GREP) -q '\@istfilename' $(basename $<).aux; then $(MAKEGLOSSARIES) $(MAKEGLOSSARIESFLAGSFLAGS) $(basename $<); fi
img/%.png: fig/%.dot
dot -Tpng $< > $@
-clean:
- $(RM) output/* $(FIGURES)
+clean: $(addprefix clean-,$(DOCS))
+ $(RM) -v $(FIGURES)
+
+clean-%:
+ $(RM) -v $(addprefix $(@:clean-=).,acn acr alg aux bbl blg fmt glg glo\
+ gls ist lof log lol lot out pdf tdo toc)
\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.
+
The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a
-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 is 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.
+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
+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
\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 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.
+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
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 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}. In this way \glspl{Task} can be sent to the device
-at runtime and information can be exchanged.
+\section{Problem statement}
+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
+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
+device at runtime, avoiding recompilation and thus write cycles on the program
+memory.
\section{Document structure}
The structure of the 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
-\gls{iTasks}
+\gls{iTasks}.
Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding
methods to create \gls{EDSL}.
Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is
devices.
\section{Relevant research}
-\todo{Hier alle citaten en achtergrond doen}
-Ivory, firmata, dsl spul, etc.
+Several types of similar research has been conducted of 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
+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{%
+https://leventerkok.github.io/hArduino}). [Accessed: 23-May-2017].}
+
+\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
+functional intermediate language that has interpreters written in
+\gls{C++}\cite{jansen_efficient_2007} and \gls{Javascript}%
+\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 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.
+
+\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}
+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
+\gls{Task}-specification is changed.
+
+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 language type safe. \gls{Ivory} has been used in for example the
+automotive industry to program parts of an autopilot%
+\cite{pike_programming_2014}\cite{hickey_building_2014}. A dialect of the
+\gls{Ivory} called \gls{Tower} has also been created by the same authors which
+is has specific backends for \glspl{RTOS}.
-\section{\acrlong{EDSL}s}
There are several techniques available for creating \glspl{EDSL}. Each of
them have their own advantages and disadvantages such as extendability,
typedness and view support. In the following subsections each of the main
techniques are briefly explained.
-\subsection{Deep embedding}
+\section{Deep embedding}
A deep \gls{EDSL} means that the language is represented as an \gls{ADT}. Views
are functions that transform something to the datatype or the other way around.
As an example we have the simple arithmetic \gls{EDSL} shown in
| E.e: Eq (DSL e) (DSL e) -> DSL Bool & == e
\end{lstlisting}
-\subsection{Shallow embedding}
+\section{Shallow embedding}
In a shallowly \gls{EDSL} all language constructs are expressed as functions in
the host language. An evaluator view for our example language then looks
something like the code shown in Listing~\ref{lst:exshallow}. Note that much of
implement all views. This makes it slow for multiple views and complex to
implement.
-\subsection{Class based shallow embedding}
+\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
-\section{mTask}
The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The
\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support several views
such as an \gls{iTasks} simulation and a \gls{C}-code generator. The \gls{EDSL}
The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
therefore it is very suitable to have a new backend that partly implements the
-given classes. The following subsections show the details of the \gls{EDSL}
+given classes. The following sections show the details of the \gls{EDSL}
that are used in this extension. The parts of the \gls{EDSL} that are not used
will not be discussed and the details of those parts can be found in the cited
literature.
instance isExpr Expr
\end{lstlisting}
-\subsection{Semantics}
+\section{Semantics}
\gls{mTask} do not behave like functions but more like
\gls{iTasks}-\glspl{Task}. When an \gls{mTask} is created it returns immediatly
and the \gls{Task} will be executed sometime in the future. \glspl{Task} can
run at an interval and they can start other tasks.
\todo{Meer uitwijden over de mTask semantiek}
-\subsection{Expressions}
+\section{Expressions}
Expressions in the \gls{mTask}-\gls{EDSL} are divided into two types, namely
boolean expressions and arithmetic expressions. The class of arithmetic
language constructs also contains the function \CI{lit} that lifts a
(==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & ...
\end{lstlisting}
-\subsection{Control flow}
+\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
(:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
\end{lstlisting}
-\subsection{Input/Output and class extensions}
+\section{Input/Output and class extensions}
All expressions that have an \CI{Upd} role can be assigned to. Examples of such
expressions are \glspl{SDS} and \gls{GPIO}. Moreover, class extensions can be
created for specific peripherals such as user LEDs. The classes facilitating
sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
\end{lstlisting}
-\subsection{Example \gls{mTask}}
+\section{Example mTask}
\todo{Also explain semantics about running tasks}
Some example \glspl{mTask} using almost all of the functionality are show in
Listing~\ref{lst:exmtask}. The \glspl{mTask} shown in the example do not belong
-\section{\acrlong{TOP}}
-\subsection{\gls{iTasks}}
+\section{iTasks}
\gls{TOP} is a recent programming paradigm implemented as
\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
specialization instances for these functions and show an according interface.
Generated interfaces can be modified with decoration operators.
-\subsection{Combinators}
+\section{Combinators}
\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
(-&&-) infixr 4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
\end{lstlisting}
-\subsection{\acrlongpl{SDS}}
+\section{\acrlongpl{SDS}}
\Glspl{SDS} are an abstraction over resources that are available in the world
or in the \gls{iTasks} system. The shared data can be a file on disk, it can be
the time, a random integer or just some data stored in memory. The actual
-\section{Architecture}
-\subsection{Devices}
+\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
and implement (part of) the device specific interface. The shared codebase only
board that only boasts a meager \emph{2K} of \emph{RAM}.
\end{itemize}
-\subsection{Specification}
+\section{Specification}
Devices are stored in a record type and all devices in the system are stored in
a \gls{SDS} containing all devices. From the macro settings in the interface
file a profile is created for the device that describes the specification. When
}
\end{lstlisting}
-\subsection{Communication}
+\section{Communication}
The communication to and fro a device runs via a single \gls{SDS}. Every
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
year = {2002},
pages = {90--104},
file = {HW02.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/A8Z49NK6/HW02.pdf:application/pdf}
-}
\ No newline at end of file
+}
+
+@misc{noauthor_arduino_nodate,
+ title = {Arduino - {Open} {Source} {Products} for {Electronic} {Projects}},
+ url = {http://www.arduino.org/},
+ urldate = {2017-05-23},
+ file = {Arduino - Open Source Products for Electronic Projects:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/FPPFH7D2/www.arduino.org.html:text/html}
+}
+
+@article{riazul_islam_internet_2015,
+ title = {The {Internet} of {Things} for {Health} {Care}: {A} {Comprehensive} {Survey}},
+ volume = {3},
+ issn = {2169-3536},
+ shorttitle = {The {Internet} of {Things} for {Health} {Care}},
+ url = {http://ieeexplore.ieee.org/document/7113786/},
+ doi = {10.1109/ACCESS.2015.2437951},
+ urldate = {2017-05-23},
+ journal = {IEEE Access},
+ author = {Riazul Islam, S. M. and {Daehan Kwak} and Humaun Kabir, Md and Hossain, Mahmud and {Kyung-Sup Kwak}},
+ year = {2015},
+ pages = {678--708},
+ file = {07113786.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/7FNMPTHJ/07113786.pdf:application/pdf}
+}
+
+@article{plasmeijer_itasks:_2007,
+ title = {{iTasks}: executable specifications of interactive work flow systems for the web},
+ volume = {42},
+ number = {9},
+ journal = {ACM SIGPLAN Notices},
+ author = {Plasmeijer, Rinus and Achten, Peter and Koopman, Pieter},
+ year = {2007},
+ pages = {141--152},
+ file = {plar2007-ICFP07-iTasks.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/N8EUZP7D/plar2007-ICFP07-iTasks.pdf:application/pdf}
+}
+
+@misc{noauthor_firmata/protocol:_nodate,
+ title = {firmata/protocol: {Documentation} of the {Firmata} protocol.},
+ url = {https://github.com/firmata/protocol},
+ urldate = {2017-05-23},
+ file = {firmata/protocol\: Documentation of the Firmata protocol.:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/98HIGKIS/protocol.html:text/html}
+}
+
+@misc{noauthor_harduino_nodate,
+ title = {{hArduino} by {LeventErkok}},
+ url = {https://leventerkok.github.io/hArduino/},
+ urldate = {2017-05-23},
+ file = {hArduino by LeventErkok:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/JUDWSMV9/hArduino.html:text/html}
+}
+
+@article{jansen_efficient_2007,
+ title = {Efficient {Interpretation} by {Transforming} {Data} {Types} and {Patterns} to {Functions}},
+ volume = {7},
+ url = {https://books.google.com/books?hl=en&lr=&id=OyY3ioMJRAsC&oi=fnd&pg=PA73&dq=%22always+contain+special+constructs+for+data+types+and+pattern+matching%22+%22with+complexity+O(1),+instead+of+proportional+to+the+size+of+the%22+%22execution+of+certain+local+function+de%EF%AC%81nitions.+The+annotations+can%22+&ots=OytT5gnmgZ&sig=uvfA71YmRu64WdDn8hf7KjRSfqk},
+ urldate = {2017-05-23},
+ journal = {Trends in Functional Programming},
+ author = {Jansen, Jan Martin and Koopman, Pieter and Plasmeijer, Rinus},
+ year = {2007},
+ pages = {73},
+ file = {janj2007-TFP06-EfficientInterpretationOfSAPL.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/AQDI7QVE/janj2007-TFP06-EfficientInterpretationOfSAPL.pdf:application/pdf}
+}
+
+@inproceedings{domoszlai_compiling_2012,
+ title = {Compiling {Haskell} to {JavaScript} through {Clean}’s core},
+ url = {http://ac.inf.elte.hu/Vol_036_2012/117_36.pdf},
+ urldate = {2017-05-23},
+ booktitle = {Selected papers of 9th {Joint} {Conference} on {Mathematics} and {Computer} {Science} ({February} 2012)},
+ author = {Domoszlai, László and Plasmeijer, Rinus},
+ year = {2012},
+ file = {117_36.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/DMQC59C4/117_36.pdf:application/pdf}
+}
+
+@article{domoszlai_implementing_2011,
+ title = {Implementing a non-strict purely functional language in {JavaScript}},
+ volume = {3},
+ url = {https://www.researchgate.net/profile/Jan_Martin_Jansen2/publication/230607075_Implementing_a_non-strict_purely_functional_language_in_JavaScript/links/53fc40190cf22f21c2f3b28a.pdf},
+ urldate = {2017-05-23},
+ journal = {Acta Universitatis Sapientiae},
+ author = {Domoszlai, Laszlo and Bruel, Eddy and Jansen, Jan Martin},
+ year = {2011},
+ pages = {76--98},
+ file = {53fc40190cf22f21c2f3b28a.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/2EVHREI3/53fc40190cf22f21c2f3b28a.pdf:application/pdf}
+}
+
+@inproceedings{elliott_guilt_2015,
+ title = {Guilt free ivory},
+ volume = {50},
+ booktitle = {{ACM} {SIGPLAN} {Notices}},
+ publisher = {ACM},
+ author = {Elliott, Trevor and Pike, Lee and Winwood, Simon and Hickey, Pat and Bielman, James and Sharp, Jamey and Seidel, Eric and Launchbury, John},
+ year = {2015},
+ pages = {189--200},
+ file = {5678351608ae125516ee79c6.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/KJMFUH7T/5678351608ae125516ee79c6.pdf:application/pdf}
+}
+
+@inproceedings{hickey_building_2014,
+ title = {Building embedded systems with embedded {DSLs}},
+ isbn = {978-1-4503-2873-9},
+ url = {http://dl.acm.org/citation.cfm?doid=2628136.2628146},
+ doi = {10.1145/2628136.2628146},
+ language = {en},
+ urldate = {2017-05-23},
+ publisher = {ACM Press},
+ author = {Hickey, Patrick C. and Pike, Lee and Elliott, Trevor and Bielman, James and Launchbury, John},
+ year = {2014},
+ pages = {3--9},
+ file = {embedded-experience.pdf:/home/mrl/.mozilla/firefox/7b4r727h.default-1470981082057/zotero/storage/7IHBGC8H/embedded-experience.pdf:application/pdf}
+}
\graphicspath{{img/}}
-\urlstyle{same}
+\urlstyle{tt}
\hypersetup{%
pdftitle={iTasks and the Internet of Things},
pdfauthor={Mart Lubbers},
\pdfstringdefDisableCommands{%
\def\acrlong#1{}%
+ \def\acrlongpl#1{}%
\def\acrshort#1{}%
\def\acrfull#1{}%
\def\gls#1{}%
-%&output/thesis
+%&thesis
\usepackage[nonumberlist,acronyms]{glossaries}
\makeglossaries%
\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{RTOS}{RTOS}{Real-Time Operating System}
+\newglossaryentry{Arduino}{name=Arduino,
+ description={is a cheap and popular microcontroller that is widely used for
+ rapid prototyping}}
\newglossaryentry{Clean}{name=Clean,
- description={is a pure lazy functional programming language based on graph
+ description={is a staticly typed pure lazy functional programming language based on graph
rewriting}}
+\newglossaryentry{Haskell}{name=Haskell,
+ description={is a staticly typed pure lazy functional programming language}}
\newglossaryentry{iTasks}{name=iTasks,
description={is a \acrshort{TOP} implementation written as a \acrshort{EDSL}
in the \gls{Clean} programming language}}
+\newglossaryentry{Ivory}{name=Ivory,
+ description={is a type-safe \gls{EDSL} designed to generate \gls{C}-code
+ for high-assurance low-level systems}}
+\newglossaryentry{Tower}{name=Tower,
+ description={is a type-safe \gls{EDSL} similar to \gls{Ivory} designed to
+ generate code for \acrlong{RTOS}}}
\newglossaryentry{Task}{name=Task,
description={is the basic building block of a \acrshort{TOP} system}}
\newglossaryentry{mTask}{name=mTask,
description={is an abstraction for \glspl{Task} living on \acrshort{IoT} devices}}
\newglossaryentry{C}{name=C,
- description={is low-level programming language suitable for embedded devices}}
+ description={is low-level imperative programming language suitable for
+ embedded devices}}
+\newglossaryentry{C++}{name=C++,
+ description={is low-level imperative and object-oriented programming
+ language suitable for embedded devices based on \gls{C}}}
+\newglossaryentry{SAPL}{name=SAPL,
+ description={is an intermediate purely functional programming language}}
+\newglossaryentry{Firmata}{name=Firmata,
+ description={is standardized protocol for communicating with
+ microcontrollers}}
+\newglossaryentry{Javascript}{name=Javascript,
+ description={is an imperative programming language designed to run in web
+ browsers}}
\begin{document}
\frontmatter{}
repositories / msc-thesis1617.git / commitdiff