IoT Gateway Architecture: Mermaid Flowchart

IoT Gateway Architecture flowchart diagram

About Source

An IoT gateway is a network node that sits between field-level devices and a cloud platform, providing protocol translation, local data processing, device management, and secure uplink — enabling heterogeneous devices that speak different protocols to integrate with a unified cloud backend.

Field devices span a wide range of communication protocols. Legacy industrial equipment speaks Modbus RTU over RS-485 or OPC-UA over Ethernet. Newer consumer-grade sensors use MQTT over Wi-Fi. Battery-powered edge nodes may use LoRaWAN or NB-IoT for wide-area low-power communication. The gateway must present a consistent interface to the cloud regardless of this diversity.

The gateway's protocol adapter layer runs one connector per southbound protocol. Each adapter subscribes to or polls the devices in its domain, normalises the data into a canonical internal format (often a JSON object with standard fields: device ID, timestamp, metric name, value, unit), and publishes to the gateway's internal message bus. This bus decouples adapters from upstream processing logic.

A local processing engine consumes messages from the bus and applies configured transformations: unit conversion, tag enrichment (adding site ID, equipment type, asset number), dead-band filtering (suppressing updates where the value hasn't changed significantly), and time-series downsampling. Processed messages are placed onto an outbound queue with at-least-once delivery semantics backed by local persistent storage.

The cloud uplink component dequeues messages and forwards them over a TLS-encrypted connection to the cloud IoT platform — AWS IoT Greengrass, Azure IoT Edge, or a custom MQTT bridge. The gateway maintains a local device shadow (a JSON document of last-known device state) that can be served to local dashboards even when the WAN connection is interrupted. For what happens downstream of the gateway at the cloud ingestion layer, see IoT Telemetry Pipeline. For edge computation running on the gateway itself, see IoT Edge Processing. For the full device-to-cloud journey, see IoT Device Data Flow.

Frequently asked questions

An IoT gateway is a network node that sits between field devices and a cloud platform, providing protocol translation, local data processing, device management, and a secure WAN uplink. It enables heterogeneous devices speaking different protocols — Modbus, OPC-UA, MQTT, LoRaWAN — to integrate with a single cloud backend without each device needing its own internet connection.

Protocol adapter modules poll or subscribe to field devices in their respective protocols and normalise readings into a canonical internal format. These messages flow through a local processing engine that applies filtering, enrichment, and downsampling before being placed on an outbound queue backed by persistent storage. A cloud uplink component forwards queued messages over TLS to the cloud platform, and a local device shadow serves current state to local consumers even when the WAN is unavailable.

Use a gateway when devices speak incompatible protocols that cannot connect directly to the cloud, when local latency requirements demand processing that cannot wait for a cloud round trip, when WAN bandwidth must be conserved by aggregating or filtering before upload, or when a local dashboard must remain available during cloud outages.

Common mistakes include relying on the outbound queue without persistent storage backing, so messages are lost when the gateway reboots during a connectivity gap. Others are running all protocol adapters in a single process so one failing device type crashes ingestion for all others, neglecting certificate rotation for the cloud uplink, and not implementing dead-band filtering so unchanged sensor values are retransmitted continuously.

mermaid

flowchart TD
    subgraph Field[Field Devices]
        Modbus[Modbus RTU\nRS-485 sensors]
        OPCUA[OPC-UA\nIndustrial PLC]
        MQTT[MQTT Wi-Fi\nSmart sensors]
        LoRa[LoRaWAN\nBattery nodes]
    end

    subgraph GW[IoT Gateway]
        ModbusAdapt[Modbus adapter]
        OPCAdapt[OPC-UA adapter]
        MQTTAdapt[MQTT adapter]
        LoRaAdapt[LoRaWAN adapter]
        Bus[Internal message bus\nCanonical JSON format]
        Processing[Local processing engine\nFilter / enrich / downsample]
        Shadow[Local device shadow\nLast-known state store]
        Queue[Outbound queue\nPersistent at-least-once]
        DevMgmt[Device management\nProvisioning / config]
    end

    Modbus --> ModbusAdapt
    OPCUA --> OPCAdapt
    MQTT --> MQTTAdapt
    LoRa --> LoRaAdapt

    ModbusAdapt --> Bus
    OPCAdapt --> Bus
    MQTTAdapt --> Bus
    LoRaAdapt --> Bus

    Bus --> Processing
    Processing --> Shadow
    Processing --> Queue
    Queue --> Uplink[Cloud uplink\nMQTT-TLS / HTTPS]
    Uplink --> Cloud[Cloud IoT Platform]
    Cloud --> DevMgmt