X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=introduction.tex;h=654cb1fb4e69e50649a9f78818fe0bdfacb49a09;hb=d118ff9d857683084065145df45135ef6fa06711;hp=4d1ddedda77ddc50a13419b3231afb8f1a77f4d6;hpb=0318eb1b212df7d3980f268f03429936d2f1d617;p=msc-thesis1617.git diff --git a/introduction.tex b/introduction.tex index 4d1dded..654cb1f 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,11 +1,24 @@ \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 @@ -13,9 +26,9 @@ 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 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 @@ -31,25 +44,78 @@ 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 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 and -the structure of the document. -Chapter~\ref{chp:methods} describes the foundations on which the implementation -is built. -Chapter~\ref{chp:results} shows the new techniques deviced and an example -application accompanied with implementation. +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}. +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 +extended on in this dissertation. +Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that +are a part of the new \gls{mTask}-system. +Chapter~\ref{chp:mtaskcont} shows the extension added to the +\gls{mTask}-\gls{EDSL} that were needed to make the system function. + +\todo{Vul aan} + Chapter~\ref{chp:conclusion} concludes by answering the research questions and discusses future research. Appendix~\ref{app:communication-protocol} shows the concrete protocol used for communicating between the server and client. Appendix~\ref{app:device-interface} shows the concrete interface for the devices. + +\section{Relevant research} +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}.