00IoT Application Platform

Connect your machines once.

One platform for industrial IoT projects: assets, telemetry, automations, dashboards, device management and OTA. The domain logic arrives as installable Solution Packs, not as a new build for every customer.

See how it worksProduct and architecture concept · in development

01Connect: any sensor, machine or existing system
02Model: the physical world as digital assets
03Understand: telemetry, events, analytics and AI
04Automate: physical events into business workflows
05Operate: provisioning, fleet, OTA, device health

01The problem

Every IoT project rebuilds the same stack

Hardware, ingestion, device management, permissions, dashboards, alerts, workflows and OTA are the same every time. Only the domain logic changes.

The usual path

Customer requestNew backendNew frontendNew databaseNew deployment

01
Rebuilt per customer
A new backend, frontend, database and deployment for requirements that are largely identical to the last project.
02
Months before value
The domain problem the customer actually cares about is the last thing that gets built.
03
Nothing compounds
Each project leaves behind bespoke code that the next project cannot reuse.

02The insight

The common part is a product, not a project

Build the common part once, as a platform. Deliver the domain logic as configuration and installable packs.

“Most B2B IoT projects are not actually unique. What changes is the domain logic.”

Each piece is already validated in the market, but only ever in isolation.

AWS IoT
fleet provisioning, device jobs
Azure IoT Operations
edge data flows
ThingsBoard
multi-tenant devices & dashboards
Eclipse Ditto
digital twin abstraction

The opportunity is the packaging: one customizable B2B product instead of a toolbox of cloud services.

03The product

Applications get assembled, not written

Three deployments, three compositions, one codebase. Custom development turns into composition, and the marginal cost of the next customer collapses.

Base platform

Solution Pack

Customer branding

Configuration

one fixed platform · everything else configured

Airport occupancy
- Base platform
- Occupancy Pack
- People-counter edge plugin
- Customer branding
Factory maintenance
- Base platform
- Predictive Maintenance Pack
- Siemens S7 plugin
- SAP connector
Device fleet
- Base platform
- Fleet Management Pack
- OTA management
- Custom device driver

The path with IoT Cloud

Create tenantSelect Solution PackConfigure assetsCustomize dashboardsAdd workflowsDeploy

A large share of customer requirements becomes solvable without code.

04Core abstraction

Model assets, not devices

This one decision is what makes every later plugin reusable across customers and industries.

asset graph

Airport
└── Terminal 1
    ├── Security
    │   ├── Zone A
    │   │   ├── Camera Counter 01
    │   │   └── Camera Counter 02
    │   └── Zone B
    ├── Escalator 12
    │   ├── Motor
    │   │   ├── Temperature
    │   │   ├── Vibration
    │   │   └── Current
    │   └── Controller
    └── HVAC

A single graph, not a device list
Every node carries properties, telemetry, commands, relationships and capabilities.
Plugins ask for capabilities
Not for MQTT topics, Modbus registers or database tables.
Protocol independence
Vibration is vibration, whether it comes from our probe, a Siemens PLC or an HTTP API.

give me an asset that provides:

vibrationtemperaturerpm

05Architecture

Five layers, one product

A predictive-maintenance pack lives almost entirely in the application layer. It never sees a certificate, a broker or a database schema.

Application

Dashboards
Apps
Analytics
Workflows
Reports
Alerts
Integrations

Control

Tenants
Assets
Users
Plugins
OTA
RBAC
Config
Twins
Audit
Billing

Data

MQTT
HTTP
OPC-UA
Modbus
BLE
LoRa
→ normalize
enrich
route
store

Edge

Gateway runtime
Drivers
Local rules
Offline buffer
Containers
OTA agent

Hardware

Gateways
Sensor probes
Customer-owned equipment

06Extensibility

Ten plugin types, one runtime

Far more powerful than letting customers build dashboard widgets, and the foundation for a partner ecosystem later.

device driver
Communicate with equipment
Siemens S7
protocol
Add connectivity
Modbus TCP
decoder
Interpret payloads
Bosch sensor payload
transformer
Convert and enrich data
ADC → °C
analyzer
Analyze telemetry
vibration anomaly detection
automation
Add actions
create a maintenance ticket
connector
External systems
SAP, Jira, Teams
ui widget
Visualization
vibration spectrum
application
Complete solution
predictive maintenance
edge plugin
Gateway-side functionality
camera people counter

Plugins run isolated in a sandboxed runtime with explicit permissions, never imported into the core backend. The same plugin can declare itself as runtime: cloud, runtime: edge or both.

07Capability matching

Install a pack, pick the machines, done

The platform reads what a pack requires and matches it against what your assets expose. No MQTT topics, no manual wiring.

plugin.yaml

name: predictive-maintenance
version: 1.3.0

requires:
  capabilities: [vibration]

optional:
  capabilities: [temperature, rpm]

provides:
  metrics: [health_score, anomaly_score]
  events: [anomaly_detected]

ui:
  widgets: [vibration_chart, machine_health]

install · step 2 of 3

Which assets should this pack monitor?

Compressor 01vibration
Compressor 02vibration
Conveyor Motor 04vibration
HVAC Fan 02no vibration

The first three match because their assets expose vibration. That is a much better experience than configuring MQTT topics by hand.

08Go to market

