<figure><img src="image_1.png" /></figure>

HAL
open science

# A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective

Fatma-Zohra Hannou, Maxime Lefrançois, Pierre Jouvelot, Victor Charpenay, Antoine Zimmermann

► To cite this version:

Fatma-Zohra Hannou, Maxime Lefrançois, Pierre Jouvelot, Victor Charpenay, Antoine Zimmermann. A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective. ACM Computing Surveys, 2024, 10.1145/3699954. hal-04764936

HAL Id: hal-04764936

https://hal.science/hal-04764936v1

Submitted on 12 Nov 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective

FATMA-ZOHRA HANNOU, EDF R&D, Paris Saclay, France

MAXIME LEFRANÇOIS, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France

PIERRE JOUVELOT, Mines Paris, PSL University, France, France

VICTOR CHARPENAY, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France

ANTOINE ZIMMERMANN, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France

The vast growth and digitalization potential offered by the Internet of Things (IoT) is hindered by substantial barriers in accessibility, interoperability, and complexity, mainly affecting small organizations and non-technical entities. This survey paper provides a detailed overview of the landscape of IoT programming platforms, focusing specifically on the development support they offer for varying end-user profiles, ranging from developers with IoT expertise to business experts willing to take advantage of IoT solutions to automate their organization processes. The survey examines a range of IoT platforms, classified according to their programming approach between general-purpose programming solutions, model-driven programming, mashups and end-user programming. Necessary IoT and programming backgrounds are described to empower non-technical readers with a comprehensive field summary. In addition, the paper compares the features of the most representative platforms and provides decision insights and guidelines to support end-users in selecting appropriate IoT platforms for their use cases. This work contributes to narrowing the knowledge gap between IoT specialists and end users, breaking accessibility barriers and further promoting the integration of IoT technologies in various domains.<fnref n="1" />

CCS Concepts: • **General and reference → Surveys and overviews;** • **Computer systems organization → Sensor networks;**
**Embedded and cyber-physical systems;** • **Software and its engineering → Software development techniques;**
**Development frameworks and environments.**

Additional Key Words and Phrases: Internet of Things, IoT programming, IoT platforms, Smart Building, Smart Agriculture

<footnote n="1">¹Due to space constraints, this paper has been abridged. An extended version of the original work is available at the following link: https://hal.science/hal-04159987</footnote>

<footnote>Authors' addresses: Fatma-Zohra HANNOU, fatma-zohra.hannou@edf.fr, EDF R&D, Paris Saclay, France; Maxime Lefrançois, maxime.lefrancois@emse.fr, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France; Pierre Jouvelot, Mines Paris, PSL University, France, France; Victor Charpenay, victor.charpenay@emse.fr, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France; Antoine Zimmermann, antoine.zimmermann@emse.fr, Mines Saint-Etienne, Univ Clermont Auvergne, INP Clermont Auvergne, CNRS, UMR 6158 LIMOS, F-42023 Saint-Etienne, France.</footnote>

<footnote>Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.</footnote>

<footnote>© 2024 Association for Computing Machinery.</footnote>

<footnote>Manuscript submitted to ACM</footnote>
**ACM Reference Format:**

Fatma-Zohra HANNOU, Maxime Lefrançois, Pierre Jouvelot, Victor Charpenay, and Antoine Zimmermann. 2024. A Survey on IoT Programming Platforms: A Business-Domain Experts Perspective. *ACM Comput. Surv.* 1, 1 (November 2024), 35 pages. https://doi.org/XXXXXXX.XXXXXXX

# 1 INTRODUCTION

The emergence of the Internet of Things (IoT) has opened up a broader, deeper, and more realistic perception of the surrounding environment by transforming any “thing” into a quasi-continuously available data source or control lever. It has demonstrated an unlimited potential for boosting the digitization of many aspects of everyone’s daily life [47]. It also supports companies in optimizing process automation, increasing operational efficiency, and optimizing costs. The IoT market has witnessed tremendous growth (from 300 billion USD in 2021 to an expected 600 billion USD in 2026 [48]), offering many new device technologies, tools, architectures, and projects, either generic or tailored to specific use cases. While this diversity accelerates the adoption of IoT within multiple domains, such as building automation, healthcare, agriculture, or energy management, it raises interoperability and access challenges. The subsequent complexity might represent a significant barrier to the immediate IoT technologies use for small organizations (or non-technical companies) that cannot afford the cost of hiring IoT expert teams to handle complex architectures and deployment processes. IoT platforms combine hardware and software technologies to enable the building and deployment of IoT applications [1] through a common user interface, easing access and interoperability within the IoT ecosystem. It provides services and facilities to develop IoT solutions, including device integration, data storage and processing, user communication and development tools. Yet, the promise of easy-to-deploy, easy-to-configure IoT systems has not been entirely fulfilled. In most cases, IoT systems are developed on generic platforms offering predefined routines with limited customization options. Domain-oriented tools are often focused on fixed architectures, device ranges, and features that do not necessarily match the organization’s needs, especially those covering overlapping vertical domains (e.g., building management and healthcare, agriculture and industry), requiring the combined automation of both domains’ processes.

Somewhere between the average end user and the IoT specialist, the so-called “vertical domain expert” increasingly expresses the will to obtain the most out of the IoT technologies by going beyond the ‘configuration routine” mode. To meet these expectations, a new generation of IoT platforms has widened the spectrum of their user profiles by creating simplified user interfaces (UIs) with more expressive power. These UIs, often rely on *domain-specific languages* [27] (DSLs), with the aim to reach larger end-user communities, including those with no or little technical background.

As an end-user, understanding the extent of what an IoT platform offers, its characteristics, and whether it makes a suitable choice for the use case at hand is a challenging matter. Committing to a specific IoT deployment requires a positive cost-benefit balance and compliance with additional requirements: interoperability, domain tasks, level of abstraction (following user skills), maintenance cost, or documentation availability. These factors, among others, are of variable importance depending on the application use cases. For example, the user/developer should consider interoperability guarantees when dealing with heterogeneous devices, protocols or sub-domains. In other cases, as within healthcare or building management fields, sensitive data and processes have to be protected against disclosure and unauthorized access risks, making security and privacy guarantees of utmost importance. Other requirements include reliability, latency, autonomy, and cost.

Unfortunately, the current scientific literature does not, to our knowledge, provide a comprehensive comparison and evaluation of IoT platforms based on the practical requirements of end-users across different domains. Most of the existing works discussed in the Related Work section in the Supplementary material (Appendix A) consider the study
of IoT platforms from a single perspective such as interoperability, architecture, connectivity, standards, security or cloud services. The specialized nature of these papers increases the difficulty of getting a comprehensive understanding of all these platforms while taking into account all their necessary practical characteristics. This survey paper aims to lower the access barriers to IoT technologies by filling this gap, evaluating IoT platforms on multiple key factors, and providing end-users with actionable insights to make informed decisions when selecting an IoT platform.

In this survey paper, we consider these key factors to describe the landscape of IoT programming platforms and exhibit some of their strengths and weaknesses. However, given the vast spectrum of available technologies, this survey focuses solely on the development side of IoT applications.

Accordingly, particular attention is paid to the support the existing platforms offer to users aiming to develop applications. This technology segment is explored based on the most relevant parameters, such as the abstraction level of IoT-specific programming languages, the expressiveness or richness of the associated toolboxes, etc. Various programming languages are accessible through IoT platforms, from the lowest abstraction level to high-level DSLs dedicated to vertical domains, with adapted representations and vocabularies.

*Contributions and Audience.* This survey aims at providing vertical domain experts striving to develop IoT applications with programming-related resources to understand the existing IoT landscape. IoT platforms are presented following different development approaches that match more or less target users’ profiles. It is intended to be used as a resource by this particular developer community for making an informed decision regarding which platform presents the best characteristics for their expected application. As such, the contribution of this work is twofold. First, it provides background on the IoT field with a particular focus on programming languages. The most relevant characteristics are defined and serve as a basis for assessing platforms. Second, it produces an analysis of the IoT landscape driven by end-user/developer requirements, examining platforms’ families and characteristics.

*Related surveys.* Several works survey IoT platforms and technologies, with variable focus points. Note that several related topics fall outside the scope of this survey, such as IoT architectures, interoperability projects, software architectures, security, or DSL implementations. Some of these aspects are mentioned in the high-level description of the IoT platforms, and therefore introduced in the survey background to support reader understanding decision insights completing programming features. However, no study covering these matters is conducted here. For more details about related works, we refer the reader to the Related Surveys section in the Supplementary material (Appendix A).

*Organization.* The remainder of this paper is organized as follows (see the roadmap illustration provided in Figure 1). Section 2 introduces two running examples used along the paper to illustrate representative usage scenarios of IoT

<figure><img src="image_3.png" /><figcaption>Fig. 1. Roadmap of the paper</figcaption></figure>
platforms. The first scenario deals with a building automation application for indoor air-quality monitoring, and the second considers precision agriculture through the case of a smart irrigation process. Section 3 provides an overview of the IoT field to introduce some key platform characteristics such as interoperability, software architecture, licences, or business domain. Appendix B in the Supplementary material also provides background information about programming languages with a focus on domain-specific languages highly used within the IoT community. Section 4 presents an insight into generic IoT platforms grouped by programming approaches. It showcases how the technical characteristics of each tool can be exploited in an automation scenario and to what IoT task it contributes. Section 5 covers specific agriculture and building automation IoT solutions. Section 6 summarizes the outcomes through a comparative table highlighting discussed platform's properties and decision making insights.

## 2 USE CASES

This section introduces two use cases for IoT programming technologies, for the building automation and the precision agriculture domains (see Fig. 2). These two domains have been selected as they are good representatives of the user community of IoT technologies, and rely on similar physical sensing techniques but with contrasting semantics, purposes, and deployment architectures (indoor/outdoor), providing thus an insightful spectrum of possibilities.

<figure><img src="image_4.png" /><figcaption>Fig. 2. Two example use cases for IoT programming technologies.</figcaption></figure>

*Building Automation Use Case.* Building-automation scenarios often aim at fulfilling energy-optimization strategies while guaranteeing users' health and comfort. Modern building management relies on sensor networks that collect data about environmental indicators, energy consumption, or room occupancy. Various actuators are deployed within the building for automatic window and door opening or controlling heating, ventilation, air conditioning, or lighting equipment. In the use case illustrated in Fig. 2a, sensors continuously monitor the indoor temperature and CO₂ levels to determine the air quality in a classroom. These data, enriched with room occupancy information (course schedule), can be used to determine the air quality and user preference for optimal temperature. Heating can be triggered as late
as possible such that the comfort temperature is reached when the users come in. If the observed CO₂ level is too high, the window is opened automatically and the heater is shut down.

*Smart Irrigation Use Case.* Precision agriculture techniques automate and optimize different crop-related processes, for example to supervise the irrigation process by automatically triggering or stopping crop watering. In the use case illustrated in Fig. 2b, sensors and actuators are deployed in the outdoor plots and the indoor greenhouse of a Farm. Sensors 1, 2, and 3 respectively observe the current indoor temperature, humidity, and soil moisture within the greenhouse. The outdoor sensors measure the soil moisture of the plots, and the local weather station provides current and forecasted weather data. Data is centralized and enriched with the crop-development state. Neuro-symbolic AI techniques are applied to support a twofold decision-making process to ensure optimal crop development: when to start/stop the watering, and what amount of water to deliver via water valves. The optimal strategy also considers budget, regulations, water-availability planning, productivity constraints, heat waves, etc.

# 3 BACKGROUND ON THE INTERNET OF THINGS

The IoT allows physical objects to have digital identities and connect to the Internet. This enables them to generate and exchange data about their status and surroundings. Kevin Ashton coined the term IoT in 1999, linking it to networks of Radio-Frequency Identification (RFID) chips [3]. The IoT has numerous definitions, often emphasizing specific deployment cases or architectural considerations. The International Telecommunication Union (ITU) provides the following definition [32]: *a global infrastructure for the information society, enabling advanced services by interconnecting (physical and virtual) things based on existing and evolving interoperable information and communication technologies.*

Objects in the IoT context can be any physical entity that can connect directly or indirectly to the Internet. With the advancement of technology and connectivity standards, more objects can now be part of the IoT. In 2008, the number of connected objects surpassed the number of humans accessing the Internet (Cisco Internet Business Solutions [31]). Cloud-based application services [4] have become increasingly popular across a wide range of applications and scales: industry [105], smart buildings [54], healthcare [49], agronomy [86], and more [93].

The main characteristics used in this survey to describe IoT platforms are grouped into five topics: interoperability, software architecture, licence and cost, business domain, and development support. This section presents the first four dimensions, and how tools are evaluated according to their subsequent criteria. Given that the primary focus of this survey is the programming of IoT applications, the development support is detailed in the Supplementary material (Appendix A).

## 3.1 Heterogeneity-Interoperability

Adapting to the high pace of technological advances, IoT tools and platforms constantly expand support to new devices, protocols, and services, increasing the heterogeneity of IoT systems and raising new interoperability challenges.

This section reviews common heterogeneity/interoperability sources such as device, connectivity, syntax, and semantics, and provides an overview of related interoperability issues.

### 3.1.1 Device
The diversity of IoT technology providers led to a mixture of billions of devices with heterogeneous hardware specifications coexisting within IoT systems. Within an IoT network architecture, nodes correspond to devices with computing capabilities. They are generally categorized according to their resources, mainly RAM, storage, CPU, communication protocols, energy supply, transmission power, and the architectural layer they belong to. These characteristics are determined by the tier in which they are deployed (Cloud, Fog, Edge) [87]. Related taxonomies
prosper and sometimes differ (see, e.g., [91, 94]), but a frequently used classification builds upon three levels: low or constrained devices with limited resources, middle or FOG devices, and powerful nodes such as cloud infrastructures.

### 3.1.2 Connectivity.
One early challenge the IoT field faced was the strong requirement for continuous object connectivity. Building reliable smart applications relies on the quasi-timely availability of sensing and actuating capabilities. The device heterogeneity and the need for reliable data exchange channels require deployment strategies to leverage hybrid networking and messaging protocols.

At the infrastructure (network) level, an extensive set of communication networks are inherited from the Wireless Sensor Network field [107], providing a wide spectrum of constrained objects with their inherent power specifications and connectivity range. Power requirements are an intrinsic characteristics of these devices, often linked to specific supervision needs to avoid high maintenance costs. While some devices support multiple protocols, the connectivity range is defined according to the deployment and application scenario: indoor or outdoor installation, device mobility, available gateways, etc. The connectivity protocols at the lower layers (Physical-Data Link in the OSI model [95]) are commonly identified by their operating range [69]: Contact area (e.g., RFID, NFC), Wireless Personal Area Network (WPAN) protocols such as ZigBEE and Bluetooth, Wireless Local Area Network (WLAN) such as WiFi, Wireless Wide Area Network (WWAN), including cellular and Low-Power Wide Area (LPWAN) networks, up to 100 km such as LoRaWAN. At the top (application) layer of the devices communications, the most popular protocols are [25] HyperText Transfer Protocol (HTTP), Message Queue Telemetry Transport (MQTT) and Constrained Application Protocol (COAP).

### 3.1.3 Syntax.
Syntactic heterogeneity denotes the variability of formats and data structures used to exchange information between IoT system components (nodes and services). IoT systems rely upon the representations most frequently used on the Web: plain text, comma-separated values (CSV), JavaScript Object Notation (JSON), Extensible Markup Language (XML), or Resource Description Framework (RDF) (different serializations). The RDF formats and schemas may turn out to be unsuitable for the most constrained devices that generate and process increasing amounts of data. More lightweight formats with binary representations have been defined, such as Efficient XML Interchange format (EXI) by the W3C,<fnref n="2" /> Constrained Binary Object Representation (CBOR) of the IETF,³ or CBOR Linked Data (CBOR-LD) and Header, Dictionary, Triples (HDT) as RDF binary serializations for linked data. These formats intend to standardize data exchange, but they do not apply everywhere [80].

