Integrating a third-party package into the DCS over Modbus: our checklist

A package unit arrives with its own PLC, its own logic and its own idea of what the DCS should see. The link is often Modbus — RTU on a serial line or TCP over Ethernet — and on paper it looks simple: a list of registers to read and write.

In practice, most start-up headaches with packages are interface headaches: a value that looks plausible but is wrong, a command that was sent but never executed, a fault the operator cannot interpret. This is the checklist we work through on every package we integrate.

PLC · DCS interface

1. A register map agreed in writing

The register map — the exchange table — is the contract between the package and the DCS. It must be agreed in writing and kept under revision, and each line must state:

The question of 0-based or 1-based addresses alone explains many “off by one” errors at start-up. It costs nothing to settle it on paper.

2. Byte order, word order and scaling — checked on real values

A 32-bit value travels in two 16-bit registers, and not every device puts them in the same order. The bytes inside a register can be swapped too. A mismatch does not produce an error message: it produces a number that looks plausible but is wrong. That is why we check the interface on real values, not only on paper:

• force a known value in the package PLC, or read a stable and known measurement, and compare it with what the DCS displays;
• check at least one value of each data type used in the map;
• check the scaling at both ends of the range, not only in the middle.

3. A heartbeat to detect communication loss

A frozen value looks exactly like a stable one. Without a heartbeat, the DCS can keep displaying the last good reading long after the link has failed. A simple watchdog solves it: the package increments a counter or toggles a bit, the DCS checks that it keeps changing within a defined time, and raises an alarm if it stops. Where the package also needs to know that the DCS is alive, the same principle applies in the other direction.

4. Defined behaviour on communication loss

Detecting the loss is only half of the job. The functional analysis must say what happens next, on both sides:

• what the package does: carry on in local control, hold its current state, or go to a safe stop;
• what the DCS does: which sequences hold, which interlocks act, which values are flagged as bad;
• which alarm the operator receives, and with which priority;
• what happens when communication returns — nothing should restart on its own without a defined rule.

5. Commands with feedback

Writing a register is not the same as executing an order. Every command from the DCS — start, stop, setpoint, mode change — should be confirmed by feedback from the package: running status, actual setpoint, current mode. The DCS logic compares command and feedback and raises a discrepancy alarm when they still disagree after a defined time. Never assume an order was executed just because it was sent.

6. Package alarms the operator can understand

Packages often expose their alarms as a status word or a single “common fault” bit. A common fault tells the operator that something is wrong, but not what. Where the package makes the detail available, we bring the individual alarms back into the DCS with clear texts, the right priority and the package name, so the operator knows whether to call maintenance, call the vendor or simply reset. Package alarms belong in the alarm and interlock database like any other alarm.

One partner on both sides of the interface

Many interface problems come from two teams each assuming the other one handles something: the scaling, the heartbeat, the behaviour on communication loss. When the same engineering partner works on the DCS configuration and on the PLC side, those gaps close early, during the design rather than during start-up. That is why we work on both Emerson DeltaV and Siemens PLCs.

In short

A register map in writing, byte and word order checked on real values, a heartbeat, a defined behaviour on communication loss, commands with feedback and clear package alarms: six points that remove most start-up headaches with packages. Read more about our Siemens PLC and DCS integration work.