dnp3 – more than just an electric power utilities protocol
TRANSCRIPT
DNP3 – More Than Just an Electric Power Utilities Protocol
by Philip Aubin
Executive summaryOver the last decade, DNP3 has emerged as one of the most prevalent international standard protocols in the SCADA market. Its rich feature set and proven high degree of interoperability has made it the protocol of choice in a number of utility sectors, especially the electrical and water industries. This paper explores how recent additions to the DNP3 standard allow oil and gas sectors, including in the EFM area, to similarly leverage value from DNP3.
998-2095-04-10-12AR0
Summary
Executive Summary ........................................................................................ p 2
Introduction .................................................................................................... p 3
Telemetry Systems – Components & Characteristics ....................................... p 4
Telemetry Communication Protocol Architectures ........................................... p 6
Proprietary System Protocols .......................................................................... p 9
Benefits of Standardisation ............................................................................. p 10
DNP3 in the Water Industry ............................................................................. p 15
Enabling Facilities of DNP3 ............................................................................. p 17
DNP3 for EFM ................................................................................................ p 19
Conclusion ..................................................................................................... p 21
Executive summary
Over the last decade, DNP3 has emerged as one of the most prevalent
international standard protocols in the SCADA market. Whilst having its origins in
Electrical Power Utility systems in North America, its rich feature set and proven
high degree of interoperability has made it the protocol of choice in a number of
utility sectors, internationally. Its popularity in Electric Utilities sector has continued
in Distribution, Transmission and Generation. In non-electrical sectors there has
also been significant uptake of DNP3; in particular in the Water & Wastewater
sectors, and to a lesser extent in the Gas Distribution and Pipeline sectors.
As a standard, DNP3 continues to evolve through its international User Group,
meeting the needs of vendors and end users through improved interoperability
and advances in its technical capabilities. Some of the recent additions to
the DNP3 standard have paved the way for sector specific implementation
standards. These recent additions are directly applicable to the future of SCADA
communications in the Oil and Gas sectors where there is an increasing focus
on data modelling and standardisation. PRODML is one such standard for
modelling production data.
This paper builds on all these themes by first introducing the basic components
of Telemetry communications, protocol architectures, the nature of proprietary
systems, and the importance of standards for communication protocols. The
current status of DNP3 is presented for industry sectors outside of traditional
Electricity SCADA. Facilities of DNP3 that can be leveraged in Electronic Flow
Measurement and other Oil & Gas systems is detailed, showing the potential of
DNP3 for SCADA communications going forward.
White paper on DNP3 for Electric Power Utilities | 02
DNP3 – More Than Just an Electric Power Utilities Protocol
Introduction
The use of Open Standard communications for Supervisory Control and Data
Acquisition (SCADA) is well established in an increasing number of utility and
industry sectors across the globe. This has provided significant benefits in
system deployment and operation. The same philosophies widely adopted
in the Electricity sector a number of years ago have been applied to Water
sector SCADA, and can be equally be applied to SCADA and Electronic Flow
Measurement (EFM) and Production data for Gas and Oil sectors.
DNP3 is one of the most successful SCADA open standards adopted in the
Electricity sector and now the Water sector, across the globe. Over the last 10
years it has seen significant adoption in the Electricity sector where it has its
historic origins. In addition, the Water Sector in many countries has also adopted
DNP3 over this period. In particular the Water Sector in Australia, and more
recently the United Kingdom have adopted DNP3 for SCADA communications
on a wide scale basis. Use of DNP3 in the Gas and Oil sectors has also been
gaining ground. There is significant scope for expanding the use of DNP3 into
electronic flow measurement and other Gas and Oil sector applications.
The global attraction of DNP3 is strongly influenced by the methodology on which
it is based, but also its strong international user community, formal User Group
supported by an international Technical Committee, technical forums and so on.
White paper on DNP3 for Electric Power Utilities | 03
DNP3 – More Than Just an Electric Power Utilities Protocol
White paper on DNP3 for Electric Power Utilities | 04
DNP3 Communications for Water and Wastewater Applications
Telemetry engineering, in the context of SCADA
systems, is a specialised field dealing with various
aspects of remote data communications and
control. The nature of telemetry, with its close
association with the hardware that provides
interfaces to the physical world and communications
systems, has historically lead to customised
engineering solutions for SCADA system
communications. The expectations, requirements
and constraints of using telemetry are varied
across different industry groups. Not all aspects of
telemetry are applicable to all industries, or all users
within an industry. Despite this, Standards have had
an increasingly important role to play in telemetry
at all levels over the years. In today’s era, the
leverage that can be sought from standardisation
is becoming a critical factor in rapid and successful
deployment of systems.
The following list, although not exhaustive, provides
a scope of facilities provided by modern telemetry
systems. There is an area of overlap of telemetry
into control facilities at the lower end of system
hierarchies, and into SCADA system facilities at the
higher end. This is typical of the nature of telemetry.
• Remotefielddevicesforcollectionofdata
(RTUs)
• Lowcost,lowprocessingpower,relatively
high volume compared with computer
desktop and server systems
• Highreliability
• Autonomousorcoordinatedcontrolofremote
assets
• Lowbandwidthand/orwidearea
communication links
• Requirementfornewequipmenttooperatein
conjunction with legacy equipment
• Several(ormany)fielddevicesonthesame
communication link
• Multiplecommunicationlinksintocriticalassets
• Centralisedcommunicationprocessors
linking distributed remote systems (including
centralising on LAN or WAN)
Pivotal in the remote aspects of telemetry systems
is the field RTU device. RTU devices are becoming
increasingly advanced in the features they are
required to offer.
Requirements of modern RTUs include:
• HighaccuracyI/OInterfaces
• HighspeedI/Oprocessingandeventtime-
stamping
• ControlandSequencing
• Preservationofdataduringsystemfaults,
forwarding stored data after fault restoration
• Wideareacommunicationsprocessing-diverse
communications support from hundreds of
meters up to thousands of kilometres
• Landline(leased&private)
• UHFRadio
• Spreadspectrumradio
• Dial-upPSTN
• GSMdigitalcellular
• VSATSatellite
• FiberOptic
• Communicationssupportwithalargerangeof
field devices
• SmartInstruments
• IEDs(IntelligentElectronicDevices)
• PLCs(ProgrammableControllers)
Telemetry Systems – Components & Characteristics
White paper on DNP3 for Electric Power Utilities | 05
DNP3 Communications for Water and Wastewater Applications
A variety of International and Industry Standards
exist covering many of these aspects of data
gathering field devices (of which RTUs are a family of
these devices):
• Powersupplyperformance
• Electricalcharacteristicsincluding
• RFemissions
• RFimmunityperformance
• Electrostaticdischargeimmunity
• I/Ospecificationsincludingisolation
• Control&sequencinglanguages
• Physicalcommunicationsmedia
• Communicationsprotocols
• Security
Regulatory bodies have enforced standards in some
of these areas via legislative means, while industrial
users are specifying some as industry standards
to satisfy interoperability requirements. There is
increasing awareness of the availability of standards
in SCADA and telemetry, and these have generated
intense interest.
With increased focus of interoperable data
exchange and standardisation of data “models”
across industry, the role of the communications
protocol, and its part in standardisation, is becoming
increasing critical.
The following sections provide details on the
issues affecting standardisation of communications
protocols in telemetry systems for SCADA.
Telemetry Communication Protocol Architectures
White paper on DNP3 for Electric Power Utilities | 06
DNP3 Communications for Water and Wastewater Applications
Central to the desires of Standardisation is the
promotion of interoperability between systems. A
key aspect of this is the communication protocol
architectures used by telemetry systems.
A model for computer system communications has
been promoted for many years by the International
Standards Organisation (ISO). Figure 1 shows
the 7-layer model described for Open Systems
Interconnectivity (OSI) that has been the corner
stone of communications system specifications.
OSI Layer
Application Layer
Presentation Layer
Session Layer
Transport Layer
Network Layer
Data Link Layer
Physical Layer
Figure 1: OSI 7 layer communications model
EPA Layer
Application Layer
Data link Layer
Physical Layer
Figure 2: Enhanced Performance Architecture model
Telemetry protocol designs have classically been
based on OSI specifications, but have often used an
optimised model to overcome the limited processing
and communications capabilities of remote
telemetry devices and wide area telemetry networks,
compared with their IT computing counter-parts.
Many SCADA telemetry protocols are based on
Enhanced Performance Architecture (EPA) models
using 3 layers from the 7-layer OSI model. This is
illustrated in Figure 2. In practice, this optimisation
has been required to achieve operational and
communication performance.
Demanding requirements for remote telemetry
devices and remote communications has led to
the introduction of pseudo layers to complement
the 3-layer EPA model. Without introducing the
processing or communication overhead of fully
implemented layers, selected functions from other
OSI layers are being applied. An example, as
shown in Figure 3, may provide:
> Selected Network functions– packet forwarding,
sub-network packet filtering, bridging between
IP and non-IP communication links
> Selected Transport functions– packet
disassembly & re-assembly allowing large data
messages to be sent between devices e.g.
remote device configurations, downloading
control sequences, uploading historical data
Proprietary systems and Standards based
systems, alike, can use similar communication
models as those described above. It is well
known, though, that proprietary systems from
different manufacturers based on this common
communications model typically cannot operate
together. If interoperability is to be achieved
using Standards in SCADA telemetry networks,
the relationship between devices at each of the
communication layers needs to be specified.
Standard communications protocols document
details at each of the communication model’s layers.
The following descriptions serve to illustrate
the potential complexities involved in achieving
interoperability at each layer.
At the Physical Layer, interoperable devices must
support an interface to a common (or linked) physical
communication channel, and provide compatible
access techniques to the media that the channel
utilises. Interfaces such as RS232, RS485 and
10Base-T are common examples of physical layers
based on standards. Interoperability between devices
at this layer is usually straightforward to achieve as
the choice of communication media dictates many of
the characteristics of the interface. Incompatibilities
between methodologies used on these channels can
still occur, preventing interoperability.
At the Data Link Layer, compatible data framing
must be provided including uniform packet headers,
data link functions, error check codes and packet
sizes. In the enhanced performance architecture,
node addressing may be relevant at this layer which
also needs to be compatible between devices.
Interoperable systems will need to share a common
methodology for device addressing which may
require unique device addresses in an entire network.
White paper on DNP3 for Electric Power Utilities | 07
DNP3 Communications for Water and Wastewater Applications
Application Layer
Selected Transport Functions
Selected Network Functions
Data Link Layer
Physical Layer
Figure 3: Enhanced Performance Architecture model with selected functions in additional layers
White paper on DNP3 for Electric Power Utilities | 08
DNP3 Communications for Water and Wastewater Applications
Simple Transport functions may be included in a
protocol for disassembling and re-assembling larger
packets from smaller ones, and visa-versa. The
means of specifying this within the communication
protocol, and the mechanisms used to achieve it
must be compatible in all interoperable devices.
In the optimised architectures of telemetry
protocols, the Application Layer may be required
to encompass a wide range of facilities. The basic
transaction types will be described, and methods
must be compatible between interoperable devices.
Examples include: Read, Control, Unsolicited report,
etc. The data involved in the transaction must also
be specified. It may include such parameters as
Data Type, Access Method and Description of data
affected. A particular protocol may allow devices
to support multiple data types, various access
methods and large quantities of data; interoperability
can only be achieved with very close agreement on
the variants for each parameter.
Technically, the process of providing interoperability
at all layers in a protocol depends very much on the
structure of the protocol and the facilities it provides.
Politically though, overcoming the dominance
of proprietary protocols to allow promotion of
a Standard that offers interoperability, requires
the Standard to be managed by an independent
organisation.
White paper on DNP3 for Electric Power Utilities | 09
DNP3 Communications for Water and Wastewater Applications
Prior to the current momentum brought about by the
use of standards within the telemetry marketplace,
manufacturers designed their own communications
protocols, usually based on the communications
models described above. The experience in the
Process Control industry with Programmable
Controllers (PLCs) has been repeated with virtually
every telemetry manufacturer, each providing a
different communications protocol, or manufacturer
specific modifications and extensions to a
“standard” protocol.
A manufacturer’s specific protocol is nearly always
optimised at each of the communication layers
to suit particular requirements of their device, or
target market. This results in designs based on
particular data formats only suitable for particular
communication networks or particular applications.
The developed systems generally offer highly efficient
protocols, but can suffer from a lack of generality
when applied to different applications. Despite being
based on the same layered communication models,
some designs don’t take advantage of the layered
structure that in theory allows the physical layer and
its interfaces to be changed while allowing the layers
above to continue operating. Some proprietary
systems are customised to the extent that only a
single physical interface is possible.
In many cases, proprietary SCADA protocols were
developed over long periods of time, as a series
of enhancements as the demands of telemetry
specifications expanded. It is common for designs
to include backward compatibility with earlier
products, building on the base of intellectual property
previously created. At times, enhancements based
on earlier designs can have negative effects, leading
to inconsistencies in the operation of systems, or the
customisation of solutions, each system different for
each new project. This can create major support
problems as systems age.
Proprietary System Protocols
Telemetry systems owners, like all asset owners,
naturally attempt to maximise their investments
in installed infrastructure. The matching of new
SCADA with old RTU systems, or old SCADA with
new RTU systems is not always possible without a
great deal of engineering effort. System interfacing
is often resolved with expensive, complex protocol
converters.
Historically,theproprietarynatureoftelemetry
systems has resulted in closed systems and captive
markets. Users have suffered from the long-term
effects of such an arrangement finding difficulty, for
example, in procuring cost competitive expansion to
systems.
Recent experience within the telemetry industry
has also highlighted the fact that closed proprietary
systems are not conducive to providing a competitive
drive for technological improvement.
White paper on DNP3 for Electric Power Utilities | 10
DNP3 Communications for Water and Wastewater Applications
In overcoming the problems of proprietary telemetry
systems, standards can provide universal specifica-
tions for the implementation of various aspects of
these systems. Significant benefits are now being
realised in the SCADA industry in many areas.
The inherent documentation clearly specifying a
Standard solves many of the problems associated
with proprietary systems discussed earlier. Standard
methods are typically defined for providing facilities
that were classically implemented to suit individual
projects. SCADA protocol features such as time-
stamped event reporting and peer communications
now have well defined, standard methodology.
From the user’s perspective, the key to success in
using standards is to verify that the products provided
by the vendor are compliant with the standards.
There is continuous effort being made by various
bodies controlling standards to provide meaningful
and improved compliance testing.
Once it is established that equipment is Standards
Compliant, interoperability between equipment from
different manufacturers is possible, and the ability to
operate equipment in different configurations usually
results.
Standards compliance provides many opportunities
for both users and vendors. Previously closed
systems can now be “opened up”. Equipment can
be sourced from more than one vendor allowing cost
competitive procurement for users and guaranteeing
access to supply of products from more than one
source. Standards compliance also provides
advantages to vendors by allowing equipment to be
supplied into broader markets, and to users whom
were previously in closed arrangements.
Additional benefits are delivered when standards be-
come widely accepted. The ability to source exper-
tise from multiple sources becomes achievable. No
longer are the vendors the only source of technical
expertise or support. In effect the expertise required
to support systems spreads throughout the industry.
Benefits of Standardisation
Another goal of some standards is to achieve
universal support by many users across many
markets. This necessarily requires standards to
be more generalised and flexible. Standards can
be large, and as with most engineering solutions,
flexibility can result in complexity. As such, not all
systems require all aspects of a standard to be
implemented. Where users request particular parts
of a standard, and where manufacturers implement
only particular parts of a standard, interoperability
problems between different products can suffer.
Interoperability, however, is one of the primary aims of
standardisation.
So how are these conflicting issues of universal
flexibility and interoperability resolved?
Requirements forcing full implementation of a
complex standard in every situation can superficially
solve the interoperability problem, potentially at the
cost of more expensive solutions where simpler low
cost alternatives could have been used. This can
ultimately lead to abandoning of the Standard.
The DNP3 SCADA-RTU protocol, for example, has
solved this problem by specifying four (4) graded,
minimum interoperability Subsets for different levels
of device. While the DNP3 standard is very versatile,
it is also fairly large, and specific applications
may require different parts of the standard to
be implemented. Specification of the minimum
requirements for devices of a particular level allows
interoperability with other devices at the same level.
In addition, vendors are required to provide specific
implementation details for their products with respect
to the standard. These requirements have proved to
be very popular and are important parts of the DNP3
protocol for users. This has significantly contributed
to making DNP3 the leading SCADA-RTU protocol in
the telemetry market today.
Industry requirements do change and evolve, and
rapid improvements in telemetry hardware technology
have enabled RTUs, in particular, to perform more
and more complex tasks. If a Standard is supported
and maintained by a standards body that is
responsive to the needs of the market, it can provide
both users and manufacturers with a defined path for
future enhancements and features.
Standards, and hence multi-vendor solutions, also
promote efficiencies in other SCADA areas. The
use of communications bearers can be shared
resulting in reduced communication costs, and rare
resources such as radio spectrum can be utilised
more efficiently. As well as standard methodologies
being provided, minimum functionality is specified by
Standards, and can lead to products being delivered
to the market with better specifications. Market
forces are automatically applied to manufacturers due
to the improved competition in open systems. This
can drive the enhancement of products in uniform,
competitive ways and prevent stagnation of the
technology that occurs in closed markets.
With increasingly complex systems all around us,
and the requirements to be smarter and cheaper,
it is one of the challenges of the SCADA industry
to recognise the advantages of applying standard
solutions to these systems. The worldwide SCADA
market is big enough to support standards for the
technologies deployed, and it currently does through
standards such as IEC60870 and DNP3. MODBUS
is often cited as a “standard’ in this respect; however
in comparison with DNP3, for example, the technical
capability of MODBUS has been widely extended in
ad-hoc proprietary ways. Overall the functionality of a
modern MODBUS device is largely non-interoperable
with other MODBUS devices, apart from very basic
exchange of data values.
Of the important improvements in SCADA technology
that DNP3 offers is its handling of a wide range of
communication links. Its native support for change-
based event transactions, time-stamping and historic
recording of data and unsolicited reporting, optimise
data transfer for low speed links. This is particularly
important for legacy communication systems.
Typically these are not practical, economically
viable, or possible to change in a wholesale manner.
DNP3 excels in the area of efficiently handling low
bandwidth links, with the important capability of
ensuring there is no loss of captured data under
conditions of system problems, such as loss of
communications, loss of power, interruption to master
station operation, and so on.
DNP3: a SCADA – RTU Protocol
Originating in North America and based on
IEC60870-5 principles developed in Europe in the
1990’s, DNP3 is now maintained and controlled by
an international User Group. As discussed, DNP3
protocol is now a widely used industry Standard
across multiple sectors in various parts of the world.
The DNP User Group has international representation
from end-user utilities, implementers, vendors, and
service providers. A Technical Committee, that
has proven to be responsive to the requirements
of the user community, supports implementation
and development of the protocol. The Technical
Committee’s recent activities have seen the extension
of the DNP3 standard to include definitions for
SCADA protocol security over low bandwidth wide
area communications systems, and the introduction
of the DNP3 Level 4 subset. There is also an on-
going focus for delivery of detailed conformance
testing for Master station devices to the DNP3
protocol interoperability subsets. This will supplement
the already extensive DNP3 slave protocol
interoperability test procedures.
White paper on DNP3 for Electric Power Utilities | 11
DNP3 Communications for Water and Wastewater Applications
White paper on DNP3 for Electric Power Utilities | 12
DNP3 Communications for Water and Wastewater Applications
Although originally based on Electricity Industry
requirements, DNP3’s generic features, including
its excellent interoperability specifications, are
making it the protocol of choice in many industries
internationally, including the Water industry. DNP3
SCADA system solutions are supported by hundreds
of vendors and user organisations.
Applications of DNP3 capable RTUs
DNP3 standard protocols provide facilities suitable
for the requirements of modern SCADA telemetry
networks.
Some of the features provided by DNP3 include
standardised:
• Highdataintegrityspecifications
This means no misinterpreted or corrupted data!
• PointtopointcommunicationsbetweenSCADA
masters and RTU devices
• Distributedpointtomulti-pointcommunications
between SCADA and RTUs
• Polledcommunications(e.g.cyclic)
• Reportbyexception(changedetection)
• Unsolicitedtransmission(spontaneousdevice
reporting)
• Highaccuracytime-stampedevents,recording
and remembering
This means no loss of data when something goes
wrong!
• Objectbaseddatadefinitions
• Diverseandstronglydefineddatatypesincluding
binary, integer, floating point, accumulators,
controls, strings, point quality information
This means every device using DNP3 handles
and presents data the same way!
• Filedownloadanduploadcapabilities
• TCP/IPcommunicationintegration
• Extensibledeviceandassetinformation
• Groupingofeventandloggeddatabasedon
data models
This means data can be represented and
interpreted in meaningful ways, not just as a list of
numbers!
DNP3 specialises in support for unsolicited reporting
from distributed RTUs on a multi-point network, peer
communications between distributed RTUs, and
transport functions for transfer of mixed data types
and large amounts of data between RTU and SCADA
master stations. Together these provide highly
functional but efficient communications.
Many organisations have discovered the extensibility
of systems based on the DNP3 standard. Forward
planning to use DNP3 in the installation of even
small telemetry networks caters for medium-term
strategies that result in the integration of the existing
small systems into larger networks. I.e. this prevents
initial small systems becoming orphans when a larger
system is implemented.
Intelligent systemic control of distributed assets is
making use of DNP3 Peer-to-peer communications
facilities for coordinating reliable control between
remote sites as well as communicating with SCADA
master stations. The increased efficiency of
communications, particularly in multi-drop systems
on common communication bearers, results in
more efficient use of communications infrastructure.
This has allowed removal of previously dedicated
circuits and amalgamation of radio links to minimise
spectrum requirements and reduce system
interference.
White paper on DNP3 for Electric Power Utilities | 13
DNP3 Communications for Water and Wastewater Applications
The protocol functionality described above is in
contrast to commonly used protocols (of which
MODBUS is an example) that have long being
considered “standard” protocols throughout the
industrial systems community. MODBUS and
other PLC protocols continue to be a popular for
interfacing with PLC systems and will continue to be
important in that area for a long time to come. In
reality though, MODBUS and its counterparts have
been around for a very long time. They have only
standardised basic protocol framing and data value
exchange at a low level. Even so there are now a
myriad of interpretations and variations on device
addressing, register addressing, and data formats
to overcome the simplistic limitations (designed long
ago). Impressively mechanisms such as data logging,
unsolicited reporting and peer to peer operation have
appeared on some MODBUS devices, and have
universally been proprietary extensions with little or no
interoperability between equipment of different brands
(and sometimes not even within the same brand).
MODBUS does not provide consistent definitions for
data reporting, security and interoperability required
for today’s modern SCADA networks.
TCP/IP Communications
TCP/IPistheworld’sbestknownsuiteof
communication protocols suitable for both local area
andwideareanetworking.TCP/IPowesmuchof
its success to its beginnings as a universal open
protocol and indeed it has delivered much of its
promised capabilities for interoperation between
devices. Structured for expansion, its application is
wide spread. It has demonstrated its adaptability to
changes in technology and security concerns over
the years and appears that it will continue to do so
for years to come.
Notsurprisingthen,TCP/IPiswidelyusedinSCADA
networks.SCADA’sintegrationwithTCP/IPprotocols
occurs at many levels from SCADA computer Local
Area Networks, through to communication wide area
networks for SCADA and Corporate data. It has
been increasingly used as transport for RTU telemetry
network communication in recent years. It is in this
area that users have recognised additional benefits
for SCADA. The trends in this area are reflected in
the priority that standards bodies have placed on
defining how RTU communications is handled over
TCP/IPnetworks.
TCP/IPbyitselfisnotsuitableasanRTU
communicationsprotocol.TCP/IPsimplytransports
other protocols around local area or wide area
“Internet” networks. Applications we regularly see
thatareassociatedwithTCP/IPsuchase-mail
(SMTP), file transfer (FTP), network management
(SNMP),hypertextwebformat(HTTP)andsoon,
are separate application protocols transported by
underlyingTCP/IPcommunicationslayers.Similarly
theTCP/IPcommunicationlayerscantransportRTU
protocols, but the RTU protocol itself must be defined
for interoperability.
White paper on DNP3 for Electric Power Utilities | 14
DNP3 Communications for Water and Wastewater Applications
InterconnectionofTCP/IPsystemsisanaccepted
capability of modern systems. Interoperability of
integratedTCP/IPandRTUcommunicationsthen
requires two sets of definitions: a standard methodol-
ogyforusingtheTCP/IPcommunicationslayers;and
a standard RTU protocol. DNP3 RTU protocol has a
strongdefinitionforoperationoverTCP/IP.
AdefinitionforoperationofTCP/IPcommunications
early in DNP3’s life has resulted in proven operation
and wide adoption of DNP3 over modern IP
based communication infrastructure. This includes
operation using spread-spectrum radio and other
Ethernet radio technologies, integration of SCADA
and corporate communications, and cost effective
extension of the reach of telemetry communications
through integration with mobile IP solutions such as
GPRS over GSM, 1xRTT over CDMA, and up-coming
3G communication technologies.
TheuseofTCP/IPasatransportmechanismfor
RTU protocols lends itself to many applications,
but is not applicable in all circumstances. Some
SCADA network designs rely on deterministic (or
close to deterministic) communication networks with
consistentlyfastresponsetimes.WideareaTCP/IP
networks cannot generally deliver this functionality.
Features of DNP3 such as time-stamped events and
unsolicited exception reporting come to the rescue
here, and can alleviate these problems in most
systems, virtually eliminating problems of lost data
suffered by other protocols.
High-speedlocalareaRTUnetworks,andincreasing
use of short to medium range spread spectrum
radio technology, provide Ethernet interoperability
and high performance between master stations and
RTU systems.
SharingcorporatewideareaTCP/IPnetworksor
parts of these networks, between corporate systems
and SCADA can significantly reduce duplicated
infrastructure. Aspects of network performance,
security and the critical nature of SCADA data
need to be evaluated when considering combined
services. The use of external infrastructure, such as
Internet services to distribute lower priority SCADA
data is also possible. Naturally there are increased
security considerations in this environment.
Once again, standards based mechanisms are
available for securing DNP3 in private and public
infrastructure systems.
ManyadvantagesarisefromtheuseofcurrentTCP/
IPtechnology.CommercialTCP/IProutersprovide
advanced facilities for computer communications
such as dynamic re-routing and load balancing on
multiple communication paths. If applied to SCADA
communications, major telemetry sites can be
transparently provided with redundant communication
paths.StandardtoolsavailableforTCP/IPsystems
can also provide increased functionality in the SCADA
environment. Tools such as SNMP and Telnet can be
used for telemetry system management, maintenance
and remote diagnostics.
White paper on DNP3 for Electric Power Utilities | 15
DNP3 Communications for Water and Wastewater Applications
DNP3 in the Water Industry
DNP3 has enjoyed increasing and widespread
popularity and success in the Water Industry globally
over the last 9 years. It has widespread application in
the water sector in Australia, and has been adopted
in some parts of the industry in the USA, as well
as in other countries. DNP3’s strong data types,
functional subsets and extended facilities (such as file
transfer, virtual terminal, floating point data definitions
and so on) has ensured it is technically capable
and interoperable in an environment different from
classical electrical systems. More recently, projects
have adopted DNP3 due to its ability to operate in
meshed networks and in conjunction with modern
encryption security standards.
More recently, an independent assessment for
standardisation of SCADA protocols for the UK Water
sector chose DNP3 as the protocol for systems
across the UK going forward. A national water sector
initiative has defined functionality built upon the
DNP3 standard, to ensure interoperability of master
station and field device vendor’s equipment across
the market. This is known as the Water Industry
Telemetry Standards (WITS) initiative.
The defining features of DNP3 that led to its adoption
as part of the WITS initiatives included:
• Operationoverarangeofcommunicationsmedia
(PSTN, radio, Ethernet, mobile IP, satellite)
• Multi-layeredprotocoltuneableforlowspeed
legacy communication links but with efficient
operation on high speed links
• SourceandDestinationframeaddressing
permitting multi-master and peer-to-peer
communication
• StrongIPnetworkingdefinitions
• Strongdatatypedefinitions,especiallyforfloating
point data
• Strongdataintegrity
• Strongcontrolverification
• NativeStringdatatypes
• NativeEventreportingandaccuratetime-
stamping
• NativeTimesynchronisation
• NativeDataqualityinformation
• NativeFiletransfercapability
• Unsoliciteddatareportingoveranymedia
• Nativeaddressingfor65000+devicesinone
system
• Deviceprofiledefinitionsofdeviceoperation
• SCADASecuritydefinition
• DataSetaggregationfordirectdatamodelling
• WellsupportedUserGroupwithTechnical
support
• Extensibilityforthefuture
In addition to the native DNP3 functionality, WITS has
defined a set of facilities for Water Industry outstation
operation, utilising standard DNP3 capabilities. These
facilities define standard outstation features and
include:
• DefinitionofminimumDNP3requirements
• MandateuseofDNP3’sDevicecapability
reporting (using XML)
• Fielddevice/Masterstationconfiguration
exchange (XML)
• ExtensionofDNP3XMLtoincludeadditional
WITS definitions
• Fielddeviceandassetstatusreporting
• Integratedmasterstation–RTUattribute
configuration
• OutstationBulkconfigurationdownload
• RemotePointperformancemanagement
White paper on DNP3 for Electric Power Utilities | 16
DNP3 Communications for Water and Wastewater Applications
• Alarmlimitandanalogperformanceincremental
configuration
• Backupcommunicationschanneltests
• HistoricandEventdataloggingqueryand
transfer
• Multiplealarmlimitnotification
• Controlapplicationhandling
• Dial-upreportingschedules
Definition and management of these capabilities
is provided by a WITS management panel
representative of the industry (customers, vendors
and consultants).
Further information on WITS and its initiatives utilising
DNP3 is available at www.ukwits.org
The WITS initiative is an excellent example for what
can be achieved in adopting a standard and ensuring
it meets the specific requirements of an industry
sector. Similar philosophies can equally be applied to
Oil/Gassectorreportingrequirements.
White paper on DNP3 for Electric Power Utilities | 17
DNP3 Communications for Water and Wastewater Applications
Enabling Facilities of DNP3
As described in the WITS initiative above, a number
of facilities were available in DNP3 which led to its
choice as the basis for the UK water sector telemetry
standard. These native DNP3 facilities enabled
WITS to provide additional functionality within the
framework of the DNP3 standard. As the DNP3
facilities are tightly specified, their adoption provides
the mechanisms required to assist interoperability
between different vendor’s devices.
Three such facilities are highlighted below as an
example of DNP3’s flexibility:
1) File Transfer
The methodology for file transfer is defined by
the DNP3 standard, providing a comprehensive
mechanism for both downloading files from a
master station or other device to an RTU and
uploading files from an RTU to a master station or
other device. This mechanism specifically handles
low speed communication links by permitting
a file transfer to start but allowing other DNP3
communications to operate, or “interrupt” the
transfer.
The advantage of using a DNP3 file transfer
mechanism as opposed to other mechanisms
(such as FTP) is that it can operate on any
communication bearer, and is tightly coordinated
and if necessary prioritised with respect to other
SCADA data on the same link.
While the transfer mechanism is strongly defined
and highly interoperable, the content of files is
notdefinedbytheprotocol.Hencethereisscope
for a particular industry segment to define the file
format for the purpose of specifically transferring
particular information content. Examples of this
include the Electricity sector’s COMTRADE file
format for power line protection disturbance
records; WITS defines file formats for logged
historic and event data retrievals, including
retrieval separate from the conventional SCADA
master station based on point & time queries.
Similar data constructs can easily be imagined for
Oil and Gas sector data reporting. This is further
explored in this paper, below.
White paper on DNP3 for Electric Power Utilities | 18
DNP3 Communications for Water and Wastewater Applications
2) Data Sets
The structure for defining data models is a native
part of the DNP3 standard and permits flexible
combinations of DNP3 data primitives to be
grouped. This includes modelling physical devices
by grouping related data; grouping unrelated data
but with a common time-stamp, adding value to
existing DNP3 data constructs, and so on.
DNP3 data sets support a data prototype
mechanism (equivalent of a template) whose
format (or model) can be defined and re-used.
These prototypes include identifiers for version
management, allowing standard data definitions
to be extended, and identifying which version
of a definition is in current use in a device.
This unravels a multitude of compatibility and
interoperability issues experienced by systems
in the past, where different devices implement
different “versions” of data formats, and are
incompatible.
Examples of Data Sets usage includes modelling
power line feeders, water system pumps and
valves, grouping asset status, adding multiple
alarm limit indicators to DNP3 analog point
events, and so on. Once again, it can be
envisaged that data sets can be applied to Oil
and Gas data reporting.
3) Capabilities definition
With the introduction of XML capabilities
reporting, a master station device can
electronically identify the capabilities of each
device to which is communicates, automatically
adjusting how it interacts and interprets data from
each device. The master station can “learn” about
a device’s capability in a number of ways. An
XML file may be provided by the device vendor
on electronic media or via the Internet. This
would be loaded in to the master station during
configuration time. Alternatively, a capabilities
file may be uploaded from the device itself as
part of the start-up communications sequence.
The file may additionally include configuration
information, allowing the master station to
generate configuration automatically reducing
duplicate data entry (and improving accuracy of
the configuration process). This has large benefits
for systems engineering, going forward.
The capabilities provided by DNP3 at the ‘coal-face’
of data gathering and reporting are similar to some
of the mechanisms described in PRODML (and
other) standards for computer application information
interchange. Data modelling, self description and
providing interoperable data definitions are emerging
as important corporate requirements to leverage the
best use of business “information”. DNP3 is providing
the same leverage in this lower tier of the ‘information
providing’ systems.
White paper on DNP3 for Electric Power Utilities | 19
DNP3 Communications for Water and Wastewater Applications
DNP3 for EFM
Communication protocols used in oil and gas
systems, including electronic flow measurement
(EFM), have typically been characterised by
proprietary solutions (similar to those experienced in
other sectors as described in this paper).
Some solutions for EFM have been based on the
MODBUS “standard”, which is inevitably extended in
proprietary ways to provide EFM capabilities. ENRON
MODBUS is one such protocol that has become a
pseudo-standard definition that extends MODBUS
to provide EFM facilities. Further vendor specific
extensions to this “standard” have also emerged into
the market from time to time.
Unfortunately the nature of EFM communications
being based on proprietary protocols and proprietary
extensions of other protocols has invariably prevented
interoperation of devices. Over time it has become
the norm for EFM systems to require expensive and
complex protocol translators to facilitate system
growth, and modernisation.
While protocols such as MODBUS have been
successfully manipulated by individual manufacturers
to provide EFM functionality, many still lack flexible
and comprehensive SCADA facilities to go along with
the EFM capabilities of the protocol.
As described in this paper, DNP3 has a
comprehensive set of SCADA communication
facilities that are also directly applicable to EFM
systems. The strong data type definitions and
standard facilities of DNP3 are ideal for both SCADA
and EFM communications.
DNP3 has as well defined set of tools within the
protocol that allow the definition of expanded
functionality in standard and manageable ways.
These include definitions of aggregated data forms
for online transactions between field devices and
master stations, as well as offline mechanisms for
coordinating configuration between field devices and
master stations.
For example, the following DNP3 facilities are fully
defined and would be applicable to Oil and Gas
systems SCADA and EFM data:
• 16-bitand32-bitintegerdata
• 32-bitand64-bitfloatingpointdata
• currentvalue(staticdata)andtime-stamped
event data for all data types
• flexibledatagroupingforeventandcurrentvalue
data polling
• flexibleunsoliciteddatareporting
• DNP3filetransfer
• DNP3datasets
• DNP3group0assetandconfiguration
management
• DNP3devicecapabilityreporting(XML)
• DNP3deviceconfigurationexchange(XML)
• DNP3VirtualTerminalfortransportingnative
communications to intelligent field devices across
a DNP3 communications link
Examples of EFM specific requirements that can
be defined and mapped directly to DNP3 facilities
include:
• Hourlylogs
• Dailylogs
• FlowAccumulation
• Alarmlogs
• Gasflowcompositions
• Flowrunconfigurations
White paper on DNP3 for Electric Power Utilities | 20
DNP3 Communications for Water and Wastewater Applications
There is a close correlation between EFM
requirements and native facilities provided by DNP3.
A combination of file format definitions and data set
prototypes would see a majority of EFM reporting
mechanisms standardised fairly easily. The beauty
of such definitions is that they are not locked in
to the protocol definition, for which future change
or adaptation would lead to the interoperability
constraints that currently exist in the industry today.
Versioningoffileformatsanddatasetprototypes
will ensure that data definitions can be flexible in the
future, whilst maintaining protocol compatibility and
data definition compatibility with the initial definitions
that can be defined now.
DNP3 undoubtedly has the features, capabilities, and
track-record in other sectors, and potentially can be a
significant force in providing tightly coupled EFM and
SCADA communications going forward.
Conclusion
Standards Providing Solutions
Some of the advantages that Standards such as DNP3 can deliver have been
detailed in this paper. In numerous industry sectors and countries across the
globe, both users and manufacturers are benefiting from the movement away
from proprietary based and proprietary extended systems, towards Standards
based systems.
Driven by market forces, and in response to key requirements of users, installed
systems implementing international standards are realising their potential and
delivering significant benefits to the SCADA industry. DNP3 has been particularly
successful in the electricity and water sectors, globally. Oil and Gas sectors,
including in the EFM area, can also leverage value from DNP3 in similar ways,
going forward.
More information is available from Control Microsystems Inc.
www.controlmicrosystems.com
White paper on DNP3 for Electric Power Utilities | 21
DNP3 Communications for Water and Wastewater Applications
Schneider Electric
Telemetry & Remote SCADA Solutions48 Steacie Drive, Kanata, Ontario K2K 2A9 Canada Direct Worldwide: 1 (613) 591-1943Fax: 1 (613) 591-1022Toll Free within North America: 1 (888) 267-2232www.schneider-electric.com
Document Number TBUL00001-24
© 2
011
Sch
neid
er E
lect
ric. A
ll rig
hts
rese
rved
.
February 2012 tk
This document has beenprinted on recycled paper