### 3.1.4 Semantics.
Semantic heterogeneity relates to data understanding. IoT systems communicate data between their nodes to achieve data-centric services. When two entities exchange data, their meaning is not necessarily *understood* the right way by the receiver. The message integrity is threatened, leading to unreliably processed outputs. Metadata can be used to describe data content and its production context to facilitate the interpretation and use of the data. Still, node software might use distinct schemas to generate the metadata, increasing interpretation mismatches. One way to homogenize the knowledge representation in a field of study are ontologies. An ontology is defined, according to [96], as "*a formal, explicit specification of a shared conceptualisation.*" This definition underlines that ontologies provide machine-readable (explicit) abstractions of real-world phenomenon concepts, their relationships and constraints.

IoT ontologies such as Semantic Sensor Network (SSN) [45] / Sensor, Observation, Sample, and Actuator (SOSA) [52], Thing Description (TD) [17] or Smart Applications REFerence (SAREF) [23] have been defined to create a common data interpretation ground for IoT systems. They cover various aspects (e.g., objects, context, communications) to different

<footnote n="2">²World Wide Web Consortium, https://www.w3.org/
³Internet Engineering Task Force, https://www.ietf.org/</footnote>
extents. These ontologies, originating from different organizations, may overlap and do not necessarily share the same
structure or terminology. Moreover, the granularity level of an ontology varies from generic cross-domain descriptions
to domain-specific ontologies (energy, agriculture, etc.). Alignments are not systematically made explicit.

**3.1.5 Interoperability.** As an answer to the high fragmentation of the IoT ecosystem, multiple standard development organizations (SDOs) and initiatives deliver tools, models and guidelines to improve interoperability. Interoperability denotes the ability of different systems to work together [104], and has been very quickly identified as a challenging topic for the IoT field development [5]. The ISO/IEC 19118 standard [51] defines interoperability as *"the capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units."* This definition showcases the utmost importance of ensuring seamless user access with low effort while considering scalability issues. Reaching global interoperability in the context of IoT enables earning reliability and lowering the time it takes to access (connectivity and communication), read (syntax and schemes), understand and transform data into valuable knowledge (semantics). Many research works survey interoperability in IoT [1, 11, 80] and propose classifications, frequently correlated with sources of heterogeneity.

Standards such as communication protocols, data formats or standard ontologies have been defined to overcome heterogeneity. Platforms include a standardization layer at their lowest level, where several devices with variable communication and access protocols can connect to a unique interface. At the application layer, application programming interfaces (APIs) and cloud services interfaces offer data storage and analysis services to enhance collaboration with other platforms and systems. Although platforms play the interoperability game by developing access interfaces such as APIs/software development kit (SDK) or gateways, the diversity of these interfaces complicates the cross-platform and cross-domain application definition task. Several projects have been or are being developed to offer a reference solution for IoT interoperability: IETF SenML [97], OGC SensorThings API [67], and W3C Web of Things (WoT) [43].

**3.2 System Architectures**

Software architecture refers to the overall design and structure of a software system, including its components, their properties and the rules shaping their connections and interactions [8]. A system’s architecture substantially constrains its non-functional requirements [15, 20]. IoT systems often have a complex and heterogeneous architecture, interconnecting multiple hardware and software components at varying abstraction levels.

Standard ISO/IEC 25010:2011 [50] defines a taxonomy for software quality dimensions, such as efficiency, reliability and maintainability. Across the literature [44, 77, 88], some qualities are frequently associated with the evaluation of ubiquitous systems, a class of systems that greatly overlaps with IoT systems: availability (the system remains accessible to users), scalability (the system can be extended to more components), reliability (the system is fault-tolerant) and performance efficiency (the system is functional with minimal resource usage).

In an IoT system architecture, it is important to distinguish between thing components, capable of sensing and actuating in the physical world, and pure software components, only interacting physically via communication protocols (on the Internet or on restricted ZigBEE, BLE or LoRaWAN networks). Things tend to have low availability and low reliability and to offer no scalability (taken in isolation) and limited computing resources. In contrast, cloud-based IoT platforms are generally considered to offer a high quality of service (combining availability and reliability constraints), to scale on demand and to have virtually infinite resources. The quality of an IoT system combining things with a third-party software platform thus depends on the quality of the interactions between the things and the platform.
<figure><img src="image_5.png" /><figcaption>Fig. 3. Common architectural styles for IoT platforms (□: component, □: connector, →: connection)</figcaption></figure>

From a programming point of view, it is also worth distinguishing between software components that are pro-
grammable and those that are not. We will refer to the former as *application-runtime* components and to the latter
as *middleware* components. In some cases, the application runtime is embedded in things themselves. Depending on
the level of abstraction chosen to describe the system’s architecture, a thing can be seen either as the combination
of a sensing/actuation component and a runtime component, deployed on the same platform, or as a single compo-
nent, whose interface to other components is at the physical layer. In the following, we consider the highest level of
abstraction—with the least number of components—and only consider physical-layer connectors between components.
A thing hosting an application runtime will therefore be considered as a single component.

Given the three types of architectural components of IoT systems (things, runtimes and middleware components),
the following criteria are relevant for a comparison of IoT platforms.

* Number of components (of each type). Every IoT system architecture has at least 1 thing component but it may have 0 runtime and/or 0 middleware component. There may be *n* things, runtimes or middleware components.

