\end{chapterabstract}
There are at least 13.4 billion devices connected to the internet at the time of writing\footnote{\url{https://transformainsights.com/research/tam/market}, accessed on: \formatdate{13}{10}{2022}}.
-Each and every one of those devices senses, acts, or otherwise interacts with people, other computers, and the environment surrounding us.
-Even though there is a substantial variety among these devices, they all have one thing in common: they are all computers and hence require software to operate.
+Each of these senses, acts, or otherwise interacts with people, other computers, and the environment surrounding us.
+Despite their immense diversity, they all have one thing in common.
+They are all computers, and as computers, they they require software to operate.
An increasing amount of these connected devices are so-called \emph{edge devices} that operate in the \gls{IOT}.
Typically, these edge devices are powered by microcontrollers.
-These miniature computers contain integrated circuits accommodating a microprocessor designed for use in embedded applications.
-Typical edge devices are therefore tiny in size; have little memory; contain a slow, but energy-efficient processor; and allow for a lot of connectivity to connect peripherals such as sensors and actuators in order to interact with their surroundings.
+These miniature computers contain integrated circuits that accomodates a microprocessor designed for use in embedded applications.
+Typically, microcontrollers are therefore tiny in size; have little memory; contain a slow, but energy-efficient processor; and allow for a lot of connectivity to connect peripherals such as sensors and actuators in order to interact with their surroundings.
%
%\begin{figure}[ht]
% \centering
%\end{figure}
Programming and maintaining \gls{IOT} systems is a complex and error-prone process.
+Unlike the conductor in the orchestra waving their baton to orchestrate the ensemble of instruments in an orchestra, in the universe of software there is room for little error.
An \gls{IOT} programmer has to program each device and their interoperation using different programming paradigms, programming languages, and abstraction levels resulting in semantic friction.
This thesis describes the research carried out around orchestrating these complex \gls{IOT} systems using \gls{TOP}.
\Gls{TOP} is an innovative tierless programming paradigm for interactive multi-tier systems.
-By utilising advanced compiler technologies, much of the internals, communication, and interoperation of the applications is automatically generated.
-From a single declarative specification of the work that needs to be done, the compiler makes a ready-for-work application.
+By utilising advanced compiler technologies, much of the internals, communications, and interoperations of the applications are automatically generated.
+From a single declarative specification of the work required, the compiler makes a ready-for-work application.
For example, the \gls{TOP} system \gls{ITASK} can be used to program all layers of a multi-user distributed web applications from a single source specification.
-Unfortunately, because the abstraction level is so high, the hardware requirements are too excessive for \gls{TOP} systems such as \gls{ITASK} to be suitable for the average \gls{IOT} edge device.
+Unfortunately, because the abstraction level is so demanding, the hardware requirements are overly excessive for \gls{TOP} systems such as \gls{ITASK}.
+Hence, impractical for the average edge device.
-This is where \glspl{DSL} are brought into play.
+This is where \glspl{DSL} are must be brought into play.
\Glspl{DSL} are programming languages created with a specific domain in mind.
Consequently, jargon does not have to be expressed in the language itself, but they can be built-in features.
-As a result, the hardware requirements can be drastically lower, even with high levels of abstraction for the specified domain.
+As a result, hardware requirements can be drastically lowered, even with high levels of abstraction for the specified domain.
To incorporate the plethora of edge devices in the orchestra of an \gls{IOT} system, the \gls{MTASK} system is used.
\Gls{MTASK} is a novel programming language for programming \gls{IOT} edge devices using \gls{TOP}.
\section{Reading guide}%
\label{lst:reading_guide}
-The thesis is structured as a purely functional rhapsody.
+This work is is structured as a purely functional rhapsody.
On Wikipedia, a musical rhapsody is defined as follows \citep{wikipedia_contributors_rhapsody_2022}:
\begin{quote}\emph{%
A \emph{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality.}
\emph{The \glsxtrlong{IOT}, or \glsxtrshort{IOT}, is the integration of people, processes and technology with connectable devices and sensors to enable remote monitoring, status, manipulation and evaluation of trends of such devices.}
\end{quote}
-CISCO states that the \gls{IOT} started when there where as many connected devices as there were people on the globe, i.e.\ around 2008 \citep{evans_internet_2011}.
-Today, \gls{IOT} is the term for a system of devices that sense the environment, act upon it and communicate with each other and the world.
+CISCO states that the \gls{IOT} started when there were as many connected devices as there were people on the globe, i.e.\ around 2008 \citep{evans_internet_2011}.
+Today, \gls{IOT} is the term for a system of devices that sense the environment, act upon it and communicate with each other and the world they live in.
These connected devices are already in households all around us in the form of smart electricity meters, fridges, phones, watches, home automation, \etc.
When describing \gls{IOT} systems, a tiered---or layered---architecture is often used for compartmentalisation.
\end{figure}
To explain the tiers, an example \gls{IOT} application---home automation---is dissected accordingly.
-Closest to the end-user is the presentation layer, it provides the interface between the user and the \gls{IOT} system.
-In home automation this may be a web interface or an app used on a phone or wall-mounted tablet to interact with the edge devices and view the sensor data.
+Closest to the end-user is the presentation layer, it provides the interface between the user and \gls{IOT} systems.
+In home automation this may be a web interface, or an app used on a phone or wall-mounted tablet to interact with edge devices and view sensor data.
-The application layer provides the \glspl{API}, data interfaces, data processing, and data storage of the \gls{IOT} system.
+The application layer provides the \glspl{API}, data interfaces, data processing, and data storage of \gls{IOT} systems.
A cloud server or local server provides this layer in a typical home automation application.
The perception layer---also called edge layer---collects the data and interacts with the environment.
It consists of edge devices such as microcontrollers equipped with various sensors and actuators.
-In home automation this layer consists of all the devices hosting the sensors and actuators such as smart light bulbs, actuators to open doors or a temperature and humidity sensors.
+In home automation this layer consists of all the devices hosting sensors and actuators such as smart light bulbs, actuators to open doors or a temperature and humidity sensors.
All layers are connected using the network layer.
In some applications this is implemented using conventional networking techniques such as WiFi or Ethernet.
-However, networks or layers on top of it---tailored to the needs of the specific interconnection between layers---have been increasingly popular.
-Examples of this are BLE, LoRa, ZigBee, LTE-M, or \gls{MQTT} for connecting the perception layer to the application layer and techniques such as HTTP, AJAX, and WebSocket for connecting the presentation layer to the application layer.
+However, networks or layers on top of it---tailored to the needs of the specific interconnection between layers---have become increasingly popular.
+Examples of this are BLE, LoRa, ZigBee, LTE-M, or \gls{MQTT} for connecting perception layers to application layers and techniques such as HTTP, AJAX, and WebSocket for connecting presentation layers to application layers.
Across the layers, the devices are a large heterogeneous collection of different platforms, protocols, paradigms, and programming languages often resulting in impedance problems or semantic friction between layers when programming \citep{ireland_classification_2009}.
-Even more so, the perception layer itself often is a heterogeneous collections of microcontrollers in itself as well, each having their own peculiarities, language of choice, and hardware interfaces.
-Moreover, as the edge hardware needs to be cheap, small-scale, and energy efficient, the microcontrollers used to power these devices do not have a lot of computational power, only a soup\c{c}on of memory, and little communication bandwidth.
-Typically the devices are unable to run a full-fledged general-purpose \gls{OS} but use compiled firmwares that are written in an imperative language.
-While devices are getting a bit faster, smaller, and cheaper, they keep these properties to an extent, greatly reducing the flexibility for dynamic systems where tasks are created on the fly, executed on demand, or require parallel execution.
-As program memory is mostly flash based and only lasts a couple of thousand writes before it wears out, it is not suitable for rapid reconfiguring and reprogramming.
+Even more so, the perception layer itself is often a heterogeneous collections of microcontrollers in itself, each having their own peculiarities, language of choice, and hardware interfaces.
+Insofar, as edge hardware needs to be cheap, small-scale, and energy efficient, the microcontrollers used to power them do not have a lot of computational power, only a soup\c{c}on of memory, and little communication bandwidth.
+Typically these devices are unable to run a full-fledged general-purpose \gls{OS}.
+Rather they employ compiled firmware written in imperative languages.
+While devices are getting a bit faster, smaller, and cheaper, they keep these properties to an extent, greatly reducing the flexibility for dynamic systems when tasks are created on the fly, executed on demand, or require parallel execution.
+As program memory is mostly flash-based and only lasts a couple of thousand writes before it wears out, it is not suitable for rapid reconfiguring and reprogramming.
These problems can be mitigated by dynamically sending code to be interpreted to the microcontroller.
-With interpretation, a specialized interpreter is flashed in the program memory once that receives the program code to execute at runtime.
+With interpretation, a specialized interpreter is flashed in the program memory once it receives the program code to execute at run time.
Interpretation always comes with an overhead, making it challenging to create them for small edge devices.
-However, the hardware requirements can be reduced by embedding domain-specific data into the programming language to be interpreted, so called \glspl{DSL}.
+However, the hardware requirements can be reduced by embedding domain-specific data into the programming language to be interpreted, so-called \glspl{DSL}.
\section{\texorpdfstring{\Glsxtrlongpl{DSL}}{Domain-specific languages}}%
\label{sec:back_dsl}
On the other hand, \gls{MTASK} offers abstractions for edge layer-specific details such as the heterogeneity of architectures, platforms, and frameworks; peripheral access; (multi) task scheduling; and lowering energy consumption.
The \gls{MTASK} language is written in \gls{CLEAN} as a multi-view \gls{EDSL} and hence there are multiple interpretations possible.
The byte code compiler is the most relevant for this thesis.
-From an \gls{MTASK} task constructed at runtime, a compact binary representation of the work that needs to be done is compiled.
+From an \gls{MTASK} task constructed at run time, a compact binary representation of the work that needs to be done is compiled.
This byte code is then sent to a device that running the \gls{MTASK} \gls{RTS}.
This feather-light domain-specific \gls{OS} is written in portable \gls{C} with a minimal device specific interface and functions as a \gls{TOP} engine.
\Gls{MTASK} is seamlessly integrated with \gls{ITASK}: \gls{MTASK} tasks are integrated in such a way that they function as \gls{ITASK} tasks, and \glspl{SDS} in on the device can tether an \gls{ITASK} \gls{SDS}.
% \paragraph{Contribution}
% The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer.
\item \emph{Simulation of a Task-Based Embedded Domain Specific Language for the Internet of Things} \citep{koopman_simulation_2018}\footnotemark[\value{footnote}]
- are the revised lecture notes are from a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash{}\gls{3COWS} winter school in Ko\v{s}ice, Slovakia.
+ are the revised lecture notes are from a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash{}\gls{3COWS} winter school in Ko\v{s}ice, Slovakia, January 22--26, 2018.
% \paragraph{Contribution}
% Pieter Koopman wrote and taught it, I helped with the software and research.
\item \emph{Writing Internet of Things Applications with Task Oriented Programming} \citep{lubbers_writing_2019}\footnotemark[\value{footnote}]
- are the revised lecture notes from a course on programming \gls{IOT} systems using \gls{MTASK} provided at the 2019 \gls{CEFP}\slash{}\gls{3COWS} summer school in Budapest, Hungary.
+ are the revised lecture notes from a course on programming \gls{IOT} systems using \gls{MTASK} provided at the 2019 \gls{CEFP}\slash{}\gls{3COWS} summer school in Budapest, Hungary, June 17--21, 2019.
% \paragraph{Contribution}
% Pieter Koopman prepared and taught half of the lecture and supervised the practical session.
% I taught the other half of the lecture, wrote the lecture notes, made the assignments and supervised the practical session.
% The research was carried out by \citet{crooijmans_reducing_2021} during his Master's thesis.
% I did the daily supervision and helped with the research, Pieter Koopman was the formal supervisor and wrote most of the paper.
\item \emph{Green Computing for the Internet of Things} \citep{lubbers_green_2022}\footnote{This work acknowledges the support of the \erasmusplus{} project ``SusTrainable---Promoting Sustainability as a Fundamental Driver in Software Development Training and Education'', no.\ 2020--1--PT01--KA203--078646.}
- are the revised lecture notes from a course on sustainable \gls{IOT} programming with \gls{MTASK} provided at the 2022 SusTrainable summer school in Rijeka, Croatia.
+ are the revised lecture notes from a course on sustainable \gls{IOT} programming with \gls{MTASK} provided at the 2022 SusTrainable summer school in Rijeka, Croatia, July 4--8, 2022.
% \paragraph{Contribution}
% These revised lecture notes are from a course on sustainable programming using \gls{MTASK} provided at the 2022 SusTrainable summer school in Rijeka, Croatia.
\end{enumerate}
\paragraph{Contribution:}
-The original imperative predecessors of the \gls{MTASK} language and their initial interpretations were developed by Pieter Koopman and Rinus Plasmeijer.
+The original imperative predecessors, the \gls{MTASK} language, and their initial interpretations were developed by Pieter Koopman and Rinus Plasmeijer.
I continued with the language; developed the byte code interpreter, the precursor to the \gls{C} code generation interpretation; the integration with \gls{ITASK}; and the \gls{RTS}.
The paper of which I am first author are solely written by me, there were weekly meetings with the co-authors in which we discussed and refined the ideas.
\item \emph{Tiered versus Tierless IoT Stacks: Comparing Smart Campus Software Architectures} \citep{lubbers_tiered_2020}\footnote{This work was partly funded by the 2019 Radboud-Glasgow Collaboration Fund.}\label{enum:iot20} compares traditional tiered programming to tierless architectures by comparing two implementations of a smart-campus application.
\item \emph{Could Tierless Programming Reduce IoT Development Grief?} \citep{lubbers_could_2022}
is an extended version of the paper~\ref{enum:iot20}.
- It compares programming traditional tiered architectures to tierless architectures by showing a qualitative and a quantitative four-way comparison of a smart-campus application.
+ It compares programming traditional tiered architectures to tierless architectures by illustrating a qualitative and a quantitative four-way comparison of a smart-campus application.
\end{enumerate}
\paragraph{Contribution:}
repositories / phd-thesis.git / blobdiff