Skip to content
TechnologyTechnical deep dive

The stack, layer by layer.

For engineers evaluating whether this fits. Written as a description of the architecture rather than a summary of its benefits.

Signal path: gateways, sensors and interfaces feed C3F, then the edge layer, then SPIEngine, then applications.GatewaySensorInterfaceL1 · HARDWAREL2C3FframeworkL3Edgelocal logicL4SPIEngineoperationsL5Applicationsyour product
Architecture

Eight technical areas.

T1

Device layer

Hardware and firmware. Boards, radios, industrial interfaces and power design, brought up against a shared baseline so a new device inherits a working starting point.

  • · Embedded Linux and RTOS targets
  • · ARM-class platforms
  • · Peripheral and interface bring-up
  • · Power and thermal design
  • · Production programming and test
T2

Communication layer

The protocols a device has to speak, handled once inside the framework rather than reimplemented per product.

  • · MQTT over TLS
  • · Bluetooth Low Energy
  • · Ethernet / IP
  • · RS485
  • · Modbus RTU and TCP
  • · UART, SPI, I²C
  • · Cellular (device dependent)
T3

C3F

Hardware abstraction, protocol management, device services and lifecycle. The layer that makes device software portable between boards and products.

  • · Hardware abstraction
  • · Device services
  • · Configuration model
  • · Telemetry normalisation
  • · Structured diagnostics
  • · Module system
T4

Edge

Processing kept close to the data. Rules, conversion and buffering that let a site keep working when the link does not.

  • · Rules and event handling
  • · Protocol conversion
  • · Local aggregation
  • · Store and forward
  • · Offline operation
  • · Local control
T5

Cloud — SPIEngine

Multi-tenant device operations: registry, telemetry pipelines, configuration, updates, alerting and audit.

  • · Device registry
  • · Telemetry ingest and retention
  • · Command dispatch
  • · OTA orchestration
  • · Alerting
  • · Tenant separation and RBAC
T6

APIs and integration

The platform is designed to sit inside a wider architecture, not to replace it.

  • · REST API
  • · MQTT interfaces
  • · Webhooks
  • · External cloud integration
  • · Customer PKI / CA compatibility
T7

Security

Identity, transport, access and audit treated as platform services. See the security page for the full picture.

  • · Device identity
  • · Certificate-based trust
  • · Encrypted transport
  • · Role-based access control
  • · Signed firmware
  • · Session and change audit
T8

Operations

What it takes to keep a fleet healthy after launch — the part that is usually underestimated.

  • · Fleet monitoring
  • · Staged OTA rollout
  • · Remote diagnostics
  • · Brokered terminal access
  • · Configurable data retention
  • · Lifecycle and decommissioning

Protocol and interface availability varies by device. Product pages list what each device supports, and hardware-dependent values that have not been verified are marked rather than estimated.

Send the technical questionnaire.

Platform capabilities are answered directly. Hardware-dependent items are flagged for verification instead of being filled in optimistically.