The edge layer of the \gls{IOT} contains small devices that sense and interact with the world and it is crucial to lower their energy consumption.
While individual devices consume little energy, the sheer number of devices in total amounts to a lot.
-Furthermore, many \gls{IOT} devices operate on batteries and higher energy consumption increases the amount of e-waste as \gls{IOT} edge devices are often hard to reach and consequently hard to replace \citep{NIZETIC2020122877}.
+Furthermore, many \gls{IOT} devices operate on batteries and higher energy consumption increases the amount of e-waste as \gls{IOT} edge devices are often hard to reach and consequently hard to replace \citep{nizetic_internet_2020}.
To reduce the power consumption of an \gls{IOT} device, the specialized low-power sleep modes of the microprocessors can be leveraged.
Different sleep modes achieve different power reductions because of their different run time characteristics.
The system calculates the refresh rates from the current task expression.
This has the advantage that the programmer does not have to deal with them and that they are available in each and every \gls{MTASK} program.
-\subsection{Basic Refresh Rates}
+\subsection{Basic tasks}
We start by assigning default refresh rates to basic tasks.
These refresh rates reflect the expected change rates of sensors and other inputs.
\end{tabular}
\end{table}
-\subsection{Deriving Refresh Rates}\label{sec:deriving_refresh_rates}
+\subsection{Deriving refresh rates}\label{sec:deriving_refresh_rates}
Based on these refresh rates, the system can automatically derive refresh rates for composed \gls{MTASK} expressions using $\mathcal{R}$.
We use the operator $\cap_{\textit{safe}}$ to compose refresh ranges.
When the ranges overlap the result is the overlapping range.
We will briefly discuss the various cases of deriving refresh rates together with the task semantics of the different combinators
-\subsubsection{Parallel Combinators} For the parallel composition of tasks we compute the intersection of the refresh intervals of the components as outlined in the definition of $\cap_{\textit{safe}}$.
+\subsubsection{Parallel combinators} For the parallel composition of tasks we compute the intersection of the refresh intervals of the components as outlined in the definition of $\cap_{\textit{safe}}$.
The operator \cleaninline{.\|\|.} in \cref{R:or} is the \emph{or}-combinator; the first subtask that produces a stable value determines the result of the composition.
The operator \cleaninline{.&&.} in \cref{R:and} is the \emph{and}-operator. The result is the tuple containing both results when both subtasks have a stable value.
The refresh rates of the parallel combinators have no direct relation with their task result.
-\subsubsection{Sequential Combinators}
+\subsubsection{Sequential combinators}
For the sequential composition of tasks we only have to look at the refresh rate of the current task on the left.
The sequential composition operator \cleaninline{>>\|.} in \cref{R:seq} is similar to the monadic sequence operator \cleaninline{>>\|}.
The operator \cleaninline{>>=.} in \cref{R:bind} provides the stable task result to the function on the right-hand side, similar to the monadic bind.
The operator \cleaninline{>>~.} steps on an unstable value and is otherwise equal to \cleaninline{>>=.}.
The step combinator \cleaninline{>>*.} in \cref{R:step} has a list of conditional actions that specify a new task.
-\subsubsection{Repeat Combinators}
+\subsubsection{Repeat combinators}
The repeat combinators repeats their argument indefinitely.
The combinator \cleaninline{rpeatEvery} guarantees the given delay between repetitions.
The refresh rate is equal to the refresh rate of the current argument task.
Only when \cleaninline{rpeatEvery} waits between the iterations of the argument the refresh interval is equal to the remaining delay time.
-\subsubsection{Other Combinators}
+\subsubsection{Other combinators}
The refresh rate of the \cleaninline{delay} in \cref{R:delay} is equal to the remaining delay.
Refreshing stable tasks can be delayed indefinitely, their value never changes.
For other basic tasks, the values from \cref{tbl:refresh} apply.
\end{tabular}
\end{table}
-\subsection{User Defined Refresh Rates}
+\subsection{Tweaking refresh rates}
A tailor-made \gls{ADT} (see \cref{lst:interval}) determines the timing intervals for which the value is determined at runtime but the constructor is known at compile time.
During compilation, the constructor of the \gls{ADT} is checked and code is generated accordingly.
If it is \cleaninline{Default}, no extra code is generated.
\begin{lstClean}[caption={Repeat task combinator with a timing interval.},label={lst:rpeatevery}]
class rpeat v where
- rpeatEvery v :: (TimingInterval v) (MTask v t) -> MTask v t
rpeat :: (MTask v t) -> MTask v t
+ rpeatEvery v :: (TimingInterval v) (MTask v t) -> MTask v t
\end{lstClean}
\Cref{lst:rpeateveryex} shows an example of an \gls{MTASK} task utilising the \cleaninline{rpeatEvery} combinator that would be impossible to create with the regular \cleaninline{rpeat}.
repositories / phd-thesis.git / blobdiff