How to Simulate Modbus for IIoT Gateway Testing

What an IIoT Gateway Actually Does

An industrial IoT gateway sits between plant-floor Modbus devices and everything upstream of the plant floor — a cloud platform, an on-prem historian, or a SCADA system:

Modbus Devices (PLC/meter/VFD)  →  IIoT Gateway  →  Cloud / SCADA / Historian
[TCP or RTU, Unit IDs 1..N]         [Poll + translate + edge rules]   [MQTT, OPC UA, REST, vendor SDK]

Devices like the Advantech ADAM-6717 combine Modbus TCP/RTU polling, local edge computing, and cloud gateway functions in one box. Moxa's IIoT edge computers and HMS Networks' Ewon Flexy/Edge line do the same, with the Ewon line specifically built to read Modbus TCP, Siemens S7, and Allen-Bradley EtherNet/IP and forward all three to AWS IoT or Azure IoT Hub over MQTTS. The common thread: Modbus is the southbound (device-facing) protocol, and something else — MQTT, OPC UA, a REST API, or a proprietary cloud SDK — is the northbound (cloud-facing) one.

Why Simulate Instead of Testing Against a Real PLC

Three practical reasons engineers test gateways against a simulator instead of live hardware:

• Availability: a production PLC is usually running a live process you can't take offline to test a gateway configuration change against it
• Edge cases: a real device only ever shows you the values it currently has. You can't easily make a live PLC return a Modbus exception code, sit at an out-of-range value, or drop off the network on command
• Repeatability: a simulator lets you set exact register values and reproduce the same test scenario every time — essential for regression-testing a gateway's firmware or configuration across versions

ModbusSimulator runs as a fully configurable Modbus TCP or RTU slave on a normal Windows machine, which makes it a practical stand-in for the PLC, meter, or VFD your gateway will eventually poll.

Setting Up the Test Environment

The basic bench setup has two components on the same network (or reachable over the gateway's configured WAN/cellular test path):

Configure the simulator's Modbus TCP port (502 by default) or RTU COM port to match how the gateway will reach production devices, and set the Unit ID to match your real device's address. Pre-load registers with distinctive, non-zero test values — the same principle used for testing any Modbus integration — so you can immediately tell whether the gateway is reading and forwarding the right data.

Simulating a Multi-Device Site

Most real sites aren't a single PLC. A typical gateway polling list might look like:

# Example gateway polling config — one Modbus TCP connection, three Unit IDs
Unit 1: PLC          — holding registers 0-49   (process values)
Unit 2: Power meter  — holding registers 0-19   (voltage, current, kWh)
Unit 3: VFD           — holding registers 0-9    (speed, fault code)

A simulator that supports multiple Unit IDs in one running instance lets you reproduce this exact layout on one machine, at one IP address, without needing three physical devices on the bench. Configure each Unit ID's register map to mirror the real site's documentation, then verify the gateway correctly separates and tags data from each device rather than merging or misattributing values — a common bug when a gateway's Unit ID handling isn't configured correctly.

Testing Protocol Translation

The core job of an IIoT gateway is translating Modbus register values into whatever protocol runs north of it. Test each translation path the gateway supports:

MQTT: subscribe with mosquitto_sub -h <broker> -t '#' -v and confirm register changes in the simulator appear as MQTT messages within one polling interval, on the expected topic, in the expected payload format (JSON, CSV, or raw).

OPC UA: connect an OPC UA client (e.g. UaExpert) to the gateway's OPC UA server endpoint and confirm the Modbus registers appear as the correct node IDs with the correct data types and current values.

REST / cloud SDK: if the gateway posts to a REST endpoint or vendor cloud API, use a local mock HTTP server (or the vendor's sandbox/staging environment) to capture what the gateway actually sends, and diff it against what the simulator's registers say it should be sending.

In every case, the validation loop is the same: change a value in the simulator, confirm the correct translated value appears on the northbound side within one polling cycle.

Testing Edge Computing Logic

Gateways with edge computing capability — like the ADAM-6717's onboard Node-RED or logic engine — run rules locally before forwarding data: threshold alarms, unit conversion, data aggregation over a time window, or deciding what to forward versus discard to save bandwidth on a cellular connection.

# Example: test an edge alarm rule
# Gateway rule: if HR 5 (temperature, raw x10) > 800, fire "high temp" alarm

# Step 1: set simulator HR 5 = 750 (75.0°C) — confirm no alarm
# Step 2: set simulator HR 5 = 850 (85.0°C) — confirm alarm fires within 1 poll cycle
# Step 3: set simulator HR 5 back to 750 — confirm alarm clears (or stays latched, per spec)

Drive each threshold and aggregation rule through the simulator the same way: below, at, and above the trigger point, and confirm the gateway's behavior matches its configuration — not just "it seemed to work once."

Failure Modes to Test Before Deployment

These are the scenarios that don't show up in a quick demo but do show up in production:

Modbus device offline: stop the simulator (or block its port with a firewall rule) while the gateway is running. Confirm the gateway logs the failure, retries per its configured interval, and doesn't crash or stop polling other Unit IDs on the same connection.

Modbus exception response: configure the gateway to poll a register address the simulator doesn't have. Confirm it handles the resulting exception code (typically 0x02, Illegal Data Address) gracefully — logs it, skips that point, and keeps polling everything else.

Uplink loss (store-and-forward): if the gateway has store-and-forward buffering for its northbound connection, disconnect its WAN/cellular/broker connection while the simulator keeps changing values. Reconnect and confirm buffered data arrives in order, without silent gaps.

Restart recovery: power-cycle the gateway (or restart its polling service) while the simulator is running and confirm it reconnects and resumes correct polling without manual intervention — this matters most for gateways deployed at remote, hard-to-reach sites.

Notes on Common IIoT Gateway Hardware

Advantech ADAM-6717: combines Modbus TCP/RTU I/O with onboard edge computing (Node-RED) and cloud connectors. Point its Modbus TCP master configuration at the simulator's IP:502 during bench testing before wiring to field devices.

Moxa IIoT edge computers: Debian-based edge gateways used in solar, wind, and water/wastewater deployments. Configure the Modbus driver against the simulator first — Moxa's newer open architecture makes it straightforward to run the same test scripts you'd use against any Linux-based Modbus master.

HMS Ewon Flexy / Edge: reads Modbus TCP (alongside Siemens S7 and Allen-Bradley EtherNet/IP) and forwards to Ewon Cloud, AWS IoT, or Azure IoT Hub over MQTTS. Test the Modbus tag mapping locally against the simulator before enabling the cloud forwarding rule, so a bad tag map doesn't propagate into production cloud dashboards.

Software gateways (Node-RED, ThingsBoard Gateway): the Modbus nodes in these platforms connect exactly like a hardware gateway would. Running them against a local simulator is often faster to iterate on than a physical gateway, since there's no firmware flash cycle between configuration changes.

Download ModbusSimulator to Test Your IIoT Gateway →

Frequently Asked Questions