\input{subfilepreamble}
-\setcounter{chapter}{6}
+\setcounter{chapter}{7}
\begin{document}
\input{subfileprefix}
-\chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
+\chapter{Green computing with mTask}%
\label{chp:green_computing_mtask}
\begin{chapterabstract}
This chapter demonstrate the energy-saving features of \gls{MTASK} by:
\end{itemize}
\end{chapterabstract}
-The edge layer of the \gls{IOT} contains small devices that sense and interact with the world.
+The edge layer of the \gls{IOT} is built from energy-efficient devices that sense and interact with the world.
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{nizetic_internet_2020}.
+Furthermore, many of these 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}.
It is therefore crucial to lower their energy consumption.
-To reduce the power consumption of an \gls{IOT} edge device, the specialized low-power sleep modes of the microprocessors can be leveraged.
+To reduce the power consumption of an \gls{IOT} edge device, the specialised low-power sleep modes of the microprocessors can be leveraged.
Different sleep mode achieve different power reductions because of their run time characteristics.
These specifics range from disabling or suspending the \gls{WIFI} radio; stop powering (parts) of the \gls{RAM}; disabling peripherals; or even turning off the processor completely, requiring an external signal to wake up again.
Determining exactly when, and for how long it is safe to sleep is expensive in the general case.
\begin{tabular}{ccccccccc}
\toprule
& \multicolumn{4}{c}{\Gls{WEMOS} D1 mini}
- & \multicolumn{4}{c}{Adafruit Feather M0 Wifi} \\
+ & \multicolumn{4}{c}{Adafruit Feather M0 \gls{WIFI}} \\
\midrule
& active & modem & light & deep & active & modem & light & deep\\
& & sleep & sleep & sleep & & sleep & sleep & sleep\\
\endgroup
\end{table}
-\section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing}
+\section{Green \IOT{} computing}
The data in \cref{tbl:top_sleep} shows that it is worthwhile to put the system in some sleep mode when there is temporarily no work to be done.
A deeper sleep mode saves more energy, but also requires more work to restore the software to its working state.
A processor like the ESP8266 driving the \gls{WEMOS} D1 mini loses the content of its \gls{RAM} in deep sleep mode.
| RangeS (v Int) (v Int) // yields [+$\rewriterate{x \times 1000}{y \times 1000}$+]
\end{lstClean}
-\subsubsection{Sensors and \texorpdfstring{\glspl{SDS}}{shared data sources}}
+\subsubsection{Sensors and shared data sources}
In some applications, it is necessary to read sensors or \glspl{SDS} at a different rate than the default rate given in \cref{tbl:rewrite}, i.e.\ to customise the rewrite rate.
This is achieved by calling the access functions with a custom rewrite rate as an additional argument (suffixed with the backtick (\cleaninline{`}))
The adaptions to other classes are similar and omitted for brevity.
delayTime :: TimingInterval v | mtask v
delayTime = BeforeS (lit 60) // 1 minute in seconds
-devTask :: Main (MTask v Real) | mtask, dht, liftsds v
+devTask :: Main (MTask v Real) | mtask, dht, lowerSds v
devTask =
DHT (DHT_DHT pin DHT11) \dht =
- liftsds \localSds = tempSds
+ lowerSds \localSds = tempSds
In {main = rpeat (temperature` delayTime dht >>~. setSds localSds)}
\end{lstClean}
}
\end{lstClean}
-\section{Task scheduling in the \texorpdfstring{\gls{MTASK}}{mTask} engine}\label{sec:scheduling}
+\section{Task scheduling in the mTask engine}\label{sec:scheduling}
The rewrite rates from the previous section only tell us how much the next evaluation of the task can be delayed.
In the \gls{MTASK} system, an \gls{IOT} edge devices can run multiple tasks.
In addition, it has to communicate with a server to collect new tasks and updates of \glspl{SDS}.
}[+\label{lst:arduino_interrupt:isr_to}+]
\end{lstArduino}
-\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} language}
+\subsection{The mTask language}
\Cref{lst:mtask_interrupts} shows the interrupt interface in \gls{MTASK}.
The \cleaninline{interrupt} class contains a single function that, given an interrupt mode and a \gls{GPIO} pin, produces a task that represents this interrupt.
Lowercase variants of the various interrupt modes such as \cleaninline{change :== lit Change} are available as convenience macros (see \cref{sec:expressions}).
The interrupt handler is set up in such a way that the rewrite rate is changed to $\rewriterate{0}{0}$ once the interrupt triggers.
As a consequence, the task is executed on the next execution cycle.
-The \cleaninline{pirSwitch} function in \cref{lst:pirSwitch} creates, given an interval in \unit{\ms}, a task that reacts to motion detection by a \gls{PIR} sensor (connected to \gls{GPIO} pin 0) by lighting the \gls{LED} connected to \gls{GPIO} pin 13 for the given interval.
+The \cleaninline{pirSwitch} function in \cref{lst:pirSwitch} creates, given an interval in milliseconds, a task that reacts to motion detection by a \gls{PIR} sensor (connected to \gls{GPIO} pin 0) by lighting the \gls{LED} connected to \gls{GPIO} pin 13 for the given interval.
The system turns on the \gls{LED} again when there is still motion detected after this interval.
By changing the interrupt mode in this program text from \cleaninline{high} to \cleaninline{rising} the system lights the \gls{LED} only one interval when it detects motion, no matter how long this signal is present at the \gls{PIR} pin.
>>|. writeD ledpin true) }
\end{lstClean}
-\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} engine}
+\subsection{The mTask engine}
While interrupt tasks have their own node type in the task tree, they differ slightly from other node types because they require a more elaborate setup and teardown.
Enabling and disabling interrupts is done in a general way in which tasks register themselves after creation and deregister after deletion.
Otherwise, no value is emitted.
\section{Conclusion}
-\todo[inline]{Conclusion}
+This chapter show how we can automatically associate execution intervals to tasks.
+Based on these intervals, we can delay the executions of those tasks.
+When all task executions can be delayed, the microprocessor executing those tasks can go to sleep mode to reduce its energy consumption.
+This is a rather difficult problem that must be solved dynamically, since we make no assumptions on the number and nature of the tasks that will be allocated to an IoT node.
+Furthermore, the execution intervals offer an elegant and efficient way to add interrupts to the language.
+Those interrupts offer a more elegant and energy efficient implementation of watching an input than polling this input.
+
+The actual reduction of the energy is of course highly dependent on the number and nature of the task shipped to the edge device.
+Our examples show a reduction in energy consumption of two orders of magnitude.
+Those reductions are a necessity for edge devices running of battery power.
+Given the exploding number of \gls{IOT} edge devices, such savings are also mandatory for other nodes to limit the total power consumption of the \gls{IOT}.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff