1 \Glspl{Task
} in the
\gls{iTasks
} system are modelled after real life workflow
2 tasks but the modelling is applied on a high level. Therefore it is difficult
3 to connect
\gls{iTasks
}-
\glspl{Task
} to real world tasks and allow them
4 to interact. A lot of the actual tasks could very well be performed by small
5 \gls{IoT
} devices. Nevertheless, adding such devices to the current system is
6 difficult to say the least as it was not designed to cope with these devices.
8 In the current system such adapters connecting devices to
\gls{iTasks
} --- in
9 principle --- can be written in two ways.
11 First, an adapter for a specific device can be written as a
12 \glspl{SDS
}\footnote{Similar as to resources such as time are available in the
13 current
\gls{iTasks
} implementation.
}.
\glspl{SDS
} can interact with the world
14 and thus with hardware, allowing it to communicate with any type of device.
15 However, this requires a tailor-made
\gls{SDS
} for every specific device and
16 does not allow logic to be changed. Once a device is programmed to serve as an
17 \gls{SDS
}, it has to behave like that forever. Thus, this solution is not
18 suitable for dynamic systems.
20 The second method uses the novel contribution to
\gls{iTasks
} by Oortgiese et
21 al. They lifted
\gls{iTasks
} from a single server model to a distributed server
22 architecture~
\cite{oortgiese_distributed_2017
}. As a proof of concept, an
23 android app has been created that runs an entire
\gls{iTasks
} core and is able
24 to receive
\glspl{Task
} from a different server and execute them. While android
25 often runs on small
\gls{ARM
} devices, they are a lot more powerful that the
26 average
\gls{IoT
} microcontroller. Running the entire
\glspl{iTasks
} core on a
27 microcontroller is not feasible. Even if it would be possible, this technique
28 would still not be suitable because a lot of communication overhead is needed
29 to transfer the
\glspl{Task
}.
\gls{IoT
} devices are often connected to the
30 server through
\emph{Low Power Low Bandwidth
} which is unsuitable for
31 transferring a lot of data.
33 The novel system that has been devised that bridges the gap between the
34 aforementioned solutions. The system consists of updates to the
35 \gls{mTask
}-
\gls{EDSL
}~
\cite{koopman_type-safe_nodate
}, a new communication
36 protocol, device application and an
\gls{iTasks
} server application. The system
37 supports devices as small as
\gls{Arduino
}
38 microcontrollers~
\cite{noauthor_arduino_nodate
} and operates via the same
39 paradigms and patterns as regular
\glspl{Task
} in the
\gls{TOP
} paradigm.
40 Devices in the
\gls{mTask
}-system can run small imperative programs written in
41 the
\gls{EDSL
} and have access to
\glspl{SDS
}.
\Glspl{Task
} are sent to the
42 device at runtime, avoiding recompilation and thus write cycles on the program