1 \documentclass[../thesis.tex
]{subfiles
}
4 \ifSubfilesClassLoaded{
8 \chapter{Could Tierless Languages Reduce IoT Development Grief?
}%
9 \label{chp:smart_campus
}
11 \begin{chapterabstract
}
12 \Gls{IOT
} software is notoriously complex, conventionally comprising multiple tiers.
13 The developer must use multiple programming languages and ensure that the components interoperate correctly. A novel alternative is to use a single
\emph{tierless
} language with a compiler that generates the code for each component and ensures their correct interoperation.
15 We
report a systematic comparative evaluation of two tierless language technologies for
\gls{IOT
} stacks: one for resource-rich sensor nodes (
\gls{CLEAN
} with
\gls{ITASK
}), and one for resource-constrained sensor nodes (
\gls{CLEAN
} with
\gls{ITASK
} and
\gls{MTASK
}).
16 The evaluation is based on four implementations of a typical smart campus application: two tierless and two
\gls{PYTHON
}-based tiered.
17 %, with two targeting microprocessors and two targeting supersensors.
19 \item We show that tierless languages have the potential to significantly reduce the development effort for
\gls{IOT
} systems, requiring
70\% less code than the tiered implementations. Careful analysis attributes this code reduction to reduced interoperation (e.g.\ two
\glspl{EDSL
} and one paradigm versus seven languages and two paradigms), automatically generated distributed communication, and powerful
\gls{IOT
} programming abstractions.
20 \item We show that tierless languages have the potential to significantly improve the reliability of
\gls{IOT
} systems, describing how
\gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} maintains type safety, provides higher order failure management, and simplifies maintainability.
21 \item We
report the first comparison of a tierless
\gls{IOT
} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes. The comparison shows that they have similar code size (within
7\%), and functional structure.
22 \item We present the first comparison of two tierless
\gls{IOT
} languages, one for resource-rich sensor nodes, and the other for resource-constrained sensor nodes.
26 \section{Introduction
}%
29 Conventional
\gls{IOT
} software stacks are notoriously complex and pose very significant software development, reliability, and maintenance challenges.
\Gls{IOT
} software architectures typically comprise multiple components organised in four or more tiers or layers~
\citep{sethi2017internet,Ravulavaru18,Alphonsa20
}. This is due to the highly distributed nature of typical
\gls{IOT
} applications that must read sensor data from end points (the
\emph{perception
} layer), aggregate and select the data and communicate over a network (the
\emph{network
} layer), store the data in a database and analyse it (the
\emph{application
} layer) and display views of the data, commonly on web pages (the
\emph{presentation
} layer).
31 Conventional
\gls{IOT
} software architectures require the development of separate programs in various programming languages for each of the components/tiers in the stack. This is modular, but a significant burden for developers, and some key challenges are as follows.
33 \item Interoperating components in multiple languages and paradigms increases the developer's cognitive load who must simultaneously think in multiple languages and paradigms, i.e.\ manage significant semantic friction.
34 \item The developer must correctly interoperate the components, e.g.\ adhere to the
\gls{API
} or communication protocols between components.
35 \item To ensure correctness the developer must maintain type safety across a range of very different languages and diverse type systems.
36 \item The developer must deal with the potentially diverse failure modes of each component, and of component interoperations.
39 A radical alternative development paradigm uses a single
\emph{tierless
} language that synthesizes all components/tiers in the software stack. There are established
\emph{tierless
} languages for web stacks, e.g.\ Links~
\citep{cooper2006links
} or Hop~
\citep{serrano2006hop
}.
40 In a tierless language the developer writes the application as a single program. The code for different tiers is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the web client and to SQL on the server to interact with the database system. Tierless languages for
\gls{IOT
} stacks are more recent and less common, examples include
41 Potato~
\citep{troyer_building_2018
} and
\gls{CLEAN
} with
\gls{ITASK
}\slash\gls{MTASK
}~
\citep{lubbers_interpreting_2019
}.
43 \Gls{IOT
} sensor nodes may be microprocessors with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal
\etc.
45 Potentially a tierless language both reduces the development effort and improves correctness as correct interoperation and communication is automatically generated by the compiler. A tierless language may, however, introduce other problems. How expressive is the language? That is, can it readily express the required functionality? How maintainable is the software? Is the generated code efficient in terms of time, space, and power?
48 This paper reports a systematic comparative evaluation of two tierless language technologies for
\gls{IOT
} stacks: one targeting resource-constrained microprocessors, and the other resource-rich supersensors. The basis of the comparison is four implementations of a typical smart campus
\gls{IOT
} stack~
\citep{hentschel_supersensors:_2016
}. Two implementations are conventional tiered
\gls{PYTHON
}-based stacks:
\gls{PRS
} and
\gls{PWS
}. The other two implementations are tierless:
\gls{CRS
} and
\gls{CWS
}. Our work makes the following research contributions, and the key results are summarised, discussed, and quantified in
\cref{sec_t4t:Conclusion
}.
51 \item[C1
] We show that
\emph{tierless languages have the potential to significantly reduce the development effort for
\gls{IOT
} systems
}.
52 We systematically compare code size (
\gls{SLOC
}) of the four smart campus implementations as a measure of development effort and maintainability~
\citep{alpernaswonderful,rosenberg1997some
}.
53 The tierless implementations require
70\% less code than the tiered implementations. We analyse the codebases to attribute the code reduction to three factors.
55 \item Tierless languages benefit from reduced interoperation, requiring far fewer languages, paradigms and source code files e.g.\
\gls{CWS
} uses two languages, one paradigm and three source code files where
\gls{PWS
} uses seven languages, two paradigms and
35 source code files
56 (
\cref{table_t4t:multi,table_t4t:languages,table_t4t:paradigms
}).
57 \item Tierless languages benefit from automatically synthesized, and hence correct, communication between components that may be distributed.
58 \item Tierless languages benefit from high-level programming abstractions like compositional and higher-order task combinators (
\cref{sec_t4t:ProgrammingComparison
}).
61 \item[C2
] We show that
\emph{tierless languages have the potential to significantly improve the reliability of
\gls{IOT
} systems
}. We demonstrate how tierless languages preserve type safety, improve maintainability and provide high-level failure management. For example, we illustrate a loss of type safety in
\gls{PRS
}. We also critique current tool and community support (
\cref{sec_t4t:Discussion
}).
63 \item[C3
] We
report \emph{the first comparison of a tierless
\gls{IOT
} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes
}. The tierless smart campus implementations have a very similar code size (within
7\%), as do the tiered implementations. This suggests that the development and maintenance effort of simple tierless
\gls{IOT
} systems for resource-constrained and for resource-rich sensor nodes is similar, as it is for tiered technologies. The percentages of code required to implement each
\gls{IOT
} functionality in the tierless
\gls{CLEAN
} implementations is very similar, as it is in the tiered
\gls{PYTHON
} implementations. This suggests that the code for resource-constrained and resource-rich sensor nodes is broadly similar in tierless technologies, as in tiered technologies (
\cref{sec_t4t:resourcerich
})
65 \item[C4
] \emph{We present the first comparison of two tierless
\gls{IOT
} languages, one designed for resource-constrained sensor nodes (
\gls{CLEAN
} with
\gls{ITASK
} and
\gls{MTASK
}), and the other for resource-rich sensor nodes (
\gls{CLEAN
} with
\gls{ITASK
}).
}
66 We show that the bare metal execution environment enforces some restrictions on
\gls{MTASK
} although they remain high level. Moreover, the environment conveys some advantages, e.g.\ better control over timing (
\cref{sec_t4t:ComparingTierless
}).
69 The current work extends~
\citep{lubbers_tiered_2020
} as follows. Contributions C3 and C4 are entirely new, and C1 is enhanced by being based on the analysis of four rather than two languages and implementations.
71 \section{Background and related work
}%
72 \label{sec_t4t:Background
}
74 \subsection{\texorpdfstring{\Acrlong{UOG
}}{University of Glasgow
} smart campus
}%
75 \label{sec_t4t:UoGSmartCampus
}
77 The
\gls{UOG
} is partway through a ten-year campus
78 upgrade programme, and a key goal is to embed pervasive sensing infrastructure into
79 the new physical fabric to form a
\emph{smart campus
} environment.
80 As a prototyping exercise, we use modest commodity
81 sensor nodes (i.e.\ Raspberry Pis) and low-cost, low-precision sensors
82 for indoor environmental monitoring.
84 We have deployed sensor nodes into
12 rooms in two buildings. The
\gls{IOT
} system has an online data store, providing live
85 access to sensor data through a RESTful
\gls{API
}.
86 This allows campus stakeholders to add functionality at a business layer above the layers that we consider here. To date,
87 simple apps have been developed including room temperature
88 monitors and campus utilization maps~
\citep{hentschel_supersensors:_2016
}.
89 A longitudinal study of sensor accuracy has also been
90 conducted~
\citep{harth_predictive_2018
}.
92 \subsection{\texorpdfstring{\Gls{IOT
}}{IoT
} applications
}%
93 \label{sec_t4t:Stacks
}
95 Web applications are necessarily complex distributed systems, with client browsers interacting with a remote webserver and data store. Typical
\gls{IOT
} applications
96 are even more complex as they combine a web application with a second distributed system of sensor and actuator nodes that collect and aggregate data, operate on it, and communicate with the server.
98 Both web and
\gls{IOT
} applications are commonly structured into tiers, e.g.\ the classical four-tier Linux, Apache, MySQL and PHP (LAMP) stack.
99 \Gls{IOT
} stacks typically have more tiers than webapps, with the number depending on the complexity of the application~
\citep{sethi2017internet
}. While other tiers, like the business layer~
\citep{muccini2018iot
} may be added above them, the focus of our study is on programming the lower four tiers of the
\gls{PRS
},
\gls{CRS
},
\gls{PWS
} and
\gls{CWS
} stacks, as illustrated in
\cref{fig_t4t:iot_arch
}.
101 \begin{description
}%[style=nextline]
102 \item [Perception layer
] collects the data, interacts with the environment, and consists of devices using light, sound, motion, air quality and temperature sensors.
103 \item [Network layer
] replays the communication messages between the sensor nodes and the server through protocols such as
\gls{MQTT
}.
105 \item [Application layer
] acts as the interface between the presentation layer and the perception layer, storing and processing the data.
107 \item [Presentation layer
] utilises web components as the interface between the human and devices where application services are provided.
114 \includegraphics[width=
\linewidth]{arch
}
116 \gls{PRS
} and
\gls{PWS
} (left) together with
\gls{CRS
} and
\gls{PRS
} (right) mapped to the four-tier
\gls{IOT
} architecture.
117 Every box is the diagram denotes a source file or base.
118 Bold blue text describes the language or technology used in that source.
119 The network and perception layer are unique to the specific implementation, where the application and presentation layers are shared between implementations.
121 \label{fig_t4t:iot_arch
}
125 \subsection{The benefits and challenges of developing tiered
\texorpdfstring{\gls{IOT
}}{IoT
} stacks
}
127 Using multiple tiers to
128 structure complex software is a common software engineering practice that provides significant architectural benefits for
\gls{IOT
} and other software. The tiered
\gls{PYTHON
} \gls{PRS
} and
\gls{PWS
} stacks exhibit these benefits.
131 \item[Modularity
] tiers allow a system to be structured as a set of components with clearly defined functionality. They can be implemented independently, and may be interchanged with other components that have similar functionality~
\citep{maccormack2007impact
}. In
\gls{PRS
} and
\gls{PWS
}, for example, a different NoSQL DBMS could relatively easily be substituted for
{MongoDB
}.
133 \item[Abstraction
] the hierarchical composition of components in the stack abstracts the view of the system as a whole. Enough detail is provided to understand the roles of each layer and how the components relate to one another~
\citep{belle2013layered
}.
\Cref{fig_t4t:iot_arch
} illustrates the abstraction of
\gls{PRS
} and
\gls{PWS
} into four tiers.
135 \item[Cohesion
] well-defined boundaries ensure each tier contains functionality directly related to the task of the component~
\citep{lee2001component
}. The tiers in
\gls{PRS
} and
\gls{PWS
} contain all the functionality associated with perception, networking, application and presentation respectively.
139 However, a tiered architecture poses significant challenges for developers of
\gls{IOT
} and other software. The tiered
\gls{PYTHON
} \gls{PRS
} and
\gls{PWS
} stacks exhibit these challenges, and we analyse these in detail later in the paper.
142 \item[Polyglot development
] the developer must be fluent in all the languages and components in the stack, known as being a full-stack developer for webapps
\citep{mazzei2018full
}. That is, the developer must correctly use multiple languages that have different paradigms, i.e.\ manage significant
\emph{semantic friction
}~
\citep{ireland2009classification
}. For example the
\gls{PWS
} developer must integrate components written in seven languages with two paradigms (
\cref{sec_t4t:interoperation
}).
143 \item[Correct interoperation
] the developer must adhere to the
\gls{API
} or communication protocols between components.
\Cref{sec_t4t:codesize,sec_t4t:resourcerich
} show that communication requires some
17\% of
\gls{PRS
} and
\gls{PWS
} code, so around
100 \gls{SLOC
}.
\Cref{sec_t4t:Communication
} discusses the complexity of writing this distributed communication code.
144 \item[Maintaining type safety
] is a key element of the semantic friction encountered in multi-language stacks, and crucial for correctness. The developer must maintain type safety across a range of very different languages and diverse type systems, with minimal tool support. We show an example where
\gls{PRS
} loses type safety over the network layer (
\Cref{sec_t4t:typesafety
}).
145 \item[Managing multiple failure modes
] different components may have different failure modes, and these must be coordinated.
\Cref{sec_t4t:NetworkManagement
} outlines how
\gls{PRS
} and
\gls{PWS
} use heartbeats to manage failures.
148 Beyond
\gls{PRS
} and
\gls{PWS
} the challenges of tiered polyglot software development are evidenced in real world studies. As recent examples, a study of GitHub open source projects found an average of five different languages in each project, with many using tiered architectures~
\citep{mayer2017multi
}.
149 An earlier empirical study of GitHub shows that using more languages to implement a project has a significant effect on project quality, since it increases defects~
\citep{kochhar2016large
}.
150 A study of
\gls{IOT
} stack developers found that interoperation poses a real challenge, that microservices blur the abstraction between tiers, and that both testing and scaling
\gls{IOT
} applications to more devices are hard~
\citep{motta2018challenges
}.
152 One way of minimising the challenges of developing tiered polyglot
\gls{IOT
} software is to standardise and reuse components. This approach has been hugely successful for web stacks, e.g.\ browser standards. The W3C
153 Web of Things aims to facilitate re-use by providing standardised metadata and other re-usable technological
\gls{IOT
} building blocks~
\citep{guinard_building_2016
}. However, the Web of Things has yet to gain widespread adoption. Moreover, as it is based on web technology, it requires the
\emph{thing
} to run a web server, significantly increasing the hardware requirements.
155 \section{Tierless languages
}%
156 \label{sec_t4t:TiredvsTierless
}
158 A radical approach to overcoming the challenges raised by tiered distributed software is to use a tierless programming language that eliminates the semantic friction between tiers by generating code for all tiers, and all communication between tiers, from a single program.
159 %\adriancomment{Also referred to as multi-tier programming, tierless language applications usually utilise a single language, paradigm and type system, and the entire system is simultaneously checked by the compiler~\citep{weisenburger2020survey}.}
160 Typically a tierless program uses a single language, paradigm and type system, and the entire distributed system is simultaneously checked by the compiler.
162 There is intense interest in developing tierless, or multitier, language technologies with a number of research languages developed over the last fifteen years, e.g.\
\citep{cooper2006links, serrano2006hop, troyer_building_2018,
10.1145/
2775050.2633367}. These languages demonstrate the
163 advantages of the paradigm, including less development effort, better maintainability, and sound semantics of distributed execution. At the same time a number of industrial technologies incorporate tierless concepts, e.g.\
\citep{balat2006ocsigen, bjornson2010composing, strack2015getting
}. These languages demonstrate the benefits of the paradigm in practice. Some tierless languages use (embedded)
\glspl{DSL
} to specify parts of the multi-tier software.
165 Tierless languages have been developed for a range of distributed paradigms, including web applications, client-server applications, mobile applications, and generic distributed systems. A recent and substantial survey of these tierless technologies is available~
\citep{weisenburger2020survey
}. Here we provide a brief introduction to tierless languages with a focus on
\gls{IOT
} software.
167 \subsection{Tierless web languages
}
169 There are established tierless languages for web development, both standalone languages and
\glspl{DSL
} embedded in a host language.
170 Example standalone tierless web languages are Links~
\citep{cooper2006links
} and Hop~
\citep{serrano2006hop
}.
171 From a single declarative program the client, server and database code is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the client side and to SQL on the server-side to interact with the database system.
173 An example tierless web framework that uses a
\gls{DSL
} is Haste~
\citep{10.1145/
2775050.2633367}, that embeds the
\gls{DSL
} in
\gls{HASKELL
}. Haste programs are compiled multiple times: the server code is generated by the standard
\gls{GHC
} \gls{HASKELL
} compiler~
\citep{hall1993glasgow
}; Javascript for the client is generated by a custom
\gls{GHC
} compiler backend. The design leverages
\gls{HASKELL
}'s high-level programming abstractions and strong typing, and benefits from
\gls{GHC
}: a mature and sophisticated compiler.
176 \subsection{Tierless
\texorpdfstring{\gls{IOT
}}{IoT
} languages
}
177 The use of tierless languages in
\gls{IOT
} applications is both more recent and less common than for web applications.
178 Tierless
\gls{IOT
} programming may extend tierless web programming by adding network and perception layers.
179 The presentation layer of a tierless
\gls{IOT
} language, like tierless web languages, benefits from almost invariably executing in a standard browser. The perception layer faces greater challenges, often executing on one of a set of slow and resource-constrained microprocessors. Hence, tierless
\gls{IOT
} languages typically compile the perception layer to either
\gls{C
}\slash\gls{CPP
} (the lingua franca of microcontrollers), or to some intermediate representation to be interpreted.
181 \subsubsection{\texorpdfstring{\Glspl{DSL
}}{DSLs
} for microprocessors
}
182 Many
\glspl{DSL
} provide high-level programming for microprocessors, for example providing strong typing and memory safety.
183 For example Copilot~
\citep{hess_arduino-copilot_2020
}
184 and Ivory~
\citep{elliott_guilt_2015
} are imperative
\glspl{DSL
} embedded in a functional language that compile to
\gls{C
}\slash\gls{CPP
}. In contrast to
\gls{CLEAN
}/
\gls{ITASK
}/
\gls{MTASK
} such
\glspl{DSL
} are not tierless
\gls{IOT
} languages as they have no automatic integration with the server, i.e.\ with the application and presentation layers.
187 \subsubsection{\texorpdfstring{\Gls{FRP
}}{Functional reactive programming
}}
188 \Gls{FRP
} is a declarative paradigm often used for implementing the perception layer of an
\gls{IOT
} stack.
189 Examples include mfrp~
\citep{sawada_emfrp:_2016
}, CFRP~
\citep{suzuki_cfrp_2017
}, XFRP~
\citep{10.1145/
3281366.3281370}, Juniper~
\citep{helbling_juniper:_2016
}, Hailstorm~
\citep{sarkar_hailstorm_2020
}, and Haski~
\citep{valliappan_towards_2020
}.
190 None of these languages are tierless
\gls{IOT
} languages as they have no automatic integration with the server.
192 Potato goes beyond other
\gls{FRP
} languages to provide a tierless
\gls{FRP
} \gls{IOT
} language for resource rich sensor nodes~
\citep{troyer_building_2018
}. It does so using the Erlang programming language and sophisticated virtual machine.
194 TOP allows for more complex collaboration patterns than
\gls{FRP
}~
\citep{wang_maintaining_2018
}, and in consequence is unable to provide the strong guarantees on memory usage available in a restricted variant of
\gls{FRP
} such as arrowized
\gls{FRP
}~
\citep{nilsson_functional_2002
}.
196 \subsubsection{Erlang/Elixir
\texorpdfstring{\gls{IOT
}}{IoT
} systems
}
197 A number of production
\gls{IOT
} systems are engineered in Erlang or Elixir, and many are mostly tierless.
198 That is the perception, network and application layers are sets of distributed Erlang processes, although the presentation layer typically uses some conventional web technology.
199 A resource-rich sensor node may support many Erlang processes on an Erlang VM, or low level code (typically
\gls{C
}\slash\gls{CPP
}) on a resource-constrained microprocessor can emulate an Erlang process.
200 Only a small fraction of these systems are described in the academic literature, example exceptions are~
\citep{sivieri2012drop,shibanai_distributed_2018
}, with many described only in grey literature or not at all.
202 \subsection{Characteristics of tierless
\texorpdfstring{\gls{IOT
}}{IoT
} languages
}%
203 \label{sec_t4t:characteristics
}
205 This study compares a pair of tierless
\gls{IOT
} languages with conventional tiered
\gls{PYTHON
} \gls{IOT
} software.
\gls{CLEAN
}\slash\gls{ITASK
} and
\gls{CLEAN
}/
\gls{ITASK
}/
\gls{MTASK
} represent a specific set of tierless language design decisions, however many alternative designs are available. Crucially the limitations of the tierless
\gls{CLEAN
} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general. This section briefly outlines key design decisions for tierless
\gls{IOT
} languages, discusses alternative designs, and describes the
\gls{CLEAN
} designs. The
\gls{CLEAN
} designs are illustrated in the examples in the following section.
207 \subsubsection{Program splitting
}
209 A key challenge for an automatically segmented tierless language is to determine which parts of the program correspond to a particular tier and hence should be executed by a specific component on a specific host, so-called tier splitting.
210 For example a tierless web language must identify client code to ship to browsers, database code to execute in the DBMS, and application code to run on the server. Some tierless languages split programs using types, others use syntactic markers, e.g.\ pragmas like
\cleaninline{server
} or
\cleaninline{client
}, to split the program~
\citep{cooper2006links,
10.1145/
2775050.2633367}. It may be possible to infer the splitting between tiers, relieving the developers from the need specify it, as illustrated for Javascript as a tierless web language~
\citep{10.1145/
2661136.2661146}.
212 In
\gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} and
\gls{CLEAN
}/
\gls{ITASK
} tier splitting is specified by functions, and hence is a first-class language construct.
213 For example in
\gls{CLEAN
}\slash\gls{ITASK
} the
\cleaninline{asyncTask
} function identifies a task for execution on a remote device and
\cleaninline{liftmTask
} executes the given task on an
\gls{IOT
} device. The tier splitting functions are illustrated in examples in the next section, e.g.\ on
\cref{lst_t4t:itaskTempFull:startdevtask
} in
\cref{lst_t4t:itaskTempFull
} and
\cref{lst_t4t:mtaskTemp:liftmtask
} in
\cref{lst_t4t:mtaskTemp
}.
214 Specifying splitting as functions means that new splitting functions can be composed, and that splitting is under program control, e.g.\ during execution a program can decide to run a task locally or remotely.
216 \subsubsection{Communication
}\label{ssec_t4t:communication
}
218 Tierless languages may adopt a range of communication paradigms for communicating between components. Different tierless languages specify communication in different ways~
\citep{weisenburger2020survey
}. Remote procedures are the most common communication mechanism: a procedure/function executing on a remote host/machine is called as if it was local. The communication of the arguments to, and the results from, the remote procedure is automatically provided by the language implementation. Other mechanisms include explicit message passing between components; publish/subscribe where components subscribe to topics of interest from other components; reactive programming defines event streams between remote components; finally shared state makes changes in a shared and potentially remote data structure visible to components.
220 \Gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} and
\gls{CLEAN
}/
\gls{ITASK
} communicate using a combination of remote task invocation, similar to remote procedures, and shared state through
\glspl{SDS
}.
221 \Cref{lst_t4t:itaskTempFull
} illustrates:
\cref{lst_t4t:itaskTempFull:startdevtask
} shows a server task launching a remote task,
\cleaninline{devTask
}, on to a sensor node; and
\cref{lst_t4t:itaskTempFull:remoteShare
} shows the sharing of the remote
\cleaninline{latestTemp
} \gls{SDS
}.
222 %\mlcomment{I think this is fine}
224 \subsubsection{Placement
}
226 In many
\gls{IOT
} systems the sensor nodes are microprocessors that are programmed by writing the program to flash memory. This means that without extra effort, physical access to the microcontroller is needed to change the program making updates challenging.
227 Hence, most
\gls{IOT
} systems compile sensor node code directly for the target architecture or via an existing language such as
\gls{C
}\slash\gls{CPP
}.
229 Techniques such as over-the-air programming and interpreters allow microprocessors to be dynamically provisioned, increasing their maintainability and resilience.
230 For example Baccelli et al.\ provide a single language
\gls{IOT
} system based on the RIOT
\gls{OS
} that allows runtime deployment of code snippets called containers~
\citep{baccelli_reprogramming_2018
}.
231 Both client and server are written in JavaScript. However, there is no integration between the client and the server other than that they are programmed from a single source.
232 Mat\`e is an example of an early tierless sensor network framework where devices are provided with a virtual machine using TinyOS for dynamic provisioning~
\citep{levis_mate_2002
}.
234 Placement specifies how data and computations in a tierless program are assigned to the
235 devices/hosts in the distributed system. Different tierless languages specify placement in different ways, e.g.\ code annotations or configuration files, and at different granularities, e.g.\ per function or per class~
\citep{weisenburger2020survey
}.
237 \Gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} and
\gls{CLEAN
}/
\gls{ITASK
} both use dynamic task placement, similar to dynamic function placement.
238 In
\gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} sensor nodes are programmed once with the
\gls{MTASK
} \gls{RTS
}, and possibly some precompiled tasks.
239 Thereafter a sensor node can dynamically receive
\gls{MTASK
} programs, compiled at runtime by the server.
240 In
\gls{CLEAN
}\slash\gls{ITASK
} the sensor node runs an
\gls{ITASK
} server that recieves and executes code from the (
\gls{IOT
}) server~
\citep{oortgiese_distributed_2017
}.
241 %The \gls{ITASK} server decides what code to execute depending on the serialised execution graph that the server sends~\citep{oortgiese_distributed_2017}.
242 Placement happens automatically as part of the first-class splitting constructs outlined in
\cref{ssec_t4t:communication
}, so
\cref{lst_t4t:mtaskTemp:liftmtask
} in
\cref{lst_t4t:mtaskTemp
} places
\cleaninline{devTask
} onto the
\cleaninline{dev
} sensor node.
244 \subsubsection{Security
}
246 Security is a major issue and a considerable challenge for many
\gls{IOT
} systems~
\citep{10.1145/
3437537}. There are potentially security issues at each layer in an
\gls{IOT
} application (
\cref{fig_t4t:iot_arch
}). The security issues and defence mechanisms at the application and presentation layers are relatively standard, e.g.\ defending against SQL injection attacks. The security issues at the network and perception layers are more challenging. Resource-rich sensor nodes can adopt some standard security measures like encrypting messages, and regularly applying software patches to the operating system. However microprocessors often lack the computational resources for encryption, and it is hard to patch their system software because the program is often stored in flash memory. In consequence there are infamous examples of
\gls{IOT
} systems being hijacked to create botnets~
\citep{203628,herwig_measurement_2019
}.
248 Securing the entire stack in a conventional tiered
\gls{IOT
} application is particularly challenging as the stack is implemented in a collection of programming languages with low level programming and communication abstractions. In such polyglot distributed systems it is hard to determine, and hence secure, the flow of data between components. In consequence a small mistake may have severe security implications.
250 A number of characteristics of tierless languages help to improve security. Communication and placement vulnerabilities are minimised as communication and placement are automatically generated and checked by the compiler. So injection attacks and the exploitation of communication/placement protocol bugs are less likely. Vulnerabilities introduced by mismatched types are avoided as the entire system is type checked. Moreover, tierless languages can exploit language level security techniques. For example languages like Jif/split~
\citep{zdancewic2002secure
} and Swift~
\citep{chong2007secure
} place components to protect the security of data. Another example are programming language technologies for controlling information flow, and these can be used to improve security. For example Haski uses them to improve the security of
\gls{IOT
} systems~
\citep{valliappan_towards_2020
}.
252 However many tierless languages have yet to provide a comprehensive set of security technologies, despite its importance in domains like web and
\gls{IOT
} applications. For example Erlang and many Erlang-based systems~
\citep{shibanai_distributed_2018,sivieri2012drop
}, lack important security measures. Indeed security is not covered in a recent, otherwise comprehensive, survey of tierless technologies~
\citep{weisenburger2020survey
}.
254 \Gls{CLEAN
}\slash\gls{ITASK
} and
\gls{CLEAN
}/
\gls{ITASK
}/
\gls{MTASK
} are typical in this respect: little effort has yet been expended on improving their security. Of course as tierless languages they benefit from static type safety and automatically generated communication and placement. Some preliminary work shows that, as the communication between layers is protocol agnostic, more secure alternatives can be used. One example is to run the
\gls{ITASK
} server behind a reverse proxy implementing TLS/SSL encryption~
\citep{wijkhuizen_security_2018
}. A second is to add integrity checks or even encryption to the communication protocol for resource-rich sensor nodes~
\citep{boer_de_secure_2020
}.
256 \section{Task-oriented and
\texorpdfstring{\gls{IOT
}}{IoT
} programming in
\texorpdfstring{\gls{CLEAN
}}{Clean
}}
258 To make this paper self-contained we provide a concise overview of
\gls{CLEAN
},
\gls{TOP
}, and
\gls{IOT
} programming in
\gls{ITASK
} and
\gls{MTASK
}. The minor innovations reported here are the interface to the
\gls{IOT
} sensors, and the
\gls{CLEAN
} port for the Raspberry Pi.
260 \Gls{CLEAN
} is a statically typed
\gls{FP
} language similar to
\gls{HASKELL
}: both languages are pure and non-strict~
\citep{achten_clean_2007
}.
261 A key difference is how state is handled:
\gls{HASKELL
} typically embeds stateful actions in the
\haskellinline{IO
} Monad~
\citep{peyton_jones_imperative_1993,wiki:IO
}.
262 In contrast,
\gls{CLEAN
} has a uniqueness type system to ensure the single-threaded use of stateful objects like files and windows~
\citep{barendsen_smetsers_1996
}.
263 Both
\gls{CLEAN
} and
\gls{HASKELL
} support fairly similar models of generic programming~
\citep{ComparingGenericProgramming
}, enabling functions to work on many types. As we shall see generic programming is heavily used in task-oriented programming~
\citep{GenericProgrammingExtensionForClean,HinzeGenericFunctionalProgramming
}, for example to construct web editors and communication protocols that work for any user-defined datatype.
265 \subsection{\texorpdfstring{\Acrlong{TOP
}}{Task-oriented programming
}}
267 \Gls{TOP
} is a declarative programming paradigm for constructing interactive distributed systems~
\citep{plasmeijer_task-oriented_2012
}.
268 Tasks are the basic blocks of
\gls{TOP
} and represent work that needs to be done in the broadest sense.
269 Examples of typical tasks range from allowing a user to complete a form, controlling peripherals, moderating other tasks, or monitoring a database.
270 From a single declarative description of tasks all of the required software components are generated.
271 This may include web servers, client code for browsers or
\gls{IOT
} devices, and for their interoperation.
272 That is, from a single
\gls{TOP
} program the language implementation automatically generates an
\emph{integrated distributed system
}.
273 Application areas range from simple web forms or blinking
\glspl{LED
} to multi-user distributed collaboration between people and machines~
\citep{oortgiese_distributed_2017
}.
276 \Gls{TOP
} adds three concepts: tasks, task combinators, and
\glspl{SDS
}. Example basic tasks are web editors for user-defined datatypes, reading some
\gls{IOT
} sensor, or controlling peripherals like a servo motor.
277 Task combinators compose tasks into more advanced tasks, either in parallel or sequential and allow task values to be observed by other tasks.
278 As tasks can be returned as the result of a function, recursion can be freely used, e.g.\ to express the repetition of tasks.
279 There are also standard combinators for common patterns.
280 Tasks can exchange information via
\glspl{SDS
}~
\citep{ParametricLenses
}.
281 All tasks involved can atomically observe and change the value of a typed
\gls{SDS
}, allowing more flexible communication than with task combinators.
282 \Glspl{SDS
} offer a general abstraction of data shared by different tasks, analogous to variables, persistent values, files, databases and peripherals like sensors. Combinators compose
\glspl{SDS
} into a larger
\gls{SDS
}, and
283 parametric lenses define a specific view on an
\gls{SDS
}.
285 \subsection{The
\texorpdfstring{\gls{ITASK
}}{iTask
} \texorpdfstring{\gls{EDSL
}}{eDSL
}}%
286 \label{sec_t4t:itasks
}
287 The
\gls{ITASK
} \gls{EDSL
} is designed for constructing multi-user distributed applications, including web~
\citep{TOP-ICFP07
} or
\gls{IOT
} applications.
288 Here we present
\gls{ITASK
} by example, and the first is a complete program to repeatedly read the room temperature from a digital humidity and temperature (DHT) sensor attached to the machine and display it on a web page (
\cref{lst_t4t:itaskTemp
}).
289 The first line is the module name, the third imports the
\cleaninline{iTask
} module, and the main function (
\cref{lst_t4t:itaskTemp:systemfro,lst_t4t:itaskTemp:systemto
}) launches
\cleaninline{readTempTask
} and the
\gls{ITASK
} system to generate the web interface in
\cref{fig_t4t:itaskTempSimple
}.
291 Interaction with a device like the DHT sensor using a protocol like
1-Wire or gls
{I2C
} is abstracted into a library. So the
\cleaninline{readTempTask
} task starts by creating a
\cleaninline{dht
} sensor object (
\cref{lst_t4t:itaskTemp:dhtDef
}) thereafter
\cleaninline{repeatEvery
} executes a task at the specified
\cleaninline{interval
}. This task reads the temperature from the
\cleaninline{dht
} sensor, and with a sequential composition combinator
\cleaninline{>>~
} passes the
\cleaninline{temp
} value to
\cleaninline{viewInformation
} that displays it on the web page (
\cref{lst_t4t:itaskTemp:viewInformation
}).
292 The tuning combinator
\cleaninline{<<@
} adds a label to the web editor displaying the temperature. Crucially, the
\gls{ITASK
} implementation transparently ships parts of the code for the web-interface to be executed in the browser, and
\cref{fig_t4t:itaskTempSimple
} shows the UML deployment diagram.
296 caption=
{SimpleTempSensor: a
\gls{CLEAN
}\slash\gls{ITASK
} program to read a local room temperature sensor and display it on a web page
},
297 label=
{lst_t4t:itaskTemp
}]
298 module simpleTempSensor
302 Start :: *World -> *World
[+
\label{lst_t4t:itaskTemp:systemfro
}+
]
303 Start world = doTasks readTempTask world
[+
\label{lst_t4t:itaskTemp:systemto
}+
]
305 readTempTask :: Task Real
307 withDHT IIO_TempID
\dht ->
[+
\label{lst_t4t:itaskTemp:dhtDef
}+
]
308 repeatEvery interval (
[+
\label{lst_t4t:itaskTemp:repeat
}+
]
309 temperature dht >>~
\temp ->
[+
\label{lst_t4t:itaskTemp:readDHT
}+
]
310 viewInformation
[] temp <<@
[+
\label{lst_t4t:itaskTemp:viewInformation
}+
]
311 Label "Temperature"
[+
\label{lst_t4t:itaskTemp:label
}+
]
317 \begin{subfigure
}[t
]{.2\textwidth}
319 \fbox{\includegraphics[width=
.9\textwidth]{readTempTask
}}
322 \begin{subfigure
}[t
]{.8\textwidth}
324 \includegraphics[width=
\textwidth]{simpleTempSensor
}
325 \caption{Deployment diagram.
}
327 \caption{\Gls{ITASK
} SimpleTempSensor.
}%
328 \label{fig_t4t:itaskTempSimple
}
331 SimpleTempSensor only reports instantaneous temperature measurements. Extending it to store and manipulate timed temperature records produces a tiny tierless web application: TempHistory in
\cref{lst_t4t:TempHistory
}. A tierless
\gls{IOT
} system can be controlled from a web interface in exactly the same way, e.g.\ to view and set the measurement frequencies of each of the room sensors.
\Cref{lst_t4t:itaskTemp:Measurement
} defines a record to store
\cleaninline{time
} and
\cleaninline{temp
} measurements. Task manipulations are derived for
\cleaninline{Measurement
} (
\cref{lst_t4t:itaskTemp:derive
}) and these include displaying measurements in a web-editor and storing them in a file.
332 \Cref{lst_t4t:itaskTemp:measurementsSDS
} defines a persistent
\gls{SDS
} to store a list of measurements, and for communication between tasks. The
\gls{SDS
} is analogous to the SQL DBMS in many tiered web applications.
334 TempHistory defines two tasks that interact with the
\texttt{mea\-sure\-ments\-SDS
}:
\texttt{mea\-sure\-Task
} adds measurements at each detected change in the temperature.
335 It starts by defining a
\cleaninline{dht
} object as before, and then defines a recursive
\cleaninline{task
} function parameterized by the
\cleaninline{old
} temperature.
336 This function reads the temperature from the DHT sensor and uses the step combinator,
\cleaninline{>>*
}, to compose it with a list of actions.
337 The first of those actions that is applicable determines the continuation of this task. If no action is applicable, the task on the left-hand side is evaluated again.
338 The first action checks whether the new temperature is different from the
\cleaninline{old
} temperature (
\cref{lst_t4t:itaskTemp:action1
}). If so, it records the current time and adds the new measurements to the
\cleaninline{measurementsSDS
}.
339 The next action in
\cref{lst_t4t:itaskTemp:action2
} is always applicable and waits (sleeps) for an interval before returning the old temperature.
340 On
\cref{lst_t4t:itaskTemp:launch
} \cleaninline{task
} is launched with an initial temperature.
344 caption=
{TempHistory: a tierless
\gls{CLEAN
}\slash\gls{ITASK
} webapplication that records and manipulates timed temperatures
},
345 label=
{lst_t4t:TempHistory
}]
348 import iTasks, iTasks.Extensions.DateTime
350 :: Measurement =
{time :: Time, temp :: Real
} [+
\label{lst_t4t:itaskTemp:Measurement
}+
]
351 derive class iTask Measurement
[+
\label{lst_t4t:itaskTemp:derive
}+
]
353 measurementsSDS :: SimpleSDSLens
[Measurement
] [+
\label{lst_t4t:itaskTemp:measurementsSDS
}+
]
354 measurementsSDS = sharedStore "measurements"
[]
356 measureTask :: Task ()
[+
\label{lst_t4t:itaskTemp:measureTask
}+
]
358 withDHT IIO_TempID
\dht ->
360 temperature dht >>*
[+
\label{lst_t4t:itaskTemp:step
}+
]
361 [ OnValue (ifValue ((<>) old)
\temp ->
[+
\label{lst_t4t:itaskTemp:action1
}+
]
362 get currentTime >>~
\time ->
363 upd (
\list.
[{time=time, temp=temp
}:list
]) measurementsSDS
365 , OnValue (always (waitForTimer False interval @! old))
[+
\label{lst_t4t:itaskTemp:action2
}+
]
367 in task initialTemp
[+
\label{lst_t4t:itaskTemp:launch
}+
]
370 controlSDS :: Bool -> Task
[Measurement
]
372 ((Label "# to take" @>> enterInformation
[]) -||
[+
\label{lst_t4t:itaskTemp:enter
}+
]
373 (Label "Measurements" @>>
[+
\label{lst_t4t:itaskTemp:view
}+
]
374 viewSharedInformation
375 [ ViewAs (if byTemp (sortBy (
\x y->x.temp < y.temp)) id)
]
376 measurementsSDS)) >>*
[+
\label{lst_t4t:itaskTemp:viewend
}+
]
377 [ OnAction (Action "Clear") (always
378 (set
[] measurementsSDS >-| controlSDS byTemp))
379 , OnAction (Action "Take") (ifValue ((<)
0)
380 (
\n.upd (take n) measurementsSDS >-| controlSDS byTemp))
381 , OnAction (Action (if byTemp "Sort time" "Sort temp")) (always
382 (controlSDS (not byTemp)))
383 ] [+
\label{lst_t4t:itaskTemp:actionend
}+
]
385 mainTask :: Task
[Measurement
]
386 mainTask = controlSDS False -|| measureTask
389 The
\cleaninline{controlSDS
} task illustrates communication from the web page user and persistent data manipulation. That is, it generates a web page that allows users to control their view of the temperature measurements, as illustrated in
\cref{fig_t4t:TempHistory
}. The page contains
391 \item a web editor to enter the number
\cleaninline{n
} of elements to display, generated on
\cref{lst_t4t:itaskTemp:enter
}.
392 \item A display of the
\cleaninline{n
} most recent temperature and time measurements,
\crefrange{lst_t4t:itaskTemp:view
}{lst_t4t:itaskTemp:viewend
}.
393 \item Three buttons that are again combined with the step combinator
\cleaninline{>>*
},
\crefrange{lst_t4t:itaskTemp:viewend
}{lst_t4t:itaskTemp:actionend
}. The
\cleaninline{Clear
} button is
\cleaninline{always
} enabled and sets the
\gls{SDS
} to an empty list before calling
\cleaninline{controlSDS
} recursively. The
\cleaninline{Take
} button is only enabled when the web editor produces a positive
\cleaninline{n
} and updates the
\cleaninline{measurementsSDS
} with the
\cleaninline{n
} most recent measurements before calling
\cleaninline{controlSDS
} recursively. The final action is
\cleaninline{always
} enabled and calls
\cleaninline{controlSDS
} recursively with the negation of the
\cleaninline{byTemp
} argument to change the sorting criteria.
398 \begin{subfigure
}[t
]{.5\textwidth}
400 \fbox{\includegraphics[width=
.95\textwidth]{TempHistory1
}}
401 \caption{Web page sorted by time.
}
403 \begin{subfigure
}[t
]{.5\textwidth}
405 \fbox{\includegraphics[width=
.95\textwidth]{TempHistory2
}}
406 \caption{Web page sorted by temperature.
}
408 \caption{Web pages generated by the
\cleaninline{TempHistory
} \gls{CLEAN
}\slash\gls{ITASK
} tierless web application.
409 The
\cleaninline{Take
} button is only enabled when the topmost editor contains a positive number.
411 \label{fig_t4t:TempHistory
}
416 \includegraphics[width=
.95\textwidth]{TempHistory
}
417 \caption{Deployment diagram of the
\gls{ITASK
} TempHistory tierless web application from
\cref{lst_t4t:TempHistory
}.
}%
418 \label{fig_t4t:TempHistoryDiagram
}%
421 \Cref{fig_t4t:TempHistory
} shows two screenshots of web pages generated by the
\cleaninline{TempHistory
} program.
\Cref{fig_t4t:TempHistoryDiagram
} is the deployment diagram showing the addition of the persistent
\cleaninline{measurementsSDS
} that stores the history of temperature measurements.
423 \subsection{Engineering tierless
\texorpdfstring{\gls{IOT
}}{IoT
} systems with
\texorpdfstring{\gls{ITASK
}}{iTask
}}%
424 \label{sec_t4t:itaskIOT
}
426 A typical
\gls{IOT
} system goes beyond a web application by incorporating a distributed set of sensor nodes each with a collection of sensors or actuators. That is, they add the perception and network layers in
\cref{fig_t4t:iot_arch
}. If the sensor nodes have the computational resources to support an
\gls{ITASK
} server, as a Raspberry Pi does, then
\gls{ITASK
} can also be used to implement these layers, and integrate them with the application and presentation layers tierlessly.
428 As an example of tierless
\gls{IOT
} programming in
\gls{CLEAN
}\slash\gls{ITASK
} \cref{lst_t4t:itaskTempFull
} shows a complete temperature sensing system with a server and a single sensor node (
\gls{CRTS
}), omitting only the module name and imports.
429 It is similar to the SimpleTempSensor and TempHistory programs above, for example
\cleaninline{devTask
} repeatedly sleeps and records temperatures and times, and
\cleaninline{mainTask
} displays the temperatures on the web page in
\cref{fig_t4t:cwtsweb
}. There are some important differences, however. The
\cleaninline{devTask
} (
\crefrange{lst_t4t:itaskTempFull:sensorfro
}{lst_t4t:itaskTempFull:sensorto
}) executes on the sensor node and records the temperatures in a standard timestamped (lens on) an
\gls{SDS
}:
\cleaninline{dateTimeStampedShare
} \cleaninline{latestTemp
}.
430 The
\cleaninline{mainTask
} (
\cref{lst_t4t:itaskTempFull:main
}) executes on the server: it starts
\cleaninline{devTask
} as an asynchronous task on the specified sensor node (
\cref{lst_t4t:itaskTempFull:startdevtask
}) and then generates a web page to display the latest temperature and time (
\cref{lst_t4t:itaskTempFull:displaystart,lst_t4t:itaskTempFull:displayend
}).
432 The
\cleaninline{tempSDS
} is very similar to the
\cleaninline{measurementsSDS
} from the previous listings.
433 The only difference is that we store measurements as tuples instead of tailor-made records.
434 The
\cleaninline{latestTemp
} is a
\emph{lens
} on the
\cleaninline{tempSDS
}.
435 A lens is a new
\gls{SDS
} that is automatically mapped to another
\gls{SDS
}.
436 Updating one of the
\glspl{SDS
} that are coupled in this way automatically updates the other.
437 The function
\cleaninline{mapReadWrite
} is parameterized by the read and write functions, the option to handle asynchronous update conflicts (here
\cleaninline{?None
}) and the
\gls{SDS
} to be transformed (here
\cleaninline{tempSDS
}).
438 The result of reading is the head of the list, if it exists.
439 The type for writing
\cleaninline{latestTemp
} is a tuple with a new
\cleaninline{DateTime
} and temperature as
\cleaninline{Real
}.
443 caption=
{\gls{CRTS
}: a tierless temperature sensing
\gls{IOT
} system. Written in
\gls{CLEAN
}\slash\gls{ITASK
}, it targets a resource-rich sensor node.
},
444 label=
{lst_t4t:itaskTempFull
}]
445 tempSDS :: SimpleSDSLens
[(DateTime, Real)
]
446 tempSDS = sharedStore "temperatures"
[]
448 latestTemp :: SDSLens () (? (DateTime, Real)) (DateTime, Real)
449 latestTemp = mapReadWrite (listToMaybe,
\x xs-> ?Just
[x:xs
]) ?None tempSDS
451 devTask :: Task DateTime
452 devTask =
[+
\label{lst_t4t:itaskTempFull:sensorfro
}+
]
453 withDHT IIO_TempID
\dht ->
454 forever (
[+
\label{lst_t4t:itaskTempFull:forever
}+
]
455 temperature dht >>~
\temp ->
456 set temp (dateTimeStampedShare latestTemp) >-|
457 waitForTimer False interval)
[+
\label{lst_t4t:itaskTempFull:waitForTimer
}+
][+
\label{lst_t4t:itaskTempFull:sensorto
}+
]
460 mainTask
[+
\label{lst_t4t:itaskTempFull:main
}+
]
461 = asyncTask deviceInfo.domain deviceInfo.port devTask
[+
\label{lst_t4t:itaskTempFull:startdevtask
}+
]
462 -|| viewSharedInformation
[] [+
\label{lst_t4t:itaskTempFull:displaystart
}+
]
463 (remoteShare latestTemp deviceInfo)
[+
\label{lst_t4t:itaskTempFull:remoteShare
}+
]
464 <<@ Title "Latest temperature"
[+
\label{lst_t4t:itaskTempFull:displayend
}+
]
469 \begin{subfigure
}[t
]{.2\textwidth}
471 \fbox{\includegraphics[width=
.9\textwidth]{cwts
}}
474 \begin{subfigure
}[t
]{.8\textwidth}
476 \includegraphics[width=
\textwidth]{devTaskDiagram2
}
477 \caption{Deployment diagram.
}
479 \caption{Tierless
\gls{ITASK
} \gls{CRTS
} temperature sensing
\gls{IOT
} system.
}%
480 \label{fig_t4t:cwtsweb
}
483 \subsection{The
\texorpdfstring{\gls{MTASK
}}{mTask
} \texorpdfstring{\gls{EDSL
}}{eDSL
}}%
484 \label{sec_t4t:mtasks
}
486 In many
\gls{IOT
} systems the sensor nodes are resource constrained, e.g.\ inexpensive microprocessors. These are far cheaper, and consume far less power, than a single-board computer like a Raspberry Pi. Microprocessors also allow the programmer to easily control peripherals like sensors and actuators via the
\gls{IO
} pins of the processor.
488 Microprocessors have limited memory capacity, compute power and communication bandwidth, and hence typically no
\gls{OS
}.
489 These limitations make it impossible to run an
\gls{ITASK
} server:
490 there is no
\gls{OS
} to start the remote task, the code of the task is too big to fit in the available memory and the microprocessor processor is too slow to run it.
491 The
\gls{MTASK
} \gls{EDSL
} is designed to bridge this gap:
\gls{MTASK
} tasks can be communicated from the server to the sensor node, to execute within the limitations of a typical microprocessor, while providing programming abstractions that are consistent with
\gls{ITASK
}.
493 Like
\gls{ITASK
},
\gls{MTASK
} is task oriented, e.g.\ there are primitive tasks that produce intermediate values, a restricted set of task combinators to compose the tasks, and (recursive) functions to construct tasks.
494 \Gls{MTASK
} tasks communicate using task values or
\glspl{SDS
} that may be local or remote, and may be shared by some
\gls{ITASK
} tasks.
496 Apart from the
\gls{EDSL
}, the
\gls{MTASK
} system contains a featherlight domain-specific
\emph{operating system
} running on the microprocessor.
497 This
\gls{OS
} task scheduler receives the byte code generated from one or more
\gls{MTASK
} programs and interleaves the execution of those tasks. The
\gls{OS
} also manages
\gls{SDS
} updates and the passing of task results.
498 The
\gls{MTASK
} \gls{OS
} is stored in flash memory while the tasks are stored in
\gls{RAM
} to minimise wear on the flash memory. While sending byte code to a sensor node at runtime greatly increases the amount of communication, this can be mitigated as any tasks known at compile time can be preloaded on the microprocessor.
499 In contrast, compiled programs, like
\gls{C
}\slash\gls{CPP
}, are stored in flash memory and there can only ever be a few thousand programs uploaded during the lifetime of the microprocessor before exhausting the flash memory.
501 \subsection{Engineering tierless
\texorpdfstring{\gls{IOT
}}{IoT
} systems with
\texorpdfstring{\gls{MTASK
}}{mTask
}}%
502 \label{sec_t4t:mtaskIOT
}
504 A tierless
\gls{CLEAN
} \gls{IOT
} system with microprocessor sensor nodes integrates a set of
\gls{ITASK
} tasks that specify the application and presentation layers with a set of
\gls{MTASK
}s that specify the perception and network layers.
505 We illustrate with
\gls{CWTS
}: a simple room temperature sensor with a web display.
\gls{CWTS
} is equivalent to the
\gls{ITASK
} \gls{CRTS
} (
\cref{lst_t4t:itaskTempFull
}), except that the sensor node is a
\gls{WEMOS
} microprocessor.
507 \Cref{lst_t4t:mtaskTemp
} shows the complete program, and the key function is
\cleaninline{devTask
} with a top-level
\cleaninline{Main
} type (
\cref{lst_t4t:mtaskTemp:devTask
}). In
\gls{MTASK
} functions, shares, and devices can only be defined at this top level.
508 The program uses the same shares
\cleaninline{tempSDS
} and~
\cleaninline{latestTemp
} as
\gls{CRTS
}, and for completeness we repeat those definitions.
509 The body of
\cleaninline{devTask
} is the
\gls{MTASK
} slice of the program (
\crefrange{lst_t4t:mtaskTemp:DHT
}{lst_t4t:mtaskTemp:setSds
}).
510 With
\cleaninline{DHT
} we again create a temperature sensor object
\cleaninline{dht
}.
511 The
\gls{ITASK
} \gls{SDS
} \cleaninline{latestTemp
} is first transformed to a
\gls{SDS
} that accepts only temperature values,
512 the
\cleaninline{dateTimeStampedShare
} adds the data via a lens.
513 The
\cleaninline{mapRead
} adjusts the read type.
514 This new
\gls{SDS
} of type
\cleaninline{Real
} is lifted to the
\gls{MTASK
} program with
\cleaninline{liftsds
}.
515 %The \cleaninline{mapRead} ensures that every write to \cleaninline{localSds} is automatically time-stamped when it is written to \cleaninline{latestTemp}.
518 The
\cleaninline{mainTask
} is a simple
\gls{ITASK
} task that starts the
\cleaninline{devTask
} \gls{MTASK
} task on the device identified by
\cleaninline{deviceInfo
} (
\cref{lst_t4t:mtaskTemp:withdevice
}). At runtime the
\gls{MTASK
} slice is compiled to byte code, shipped to the indicated device, and launched. Thereafter,
\cleaninline{mainTask
} reads temperature values from the
\cleaninline{latestTemp
} \gls{SDS
} that is shared with the
\gls{MTASK
} device, and displays them on a web page (
\cref{fig_t4t:cwtsweb
}). The
\gls{SDS
}---shared with the device using
\cleaninline{liftsds
}---automatically communicates new temperature values from the microprocessor to the server.
520 While this simple application makes limited use of the
\gls{MTASK
} \gls{EDSL
}, it illustrates some powerful
\gls{MTASK
} program abstractions like basic tasks, task combinators, named recursive and parameterized tasks, and
\glspl{SDS
}.
521 Function composition (
\cref{lst_t4t:mtaskTemp:o
}) and currying (
\cref{lst_t4t:mtaskTemp:setSds
}) are inherited from the
\gls{CLEAN
} host language.
522 As
\gls{MTASK
} tasks are dynamically compiled, it is also possible to select and customise tasks as required at runtime.
523 For example, the interval used in the
\cleaninline{rpeatevery
} task (
\cref{lst_t4t:mtaskTemp:rpeatevery
}) could be a parameter to the
\cleaninline{devTask
} function.
525 \newcommand{\srcmark}[1]{\marginpar[\footnotesize\emph{#1}]{\footnotesize\emph{#1}}}
529 \Gls{CWTS
}: a tierless temperature sensing
\gls{IOT
} system. Written in
\gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
}, it targets a resource-constrained sensor node. Each line is annotated with the functionality as analysed in
\cref{sec_t4t:codesize
}.
},
530 label=
{lst_t4t:mtaskTemp
},
534 import mTask.Language, mTask.Interpret, mTask.Interpret.Device.TCP
535 import iTasks, iTasks.Extensions.DateTime
537 deviceInfo =
{TCPSettings|host="...", port=
8123, pingTimeout= ?None
} [+
\label{lst_t4t:mtaskTemp:co0
}\srcmark{CO
}+
]
538 interval = lit
10[+
\label{lst_t4t:mtaskTemp:sn0
}\srcmark{SN
}+
]
539 DHT_pin = DigitalPin D4
[+
\label{lst_t4t:mtaskTemp:si0
}\srcmark{SI
}+
]
541 Start world = doTasks mainTask world
[+
\label{lst_t4t:mtaskTemp:wi0
}\srcmark{WI
}+
]
543 tempSDS :: SimpleSDSLens
[(DateTime, Real)
]
544 tempSDS = sharedStore "temperatures"
[][+
\label{lst_t4t:mtaskTemp:di0
}\srcmark{DI
}+
]
546 latestTemp :: SDSLens () (? (DateTime, Real)) (DateTime, Real)
547 latestTemp = mapReadWrite (listToMaybe,
\x xs-> ?Just
[x:xs
]) ?None tempSDS
[+
\label{lst_t4t:mtaskTemp:di1
}\srcmark{DI
}+
]
549 devTask :: Main (MTask v Real) | mtask, dht, liftsds v
[+
\label{lst_t4t:mtaskTemp:devTask
}+
]
551 DHT (DHT_DHT DHT_pin DHT11)
\dht ->
[+
\label{lst_t4t:mtaskTemp:DHT
}+
][+
\label{lst_t4t:mtaskTemp:si1
}\srcmark{SI
}+
]
552 liftsds
\localSds =
[+
\label{lst_t4t:mtaskTemp:liftsds
}+
][+
\label{lst_t4t:mtaskTemp:co1
}\srcmark{CO
}+
]
553 mapRead (snd o fromJust) (dateTimeStampedShare latestTemp)
[+
\label{lst_t4t:mtaskTemp:o
}+
][+
\label{lst_t4t:mtaskTemp:sn1
}\srcmark{SN
}+
]
554 In
{main = rpeatEvery (ExactSec interval)
[+
\label{lst_t4t:mtaskTemp:rpeatevery
}+
][+
\label{lst_t4t:mtaskTemp:sn2
}\srcmark{SN
}+
]
555 (temperature dht >>~.
[+
\label{lst_t4t:mtaskTemp:temperature
}+
][+
\label{lst_t4t:mtaskTemp:si2
}\srcmark{SI
}+
]
556 setSds localSds)
}[+
\label{lst_t4t:mtaskTemp:setSds
}+
][+
\label{lst_t4t:mtaskTemp:sn3
}\srcmark{SN
}+
]
558 mainTask :: Task Real
560 = withDevice deviceInfo
\dev -> liftmTask
} devTask dev
[+
\label{lst_t4t:mtaskTemp:liftmtask
}+
][+
\label{lst_t4t:mtaskTemp:withdevice
}+
][+
\label{lst_t4t:mtaskTemp:co2
}\srcmark{CO
}+
]
561 -|| viewSharedInformation
[] latestTemp
[+
\label{lst_t4t:mtaskTemp:wi1
}\srcmark{WI
}+
]
562 <<@ Title "Latest temperature"
[+
\label{lst_t4t:mtaskTemp:wi2
}\srcmark{WI
}+
]
568 \begin{subfigure
}[t
]{.2\textwidth}
570 \fbox{\includegraphics[width=
.9\textwidth]{cwts
}}
573 \begin{subfigure
}[t
]{.8\textwidth}
575 \includegraphics[width=
.95\textwidth]{cwtsDiagram2
}
576 \caption{Deployment diagram.
}
578 \caption{Tierless
\gls{ITASK
}\slash\gls{MTASK
} \gls{CWTS
} temperature sensing
\gls{IOT
} system.
}%
579 \label{fig_t4t:cwtsDiagram
}
582 \section{\texorpdfstring{\gls{UOG
}}{UoG
} smart campus case study
}%
584 The basis for our comparison between tiered and tierless technologies are four
\gls{IOT
} systems that all conform to the
\gls{UOG
} smart campus specifications (
\cref{sec_t4t:OperationalComparison
}). There is a small (
12 room) deployment of the conventional
\gls{PYTHON
}-based
\gls{PRS
} stack that uses Raspberry Pi supersensors, and its direct comparator is the tierless
\gls{CRS
} implementation: also deployed on Raspberry Pis.
585 To represent the more common microprocessor sensor nodes we select ESP8266X powered
\gls{WEMOS
} D1 Mini microcontrollers. To evaluate tierless technologies on microcontrollers we compare the conventional
\gls{PYTHON
}\slash\gls{MICROPYTHON
} \gls{PWS
} stack with the tierless
\gls{CWS
} implementation.
587 %The four systems under comparison are different in architecture ---tiered or tierless--- and type of sensor node hardware ---regular or embedded--- but they share many properties as well.
589 %The embedded sensor nodes are all implemented on the ESP8266X powered \gls{WEMOS} D1 Mini microprocessor.
590 A similar range of commodity sensors is connected to both the Raspberry Pi and
\gls{WEMOS
} sensor nodes using various low-level communication protocols such as
\gls{GPIO
},
\gls{I2C
},
\gls{SPI
} and
\gls{ONEWIRE
}. The sensors are as follows: Temperature \& Humidity: LOLIN SHT30; Light: LOLIN BH1750; Motion: LOLIN
\gls{PIR
}; Sound: SparkFun SEN-
12642;
\gls{ECO2
}: SparkFun CCS811.
592 \Cref{fig_t4t:wemos_prss
} shows both a prototype
\gls{WEMOS
}-based sensor node and sensors and a Raspberry Pi supersensor. Three different development teams developed the four implementations:
\gls{CWS
} and
\gls{CRS
} were engineered by a single developer.
596 \begin{subfigure
}[t
]{.49\textwidth}
598 \includegraphics[width=
.9\textwidth]{wemos
}
599 \caption{A
\gls{WEMOS
} used in
\gls{PWS
} and
\gls{CWS
}}.
%
601 \begin{subfigure
}[t
]{.49\textwidth}
603 \includegraphics[width=
.9\textwidth]{prss
}
604 \caption{A Raspberry Pi used in
\gls{PRS
} and
\gls{CRS
}.
}%
606 \caption{Exposed views of sensor nodes.
}%%
607 \label{fig_t4t:wemos_prss
}
610 \subsection{Tiered implementations
}
611 The tiered
\gls{PRS
} and
\gls{PWS
} share the same server code executing on a commodity PC (
\cref{fig_t4t:iot_arch
}). The
\gls{PYTHON
} server stores incoming sensor data in two database systems, i.e.\ Redis (in-memory data) and MongoDB (persistent data). The real-time sensor data is made available via a streaming websockets server, which connects with Redis.
612 There is also an HTTP REST
\gls{API
} for polling current and historical sensor data, which hooks into
{MongoDB
}.
613 Communication between a sensor node and the server is always initiated by the node.
615 \Gls{PRS
}'s sensor nodes are
%powered by the
616 relatively powerful Raspberry Pi
3 Model Bs. There is a simple object-oriented
\gls{PYTHON
} collector for configuring the sensors and reading their values. The collector daemon service marshals the sensor data and transmits using
\gls{MQTT
} to the central monitoring server at a preset frequency.
617 The collector caches sensor data locally when the server is unreachable.
619 In contrast to
\gls{PRS
},
\gls{PWS
}'s sensor nodes are microprocessors running
\gls{MICROPYTHON
}, a dialect of
\gls{PYTHON
} specifically designed to run on small, low powered embedded devices~
\citep{kodali2016low
}.
620 To enable a fair comparison between the software stacks we are careful to use the same object-oriented software architecture, e.g.\ using the same classes in
\gls{PWS
} and
\gls{PRS
}.
622 \Gls{PYTHON
} and
\gls{MICROPYTHON
} are appropriate tiered comparison languages. Tiered
\gls{IOT
} systems are implemented in a whole range of programming languages, with
\gls{PYTHON
},
\gls{MICROPYTHON
},
\gls{C
} and
\gls{CPP
} being popular for some tiers in many implementations.
\gls{C
}\slash\gls{CPP
} implementations would probably result in more verbose programs and even less type safety.
623 The other reasons for selecting
\gls{PYTHON
} and
\gls{MICROPYTHON
} are pragmatic.
\gls{PRS
} had been constructed in
\gls{PYTHON
}, deployed, and was being used as an
\gls{IOT
} experimental platform.
624 Selecting
\gls{MICROPYTHON
} for the resource-constrained
\gls{PWS
} sensor nodes facilitates comparison by minimising changes to the resource-rich and resource-constrained codebases.
625 We anticipate that the codebase for a tiered smart campus implementation in another imperative/object-oriented language, like
\gls{CPP
}, would be broadly similar to the
\gls{PRS
} and
\gls{PWS
} codebases.
627 \subsection{Tierless implementations
}
629 The tierless
\gls{CRS
} and
\gls{CWS
} servers share the same
\gls{ITASK
} server code (
\cref{fig_t4t:iot_arch
}), and can be compiled for many standard platforms.
631 SQLite as a database backend.
632 Communication between a sensor node and the server is initiated by the server.
634 \Gls{CRS
}'s sensor nodes are Raspberry Pi
4s, and execute
\gls{CLEAN
}\slash\gls{ITASK
} programs.
635 Communication from the sensor node to the server is implicit and happens via
\glspl{SDS
} over
\gls{TCP
} using platform independent execution graph serialisation~
\citep{oortgiese_distributed_2017
}.
637 \Gls{CWS
}'s sensor nodes are
\gls{WEMOS
} microprocessors running
\gls{MTASK
} tasks. Communication and serialisation is, by design, very similar to
\gls{ITASK
}, i.e.\ via
\glspl{SDS
} over either a serial port connection, raw
\gls{TCP
}, or
\gls{MQTT
} over
\gls{TCP
}.
641 \begin{subfigure
}[t
]{.49\textwidth}
643 \fbox{\includegraphics[width=
.75\textwidth]{cwss_web
}}
644 \caption{\Gls{CWS
} and
\gls{CRS
}.
}
646 \begin{subfigure
}[t
]{.49\textwidth}
648 \fbox{\includegraphics[width=
.75\textwidth, height=
.2\textheight, keepaspectratio
]{sensordata.png
}}
649 \caption{\Gls{PWS
} and
\gls{PRS
}.
}
651 \caption{Web interfaces for the smart campus application.
}%
652 \label{fig_t4t:webinterfaces
}
655 \subsection{Operational equivalence
}%
656 \label{sec_t4t:OperationalComparison
}
659 To ensure that the comparison reported in the following sections is based on
\gls{IOT
} stacks with equivalent functionality, we demonstrate that
\gls{PWS
},
\gls{CWS
} and
\gls{CRS
}, like
\gls{PRS
}, meet the functional requirements for the
\gls{UOG
} smart campus sensor system. We also compare the sensor node power consumption and memory footprint.
661 \subsubsection{Functional requirements
}%
662 \label{sec_t4t:Validation
}
664 The main goal of the
\gls{UOG
} smart campus project is to provide a testbed for sensor nodes and potentially other devices to act as a data collection and computation platform for the
\gls{UOG
} smart campus. The high-level functional requirements, as specified by the
\gls{UOG
} smart campus project board, are as follows. The system should:
665 %\mlcomment{can be inline as well}
668 \item be able to measure temperature and humidity as well as light intensity,
670 \item scale to no more than
10 sensors per sensor node and investigate further sensor options like measuring sound levels,
672 \item have access to communication channels like WiFi, Bluetooth and even wired networks.
674 \item have a centralised database server,
676 \item have a client interface to access information stored in the database,
678 \item provide some means of security and authentication,
679 %\item have some means of providing security and authentication.
681 \item have some means of managing and monitoring sensor nodes like updating software or detecting new sensor nodes.
684 All four smart campus implementations meet these high-level requirements.
686 \subsubsection{Functional equivalence
}
688 Observation of the four implementations shows that they operate as expected, e.g.\ detecting light or motion. To illustrate
\cref{fig_t4t:webinterfaces
} shows the web interface for the implementations where
\gls{CWS
} and
\gls{CRS
} are deployed in a different room from
\gls{PWS
} and
\gls{PRS
}.
690 All four implementations use an identical set of inexpensive sensors, so we expect the accuracy of the data collected is within tolerance levels. This is validated by comparing
\gls{PRS
} and
\gls{PWS
} sensor nodes deployed in the same room for some minutes. The measurements show only small variances, e.g.\ temperatures recorded differ by less than
\qty{0.4}{\celcius}, and light by less than
\qty{1}{lux
}. For this room monitoring application precise timings are not critical, and we don't compare the timing behaviours of the implementations.
691 %\adriancomment{Maybe include a reference for accepted standards of variation between the same type of sensors?}
692 % Phil: lets see what the reviewers say
695 \subsubsection{Memory and power consumption
}%
696 %\subsubsection{Memory Consumption}%
697 \label{sec_t4t:MemPower
}
699 \paragraph{Memory
} By design sensor nodes are devices with limited computational capacity, and memory is a key restriction. Even supersensors often have less than a
\unit{\gibi\byte} of memory, and microprocessors often have just tens of
\unit{\kibi\byte{}s
}.
700 %In a tiered implementation the memory residency of the sensor node code can be minimised by carefully crafting it in a language that minimises memory residency. However, ...
701 As the tierless languages synthesize the code to be executed on the sensor nodes, we need to confirm that the generated code is sufficiently memory efficient.
705 \caption{\Gls{UOG
} smart campus sensor nodes: maximum memory residency (in bytes).
}%
707 \begin{tabular
}{rrrr
}
709 \multicolumn{1}{c
}{\gls{PWS
}} &
\multicolumn{1}{c
}{\gls{PRS
}} &
\multicolumn{1}{c
}{\gls{CWS
}} &
\multicolumn{1}{c
}{\gls{CRS
}}\\
711 \num{20270} &
\num{3557806} &
\num{880} &
\num{2726680}\\
716 \Cref{tbl_t4t:mem
} shows the maximum memory residency after garbage collection of the sensor node for all four smart campus implementations. The smart campus sensor node programs executing on the
\gls{WEMOS
} microprocessors have low maximum residencies:
\qty{20270}{\byte} for
\gls{PWS
} and
\qty{880}{\byte} for
\gls{CWS
}. In
\gls{CWS
} the
\gls{MTASK
} system generates very high level
\gls{TOP
} byte code that is interpreted by the
\gls{MTASK
} virtual machine and uses a small and predictable amount of heap memory.
717 In
\gls{PWS
}, the hand-written
\gls{MICROPYTHON
} is compiled to byte code for execution on the virtual machine. Low residency is achieved with a fixed size heap and efficient memory management. For example both
\gls{MICROPYTHON
} and
\gls{MTASK
} use fixed size allocation units and mark\&sweep garbage collection to minimise memory usage at the cost of some execution time~
\citep{plamauer2017evaluation
}.
719 The smart campus sensor node programs executing on the Raspberry Pis have far higher maximum residencies than those executing on the microprocessors:
\qty{3.5}{\mebi\byte} for
\gls{PRS
} and
\qty{2.7}{\mebi\byte} for
\gls{CRS
}. In
\gls{CRS
} the sensor node code is a set of
\gls{ITASK
} executing on a full-fledged
\gls{ITASK
} server running in distributed child mode and this consumes far more memory.
720 %The memory used is actually very similar to the memory usage of the server with a single client connected.
721 In
\gls{PRS
} the sensor node program is written in
\gls{PYTHON
}, a language far less focused on minimising memory usage than
\gls{MICROPYTHON
}. For example an object like a string is larger in
\gls{PYTHON
} than in
\gls{MICROPYTHON
} and consequently does not support all features such as
\emph{f-strings
}.
722 Furthermore, not all advanced
\gls{PYTHON
} feature regarding classes are available in
\gls{MICROPYTHON
}, i.e.\ only a subset of the
\gls{PYTHON
} specification is supported~
\citep{diffmicro
}.
%\mlcomment{reference \url{https://docs.micropython.org/en/latest/genrst/index.html} ? It contains an overview of supported features}
724 In summary the sensor node code generated by both tierless languages,
\gls{ITASK
} and
\gls{MTASK
}, is sufficiently memory efficient for the target sensor node hardware. Indeed, the maximum residencies of the
\gls{CLEAN
} sensor node code is less than the corresponding hand-written (Micro)
\gls{PYTHON
} code. Of course in a tiered stack the hand-written code can be more easily optimised to minimise residency, and this could even entail using a memory efficienthat thet language like
\gls{C
}\slash\gls{CPP
}. However, such optimisation requires additional developer effort, and a new language would introduce additional semantic friction.
726 \paragraph{Power
} Sensor nodes and sensors are designed to have low power demands, and this is particularly important if they are operating on batteries. The grey literature consensus is that with all sensors enabled a sensor node should typically have sub-
\qty{1}{\watt} peak power draw.
727 %\pwtcomment{Mart can you provide some evidence? A citation?}.
728 %\mlcomment{There only seems to be anecdotal evidence of this. See: \url{https://www.element14.com/community/people/neilk/blog/2019/02/14/investigating-the-power-consumption-of-a-\gls{WEMOS}-d1-mini-esp8266}}
729 %\pkcomment{We can state that our own measurements are consistent the experience of others.}
730 The
\gls{WEMOS
} sensor nodes used in
\gls{CWS
} and
\gls{PWS
} have the low power consumption of a typical embedded device: with all sensors enabled, they consume around
\qty{0.2}{\watt}.
731 The Raspberry Pi supersensor node used in
\gls{CRS
} and
\gls{PRS
} use more power as they have a general purpose ARM processor and run mainstream Linux. With all sensors enabled, they consume
\qtyrange{1}{2}{\watt}, depending on ambient load. So a microprocessor sensor node consumes an order of magnitude less power than a supersensor node.
734 \section[Is tierless
\texorpdfstring{\gls{IOT
}}{IoT
} programming easier than tiered?
]{\hspace{-
9pt
}Is tierless
\texorpdfstring{\gls{IOT
}}{IoT
} programming easier than tiered?
}%
735 \label{sec_t4t:ProgrammingComparison
}
738 This section investigates whether tierless languages make
\gls{IOT
} programming
\emph{easier
} by comparing the
\gls{UOG
} smart campus implementations. The
\gls{CRS
} and
\gls{CWS
} implementations allow us to evaluate tierless languages for
739 resource-rich and for resource-constrained sensor nodes respectively. The
\gls{PRS
} and
\gls{PWS
} allow a like-for-like comparison with tiered
\gls{PYTHON
} implementations.
742 %\subsection{Temperature Sensor Illustration}
744 \subsection{Comparing tiered and tierless codebases
}%
745 \label{sec_t4t:codesize
}
746 %A comparison of the Temperature sensor in \gls{PYTHON} Micropyton, Itask \& \gls{MTASK}.
748 \paragraph{Code size
} is widely recognised as an approximate measure of the development and maintenance effort required for a software system~
\citep{rosenberg1997some
}.
\gls{SLOC
} is a common code size metric, and is especially useful for multi-paradigm systems like
\gls{IOT
} systems. It is based on the simple principle that the more
\gls{SLOC
}, the more developer effort and the increased likelihood of bugs~
\citep{rosenberg1997some
}. It is a simple measure, not dependent on some formula, and can be automatically computed~
\citep{sheetz2009understanding
}.
750 Of course
\gls{SLOC
} must be used carefully as it is easily influenced by programming style, language paradigm, and counting method~
\citep{alpernaswonderful
}. Here we are counting code to compare development effort, use the same idiomatic programming style in each component, and only count lines of code, omitting comments and blank lines.
752 \Cref{table_t4t:multi
} enumerates the
\gls{SLOC
} required to implement the
\gls{UOG
} smart campus functionalities in
\gls{PWS
},
\gls{PRS
},
\gls{CWS
} and
\gls{CRS
}. Both
\gls{PYTHON
} and
\gls{CLEAN
} implementations use the same server and communication code for Raspberry Pi and for
\gls{WEMOS
} sensor nodes (rows
5--
7 of the table).
753 The Sensor Interface (SI) refers to code facilitating the communication between the peripherals and the sensor node software.
% formerly hardware interface
754 Sensor Node (SN) code contains all other code on the sensor node that does not belong to any another category, such as control flow.
% formerly device output
755 %Server communication denotes code that provides the high level communication between the sensor node and the server.
756 Manage Nodes (MN) is code that coordinates sensor nodes, e.g.\ to add a new sensor node to the system.
% formerly device management
757 Web Interface (WI) code provides the web interface from the server, i.e.\ the presentation layer.
758 Database Interface (DI) code communicates between the server and the database
\strut(s).
759 Communication (CO) code provides communication between the server and the sensor nodes, and executes on both sensor node and server, i.e.\ the network layer.
761 The most striking information in
\cref{table_t4t:multi
} is that
\emph{the tierless implementations require far less code than the tiered implementations
}. For example
166/
562 \gls{SLOC
} for
\gls{CWS
}\slash\gls{PWS
}, or
70\% fewer
\gls{SLOC
}. We attribute the code reduction to three factors: reduced interoperation, automatic communication, and high level programming abstractions. We analyse each of these aspects in the following subsections.
764 \centering % used for centering table
765 \caption{Comparing tiered and tierless smart campus code sizes:
\gls{SLOC
} and number of source files.
\gls{PWS
} and
\gls{CWS
} execute on resource-constrained sensor nodes, while
\gls{PRS
} and
\gls{CRS
} execute on resource-rich sensor nodes.
}%
766 \label{table_t4t:multi
}
767 \begin{tabular
}{l l c c c c
} % centered columns (4 columns)
769 & &
\multicolumn{2}{c
}{Tiered
\gls{PYTHON
}} &
\multicolumn{2}{c
}{Tierless
\gls{CLEAN
}} \\
770 Code location & Functionality &
\gls{PWS
} &
\gls{PRS
} &
\gls{CWS
} &
\gls{CRS
} \\
772 Sensor Node & Sensor Interface &
52 &
57 &
11 &
11\\
773 & Sensor Node &
178 &
183 &
9 &
4\\
775 Server & Manage Nodes &
\multicolumn{2}{c
}{76} &
35 &
30\\
776 & Web Interface &
\multicolumn{2}{c
}{56} &
\multicolumn{2}{c
}{28}\\
777 & Database Interface &
\multicolumn{2}{c
}{106} &
\multicolumn{2}{c
}{78}\\
779 Communication & Communication &
94 &
98 &
5 &
4\\
781 Total
\gls{SLOC
} & &
562 &
576 &
166 &
155 \\
782 \textnumero{} Files & &
35 &
38 &
3 &
3 \\
787 \paragraph{Code proportions.
} Comparing the percentages of code required to implement the smart campus functionalities normalises the data and avoids some issues when comparing
\gls{SLOC
} for different programming languages, and especially for languages with different paradigms like object-oriented
\gls{PYTHON
} and functional
\gls{CLEAN
}.
\Cref{fig_t4t:multipercentage
} shows the percentage of the total
\gls{SLOC
} required to implement the smart campus functionalities in each of the four implementations, and is computed from the data in
\cref{table_t4t:multi
}. It shows that there are significant differences between the percentage of code for each functionality between the tiered and tierless implementations. For example
17\% of the tiered implementations specifies communication, whereas this requires only
3\% of the tierless implementations, i.e.\
6$
\times$ less. We explore the reasons for this in
\cref{sec_t4t:Communication
}. The other major difference is the massive percentage of Database Interface code in the tierless implementations: at least
47\%. The smart campus specification required a standard DBMS, and the
\gls{CLEAN
}\slash\gls{ITASK
} SQL interface occupies some
78 \gls{SLOC
}. While this is a little less than the
106 \gls{SLOC
} used in
\gls{PYTHON
} (
\cref{table_t4t:multi
}), it is a far higher percentage of systems with total codebases of only around
160 \gls{SLOC
}. Idiomatic
\gls{CLEAN
}/
\gls{ITASK
} would use high level abstractions to store persistent data in an
\gls{SDS
}, requiring just a few
\gls{SLOC
}.
788 The total size of
\gls{CWS
} and
\gls{CRS
} would be reduced by a factor of two and the percentage of Database Interface code would be even less than in the tiered
\gls{PYTHON
} implementations.
793 \includegraphics[width=
.7\linewidth]{bar_chart.pdf
}
794 \caption{Comparing the percentage of code required to implement each functionality in tiered/tierless and resource-rich/constrained smart campus implementations.
}%
795 \label{fig_t4t:multipercentage
}
798 \subsection{Comparing codebases for resource-rich
\slash{}constrained sensor nodes
}%
799 \label{sec_t4t:resourcerich
}
801 Before exploring the reasons for the smaller tierless codebase we compare the implementations for resource-rich and resource-constrained sensor nodes, again using
\gls{SLOC
} and code proportions.
\Cref{table_t4t:multi
} shows that the two tiered implementations are very similar in size: with
\gls{PWS
} for microprocessors requiring
562 \gls{SLOC
} and
\gls{PRS
} for supersensors requiring
576 \gls{SLOC
}.
802 The two tierless implementations are also similar in size:
\gls{CWS
} requiring
166 and
\gls{CRS
} 155 \gls{SLOC
}.
804 There are several main reasons for the similarity. One is that the server-side code, i.e.\ for the presentation and application layers, is identical for both resource rich/constrained implementations. The identical server code accounts for approximately
40\% of the
\gls{PWS
} and
\gls{PRS
} codebases, and approximately
85\% of the
\gls{CWS
} and
\gls{CRS
} codebases (
\cref{fig_t4t:multipercentage
}). For the perception and network layers on the sensor nodes, the
\gls{PYTHON
} and
\gls{MICROPYTHON
} implementations have the same structure, e.g.\ a class for each type of sensor, and use analogous libraries. Indeed, approaches like CircuitPython~
\citep{CircuitPython
} allow the same code to execute on both resource-rich and resource-constrained sensor nodes.
807 Like
\gls{PYTHON
} and
\gls{MICROPYTHON
},
\gls{ITASK
} and
\gls{MTASK
} are designed to be similar, as elaborated in
\cref{sec_t4t:ComparingTierless
}. The similarity is apparent when comparing the
\gls{ITASK
} \gls{CRTS
} and
\gls{ITASK
}\slash\gls{MTASK
} \gls{CWTS
} room temperature systems in
\cref{lst_t4t:itaskTempFull,lst_t4t:mtaskTemp
}. That is, both implementations use similar
\glspl{SDS
} and lenses; they have similar
\cleaninline{devTask
}s that execute on the sensor node, and the server-side
\cleaninline{mainTask
}s are almost identical: they deploy the remote
\cleaninline{devTask
} before generating the web page to
report the readings.
809 In both
\gls{PYTHON
} and
\gls{CLEAN
} the resource-constrained implementations are less than
7\% larger than the resource-rich implementations. This suggests that
\emph{the development and maintenance effort of simple
\gls{IOT
} systems for resource-constrained and for resource-rich sensor nodes is similar in tierless technologies,
} just as it is in tiered technologies.
810 A caveat is that the smart campus system is relatively simple, and developing more complex perception and network code on bare metal may prove more challenging. That is, the lack of
\gls{OS
} support, and the restricted languages and libraries, may have greater impact. We return to this issue in
\cref{sec_t4t:ComparingTierless
}.
813 \subsection{Reduced interoperation
}%
814 \label{sec_t4t:interoperation
}
818 \caption{Smart campus implementation languages comparison.
}%
819 \label{table_t4t:languages
}
820 \begin{tabular
}{lllllll
}
822 & &
\multicolumn{4}{c
}{Languages
}\\
824 Code Location & Functionality &
\gls{PWS
} &
\gls{PRS
} &
\gls{CWS
} &
\gls{CRS
}\\
826 Sensor Node & Sensor Int. &
\gls{MICROPYTHON
} &
\gls{PYTHON
} &
\gls{MTASK
} &
\gls{ITASK
}\\
827 & Sensor Node &
\gls{MICROPYTHON
} &
\gls{PYTHON
} &
\gls{MTASK
} &
\gls{ITASK
}\\
829 Server & Manage Nodes &
\multicolumn{2}{c
}{\gls{PYTHON
},
\gls{JSON
}} &
\multicolumn{2}{c
}{\gls{ITASK
}}\\
830 & Web Int. &
\multicolumn{2}{c
}{HTML, PHP
} &
\multicolumn{2}{c
}{\gls{ITASK
}}\\
831 & Database Int. &
\multicolumn{2}{c
}{\gls{PYTHON
},
\gls{JSON
},Redis
} &
\multicolumn{2}{c
}{\gls{ITASK
}}\\
833 Communication & Communication &
\gls{MICROPYTHON
} &
\gls{PYTHON
} &
\gls{ITASK
},
\gls{MTASK
} &
\gls{ITASK
}\\
835 & Total &
7 &
6 &
2 &
1\\
843 \caption{Smart campus paradigm comparison.
}%
844 \label{table_t4t:paradigms
}
845 \begin{tabular
}{llll
}
847 & &
\multicolumn{2}{c
}{Paradigms
}\\
849 Code Location & Functionality &
\gls{PYTHON
} &
\gls{CLEAN
}\\
851 Sensor Node & Sensor Int. & imperative & declarative\\
852 & Sensor Node & imperative & declarative\\
854 Server & Manage Nodes & imperative & declarative\\
855 & Web Int. & both & declarative\\
856 & Database Int. & both & declarative\\
858 Communication & Communication & imperative & declarative\\
865 The vast majority of
\gls{IOT
} systems are implemented using a number of different programming languages and paradigms, and these must be effectively used and interoperated. A major reason that the tierless
\gls{IOT
} implementations are simpler and shorter than the tiered implementations is that they use far fewer programming languages and paradigms. Here we use language to distinguish
\glspl{EDSL
} from their host language: so
\gls{ITASK
} and
\gls{MTASK
} are considered distinct from
\gls{CLEAN
}; and to distinguish dialects: so
\gls{MICROPYTHON
} is considered distinct from
\gls{PYTHON
}.
867 The tierless implementations use just two conceptually-similar
\glspl{DSL
} embedded in the same host language, and a single paradigm (
\cref{table_t4t:languages,table_t4t:paradigms
}). In contrast, the tiers in
\gls{PRS
} and
\gls{PWS
} use six or more very different languages, and both imperative and declarative paradigms. Multiple languages are commonly used in other typical software systems like web stacks, e.g.\ a recent survey of open source projects reveals that on average at least five different languages are used~
\citep{mayer2015empirical
}. Interoperating components in multiple languages and paradigms raises a plethora of issues.
869 Interoperation
\emph{increases the cognitive load on the developer
} who must simultaneously think in multiple languages and paradigms. This is commonly known as semantic friction or impedance mismatch~
\citep{ireland2009classification
}. A simple illustration of this is that the tiered
\gls{PRS
} source code comprises some
38 source and configuration files, whereas the tierless
\gls{CRS
} requires just
3 files (
\cref{table_t4t:multi
}). The source could be structured as a single file, but to separate concerns is structured into three modules, one each for
\glspl{SDS
}, types, and control logic~
\citep{wang_maintaining_2018
}.
871 The developer must
\emph{correctly interoperate the components
}, e.g.\ adhere to the
\gls{API
} or communication protocols between components. The interoperation often entails additional programming tasks like marshalling or demarshalling data between components. For example, in the tiered
\gls{PRS
} and
\gls{PWS
} architectures,
\gls{JSON
} is used to serialise and deserialise data strings from the
\gls{PYTHON
} collector component before storing the data in the Redis database (
\cref{lst_t4t:json
}).
872 %e.g.\ to marshall and demarshall data between components.
874 %\mlcomment{A listing must have a caption for it to be labeled and referenced}
875 \begin{lstPython
}[caption=
{\Gls{JSON
} Data marshalling in
\gls{PRS
} and
\gls{PWS
}: sensor node above, server below.
},label=
{lst_t4t:json
}]
877 channel = 'sensor_status.
%s.%s' % (hostname,
878 sensor_types.sensor_type_name(s.sensor_type))
879 self.r.publish(channel, s.SerializeToString())
883 for message in p.listen():
884 if message
['type'
] not in
['message', 'pmessage'
]:
888 status = collector_pb2.SensorStatus.FromString(message
['data'
])
891 To ensure correctness the developer
\emph{must maintain type safety
} across a range of very different languages and diverse type systems, and we explore this further in
\cref{sec_t4t:typesafety
}. The developer must also deal with the
\emph{potentially diverse failure modes
}, not only of each component, but also of their interoperation, e.g.\ if a value of an unexpected type is passed through an
\gls{API
}. We explore this further in
\cref{sec_t4t:NetworkManagement
}.
893 \subsection{Automatic communication
}%
894 \label{sec_t4t:Communication
}
896 In conventional tiered
\gls{IOT
} implementations the developer must write and maintain code to communicate between tiers. For example
\gls{PRS
} and
\gls{PWS
} create, send and read
\gls{MQTT
}~
\citep{light2017mosquitto
} messages
897 between the perception and application layers.
\Cref{table_t4t:multi
} shows that communication between these layers require some
94 \gls{SLOC
} in
\gls{PWS
} and
98 in
\gls{PRS
}, accounting for
17\% of the codebase (bottom bars in
\cref{fig_t4t:multipercentage
}). To illustrate,
\cref{lst_t4t:mwssmqtt
} shows part of the code to communicate sensor readings from the
\gls{PWS
} sensor node to the Redis store on the server.
899 Not only must the tiered developer write additional code, but
\gls{IOT
} communication code is often intricate. In such a distributed system the sender and receiver must be correctly configured, correctly follow the communication protocol through all execution states, and deal with potential failures. For example line
3 of
\cref{lst_t4t:mwssmqtt
}:
\pythoninline{redis host = config.get('Redis', 'Host')
} will fail if either the host or IP are incorrect.
901 \begin{lstPython
}[caption=
{Tiered communication example:
\gls{MQTT
} transmission of sensor values in
\gls{PWS
}.
},label=
{lst_t4t:mwssmqtt
}]
904 redis_host = config.get('Redis', 'Host')
905 redis_port = config.getint('Redis', 'Port')
906 r = redis.StrictRedis(host=redis_host, port=redis_port)
908 p.psubscribe("sensor_status.*")
909 for message in p.listen():
910 if message
['type'
] not in
['message', 'pmessage'
]:
911 print "Ignoring message
%s" % message
915 In contrast, the tierless
\gls{CWS
} and
\gls{CRS
} communication is not only highly automated, but also automatically correct because matching sender and receiver code is generated by the compiler.
\Cref{table_t4t:multi
} shows that communication is specified in just
5 \gls{SLOC
} in
\gls{CWS
} and
4 in
\gls{CRS
}, or just
3\% of the codebase (bottom bars in
\cref{fig_t4t:multipercentage
}).
918 \Cref{lst_t4t:mtaskTemp
} illustrates communication in a tierless
\gls{IOT
} language. That is, the
\gls{CWTS
} temperature sensor requires just three lines of communication code, and uses just three communication functions. The
919 \cleaninline{withDevice
} function on
\cref{lst_t4t:mtaskTemp:withdevice
} integrates a sensor node with the server, allowing tasks to be sent to it. The
920 \cleaninline{liftmTask
} on
\cref{lst_t4t:mtaskTemp:liftmtask
} integrates an
\gls{MTASK
} in the
\gls{ITASK
} runtime by compiling it and sending it for interpretation to the sensor node.
921 The
\cleaninline{liftsds
} on
\cref{lst_t4t:mtaskTemp:liftsds
} integrates
\glspl{SDS
} from
\gls{ITASK
} into
\gls{MTASK
}, allowing
\gls{MTASK
} tasks to interact with data from the
\gls{ITASK
} server.
922 The exchange of data, user interface, and communication are all automatically generated.
924 \subsection{High level abstractions
}%
925 \label{sec_t4t:abstractions
}
927 Another reason that the tierless
\gls{CLEAN
} implementations are concise is because they use powerful higher order
\gls{IOT
} programming abstractions.
928 For comprehensibility the simple temperature sensor from
\cref{sec_t4t:mtasks
} (
\cref{lst_t4t:mtaskTemp
}) is used to compare the expressive power of
\gls{CLEAN
} and
\gls{PYTHON
}-based
\gls{IOT
} programming abstractions.
929 There are implementations for all four configurations:
\gls{PRTS
} (
\gls{PYTHON
} Raspberry Pi Temperature Sensor)
\footnotemark,
\gls{PWTS
}\footnotemark[\value{footnote
}]\todo{the dataset will be uploaded, the DOI is reserved.
}
930 \footnotetext{Lubbers, M.; Koopman, P.; Ramsingh, A.; Singer, J.; Trinder, P. (
2021): Source code, line counts and memory stats for PRS, PWS, PRT and PWT.\ Zenodo.\
\href{https://doi.org/
10.5281/zenodo
.5081386}{10.5281/zenodo
.5081386}.
},
\gls{CRTS
}\footnotemark{} and
\gls{CWTS
}\footnotemark[\value{footnote
}] \todo{the dataset will be uploaded, the DOI is reserved.
}
931 \footnotetext{Lubbers, M.; Koopman, P.; Ramsingh, A.; Singer, J.; Trinder, P. (
2021): Source code, line counts and memory stats for CRS, CWS, CRTS and CWTS.\ Zenodo.\
\href{https://doi.org/
10.5281/zenodo
.5040754}{10.5281/zenodo
.5040754}.
}
932 but as the programming abstractions are broadly similar, we compare only the
\gls{PWTS
} and
\gls{CWTS
} implementations.
934 Although the temperature sensor applications are small compared to the smart campus application, they share some typical
\gls{IOT
} stack traits.
935 The architecture consists of a server and a single sensor node (
\cref{fig_t4t:cwtsDiagram
}).
936 The sensor node measures and reports the temperature every ten seconds to the server while the server displays the latest temperature via a web interface to the user.
938 \Cref{table_t4t:temp
} compares the
\gls{SLOC
} required for the
\gls{MICROPYTHON
} and
\gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} \gls{WEMOS
} temperature sensors:
\gls{PWTS
} and
\gls{CWTS
} respectively. The code sizes here should not be used to compare the programming models as implementing such a small application as a conventional
\gls{IOT
} stack requires a significant amount of configuration and other machinery that would be reused in a larger application. Hence, the ratio between total
\gls{PWTS
} and
\gls{CWTS
} code sizes (
298:
15) is far greater than for realistic applications like
\gls{PWS
} and
\gls{CWS
} (
471:
166).
942 \caption{Comparing
\gls{CLEAN
} and
\gls{PYTHON
} programming abstractions using the
\gls{PWTS
} and
\gls{CWTS
} temperature sensors (
\gls{SLOC
} and total number of files.)
}%
943 \label{table_t4t:temp
}
944 \begin{tabular
}{llccl
}
946 Location & Functionality &
\gls{PWTS
} &
\gls{CWTS
} & Lines (
\cref{lst_t4t:mtaskTemp
})\\
948 Sensor Node & Sensor Interface &
14 &
3 &
\labelcref{lst_t4t:mtaskTemp:si0,lst_t4t:mtaskTemp:si1,lst_t4t:mtaskTemp:si2
}\\
949 & Sensor Node &
67 &
4 &
\labelcref{lst_t4t:mtaskTemp:sn0,lst_t4t:mtaskTemp:sn1,lst_t4t:mtaskTemp:sn2,lst_t4t:mtaskTemp:sn3
}\\
950 Server & Web Interface &
17 &
3 &
\labelcref{lst_t4t:mtaskTemp:wi0,lst_t4t:mtaskTemp:wi1,lst_t4t:mtaskTemp:wi2
}\\
951 & Database Interface &
106 &
2 &
\labelcref{lst_t4t:mtaskTemp:di0,lst_t4t:mtaskTemp:di1
}\\
952 Communication & Communication &
94 &
3 &
\labelcref{lst_t4t:mtaskTemp:co0,lst_t4t:mtaskTemp:co1,lst_t4t:mtaskTemp:co2
}\\
954 % \multicolumn{2}{c}{Total (\textnumero{} Files)} & 298 (27) & 15 (1) \\
955 Total
\gls{SLOC
} & &
298 &
15 \\
956 \textnumero{} Files & &
27 &
1 \\
961 The multiple tiers in
\gls{PRS
} and
\gls{PWS
} provide different levels of abstraction and separation of concerns.
962 %in order to facilitate interoperation of the components.
963 However, there are various ways that high-level abstractions make the
\gls{CWS
} much shorter than
\gls{PRS
} and
\gls{PWS
} implementations.
965 Firstly,
\gls{FP
} languages are generally more concise than most other programming languages because their powerful abstractions like higher-order and/or polymorphic functions require less code to describe a computation.
966 Secondly, the
\gls{TOP
} paradigm used in
\gls{ITASK
} and
\gls{MTASK
} reduces the code size further by making it easy to specify
\gls{IOT
} functionality concisely.
967 As examples, the step combinator
\cleaninline{>>*.
} allows the task value on the left-hand side to be observed until one of the steps is enabled;
968 and the
\cleaninline{viewSharedInformation
} (line
31 of
\cref{lst_t4t:mtaskTemp
}) part of the UI will be automatically updated when the value of the
\gls{SDS
} changes. Moreover, each
\gls{SDS
} provides automatic updates to all coupled
\glspl{SDS
} and associated tasks. Thirdly, the amount of explicit type information is minimised in comparison to other languages, as much is automatically inferred~
\citep{hughes1989functional
}.
970 \section{Could tierless
\texorpdfstring{\gls{IOT
}}{IoT
} programming be more reliable than tiered?
}%
971 \label{sec_t4t:Discussion
}
974 This section investigates whether tierless languages make
\gls{IOT
} programming more reliable. Arguably the much smaller and simpler code base is inherently more understandable, and more likely to be correct. Here we explore specific language issues, namely those of preserving type safety, maintainability, failure management, and community support.
976 \subsection{Type safety
}%
977 \label{sec_t4t:typesafety
}
978 Strong typing identifies errors early in the development cycle, and hence plays a crucial role in improving software quality. In consequence almost all modern languages provide strong typing, and encourage static typing to minimise runtime errors.
979 % Phil: so widely known that a citation is unnecessary~\citep{madsen1990strong}.
980 That said, many distributed system components written in languages that primarily use static typing, like
\gls{HASKELL
} and Scala, use some dynamic typing, e.g.\ to ensure that the data arriving in a message has the anticipated type~
\citep{epstein2011towards,gupta2012akka
}.
982 In a typical tiered multi-language
\gls{IOT
} system the developer must integrate software in different languages with very different type systems, and potentially executing on different hardware. The challenges of maintaining type safety have long been recognised as a major component of the semantic friction in multi-language systems, e.g.\
\citep{ireland2009classification
}.
984 Even if the different languages used in two components are both strongly typed, they may attribute, often quite subtly, different types to a value. Such type errors can lead to runtime errors, or the application silently reporting erroneous data. Such errors can be hard to find. Automatic detection of such errors is sometimes possible, but requires an addition tool like Jinn~
\citep{Jinn,Furr2005
}.
985 %Such errors can be hard to debug, partly because there is very limited tool support for detecting them
986 %Phil: another possible source to discuss ~\citep{egyed1999automatically}
988 \begin{lstPython
}[caption=
{\Gls{PRS
} loses type safety as a sensor node sends a
{\tt\footnotesize double
}, and the server stores a
{\tt\footnotesize string
}.
},label=
{lst_t4t:float
},morekeywords=
{message,enum,uint64,double
}]
990 enum SensorType
{ TEMPERATURE =
1;
[+
\ldots+
] }
991 SensorType sensor_type =
1;
992 uint64 timestamp =
2;
993 double float_value =
3;
996 channel = 'sensor_status.
%s.%s' % (hostname,
997 sensor_types.sensor_type_name(s.sensor_type))
998 self.r.publish(channel, s.SerializeToString())
1001 Analysis of the
\gls{PRS
} codebase reveals an instance where it, fairly innocuously, loses type safety. The fragment in
\cref{lst_t4t:float
} first shows a
\pythoninline{double
} sensor value being sent from the sensor node, and then shows the value being stored in Redis as a
\pythoninline{string
} on the server. As
\gls{PWS
} preserves the same server components it also suffers from the same loss of type safety.
1003 \emph{A tierless language makes it possible to guarantee type safety across an entire
\gls{IOT
} stack
}. For example the
\gls{CLEAN
} compiler guarantees static type safety as the entire
\gls{CWS
} software stack is type checked, and generated, from a single source. Tierless web stack languages like Links~
\citep{cooper2006links
} and Hop~
\citep{serrano2006hop
} provide the same guarantee for web stacks.
1006 \subsection{Failure management
}%
1007 \label{sec_t4t:NetworkManagement
}
1009 Some
\gls{IOT
} applications, including smart campus and other building monitoring applications, require high sensor uptimes. Hence, if a sensor or sensor node fails the application layer must be notified, so that it can
report the failure. In the
\gls{UOG
} smart campus system a building manager is alerted to replace the failed device.
1011 In many
\gls{IOT
} architectures, including
\gls{PRS
} and
\gls{PWS
}, detecting failure is challenging because the application layer listens to the devices. When a device comes online, it registered with the application and starts sending data.
1012 When a device goes offline again, it could be because the power was out, the device was broken or the device just paused the connection.
1014 If a sensor node fails in
\gls{CWS
}, the
\gls{ITASK
}\slash\gls{MTASK
} combinator interacting with a sensor node will throw an
\gls{ITASK
} exception.
1015 The exception is propagated and a handler can respond, e.g.\ rescheduling the task on a different device in the room, or requesting that a manager replaces the device. That is,
\gls{ITASK
}, uses standard succinct declarative exception handling.
1017 \begin{lstClean
}[caption=
{An
\gls{MTASK
} failover combinator.
},label=
{lst_t4t:failover
}]
1018 failover ::
[TCPSettings
] (Main (MTask BCInterpret a)) -> Task a
1019 failover
[] _ = throw "Exhausted device pool"
1020 failover
[d:ds
] mtask = try ( withDevice d (liftmTask mtask) ) except
1021 where except MTEUnexpectedDisconnect = failover ds mtask
1025 In the
\gls{UOG
} smart campus application, this can be done by creating a pool of sensor nodes for each room and when a sensor node fails, assign another one to the task.
1026 %If the pool of sensor nodes for a room is exhausted, contact a manager.
1027 \Cref{lst_t4t:failover
} shows a failover combinator that executes an
\gls{MTASK
} on one of a pool of sensor nodes.
1028 If a sensor node unexpectedly disconnects, the next sensor node is tried until there are no sensor nodes left.
1029 If other errors occur they are propagated as usual.
1032 Currently,
\gls{PRS
} and
\gls{PWS
} both use heartbeats to confirm that the sensor nodes are operational, and will
report failures. At the cost of extending the codebase, failover to an alternate sensor node could be provided.
1034 \subsection{Maintainability
}
1036 Far more engineering effort is expended on maintaining a system, than on the initial development. Tiered and tierless
\gls{IOT
} systems have very different maintainability properties.
1038 The modularity of the tiered stack makes replacing tiers/components easy. For example in
\gls{PWS
} or
\gls{PRS
} the MongoDB NoSQL DBMS could be readily be replaced by an alternative like
{CouchDB
}. Because a tierless compiler must generate code for components, replacing them may not be so easy. If there are
\gls{ITASK
} abstractions for the component then replacement is straightforward. For example replacing SQLite with some other SQL DBMS simply entails recompilation of the application.
1039 However incorporating a component that does not yet have a task abstraction, like a NoSQL DBMS, is more involved. That is, a foreign function interface to the new component must be implemented, along with a suitable
\gls{ITASK
} abstraction for operations on the component.
1041 Many maintenance tasks are smaller in scale and occur within the components or tiers. Consider a simple change, for example if the temperature value recorded by a sensor changes from integer to real.
1043 All tiers of a tiered stack must be correctly and consistently refactored to reflect the change of temperature data type: so changes at the perception, network, application and presentation layers. A
\gls{PWS
} developer works in seven languages and two paradigms to effect the change (
\cref{table_t4t:multi
}), and must edit many source files. Many programming errors are either detected at runtime when testing the stack, or worse not automatically detected and produce erroneous results.
1045 In a tierless language the source code is much smaller and so it is easier to comprehend, i.e.\ to understand what refactoring is required. A
\gls{CWS
} developer works in only two languages and a single paradigm to effect the change, and will edit no more than three source files (
\cref{table_t4t:multi
}). Moreover, the compiler will statically detect many programming errors.
1047 More substantial in-component maintenance raises similar issues as for tiered implementations. If the maintenance activity requires a new task combinator, this is readily constructed in
\gls{ITASK
}, but may require changing the
\gls{DSL
} implementation in
\gls{MTASK
}, i.e.\ to change the compiler and the byte code interpreter. That is,
\gls{MTASK
} is more
\emph{brittle
} than
\gls{ITASK
}.
1049 In summary, while a tiered approach makes replacing components easy, refactoring within the components is far harder in a multi-tier multi-language
\gls{IOT
} implementation than in a tierless
\gls{IOT
} implementation.
1051 \subsection{Support
}%
1052 \label{sec_t4t:support
}
1053 %\mlcomment{I've shortened this quite a bit}
1054 Community and tool support are essential for engineering reliable production software.
\gls{PRS
} and
\gls{PWS
} are both
\gls{PYTHON
} based, and
\gls{PYTHON
}\slash\gls{MICROPYTHON
} are among the most popular programming languages~
\citep{cass2020top
}.
\gls{PYTHON
} is also a common choice for some tiers of
\gls{IOT
} applications~
\citep{tanganelli2015coapthon
}.
1055 Hence, there are a wide range of development tools like
\glspl{IDE
} and debuggers, a thriving community and a wealth of training material. There are even specialised
\gls{IOT
} Boards like PyBoard \& WiPy that are specifically programmed using
\gls{PYTHON
} variations like
\gls{MICROPYTHON
}.
1057 In contrast, tierless languages are far less mature than the languages used in tiered stacks, and far less widely adopted.
1058 This means that for
\gls{CWS
} and
\gls{CRS
} there are fewer tools, a far smaller developer community, and less training material available.
1060 \Gls{CWS
} and
\gls{CRS
} are both written in
\glspl{DSL
} embedded in
\gls{CLEAN
}, a fairly stable industrial-grade but niche
\gls{FP
} language.
1061 The
\glspl{DSL
} are implemented in
\gls{CLEAN
} but require experimental compiler extensions that are often undocumented.
1062 There are few maintainers of the
\glspl{DSL
} and documentation is often sparse.
1063 Acquiring information about the systems requires distilling academic papers and referring to the source code.
1064 There is a
\gls{CLEAN
} \gls{IDE
}, but it does not contain support for the
\gls{ITASK
} or
\gls{MTASK
} \glspl{DSL
}.
1066 \section{Comparing tierless languages for resource-rich/constrained sensor nodes
}%
1067 \label{sec_t4t:ComparingTierless
}
1069 This section compares two tierless
\gls{IOT
} languages: one for resource-rich, and the other for resource-constrained, sensor nodes. Key issues are the extent to which the very significant resource constraints of a microprocessor limit the language, and the benefits of executing on bare metal, i.e.\ without an
\gls{OS
}.
1071 With the tierless
\gls{CLEAN
} technologies described here,
\gls{ITASK
} are always used to program the application and presentation layers of the
\gls{IOT
} stack. So any differences occur in the perception and network layer programming.
1072 If sensor nodes have the capacity to support
\gls{ITASK
}, a tierless
\gls{IOT
} system can be constructed in
\gls{CLEAN
} using only
\gls{ITASK
}, as in
\gls{CRS
}. Alternatively for sensor nodes with low computational power, like typical microprocessors,
\gls{MTASK
} is used for the perception and network layers, as in
\gls{CWS
}.
1073 This section compares the
\gls{ITASK
} and
\gls{MTASK
} \glspl{EDSL
}, with reference to
\gls{CRS
} and
\gls{CWS
} as exemplars.
\Cref{table_t4t:languagecomparison
} summarises the differences between the
\gls{CLEAN
} embedded
\gls{IOT
} \glspl{EDSL
} and their host language.
1077 \caption{Comparing tierless
\gls{IOT
} languages for resource-rich sensor nodes (
\gls{ITASK
} \gls{EDSL
}), for resource-constrained sensor nodes (
\gls{MTASK
} \gls{EDSL
}), and their
\gls{CLEAN
} host language.
}%
1078 \label{table_t4t:languagecomparison
}
1079 \begin{tabular
}{llll
}
1081 Property &
\gls{CLEAN
} &
\gls{ITASK
} &
\gls{MTASK
}\\
1083 Function for an
\gls{IOT
} System & Host Language & Specify distri- & Specify sensor\\
1084 & & buted workflows & node workflow \\
1086 Referentially transparent & Yes & Yes & Yes \\
1087 Evaluation strategy & Lazy & Lazy & Strict\\
1088 Higher-order functions & Yes & Yes & No \\
1089 User-defined datatypes & Yes & Yes & No \\
1090 Task oriented & No & Yes & Yes \\
1091 Higher-order tasks &
{--
} & Yes & No \\
1092 Execution Target & Commodity PC & Commodity PC & Microprocessor\\
1093 & & and Browser & Microprocessor\\
1094 Language Implementation & Compiled or & Compiled and & Interpreted\\
1095 & interpreted & interpreted & Interpreted\\
1100 \subsection{Language restrictions for resource-constrained execution
}
1102 Executing components on a resource-constrained sensor node imposes restrictions on programming abstractions available in a tierless
\gls{IOT
} language or
\gls{DSL
}. The small and fixed-size memory are key limitations. The limitations are shared by any high-level language that targets microprocessors such as BIT, PICBIT, PICOBIT, Microscheme and uLisp~
\citep{dube_bit:_2000,feeley_picbit:_2003,st-amour_picobit:_2009,suchocki_microscheme:_2015, johnson-davies_lisp_2020
}.
1103 Even in low level languages some language features are disabled by default when targeting microprocessors, such as runtime type information (RTTI) in
\gls{CPP
}.
1105 Here we investigate the restrictions imposed by resource-constrained sensor nodes on
\gls{MTASK
}, in comparison with
\gls{ITASK
}. While
\gls{ITASK
} and
\gls{MTASK
} are by design superficially similar languages, to execute on resource-constrained sensor nodes
\gls{MTASK
} tasks are more restricted, and have a different semantics.
1107 \Gls{MTASK
} programs do not support user defined higher order functions, the only higher order functions available are the predefined
\gls{MTASK
} combinators.
1108 Programmers can, however, use any construct of the
\gls{CLEAN
} host language to construct an
\gls{MTASK
} program, including higher order functions and arbitrary data types. For example folding an
\gls{MTASK
} combinator over a list of tasks.
1109 The only restriction is that any higher order function must be macro expanded to a first order
\gls{MTASK
} program before being compiled to byte code.
1110 %\mlcomment{Pieter: Refine paragraph about macro expansion and currying/HOF}
1111 As an example in
\cref{lst_t4t:mtaskTemp
} we use
\cleaninline{temperature dht >>~.
} \cleaninline{setSds localSds
} instead of
\cleaninline{temperature dht >>~.
} \cleaninline{\
\temp -> setSds localSds temp
}.
1112 %However, this is limited to situations where the expressions are expanded to the required \gls{MTASK} types, i.e.\ the host language acts as a macro language for \gls{MTASK}.
1113 %\mlcomment{I've refined this. The host language does not offer limited use of HOF and currying. It only appears to offer, just macro expansion}.
1114 %\pwtcomment{I've rewritten: please check.}
1116 In contrast to
\gls{ITASK
},
\gls{MTASK
} programs have no user defined or recursive data types. It is possible to add user defined types---as long as they are not sum types---to
\gls{MTASK
}, but this requires significant programming effort.
1117 Due to the language being shallowly embedded, pattern matching and field selection on user defined types is not readily available and thus needs to be built into the language by hand.
1118 Alleviating this limitation remains future work.
1120 \Gls{MTASK
} programs mainly use strict rather than lazy evaluation to minimise the requirement for a variable size heap. This has no significant impact for the
\gls{MTASK
} programs we have developed here, nor in other
\gls{IOT
} applications we have engineered.
1122 \Gls{MTASK
} abstractions are less easily extended than
\gls{ITASK
}. For example
\gls{ITASK
} can be extended with a new combinator that composes a specific set of tasks for some application.
1123 Without higher order functions the equivalent combinator can often not be expressed in
\gls{MTASK
}, and adding it to
\gls{MTASK
} requires extending the
\gls{DSL
} rather than writing a new definition in it.
1124 On the other hand, it is possible to outsource this logic to the
\gls{ITASK
} program as
\gls{MTASK
} and
\gls{ITASK
} tasks are so tightly integrated.
1126 \subsection{The benefits of a bare metal execution environment
}
1128 Despite the language restrictions, components of a tierless language executing on a microprocessor can exploit the bare metal environment. Many of these benefits are shared by other bare metal languages like
\gls{MICROPYTHON
} or
\gls{C
}\slash\gls{CPP
}. So as
\gls{MTASK
} executes on bare metal it has some advantages over
\gls{ITASK
}. Most notably
\gls{MTASK
} has better control of timing as on bare metal there are no other processes or threads that compete for CPU cycles.
1129 This makes the
\gls{MTASK
} \cleaninline{repeatEvery
} (
\cref{lst_t4t:mtaskTemp
},
\cref{lst_t4t:mtaskTemp:sn2
}) much more accurate than the
\gls{ITASK
} \cleaninline{waitForTimer
} (
\cref{lst_t4t:itaskTempFull
},
\cref{lst_t4t:itaskTempFull:waitForTimer
}).
1130 While exact timing is not important in this example, it is significant for many other
\gls{IOT
} applications.
1131 In contrast
\gls{ITASK
} cannot give real time guarantees. One reason is that an
\gls{ITASK
} server can ship an arbitrary number of
\gls{ITASK
} or
\gls{MTASK
} tasks to a device.
1132 Such competing tasks, or indeed other
\gls{OS
} threads and processes, consume processor time and reduce the accuracy of timings.
1133 However, even when using multiple
\gls{MTASK
} tasks, it is easier to control the number of tasks on a device than controlling the number of processes and threads executing under an
\gls{OS
}.
1135 An
\gls{MTASK
} program has more control over energy consumption.
1136 The
\gls{MTASK
} \gls{EDSL
} and the
\gls{MTASK
} \gls{RTS
} are designed to minimise energy usage~
\citep{crooijmans_reducing_2021
}.
1137 Intensional analysis of the declarative task description and current progress at run time allow the
\gls{RTS
} to schedule tasks and maximise idle time.
1138 As the
\gls{RTS
} is the only program running on the device, it can enforce deep sleep and wake up without having to worry about influencing other processes.
1140 The
\gls{MTASK
} \gls{RTS
} has direct control of the peripherals attached to the microprocessor, e.g.\ over
\gls{GPIO
} pins. There is no interaction with, or permission required from, the
\gls{OS
}.
1141 Moreover, microprocessors typically have better support for hardware interrupts, reducing the need to poll peripherals.
1142 The downside of this direct control is that
\gls{CWS
} has to handle some exceptions that would otherwise be handled by the
\gls{OS
} in
\gls{CRS
} and hence the device management code is longer:
28 versus
20 \gls{SLOC
} in
\cref{table_t4t:multi
}.
1144 \subsection{Summary
}
1146 \Cref{table_t4t:languagecomparison
} summarises the differences between the
\gls{CLEAN
} \gls{IOT
} \gls{EDSL
} and their host language.
1147 The restrictions imposed by a resource-constrained execution environment on the tierless
\gls{IOT
} language are relatively minor. Moreover the
\gls{MTASK
} programming abstraction is broadly compatible with
\gls{ITASK
}. As a simple example compare the
\gls{ITASK
} and
\gls{MTASK
} temperature sensors in
\cref{lst_t4t:itaskTempFull,lst_t4t:mtaskTemp
}. As a more realistic example, the
\gls{MTASK
} based
\gls{CWS
} smart campus implementation is similar to the
\gls{ITASK
} based
\gls{CRS
}, and requires less than
10\% additional code:
166 \gls{SLOC
} compared with
155 \gls{SLOC
} (
\cref{table_t4t:multi
}).
1149 Even with these restrictions,
\gls{MTASK
} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is
\gls{MTASK
} provides a set of higher order task combinators, shared distributed data stores,
\etc. (
\cref{sec_t4t:mtasks
}). Moreover, it seems that common sensor node programs are readily expressed using
\gls{MTASK
}. In addition to the
\gls{CWTS
} and
\gls{CWS
} systems outlined here, other case studies include Arduino examples as well as some bigger tasks~
\citep{koopman_task-based_2018,lubbers_writing_2019,LubbersMIPRO
}. We conclude that the programming of sensor tasks is well-supported by both
\glspl{DSL
}.
1151 \section{Conclusion
}%
1152 \label{sec_t4t:Conclusion
}
1154 \subsection{Summary
}
1157 We have conducted a systematic comparative evaluation of two tierless language technologies for
\gls{IOT
} stacks: one for resource-rich, and the other for resource-constrained sensor nodes. The basis is four implementations of a deployed smart campus
\gls{IOT
} stack: two conventional tiered and
\gls{PYTHON
}-based stacks, and two tierless
\gls{CLEAN
} stacks. An operational comparison of implementations demonstrates that they have equivalent functionality, and meet the
\gls{UOG
} smart campus functional requirements (
\cref{sec_t4t:Case
}).
1159 We show that
\emph{tierless languages have the potential to significantly reduce the development effort for
\gls{IOT
} systems
}. Specifically the tierless
\gls{CWS
} and
\gls{CRS
} stacks require far less code, i.e.\
70\% fewer
\gls{SLOC
}, than the tiered
\gls{PWS
} and
\gls{PRS
} stacks (
\cref{table_t4t:multi
}). We analyse the code reduction and attribute it to the following three main factors.
1161 \item Tierless developers need to manage less interoperation:
\gls{CRS
} uses a single
\gls{DSL
} and paradigm, and
\gls{CWS
} uses two
\glspl{DSL
} in a single paradigm and three source code files. In contrast, both
\gls{PRS
} and
\gls{PWS
} use at least six languages in two paradigms and spread over at least
35 source code files (
\cref{table_t4t:multi,table_t4t:languages,table_t4t:paradigms
}). Thus, a tierless stack minimises semantic friction.
1162 \item Tierless developers benefit from automatically generated, and hence correct, communication (
\cref{lst_t4t:mtaskTemp
}), and write
6$
\times$ less communication code (
\cref{fig_t4t:multipercentage
}).
1163 \item Tierless developers can exploit powerful high-level declarative and task-oriented
\gls{IOT
} programming abstractions (
\cref{table_t4t:temp
}), specifically the composable, higher-order task combinators outlined in
\cref{sec_t4t:itasks
}.
1164 Our empirical results for
\gls{IOT
} systems are consistent with the benefits claimed for tierless languages in other application domains. Namely that a tierless language provides a
\textit{Higher Abstraction Level
},
\textit{Improved Software Design
}, and improved
\textit{Program Comprehension
}~
\citep{weisenburger2020survey
}.
1167 We show that
\emph{tierless languages have the potential to significantly improve the reliability of
\gls{IOT
} systems
}. We illustrate how
\gls{CLEAN
} maintains type safety, contrasting this with a loss of type safety in
\gls{PRS
}.
1168 We illustrate higher order failure management in
\gls{CLEAN
}\slash\gls{ITASK
}/
\gls{MTASK
} in contrast to the
\gls{PYTHON
}-based failure management in
\gls{PRS
}. For maintainability a tiered approach makes replacing components easy, but refactoring within the components is far harder than in a tierless
\gls{IOT
} language. Again our findings are consistent with the simplied
\textit{Code Maintenance
} benefits claimed for tierless languages~
\citep{weisenburger2020survey
}.
1169 Finally, we contrast community support for the technologies (
\cref{sec_t4t:Discussion
}).
1171 %\pwtcomment{Pieter: please check discussion of ~\citep{weisenburger2020survey} in preceding 2 paragraphs}
1173 We
report \emph{the first comparison of a tierless
\gls{IOT
} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes
}.
1175 \item The tierless implementations have very similar code sizes (
\gls{SLOC
}), as do the tiered implementations: less than
7\% difference in
\cref{table_t4t:multi
}. This suggests that the development and maintenance effort of simple tierless
\gls{IOT
} systems for resource-constrained and for resource-rich sensor nodes is similar, as it is for tiered technologies.
1176 \item The percentages of code required to implement each
\gls{IOT
} functionality in the tierless
\gls{CLEAN
} implementations is very similar
1177 as it is in the tiered
\gls{PYTHON
} implementations (
\cref{fig_t4t:multipercentage
}). This suggests that the code for resource-constrained and resource-rich sensor nodes can be broadly similar in tierless technologies, as it is in many tiered technologies (
\cref{sec_t4t:resourcerich
}).
1180 We present
\emph{the first comparison of two tierless
\gls{IOT
} languages: one designed for resource-constrained sensor nodes (
\gls{CLEAN
} with
\gls{ITASK
} and
\gls{MTASK
}), and the other for resource-rich sensor nodes (
\gls{CLEAN
} with
\gls{ITASK
}).
} \gls{CLEAN
}\slash\gls{ITASK
} can implement all layers of the
\gls{IOT
} stack if the sensor nodes have the computational resources, as the Raspberry Pis do in
\gls{CRS
}. On resource constrained sensor nodes
\gls{MTASK
} are required to implement the perception and network layers, as on the
\gls{WEMOS
} minis in
\gls{CWS
}. We show that a bare metal execution environment allows
\gls{MTASK
} to have better control of peripherals, timing and energy consumption. The memory available on a microprocessor restricts the programming abstractions available in
\gls{MTASK
} to a fixed set of combinators, no user defined or recursive data types, strict evaluation, and makes it harder to add new abstractions. Even with these restrictions
\gls{MTASK
} provide a higher level of abstraction than most bare metal languages, and can readily express many
\gls{IOT
} applications including the
\gls{CWS
} \gls{UOG
} smart campus application (
\cref{sec_t4t:ComparingTierless
}).
1181 Our empirical results are consistent with the benefits of tierless languages listed in Section
2.1 of~
\citep{weisenburger2020survey
}.
1183 \subsection{Reflections
}
1185 This study is based on a specific pair of tierless
\gls{IOT
} languages, and the
\gls{CLEAN
} language frameworks represent a specific set of tierless language design decisions. Many alternative tierless
\gls{IOT
} language designs are possible, and some are outlined in
\cref{sec_t4t:characteristics
}. Crucially the limitations of the tierless
\gls{CLEAN
} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general.
1187 This study has explored some, but not all, of the potential benefits of tierless languages for
\gls{IOT
} systems. An
\gls{IOT
} system specified as a single tierless program is amenable to a host of programming language technologies. For example, if the language has a formal semantics, as Links, Hop and
\gls{CLEAN
} tasks do~
\citep{cooper2006links,serrano2006hop,plasmeijer_task-oriented_2012
}, it is possible to prove properties of the system, e.g.\
\citep{Steenvoorden2019tophat
}. As another example program analyses can be applied, and
\cref{sec_t4t:characteristics
} and~
\citep{weisenburger2020survey
} outline some of the analyses could be, and in some cases have been, used to improve
\gls{IOT
} systems. Examples include automatic tier splitting~
\citep{10.1145/
2661136.2661146}, and controlling information flow to enhance security~
\citep{valliappan_towards_2020
}.
1189 While offering real benefits for
\gls{IOT
} systems development, tierless languages also raise some challenges. Programmers must master new tierless programming abstractions, and the semantics of these automatic multi-tier behaviours are necessarily relatively complex. In the
\gls{CLEAN
} context this entails becoming proficient with the
\gls{ITASK
} and
\gls{MTASK
} \glspl{DSL
}. Moreover, specifying a behaviour that is not already provided by the tierless language requires either a workaround, or extending a
\gls{DSL
}. However, implementing the relatively simple smart campus application required no such adaption. Finally, tierless
\gls{IOT
} technology is very new, and both tool and community support have yet to mature.
1192 \subsection{Future work
}
1194 This paper is a technology comparison between tiered and tierless technologies. The metrics reported, such as code size, numbers of source code files, and of paradigms are only indirect, although widely accepted, measures of development effort. A more convincing evaluation of tierless technologies could be provided by conducting a carefully designed and substantial user study, e.g.\ using N-version programming.
1196 A study that implemented common benchmarks or a case study in multiple tierless
\gls{IOT
} languages would provide additional evidence for the generality of the tierless approach. Such a study would enable the demonstration and comparison of alternative design decisions within tierless languages, as outlined in
\cref{sec_t4t:characteristics
}.
1199 In ongoing work we are extending the
\gls{MTASK
} system in various ways. One extension allows
\gls{MTASK
} tasks to communicate directly, rather than via the
\gls{ITASK
} server. Another provides better energy management, which is crucial for battery powered sensor nodes.
1201 \section*
{Acknowledgements
}
1202 Thanks to Kristian Hentschel and Dejice Jacob who developed and maintain
\gls{PRS
}
1203 and to funders: Royal Netherlands Navy, the Radboud-Glasgow Collaboration Fund, and UK EPSRC grants MaRIONet (EP/P006434) and STARDUST (EP/T014628). We also thank Lito Michala, Jose Cano, Greg Michaelson, Rinus Plasmeijer, and the anonymous TIOT reviewers for valuable feedback on the paper.
1205 \input{subfilepostamble
}
repositories / phd-thesis.git / blob