X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=introduction.tex;h=9243d2ad19e615b5b17a8cf6f3d361f71f7ceaac;hb=62adc41f28fb8baaa8e1a40d8806b06069d641ed;hp=36ef5892114da1c5ef4e3c60fc4890369c166d8a;hpb=faca758c348718411803e4b8fab3a83a85665d1a;p=msc-thesis1617.git diff --git a/introduction.tex b/introduction.tex index 36ef589..9243d2a 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,77 +1,84 @@ \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. +\Gls{IoT} technology is emerging rapidly. It offers myriads of solutions +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% -\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. +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} modules\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 accurately using little power and bandwidth. Moreover, \gls{IoT} +technology is coming into people's homes, clothes and +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. -\gls{iTasks} has been shown to be useful in many fields of operation such as +The \gls{TOP} paradigm and the corresponding \gls{iTasks} implementation offer +a high abstraction level for real world 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 a +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 sequential, parallel and conditional \glspl{Task} can be modelled +using combinators. + +\gls{iTasks} has 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 -\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. +tasks but the modelling is applied on a high level. Therefore it is difficult +to connect \gls{iTasks}-\glspl{Task} to real world \glspl{Task} and allow them +to 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, 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 -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 with low bandwidth and a very limited amount of processing power -and are therefore not suitable to run an entire \gls{iTasks} core. +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. Many small \gls{IoT} devices have limited processing power but are still +powerful enough for decision making. Recompiling the code for a small +\gls{IoT} device is expensive and therefore it is difficult to use a device +dynamically for multiple purposes. Oortgiese et al.\ lifted \gls{iTasks} from a +single server model to a distributed server architecture that is also runnable +on small devices such as those powered by +\gls{ARM}~\cite{oortgiese_distributed_2017}. However, this is limited to +fairly high performance devices that are equipped with high speed communication +channels because it requires the device to run the entire \gls{iTasks} core. +Devices in \gls{IoT} often have only Low Throughput Network 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} -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 +The updates to the \gls{mTask}-system~\cite{koopman_type-safe_nodate} will +bridge this gap in the current system by introducing a new communication +protocol, device application and \glspl{Task} synchronizing the two. 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 +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. +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. +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. +extended upon in this dissertation. +Chapter~\ref{chp:mtaskcont} describes the view and functionality for +the \gls{mTask}-\gls{EDSL} that were added and used in the system. 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} - +are a part of the new \gls{mTask}-system. It covers the client software running +on the device and the server written in \gls{iTasks}. 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 @@ -79,48 +86,61 @@ 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].} +Text written using the \CI{Teletype} font indicates code and is often +referring to a listing. \emph{Emphasized} text is used for proper nouns and +words that have a unexpected meaning. + +The complete source code of this thesis can be found in the following git +repository:\\ +\url{https://git.martlubbers.net/msc-thesis1617.git} + +The complete source code of the \gls{mTask}-system can be found in the +following git repository: +\url{https://git.martlubbers.net/mTask.git} + +\section{Related work} +Similar research has been conducted on the subject. +For example, 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 is +also available\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{C++}~\cite{jansen_efficient_2007}, \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. -\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. +\Glspl{EDSL} have often been used to generate \gls{C} code for microcontroller +environments. This work uses parts of the existing \gls{mTask}-\gls{EDSL} which +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. \gls{Ivory} has been used in for example the +~\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 +~\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 dependant type constructions. The +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} transform the embedded code during compile-time directly -into the backend which is often a state transformer that will execute on -runtime.\todo{Misschien een beetje onduidelijk of kort?} +code is transformed into an \gls{AST} that is sent to a backend. In the new +system, 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.