Digital product engineering · IoT
IoT platform development
We develop IoT platforms for companies that need to manage fleets of connected devices and use their data: a device registry and secure provisioning, connectivity over MQTT and other protocols, telemetry storage, device twins, rules and alerts, orchestration of over-the-air updates and APIs into your enterprise systems. We build the software and integration around your devices, and you own the code.
Checklist · IoT and devices
Industrial IoT and device integration checklist
A checklist for projects that connect devices, machines and sensors to software: use case, device inventory, protocols, gateways, data model, security, lifecycle and enterprise integration.- 01Eight areas to settle before you connect a fleet of devices or a plant.
- 02The device and signal facts that integration teams always need.
- 03Security and update items that are hard to add later.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Device registry
Every device with its identity, type, firmware version, owner, location, tags and lifecycle state, searchable and linked to customers and assets. - 02
Secure provisioning
Onboarding of devices with certificates or pre-shared keys, bulk and zero-touch enrolment, and revocation when a device is lost or retired. - 03
Connectivity and protocols
Brokers and gateways for MQTT, HTTP, CoAP and LwM2M, with authentication per device, topic-level permissions and support for constrained and intermittent links. - 04
Telemetry ingestion and storage
Validation and decoding of messages, time-series storage at the right resolution and retention, and replay of data after an outage. - 05
Device twins
A synchronised representation of each device's reported and desired state, so applications can read and set configuration whether or not the device is online. - 06
Rules, alerts and automation
Conditions on streams and states that raise alerts, open tickets or trigger actions in other systems, with throttling and escalation. - 07
Commands and configuration
Remote commands and configuration changes with delivery tracking, timeouts, approval for risky actions and an audit record. - 08
Over-the-air updates
Orchestration of firmware and software updates in staged rollouts, with health checks, automatic pause and rollback, using the device's own update mechanism. - 09
Applications, APIs and multi-tenancy
Dashboards, public APIs and webhooks, and tenant separation for platforms serving several customers or business units.
Reference architecture.
Standards and interfaces
What we design against.
- MQTT 5 and Sparkplug B
- Publish and subscribe messaging for devices, with Sparkplug defining topic structure and state handling for industrial data.
- LwM2M and CoAP
- Device management and constrained-device protocols for cellular and low-power devices.
- OPC UA
- Industrial interoperability standard used where devices are controllers and machines.
- W3C Web of Things
- Thing descriptions that define a device's properties, actions and events in a machine-readable way.
- ETSI EN 303 645 and IEC 62443
- Security baselines for consumer and industrial connected devices, used as the checklist for identity, updates and data protection.
- X.509 and device identity
- Certificate-based device identities, with secure elements or trusted platform modules where the hardware supports them.
Data model
The core entities.
- Device
- Identity, type, firmware, location, owner, tags, state and the credentials it uses.
- Device twin
- Reported and desired properties, versions and last-seen time.
- Telemetry point
- Device, metric, value, unit, time and quality, stored by retention policy.
- Event and alert
- Rule, device, severity, state, acknowledgement and resolution.
- Command
- Target, payload, status, timeouts and the user who issued it.
- Update campaign
- Target group, version, stages, success measures and any rollback.
- Tenant and entitlement
- Customer or unit, devices, users and the data they may access.
When custom development is the right call.
Controls designed in, not added later.
Strong device identity
A unique credential per device, protected in hardware where possible, with revocation and rotation.Least-privilege messaging
Each device can publish and subscribe only to its own topics, and platform components use scoped service accounts.Secure updates
Signed images, staged rollout, health checks and automatic rollback so a bad update cannot brick a fleet.Data protection
Encryption in transit and at rest, tenant isolation and retention rules for personal or commercially sensitive data.Fleet monitoring
Anomaly detection for devices behaving unusually, such as unexpected connections or message volumes.
From discovery to a system you run.
- 01
Fleet and use case review
We list the devices, the data they produce, the decisions that data supports and the systems that need it. - 02
Architecture and security design
Connectivity, identity, device model, storage and integration are agreed with the device, security and application teams. - 03
Build the core and connect a pilot fleet
Registry, provisioning, ingestion and twins go first, connected to a small fleet in real conditions. - 04
Add rules, updates and applications
Alerts, commands, update orchestration and applications are added and tested at pilot scale. - 05
Scale the fleet
The fleet grows in stages, with load tests, monitoring and support processes proven at each step.
Relevant work
Where to see our work.
Common questions.
- Do you design the devices?
- No. We build the platform software and the integration around devices: connectivity, identity, data, twins, updates and applications. Electronics and firmware design stay with your hardware team or vendors, and we agree the interfaces with them.
- Should we use a cloud IoT service or build our own platform?
- Start with a cloud service unless a requirement rules it out. Building makes sense for air-gapped or regulated environments, very large fleets where unit cost matters, or when the platform is your product.
- How do you handle devices that are offline most of the time?
- Twins hold the desired state until the device connects, commands have timeouts and retries, and devices buffer data and send it with its original timestamp.
- How are firmware updates made safe?
- Updates are signed, rolled out in stages to a small group first, monitored with health checks and paused or rolled back automatically if the group misbehaves.
- Who owns the code and the data?
- You do. The code, the data and any models stay yours.