A Wish List for your next IoT-Platform

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.