Configuring Modbus TCP Emulation for Ignition Integration Tests

Where does the poll go, and why does one simulator break down?

In production, the Ignition Modbus driver opens a TCP session to a Modbus TCP gateway. The gateway reads the unit ID in each request and forwards the frame to the matching downstream device. Tags address that path with the syntax [{parent_device}]{protocol_address}.HR###:

• {parent_device} is the Ignition device connection. It resolves to one IP and port, which is one gateway.
• {protocol_address} is the unit ID. The gateway uses it to select the downstream device.
• HR### is the register inside that device.

Every downstream device therefore has its own private register space. Holding register 100 on unit 5 has no relationship to holding register 100 on unit 6.

A single generic Modbus simulator replaces the gateway and all of its devices with one TCP listener. Most basic simulators do one of two things:

• They answer every unit ID from the same register table.
• They answer one unit ID and time out on the rest.

In the first case, every device connection that points at the simulator reads the same memory. Toggle one coil and the matching tag on every simulated device changes at once. That is the "total chaos" symptom. It is caused by the simulator's addressing model. Nothing is wrong in Ignition.

At integration scale the problem gets worse. This installation has about 35,000 tags across several thousand devices. Identical register maps across device types are the normal case, so almost every test write lands on hundreds of devices at once.

Ignition's built-in drivers have no simulation mode. The fix must sit on the far end of the TCP session: something that listens where the gateways would and keeps storage separate per unit ID.

What symptoms separate a shared register map from other faults?

Check layer one first. Confirm the device connection shows Connected before you look at register behavior. Then match the symptom to its cause:

Which emulation approaches are available?

There are three workable layouts. They differ in how many unit IDs one listener can keep separate and how much per-test setup they need.

Approach B is what most teams reach first, and it works for testing a subset of devices. It stops scaling when every gateway and every unit ID behind it needs its own simulator configuration for a single full-system test run.

Approach C uses the Advanced Modbus Driver from Automation Professionals, a third-party Ignition module. Its server mode emulates one or more slave devices on any of the module's three connection types, and it can run several connection types at the same time. Each driver instance listens on its own port. Each instance holds up to 255 nodes, and every node/instance combination keeps separate register storage. That maps directly onto the production pattern of one gateway with many unit IDs behind it.

Which approach should you use for a full integration test?

Use approach C. Run the server-mode driver on a separate Ignition gateway that exists only to emulate the field. The reasons:

• Isolation matches the real system. Unit 5 and unit 6 on the same emulated gateway have separate registers, just as two real devices behind one physical gateway do. A bit toggled on one node moves only that device's tags.
• Tag paths stay unchanged. The production gateway keeps its device connection names and {protocol_address} unit IDs. Only the IP and port each device connection points at change.
• Emulation load stays off the SCADA gateway. A dedicated gateway keeps emulation CPU and memory separate from the system under test. For development, a trial-mode gateway is enough for this job. Trial mode expires periodically, so plan resets around long soak tests.
• Multiple IPs remove the port bookkeeping. Assign the emulation host one IP per real Modbus gateway. Each emulated gateway can then sit on its own address with the port the production device connection already uses.

Keep approach B only for quick checks of a single device type where a standalone simulator is already set up.

Version check: the module was first announced as a beta for Ignition 7.9. Before you plan around it, confirm with Automation Professionals which module build supports your Ignition version.

How do you lay out the emulation gateway?

Mirror production one-to-one. Each real Modbus TCP gateway becomes one server-mode instance. Each downstream device becomes one node on that instance, keyed by the same unit ID the tags use in {protocol_address}.

Two layout rules decide how many instances you need.

Instance count. The minimum is ceil(devices behind a gateway / 255) for each gateway. Serial Modbus networks behind a gateway stay within the serial address range, so one instance per real gateway is the normal result. For the whole system, count the device connections on the production gateway. That number is how many instances to create.

Node address ranges. Configure each node to cover only the address range its tags actually read. The module owner recommends this for efficiency. Several thousand nodes with full-range storage waste memory on the emulation gateway for registers nothing ever polls. Pull the highest and lowest HR### (and coil and input addresses) per device type from a tag export and size each node from those values.

If the production gateways use a framing other than plain Modbus TCP, configure the matching connection type on the instance. The server mode supports all three of the module's connection types, including mixed types at the same time.

In client mode, the same module also supports Modbus function codes 20 and 21 (file records) and per-slave protocol tweaks for troublesome devices. That matters only if you later use it as the polling driver as well.

How do you move device connections between live and simulated?

Tags bind to the device connection name, not to an IP. Swapping targets therefore happens at the device connection or on the network. The tag database is never touched. There are two ways to do the swap:

Procedure for repointing device connections:

1. Export the device connection list from the production Ignition gateway. Record name, hostname, and port for each.
2. Build the mapping sheet. Assign each device connection one emulation instance and the IP:port that instance listens on.
3. On the emulation host, add the secondary IP addresses at the OS level. Confirm each responds to ping from the SCADA gateway.
4. On the emulation gateway, create one server-mode instance per row of the mapping sheet. Bind each to its IP:port. Add one node per unit ID with a trimmed register range.
5. Confirm each listener is up with netstat on the emulation host: one listening socket per IP:port pair, with no duplicates.
6. On the SCADA gateway, edit each device connection's hostname and port to the emulation values. Leave the device connection names unchanged so every [{parent_device}] reference still resolves.
7. For bulk changes, apply the mapping sheet through the gateway's configuration or scripting facilities available for your Ignition version, rather than editing thousands of entries by hand.
8. To return to live polling, apply the mapping sheet in reverse. Keep both columns in version control.

Driving test values:

• Holding registers and coils can be written from the SCADA side through writable tags, the same way operators would.
• Input registers and discrete inputs are read-only to a Modbus client. Set those from the emulation gateway's side of the server storage. Check the module documentation for how node storage is exposed there.

How do you verify isolation before trusting the integration test?

Run these checks against a sample before you move the full device set. Follow the packet at each step.

1. Transport. Every device connection on the SCADA gateway reports Connected. If any is not, check IP reachability and the listener on that IP:port before anything else.
2. Unit ID routing. Pick two devices behind the same emulated gateway, for example unit IDs n and n+1. Write a distinct value to the same HR### on each. Read both back. Each must return its own value.
3. Cross-instance isolation. Repeat step 2 across two different instances, using the same unit ID and the same register. Values must stay independent.
4. Bit-level isolation. Toggle one coil or bit-in-register on one device. Watch the matching tag on at least ten other devices that share the device type. None may change.
5. Range edges. Read the lowest and highest register each node is configured for. Then read one register past the top. Expect an exception response (illegal data address), not a timeout. A timeout means the request never reached the node or the unit ID is wrong.
6. Load. Enable all simulated devices at production scan rates. Watch device connection status and tag quality for stale or bad values. If response times climb on one instance, split its nodes across another instance on a new port or IP.
7. Coverage. Compare the mapping sheet against the SCADA gateway's device connection list. Every entry must point at an emulation IP:port, and none may still point at a production gateway address. Confirm with a packet capture on the SCADA gateway interface filtered on the Modbus port: no traffic may leave toward production subnets during the test window.

FAQ