The SPIDEX platform.
From the board in the enclosure to the application your customer signs off on — one stack, designed to be reused across every connected product you ship.
Work down the stack.
Each layer solves a problem the layer above should never have to think about. Select a layer to see what it owns.
Applications
On top of the same foundation, teams build the part that is genuinely theirs: the domain logic, the workflows, the customer-facing product. Everything below it is already solved, tested and deployed.
- ·Industrial monitoring
- ·Asset and fleet operations
- ·Energy and infrastructure
- ·Logistics and tracking
- ·Environmental monitoring
- ·Specialised enterprise systems
SPIEngine
SPIEngine is where a fleet is operated. Devices are provisioned into a registry, monitored, configured, updated and reached remotely — the same way whether the fleet is two hundred units or fifty thousand across several sites.
- ·Provisioning and registry
- ·Fleet monitoring
- ·Telemetry pipelines
- ·Remote commands
- ·Configuration management
- ·OTA firmware updates
- ·Secure remote access
- ·Alerts, APIs and integrations
Edge
Work that should not travel to the cloud stays on the device. Rules run locally, data is normalised and converted at source, and store-and-forward keeps a site operating through a link outage without losing readings.
- ·Rules and event handling
- ·Protocol conversion
- ·Data normalisation
- ·Edge analytics
- ·Offline operation
- ·Store and forward
- ·Local control loops
- ·Device health checks
C3F
C3F is the device-side software foundation every SPIDEX device runs. It abstracts the hardware underneath and exposes one consistent model for communication, configuration, telemetry, control and lifecycle — so device software becomes configuration rather than a rewrite.
- ·Hardware abstraction
- ·Protocol management
- ·Command and control
- ·Telemetry normalisation
- ·Diagnostics and logging
- ·Secure identity
- ·Firmware lifecycle
- ·Pluggable modules
Hardware
SPIDEX hardware is the physical end of the platform. Gateways, BLE devices, industrial bridges and tracking units are built on shared boards, shared interfaces and a shared bring-up process, so a new device starts from a working baseline rather than a blank schematic.
- ·Industrial gateways
- ·BLE sensing and proximity
- ·Modbus, RS485 and RFID interfaces
- ·Asset tracking and telemetry units
- ·Timing and specialised systems
- ·Custom device platforms
What each layer owns.
Hardware
Gateways, sensors, interfaces, trackers
SPIDEX hardware is the physical end of the platform. Gateways, BLE devices, industrial bridges and tracking units are built on shared boards, shared interfaces and a shared bring-up process, so a new device starts from a working baseline rather than a blank schematic.
C3F
Common Communication & Control Framework
C3F is the device-side software foundation every SPIDEX device runs. It abstracts the hardware underneath and exposes one consistent model for communication, configuration, telemetry, control and lifecycle — so device software becomes configuration rather than a rewrite.
Edge
Local processing and autonomy
Work that should not travel to the cloud stays on the device. Rules run locally, data is normalised and converted at source, and store-and-forward keeps a site operating through a link outage without losing readings.
SPIEngine
Device and cloud operations
SPIEngine is where a fleet is operated. Devices are provisioned into a registry, monitored, configured, updated and reached remotely — the same way whether the fleet is two hundred units or fifty thousand across several sites.
Applications
The product your customer actually uses
On top of the same foundation, teams build the part that is genuinely theirs: the domain logic, the workflows, the customer-facing product. Everything below it is already solved, tested and deployed.
How the platform is decided.
Reuse below, difference above
Anything that every connected product needs belongs in the platform. Anything that makes a product distinct belongs to the product.
One operational model
A gateway, a battery sensor and a vehicle tracker are provisioned, monitored, configured and updated the same way.
Architect for scale, implement for launch
A pilot should not carry the weight of an enterprise rollout — but it must not need a rewrite to become one either.
Standards at the boundaries
MQTT, REST and established industrial protocols at the edges, so the platform fits into architectures it does not control.
Deployment follows the customer
Where data lives is a customer decision. The platform is built to be deployed accordingly, including in-country and on-premise.
Operability is a feature
Diagnostics, update paths and audit trails are designed in, not retrofitted after the first field failure.
Build the next connected system on a foundation that already works.
Tell us what you are building and at what scale. We will tell you honestly which parts of the platform apply, and which parts you would still need to build.