Historical information gathering for distributed networks, where different media such as radios and cellular networks are used, has always been limited in terms of the system response. The bigger the system became, the slower the update times. In an effort to remove the influence of the communication architecture on the system response, a distributed network protocol was designed, and the two flavours of this were called DNP3 and IEC 60870-5. IEC 60870-5 is the protocol mostly used in the electrical industry. IEC 60870-5 is used widely in Europe, while DNP3 is used in the rest of the world.
Typically DNP-data contains not only the value for a data point, but also the quality and timestamp, and the specification allows for the controller to buffer the data for communications delays and failures. In simplistic terms it can be said that one should be able to obtain system responses expected from non-distributed system from for instance a radio system by using DNP.
In a DNP-system, one has DNP-Masters, DNP-slaves, DNP-Routers as well as DNP-Mapping to coordinate the architecture. Optional parameters in the DNP-protocol that like time synchronisation, retries, time-outs and confirmation messages are also used. The DNP-protocol can be implemented as a polled event where a time stamped value is transmitted on request, or an unsolicited response. In such cases a value is defined in terms of classes, and each class has its own hold time and hold count. If the hold time is 60 seconds, and the hold count is 10, it means that if the value changed outside of its dead band, more than 10 times before 60 seconds has elapsed the 10 time stamped values will be sent to the DNP-Master. The DNP master can be a controller or data concentrator or a DNP-enabled SCADA.
This report by exception (RBE) functionality allows slaves to send messages to the master, and the master needs to minimise clash avoidance and initiate recovery.
Typical applications where recording and logging events and periodic data from remote sites include:
* Non-continuous communications links (cellular, satellite and dial-up interfaces may be polled infrequently to reduce operational costs. Many only initiate calls for high priority events or alarms).
* Low power operation (infrequent communications for power management).
* Metering applications (hourly, daily and monthly totals).
* Time stamped events (sequence of events communication, failure and recovery).
With most other protocols, remote site RTU configurations can quickly become very complex because of aspects such as:
* Mapping of data.
* Conversion of data formats.
* Triggering of event logging.
* Triggering of messages.
* Retrying of failed messages.
DNP is designed to answer these problems with:
* Each device has addressing for over 65 000 points of each object type.
* Automatic time synchronisation of all devices.
* Automatic time-stamped events.
* Data class and priority configuration.
* Broadcast and polled messages.
* Capability for large messages (>2 kBytes).
Because DNP is an open protocol three levels of compliance have been certified:
* Level 1 – Basic slave ie an I/O device.
* Level 2 – Smarter slave/master ie a PLC/RTU.
* Level 3 – Very smart slave/master.
For a demonstration of a controller/SCADA environment that is Level 3 compliant, contact Jaco Hoogenboezem on scadapack@scadagroup.co.za
For a demonstration or more information contact Jaco Hoogenboezem, SCADAGroup, +27 (0)83 282 5706, scadapack@scadagroup.co.za, www.controlmicrosystems.com
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version