Debugging IEC101 / IEC104 Regulating Step Command with VestaTel Simulator

Recently, I was working on extending an embedded SCADA protocol converter running on an industrial router. The task was to implement support for a relatively uncommon IEC 60870-5 message type: Regulating Step Command.

This command is not frequently used, but it appears in specific control scenarios—typically where incremental adjustments (rather than absolute setpoints) are required.

The scenario

The target use case involved:

  • Uplink: IEC 60870-5-104 (IEC104)
  • Downlink: IEC 60870-5-101 (IEC101) RTU

The goal was to correctly translate a Regulating Step Command received over IEC104 into the corresponding action on an IEC101 RTU.

Test setup using the simulator

To validate the implementation, I used the VestaTel SCADA Multi-Protocol Simulator to emulate both ends of the system:

  • IEC104 Master (client side)
  • IEC101 RTU (serial side)

This allowed me to test the full command flow without requiring any physical devices.

Command mapping

In this setup:

  • A specific IOA on the IEC101 side was mapped to a Step Position data point<.b>
  • The IEC104 master simulator issued a Select + Operate sequence
  • Risky automation decisions based on outdated inputs
  • The command included the RCS (Regulating Command Step) value:
  • -- HIGHER
  • -- LOWER

Expected behavior

Once the command was received by the RTU simulator:

  • -- HIGHER -> increments the Step Position by +1
  • -- LOWER -> decrements the Step Position by -1

This effectively simulates a real-world regulating device where adjustments are made step-by-step.

Observability (monitor direction)

One useful aspect of this setup was full visibility on both sides:

  • The IEC101 RTU simulator reflected the updated Step Position value
  • The IEC104 master simulator could observe the updated value in real time

This made it easy to verify:

  • correct command translation
  • correct execution logic
  • proper feedback propagation

Why this mattered

Testing this type of functionality against real hardware would have been:

  • time-consuming
  • hardware-dependent
  • difficult to reproduce consistently

Using the simulator, I was able to:

  • iterate quickly
  • isolate issues
  • validate edge cases
  • confirm end-to-end behavior

Conclusion

Even for relatively niche protocol features like Regulating Step Command, having a flexible multi-protocol simulation environment makes development and debugging significantly more efficient.