Solution Packs are what customers buy

Underneath, each pack is a bundle of plugins: analyzer, workflow, dashboard, widgets, notification rules and report template.

Predictive maintenance
vibration analysis, alerts, maintenance dashboard
Energy management
consumption, peak detection, reports
Occupancy
counters, zones, occupancy dashboard
Indoor climate
temperature, humidity, CO₂, alarms
Cold chain
temperature monitoring, reports, compliance
Machine monitoring
state, OEE, downtime
Device fleet
OTA, logs, remote commands
Asset tracking
BLE / UWB / GPS tracking

Inside the Predictive Maintenance Pack

Vibration Analyzer
Machine Health Model
Maintenance Workflow
Health Dashboard
Maintenance Widget
Notification Rules
Report Template

09Edge runtime

The edge is where privacy and bandwidth are won

The gateway runs a full edge runtime: agent, local broker, drivers, buffer, rules, containers and OTA. Not just an MQTT forwarder.

On site

CameraGatewayPeople-detection plugin

{ "occupancy": 17 }

Cloud

One integer per zone, not a video stream.

Video never leaves the site
Only a number crosses the network. The privacy conversation is over before it starts.
Keeps running offline
Local rules, local twin cache, store & forward. Factories and airports lose connectivity; the site does not stop.
Heavy work stays local
FFT, ML inference, protocol translation, filtering and aggregation all run on the gateway.

Edge runtime

Device agent
Local MQTT broker
Protocol drivers
Local twin cache
Data buffer
Rules engine
Plugin runtime
Container runtime
OTA agent
Secure cloud link

10Hardware

One gateway, modular probes, zero-touch setup

Hardware stays deliberately small: one excellent gateway and one probe platform. The differentiator is the out-of-box experience, not the bill of materials.

IoT Gateway

Connectivity: EthernetWi-FiBLERS485USB
Optional: LTECANLoRa
Platform: Secure element / TPMLinuxContainer runtimeLocal storage

MiniIndustrial5G

three variants, one edge runtime

IoT Probe

Core: MCUBLE / Thread / LoRaSecure identityBattery
Sensor interface: temperaturehumidityCO₂vibrationpressurecurrentcontact

ClimateVibrationEnergyOccupancyIO

five products, one platform

Zero-touch provisioning

1
Plug in Ethernet
2
Scan the QR code
3
Gateway appears in the cloud
4
Cloud pushes config & plugins
5
Sensors appear automatically

What the customer never touches:SSHCertificatesMQTT configVPNDocker Compose

11Customers

Three ways to sell the same platform

Multi-tenancy and white-labeling are not enterprise checkboxes. They are what turns integrators and OEMs into a distribution channel.

01
End customer
Wants an outcome
Buys hardware, a Solution Pack and configuration. Airports, factories, retail, logistics.
02
System integrator
Wants a platform to build on
White-labels the product under its own domain and brand, and builds customer solutions on the SDK.
03
Hardware manufacturer
Wants a backend
Uses the cloud as its device-management and app layer instead of building provisioning, OTA and dashboards.

White-labeling

Logo, colours, domain, login screen, e-mail templates, dashboard theme and mobile app branding. A system integrator can sell the product as its own IoT platform.

cloud.iot-platform.comiot.customer.com

12Deploy & operate

Run it anywhere, operate it centrally

Same software, one control plane. For an operations team this dashboard is the product they open every morning.

SaaS
our cloud
Private cloud
customer tenant
On-premise
inside the plant
Air-gapped
regulated sites
later

Fleet operations

devices online: 995 / 1000devices online
gateways offline: 3gateways offline
sensors low battery: 2sensors low battery
on old firmware: 7on old firmware
data delivery: 98.7%data delivery

Staged OTA
OS, agent, edge plugins, firmware, config and ML models. Five devices, then 20%, then 100%, with automatic rollback.
Full audit trail
Who changed which threshold and when. Which plugin raised which event, and why.

13Why us

Hardware, cloud and ecosystem as one system

There are plenty of IoT backends, gateway vendors and dashboard tools. The unattractive part for the customer is having to choose all of them separately.

Hardware

Gateway
Sensor probes
Secure identity
OTA

Cloud

Digital twin
Telemetry
Workflows
Analytics

Ecosystem

Plugins
Solution Packs
Connectors
Templates

We deliver sensor business outcome as one system.

14The plan

V1 is one end-to-end journey

Start as a modular monolith on Postgres + TimescaleDB, then split only the high-volume path.

GatewaySensorCloudDigital twinDashboardRuleNotificationOTA

First Solution Pack

Machine monitoring / predictive maintenance

It exercises nearly everything: gateway, sensors, timeseries, edge processing, analytics, alerts, workflows, dashboards, OTA and the asset model. Airport occupancy then becomes another composition of the same primitives.

Protocols: MQTTHTTPModbus TCPBLE
Widgets: timeseriesvaluestatusalarm
Storage: PostgreSQLTimescaleDB

Deliberately not in V1

Kafka
Kubernetes operators
ML platform
20 protocols
Marketplace
Mobile app
AI assistant
Custom query language

Years of infrastructure before a product is the failure mode. Ship the end-to-end journey first; the control plane and the high-volume data plane split apart later, when they actually scale differently.

15Status