conclusion.tex

   1 \section{Discussion \& Future Research}
   2 The system is still a crude prototype and a proof of concept. Improvements and
   3 extension for the system are amply available in several fields of study.
   4
   5 \subsection{Simulation}
   6 An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
   7 works in the same way as the existing \gls{C}-backed simulation. It simulates
   8 the bytecode interpretation. Moreover, it would be possible to let the simulator
   9 function as a real device, thus handling all communication through the
  10 existing \gls{SDS}-based systems and behave like a real device. At the moment
  11 the \emph{POSIX}-client is the reference client and contains debugging code.
  12 Adding a simulation view to the system allows for easy interactive debugging.
  13 However, it might not be easy to devise a simulation tool that accurately
  14 simulates the \gls{mTask} system on some levels. The semantics can be simulated
  15 but timing and peripheral input/output are more difficult to simulate properly.
  16
  17 \subsection{Optimization}
  18 \paragraph{Multitasking on the client:}
  19 True multitasking could be added to the client software. This allows
  20 \gls{mTask}-\glspl{Task} to run truly parallel. All \gls{mTask}-\glspl{Task}
  21 get slices of execution time and will each have their own interpreter state
  22 instead of a single system-wide state which is reset after am \gls{mTask}
  23 finishes. This does require separate stacks for each \gls{Task} and therefore
  24 increases the system requirements of the client software. However, it could be
  25 implemented as a compile-time option and exchanged during the handshake so that
  26 the server knows the multithreading capabilities of the client.
  27
  28 \paragraph{Optimizing the interpreter:}
  29 Due to time constraints and focus, hardly any work has been done in the
  30 interpreter. The current interpreter is a no nonsense stack machine. A lot of
  31 improvements can be done in this part. For example, precomputed \emph{gotos}
  32 can improve jumping to the correct part of the code corresponding to the
  33 correct instruction.  Moreover, the stack currently consists of 16-bit values.
  34 All operations work on 16-bit values and this simplifies the interpreter
  35 implementation. A memory improvement can be made by converting the stack to
  36 8-bit values. This does pose some problems since an equality instruction must
  37 work on single-byte booleans \emph{and} two-byte integers. Adding specialized
  38 instructions per word size could overcome this problem.
  39
  40 \subsection{Resources}
  41 \paragraph{Resource analysis: }
  42 Resource analysis during compilation can be useful to determine if an
  43 \gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
  44 not contain the correct peripherals --- such as an \gls{LCD} --- then the
  45 \gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
  46 given. It might even be possible to do this statically on the type level.
  47
  48 \paragraph{Extended resource analysis: }
  49 The previous idea could be extended to the analysis of stack size and possibly
  50 communication bandwidth. With this functionality ever more reliable fail-over
  51 systems can be designed. When the system knows precise bounds it can allocate
  52 more \glspl{Task} on a device whilst staying within safe memory bounds. The
  53 resource allocation can be done at runtime within the backend itself or a
  54 general backend can be devised that can calculate the resources needed for a
  55 given \gls{mTask}. A specific \gls{mTask} cannot have multiple views at the
  56 same time due to the restrictions of class based shallow embedding. It might
  57 even be possible to encode the resource allocation in the type system itself
  58 using forms of dependant types.
  59
  60 \subsection{Functionality}
  61 \paragraph{Add more combinators: }
  62 More \gls{Task}-combinators --- already existing in the \gls{iTasks}-system ---
  63 could be added to the \gls{mTask}-system to allow for more fine-grained control
  64 flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
  65 \gls{TOP} paradigm even more and makes programming \gls{mTask}-\glspl{Task} for
  66 \gls{TOP}-programmers more seamless. Some of the combinators require previously
  67 mentioned extension such as the parallel combinator. Others might be achieved
  68 using simple syntactic transformations.
  69
  70 \paragraph{Launch \glspl{Task} from a \gls{Task}: }\label{par:tasklaunch}
  71 Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
  72 the current system this type of logic has to take place on the server side.
  73 Adding this functionality to the bytecode-view allows greater flexibility,
  74 easier programming and less communication resources. Adding these semantics
  75 requires modifications to the client software and extensions to the
  76 communication protocol since relations between \glspl{Task} also need to be
  77 encoded and communicated.
  78
  79 The \gls{SDS} functionality in the current system is bare. There is no easy way
  80 of reusing an \gls{SDS} for another \gls{Task} on the same device or on another
  81 device. Such functionality can be implemented in a crude way by tying the
  82 \glspl{SDS} together in the \gls{iTasks} environment. However, this will result
  83 in a slow updating system. Functionality for reusing shares from a device
  84 should be added. This requires rethinking the storage because some typedness is
  85 lost when the \gls{SDS} is stored after compilation. A possibility would be to
  86 use runtime typing with \CI{Dynamic}s or the encoding technique currently used
  87 for \CI{BCValue}s. Using \glspl{SDS} for multiple \glspl{Task} within one
  88 device is solved when the previous point at paragraph~\ref{par:tasklaunch} is
  89 implemented.
  90
  91 \subsection{Robustness}
  92 \paragraph{Reconnect with lost devices:}
  93 The robustness of the system can be greatly improved. Devices that lose
  94 connection are not well supported in the current system. The device will stop
  95 functioning and has to be emptied for a reconnect. \Glspl{Task} residing on a
  96 device that disconnected should be kept on the server to allow a swift
  97 reconnect and restoration of the \glspl{Task}. This holds the same for the
  98 client software. The client drops all existing \glspl{Task} on a shutdown
  99 request. An extra specialization of the shutdown could be added that drops the
 100 connection but keeps the \glspl{Task} in memory. During the downtime the
 101 \glspl{Task} can still be executed but publications need to be delayed. If the
 102 same server connects to the client the delayed publications can be sent
 103 anyways.
 104
 105 \paragraph{Reverse \gls{Task} sending:}
 106 Moreover, devices could send their current \glspl{Task} back at the
 107 server to synchronize it. This allows interchanging servers without
 108 interrupting the client. Allowing the client to send \glspl{Task} to the server
 109 is something to handle with care because it can easily cause high bandwidth
 110 usage.
 111
 112 \section{Conclusion}
 113 This thesis introduces a novel system for add \gls{IoT} functionality to
 114 the \gls{TOP} implementation \gls{iTasks}. A new view for the existing
 115 \gls{mTask}-\gls{EDSL} has been created which compiles the program
 116 into bytecode that can be interpreted by a client. Clients have
 117 been written for several microcontrollers and consumer architectures which can
 118 be connected through various means of communication such as serial port,
 119 bluetooth, wifi and wired network communication. The bytecode on the devices is
 120 interpreted using a stack machine and provides the programmer interfaces
 121 to the peripherals. The semantics for \gls{mTask} tries to resemble the
 122 \gls{iTasks} semantics as close as possible.
 123
 124 The host language has a proven efficient compiler and code generator. Therefore,
 125 compiling \gls{mTask}-\glspl{Task} is also fast. Compiling an
 126 \gls{mTask}-\gls{Task} is nothing more than running some functions native to
 127 the host language.
 128
 129 The dynamic nature allows the microcontroller to be programmed once and used
 130 many times. The program memory of microcontrollers often guarantees around
 131 $10.000$ write or upload cycles and therefore existing techniques such as
 132 generating \gls{C} code are not usable for dynamic \gls{Task} environments.
 133 The dynamic nature also allows the programmer to design fail-over mechanisms.
 134 When a device is assigned a \gls{Task} but another device suddenly becomes
 135 unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
 136 another device that is also suitable for running the \gls{Task} without needing
 137 to recompile the code.