DNP3 Slave RTUs on separate OrionLX DNP3 ports can be configured as a redundant pair for event queue synchronization purposes.
PUBLISHED ON Oct 29, 2014
OrionLX DNP3 communication port redundancy allows a SCADA master with multiple front end processors or communication paths to the OrionLX to poll over a secondary path without receiving duplicate events if the primary path fails.
Since the primary and secondary RTUs have nearly identical configurations, the secondary RTU reads its settings from the primary RTU, except for the RTU name and RTU address. The secondary RTU also reads its input and output point configuration from the primary RTU. The peer settings on the primary RTU must point to the secondary RTU and the peer settings on the secondary RTU must point to the primary RTU. Please refer to the DNP3 Slave manual in the NCD Docs directory for more application configuration details.
A typical configuration would be an RTU on a DNP3 Slave network port for primary communications and an RTU on a DNP3 Slave serial port for secondary communications. If the master is unable to connect via the network, it would poll the OrionLX via the serial port. When events are confirmed on an RTU operating in redundant mode, the events are also cleared on the RTU’s redundant peer RTU.
