02.02.2018 Views

Practical_modern_SCADA_protocols_-_dnp3,_60870-5_and_Related_Systems

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Advanced considerations of distributed network protocol 163<br />

used to return very limited data. This would consume only a small b<strong>and</strong>width, but would<br />

prove the continued operation of the communications system just as well as a larger data<br />

poll would.<br />

Sometimes polled static operation will be used for particular critical tasks, combined<br />

with unsolicited report-by-exception for most data acquisition.<br />

The minimum implementation mode supported is defined by the sub-set definition documents<br />

to be polled report-by-exception. However, the documents recommend that one<br />

of the reporting by exception modes should be available for any DNP3 implementation.<br />

To this effect, the following specific recommendations are made:<br />

• All slave devices should report event data<br />

• All master devices should support a report-by-exception mode of operation<br />

6.6 Time synchronization<br />

6.6.1 General method for time synchronization<br />

One of the important <strong>SCADA</strong> features of DNP3 is that it provides for time-stamping<br />

of events. Time stamping in DNP3 provides resolution of events to one-millisecond.<br />

For events to match up correctly across a system, it is essential that the clocks in all outstations<br />

are synchronized with the master station clock.<br />

Synchronizing of an outstation clock is done by sending a time <strong>and</strong> date object (object<br />

50, variation 1) to the outstation. However, there is a finite delay in transmission from the<br />

master to the outstation, <strong>and</strong> if this is not accounted for when setting the clock, it would be<br />

set retarded by this transmission time. This delay time can be due to store-<strong>and</strong>-forward<br />

delays introduced by a variety of devices along the transmission path, including:<br />

• Time in modem buffers<br />

• Time in data radio buffers<br />

• Time in intermediate repeater store-<strong>and</strong>-forward buffers<br />

In addition to these, the reader might also add the possibility of processing delays<br />

between the application level <strong>and</strong> the lower levels, or ‘stack delays’ at both master <strong>and</strong><br />

outstation. These would indeed be significant, except that the DNP3 specification accounts<br />

for these by requiring some of the time synchronization function to be performed at the<br />

data link layer. The data link is required to record the time of transmission or receipt of the<br />

first bit of any delay time message. When transmitting the message, the data link layer<br />

triggers a freeze of the master station clock, which is stored as MasterSendTime. Similarly,<br />

when a slave station receives a delay time message it must store a freeze of the local clock<br />

as RtuReceiveTime.<br />

DNP3 provides for measurement of the round trip delay time by Function Code 23<br />

Delay Measurement. The procedure is shown below.<br />

Delay measurement procedure:<br />

• Master sends Function Code 23 Delay Measurement<br />

• Master records start of transmission time as MasterSendTime<br />

• Outstation records the receipt time as RtuReceiveTime<br />

• Outstation commences to send a response <strong>and</strong> records time as RtuSendTime<br />

• Outstation calculates its internal processing turnaround time RtuTurnAround<br />

which is RtuSendTime – RtuReceiveTime

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!