Source-linked AI summary
An overview of IoT architectures, technologies, and existing open-source projects
Tomás Domínguez-Bolaño, Omar Campos, Valentín Barral, Carlos J. Escudero, José A. García-Naya
TL;DR
Organizations need IoT platforms that can integrate devices across manufacturers, protocols, and formats, while proprietary solutions can deepen device dependence and limit sensor-data access. The paper reviews IoT architectures, technologies, protocols, and formats, and surveys commercial and free and open-source platforms. It reports that free and open-source platforms are highly heterogeneous, with substantial differences among them.
Problem
Organizations’ monitoring systems are fragmented, and proprietary IoT services can constrain device integration and access to sensor data.
Source: §1 · pp. 1–2Method
The paper reviews IoT architecture, protocols, and data formats, then surveys commercial and free and open-source platforms and related projects.
Source: §1 · p. 2, §6 · p. 13Results
Free and open-source IoT platforms are very heterogeneous, with large differences between them.
Source: §6 · p. 13Takeaways & Limitations
The paper’s comparison presents popular free and open-source platform options as a varied set rather than a uniform category.
Source: §1 · p. 2, §6 · p. 13
Abstract
from arXiv · showhide
Today's needs for monitoring and control of different devices in organizations require an Internet of Things (IoT) platform that can integrate heterogeneous elements provided by multiple vendors and using different protocols, data formats and communication technologies. This article provides a comprehensive review of all the architectures, technologies, protocols and data formats most commonly used by existing IoT platforms. On this basis, a comparative analysis of the most widely used open source IoT platforms is presented. This exhaustive comparison is based on multiple characteristics that will be essential to select the platform that best suits the needs of each organization.
1. Introduction
Organizations’ monitoring systems developed without coordination, and proprietary IoT solutions can deepen fragmentation and device dependence. The paper reviews IoT architectures and technologies and compares popular free and open-source platforms, addressing the relative lack of detailed coverage of these platforms.
1. Introduction
- Uncoordinated monitoring systems dispersed across organizational departments, while proprietary IoT services can aggravate fragmentation and heterogeneity.Such services may also tie new devices to a manufacturer’s cloud and restrict access to sensor data for analysis.Source: §1 · pp. 1–2
- Platform selection should account for both required functions and non-functional factors such as performance, cost, freedom of use, and development effort.Organizations with existing cloud and network infrastructure may deploy free and open-source platforms there instead of using an external cloud solution.Source: §1 · p. 2
- The paper surveys IoT architectures, technologies, protocols, and data formats, then compares popular free and open-source platforms and related projects.Its comparison of free and open-source platforms addresses a literature shortcoming the authors identify.Source: §1 · p. 2
- Earlier reviews covered IoT architectures, technologies, and platforms, but the paper identifies fewer detailed studies of free and open-source platforms.The cited literature includes reviews of smart-home systems, commercial platforms, and comparison methodologies.Source: §1 · p. 2
2. IoT architectures and technologies
IoT systems connect physical devices with external systems, typically platforms, enabling interaction between users, sensors, and actuators. The section names a three-layer model and a reference architecture, and notes that applications can automate device actions using sensor values.
2. IoT architectures and technologies
- IoT systems center on user interaction with sensors that report environmental information and actuators users can control.The passage describes IoT devices as physical sensors or actuators managed by an external system, usually an IoT platform.Source: §2 · p. 2
- Fig. 1 presents a three-layer architecture, while Fig. 2 presents a reference IoT architecture proposed in [19].The supplied figure captions identify these architecture views without describing their internal components.Source: Figure 1 · p. 3, Figure 2 · p. 3
- IoT applications can analyze data, predict, control, monitor, and alert users; rules can automate device actions based on sensor values.The example links air-quality readings to automatic control of a ventilation system.Source: §2 · p. 3
2.1. IoT architecture
The paper proposes a seven-part IoT reference architecture, extending prior models with explicit security, management, and communications-network blocks. Its components describe how devices and services connect to platforms, applications, and system-wide functions.
2.1. IoT architecture
- The reference architecture combines seven parts: sensors and actuators, platform, communications network, gateway, applications, management, and security.It extends the reference architecture in using models from IEEE and ITU-T.Source: §2.1 · p. 3
2.1.1. Sensors and actuators
- Sensors measure environmental or system parameters, actuators perform requested actions, and sensors may preprocess captured data before transmission.The architecture also distinguishes user-deployed devices from third-party services that provide data through REST APIs.Source: §2.1.1 · pp. 3–4
2.1.2. Communications network
- The communications network supplies physical, link, and network layers; the review covers IPv4, IPv6, 6LoWPAN, and wireless technologies compared by scope, range, topology, and maximum rate.IPv6 addresses IPv4 address exhaustion, while 6LoWPAN adapts IPv6 for IEEE 802.15.4 low-rate networks.Source: §2.1.2 · p. 4, Table 1 · p. 5
2.1.3. IoT gateway
- A gateway bridges devices and platforms when their networks, data protocols, or formats differ, giving the platform common interfaces for communication.Multiple gateways may each connect to several IoT devices.Source: §2.1.3 · p. 5
2.1.4. IoT platform
- The platform’s three core blocks are device management and connectivity, data storage and analytics, and application enablement.With heterogeneous direct connections, the platform must provide a unified interface for sensor data and properties and actuator interaction; stored data also needs a defined lifetime.Source: §2.1.4 · p. 5
2.1.5. Applications
- Applications read sensor data or control actuators through interfaces such as visualizations, controls, and rules triggered by events like threshold crossings.Rules may control devices, perform operations, or send user warnings.Source: §2.1.5 · pp. 5–6
2.1.6. Security
- The security block addresses confidentiality, integrity, and availability through authentication, privacy, access control, security-event monitoring, and key and certificate management.Source: §2.1.6 · p. 6
2.1.7. Management
- System management covers fault and performance management, network management, and remote device configuration and updates.Source: §2.1.7 · p. 6
2.2. Data layer protocols
The paper distinguishes direct publish, broker-mediated publish–subscribe, and polling as basic data-exchange models. It relates architectural styles and application protocols to these models and notes that communications security requires additional protocols.
2.2. Data layer protocols
- The three data-exchange models are direct publish, broker-mediated publish–subscribe, and polling, with clients or platforms initiating exchanges as appropriate.In publish–subscribe, publishers send data and identifiers to a broker, which forwards messages to subscribers.Source: §2.2 · p. 6
- REST commonly uses HTTP methods for resource operations and supports publish or polling, while event-driven architecture uses publisher–subscriber communication.REST APIs can recover data or send commands; event listeners react to triggered events.Source: §2.2 · p. 6
- HTTP and CoAP support publish or polling, MQTT is a lightweight publisher–subscriber protocol, and AMQP’s supported models depend on its version.Matter is described as a royalty-free connectivity standard under development, aiming to increase smart-home compatibility with security as a design principle.Source: §2.2 · pp. 6–8
- TLS or DTLS must be used on top of these data protocols to provide communications privacy, integrity, and authenticity.Source: §2.2 · p. 8
2.3. Data formats
Data-layer protocols do not standardize the type or structure of transmitted data, so device and platform formats must be compatible and interpreted correctly. The paper reviews common serialization formats and notes prior comparisons of their speed and size.
2.3. Data formats
- Data-layer protocols do not constrain data type or format, so devices must send formats accepted by the platform and configure them for correct interpretation.Source: §2.3 · p. 8
- The reviewed serialization formats include text-based JSON, CSV, XML, and YAML, alongside binary CBOR and Protocol Buffers.CBOR is based on JSON and targets small code and message sizes with extensibility; Protocol Buffers serializes structured data into compact binary form.Source: §2.3 · p. 8
- Prior studies compared serialization formats by assessing serialization speed and data size.Source: §2.3 · p. 8
3. IoT platforms
The section distinguishes commercial from free and open-source IoT platforms, then compares platform types and characteristics relevant to their use. The comparison covers consumer and enterprise offerings as well as the heterogeneous open-source landscape.
3. IoT platforms
- The survey divides IoT platforms into commercial and free and open-source categories.It presents them as two groups for describing available platforms.Source: §3 · p. 8
3.1.1. Consumer-oriented platforms
- Consumer platforms offer plug-and-play control of household devices, but may provide limited services and functionality for non-enterprise users.Examples include Apple HomeKit and SmartThings.Source: §3.1.1 · p. 8
3.1.2. Enterprise platforms
- Enterprise platforms target professional and industrial settings with scalable, customizable solutions, advanced analytics, and security, but require specialist deployment and usually a subscription.Examples include AWS IoT, Google Cloud IoT, IBM Cloud, Microsoft Azure IoT, and ThingWorx.Source: §3.1.2 · p. 8
3.2. Free and open-source IoT platforms
- Free and open-source platforms vary widely, and some may offer weaker analytics, scalability, or security than enterprise platforms.The comparison includes Eclipse Kapua, Home Assistant, Mainflux, openEMS, openHAB, OpenRemote, SiteWhere, and ThingsBoard; prior comparisons covered only a few such platforms.Source: §3.2 · p. 9
- The comparison criteria include license, application focus, backend language, and integrations with commercial devices or generic protocols.Device integrations may require handling different protocols and data formats, while generic integrations can still be limited by accepted formats.Source: §3.2 · p. 9
- The platforms are also assessed by supported databases, automations, integrated analytics, and data visualization.The database overview distinguishes relational, NoSQL, and time-series systems; automations can use sensor rules or flow-based frameworks such as Node-RED.Source: §3.2 · p. 9
- Tables 2 and 3 compare the selected open-source platforms by characteristic, with each platform’s version and release date recorded.The tables are presented in two parts.Source: §3.2 · p. 9, Table 2 · p. 10, Table 3 · p. 10
4. Free and open-source IoT-related projects
The section surveys open-source projects that can serve as building blocks for IoT systems, from standards implementations and edge gateways to integration and visualization tools.
4. Free and open-source IoT-related projects
- The projects described are software components that can support custom IoT platforms, even though they are not themselves IoT platforms.The section presents these projects as building blocks for IoT systems.Source: §4 · p. 11
4.1. OPC UA
- Open-source implementations include OPC UA clients and servers, as well as oneM2M standards projects such as Eclipse OM2M and OpenMTC.OPC UA supports client-server request/response and publisher-subscriber communication.Source: §4.1 · pp. 11–12, §4.2 · p. 12
4.3. FIWARE
- FIWARE provides common specifications and open-source components, with smart cities as its primary domain and deployments in more than 40 cities.Other stated domains include smart energy, smart agriculture, and smart industry.Source: §4.3 · p. 12
4.4. Gateways
- EdgeX Foundry and Kura capture and process sensor data at a gateway before sending it to an IoT platform or another service.The gateway can sit between IoT devices and the platform.Source: §4.4 · p. 12
4.5. Data collection and integration tools
- Data collection and integration tools move and process data and metrics from varied sources and protocols, supporting integration across IoT systems.Examples include Apache Kafka, Telegraf, Fluentd, Fluent Bit, and Node-RED.Source: §4.5 · p. 12
4.6. Data visualization
- Grafana, Metabase, and Redash support complex visualization by querying databases and plotting the resulting data.The section recommends considering these tools when sensor data needs complex visualization.Source: §4.6 · p. 12
5. Summary of IoT open-source platforms and projects
The summary table catalogs open-source IoT platforms and related projects using project, support, licensing, and GitHub information.
5. Summary of IoT open-source platforms and projects
- Table 4 records each project’s type, name, developer, first public release, license, and commercial support.Some projects may also have proprietary versions with features absent from their open-source versions.Source: §5 · p. 12
- The table includes GitHub stars and project-name search results as indicators of project popularity.For Apache projects, the search omits “Apache” to avoid a term usually absent from references to those projects.Source: §5 · pp. 12–13
6. Conclusion
The conclusion reviews foundational IoT architecture, protocols, and formats, then surveys platform options and related open-source projects. It highlights the heterogeneity of open-source platforms as a reason an overview can inform platform selection.
6. Conclusion
- The paper proposes a reference IoT architecture and reviews protocols and formats, noting that protocols do not restrict data formats and that gateways can bridge incompatible device and platform technologies.Gateways may provide a common communication network, data-layer protocol, and format.Source: §6 · p. 13
- The paper surveys commercial and open-source platforms, finding substantial functional heterogeneity among open-source options and presenting an overview as a useful selection reference.It also catalogs related open-source projects that can serve as IoT-system building blocks.Source: §6 · p. 13