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
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 communication with any type of device.
15 However, this requires a tailor-made
\gls{SDS
} for every specific device and
16 functionality and does not allow logic to be changed. Once a device is
17 programmed to serve as an
\gls{SDS
}, it has to behave like that forever. Thus,
18 this solution is not suitable for systems that can send
\glspl{Task
} to
19 the device dynamically.
21 The second method uses the novel contribution to
\gls{iTasks
} by Oortgiese et
22 al. They lifted
\gls{iTasks
} from a single server model to a distributed server
23 architecture~
\cite{oortgiese_distributed_2017
}. As a proof of concept, an
24 android app has been created that runs an entire
\gls{iTasks
} core and is able
25 to receive
\glspl{Task
} from a different server and execute them. While android
26 often runs on small
\gls{ARM
} devices, they are a lot more powerful than the
27 average
\gls{IoT
} microcontroller. The system is suitable for dynamically
28 sending
\glspl{Task
} but running the entire
\gls{iTasks
} core on a
29 microcontroller is not feasible. Even if it would be possible, this technique
30 would still not be suitable because a lot of communication overhead is needed
31 to transfer the
\glspl{Task
}.
\gls{IoT
} devices are often connected to the
32 server through
\emph{Low Power Low Bandwidth
} which is unsuitable for
33 transferring a lot of data.
35 The novel system that has been devised bridges the gap between the
36 aforementioned solutions for adding
\gls{IoT
} to
\gls{iTasks
}. The system
37 consists of updates to the
38 \gls{mTask
}-
\gls{EDSL
}~
\cite{koopman_type-safe_nodate
}, a new communication
39 protocol, device application and an
\gls{iTasks
} server application. The system
40 supports devices as small as
\gls{Arduino
}
41 microcontrollers~
\cite{noauthor_arduino_nodate
} and operates via the same
42 paradigms and patterns as regular
\glspl{Task
} in the
\gls{TOP
} paradigm.
43 Devices in the
\gls{mTask
}-system can run small imperative programs written in
44 the
\gls{EDSL
} and have access to
\glspl{SDS
}.
\Glspl{Task
} are sent to the
45 device at runtime, avoiding recompilation and thus write cycles on the program
46 memory. This solution extends the reach of
\gls{iTasks
} and allows closer
47 resemblance of
\glspl{Task
} to actual tasks. Moreover, it tries to solve some
48 integration problems in
\gls{IoT
} by allowing all components to be programmed