IoT systems and device fleets

Device fleets

A pilot of ten devices can be managed by hand. A fleet cannot. We design fleets around three records for every device: its identity, its configuration and its health. Each device gets a unique certificate at manufacture or first boot, ideally held in a secure element, so a stolen key affects one device and not the fleet. Configuration lives in the cloud as a desired state and each device reports its actual state, so drift is visible and can be fixed remotely.

MQTT messaging

MQTT is a lightweight publish-subscribe protocol built for unreliable networks. Devices publish to topics on a broker and services subscribe to what they need. We design topic structures that scale and stay readable, and choose a quality-of-service level per message type: QoS 0 for frequent telemetry, QoS 1 for alarms and commands. Retained messages hold the last known state, and a last will message tells the platform when a device drops off unexpectedly. MQTT 5 adds message expiry, shared subscriptions and reason codes, which help at fleet scale.

Brokers can be managed cloud services or self-hosted options such as Mosquitto or EMQX, chosen on cost, scale and where your data has to stay.

Choosing the connection

The radio decides battery life, running cost and what a device can send. Wi-Fi and Ethernet suit powered equipment inside buildings. LTE-M and NB-IoT suit scattered devices within mobile coverage. LoRaWAN suits many low-rate sensors across one site, and satellite IoT reaches places nothing else does. Many fleets mix two or three of these, so we keep the message format the same across all of them and let the gateway or network server handle the difference. Our long-range comms page covers the trade-offs in detail.

Over-the-air updates, designed to fail safe

Every device in the field will need new firmware at some point. A failed update on a device two hours' drive away is expensive, so updates are safe by default:

• Signed images. Devices accept only firmware signed with your key.
• A/B slots. The new image installs beside the running one. If it fails to boot or check in, the device rolls back. Bootloaders such as MCUboot support this pattern on microcontrollers.
• Staged rollouts. Updates go to a small group first, then widen as health checks pass.
• Delta updates. Sending only the changed bytes keeps updates practical over slow or metered links. Over LoRaWAN, updates are possible but slow, so we keep images small and schedule them.

Edge gateways

Plants and sites often run equipment that speaks Modbus, OPC UA, CAN or Bluetooth Low Energy rather than MQTT. An edge gateway translates those protocols, filters and buffers data locally and forwards it securely. It can also run rules and models on site, so an alarm still fires when the internet link is down. We build gateways on industrial Linux hardware and manage them like any other device in the fleet.

Predictive maintenance

Many machine faults give warning before they cause a stoppage. Vibration rises, a bearing runs hotter or a motor draws more current for the same work. We fit sensors that measure these signals, compare them with each machine's own baseline and alert when the trend points to a fault. Vibration limits can follow condition monitoring practice such as the ISO 20816 series. Over time, labelled failures let us train models that estimate remaining useful life, so maintenance can be planned around production instead of interrupting it.

Dashboards and operations

Operators need to see the fleet at a glance: what is online, what is alarming and what needs a visit. We build dashboards for that job, with drill-down to each device's history, firmware version and signal quality. Security monitoring sits alongside: certificate expiry, unexpected reconnects and failed logins all raise alerts. We follow security guidance from the Australian Signals Directorate's Australian Cyber Security Centre.

Questions