Edge fleet platform
Every device in the field. One platform.
InnovaEdge adopts, configures, and monitors industrial equipment, vehicle fleets, and the hardware you manufacture — telemetry, anomaly detection, and over-the-air updates, without replacing the systems you already run. One definition configures the device and parses what comes back, and the result is speakable as i3X, OPC UA, or Sparkplug — not a second modelling exercise after the fact.
MQTT-native · SSO, OIDC & MFA shipped · Your broker and your database, or ours
The problem
Dashboards are the easy part.
Getting a number onto a screen takes an afternoon. Keeping hundreds of devices correctly configured, reporting, and updated is the part that breaks.
Every IoT protocol is different.
CAN, OBD-II, MQTT, vendor APIs. Each integration becomes its own project with its own owner.
Config drifts silently.
A device that was set up correctly last quarter isn’t anymore, and nothing tells you which one.
Firmware updates are risky.
Pushing to hardware in the field with no staged workflow and no verification is how fleets go dark.
History disappears.
Without schema and retention control, telemetry is a live gauge instead of an asset you can query.
Who it is for
Four kinds of fleet. One control plane.
01
Industrial & equipment operators
You run machines that already emit data you can’t reach.
- Equipment discovery that fingerprints what is actually on the line
- Modbus read blocks you author per station, compiled for the device family you publish to
- Assets linked to the devices reporting on them
- Anomaly rules per table, evaluated continuously
- Retention you set per stream, not per vendor default
02
Vehicle fleets
You need more than a dot on a map.
- CAN bus scan and OBD-II PID sweeps per vehicle
- Live positions across the whole fleet
- Trips segmented out of position history, replayed on a slider
- A safety score off the same fixes, from harsh braking and idling
- Geofences evaluated on the device, so entry and exit still fire when the link is down
- Native telemetry from vehicles that support it
03
OEMs & device manufacturers
We run the device layer. You build the product on top of it.
- Provisioning, staged config and OTA for hardware you have shipped
- Raw bus output parsed into structured telemetry, not frames
- Telemetry written into a database you own — you keep the data
- Scoped API tokens so your own app reads the fleet
04
Partners & white-label
You resell to customers who need their own tenant.
- Customer organizations beneath yours, each a full tenant with the same isolation
- Usage pools across your tenants, so volume pricing applies to the total rather than to each one
- A device ceiling per tenant, enforced where devices are adopted
- Your brand, inherited by every tenant that does not set its own
- Adopt hardware as inventory, re-home it to the customer when it ships
Capabilities
What it actually does.
Not a roadmap. This is the platform surface today.
Fleet & lifecycle
Adoption & ownership
Devices announce themselves and are adopted into an organization. Ownership is an explicit, auditable record; unknown or conflicting identities go to quarantine rather than into an arbitrary account.
Onboarding that closes its own loop
A device reports the identity it will actually publish under rather than being told what it is, and the first configuration is triggered from the device side once it lands. The path from unconfigured hardware to a device reporting home completes without a person stepping in at each stage, and a device that arrives under the wrong identity is realigned rather than left in a silent deadlock.
One canonical device identity
A device is addressed by the identity the industry already uses for it, and that is the identity it publishes and is billed under. Vendor-specific keys — a manufacturer serial, a cloud provider's internal id — are resolved at the boundary and never become the identity your fleet is organised by, so moving a device between paths does not rename it.
Fingerprints & capability sets
Every device carries a hardware fingerprint and a queryable capability set, so "which of these can do X" is a query rather than a guess.
Profiles & smart groups
Reusable profiles applied and published to many devices, and smart groups that address sets of devices by what they are rather than by list.
Self-populating equipment discovery
An evidence-gated discovery run learns what is on a device's bus — CAN, or Modbus stations and registers probed in batches — and promotes what answered into a draft profile. Publishing that profile creates the matching twin equipment type as well, so one act fills both what the device reads and what the ontology knows the equipment is. The recipe library grows itself.
Recovery & diagnostics
Per-device recovery actions, LED indicator programs, WiFi profile workflows with retry and cancel, and a connectivity self-heal watchdog on the device itself. A field bootstrap credential can be minted, rotated and revoked so a device that has lost its way home can be brought back without a site visit.
Device clock integrity
A device whose clock is unset or skewed misdates every row it lands, silently corrupting every time-ordered read. Those devices are flagged with the consequence stated, not left to poison the history.
Configuration & OTA
Preview before publish
Read a device's config, its fully resolved config, or its stacked view — with a dry-run diff and a per-device plan — before anything is written.
Stacked, versioned configuration
Device-specific overrides sit on top of shared profiles and you can see which layer supplied each value. Each table module carries its own monotonic version.
Desired-versus-running reconciliation
Devices report the exact table versions they loaded. The fleet view distinguishes applying, missing, rejected, version-drift and synchronized rather than assuming delivery equals effect.
OTA with staged verification
Firmware and agent bundles served per device and per model over TLS, staged through onboarding, upgrade and decommission with a verification step between stages.
Chunked, resumable OTA over thin links
A bundle is served in byte ranges and pulled one socket-sized chunk at a time, verified against a manifest, and resumed from where it stopped rather than restarted. Progress is reported per device while it runs, so a slow cellular update is visible instead of silent.
Last-good rollback
A device retains its last-good fragment through a transient failure and reports what it is actually running, so a bad push degrades instead of going dark.
Visual flow authoring
Wire a flow of source, transform, gate and report nodes on a pan-and-zoom canvas — CAN frames, OBD-II PIDs, GPS, Modbus registers, BLE tags, digital and analog IO. It compiles to the same table definition the form editor produces and deploys down the same path, so it is a second way to author one contract rather than a second contract.
Staged rollout campaigns
Target a cohort, define the rollout, and attach the workflows that carry it out so an update reaches a defined subset on a defined path before it reaches all of it. Waves publish, then soak for an observation window before the next wave begins.
Direct command channel
Queue a command for a device and it is pulled and run once, acknowledged over MQTT. A monotonic sequence per device means a re-queue forces a re-pull and a device cannot silently replay or skip a command.
Power & sleep as a compiled profile
Sleep behaviour is authored once and compiled per device family, because the families genuinely differ — what is a cyclic low-power setting on one is an alarm-gated runtime action on another. You describe the behaviour you want; the platform emits whatever that family actually needs.
Platform-owned device defaults
The on-device engine holds no defaults of its own. Device naming, transport topics and QoS, sample and report schedule, connectivity mode, status LEDs and the recovery watchdog all live in one profile the platform stamps into every pushed config, so a device is never running a default nobody chose.
Telemetry data platform
One definition, both sides
A table definition tells the device what to acquire and when to report, and tells the platform how to parse and store the result. Device config and database schema are compiled from the same module, so they cannot drift apart.
Schema & retention control
Inspect a table's schema, rename or drop columns, and set retention per table on your policy — without losing the stream while you do it.
Catalogs & enrichment
CSV/XLSX uploads or a linked live database joined onto raw telemetry by device key, so rows arrive already carrying the customer, asset or contract record you hold. Connecting a catalog to a twin type suggests a column for each field with a confidence on the match, for you to accept or correct; a field with no close enough column is left blank rather than guessed at.
Your broker, your database
Bring your own MQTT broker and your own Postgres sink, or use the managed ones. A broken private sink fails visibly — customer data is never quietly redirected into platform storage.
Data-quality expectations
Per-table expectations with quarantine for rows that fail them, plus medallion tiers, so a bad sensor does not silently become a trusted number.
Durable sink spool & replay
Writes that a private sink cannot accept are spooled and replayed rather than lost, with backlog and dead-letter counts surfaced instead of hidden.
Digital twin
Typed equipment & location models
User-defined equipment and location types built from a closed primitive set, with references, GeoJSON geometry and versioning. Model and instance are separate, as they are in a plant historian.
Instances & relationship graph
Asset instances with a navigable relationship graph and lineage, and a single-home device-to-equipment edge so it is never ambiguous which asset a reading describes.
Typed, audited actions
Every change to a twin object or the device-to-equipment graph flows through one typed action rather than a scatter of bespoke endpoints. Each call is validated, permissioned, and written to the organization audit trail with its provenance, so what changed, who changed it and why is answerable after the fact.
Interoperability
CESMII i3X 1.0 server
A full i3X 1.0 server including subscriptions over SSE, with value writeback to devices through settables. Not an export — a live interface your plant systems talk to. Each tenant's type library gets its own namespace URI, so an outside consumer can tell one organisation's types from another's instead of every tenant authoring into one shared identifier.
OPC UA NodeSet & i3X import
Bring an existing i3X namespace or OPC UA NodeSet2 in and its object types register alongside your own. An i3X import carries each type's schema; a NodeSet2 XML brings the type names, so variables and hierarchy are still modelled here.
OPC UA NodeSet2 export
The twin model exported as a standards-conformant OPC UA NodeSet2 information model.
W3C WoT Thing Description export
Devices described as W3C Web of Things Thing Descriptions, so a consumer that speaks WoT needs no InnovaEdge-specific knowledge.
Sparkplug B / UNS egress
Publish into a Unified Namespace as Sparkplug B, on demand or continuously, so InnovaEdge slots into a plant architecture instead of demanding to be its centre.
Kafka northbound egress
Landing telemetry produced to your own Kafka cluster, table by table, under a topic prefix you choose. A per-table cursor on the ingest timestamp advances only after a produce succeeds, so a broker outage replays the window rather than losing it — at-least-once, which means a consumer has to tolerate seeing a row twice.
Modbus RTU authoring & register discovery
Modbus RTU authored as an acquisition workload — bus, station range, timing, and read blocks whose register map can be pasted in from a spreadsheet — and compiled for each device family when the table is published. A dry run reports what one cycle costs on the target you pick and states that the FOX adapter expands a block into individual station and register reads; active serial execution on the Linux adapter is still gated on hardware certification. A batched sweep probes a register range station by station, keeps only the registers that answered, and promotes those into a draft profile whose signals preview their decoded value from a sample through the same transform vocabulary the device runs.
Tenancy & identity
Organization isolation
Every request resolves against your organization. Fleet, tables, charts and audit are scoped to it, each organization owns a stable physical telemetry namespace, and device ownership is fail-closed.
Native identity, SSO and MFA
Argon2id passwords, verified email, invitations, four roles, TOTP MFA, and OIDC single sign-on scoped to your organization so access follows the directory you already run.
Immutable audit stream
A per-organization audit event stream over the state-changing surface, plus failed authorization and failed sign-ins. Exportable as a support bundle.
Usage visibility
Broker messages, bytes, sink storage and active devices metered per organization and visible to you, so what you are billed for is something you can check rather than take on trust.
Scoped machine API keys
Long-lived keys for scripts and integrations, separate from login sessions. A key carries scopes that can only narrow the permissions of the person who issued it, is shown once and stored as a hash, so an integration credential can never quietly outrank its owner.
How it works
Four steps to a managed fleet.
Step 01
Adopt
Point a device at the platform. It reports a fingerprint and its capabilities, and you adopt it into an organization.
Step 02
Configure
Build config from profiles and equipment recipes, preview the result, then publish it stacked to the device.
Step 03
Watch
Telemetry lands in tables with retention and anomaly rules. Charts and notification channels follow from there.
Step 04
Update
Ship OTA artifacts through staged workflows, verifying each device before the next stage begins.
Pricing
What it costs, before you talk to anyone.
A monthly platform fee for the operations layer, plus a metered device floor billed only on the days a device actually connects. Every rate is published — no “contact us for pricing” on the tiers where we can quote you a number.
Connect
$149/mo
25 devices included
Operate
$1,200/mo
150 devices included
Integrate
from $4,500/mo
1,000 devices included
Ultimate
from $12,000/mo
10,000 devices included
Book a demo
Tell us what you operate.
We will walk the platform against something close to your fleet. If it isn’t a fit, we will tell you that instead of selling you a pilot.
- Live A walkthrough of the running platform against real fleet data, not a slide deck.
- Scope Industrial equipment, vehicle fleets, and OEM hardware.
- Included Multi-tenancy, SSO, and audit trails are part of the platform, not add-ons.
We use this to prepare the walkthrough and to reply. Nothing else.