The number of available IoT-Platforms is still on the rise although there is already a considerable amount of them. This proliferation poses the question how do they stack up agains each other by evaluating them against a feature catalog? In the following we present a bullet point level catalog of requirements and traits that we have carefully distilled from re-evaluating several IoT-projects that we have conducted in the past years using offerings from well-known cloud providers and our Xingular-Platform which supports almost all of these features.

Authentication/ Identity Management

• Flexible Identity Management with plugable/ exchangeable backend (identity stores like LDAP).
• OpenID Connect (OIDC) / OAuth 2 compatible in the API layer for friction less AuthZ of mobile apps (Krumdia kann das derzeit nicht).
• Support for long validity tokens for mobile apps.
• IdM Processes:
  • User invitation to an organization.
  • User self sign-up incl. account activation via e-mail.
  • Password reset via self-service.
  • Account deletion.
• Self sign-up.
• DSGVO conforming data report.

Authorization/ Access Management

• Access control for all API objects.
• Multi tenancy capable.
• Access control based on:
  • The ABAC principle.
  • Support for user roles.
  • Support for attributations to user-role-assocations with organization/ location scope.
  • Hierarchical organization structure.
• Possibility to transfer ownership of objects with a transfer/ claim process.
• Delegated administration model (Possibility to pass administrative persmissions to other users).

Device Management

• Support for the following device types:
  • IP (v4/v6) addressed devices.
  • LoRaWAN devices.
• Device identity management based on secrets.
• Device identity management based on public/ private keys.
• Gateway/ edge device management:
  • Telemetry data such as CPU load and memory consumption.
  • Connection state.
  • Firmware update.
• Possibility to provide and manage a device catalog:
  • Manufacturer.
  • Device type (based on SKUs).
• Device management:
  • Browsing of last n upstream messages for easy troubleshooting.
  • Battery and connection state management.
  • Firmware updates.
  • Possibility to add custom state information with flexible data model to devices (aka digital twin).

Signal Management

• Definition of signals (measuring points) based on parsed time series sensor data.
• Grouping of signals in a hierarchical structure.

Visual Data Analysis

• Creation of custom dashboards based on defined signals.
  • Consisting of multiple signals.
• Time based navigation over signals.
  • Date/ time range.
  • Relative ranges like 'last 24h' etc.

Alert Management

• Alerting based on monitoring rules applied to signals:
  • Threshholds min, max, hose.
  • Possibility to combine threshold with minimum hold duaration.
• Possibility to add/ remove custom alerts for single signals dynamically through the API.

Notificiations

• Channels:
  • e-mail.
  • Text messages (SMS).
  • Chat systems like slack.
  • Customizable templates and content.
• Push notifications for apps.

Location Management

• Management of hierarchical locations:
  • GPS coordinates.
  • Extensible with custom attributes.

Data Sources

• Generic REST based ingestion.
• The Things Network (TTN) adapter:
  • Data ingestion.
  • Device registrations.
• Generic MQTT adapter (for LTE/ NB-IoT).

Data Processing

• Flexible device type based payload parsing/ decoding based on device type from device management.
  • Support for different data types such as number, decimal, boolean.
• Downsampling of time series data.
• Archiving and purging of old data based on staleness rules.
• Notion of hot data set and cold data set.
• Possibility to create synthetical signal derived from existing signals.
  • custom functions/ calculations on existing signals (for example for the battery level case or connection state).
  • Joining of existing signals.

API Layer

• Consistent API pane over all aspects should be possible.
  • Using GraphQL or REST.
  • Custom extensions for application specific resources.
• Support for objects (files).
• Filtering, pagination, sorting, relations.
• Support for rate limiting .
• For time series data:
  • Convenience date/ time range filters like 'last 24h'.
  • Possibility to dynamically reduce the resolution for efficient plots in the mobile app.
• Possibility to create API mashh-ups optimized for mobile App needs.
• Push Layer to inform running, active apps of data changes.

UI Generic Features

• Multi language, l10n, i18n.
• At least limited mobile devices compatibility.
• Single Page Application (SPA) architecture.
• Extensible with custom features (for example for managing positions of Windows).
• Custom theme consisting of colors, fonts and logos possible (corporate identity).

LoRaWAN Specific Features

• Support to run a custom network server and join server.

Volume Profile

• Number of sensors.
• Message size per transmission.
• Transmissions per hour.
• Messages per day.
• Cumulated required peak bandwidth.
• Amount of stored raw data per year.

Billing

• Monthly billing based on:
  • fixed amount,
  • consumption metric.
• Initial/ set-up fees.
• Tariffs:
  • Customer individual enterprise agreements.
  • Pre-defined plans.

Hosting/ Delivery Model

• SaaS or on premise.
• Based on Azure, AWS, IBM, Oracle, SAP Leonardo.
• Cloud provider agnostic.
• K8s friendly.
• DSGVO Compliant hosting possible.

Miscellaneous

• Open Source or commercial.
• Pricing model.
• References.
• Developer documentation.
• Commercial consuling/ support available.