During a recent project in the power industry, I was involved as an embedded software consultant in preparation for Factory Acceptance Testing (FAT) of a new product. One of the key changes before testing was the replacement of an existing open-source DNP3 stack with a newly purchased proprietary implementation.

I participated in porting the new DNP3 library into the product and preparing it for FAT validation. As expected, once implementation work was complete, the focus shifted to testing the system against detailed FAT requirements.

Very quickly, several practical challenges emerged — not in the implementation itself, but in how to effectively test certain scenarios.

Limitations of Existing DNP3 Simulation Tools

It became apparent that the standard DNP3 simulation tools available to the team did not support some of the required test cases. This is something I have encountered multiple times over the years: tools often cover common use cases well, but fall short when more specialized or less typical behavior needs to be validated.

One particular requirement stood out.

Unusual Requirement: RTU Initiated Connection (“Dial-Out”)

The system under test required the DNP3 RTU (server) to temporarily act as a TCP client and initiate a connection to the DNP3 master. After establishing the connection, normal DNP3 communication would proceed as if the master had initiated it.

This “dial-out” behavior is not typical in standard configurations, but it is used in certain architectures where inbound connections to substations are restricted.

The problem was straightforward: none of the available tools allowed a DNP3 master (client) to accept an incoming TCP connection.

The simulators used in the project, including ASE and another proprietary DNP3 master tool, assumed the traditional model where the master initiates the connection.

Adapting the Test Environment

To address this limitation, I extended the DNP3 client functionality in my VestaTel SCADA Multi-Protocol Simulator to support a “Run as TCP Server” mode. This allowed the simulated DNP3 master to accept incoming connections from the RTU.

With this capability in place, it became possible to fully execute and validate the FAT requirement.

Functional Testing Coverage

Once the communication setup was resolved, we were able to perform comprehensive testing of the RTU functionality, including:

• Unsolicited and polled reporting of events and static objects (binary inputs, analog inputs, counters, binary/analog output status)
• Configuration and validation of static and event variations
• Control operations (binary and analog outputs), including Select-Before-Operate (SBO) and Direct Operate
• Assignment and handling of event classes
• Time synchronization and validation of event timestamps
• Handling of DNP3 “Self Address”

Results: Issues Identified in the New DNP3 Stack

As a result of this testing effort, several issues were identified in the newly integrated DNP3 library:

• “Dial-out” connection was established only once, with no retry mechanism
• Incorrect timestamps in event data despite successful time synchronization
• Lack of support for DNP3 Self Address

These issues were subsequently corrected prior to final acceptance.

Conclusion

This experience highlights a common challenge in SCADA and power system development: testing requirements often go beyond what standard tools support. Having a flexible simulation environment that can adapt to non-standard scenarios can significantly reduce risk during FAT and improve overall system reliability.

If you are working with DNP3 or other SCADA protocols and encounter similar testing challenges, feel free to explore:

VestaTel SCADA Multi-Protocol Simulator