X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=introduction.tex;h=62bbb9f716323ee7deaa8167908d0c907028d432;hb=0810fd13a4d0701b7191ac4195ae933c4caa3e6d;hp=7ea1d08763e1deb184b60870ab31dd3ebc1c9736;hpb=435b0d98d22a47530f50ff82f2451e70ce2bed96;p=msc-thesis1617.git diff --git a/introduction.tex b/introduction.tex index 7ea1d08..62bbb9f 100644 --- a/introduction.tex +++ b/introduction.tex @@ -7,29 +7,29 @@ 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 +~\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 +\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. 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 +~\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 +like sequence, parallel and conditional \glspl{Task} 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 +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 +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. @@ -38,22 +38,22 @@ 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. +This forces a fixed logic in the device that is set at compile time. Many +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 small +devices such as those powered by \acrshort{ARM}~~\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} -The updates to the \gls{mTask}-system\cite{koopman_type-safe_nodate} will +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 +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} @@ -70,14 +70,13 @@ Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and 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: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: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 @@ -85,6 +84,10 @@ communicating between the server and client. Appendix~\ref{app:device-interface} shows the concrete interface for the devices. +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. + \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 @@ -101,9 +104,9 @@ 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 +\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 @@ -114,16 +117,16 @@ 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}. +~\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 +~\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 dependent type constructions. The process of compiling an \gls{Ivory} program happens in stages. The embedded