* Number of distinct connectors per component. Each component has 1 or more interfaces to other components. Each interface is implemented by one connector (e.g., a library, linked statically or dynamically as an add-on to the component's main program). If connectors can be added dynamically to a component, it is assumed that a finite number of connectors can be added to the component. Some IoT platforms are used jointly with a software artifact repository from which add-ons may be downloaded (similar to Maven Central for Java or PyPI for Python, and to Linux package repositories). In this case, the number of connectors provided by the platform component equals the number of (communication-related) artifacts in the repository.

* Number of connections. Two interacting components must have compatible connectors to communicate (e.g., both components embed an MQTT client or an HTTP library). If the connectors of two components are compatible, a connection exists (at the architectural level) between the two components. For simplicity, broadcast and multicast communication is modeled as a set of one-to-one connections between components.

* Type of connections. A connection may be unidirectional or bidirectional. It is unidirectional if only one of the components can initiate communication (regardless of the number of subsequent messages being exchanged between the two components): an HTTP connection is directed from the client towards the server; an MQTT connection is directed from the client (taking either the role of a publisher or a subscriber) towards the hub.

Certain combinations of values for these 4 criteria can be factorized into *architectural styles*, as per usual terminol-
ogy [99, p. 72]. Figure 3 shows some of the main architectural styles in use in the IoT literature: the *kernel*, *blackboard*,
*orchestrator* and *peer-to-peer* styles. In the *kernel style*, the platform is a single runtime able to interact with a het-
erogeneous set of things via multiple connectors. It is analogous to an operating system kernel that exposes a high
number of system calls and can handle a high number of I/O signals. A kernel platform is not naturally scalable, but it tends to provide good performance and a fair level of reliability. A blackboard platform has a small number of connectors (usually 1 or 2, to read and write content) such that any thing with the suitable interface can write data (or read commands) and any application runtime can read data (and write commands). The blackboard is a passive middleware that can compensate low availability of things, but that may not match the performance of a kernel for asynchronous communication. To overcome this problem, the application runtime may be hosted on the same platform as the blackboard. One then obtains the orchestrator style (one runtime, few connectors). An orchestrator has qualities similar to those of a kernel. Finally, in the peer-to-peer style, there is no dedicated runtime and no middleware. Things drive the application in a fully decentralized manner, all things having a connection to all other things. The reliability of a peer-to-peer system is low in general, but its scalability may be high.

Architectural styles impact the quality attributes of the final application [77]. Complex systems often use more than one architectural style [36] and their combination provides trade-offs between targeted quality attributes. Authors in [44] proposed an assessment framework for Edge Computing, but no such work applied to IoT systems exist.

## 3.3 Cost and Licenses

A product license is a legal agreement detailing the terms and conditions governing the use of the product and its possible modification or distribution. It specifies in which context the product can be used and the underlying fees potentially charged. Software product licenses fall under five categories, with broad variations in the detailed terms.

* Open Source Licenses: The product code source is open, free for use, modification and distribution.

* Proprietary Licenses: The product is provided to users under precise access conditions, often involving fees. Extending the product features is impossible since the code source is unavailable for modification or distribution.

* Free Licenses: This license is similar to an open-source license, where the user can access the platform for free. However, the modification of the software code source and its distribution is reserved to its owner.

* Freemium Licenses: They rely on a cost model where a basic version of the product is available for free, while the full version, including more advanced services and features, is only provided by subscribing to a paying offer.

* Commercial Licences: Here, the use or modification of the product requires paying fees.

Licensing is an important factor when selecting an appropriate product; users should carefully review the terms and constraints, mainly for financial reasons, but also to check the legal compliance with their intended use. Some solutions, although adapted to the requirements in terms of features, require an unaffordable budget, which blocks use. Consequently, licensing also has a significant role in adopting IoT technologies for organizations that cannot afford proprietary solutions [12]. Furthermore, some cost models restrict access to the product to a predefined number of devices/users/scenarios, preventing the scalability of the developed applications.

# 4 PROGRAMMING THE IOT

Creating applications for the IoT is of significant complexity, even for experienced domain developers. This is mainly due to considerable hardware and software heterogeneities, requiring advanced knowledge to achieve interoperability. As discussed in Section 3.1, device heterogeneity, due to hardware specification, communications, or resource limitations, makes programming IoT systems borrow a mix of different computational patterns with different styles and programming languages with varying technical abstractions. In layered architecture deployments (cloud, fog, or edge), several programming tools are used to increase technology coverage, widening the range of skills programmers must have.
An IoT-compatible program, either written using a GPL or a DSL, and depending on the role of the node running the program, should present some features for reliability and ease of use [6]: (1) lightweight footprint and efficient resource use; (2) fault tolerance to support connectivity and access instability; (3) interoperability support through libraries and APIs covering various devices; (4) scalability, managing access to masses of services, devices, and data (load-balancing) [108]; (5) concurrent access and coordination between computations performed in distributed parallel systems; (6) availability of language tools and community via development environments, plugins, specific IoT libraries (e.g., General Purpose Input/Output - GPIO -, communication protocols).

Choosing a programming language requires defining the expected outcomes of the application, affordable cost, and time effort. The set of skills necessary for a programmer (end user of the language) to create a full end-to-end IoT system application is getting larger and larger, including knowledge of embedded devices, cloud systems, mobile and web development [98]. Developers use different levels of IoT software stacks depending on the aforementioned considerations but also their expected capabilities to fit the specificities of different deployments.

To make the potential of IoT accessible to end users regardless of their technical proficiency, a wide range of technologies and domain platforms have been defined to enable both developers and end users design smart applications, breaking down the complexity and providing abstractions for low-level specifications. The IoT landscape offers hundreds of such platforms, and a selection methodology has been followed to present those relevant to this paper audience.

## 4.1 Methodology

This survey follows a purposeful selection approach in identifying Internet of Things (IoT) platforms. The following selection criteria were adopted to ensure a holistic representation of available technologies.

* C1: Open Source Platforms. Preference is given to open-source platforms for the benefits they guarantee for seamless access, collaboration and community extent. This aligns with the purpose of offering end-user/developer affordable and easy testing. This criterion has been relaxed for domain-specific platforms, considering the predominance of commercial solutions and the high adaptability that might offer to these domain use cases.

* C2: Domain-Specific Language (DSL) Support. Platforms that offer a DSL designed for IoT applications are prioritized. The use of a DSL can simplify complex tasks, improve productivity, and enrich the community with additional programming resources.

* C3: Various Programming Approaches. The survey aims to present platforms adhering to different programming approaches. Some criteria might be relaxed to favour platforms that accommodate multiple paradigms.

* C4: Richness of the toolbox. Platforms offering different programming channels adapt better to larger user-profile communities. Modelling or mashup platforms might offer scripting APIs for GPL-based programming or leverage visual programming language (VPL) to support non-technical end-users.

* C5: Interoperability. Platforms that enable interoperability are chosen to ensure the potential for seamless integration with different IoT devices, protocols, and systems. Given the heterogeneous nature of IoT ecosystems, higher interoperability support enlarges platform applicability and impact.

* C6: Established User-Base. Preference is given to platforms with a solid user-base over those in the early development phase. Community supports users to master the platform and adapt its features to their use cases.

Following these criteria, the search process has been manually conducted across multiple platforms and databases. Since many IoT programming platforms are industrial solutions developed outside academia, only part of them have
associated published research papers. To ensure a comprehensive coverage, a first step has been to establish a list of platforms that falls into our scope and conforms to selection criteria, by looking at:

* Scientific databases and search engines: Google Scholar, Scopus, ACM digital library, IEEE Xplore Digital Library.

* IoT blogs and industrial platforms websites.

Afterwards, priority was given to platforms compliant with the selection criteria above. A selection of open-source platforms has been made to enable presenting platforms covering various programming paradigms, and with rich toolboxes. For commercial platforms, preference is given to solutions with specific domain features descriptions, which is compliant with the purpose to offer small organizations and less-technical users with tracks on non-complex solutions they can afford. While this approach does not provide an exhaustive overview of all the available platforms, it aims to present a representative sample of the most relevant solutions relying on various programming approaches.

We analyze each selected platform in terms of the following programming characteristics: (1) the type of exposed DSL language (refer to Appendix B in the Supplementary material); (2) whether the platform provides a visual programming interface; (3) if the user interface is textual or graphical; (4) if the programming approach is model-driven programming, mashups, or end-user programming (see Section B.3 in the Supplementary material); (5) the types of tools that support developers' activities; and (6) the programming languages developers can access to develop applications, extend platforms functionalities and set interoperability options. We also analyze the platforms in terms of the characteristics identified and defined in Section 3. We identify if an extension point is defined and documented for supporting more devices, protocols, exchange formats, or data models. We identify the system and components interaction paradigm (see Section 3.2). We also take note of the license of the platform (see Section 3.3), and distinguish between generic, domain-oriented, and task-oriented platforms. Table 1 provides a summary of these IoT platforms characteristics.

## 4.2 General-Purpose Languages

When dealing with a small limited number of devices, IoT systems programming does not much differ from traditional web or mobile development. Interoperability and distribution concerns are less critical, and common general-purpose languages are convenient to use, assuming device resources can afford the requirements of the output programs.

To this extent, one tends to take as the main criteria the device's capabilities and computational power, which explains why assembly language makes a strong comeback among the top ten languages, according to the TIOBE index for the most used programming languages.<fnref n="4" /> By using assembly or C, developers trade productivity in code writing for performance and adequacy to a broader device range.

On larger dimensions, building an IoT system requires dealing with a system of systems [35], where handling low-level programming drawbacks is no longer reasonable. Many cloud-based solutions (Section 3.1) (Platform as a Service and Software As A Service) provide a “golden middle” solution, abstracting devices interoperability while offering web-enabled programming environments through high-level programming languages SDKs (such as Java, python). Still, these solutions are tied to a subset of devices and low-end technologies.

Every year, the Eclipse IoT working group produces an IoT developer survey [28], tracking the most used technologies by IoT developers. Top programming languages are ordered by cloud, fog, and constrained devices tiers. The IoT-programming languages' ranking (last updated June 2022) correlates with the general programming trends, where python takes for the first time the top position, overpassing Java and C.

<footnote n="4">⁴Latest TIOBE Index, https://www.tiobe.com/tiobe-index/. Accessed: 2023-07-10.</footnote>
In addition to its extensive adoption for machine learning-based programs, the use of MicroPython (embedded python language) overcomes the lack of resources by providing complete OS and programming features. Constrained-device programming is evolving with advances to hardware technology, from one-shot configuration (plus multiple flashings) to dynamic programming capabilities that allow many computations with increasing high-level abstractions [98].

The use of general-purpose languages for IoT is supported by multiple libraries handling specific IoT features (General Purpose Input/Output - GPIO -, communication protocols, etc.), and IoT plugins extending development environments. The top three general IDEs following their adoption by the IoT community are [28]: Eclipse desktop, Visual Studio Code, and IntelliJ. Besides, other vendor-specific and board-specific tools carve a niche: ESPlorer (for ESP8266 programming with lua and python), Android Studio, Thonny IDE (for micropython programming), Eclipse Orion.

4.3 Model-Driven Tools

The literature pays considerable attention to MDE works for the IoT domain. Malavolta and Muccini [73] and Essaadi et al. [29] survey generic or domain-specific tools. In the following, we discuss the most significant IoT domain-specific modeling languages.

4.3.1 *ThingML*. ThingML [46] is an open-source project offering a DSML, along with a set of tools for cross-platform code generation through model transformation, plugins for the Eclipse IDE, a standalone text editor, and methodological/documentation support. A first version of the platform has been released in 2012. The cross-platform code generation framework is designed for use in distributed systems with heterogeneous nodes with support for C, C++, Java, JavaScript and Arduino. ThingML generated code can be run on devices with varying capabilities and operating systems: windows/linux servers, Rasberry Pi, ESP32... It is intended for a hub-based system but can be considered for cloud use in a client-server architecture. Unlike many DSMLs, the ThingML language has a textual descriptive syntax allowing users to model: (1) Things, for the structure of the system components with asynchronous message interfaces; (2) State machines, with unified modeling language (UML) state-charts-like configuration files describing the components (things) behaviors and their interactions. Things communicate in an asynchronous fashion ; (3) Events, with an imperative action language (platform-independent) for event processing in an (Event-Condition-Action) fashion.

A multi-platform code-generation framework enables model transformation into target languages such as Java, JavaScript, C, Arduino. The generated implementation contains the executable code and configuration files for different target devices. It offers wide support for devices and communication protocols, and allows for the definition of custom data types and structures that can be used to represent data in a variety of formats (XML, JSON,...). In addition, ThingML provides a rich toolbox, including APIs (Java API, Rest API) along with Eclipse IDE SDK allowing developers to interact with the generated model-based generation code. While the ThingML DSL is purely textual, the Eclipse SDK provides a corresponding graphical modeling tool and a runtime environment for ThingML-generated code.

The ThingML is built using the Eclipse Modeling framework, which allows flexibility in extending the system as in [78], where the authors present an extension of the language to support things with data analytics features. To support different IoT domains, ThingML can be considered as a generic tool, since it provides a set of built-in features and constructs that can be used to define the behavior of IoT components, regardless of the specific domain they are being used in. The tool is not restricted to fixed hardware or network specifications.

ThingML has been validated in multiple use cases with different platforms, but remains a fairly technical DSML intended for users with technical background and IoT architecture knowledge to fully make profit of the code generator.
4.3.2 Midgar. Midgar [38, 39] is an IoT platform offering several services, including a DSL and a graphical editor to interconnect web services and create applications for heterogeneous devices. Midgar aims to support interoperability by interconnecting objects through a Midgar server with REST services without getting to manage the technical sophistication specific to each object. The platform consists of 4 layers: Process definition, service generation, data processing, and object management. Only the process layer is intended for user interaction. The latter defines connection processes on objects via MOISL, the DSL developed with the HTML5 canvas and JavaScript generating serialized XML models. Service generation achieves model transformation into the target application language. The platform offers code generation into Java for desktop or mobile application and C for arduino/android devices. Things or objects implement the messaging interfaces with the Midgar server (REST service).

The platform evolved by offering several model-based programming languages. The primary contribution includes Midgar Object Interconnection Specific Language (MOISL), a language with graphical notations enabling the definition of heterogeneous and ubiquitous object interconnections. It allows the user to describe how each object behaves with its network and the Midgar server and considers security aspects. A textual DSL with the same purpose has been defined later, as Midgar Use Case Specification Language (MUCSL) [40], which provides development support of automation routines expression using a natural language (English-like) syntax. This layer does not support the automatic generation of IoT applications and requires the explicit definition of the logic of the objects by the users. In recent work [39], the same authors define Midgar Object Case Specification Language (MOCSL) with a graphical interface to facilitate the creation of smart objects and the generation of data-processing applications by users with a little technical background. A drag and drop interface allows to define communications between different connected objects.

EXAMPLE 4.1. Consider the use case defined in Section 2. Three objects can be connected to the Midgar platform:

* a temperature sensor, registered under the ID `tempSensorXXXX01` (numerical values);

* a carbon dioxide sensor, registered with the ID `carbonDioxideYYYY01` (numerical values);

* an actuator for automatic window opening, with the ID `windowAutoZZZZ01` (0 for close and 1 for open).

The application logic can be defined using the graphical notation of the platform or the textual DSL (MUCSL), where a conjunction of conditions can be expressed and verified (here, temperature above 25 degrees and CO2 levels above 350 ppm) to trigger an action on the connected device (window actuator).

```
When [the] tempSensorXXXX01 [is] greater than 25
or [the] carbonDioxideYYYY01 [is] greater than 350
then [the] windowAutoZZZZ01 [to] 1
```

<caption>Listing 1. Example of MUCSL rule definition</caption>

4.3.3 FRASAD. FRASAD framework for Sensor Application Development [79] is a development framework allowing users to create IoT applications by defining a multi-layered node-centric model. It focuses on in-board sensor computation providing a simple alternative to program sensor events reading, alerts and actions. Communication within a sensor network is handled through two communication protocol support: unicast and broadcast protocols. FRASAD enables developing applications while hiding hardware technical specifications related to the nodes. This abstraction is possible thanks to the definition of two layers: the application abstraction layer (APL) and the operating-system abstraction layer (OAL). Accordingly, the platform uses model-driven architecture principles at three distinct layers, supported by a DSL definition. At the application layer, the visual model operates on rule-based programming patterns to describe the sensor nodes and their local behaviours independently from their technical specifications. The model is stored as an
XML file. A code generation tool automatically transforms the user-defined models to generate platform-independent applications at the OAL. The latter is then mapped and compiled by OS-specific C compiler into binary code. The rule DSL language allows for a three parts rule definition: Select-Clause, Processing Clause and ActionClause. As code generation is a two-step process, device-specific code might deviate from the user-defined model. This gap can be explained by the pipeline of mappings applied to get a platform-specific code. Additionally, the platform focuses on a fixed number of devices and operating systems (Contiki OS, TinyOS) and protocols, limiting the applicability. To the best of our knowledge, the platform development has not been perused, and no code repository has been maintained.

#### 4.3.4 WoX
Web of Topics (WoX) [13, 70, 71] is a multi-layer IoT platform first introduced in 2015, that aims at simplifying the design of user-centric applications by adopting a model-driven approach. It extends the Web of Things (WoT) by focusing on the functional aspects of the system and this despite the object's hardware complexities and their diverse communication protocols. To overcome the technical complexity of the WoT, WoX introduces an abstraction layer hiding heterogeneous technical details of things in a conceptual model. The WoX model is built around the "topic" concept: a topic describes the feature values (perceivable, measurable characteristics) of entities of interest. It is a representation of a physical or virtual sensor/actuator. The topic is identified by a uniform resource identifier (URI) designating it and its location. An IoT entity is defined by the couple (topic, role), given that a role expresses the entity's technological and collaborative status. Unlike many IoT tools addressing the development within a single IoT architecture layer, WoX defines three variants, one for each layer: WoX cloud, WoX local (L-WoX) for mobile use, and eMbedded WoX (M-WOX), for constrained objects embedded. Corresponding adapted APIs are presented: Java/Python/.NET APIs, Android/iOS or C/C++ for constrained objects. To homogenize modelling, WoX middleware (Hardware Abstraction Layer) exhibits an exchange format based on the publish-subscribe model and provides a set of adapters for physical and virtual communication protocols. Besides, the tool is structured to manage the flow of events issued by physical or virtual environments through adapters connected to a REST service to several web technologies and a Linked Open Data (LOD) API for the semantic transformation of topics into a semantic data model.

The platform has been demonstrated via prototypes such as the airport short-stay parking service or City4Age, an application for the e-monitoring of elderly people's behaviors [34]. In a recent work [72], WoX authors introduce WoX+, extending the original model by integrating machine learning for automatic automation rules discovery. Rules are created by mining users' habits in smart environments.

#### 4.3.5 UML-Based Tools
Other works adapt the use of the UML language to build visual interfaces enabling users to express the structure and behavior of IoT systems. Eterovic et al. [30] propose a visual programming modeling language based on UML. The base elements of the model refer to "things" (sensors/actuators, physical or virtual), and their communication interfaces describe data flows. The things compose hierarchical subsystems with input/output notations. Even if the language is designed for non-technical users, the authors propose an extension using advanced UML notations for developers to achieve more complex tasks. UML4iot [100] borrows some UML constructs to create customized profiles that address IoT systems' challenges, namely heterogeneity and distribution. The profile is used within a wrapper to define an IoT-compliant layer, providing cyber-physical manufacturing-system components with capabilities to integrate IoT architectures and thus take advantage of IoT protocols (LWM2M).

## 4.4 Mashup Tools

In the IoT era, the need to compose services and expose them in a uniform user-centric fashion has arisen, and the mashup principle has gained extensive attention. New challenges appeared regarding mashups' use for the IoT, given
the heterogeneity of devices and resources to integrate. The Web of Things (discussed in Section 3.1) tackles these challenges by allowing users to create applications based on a uniform semantic data model for heterogeneous sources (things) integration and combine the use of web services and standard technologies (connecting functional islands). Such a platform is possible thanks to the availability of communication protocols and REST APIs. Mashup tools are helpful to speed-up application prototyping and are suitable for non-technical users or domain experts to quickly create and deploy new IoT applications. They often leverage visual interfaces to encode rule-based and flow-based programming patterns, describing message flows between components as resources producing data or web services. Some examples of widespread IoT mashup tools are discussed in the following.

### 4.4.1 Node-RED
Node-RED<fnref n="5" /> is a mashup tool created by IBM for IoT applications’ development with the aim to wire together IoT components. In 2016, Node-RED was transformed into an open-source JS Foundation project. The tool offers a browser-based drag-and-drop graphical UI for building and editing event flows through nodes, reducing the size of code writing for users. A Node.js runtime supports the application deployment of node-centric event-driven programs, taking advantage of the built-in event model and native support for JavaScript. A node characterizes a hardware device, a software API, or a service. The network of nodes is managed by a node package manager (rpm) with an extensible set of components, where each behavior is described in JavaScript and its structure in HTML.

The extensible palette of nodes includes function nodes (trigger, execute), network nodes (MQTT, HTTP, etc.), parser nodes (for CSV, XML, HTML, and so on), etc. The interaction between nodes is constructed through links, capturing events transformation, and each process is a black box, autonomously and asynchronously transforming data from the input nodes to some output result for the target node. The created flows can be stored for reuse in JSON format. When a user deploys a Node-RED flow, the runtime generates and executes the underlying JavaScript code based on the connections and configurations explicit in the visual flowchart.

Node-RED is platform-agnostic tool written in JavaScript; it can be deployed on small devices due to the lightweight nature of Node.js, supporting edge-computing scenarios as well as cloud devices, which guarantees a full-IoT system-development process. Another advantage of Node-RED is the possibility to integrate different technology libraries (databases, MQTT communication protocol, etc.), strengthening interoperability and extensibility. When a user deploys a Node-RED flow, the runtime generates and executes the underlying JavaScript code based on the connections and configurations made in the visual flowchart. One drawback of the open possibilities in flow definition (unique or multiple flows with different node settings) is the difficulty of fault detection and system behavior fixing.

Many works extend Node-RED with additional features such as voice command interface [85] or adapt it to specific uses cases [106]. Glue.things [61] is built on top of Node-RED, providing user-friendly predefined trigger and action nodes. In glue.things, a flow editor is associated with a master device that controls all the nodes in a local network. The master device can be deployed on the cloud allowing service compositing at this level. Node-RED is built to run on a single device. Distributed Node-RED [9, 41] proposes a distributed version to run in fog-based architectures.

Ji et al. [53] propose an extension of Node-RED with a module running as a WoT servient. It combines REST APIs and IoT devices as web things. The Thingweb node-wot<fnref n="6" /> is used as a runtime environment on the Scripting API. A top layer implementing WoT Thing Description (TD) allows Web things (sensors/actuators) to interoperate, exposing their properties, actions, and events. Sensing data are streamed in a chat channel, and activated triggers are reported to users

<footnote n="5">⁵Node-RED, https://nodered.org/. Accessed: 2024-06-27.</footnote>

<footnote n="6">⁶Thingweb node-wot, https://github.com/eclipse/thingweb.node-wot. Accessed: 2024-06-27.</footnote>
as WoT events. Authors claim that Node-RED enriched with specific WoT semantic description and servient-behavior integration represent a good candidate for a standard WoT implementation.

**EXAMPLE 4.2.** *Node-RED can be used for both automation scenarios in building and agriculture, presented in Section 2. To showcase an automation program for smart irrigation, we assume a minimalist hardware setting with a moisture sensor and a water valve, both connected to an Arduino microcontroller. An Arduino-node can be installed into the palette manager*

```
npm install node-red-node-Arduino
```

<caption>Listing 2. The installation command for NPM arduino node</caption>

*This node enables communication with the Arduino through the serial-in node for data reading and the serial-out node for command sending. Moisture data received is processed (through function nodes) to check whether the moisture level is below crop-watering recommendations. An Arduino-node can be installed into the palette manager to enable communication with the Arduino through the serial-in node, for data reading, and the serial-out node, for command sending. Moisture data received is processed (through function nodes) to check whether the moisture level is below crop-watering recommendations. The flow can also integrate available web services for weather data, such as the OpenWeather API, accessible via HTTP requests. To this aim, an inject node allows triggering API requests at a certain defined frequency, while the HTTP node is set to GET weather data. A function node filters data (JSON) for rainfall forecasts. The data obtained from the API can be combined with moisture-sensor data to prevent valve actuation if rainfall is expected.*

**4.4.2 Dynamic Dashboard.** Vanden Hautte et al. [102] provide a dash-boarding tool enabling the visualization of RESTful web things (sensors) and available data-aggregations services, abstracting sensor settings. The tool uses semantic reasoning on things metadata to suggest a suitable visual interface composed of single-service widgets. The dashboard interface is dynamically customized given the events picked by the user. The dynamic dashboard provides real-time data and is supported by three core services: (1) It subscribes to a data streamer (Kafka Stream) to enable access to data and apply filters to get relevant event-related values. The output is then transmitted to widgets for visualization. (2) It interacts with a broker, which stores and provides the user interface state. It hosts the semantic reasoner in charge of suggesting appropriate widgets given things semantic metadata. (3) WoT compliant gateway API discovers things, and the semantic annotations explain things capabilities.

**4.4.3 WoTKit.** is a web-centric lightweight Java platform for managing IoT things and their real-time events. Things can be grouped into systems (and subsystems), identified as modules that communicate through wires in a flow-based fashion. The combination of modules and wires creates pipes inspired by Yahoo! Pipes [33]. WoTKit web application has both visual and textual user interfaces. The main visual user interface is a JavaScript dashboard combining widgets that enable pipe creation, start, stop and editing features, as well as navigating through different user pipes. Besides, users can extend the built-in features by defining new modules' scripts in Python to integrate into pipes. A central sensor gallery allows reusing created sensors or discovering other public users' shared sensors added to the system. The gallery also stores meta-data describing the sensors, their location, and data output. WoTKit serves as a sensor-data aggregator for processing, with the generation of control messages to actuators and visualization features. Additional sensors can be registered to the platform through gateways definition. New sensor information are posted through the REST API by providing a description file in supported formats (JSON, CSV, KML, HTML). An advantage of the WoTKit architecture is the separation between wires and modules; modules can have many input wires enriching program patterns. The processor can handle many flows for a single user.
4.4.4 *A-Mage*. A-Mage, an Atomic Mashup Generator [63], is a tool enabling Atomic mashup generation based on Thing Descriptions files and a possible set of constraints and filtering conditions expressed by an end-user. All candidate atomic mashups are automatically generated, enabling user evaluation through a sequence diagram. The user picks the best fit atomic mashup (or adjusts constraints to get a new one), achieving the desired system behavior, and generates an executable code based on the WoT Scripting API. The end user constraints are expressed in natural language and then processed and used to generate semantic filters restricting the number of things involved in the WoT system, their types, contexts, TD annotation, or annotation availability. The tool has been tested against agriculture, industrial and smart home scenarios, with reasonable generation time and good response to user's constraints.

**4.5 End-User Development Tools**

The following sections overview some examples of widespread EUP platforms. Detailed comparative studies of IoT end-user development tools are reported in [66, 81, 92].

4.5.1 *Trigger-Action Based Approaches.* This programming approach uses event-condition-action (ECA) rules [19], with visual user interfaces. The user specifies an expected system behavior through if-then statements, to automate actions following some trigger occurrence.

IFTTT. IF This Then That<fnref n="7" /> is a widely-used IoT platform launched in 2011, and represents the most frequently used tool of event-action programming [76, 101]. IFTTT presents a web-based interface (and a mobile app), enabling users to define programs through automation scripts called *applets* or *recipes* that connect services, websites, and physical devices. Each applet encodes the automation logic, i.e., a trigger-action rule "on trigger do action", such as turning off the light when someone leaves the room or sharing stats data on Twitter following a smartwatch notification. A trigger is an event produced by a connected service (ingredients data) as the sensing data output, while actions can be executed by physical devices or web applications.

IFTTT enjoys a large community thanks to its user-friendly interface and support for trending use cases such as home automation [76]. This led to many research works and products extending the platform with support for voice assistant commands [65], home automation extension [103], or secure authentication mechanisms [7]. The platform owes its popularity to the simple means for creating automation rules, which in contrast makes for a significant expressiveness limitation. Tasks only include rules with a single action per trigger, preventing the composition of rules and, therefore, the expression of complex scenarios. IFTTT also provides a tool called "Platform API" that allows developers to create more complex integrations. The GraphQL API allows developers to query and mutate data in the IFTTT ecosystem. The platform supports a wide range of device integrations but do not allow the use of virtual devices. A recent development of IFTTT supports the composition of actions through a "Maker" platform enabling developers to add multiple triggered actions. Similar platforms such as Zapier, Microsoft Power Automate, or recently Mozart [64] address this issue by enabling broader rule automation patterns.

EXAMPLE 4.3. *A popular use scenario of IFTTT is home automation.* Consider the air-quality monitoring scenario defined in Section 2. A minimalist hardware setting includes an ESP32 microcontroller hosting a CO2 sensor and a window actuator. An IFTTT applet defines a trigger on any available MQTT service that can get data from the microcontroller. A filter code option enables defining custom data transformation to check whether the CO2 level is above normal. A window-opening

<footnote n="7">⁷IFTTT: Every thing works better together, https://ifttt.com/. Accessed: 2022-07-13.</footnote>
command through the MQTT service constitutes the action statement. To combine a trigger recorded by a web service, such as temperature via a weather API, a query statement must be defined (only available for IFTTT Pro users).

**Zapier.** Zapier<fnref n="8" /> is a web-based workflow automation platform primarily interested in business project management. The zaps (equivalent to recipes) allow more composition rules than IFTTT [84] since one trigger can lead to a sequence of actions. The subsequent tasks are more expressive since they include filtering and data transformation on trigger data. Zapier also provides developers with support for customized service integration. Zapier exposes a REST API enabling developers to create zaps custom templates.

**Microsoft Power Automate.** Previously called, Microsoft Flow,<fnref n="9" /> provides advanced conditions and looping constructs for more expressivity. It is a workflow-management platform with web and mobile tools, offering an interface for connecting two or more cloud services to create business workflows, such as automating file synchronization, alerting, and data organization. It is oriented towards supporting Microsoft business tools integration for business task-automation scenarios.

### 4.5.2 Programming by Demonstration.

**Epidosite.** Enabling Programming of IoT Devices On Smartphone Interfaces for The End-users (Epidosite) [66] is a mobile platform for home automation leveraging a programming-by-demonstration style. A user performs operations on a real use case example to define expected system behavior. Epidosite reasons about the underlying logic to infer a generalization program pattern that can be applied to new scenarios and features later. The programming is performed through mobile, using the Android accessibility API to record user behavior when using IoT applications. The recorded scenario is then used to generate a script for further use automatically. So, the created automation tasks are sequential action-triggered rules and do not handle composition.

**Improv.** This system [18] exploits the programming-by-example approach, enabling users to compose software operating across different devices to define a common interoperable system-interaction behavior. The user mimics the interaction desired for the set of devices, and the tool transforms these parameters to extend the input-device application by connecting it to additional devices.

### 4.5.3 Visual Mobile Applications.

**Puzzle.** Puzzle [22] is a desktop/mobile platform enabling the development of IoT applications. It uses the jigsaw puzzle metaphor, where each system component is perceived as a puzzle piece exhibiting some functionality, and connections provide necessary data inputs/outputs. The puzzle diagram corresponds to a sequential automation logic, and Looping on particular triggers or actions is possible. The color code and the shape of the pieces suggest to the user what puzzles can be connected based on data types and transformation for functionality composition. The tool allows the integration of multiple hardware things and query web services, but its expressivity of the tool is limited to a predefined puzzle set.

#### 4.5.4 Tools using Natural Language.
In natural language programming, the user expresses the requirements a system should fulfill or enumerates automation rules using natural language. The constructs can sometimes be constrained

<footnote n="8">⁸Zapier, https://zapier.com/. Accessed: 2023-07-10.</footnote>

<footnote n="9">⁹Microsoft Power Automate, https://powerautomate.microsoft.com/. Accessed: 2023-07-10.</footnote>
with templates, and UIs are either textual or voice-based. Recently, advances in natural language processing (NLP) opened up avenues to a less constrained user-interaction mode, especially the transformation of voice assistants output.

*AppsGate.* AppsGate [21] is a rule-based web platform for home automation using a pseudo-natural language syntax for user interaction. A dependency graph and timeline depict home devices and associated services, enabling users to specify control patterns in a syntax editor with simple predefined constructs. Visual notations and color codes assist the user in identifying allowed syntax, checking rule completeness extent, and understanding the system's state. The rules define how automation actions are associated with the environment state or occurring events. The simplified syntax does not allow for rule composition or operating changes on the graph devices or the timeline of events.

4.5.5 Voice Assistants. Voice-activated devices are increasingly integrated into various automation fields, thanks to their growing hardware capabilities and the advances in artificial intelligence. Voice assistants are increasingly smaller, cheaper, and equipped with broader skills. Leading manufacturers are marketing powerful assistants: Alexa, Siri, Cortana, Google Assistant. Beyond acting as high-level interfaces for getting weather data, the progress of natural language processing and the richness of human-interaction logs offer a learning base for programming control behaviors through IoT systems. Most of the applications of this programming style have been applied to smart home scenarios, which remains one of the most end-user-centric IoT applications, with a need to simplify access to programming.

Early uses of voice assistants extend visual programming platforms such as Node-RED or IFTTT with voice user interaction, enabling humans to get natural-language answers. Rajalakshmi and Shahnasser [85] combine the use of Alexa and Node-RED to offer complex automation-rules definition for home-environment control through the platform and the use of Alexa to simplify the user awareness of the house state. However, in the cases mentioned above, the voice-activated device does not operate to trigger or configure rules but is limited to query answering.

Other propositions allow users to trigger predefined rules in IFTTT via voice [58, 60]. The tool expressivity is limited to the IFTTT applets, and the voice can be used only to activate the rules. A similar prototype has been defined by [62], which integrates Google Assistant to an Android application using MQTT, Node-RED, IFTTT and Mongoose OS. The event-action rules are first defined in Node-RED and can be triggered through Google Assistant. TAREME (Trigger-Action Rule Editing, Monitoring) [74] allows triggering and defining rules through Alexa.

Almond [14] is an open-source platform<fnref n="10" /> that defines a textual domain-specific language named *Thing Talk*, for connecting IoT devices, abstracting their technical specifications and enabling a pseudo-natural language for rules definition. A knowledge-base *Thingpedia* includes natural language interfaces and open APIs for IoT devices and services used for system building. The Almond Virtual Assistant is a Java/JavaScript-based mobile application running a web service for voice-to-text transformation enabling users to formulate Thing Talk constructs vocally.

# 5 DOMAIN-DEDICATED IOT PLATFORMS

In this section, we discuss IoT platform providing domain-specific functionnalities: building automation (Subsection 5.1) and smart agriculture (Subsection 5.2).

## 5.1 Building Automation

The earliest form of building automation goes back to the 1960s [26] with the use of digital computers to automate heating and ventilation in large commercial buildings. With the evolution of control systems to handle additional

<footnote n="10">¹⁰Stanford Almond, https://github.com/stanford-oval/almond-gnome. Accessed: 2023-04-30.</footnote>
automation aspects such as lighting, security, or electrical equipment, the concept of Building Automation Systems (BAS) has emerged. A BAS is a distributed system integrating all building automation services, aiming for energy optimization and user comfort. The rise of IoT technology has accelerated the development of BAS by enriching the lower perception layer with new sensors, actuators, and connectivity protocols, enabling the definition of autonomously triggered routines and opening up the spectrum of use cases. An increasing number of building management system deployments integrate IoT devices to create so-called *IoT-enabled building management systems*. They enable efficient and remote building monitoring features with cost optimization [10, 16].

IoT platforms in smart buildings support the centralization of management systems and offer multiple features such as data collection and visualization, data analytics, and third-party systems and web services integration. There exist a large panel of home automation platforms with varying technical characteristics [37], from device and protocol support to user interfaces and the application layer. The following discusses platforms dedicated to home automation.

### 5.1.1 *Open-source platforms.* We survey the most important open-source solutions below.

**OpenHAB.** Open Home Automation Bus is an open-source home automation platform designed to integrate a large panel of home devices and different systems services. The project was launched in 2010 and became an official Eclipse Foundation project in 2013. OpenHab is a cloud-agnostic platform written in Java that operates on various operating systems and can be deployed on either classical computers or embedded boards such as Rasberry Pi, Beaglebone Black, Intel Galileo, or any device running Java Virtual Machine (JVM). Compared to other open-source solutions, it has been tested on a large number of ARM-based single board computers. The platform is built as a modular software architecture following the OSGi framework,<fnref n="11" /> where modules called “bundles” are implemented separately and communicate via a publish/subscribe architecture.

The physical layer of the OpenHAB system, named Things, manages over 400 bindings (plugins), integrating more than 3000 entities (things). A “thing” corresponds to a physical device identified and described by a thing-configuration file detailing its items and channels. The latter represents the thing’s exposed capabilities. An “item” is the virtual representation of a thing whose state can be modified by the application commands. There exist 14 possible items that can be linked to a range of channels for event handling. The set of supported things is extensible: device or system integration can be achieved via binding definition, extending the thing handler Java library.

In addition to physical things, a set of add-on bundles increase the core services with external systems or services. The cloud connector enables connecting the local OpenHab runtime to a cloud instance to use advanced features, including secure remote access, push notifications, or access to web services requiring OAuth,<fnref n="12" /> such as IFTTT or Google Assistant. Additional system-integration add-ons cover HomeKit, Philips Hue, NEEO, ImperiHome. The platform also integrates a REST API and enables event monitoring and historical data management through bindings integrating InfluxDB and Grafana open-source time-series databases and visualization tools.

Different user interfaces are available on both mobile and web for programming automation routines. OpenHAB defines a rule DSL, based on Xtend, that allows using a simplified textual syntax for rule definition. Since rules follow an event-condition-action (ECA) programming style, actions are automatically triggered by time or sensor-based events. DSL-based rules can be edited via a graphical rule editor and are ultimately parsed into actuators' commands. Technically trained users can access full configuration and automation routines' options thanks to the supported scripting languages: Python, JavaScript, Groovy, and Ruby.

<footnote n="11">¹¹Open Service Gateway Initiative, https://www.oci.org/. Accessed 2023-07-10.</footnote>

<footnote n="12">¹²Open Authorization, https:///2/.</footnote>
Version 3 of OpenHAB, published in 2020, brings significant changes to the platform. A semantic model enriches automation rules with semantic actions definition. The model relies on a modular ontology (location, equipment, point, property) that users can employ for modelling their physical environment. In addition, the user interface is reorganized with page definitions, including user-defined widgets. Finally, a blockly<fnref n="13" /> rule engine has been integrated, easing rule definition for non-technical programmers through a fully visual UI. OpenHAB enjoys increasing popularity and has gathered an active community,<fnref n="14" /> which supports its adoption along the different versions.

Note that while OpenHAB is open source, it operates under the Eclipse Public License (EPL), which requires users to attribute its use in commercial products.

*Home Assistant.* <fnref n="15" /> is a home-automation platform developed in Python that enjoys worldwide popularity; it supports interoperability with a wide range of plugins allowing the integration of various devices and protocols (currently over 2200). Home Assistant is a free software backed by a strong community, assisting users with multiple topics and providing extensive documentation. The platform makes privacy and user control a priority; it does not depend on cloud services to operate. However, cloud-service integration with reinforced authentication is provided to ensure remote access and support voice assistant interfaces such as Alexa. As for OpenHAB, the core component of the architecture is an event bus handling event-based components’ interactions. End-users program automation routines with ECA rules via a graphical dashboard generating YAML files. Developers can create advanced services using Python scripting integration or REST and WebSocket APIs. The configuration of the dashboard, automation rules, devices and concepts is mainly achieved through YAML configuration files, which may turn out to be heavy for beginners.

*Jeedom*. <fnref n="16" /> is a home-automation platform developed in 2014, written in PHP and operating on various Linux distributions. The platform is standalone, providing a user-friendly and flexible interface thanks to numerous customization options via widgets. The platform supports several devices integration, protocols and services via official plugins or third-party plugins. The Jeedom market counts around 600 plugins, but some are not free. The definition of new plugins is possible in PHP, based on provided templates and JSON configuration files. In addition to the visual dashboard, automation rules can be expressed via scripted plugins written on Python, PHP, Shell or Ruby. The documentation of the platform is provided in different languages. One drawback hindering the expansion of the platform is its focus on French users, since the community forums are mainly written in French.

*IOBroker*. <fnref n="17" /> is a node.js-based home-automation platform freely available and running on multiple operating systems. The platform has a modular architecture and currently provides 450 adapters implementing devices, protocols and services integration. IOBroker Pro is a paying cloud service proposed by the platform to support remote access or interfacing voice assistant services such as Alexa or Google Home. Developers can create custom JavaScript code for home automation using VSCode<fnref n="18" /> or Webstorm<fnref n="19" /> IDEs.

*DomoticZ*. <fnref n="20" /> is a lightweight home-automation system first released in 2012, written in C++. It runs on different operating systems and is adapted to low-resource devices. All things connected to the platform interact through MQTT.

<footnote n="13">¹³Google Blockly, https://developers.google.com/blockly. Accessed: 2023-07-10.</footnote>

<footnote n="14">¹⁴OpenHAB community, https://community.openhab.org/. Accessed: 2023-04-18.</footnote>

<footnote n="15">¹⁵Home Assistant, https://www.home-assistant.io/. Accessed: 2023-04-24.</footnote>

<footnote n="16">¹⁶Jeedom, https://www.jeedom.com/. Accessed: 2023-04-18.</footnote>

<footnote n="17">¹⁷IOBroker, https://www.iobroker.net/. Accessed: 2023-04-24.</footnote>

<footnote n="18">¹⁸Visual Studio Code, https://code.visualstudio.com/. Accessed: 2023-07-10.</footnote>

<footnote n="19">¹⁹WebStorm, https://www jetbrains.com/fr-fr/webstorm/. Accessed: 2023-07-10.</footnote>

<footnote n="20">²⁰DomoticZ, https://www.domoticz.com/. Accessed: 2023-04-24.</footnote>
The ECA rules can be defined using Blockly or through scripts. Supported languages are Lua, Python, shell and a DomoticZ DSL called DzVents. DomoticZ has an E-vehicle framework enabling the integration of electrical vehicle systems from, e.g., Tesla, Mercedes or KIA to read sensor data and automate in-car temperature or door locks.

5.1.2 Proprietary solutions.

Habitat Home Hub.<fnref n="21" /> is an automation system introduced by the Habitat Elevation company in 2018. It is designed with a strong focus on data privacy and security by promoting user control of data and devices. It runs locally without requiring any data transfer and uses industry-compliant encryption protocols to secure communication between home devices and Habitat Hub. Habitat applications are written in the Groovy scripting language, running on top of the JVM. JavaScript support is available, enabling custom automation and device integration. Event-driven automation is achieved through a rule machine, a powerful built-in tool offering complex automation scenarios. Events handling considers events issued by devices, hubs, networks or that are time-related. Creating new rules is available for advanced use through the rule machine API or HTTP requests. The rule machine enables complex rule definitions, combining multiple conditions and triggering complex device actions. Beginner end users can set simple actions using the simple automation rule, which provides a user-friendly interface with predefined rules that users can easily configure. On the physical layer, supported devices includes z-wave, ZigBEE-enabled and LAN-based connected devices, and virtual or cloud devices. It does not support Bluetooth-connected devices.

HomeSeer.<fnref n="22" /> is a home-automation platform marketed by Home Seer Technologies since 1999. The company also sells controllers and hubs compatible with its software solution, with variable capabilities and prices, which allow automation routines to run across multiple devices. In addition to its hardware offer, including sensors and actuators, the platform is popular for its extensive panel of plugins (currently around 400), free or not, allowing interoperability with several cloud systems and services and third-party devices and protocols. The Home Seer products are z-wave-plus certified, focusing on lighting automation, door-locking systems, and water management through valves and controllers. In addition, Home Seer stands out for its integration of video surveillance systems and anti-intrusion functionality. The platform works locally and autonomously, although it also provides a cloud solution to interface the use of voice assistants and IFTTT services. Pricing plans vary with the number of devices and plugins required for the use case.

Apple HomeKit.<fnref n="23" /> is a home-automation system that allows users to automate their homes by controlling compatible devices, virtually defined as accessories. The system is available through an application called Home, running exclusively on Apple operating systems (IOS, iPadOS, macOS). Accessories can be integrated into the smart-home instance by automatically discovering network-connected devices (Wifi, Bluetooth). In addition to single-device control, the platform allows the definition of complex automation rules, defined as scenes where combined actions on multiple accessories can be triggered if a specific event condition is fulfilled. A set of accessories can be declared as physically belonging to the same room in the home layout. Events are either time-based or sensor-output data. The platform provides a multi-control option where multiple users can share the automation of the home, defining distinct preferences. User's geolocation data are then used to adapt home scenes according to the resident's presence. To guarantee remote access, an Apple device (Apple TV, home pod, iPad,...) must be configured as a HomeKit hub. The hub also enables integrating additional accessories such as matter-compatible devices [2] or cloud-based services

<footnote n="21">²¹Habitat Home Automation, https://hubitat.com/. Accessed: 2023-04-24.</footnote>

<footnote n="22">²²HomeSeer Home Automation, https://homeseer.com/. Accessed: 2023-04-24.</footnote>

<footnote n="23">²³Apple HomeKit Home Automation, https://developer.apple.com apple-home/. Accessed: 2023-04-24.</footnote>
such as the Siri assistant for voice commands. To enlarge the range of accessories compatible with the platform, the open-source project homebridge<fnref n="24" /> is a node.js-based solution that emulates the iOS HomeKit API. It defines a set of plugins to interface third-party device APIs with the HomeKit platform. Developers aiming to integrate new accessories or communicate with HomeKit in their applications might consider the HomeKit Accessory Development Kit (ADK) framework,<fnref n="25" /> using the supported programming languages Objective-C and Swift.

*Other solutions.* The following solutions are provided by large technology companies, with scalability features to handle large commercial buildings deployments:

* Samsung Smart Things, which supports a wider range of protocols (ZigBEE, Z-Wave, Wi-Fi), making it suitable for complex and diverse IoT ecosystems in large commercial buildings;<fnref n="26" />

* Amazon AWS IoT, which offers extensive scalability and integration with other AWS services, providing robust cloud-based solutions for large-scale industrial and commercial IoT deployments;<fnref n="27" />

* Google IoT, which provides powerful data analytics and machine-learning-based services;

* and Microsoft Azure IoT, tailored for enterprise solutions, offering advanced security, scalability, and integration with a wide range of enterprise applications.<fnref n="28" />

Note, however, that these solutions might be less suited for new IoT users with limited budget and targeting small deployments.

## 5.2 Smart Agriculture

Agriculture represents one of the application fields where the integration of IoT technologies records the most significant growth. According to [83], the IoT market in agriculture has been valued at USD 12.5 billion in 2021 and is expected to reach 28.56 billion by 2030. The rapid increase in the world population demands an increase in agricultural production while paying attention to the ongoing climate and energy crises. These challenges require optimization strategies for improving crop yield and monitoring resources such as water and energy. IoT provides effective solutions to support the automation of several agriculture tasks [59] such as precision agriculture (e.g., for irrigation, fertilizer products, greenhouses), environmental management (e.g., for pollution, water reserves, weather conditions), crop monitoring (e.g., for animal management, product quality, soil health), horticulture via soil control or machinery.

The introduction of dedicated IoT platforms for agriculture is still recent [57] compared to other application domains such as smart cities. Emerging projects aim to handle the complexity of the outdoor configuration, deliver (multi) task-oriented decision support tools where farmers can define automation routines, collect data and get analytics to make informed decisions towards performance improvement. We briefly describe below the most relevant propositions.

### 5.2.1 *Proprietary solutions.*

*CropX*. CropX<fnref n="29" /> is an agronomic farm management platform that leverages mashup principles to enable farm data analytics and decision making. It includes a web UI and a mobile application to allow farmers access to a personalized dashboard. The dashboard displays field and environment data recorded by CropX sensors or online cloud services.

<footnote n="24">²⁴Home bridge, https://github.com/homebridge/homebridge. Accessed: 2023-04-30.</footnote>

<footnote n="25">²⁵Apple HomeKit Accessory Development Kit, https://github.com/apple/HomeKitADK. Accessed: 2023-04-30</footnote>

<footnote n="26">²⁶Samsung developer, https://developer.samsung.com/smarthings/blog/en/2021/10/21/accelerating-home-automation-at-smartthings-with-rule-engine</footnote>

<footnote n="27">²⁷AWS IoT, https://aws.amazon.com/fr/iot/. Accessed: 2024-06-27.</footnote>

<footnote n="28">²⁸Azure IoT, https://azure.microsoft.com/fr-fr/solutions/iot. Accessed: 2024-06-27.</footnote>

<footnote n="29">²⁹CropX, https://cropx.com/. Accessed: 2023-03-28.</footnote>
Data insights cover underground indicators on the soil state, such as temperature or moisture, and additional data analytics on satellite images, topological maps, or meteorological forecasts. Further farm management operational statuses are integrated thanks to machinery APIs, or farmer's feedback. In addition to data visualization, the farmer can apply machine learning models to her data to obtain custom recommendations about irrigation planning, crop protection against diseases, effluence irrigation, and fertilization task. The pre-trained models support a large set of crops and are designed to increase the crop yield while ensuring water and energy saving. While supporting various crops and soil types, the platform does not allow end users to customize model definitions or service integration. As the platform is proprietary, its use leads to various underlying costs, the first of which comes from acquiring the hardware set compatible with the software solution. The sensors the company markets transmit real-time soil indicators, including soil moisture, temperature, and electrical conductivity, at variable depths. To target farms with an existing hardware installation and interoperate with additional connected devices as weather stations or rain gauges, CropX sells a telemetry device to provide connectivity to the platform. In addition, access to cloud services and ML models requires a monthly or annual subscription, and additional fees can be charged for in-person technical support services.

*John Deere Operations Center.* John Deere Operations Center<fnref n="30" /> is a cloud-based platform provided by the John Deere company, which specialises in the manufacturing of agriculture equipment. The platform offers a set of tools to support farm management, including data collection and integration, data analysis and visualization, and decision support through recommendations and notifications. The platform is also available through a mobile application enabling remote management on several tasks, primarily machine-based: machine operating and maintenance status, data analysis and recommendations for yield improvement, and collaboration features with agronomists or support teams. The platform does not allow for automatic control of machinery or field actuators, except for remote settings updates on the machines. Although the platform can integrate other brands' equipment, most features are limited to its ecosystem, restricting its interoperability.

*AgriWebb*. AgriWebb<fnref n="31" /> is a cloud-based platform with web and mobile interfaces dedicated to farm management with a primary focus on livestock management, including cattle and sheep. Livestock management covers animal activity, health and insurance records, chemical and feed inventory (animal treatment, water stocks), and grazing activity management. The platform enables activity planning based on financial forecasts by integrating financial market data to ensure profitability and efficiency. AgriWebb has a GraphQL open API and supports multiple data import and export options and formats. Sensing activity is limited to vendor-specific items through Bluetooth and wifi. The solution is designed for livestock management and offers limited features regarding crop management (only grazing).

### 5.2.2 *Open-source solutions*.

*The Smart Water Management Platform (SWAMP) project.* SWAMP<fnref n="32" /> develops an IoT-based solution for smart irrigation to improve water saving [24, 56]. It pays particular attention to security challenges raised around farmers' data management. The project has four pilots in three countries sharing the same technical architecture but covering different crops and soil characteristics, with the purpose of reinforcing the irrigation and water distribution models. The platform is designed as a modular framework, including several components interacting according to the microservice architectural style. The modules are organized vertically following the IoT Computing Continuum [110] in five

<footnote n="30">³⁰John Deere Operations Center, https://operationscenter.deere.com/, accessed 2023-04-14.</footnote>

<footnote n="31">³¹AgriWebb, https://www.agriwebb.com/. Accessed: 2023-04-14.</footnote>

<footnote n="32">³²Smart Water Management Platform, http://swamp-project.org/. Accessed: 2023-04-11.</footnote>
layers, each corresponding to a processing step. The bottom layer consists of devices' integration and ensuring communications, while the top layer hosts application services, providing two use scenarios accessible through mobile and web applications. Farmers benefit from data insights to make informed decisions regarding their irrigation system, while water distribution actors get recommendations on distribution planning following real-time and forecast farmers' needs. All soil indicators such as moisture or temperature can be visualized in real time, and farmers can trigger irrigation by controlling probes through the mobile application.

The SWAMP framework is open-source<fnref n="33" /> and is built around the FIWARE framework,<fnref n="34" /> from which it integrates the services of the data-management layer. It also reuses the IoT FIWARE security module within its data-acquisition layer, ensuring safe data transmission and storage with reinforced authentication and data-encryption protocols. All processing modules expose RESTful APIs for communication interfacing with the application layer. SWAMP pays particular attention to semantic interoperability, by deploying within the data management layer an RDF triplestore and a SPARQL Event Processing Architecture (SEPA) [90], enabling users to store and query knowledge graphs efficiently. The graphs are defined on top of a SWAMP ontology defined to fit the platform's use cases. SWAMP stands out by offering the ability to request drone flight missions using the mobile application and visualize the path in real time. Drone missions are autonomously launched by the platform. The platform is dedicated to irrigation-related tasks, which prevents other use scenarios such as crop-disease control.

FIWARE is also the base platform of many other smart agriculture solutions, thanks to its open-source license and the diversity of the supported open standards and tools it offers for IoT application development. The FIWARE project is funded by the European Commission under Horizon 2020 program and considers interoperability within IoT applications as a primary focus. Frequently compared to W3C WoT, a WOT-FIWARE connector has been proposed and illustrated on smart agriculture scenarios in [109]. In [89], a review of smart agriculture solutions built around FIWARE is provided. The following list is enriched with recent contributions.

*Farm Management System (FMS).* FMS [55] is a cloud-based platform built around FIWARE General Enablers in a multilayer architecture. A local FMS collects data from sensors and machinery to integrate environment and soil indicators and operating status. The collected data are transferred to a cloud FMS for management, processing and application ends, including reporting and visualization. A case study on greenhouse management has been implemented to showcase the collaboration and use scenario. The platform targets multiple end-user groups allowing for collaboration among agriculture-related business domains (farmers, agriculturists, agronomists, ICT experts).

*Cropinfra.* Cropinfra [82] is a project carried out by MTT Agrifood Research Finland with the purpose of supporting farmers in the management of demanding farm operations. The platform allows end users to interconnect data and services of fields, machinery and buildings to create a custom operation-management environment. The resulting application enables farmers to get real-time insights on their farming activities and receive warnings of potential risks. Other similar platforms include Testbed [75], SME Widhoc [68], and Agricolus [42].

# 6 DISCUSSION AND INSIGHTS

The presentation of the previously discussed IoT platforms showcases the diversity of their technical characteristics and use modalities. Table 1 provides a summary of IoT platforms characteristics as identified and defined in Section 3. In this section we discuss some of the insights that one can draw from this survey.

<footnote n="33">³³SWAMP IoT Platform, https://git.rnp.br/swamp-essentials/iot-platform. Accessed: 2023-07-10.</footnote>

<footnote n="34">³⁴FIWARE project, https://www.fiare.org/. Accessed: 2023-04-11.</footnote>
<table><caption>Table 1. Summary of IoT programming platforms characteristics.</caption><thead><tr><th rowspan="2">Tool</th><th colspan="3">Programming</th><th rowspan="2">Supp Lang</th><th colspan="3">Interoperability</th><th rowspan="2">Licence</th><th rowspan="2">Domain</th></tr><tr><th>DSL</th><th>UI</th><th>Dev Approach</th><th>Toolbox</th><th>Java JavaScript C / C++</th><th>D-C-Sx</th><th>Peer-to-peer</th></tr></thead><tbody><tr><td>ThingML</td><td>UML-like</td><td>T</td><td>MDD</td><td>Eclipse-based IDE Network and Serialization plugins Port, Messages, Things APIs Eclipse SDK</td><td>Java JavaScript C / C++</td><td>D-C-Sx</td><td>Orchestrator</td><td>Open Source</td><td>Generic</td></tr><tr><td>MIDGAR</td><td>MOISL, MOCSL, MUCSL DSLs</td><td>G T</td><td>MDD</td><td>APIs</td><td>Java C / C++</td><td>D-C-Sx</td><td>Orchestrator</td><td>Open Source</td><td>Generic</td></tr><tr><td>FRASAD</td><td>Rule-DSL</td><td>G</td><td>MDD</td><td>Eclipse IDE plugins</td><td>C</td><td>D-C</td><td>Peer-to-peer</td><td>NA</td><td>Generic</td></tr><tr><td>WOX</td><td>-</td><td>T</td><td>MDD</td><td>REST APIs Linked Open Data API</td><td>Java/Python Android or C/C++</td><td>D-C-SX-S</td><td>Blackboard</td><td>Open Source</td><td>Generic</td></tr><tr><td>Node-RED</td><td>-</td><td>G</td><td>Mashup</td><td>Web visual editor Flow library, APIs NodeJS SDKs</td><td>JavaScript</td><td>D-C-Sx-S</td><td>Kernel</td><td>Open Source</td><td>Generic</td></tr><tr><td>WoTKIT</td><td>-</td><td>T</td><td>Mashup</td><td>REST APIs Sensor gateways</td><td>JavaScript, Python</td><td>D-C-Sx</td><td>Blackboard</td><td>Proprietary</td><td>Generic</td></tr><tr><td>IFTTT</td><td>-</td><td>T</td><td>EUP</td><td>integration API</td><td>JavaScript</td><td>D-C-Sx</td><td>Orchestrator</td><td>Freemium</td><td>Generic</td></tr><tr><td>Epidosite</td><td>-</td><td>G</td><td>EUP</td><td>REST API (IFTTT)</td><td>Java</td><td>D-C</td><td>Kernel</td><td>Open Source</td><td>Generic</td></tr><tr><td>Zapier</td><td>-</td><td>G</td><td>EUP</td><td>REST API</td><td>JavaScript, Python</td><td>D-C-Sx</td><td>Orchestrator</td><td>Open Source</td><td>Generic</td></tr><tr><td>Puzzle</td><td>-</td><td>G</td><td>EUP</td><td>-</td><td>Java</td><td>D-C</td><td>Blackboard</td><td>Proprietary</td><td>Generic</td></tr><tr><td>Almond</td><td>Thing Talk</td><td>G V</td><td>EUP</td><td>API</td><td>Java JavaScript</td><td>D-C-Sx-S</td><td>Kernel</td><td>Open Source</td><td>Generic</td></tr><tr><td>Appsgate</td><td>Appsgate DSL</td><td>T</td><td>EUP</td><td>Device adapters P-Openhab middleware</td><td>Java</td><td>D-C</td><td>Blackboard</td><td>Open Source</td><td>Home Automation</td></tr><tr><td>OpenHAB</td><td>Rule DSL</td><td>G T</td><td>EUP</td><td>REST APIs Bindings</td><td>Java Python Groovy</td><td>D-C-Sx-S</td><td>Kernel</td><td>Open Source</td><td>Home automation</td></tr><tr><td>Home Assistant</td><td>YAML-Based Scription</td><td>G T</td><td>EUP</td><td>Rest APIs Add-ons Web services integrations Webhooks</td><td>Python JavaScript</td><td>D-C-Sx</td><td>Kernel</td><td>Open Source</td><td>Home automation</td></tr><tr><td>Habitat</td><td>-</td><td>G</td><td>EUP</td><td>Rule machine API Hub variable API Driver/Library/App bundles Web services integrations</td><td>Groovy</td><td>D-C-Sx</td><td>Kernel</td><td>Proprietary</td><td>Home automation</td></tr><tr><td>CropX</td><td>-</td><td>G</td><td>Mashups</td><td>N/A</td><td>NA</td><td>D-C-Sx</td><td>Kernel</td><td>Freemium</td><td>Agriculture Irrigation</td></tr><tr><td>SWAMP</td><td>-</td><td>G</td><td>EUP</td><td>Rest APIs</td><td>JavaScript</td><td>D-C-SX-S</td><td>Kernel</td><td>Open Source</td><td>Agriculture Irrigation</td></tr></tbody></table>

**Programming:** DSL: the exposed DSL language (see Appendix B on DSLs), or only a Visual Programming Interface (\_); UI: textual (T) or graphical (G) notations; **Dev Approach:** the programming approach (see Appendix B on DSLs), model-driven programming (MDD), mashups, or end-user programming (EUP). **Toolbox:** types of tools that support developers' activities; **Supp Lang:** the programming languages developers can access to develop applications, extend platforms functionalities and set interoperability options. If the platform uses an internal DSL, indicates the target language for code generation. **Interoperability:** if extension point is defined and documented for supporting more devices (D), protocols (C), exchange formats (Sx) or data models (S); **Architectural Patterns:** system and components interaction paradigm (see Sec. 3.2); **License:** license of the platform (see Sec. 3.3; **Domain:** distinguishes generic, domain-oriented, and task-oriented platforms.
## 6.1 K1: Expressivity and Technical Features

The first decision factor to consider when selecting any software solution is its adaptation to the envisaged use-case requirements. For IoT platforms, adaptability relates to the capacity of the platform to support the tasks of the vertical application domain, the use case and the compatibility with the technical configuration, if set by the client organization.

Exploring platform features enables one to identify to what extent it can be exploited or what adaptation degree is necessary to maximize requirements coverage. In the smart irrigation use case, platforms exclusively dedicated to building automation are likely outside the scope. Further, agriculture-oriented platforms might sometimes focus on specific tasks such as livestock management with Agriwebb; more generic solutions such as Node-RED present a better fit, considering the extensive extensibility features, documentation and support easing the development of custom automation routines.

Similarly, data-management strategies are relevant to evaluate what insights or automation can be provided.Data-analysis frequency and decision-making process pace do not always conform to the end user's expectation nor the device's accuracy and data transmission rate. The decision to irrigate soil can be produced on a daily basis, which differs from the ventilating decision for a room recording unhealthy CO₂ peaks, which requires a faster system reactivity.

Technical deployment constraints are an additional aspect impacting the platform choice. Agricultural use cases generally have outdoor deployments covering large areas, thus requiring wide-range communication protocols (WPLAN). Outdoor systems expose devices to harsh environmental conditions, such as wind and snow, leading to unstable connectivity and possible lack of data availability. Automation accuracy in these settings relies on the platform's fault tolerance capacity, including data synchronization mechanisms. In the building automation domain, indoor deployment presents different challenges resulting from the density and complexity of the sensor network deployed in a narrow area, requiring robust scalability.

## 6.2 K2: Learning Curve

From a user-developer perspective, the learning curve of a programming tool indicates the rate at which she acquires proficiency in writing programs over time. Thus, time to proficiency impacts IoT platform choice. Several factors acting on this curve are related to the platform itself: abstraction level and toolbox, frequency of updates, documentation availability, customization degree and community strength (described later).

* Abstraction Level and Toolbox. As discussed in the DSL background (Appendix B of supplementary material), classifying a platform as belonging to a programming approach family is hard. Table 1 showcases that most IoT programming platforms provide scripting APIs to enable low-level operations control, which increases expressivity. Depending on use cases, the use of scripting APIs and, consequently, general-purpose languages remain optional if the platform's main programming interface fully covers the user's requirements. This is also valid for plugin definition APIs, service integration, templating or configuration file editing, which might require more familiarization effort.

* System Architecture. The learning curve is generally lower for centric systems with one main programming interface such as kernel systems. Peer-to-peer systems for example exhibit more heterogeneities to consider.

* Customization and Extensibility: Highly customizable platforms usually correlate with higher expressivity and complexity, leading to steep learning curves. Identifying settings matching use-case requirements demands more effort to understand possible scenarios, and the provided documentation does not cover all customizations. Examples of similar platforms are NodeRED, for the extensive number of nodes in palette and flow-composition
options, Home Assistant, relying on YAML-like configuration files, or ThingML, where the DSML supports high
customization degrees and relies on multi-language code generation. Trigger-action-based programming tools
offering compositions over rules appear to be complex while expressing advanced scenarios. The user might
need to compose numerous constructs (textual or visual) to encode a program, and quickly be confused by an
overwhelming flow of events and triggers.

*   Frequency of updates: Whether the platform is proprietary or open-source, new versions are regularly released, providing new features and enhancements addressing identified issues. This enrichment often affects users' familiarization with the platform services and sometimes involves changes in the programming operation; well-managed platforms carefully review new releases to ensure maximal stability and/or upward compatibility.

*   Documentation and Tutorials: The availability of comprehensive learning resources is crucial for lowering the learning curve. High-quality documentation is well structured, introducing platform features and characteristics and supporting users in getting started. Tutorials consist of step-by-step programming examples covering the most popular applications. Many platforms rely on GitHub to host the source code of application examples guiding users through their learning experience.

Other factors impacting the learning curve derive from the complexity of the programs to write. Automation routines involving trivial logical rules for turning off lights in an empty room can be implemented quite quickly. However, scenarios such as window opening may present higher complexity due to the presence of several triggers to be considered and the management of concurrent actions originated by parallel triggering events, duration control, or user-preference integration. Furthermore, automation scenarios where objects communicate with different protocols in an outdoor/indoor system, such as irrigation, require homogenization and data integration mechanisms with query handling. Additional web-available data, such as crop-standard recommendations or timely weather forecasts should be considered in the automation rules for irrigation. The learning curve is expected to follow complexity of use case. Finally, the human factor relates to the user's prerequisites, their skills, and the rate at which they might master the platform programming interfaces. The user profile is of utmost importance when formulating platform recommendations.

6.3 K3: Community Strength

Multiple metrics can be used to evaluate the strength of the community, with a difference between proprietary and open-source systems. Proprietary platforms communicate about their active user base, such as IFTTT, which indicates 20 million consumers (end of 2021). Open-source platforms usually make their projects available on collaborative software-development platforms like Github. GitHub provides indicators about the project's popularity by displaying the number of stars, forks, watchers or contributing users. Table 2a gives statistics (at the time of writing, mid-2023) about some open-source projects on GitHub. The number of mobile application downloads might be relevant, especially for end-user programming platforms where mobile applications provide simplified automation routines. The IFTTT Android application has been downloaded over 5 million times. Some systems lead to the development of mobile applications as a secondary UI that does not provide all system features or might be created for remote access, visualization, and alerting purposes. Some of them are fee-based, which may explain their low popularity compared to the platform's success, as for the NodeRED mobile application, namely RedMobile (1000 downloads).

The community strength is an important factor for time-to-master evaluation and the richness of the open-source
system features. IoT platforms with kernel architectures rely on multiple plugins (add-ons) to interface with het-
erogeneous devices and services, generally widely supported and developed by the community. Moreover, strong
communities and user bases provide examples of successful implementations of the platforms, which may present better guarantees of applicability for new users. If proprietary solutions such as CropX communicate mostly about the volume of deployments,<fnref n="35" /> exceeding there 10,000 fields, with statistics about their location and variety, implementation stories are more detailed with open-source platforms such as openHAB<fnref n="36" /> or Home Assistant.<fnref n="37" />

## 6.4 K4: Interoperability

Interoperability is a crucial aspect when choosing an IoT platform for programming automation applications. First, compliance with the technical constraints of the use case and the expected deployment are decisive factors for the project's viability. The system might also be regularly enriched with new devices operating via different communication protocols. Furthermore, IoT applications are frequently associated and meant to interoperate with other domain-related software solutions such as physical-security management systems, or room-reservation solutions in building automation, or inventory management and accounting solutions in agriculture.

Model-Driven programming platforms usually generate executable codes in general-purpose languages that can be executed on various environments and, in a general fashion, guarantee easier interoperability through protocols or devices code injection, either at the higher level, using modelling notations, or by directly acting on code generation. Mashups or EUP Platforms often come with a primary core of targeted hardware or software specifications and generally include a set of plugins or gateways to expand the extent of supported devices and protocols or integrate external web services to enrich delivered functionalities. Proprietary platforms sometimes require contacting the company for additional service integration or plugin definition, as for the John Deere operation centre or CropX. Apple HomeKit supports interoperability through a proprietary communication protocol, namely HomeKit Accessory Protocol (HAP), which enables making devices compatible with the software solution by acquiring and implementing the protocol. In the case of open-source platforms, the developer community enriches these software solutions using provided templates and tools. Examples of such platforms include Node-RED, which provides JavaScript templates to support custom node creation. The availability of this support is an indicator of interoperability concerns, enabling autonomous platform adaptation to other technologies. However, the number of plugins or gateways is only partially relevant, considering that several plugins are defined for the same device or protocol, leading to redundancy and impacting support coverage.

Another aspect of interoperability involves interfaces allowing the integration of web services such as IFTTT or Zapier, which define templates for new service integrations through service APIs. However, these last two examples are intended for the service provider, so that this solution is integrated into the platform. Some platforms natively include external IoT systems integrations, such as Habitat includes IFTTT or Google Home services, or Epidosite API for IFTTT integration. Scripting APIs allow users to program scripts adapting the platform's features or extending them through GPLs, usually Java (ThingML, OpenHAB), Python (Home Assistant, WoX, WoTkiT) or JavaScript (Node-RED, IFTTT), but also C/C++ (FRASAD, MIDGAR), Swift (Apple HomeKit) or Groovy (Habitat). Some examples are in Table 2b.

## 6.5 K5: Cost and Licensing

The selection of an IoT platform is impacted by its associated costs. Upfront costs of acquiring the platform significantly vary from one vendor to another, depending on their pricing models. In addition, the use of some solutions is constrained by the acquisition of platform-compatible devices. John Deere Operation Center designs its agriculture solutions to fit

<footnote n="35">³⁵Reinke + CropX Farm Management – A Bold New Era, https://aboldnewera.com/ Accessed: 2024-06-27.</footnote>

<footnote n="36">³⁶Projects using openHAB Companies, https://github.com/openhab/openhab1-addons/wiki/Projects-using-openHAB---Companies. Accessed 2024-06-27.</footnote>

<footnote n="37">³⁷Awesome Home Assistant, https://github.com/frenck/awesome-home-assistant. Accessed: 2024-06-27.</footnote>
<table><thead><tr><th>Platform</th><th>Repository</th><th>Stars</th><th>Forks</th></tr></thead><tbody><tr><td>Home Assistant</td><td>*/home-assistant/core</td><td>61 000</td><td>24 000</td></tr><tr><td>Node-RED</td><td>*/node-red/node-red</td><td>17 000</td><td>4 000</td></tr><tr><td>ThingML</td><td>*/TelluIoT/ThingML</td><td>100</td><td>30</td></tr><tr><td>Openhab</td><td>*/openhab/openhab-core</td><td>800</td><td>400</td></tr><tr><td>Jeedom</td><td>*/jeedom/core</td><td>374</td><td>312</td></tr></tbody></table>

(a) Overview of some IoT platforms popularity metrics on Github (*/ = https://github.com/)

<table><thead><tr><th>Platform</th><th>Plugins/<br>Integrations</th><th>Connect API<br>(JavaScript)</th><th>Extension support</th></tr></thead><tbody><tr><td>IFTTT</td><td>700</td><td>Connect API<br>(JavaScript)</td><td>OpenAPI definition</td></tr><tr><td>Node-RED</td><td>4400</td><td>Module API<br>(JavaScript)</td><td>Editor API (Nodes)<br>Library store<br>Hooks</td></tr><tr><td>OpenHAB</td><td>400</td><td>REST API<br>(Java)</td><td>Core bindings API<br>Scripting APIs<br>(Java, Jython, Groovy)</td></tr><tr><td>HomeKit</td><td>900</td><td>Module API<br>(Swift)</td><td>Home Bridge project</td></tr></tbody></table>

(b) Overview of some IoT platforms offered APIs and plugins

<caption>Table 2. Overview of IoT platforms developer support metrics</caption>

the John Deere machines, and although interoperability features are proposed, they considerably restrict the scope of applications. The required hardware settings are also often related to hubs acquisition as for Habitat elevation, which entirely relies on local computations for privacy. For home automation, Apple HomeKit is free for users owning an Apple device that can be employed as a hub (iPad, homePad or Apple TV), but limited to compatible IoT devices. Devices with the label “works with Apple HomeKit” are considerably more expensive.

The financial aspects extend to the ongoing operating, support or maintenance costs. These include the costs for extending the platform use cases to additional devices or services. Hub-based platforms are limited to a number of devices, 100 for Apple HomeKit, for example. Scaling up to larger settings could require additional expenses. Freemium platforms offer users a set of basic functionalities and request them to subscribe to monthly or annual billing plans for additional services supporting complex automation, such as IFTTT. As discussed for interoperability, another aspect that might contribute to ongoing fees relates to purchasing plugins or add-ons to enlarge the extent of supported devices and protocols. JEEDOM open-source platform offers a plugin marketplace that provides free and chargeable components. Many hub-based platforms offer cloud-access options for data storage, web-based service integration or remote access, which leads to additional costs. Examples include the Home Assistant cloud. Maintenance and support costs, essential for maintaining platform efficiency and resolving technical issues, are potential ongoing costs. Most IoT platforms, whether open-source or commercial, provide extensive documentation and publicly available tutorials. However, some offer paid training sessions or certification programs such as Azure Farmbeats or CropX. It is worth mentioning that open-source platforms come with different licensing terms that should be considered when selecting the appropriate IoT platform. Some licenses, such as the Eclipse Public License, require crediting the platform when reusing its features in commercial applications, which may introduce constraints for large-scale industrial projects.

## 7 CONCLUSION

As for other complex systems, building, using, and maintaining IoT systems faces increasing challenges, primarily due to the technological diversity and complexity of system components. On the other hand, the use scenarios involving the Internet of Things and supporting task automation have never been this broad. Several high-level tools are striving to offer simplified user-interaction interfaces for seamless access to these technologies, preventing users from being overwhelmed with technical stacks wrapping edge, cloud, mobile, or constrained device management, communicating via multiple adapted protocols. On another dimension, the popularity and success of IoT applications also transformed users' profiles, who have recently evolved from simple consumers to developers creating applications through user-friendly
interfaces. IoT platforms nowadays attempt to expose interfaces with new languages (Domain-Specific Languages), thought and designed to bridge the gap between the physical layers (cloud infrastructures and protocols, mobile-constrained objects, etc.) and the high-level services supporting the communication between networked objects.

In IoT systems, general-purpose languages can be too sophisticated, requiring skilled users and much coding time, and include patterns that might be unnecessary for some given domain requirements. They are still used across various platforms but are generally wrapped into intermediate layers or exposed for device-programming utilities. Tools tending to enlarge their user profiles prefer simplified interactions supported by domain-specific languages. In the realm of IoT domain-centric tools, three primary paradigms—model-driven, mashup tools, and end-user programming—mirror established programming models. Model-driven languages primarily cater to business experts possessing field knowledge, facilitating the creation of applications via UML-like models or other VSDML visual languages. These languages are beneficial for IoT systems that intertwine technical system building with vertical domains. The use of simplified modelling tools encourages the involvement of domain experts, enhancing the system’s alignment with domain requirements and facilitating autonomy for domain experts who prefer modelling for encoding system behaviour and components. Mashup tools, on the other hand, harness the plethora of available IoT web services to enable data and service composition. Unlike MDD tools, which focus on systems components, mashup tools are designed to focus on flow messages between components. While the preexistence of services eases system development, it also limits its applicability to available features. The tools enable the composition of various web-available services at the user-interface level, but the extent to which users act on logical behaviours is restricted. End-user programming as a concept is common to the programming community beyond IoT. It has evolved with technological advances to facilitate higher abstraction levels, leveraging increasingly broader techniques. Historically, model-driven programming and mashup tools were considered EUP tools as they encapsulate technical specifications in high-level component representations. Recently, natural-language processing, programming by example or through games or voice-based interactions are employed through various platforms, including computers and mobiles, for simplified automation encoding. The platform programming approach usually affects its expressivity and the expected learning curve for new users. The IoT platform selection process is thus dependent on various factors, including technical characteristics.

An extensive interest has been dedicated to interoperability within IoT systems in the last few years. Making complex systems interconnect and operate together becomes more challenging with each proposed standard, tool, device, or language. Interoperability support is tooled with plugins, adapters, gateways and APIs, enabling effective collaboration and broader hardware support. As for complex systems, the architectural patterns also affect the deployment of IoT solutions and their non-functional requirements, such as scalability, performance efficiency or security. The number of system components and the type of interactions provide valuable insights about the system’s operating mode, robustness, security or scalability. Platforms are increasingly putting effort into documentation and user communities to increase their popularity and ensure comprehensive and effective use of their platforms.

In summary, the fast-evolving landscape of IoT technologies, in its vast diversity and complexity, calls for an ongoing effort to empower end-users with the knowledge and selection criteria that support them to make informed decisions, thereby making steps towards democratizing technological progress in every domain. We believe this paper is a step in this direction, providing a broad survey of all these issues in a manner accessible to any technically inclined professional interested in entering the IoT field from a business-domain perspective. We provide up to date knowledge and references that should help fast-track the necessary selection, design and implementation steps that IoT deployment requires. Future work may consider extending this survey to other application domains such as Industry 4.0 or healthcare, to discuss more domain specific platforms.
REFERENCES

[1] Ala Al-Fuqaha, Mohsen Guizani, Mehdi Mohammadi, Mohammed Aledhari, and Moussa Ayyash. 2015. Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications. *IEEE communications surveys & tutorials* 17, 4 (2015), 2347–2376.

[2] Connectivity Standards Alliance. 2011. *Matter Specification Version 1.0*. Technical Report. Connectivity Standards Alliance, San Jose, CA, USA. 11 pages. https://csa-iot.org/wp-content/uploads/2022/11/22-27349-001_Matter-1.0-Core-Specification.pdf

[3] Kevin Ashton. 2009. That 'Internet of Things' thing. *RFID journal* 22, 7 (2009), 97–114.

[4] Luigi Atzori, Antonio Iera, and Giacomo Morabito. 2010. The Internet of Things: A survey. *Computer networks* 54, 15 (2010), 2787–2805.

[5] Debasis Bandyopadhyay and Jaydip Sen. 2011. Internet of Things: Applications and Challenges in Technology and Standardization. *Wireless personal communications* 58, 1 (2011), 49–69.

[6] Sourav Banerjee, Chinmay Chakraborty, and Sudipta Paul. 2019. Programming Paradigm and the Internet of Things. In *Handbook of IoT and Big Data*. CRC Press, 145–163.

[7] Barnana Baruah and Subhashis Dhal. 2018. A two-factor authentication scheme against FDM attack in IFTTT based Smart Home System. *Computers & Security* 77 (2018), 21–35.

[8] Len Bass, Paul Clements, and Rick Kazman. 2003. *Software architecture in practice*. Addison-Wesley Professional.

[9] Michael Blackstock and Rodger Lea. 2014. Toward a Distributed Data Flow Platform for the Web of Things (Distributed Node-RED)). In *Proceedings of the 5th International Workshop on Web of Things*. 34–39.

[10] Evandro Eduardo Broday and Manuel Carlos Gameiro da Silva. 2023. The role of internet of things (IoT) in the assessment and communication of indoor environmental quality (IEQ) in buildings: a review. *Smart and Sustainable Built Environment* 12, 3 (2023), 584–606.

[11] Arne Bröring, Stefan Schmid, Corina-Kim Schindhelm, Abdelmajid Khelil, Sebastian Käbisch, Denis Kramer, Danh Le Phuoc, Jelena Mitic, Darko Anicic, and Ernest Teniente. 2017. Enabling IoT ecosystems through platform interoperability. *IEEE software* 34, 1 (2017), 54–61.

[12] Paul Brous, Marijn Janssen, and Paulien Herder. 2020. The dual effects of the Internet of Things (IoT): A systematic review of the benefits and risks of IoT adoption by organizations. *International Journal of Information Management* 51 (2020), 101952.

[13] Adriana Caione, Alessandro Fiore, Luca Mainetti, Luigi Manco, and Roberto Vergallo. 2017. WoX: Model-Driven Development of Web of Things Applications. In *Managing the Web of Things*. Elsevier, 357–387.

[14] Giovanni Campagna, Rakesh Ramesh, Silei Xu, Michael Fischer, and Monica S. Lam. 2017. Almond: The architecture of an open, crowdsourced, privacy-preserving, programmable virtual assistant. In *Proceedings of the 26th International Conference on World Wide Web*. 341–350.

[15] Humberto Cervantes and Rick Kazman. 2016. *Designing software architectures: a practical approach*. Addison-Wesley Professional.

[16] Raymond Chan, Wye Kaye Yan, Jung Man Ma, Kai Mun Loh, Tan Yu, Malcolm Yoke Hean Low, Kar Peo Yar, Habib Rehman, and Thong Chee Phua. 2023. IoT devices deployment challenges and studies in building management system. *Frontiers in The Internet of Things* 2 (2023), 1254160.

[17] Victor Charpenay, Maxime Lefrançois, María Poveda-Villalón, and Sebastian Käbisch. 2023. *Thing Description (TD) ontology*. W3C internal document. World Wide Web Consortium. https://www.w3.org/2019/wot/td

[18] Xiang 'Anthony' Chen and Yang Li. 2017. Improv: an input framework for improvising cross-device interaction by demonstration. *ACM Transactions on Computer-Human Interaction (TOCHI)* 24, 2 (2017), 1–21.

[19] Bo Cheng, Da Zhu, Shuai Zhao, and Junliang Chen. 2016. Situation-aware IoT service coordination using the event-driven SOA paradigm. *IEEE Transactions on Network and Service Management* 13, 2 (2016), 349–361.

[20] Lawrence Chung and Julio César Sampaio do Prado Leite. 2009. On Non-Functional Requirements in Software Engineering. (2009), 363–379.

[21] Joëlle Coutaz and James L. Crowley. 2016. A first-person experience with end-user development for smart homes. *IEEE Pervasive Computing* 15, 2 (2016), 26–39.

[22] Jose Danado and Fabio Paternò. 2012. Puzzle: a visual-based environment for end user development in touch-based mobile phones. In *International Conference on Human-Centred Software Engineering*. Springer, 199–216.

[23] Laura Daniele, Raúl García-Castro, Maxime Lefrançois, and María Poveda-Villalón. 2020. *SAREF: the Smart Applications REFerence ontology*. Technical Report TS 103 264, v3.1.1. ETSI. https://saref.etsi.org/core/v3.1.1/

[24] Ramide Augusto Sales Dantas, Milton Vasconcelos da Gama Neto, Ivan Dimitry Zyrianoff, and Carlos Alberto Kamienski. 2020. The swamp farmer app for iot-based smart water status monitoring and irrigation control. In *2020 IEEE International Workshop on Metrology for Agriculture and Forestry (MetroAgriFor)*. IEEE, 109–113.

[25] Jasenka Dizdarević, Francisco Carpio, Admela Jukan, and Xavi Masip-Bruin. 2019. A Survey of Communication Protocols for Internet of Things and Related Challenges of Fog and Cloud Computing Integration. *ACM Computing Surveys (CSUR)* 51, 6 (2019), 1–29.

[26] Pedro Domingues, Paulo Carreira, Renato Vieira, and Wolfgang Kastner. 2016. Building automation systems: Concepts and technology review. *Computer Standards & Interfaces* 45 (2016), 1–12.

[27] David L. Donoho. 2006. Compressed Sensing. *IEEE Transactions on Information Theory* 52, 4 (April 2006), 1289–1306.

[28] Inc Eclipse Foundation. 2019. *IoT Developer Survey 2019*. Technical Report. Eclipse Foundation, Inc.

[29] Fatima Essaadi, Yann Ben Maissa, and Mohammed Dahchour. 2016. MDE-based languages for wireless sensor networks modeling: A systematic mapping study. In *International Symposium on Ubiquitous Networking*. Springer, 331–346.

[30] Teo Eterovic, Enio Kaljic, Dzenana Donko, Adnan Salihbegovic, and Samir Ribic. 2015. An Internet of Things visual domain specific modeling language based on UML. In *2015 XXV International Conference on Information, Communication and Automation Technologies (ICAT)*. IEEE, 1–5.
[31] Dave Evans. 2011. *The Internet of Things: How the Next Evolution of the Internet Is Changing Everything*. Technical Report. Cisco Internet Business Solutions Group (IBSG), Cisco Systems, Inc., San Jose, CA, USA. http://www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf

[32] Dave Evans. 2012. *Overview of the Internet of Things*. Technical Report. International Telecommunication Union. 22 pages. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.2060-201206-I!PDF-E&type=items

[33] Jody Condit Fagan. 2007. Mashing up Multiple Web Feeds Using Yahoo! Pipes. *Computers in Libraries* 27, 10 (2007), 10–17.

[34] Alessandro Fiore, Adriana Caione, Luca Mainetti, Luigi Manco, and Roberto Vergallo. 2018. Top-Down Delivery of IoT-based Applications for Seniors Behavior Change Capturing Exploiting a Model-Driven Approach. *Journal of Communications Software and Systems* 14, 1 (2018), 60–67.

[35] Giancarlo Fortino, Claudio Savaglio, Giandomenico Spezzano, and MengChu Zhou. 2020. Internet of Things as System of Systems: A Review of Methodologies, Frameworks, Platforms, and Tools. *IEEE Transactions on Systems, Man, and Cybernetics: Systems* 51, 1 (2020), 223–236.

[36] Martin Fowler. 2012. *Patterns of Enterprise Application Architecture: Pattern Enterpr Applica Arch*. Addison-Wesley.

[37] Iván Froiz-Míguez, Tiago M Fernández-Caramés, Paula Fraga-Lamas, and Luis Castedo. 2018. Design, implementation and practical evaluation of an IoT home automation system for fog computing applications based on MQTT and ZigBee-WiFi sensor nodes. *Sensors* 18, 8 (2018), 2660.

[38] Cristian González García, B Cristina Pelayo G-Bustelo, Jordán Pascual Espada, and Guillermo Cueva-Fernandez. 2014. Midgar: Generation of heterogeneous objects interconnecting applications. A Domain Specific Language proposal for Internet of Things scenarios. *Computer Networks* 64 (2014), 143–158.

[39] Cristian González García, Daniel Meana-Llorián, Vicente García-Díaz, Andrés Camilo Jiménez, and John Petearson Anzola. 2020. Midgar: Creation of a Graphic Domain-Specific Language to Generate Smart Objects for Internet of Things Scenarios Using Model-Driven Engineering. *IEEE Access* 8 (2020), 141872–141894.

[40] Cristian González García, Liping Zhao, and Vicente García-Díaz. 2019. A user-oriented language for specifying interconnections between heterogeneous objects in the Internet of Things. *IEEE Internet of Things Journal* 6, 2 (2019), 3806–3819.

[41] Nam Ky Giang, Michael Blackstock, Rodger Lea, and Victor C.M. Leung. 2015. Developing IoT Applications in the Fog: a Distributed Dataflow Approach. In *2015 5th International Conference on the Internet of Things (IoT)*. IEEE, 155–162.

[42] Diego Guidotti, Susanna Marchi, Sara Antognelli, and Andrea Cruciani. 2019. Water management: agricolus tools integration. In *2019 Global IoT Summit (GloTS)*. IEEE, 1–5.

[43] Dominique Guinard, Vlad Trifa, Friedemann Mattern, and Erik Wilde. 2011. From the Internet of Things to the Web of Things: Resource-oriented Architecture and Best Practices. In *Architecting the Internet of Things*. Springer, 97–129.

[44] Sandeep Gupta. 2022. Non-functional requirements elicitation for edge computing. *Internet of Things* 18 (2022), 100503.

[45] Armin Haller, Krzysztof Janowicz, Simon Cox, Danh Le Phuoc, Jamie Taylor, and Maxime Lefrançois. 2017. *Semantic Sensor Network Ontology, W3C Recommendation*. W3C Recommendation. World Wide Web Consortium. https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/

[46] Nicolas Harrand, Franck Fleurey, Brice Morin, and Knut Eilif Husa. 2016. ThingML: a language and code generation framework for heterogeneous targets. In *Proceedings of the ACM/IEEE 19th international conference on model driven engineering languages and systems*. 125–135.

[47] Jorge E Ibarra-Esquer, Félix F González-Navarro, Brenda L Flores-Rios, Larysa Burtseva, and Maria A Astorga-Vargas. 2017. Tracking the evolution of the Internet of Things concept across different application domains. *Sensors* 17, 6 (2017), 1379.

[48] IoT Analytics. 2020. IoT Platforms Landscape. https://iot-analytics.com/product/iot-platforms-landscape-database-2020. Accessed: 2022-06-09.

[49] SM Riazul Islam, Daehan Kwak, MD Humaun Kabir, Mahmud Hossain, and Kyung-Sup Kwak. 2015. The internet of things for health care: a comprehensive survey. *IEEE access* 3 (2015), 678–708.

[50] ISO/IEC 25010:2011. *Systems and software Quality Requirements and Evaluation (SQuaRE)*. Standard. International Organization for Standardization, Geneva, CH.

[51] ISO/TC 211. 2011. *Geographic information — Encoding*. Standard. International Organization for Standardization, Geneva, CH.

[52] Krzysztof Janowicz, Armin Haller, Simon JD Cox, Danh Le Phuoc, and Maxime Lefrançois. 2019. SOSA: A lightweight ontology for sensors, observations, samples, and actuators. *Journal of Web Semantics* 56 (2019), 1–10.

[53] Youngmin Ji, Kisu Ok, and Woo Suk Choi. 2018. Web of things based IoT standard interworking test case: Demo abstract. In *Proceedings of the 5th Conference on Systems for Built Environments*. 182–183.

[54] Mengda Jia, Ali Komeily, Yueren Wang, and Ravi S Srinivasan. 2019. Adopting Internet of Things for the development of smart buildings: A review of enabling technologies and applications. *Automation in Construction* 101 (2019), 111–126.

[55] Alexandros Kaloxylos, Aggelos Groumas, Vassilis Sarris, Lampros Katsikas, Panagis Magdalinos, Eleni Antoniou, Zoi Politopoulou, Sjaak Wolfert, Christopher Brewster, Robert Eigenmann, et al. 2014. A cloud-based Farm Management System: Architecture and implementation. *Computers and electronics in agriculture* 100 (2014), 168–179.

[56] Carlos Kamienski, Juha-Pekka Soininen, Markus Taumberger, Ramide Dantas, Attilio Toscano, Tullio Salmon Cinotti, Rodrigo Filev Maia, and André Torre Neto. 2019. Smart water management platform: IoT-based precision irrigation for agriculture. *Sensors* 19, 2 (2019), 276.

[57] Andreas Kamilaris, Feng Gao, Francesc X Prenafeta-Boldu, and Muhammad Intizar Ali. 2016. Agri-IoT: A semantic framework for Internet of Things-enabled smart farming applications. In *2016 IEEE 3rd World Forum on Internet of Things (WF-IoT)*. IEEE, 442–447.

[58] M. Karthikeyan, T.S. Subashini, and M.S. Prashanth. 2020. Implementation of Home Automation Using Voice Commands. In *Data Engineering and Communication Technology*. Springer, 155–162.

[59] Sabrine Khriji, Dhouha El Houssaini, Ines Kammoun, and Olfa Kanoun. 2021. Precision irrigation: an IoT-enabled wireless sensor network for smart irrigation systems. In *Women in precision agriculture*. Springer, 107–129.
[60] Tae-Kook Kim. 2020. Short research on voice control system based on artificial intelligence assistant. In *2020 International Conference on Electronics, Information, and Communication (ICEIC)*. IEEE, 1-2.

[61] Robert Kleinfeld, Stephan Steglich, Lukasz Radziwonowicz, and Charalampos Doukas. 2014. glue.things: a Mashup Platform for wiring the Internet of Things with the Internet of Services. In *Proceedings of the 5th International Workshop on Web of Things*. 16-21.

[62] Ravi Kishore Kodali, Sasweth C Rajanarayanan, Lakshmi Boppana, Samradh Sharma, and Ankit Kumar. 2019. Low cost smart home automation system using smart phone. In *2019 IEEE R10 Humanitarian Technology Conference (R10-HTC)(47129)*. IEEE, 120-125.

[63] Ege Korkan, Fady Salama, Sebastian Kaebisch, and Sebastian Steinhorst. 2021. A-MaGe: Atomic Mashup Generator for the Web of Things. In *Web Engineering - 21st International Conference, ICWE 2021, Biarritz, France, May 18-21, 2021, Proceedings*. Springer, 320-327. https://doi.org/10.1007/978-3-030-74296-6_24

[64] Ajay Krishna, Michel Le Pallec, Alejandro Martinez, Radu Mateescu, and Gwen Salaün. 2020. MOZART: design and deployment of advanced IoT applications. In *Companion proceedings of the web conference 2020*. 163-166.

[65] S.V. Aswin Kumer, P. Kanakaraja, A. Punya Teja, T. Harini Sree, and T. Tejaswni. 2021. Smart home automation using IFTTT and google assistant. *Materials Today: Proceedings* 46 (2021), 4070-4076.

[66] Toby Jia-Jun Li, Yuanchun Li, Fanglin Chen, and Brad A. Myers. 2017. Programming IoT devices by demonstration using mobile apps. In *International Symposium on End User Development*. Springer, 3-17.

[67] Steve Liang, Chih-Yuan Huang, and Tania Khalafbeigi. 2016. OGC SensorThings API Part 1: Sensing, Version 1.0. Standard OGC 15-078r6. Open Geospatial Consortium. http://dx.doi.org/10.25607/OBP-455

[68] JA López-Riquelme, N Pavón-Pulido, H Navarro-Hellín, F Soto-Valles, and R Torres-Sánchez. 2017. A software architecture based on FIWARE cloud for Precision Agriculture. *Agricultural water management* 183 (2017), 123-135.

[69] Mahmoud Shuker Mahmoud and Auday AH Mohamad. 2016. A study of efficient power consumption wireless communication techniques/modules for internet of things (IoT) applications. *Advances in Internet of Things* 6, 2 (2016), 19-29.

[70] Luca Mainetti, Luigi Manco, Luigi Patrono, Andrea Secco, Ilaria Sergi, and Roberto Vergallo. 2016. An ambient assisted living system for elderly assistance applications. In *2016 IEEE 27th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications*. IEEE, 1-6.

[71] Luca Mainetti, Luigi Manco, Luigi Patrono, Ilaria Sergi, and Roberto Vergallo. 2015. Web of Topics: An IoT-aware model-driven designing approach. In *2015 IEEE 2nd World Forum on Internet of Things (WF-IoT)*. IEEE, 46-51.

[72] Luca Mainetti, Paolo Panarese, and Roberto Vergallo. 2022. WoX+: A Meta-Model-Driven Approach to Mine User Habits and Provide Continuous Authentication in the Smart City. *Sensors* 22, 18 (2022), 6980.

[73] Ivano Malavolta and Henry Muccini. 2014. A study on MDE approaches for engineering wireless sensor networks. In *2014 40th EUROMICRO Conference on Software Engineering and Advanced Applications*. IEEE, 149-157.

[74] Marco Manca, Parvaneh Parvin, Fabio Paternò, and Carmen Santoro. 2020. Integrating Alexa in a Rule-based Personalization Platform. In *Proceedings of the 6th EAI International Conference on Smart Objects and Technologies for Social Good*. 108-113.

[75] Ramón Martínez, Juan Ángel Pastor, Bárbara Álvarez, and Andrés Iborra. 2016. A testbed to evaluate the firmware-based IoT platform in the domain of precision agriculture. *Sensors* 16, 11 (2016), 1979.

[76] Xianghang Mi, Feng Qian, Ying Zhang, and XiaoFeng Wang. 2017. An empirical characterization of IFTTT: ecosystem, usage, and performance. In *Proceedings of the 2017 Internet Measurement Conference*. 398-404.

[77] José P Miguel, David Mauricio, and Glen Rodriguez. 2014. A review of software quality models for the evaluation of software products. *International Journal of Software Engineering and Applications* 5, 6 (2014), 31-53.

[78] Armin Moin, Stephan Rössler, Marouane Sayih, and Stephan Günnemann. 2020. From things' modeling language (ThingML) to things' machine learning (ThingML2). In *Proceedings of the 23rd ACM/IEEE Int. Conf. on Model Driven Engineering Languages and Systems: Companion Proc.* 1-2.

[79] Xuan Thang Nguyen, Huu Tam Tran, Harun Baraki, and Kurt Geihs. 2015. FRASAD: A framework for model-driven IoT Application Development. In *2015 IEEE 2nd world forum on internet of things (WF-IoT)*. IEEE, 387-392.

[80] Mahda Noura, Mohammed Atiquzzaman, and Martin Gaedke. 2019. Interoperability in Internet of Things: Taxonomies and Open Challenges. *Mobile networks and applications* 24, 3 (2019), 796-809.

[81] Fabio Paternò and Carmen Santoro. 2017. A Design Space for End User Development in the Time of the Internet of Things. In *New perspectives in end-user development*. Springer, 43-59.

[82] Liisa A Pesonen, Frederick K-W Teye, Ari K Ronkainen, Markku O Koistinen, Jere J Kaivosoja, Pasi F Suomi, and Raimo O Linkolehto. 2014. Cropinfra-An Internet-based service infrastructure to support crop production in future farms. *Biosystems engineering* 120 (2014), 92-101.

[83] Precedence Research. 2022. Internet of Things (IoT) in Agriculture Market. https://www.precedenceresearch.com/iot-in-agriculture-market. Accessed: 2023-03-28.

[84] Amir Rahmati, Earlence Fernandes, Jaeyeon Jung, and Atul Prakash. 2017. IFTTT vs. Zapier: A comparative study of trigger-action programming frameworks. arXiv:1709.02788 [cs.CR]

[85] Anoja Rajalakshmi and Hamid Shahnasser. 2017. Internet of Things using Node-Red and Alexa. In *2017 17th International Symposium on Communications and Information Technologies (ISCIT)*. IEEE, 1-4.

[86] Partha Pratim Ray. 2017. Internet of things for smart agriculture: Technologies, practices and future direction. *Journal of Ambient Intelligence and Smart Environments* 9, 4 (2017), 395-420.

[87] Partha Pratim Ray. 2018. A survey on Internet of Things architectures. *J. of King Saud U.-Computer and Information Sciences* 30, 3 (2018), 291-319.
[88] Larissa C Rocha, Rossana MC Andrade, Andreia L Sampaio, and Valéria Lelli. 2017. Heuristics to evaluate the usability of ubiquitous systems. In *Distributed, Ambient and Pervasive Interactions: 5th International Conference, DAPI 2017, Held as Part of HCI International 2017, Vancouver, BC, Canada, July 9-14, 2017, Proceedings* 5. Springer, 120-141.

[89] Maria Angeles Rodriguez, Llanos Cuenca, and Angel Ortiz. 2018. FIWARE open source standard platform in smart farming-a review. In *Collaborative Networks of Cognitive Systems: 19th IFIP WG 5.5 Working Conf.on Virtual Enterprises, Cardiff, UK, September 17-19, 2018, Proc. 19*. Springer, 581-589.

[90] Luca Roffia, Paolo Azzoni, Cristiano Aguzzi, Fabio Viola, Francesco Antoniazzi, and Tullio Salmon Cinotti. 2018. Dynamic linked data: A SPARQL event processing architecture. *Future Internet* 10, 4 (2018), 36.

[91] Challouf Sabri, Lobna Kriaa, and Saidane Leila Azzouz. 2017. Comparison of IoT constrained devices operating systems: A survey. In *2017 IEEE/ACS 14th International Conference on Computer Systems and Applications (AICCSA)*. IEEE, 369-375.

[92] Audrey Sanctorum, Suzanne Kieffer, and Beat Signer. 2020. User-driven Design Guidelines for the Authoring of Cross-Device and Internet of Things Applications. In *Proceedings of the 11th Nordic Conference on Human-Computer Interaction: Shaping Experiences, Shaping Society*. 1-12.

[93] Sajjad Hussain Shah and Ilyas Yaqoob. 2016. A survey: Internet of Things (IOT) technologies, applications and challenges. In *2016 IEEE Smart Energy Grid Engineering (SEGE)*. IEEE, 381-385.

[94] Kiran Jot Singh and Divneet Singh Kapoor. 2017. Create your own Internet of Things: A survey of IoT platforms. *IEEE Consumer Electronics Magazine* 6, 2 (2017), 57-68.

[95] William Stallings. 1987. *Handbook of computer-communications standards; Vol. 1: the open systems interconnection (OSI) model and OSI-related standards*. Macmillan Publishing Co., Inc.

[96] Rudi Studer, V. Richard Benjamins, and Dieter Fensel. 1998. Knowledge Engineering: Principles and Methods. *Data and Knowledge Eng.* 25, 1-2 (1998), 161-197.

[97] Xiang Su, Hao Zhang, Jukka Riekki, Ari Keränen, Jukka K. Nurminen, and Libin Du. 2014. Connecting IoT sensors to knowledge-based systems by transforming SenML to RDF. *Procedia Computer Science* 32 (2014), 215-222.

[98] Antero Taivalsaari and Tommi Mikkonen. 2018. On the development of IoT systems. In *2018 Third Int. Conf. on Fog and Mobile Edge Computing (FMEC)*. IEEE, 13-19.

[99] Richard N. Taylor, Nenad Medvidovic, and Dashofy Eric M. 2010. *Software Architecture: Foundations, Theory, and Practice*. John Wiley & Sons, Inc.

[100] Kleanthis Thramboulidis and Foivos Christoulakis. 2016. UML4IoT-A UML-based approach to exploit IoT in cyber-physical manufacturing systems. *Computers in Industry* 82 (2016), 259-272.

[101] Blase Ur, Melwyn Pak Yong Ho, Stephen Brawner, Jiyun Lee, Sarah Mennicken, Noah Picard, Diane Schulze, and Michael L. Littman. 2016. Trigger-Action Programming in the Wild: An Analysis of 200,000 IFTTT Recipes. In *Proceedings of the 2016 CHI Conference on Human Factors in Computing Systems*. 3227-3231.

[102] Sander Vanden Hautte, Pieter Moens, Joachim Van Herwegen, Dieter De Paepe, Bram Steenwinckel, Stijn Verstichel, Femke Ongenaae, and Sofie Van Hoecke. 2020. A dynamic dashboarding application for fleet monitoring using semantic web of things technologies. *Sensors* 20, 4 (2020), 1152.

[103] Supachai Vorapojpisut. 2015. A Lightweight Framework of Home Automation Systems Based on the IFTTT Model. *J. Softw.* 10, 12 (2015).

[104] Peter Wegner. 1996. Interoperability. *ACM Computing Surveys (CSUR)* 28, 1 (1996), 285-287.

[105] Hansong Xu, Wei Yu, David Griffith, and Nada Golmie. 2018. A survey on industrial Internet of Things: A cyber-physical systems perspective. *Ieee access* 6 (2018), 78238-78259.

[106] Hikmat Yar, Ali Shariq Imran, Zulfiqar Ahmad Khan, Muhammad Sajjad, and Zenun Kastrati. 2021. Towards smart home automation using IoT-enabled edge-computing paradigm. *Sensors* 21, 14 (2021), 4932.

[107] Jennifer Yick, Biswanath Mukherjee, and Dipak Ghosal. 2008. Wireless sensor network survey. *Computer networks* 52, 12 (2008), 2292-2330.

[108] Wei-Zhe Zhang, Ibrahim A. Elgendy, Mohamed Hammad, Abdullah M. Iliyasu, Xiaojiang Du, Mohsen Guizani, and Ahmed A. Abd El-Latif. 2020. Secure and optimized load balancing for multitier IoT and edge-cloud computing systems. *IEEE Internet of Things Journal* 8, 10 (2020), 8119-8132.

[109] Ivan Zyrianoff, Alexandre Heideker, Luca Sciullo, Carlos Kamienski, and Marco Di Felice. 2021. Interoperability in open IoT platforms: WoT-FIWARE comparison and integration. In *2021 IEEE International Conference on Smart Computing (SMARTCOMP)*. IEEE, 169-174.

[110] Ivan Zyrianoff, Alexandre Heideker, Dener Silva, João Kleinschmidt, Juha-Pekka Soininen, Tullio Salmon Cinotti, and Carlos Kamienski. 2019. Architecting and deploying IoT smart applications: A performance-oriented approach. *Sensors* 20, 1 (2019), 84.

Received 12 July 2023; accepted 2 September 2024