Building Industrial IoT Solutions with MQTT and AWS IoT Core

Industrial IoT Requirements

Industrial IoT (IIoT) has different requirements than consumer IoT. Reliability is paramount — a factory monitoring system can't miss critical sensor readings. Security is critical — industrial control systems are high-value targets. Protocol diversity is the norm — factory floors have equipment from decades of vendors using Modbus, OPC-UA, Profinet, and proprietary protocols. And latency requirements vary — some equipment needs sub-second monitoring, while environmental sensors report every 5 minutes.

The architecture must handle all of these: reliable message delivery (MQTT QoS 1 minimum for critical data), mutual TLS authentication for every device, protocol translation gateways for legacy equipment, and edge buffering for connectivity outages (factory networks are unreliable).

Protocol Translation (Modbus to MQTT)

Modbus is the most common industrial protocol — it's been used since 1979 and runs on virtually all factory equipment. Modbus RTU (serial) and Modbus TCP (Ethernet) provide register-based access to device data. The gateway reads Modbus registers at configured intervals, maps register addresses to meaningful sensor names, and publishes the data as MQTT messages.

The implementation: a gateway application (running on industrial hardware like a Menlo or Rugged Pi) uses a Modbus library to poll devices on a schedule. Register values are converted to engineering units (temperature in °C, pressure in bar, vibration in mm/s). The converted data is published to MQTT topics following a consistent naming convention: factory/{factory_id}/line/{line_id}/device/{device_id}/telemetry. This hierarchical topic structure enables efficient subscription filtering — a dashboard for Line 3 subscribes only to Line 3 topics.

Device Management and OTA Updates

AWS IoT Core's device management features handle fleet at scale. The device registry stores metadata for every device (model, firmware version, location, last-seen timestamp). Device shadows maintain desired and reported state — if a device is offline when a configuration change is requested, the shadow stores the desired state and the device applies it when it reconnects. Jobs provide OTA firmware updates — you create a job targeting specific devices, the job document contains the firmware URL and signature, and the device downloads and installs the update with rollback on failure.

Fleet-wise (AWS IoT FleetWise) provides a data model for vehicle and equipment fleets — define the signals you want to collect, and FleetWise handles the edge-to-cloud data pipeline with automatic batching and compression for bandwidth optimization.

Security for Industrial IoT

Industrial IoT security has three layers: device authentication (every device must prove its identity), transport encryption (all data in transit must be encrypted), and network segmentation (IoT devices should be on a separate network segment from corporate IT). AWS IoT Core uses X.509 certificates for device authentication — each device has a unique certificate and private key provisioned during manufacturing. The private key never leaves the device; all communication uses mutual TLS.

Certificate rotation is critical for long-lived deployments. AWS IoT Core supports just-in-time registration (JITR) for automated certificate provisioning at scale. For production, we provision unique certificates during device manufacturing and implement automatic rotation every 12 months. Compromised certificates can be revoked immediately through the IoT Core registry.

Real-Time Monitoring Dashboard

The monitoring dashboard displays real-time equipment status, sensor readings, and alerts. The architecture: MQTT messages flow through IoT Core rules to Timestream (for time-series storage) and AppSync (GraphQL API for the frontend). The frontend (React or Next.js) subscribes to AppSync real-time subscriptions for live updates and queries Timestream via the API for historical data and charts.

Alert rules are implemented as IoT Core rules that evaluate message payloads against thresholds. When a sensor reading exceeds a threshold, the rule triggers a Lambda function that sends notifications (SNS → email/SMS/PagerDuty) and creates an incident in the maintenance system. Alert deduplication prevents notification storms when a sensor oscillates around a threshold.

Reliability and Offline Operation

Factory networks are unreliable. Gateways must buffer data during outages and synchronize when connectivity resumes. The gateway stores unsent messages in a local SQLite database with timestamps. When the MQTT connection resumes, the gateway replays buffered messages in chronological order. AWS IoT Core's message broker handles the replay without data loss — messages are delivered in order with their original timestamps preserved.

For critical monitoring (safety systems, emergency shutdown), the edge system must operate independently of the cloud. Local alerting and control logic runs on the gateway even when disconnected. The cloud connection is for analytics, historical reporting, and management — not for real-time control of safety-critical systems. This edge-first reliability model is core to how our IoT development team designs industrial deployments, and our IoT hardware prototyping practice validates the gateway hardware against exactly these offline-operation requirements before mass rollout.