IoT Platform Development

Secure device onboarding from factory floor to field deployment, with every device authenticated before it can publish data to the platform. Certificate-based mutual TLS authentication using X.509 device certificates issued by a private CA managed within the platform, each device provisioned with a unique certificate so a compromised device's certificate can be revoked without affecting the rest of the fleet. AWS IoT Core or Azure IoT Hub as the managed message broker layer for teams on those clouds, with custom MQTT broker deployment (HiveMQ, EMQX, or Mosquitto) for teams requiring on-premises or air-gapped operation. Provisioning workflow for new device registration: device claims a certificate from the provisioning service using a bootstrap credential, receives its unique certificate and broker endpoint, and registers its metadata (device type, firmware version, hardware serial, deployment location) in the device registry, the process completing in under 5 seconds without manual backend intervention. OTA firmware update management: firmware version tracked per device; update packages published to the platform and pushed to individual devices or device groups with configurable rollout percentage (canary → staged → fleet-wide) and automatic rollback if the update causes the device to go offline. Fleet management dashboard: device status (online/offline/error), last-seen timestamp, connectivity health score, firmware version distribution across the fleet, and devices pending update, filtered by device type, location, and status.

Message broker architecture matched to your device fleet's protocol requirements rather than forcing your devices to adapt to a generic cloud service's constraints. MQTT configuration: topic hierarchy design ({tenant}/{site}/{device-id}/{measurement} structure for multi-tenant deployments), QoS level selection (QoS 1 for guaranteed delivery with acknowledgement, QoS 0 for high-frequency telemetry where occasional loss is acceptable), retained message configuration for last-known-value reads, and keep-alive settings calibrated to your devices' power budget and connectivity pattern. Industrial protocol integration: Modbus TCP/RTU and OPC-UA for PLCs, SCADA systems, and industrial sensors that predate MQTT, a protocol gateway (Node-RED, Kepware, or custom Python) translates readings from legacy equipment into the platform's MQTT topic structure so old hardware feeds the same data pipeline as modern IoT devices. Protocol translation for mixed fleets: a normalisation layer maps each device type's payload format (some devices publish raw binary, others publish JSON with proprietary field names) to a canonical platform schema before data reaches the storage layer. Apache Kafka as the message queue between the broker and the processing layer: decouples ingestion rate from processing rate so burst traffic from 10,000 devices sending simultaneously is buffered and processed at the database's sustainable write rate without data loss. CoAP for constrained devices with minimal power budgets; HTTP/REST for devices with adequate connectivity where simpler protocol support reduces firmware complexity.

Multi-tenant architecture for IoT products that serve multiple customers, sites, or business units from shared infrastructure with strict data isolation between tenants, the design pattern that lets you scale to hundreds of customers without multiplying infrastructure costs. Tenant isolation at every layer: at the MQTT broker level, each tenant's devices publish to a topic namespace prefixed by the tenant ID and broker ACLs enforce that tenant A's devices cannot subscribe to tenant B's topics; at the database level, a tenant ID column with row-level security (PostgreSQL RLS) ensures queries only return the requesting tenant's data even when the application layer passes no filter; at the application layer, every API endpoint validates the JWT's tenant claim against the requested resource before any database query executes. Tenant onboarding: a self-service workflow creates the tenant record, provisions the MQTT credentials namespace, initialises the device registry partition, and sends the tenant administrator's invite email, a new customer can start provisioning devices within minutes of signing up without manual infrastructure work. Per-tenant configuration: alert thresholds, notification recipients, dashboard layouts, data retention periods, and API rate limits configurable per tenant through the admin portal without code changes. White-labelling support: subdomain routing (customer.yourplatform.com) with per-tenant logo, colour scheme, and email sender identity so each customer sees a branded experience. Tenant usage metering: device count, message volume, storage consumption, and API call count tracked per tenant for billing and capacity planning.

Time-series data architecture scoped around your specific device count, messages-per-second rate, and data retention requirements before a line of code is written. Ingestion pipeline: MQTT messages arrive at the broker, published to an Apache Kafka topic partitioned by device ID, consumed by a stream processor (Apache Flink or Kafka Streams) that validates message schema, converts engineering units (raw ADC value to temperature in Celsius, raw counter to litres-per-minute), and writes normalised records to the time-series database. Time-series storage with TimescaleDB (the PostgreSQL extension that handles 100M+ rows with sub-second query performance via hypertable partitioning) or InfluxDB (for organisations wanting a purpose-built time-series engine separate from their relational database). Retention policies and continuous aggregates: raw readings retained at full resolution for 30-90 days; 5-minute averages retained for 1 year; hourly averages retained indefinitely, the downsampling strategy that keeps storage costs proportional to historical query patterns rather than retaining raw data indefinitely. Stream processing for real-time alerting: threshold evaluation runs on the stream at ingestion time so an over-temperature alert fires within 2 seconds of the reading arriving, not after the next dashboard refresh. Anomaly detection at ingestion time using statistical process control (3-sigma rolling window) to flag readings that deviate significantly from the device's recent baseline, surfaced as maintenance alerts before the condition causes failure.

Operational interfaces designed for the people who act on device data, not a generic operations console adapted from a cloud vendor's template. Real-time fleet map showing all device locations with status colour coding (green online, amber warning, red alarm, grey offline), clustered at higher zoom levels using supercluster, expanding to individual devices as the operator zooms in. Device detail panel: real-time readings for every sensor on the device, 24-hour trend chart with zoom capability, alert history, firmware version, and connectivity log. Exception queue for devices in alarm state: sorted by severity and duration with one-click acknowledgement, silencing, and resolution, the workflow that prevents operators from missing critical alerts buried in a list of lower-priority notifications. Alert rule configuration: threshold rules (above X, below Y, rate-of-change exceeding Z), duration rules (condition must persist for N minutes before alerting to suppress transient spikes), and composite rules combining multiple sensor conditions. Escalation chains: alert fires to operator via push notification; if unacknowledged in 10 minutes, escalates to supervisor via SMS; if unacknowledged in 30 minutes, pages the on-call engineer via PagerDuty integration. Mobile-responsive dashboard for field engineers who need real-time visibility on their phones without downloading a separate app. Role-based dashboard profiles: operators see their site's live status; managers see aggregated metrics across sites; executives see KPI summaries, each profile loading automatically on authentication.

REST API layer exposing device data, management operations, and alert configuration to your existing business systems, so IoT insights feed decisions in the tools your operations and maintenance teams already use rather than requiring them to learn a new interface. API design: RESTful endpoints for device registry CRUD, time-series data querying (point-in-time, range, aggregated), alert rule management, and command sending (reboot, configuration update, firmware trigger); authenticated via JWT or API key with per-key rate limits and scope restrictions; documented with OpenAPI 3.0 spec and a hosted Swagger UI. CMMS integration with Maximo, SAP PM, or ServiceNow: a device alarm event triggers a work order creation via the CMMS API with the device ID, alarm type, current readings, and recent trend data pre-populated in the work order, maintenance technicians arrive on-site with context rather than an empty work order. ERP integration via REST or message queue: daily production metrics (total output, runtime hours, downtime events, energy consumption per shift) exported to SAP or Oracle for operational reporting and cost allocation without manual data entry. Webhook support for event-driven integrations: configurable webhook endpoints fire on alarm state change, device connectivity change, or threshold crossing events, enabling downstream systems to react to device events in real time without polling the API. API versioning strategy with v1/v2 path prefixes and a deprecation policy that gives integration partners a minimum 12-month migration window before old versions are retired.