APCS Emulation: Modbus RTU Controllers

Software Emulation of Controllers in SCADA Systems for Testing

Developing software for Supervisory Control and Data Acquisition (SCADA) systems demands rigorous testing of device, sensor, and controller interactions. Traditional physical commissioning panels with switches and load cells could simulate basic scenarios but were limited by weight capacity (up to 30 kg) and couldn’t fully replicate parallel processes. Transitioning to software emulation using Delphi eliminated these constraints, enabling precise simulation of Modbus RTU communication and input/output module behavior.

The emulator is built as a device configurator: users add controllers, assign RS-485 addresses, and map inputs/outputs. It supports all equipment versions, including emergency stop buttons to simulate communication failures.

Emulator Architecture

The main emulator window displays a list of devices with status indicators. For weighing controllers, features include:

• A slider to adjust weight without physical limits.
• Manual parameter setting and state switching.
• A manual/auto mode toggle with randomized weight increments for realistic batching.

I/O modules allow manual input/output switching. In automatic mode, they emulate real material dosing (cement, aggregate, water).

Integration with the core application is minimal: the compiler directive $IF Emulate=True redirects calls from ComPort.Write to Emulator.Send.

{$IF Emulate=True}
Emulator.Send(EmulData, FWaitingTime);
{$ELSE}
ComPort.Write(OutDIOM, 11, @InDIOM, 8);
ComPort.Wait(FWaitingTime);
{$IFEND}

Changes are isolated to the communication module—Modbus RTU commands remain unchanged, and responses strictly follow specifications.

Communication and Command Queues

Communication follows a "command" pattern with multiple queues to enable parallelism:

• Continuous reading of controller states (even during idle periods).
• Reading I/O module inputs/outputs for monitoring.
• Sending commands (highest priority: start batching, motor activation).

A continuous flow manages the queues. Read queues fill up to a threshold, while high-priority operator commands are inserted at the front. Commands are dynamically generated based on current and expected device states.

Example: On a concrete plant, three or more batching operations run in parallel (setup, weight assignment, start). On a cement plant, sequential state checks occur before each new command.

Queue indicators turn red when communication is lost. Delays across 10 I/O modules (20 ms per request) result in a ~400 ms cycle plus controller polling, totaling ~1 second response time—accounted for in the UI to prevent false error alerts.

Advantages of Software Emulation

• Full scenario simulation: failures, jams, parallel batching—all without physical hardware.
• Configuration saving/loading tailored to specific plants.
• Extensibility: adding new devices requires only adherence to Modbus and controller specs.
• Faster commissioning: fewer unpredictable errors on-site.

The emulator runs on legacy Windows XP/7 applications, enabling complex process testing without downtime or risk of damage.

Key Takeaways

• Emulation preserves Modbus RTU accuracy, minimizing changes to core code.
• Automatic mode includes randomized dosing for realistic test conditions.
• Multiple command queues enable parallel execution without blocking.
• Simplicity: easy to learn after understanding the protocol and device docs.
• Cost savings: no need for physical panels, faster development and debugging.

— Editorial Team