X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=introduction.tex;h=1f4fc9a495e30a748d88cc8a8ccb8fa5c606e338;hb=7694dfaa240c6dd9af2f1ac8880f0fb1d7f38324;hp=4352f6e594851f9c8a0eba26ac87083646f20ccc;hpb=7910fda15825b983fd6b1309b07872616cc6367b;p=msc-thesis1617.git diff --git a/introduction.tex b/introduction.tex index 4352f6e..1f4fc9a 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,34 +1,132 @@ -\section{Motivation} -\Gls{TOP} and \gls{iTasks} have been designed to offer a high abstraction level -through a \gls{DSL} that describes workflows as \glspl{Task}. \gls{iTasks} has -been shown to be useful in fields such as incident -management~\cite{lijnse_top_2013}. However, there still lacks support for small -devices to be added in the workflow. In principle such adapters 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. Oortgiese et al.\ -lifted \gls{iTasks} from a single server model to a distributed server -architecture~\todo{Add cite} 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 LPLB communication with low bandwidth and a very limited amount -of processing power. \glspl{mTask} will bridge this gap. It can run on devices -as small as Arduino microcontrollers and operates via the same paradigms as -regular \glspl{Task}. The \glspl{mTask} have access to \glspl{SDS} and can run -small imperative programs. +\section{Introduction} +\Gls{IoT} technology is emerging very quickly. It 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. 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 +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}. 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 tasks can be modelled using +combinators. + +\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}-\glspl{Task} to real world tasks and let +them 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. 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 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. \section{Problem statement} -Therefore the problem statement is as follows: +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 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 \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 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 together with the new techniques introduced. -Chapter~\ref{chp:results} shows the results in the form of an example -application accompanied with implementation. -Chapter~\ref{chp:conclusion} concludes by answering the research question (s) +The structure of this thesis is as follows. + +Chapter~\ref{chp:introduction} contains the problem statement, motivation, +related work 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. +Chapter~\ref{chp:itasksint} shows the integration with \gls{iTasks} that was +built to realise the system. +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{Related work} +Several types of similar research have 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 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{% +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 and therefore not directly suitable for devices with 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 sent to the device. + +\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 +\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 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 +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.