dnp3 – more than just an electric power utilities protocol

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


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.




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



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



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.



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



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.



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.



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.





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.



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.



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.



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



• 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.



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.



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.



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



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



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

dnp3 – more than just an electric power utilities protocol

Documents