IEEE DPN3

IEEE Standard for Electric Power Systems Communications— Distributed Network Protocol (DNP3)

IEEE Power and Energy Society

Sponsored by the Transmission and Distribution Committee and Substations Committee

IEEE 3 Park Avenue New York, NY 10016-5997 USA

IEEE Std 1815™-2012 (Revision of IEEE Std 1815-2010)

10 October 2012

Authorized licensed use limited to: UNIVERSIDADE FEDERAL DA BAHIA. Downloaded on August 10,2015 at 14:58:21 UTC from IEEE Xplore. Restrictions apply.


IEEE Std 1815TM-2012 (Revision of IEEE Std 1815-2010)

IEEE Standard for Electric Power Systems Communications— Distributed Network Protocol (DNP3) Sponsor Transmission and Distribution Committee and Substations Committee of the IEEE Power and Energy Society Approved 8 June 2012 IEEE-SA Standards Board


The Working Group thanks the International Electrotechnical Commission (IEC) for permission to reproduce information from the International Standards IEC/TS 62351-3 ed. 1.0 (2007), IEC/TS 62351-5 ed. 1.0 (2009), and IEC/TS 62351-8 ed. 1.0 (2011). All such extracts are copyright of IEC, Geneva, Switzerland. All rights reserved. Further information on the IEC is available from www.iec.ch. IEC has no responsibility for the placement and context in which the extracts and contents are reproduced by the author, nor is IEC in any way responsible for the other content or accuracy therein. Abstract: The DNP3 protocol structure, functions, and interoperable application options (subset levels) are specified. The simplest application level is intended for low-cost distribution feeder devices, and the most complex for full-featured systems. The appropriate level is selected to suit the functionality required in each device. The protocol is suitable for operation on a variety of communication media consistent with the makeup of most electric power communication systems. Keywords: Distributed Network Protocol (DNP3), distribution automation, distribution feeder, electric power communication systems, IEEE 1815, master station, substation automation

•

The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2012 by The Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 10 October 2012. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and Electronics Engineers, Incorporated. PDF: Print:

ISBN 978-0-7381-7292-7 ISBN 978-0-7381-7344-3

STD97267 STDPD97267

IEEE prohibits discrimination, harassment and bullying. For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.


Notice and Disclaimer of Liability Concerning the Use of IEEE Documents: IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While IEEE administers the process and establishes rules to promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained in its standards. Use of an IEEE Standard is wholly voluntary. IEEE disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon any IEEE Standard document. IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained in its standards is free from patent infringement. IEEE Standards documents are supplied "AS IS." The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard. In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard. Translations: The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard. Official Statements: A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered the official position of IEEE or any of its committees and shall not be considered to be, nor be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position of IEEE. Comments on Standards: Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important to ensure that any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to comments or questions except in those cases where the matter has previously been addressed. Any person who would like to participate in evaluating comments or revisions to an IEEE standard is welcome to join the relevant IEEE working group at http://standards.ieee.org/develop/wg/. Comments on standards should be submitted to the following address: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854-4141 USA Photocopies: Authorization to photocopy portions of any individual standard for internal or personal use is granted by The Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center.


Notice to users Laws and regulations Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so.

Copyrights This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private selfregulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document.

Updating of IEEE documents Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE-SA Website at http://standards.ieee.org/index.html or contact the IEEE at the address listed previously. For more information about the IEEE Standards Association or the IEEE standards development process, visit IEEE-SA Website at http://standards.ieee.org/index.html.

Errata Errata, if any, for this and all other standards can be accessed at the following URL: http://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically.

iv Copyright © 2012 IEEE. All rights reserved.


Patents Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-SA Website at http://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association.

v Copyright © 2012 IEEE. All rights reserved.


Participants At the time this standard was submitted to the IEEE-SA Standards Board for approval, the Standard for Electric Power Systems Communications—Distributed Network Protocol (DNP3) Working Group had the following membership: H. Lee Smith, Co-Chair Ron Farquharson, Co-Chair Andrew West, Vice Chair Bill Ackerman Demos Andreou Philip Aubin Jim Baker James Bougie Jake Brodsky Carlos Bustamante Ed Cenzon Mason Clark Lorene Cunningham Mike Dood

Chris Francis Charles Freedman Dan Friedman Grant Gilchrist Randy Kimura Marc Lacroix Bob Landman Parker McCauley Steve McCoy Bruce Muschlitz Craig Preuss James Recchia

Craig Rodine Samuel Sciacca Alan Scott Barry Shephard Michael S. Smith John T. Tengdin Eric Thibodeau Tim Tibbals Jay Vellore Jack Verson David Wood

The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention. Bill Ackerman Satish Aggarwal Ali Al Awazi Saleman Alibhay Ficheux Arnaud Jim Baker Wallace Binder Paul Bishop Chris Brooks William Byrd Paul Cardinal Edgar Cenzon Jerry Corkran Lorene Cunningham Ray Davis Muhammad Dhodhi Mike Dood Randall Dotson Gary Engmann Ron Farquharson Dan Friedman Grant Gilchrist Mietek Glinkowski Roman Graf Stephen Grier Randall Groves Timothy Hayden Gary Heuston Gary Hoffman Yi Hu

Noriyuki Ikeuchi Piotr Karocki Yuri Khersonsky James Kinney Stanley Klein Joseph L. Koepfinger Jim Kulchisky Marc Lacroix Chung-Yiu Lam G. Luri Ahmad Mahinfallah Wayne Manges Pierre Martin Jeffery Masters John McDonald Gary McNaughton Willam Moncrief Jose Morales Charles Morgan Adi Mulawarman R. Muprhy Bruce Muschlitz Pratap Mysore Arthur Neubauer Michael S. Newman Charles Ngethe Gary Nissen Lorraine Padden Mirko Palazzo

Donald Parker Bansi Patel Craig Preuss John Randolph Michael Roberts Charles Rogers Bob Saint Steven Sano Bartien Sayogo Samuel Sciacca Gil Shultz Mark Simon Jerry Smith Joshua Smith Aaron Snyder John Spare Wayne Stec Gary Stoedter Walter Struppler Charles Sufana William Taylor David Tepen Eric Thibodeau Eric Udren John Vergis Jane Verner Daniel Ward Andrew West Janusz Zalewski Matthew Zeedyk

vi Copyright © 2012 IEEE. All rights reserved.


When the IEEE-SA Standards Board approved this standard on 8 June 2012, it had the following membership: Richard H. Hulett, Chair John Kulick, Vice Chair Robert Grow, Past Chair Satish Aggarwal Masayuki Ariyoshi Peter Balma William Bartley Ted Burse Clint Chaplin Wael Diab Jean-Philippe Faure

Alexander Gelman Paul Houzé Jim Hughes Young Kyun Kim Joseph L. Koepfinger* David J. Law Thomas Lee Hung Ling

Oleg Logvinov Ted Olsen Gary Robinson Jon Walter Rosdahl Mike Seavey Yatin Trivedi Phil Winston Yu Yuan

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons: Richard DeBlasio, DOE Representative Michael Janezic, NIST Representative Don Messina IEEE Standards Program Manager, Document Development Matthew J. Ceglia IEEE Standards Client Services Manager, Professional Services

vii Copyright © 2012 IEEE. All rights reserved.


0

Introduction

This in ntroduction is no ot part of IEEE Std 1815-2012,, IEEE Standardd for Electric Poower Systems C Communications— — Distrib buted Network Prrotocol (DNP3)..

0.1

DNP3 pu urpose and history

This Introduction discusses the creeation and histtory of DNP3. The structure and operationn of the protocol b easier to und derstand when taken in the context c of the pproblems the ddesigners of DN NP3 intended to may be solve. 0.1.1

Addressin ng an impediiment to auto omation

Westro onic Incorporaated developed d DNP3 betweeen 1992 and 11994, intendinng it to be the first truly opeen, truly useful u protocoll standard in th he utility industtry. Westronic was a manufaccturer of remotte terminal uniits and a system integrator based in n Calgary, Can nada. It had m made a reputaation convertinng between thhe hundreeds of proprieetary utility prrotocols in usee at the time. This was nott an easy taskk, however, annd Westro onic managem ment had becom me frustrated with w trying to make its deviices compatiblle with so manny proprietary protocolss. A prop posal was mad de that Westro onic should dev velop its own protocol but tthen release it to the industrry. The new protocol would w incorporaate the best feeatures of the m many protocolls Westronic hhad encountereed, plus some new ideas. Westronic would w place the specificationn under the conntrol of an inddependent userrs’ vited to be meembers, includding Westronicc’s competitorrs. group.. Both utilitiess and vendors would be inv Westro onic would nott receive any money m for the sale s and distribbution of the sppecification. 0.1.2

Rationale for a new prrotocol based on standarrds

Westro onic was not th he first to prop pose an open standard s for thee utility industtry, but the dessigners of DNP P3 did no ot find any of the t existing effforts suitable. At A the time whhen Westronic was consideriing DNP3, there were two t main candiidates availablee for an open protocol: p ⎯ The Electrical Power Ressearch Institutee (EPRI) had reecently releaseed the Utility C Communicationns on 1.0. Howev ver, version 1.00 listed a choicce of protocol pprofiles only annd Architecture (UCA) versio did not defiine any object models m or serv vices suitable ffor performing Supervisory C Control and Daata Acquisition n (SCADA) fun nctions. At thaat point in the development of UCA, veryy few utilities oor vendors haad provided in nput to the speecification, annd there were some serious concerns about bandwidth usage. These drawbacks and others eventtually led to tthe developmeent of UCA 2.0. E technical repo ort in 1998 andd eventually evvolved into IEC C 61850.a UCA 2.0 beecame an IEEE ⎯ The Internaational Electrotechnical Com mmission (IEC)) had developeed the first few w documents in the IEC 60 0870-5 series of specificatio ons, including the specifics of the Data L Link Layer annd general deffinitions for thee Application Layer. (At thaat time, it was called just 8770-5.) Westronnic had been participating in this effort butt felt that it waas progressingg too slowly. F Furthermore, thhe IEC had prrovided many options in thee specificationn, and Westronnic was worriied the standarrd would not be restrictive enough to prromote interopperability. Thee IEC eventuaally released thhe 01-companion standard s in 199 95 to address thhese issues. 60870-5-10 In 199 92, the IEC work seemed to be b the more com mplete of the ttwo efforts andd had wider inddustry support at the tim me. Westronic therefore deciided to base DNP3 D on the IE EC work alreaady completed. Even now, thhe

a

Inform mation on referencees can be found in Clause 2.

viii Copyright © 2012 IEEE. All rightts reserved.


featuree sets of IEC 60870-5-101:2 2003 [B3]b an nd DNP3 are vvery similar beecause the dessign teams buiilt them on o the same baasic research. UCA was not forgo otten. Westron nic (by then caalled Harris D Distributed Aut utomation Prodducts) circulateed NP3 Basic 4 Document Set S including a paper calleed “On the R Road to Utility versions of the DN munications Architecture.” Th he thesis of this paper was thaat by standardiizing on DNP33, utilities wouuld Comm at leasst be reducing from f many pro otocols to one. This would m make it easy forr utilities to lateer change to usse UCA. However, veery few design n elements of UCA found their way intoo this standarrd, other than a generaally layered arcchitecture. 0.1.3

Need for scalability s

The deesigners of DN NP3 built it witth several goalss in mind, but tthe one that haad the most imppact on the finnal protoccol was the industry’s desire to t limit the am mount of bandw width used. At tthat time, utilitties consideredd a link ru unning at 1200 0 bits per secon nd to be fairly quick. (Yes, th there are areas where this is still true). Loccal area networks n (LAN Ns) were for offfice computing g only, and thee thought of tru rusting one’s S SCADA networrk to a th hird-party telecom provider was w heresy. Powerr utilities had heard h about lay yered protocolls and the Opeen System Inteerconnection (O OSI) model, but they were w unconvin nced of their value v in a SCA ADA protocoll. The Interneet was beginniing to boom, oof coursee, but most utiilities considerred those prottocols for busiiness computinng only. Theyy were not for a SCAD DA network. Those who follo owed such thin ngs may also hhave heard thaat there was a bbacklash againnst the OS SI model brew wing. Protocolss like Asynchrronous Transfeer Mode (ATM M) and Frame Relay promiseed higherr performance by eliminating g layers. No uttility at that tim me would havee used these protocols in theeir network, but they pro obably heard th hat “layers are bad.” Thereffore, the design ners of DNP3 gave g themselves a design goaal to reduce baandwidth and uuse as few layeers as posssible. This goal g combined with the desiree to be compliaant with IEC 660870-5 resulteed in the “Trannsport Functionn” as it now n exists: a header that iss not quite parrt of the Dataa Link Layer aand yet not qquite a compleete Transp port Layer. A later l subclause will discuss th he Transport Fuunction in morre detail. 0.1.4

Emphasis s on reliabilitty

While requesting leess bandwidth, utilities refu used to comprromise on the requirement that a SCAD DA protoccol be extremelly reliable. Earrly bit-oriented d protocols hadd acquired a baad reputation because a changge of a single bit could d result in a device d operatin ng the wrong sswitch. This leed to utilities requiring in bid fications that vendors v build select-before-o s operate, “I tell you twice,” ffunctions into all protocols. A specifi few baad experiences made utilities paranoid abou ut reliability to the point of w writing it into coontracts. Thereffore, when dessigning a framee format to usee, the DNP3 d esigners chosee the most reliaable format theey could find. The IEC had done extensive e mod deling on reliaability and haad documentedd the results in 6 0 [B3]. Ratherr than reinventt the wheel, thhe designers piicked the most reliable of thhe IEC 60870-5-1:1990 severaal formats described in that sp pecification, Frrame Type 3 (F FT3). In the years that hav ve passed, thiss decision has proven to be a good one. M Many vendors have cursed thhe y cyclic redund dancy checks ((CRCs). Manyy system engineeers have curseed calculaations necessarry for the many the ex xtra bandwidth h overhead. However, H DNP P3’s reputationn for reliabilitty started welll and has onnly improv ved with the yeears.

b

The nu umbers in bracketss correspond to tho ose of the bibliograaphy in Annex G..

ix Copyright © 2012 IEEE. All rightts reserved.


0.1.5

Feature se election

Becau use the designeers of DNP3 were w from a sy ystems integrattion company, they tried to incorporate into DNP3 the best featurres of all the uttility protocolss they had encoountered. Thesee features incluuded: ⎯ Broadcastin ng. The ability to send a singlle message to m multiple devicees. ⎯ Select-before-operate—orr not. The ability to choosee to use extra reliability when operating aan o choose not to o use it. output, or to ⎯ Time-stamp ped data. Somee of the most popular utilityy protocols, succh as Modbus, had no way to accurately time-stamp t datta. Vendors and utilities weree forced to devvelop proprietaary work-arounnd solutions. Other O protocolss supported tim me stamps on bbinary data onlly. DNP3 perm mits time stampps on almost all a data. This feature has beecome increassingly more usseful as utilitiees progressively gather otherr types of histo orical data beyo ond the standarrd binary “sequuence of eventts” log. ⎯ Accurate tim me synchronization. Many eaarlier protocolss had no way too account for ttransmission annd software deelays when syn nchronizing. The T method ussed in DNP3 iis an amalgam mation of severral different protocols’ solutio ons. ⎯ Quality flag gs. Representin ng a maker of data d concentraators, the desiggners provided a mechanism to see whetherr data was vallid, and why. Some protocolls, designed byy intelligent electronic devicce (IED) vendors whose dataa was always online, o did not iinclude this feaature. ⎯ Multiple daata formats. Th he ability to rep port data in a vvariety of form mats: 16-bit, 32-bit, with a flaag, without a fllag, floating-po oint, binary-cod ded decimal (B BCD), packed, unpacked, andd so on. ⎯ Scan groups. The ability to t define and ask a for a large sset of otherwisse unrelated data using a singgle request. ⎯ Layer separation. Separaating the functtion of “gettinng the data theere” from the actual SCAD DA functions. ⎯ Report-by-eexception. Morre than any oth her feature, thee ability to reliaably report onlyy the changes in data has hellped make DNP3 successful. ⎯ Internal ind dications. As seeveral protocol efforts that aree more recent tthan DNP3 havve discovered, it is extremely y useful to hav ve a global set of flags return ed in each respponse. These fl flags indicate thhe health of the device and th he results of the last request. Most of these featurres had been seen s elsewheree, but this wass the first timee an open utiliity protocol haad pted to do them m all. attemp 0.1.6

Rationale for DNP3 su ubset definitiions

Unforttunately, the “best “ practices” approach to developing D DNP3 was not perfect, causinng a number oof featurees to be added d that were nott really in wideespread use. A number of thhem existed onnly in Westronnic equipm ment. At variou us times, vendo ors have questiioned the needd for: ⎯ So many different types of o counters, parrticularly delta counters ⎯ So many different types of o binary output operations, esspecially contrrol queuing ⎯ So many different ways to o format data (ii.e., many quallifier codes) ⎯ Pattern massks ⎯ Binary-codeed decimal anaalogs ⎯ Storage objects

x Copyright © 2012 IEEE. All rightts reserved.


⎯ The ability to either write or operate an output o ⎯ So many lay yers of confirm mation and segm mentation 0.1.7

Features to t support distributed ca apabilities

Anoth her trend in thee early 1990s was the movee to put largerr processors aand more mem mory in SCAD DA devicees. Marketing and sales peo ople were talkiing about “thee intelligent neetwork.” By tthis, they meaant pushin ng many of thee functions previously perfo ormed only by master stationns into remotee devices. Thesse devicees would be more m independeent and make more decisionns on their ow wn. Those whoo join the utility industtry these days are a sometimes confused by th he term “IED”” meaning intellligent electronnic device. Theey say, “A Aren’t all comp puting devices intelligent?” Yes, Y but it wasnn’t always thiss way. In term ms of DNP3 deesign, the idea of “the intellig gent network” ttranslated to thhe following features: ⎯ Spontaneou us reporting. A device could transmit whennever it wantedd, not just wheen polled by thhe master. On multi-drop link ks, this led to the t need for a ccollision avoiddance mechanissm. ⎯ Meta-data. The DNP3 dessigners called a spontaneouss message an ““Unsolicited Reesponse,” whicch hose days. Most devices onlly sent data inn response to a poll requesst. shows the mindset in th ways knew wh hat data was coming. For a device to sendd an unsoliciteed Therefore, the master alw S data ittself but also innformation desscribing the daata response, itt had to includee not only the SCADA so the master knew what it was. The terrm these days ffor such inform mation is metaa-data. It appeaars in such mod dern technolog gies as Extensib ble Markup Laanguage (XML L). At that timee, though, it waas a very new concept for thee utility industrry. ⎯ Wild-cardin ng. Because th he remote devicce was more inntelligent, the designers gavee it more choicce in the amou unt and formatt of the data itt reported. A m master could aask very simplee questions, likke “Give me all a your data” or o “Give me yo our analog channges” and get vvery complex answers. Agaiin, because thee answer did no ot exactly matcch the questionn, meta-data waas required in tthe response. ⎯ Self-descrip ption. The ideaa that a device could c tell the m master what daata it had availaable, and how to present it, was w already aro ound thanks to o UCA 1.0. Thhe DNP3 desiggners tried to inncorporate som me of this abiliity into DNP3. The Device Profile P Object and the use oof floating-poinnt with the uniits transmitted were consideered very adv vanced. Perhap aps they were too advanced because theey n very few impllementations. appeared in ⎯ Vendor-speecific expansion. This standard includes thee Private Regisstration Objectt, which permiits vendors to add proprietaary extensions to the basic standard. Thee Private Reggistration Objeect ndard implemeentation to paarse these exteensions even tthough they aare Descriptor permits a stan proprietary.. These objectss, too, have no ot been very poopular, but a feew vendors haave used them to good effect. ⎯ File transfer. The designers gave DNP3 file transfer caapabilities so tthat an intelligeent device couuld n configurattion or softwaare, or upload oscillography files. At the ttime DNP3 waas download new developed, few devices had h flash memo ory, and only sspecialized fauult recorder devvices performeed hy. Now both are a widespread d. oscillograph ⎯ Program co ontrol. The ability to start and a stop indivvidual program ms and processses on a remoote device was common in th he factory autom mation industryy. DNP3 proviides a rudimenntary mechanism to do this. The dream d of the “iintelligent netw work” has had d mixed resultss. Some of theese features, liike spontaneouus reportiing, meta-dataa, prioritization n and wild-card ding, have woorked very welll. They are prrobably some oof the maain reasons forr DNP3’s popu ularity. Other features, like self-description, file transferr, floating-poinnt, prograam control, and d collision avoiidance, were not n completely thought out. T The DNP Technnical Committeee was fo orced to revise these and issue technical bullletins clarifyinng their use. Soome features have died a deaath of obsscurity.

xi Copyright © 2012 IEEE. All rightts reserved.


Howev ver, history sho ould not be a harsh h judge. Many M people takke such featurees for granted tthese days, but it is important to remem mber that DNP P3 was there firrst. 0.1.8

Additiona al communica ations featurres

Becau use of the inten nse pressure to reduce bandw width, and becaause the DNP33 designers hadd more expertisse in SCA ADA than in general g data com mmunications,, a number of ccommon comm munications feaatures were “leeft out” of o the DNP3 definition. d Man ny designers have h subsequenntly mourned tthe absence off these featurees. Some of them the DNP D Technical Committee haas attempted too “add on” afteerward. Otherss the Committeee n at the cost of obsoleting all existing imp mplementations.. could only achieve now The fo ollowing list of o missing datta communicattions features illustrates how w well the DN NP3 architectuure works despite the lim mitations impossed at its birth:: ⎯ Network laayer. At one point, p the desig gners actually wrote a speciification for a DNP3 networrk layer, but Westronic W manaagement did no ot approve it. IIn retrospect, tthis is just as w well, because thhe Internet Pro otocol (IP) netw work layer now w used is far moore popular. ⎯ Application n Layer addressses. The ability y to select a paarticular logicaal device withinn a physical onne would havee been useful. Most M devices th hat support thiss feature have found a way arround it througgh local softwaare mechanism ms that use the Data D Link addrress and/or phyysical port num mber as a key. ⎯ Application n and Transporrt Layer sequen nce number iniitialization. Thhis has caused much grief over the years and a has been addressed ass well as posssible withoutt causing obsoolescence. Daata communicaations experts should note, th herefore, that DNP3 is not quite connectiion-oriented annd not quite co onnectionless, but b somewheree in between. ⎯ Long sequeence numbers. DNP3 sequen nce numbers aare very short, which is goodd for bandwiddth but not forr detecting du uplicates. This is the reasonn Transmissioon Control Prootocol (TCP) is required wh hen using DNP P3 over wide area a networks ((WANs), which turns out to bbe a very robuust solution. ⎯ Sequence number n in Daata Link Conffirms. Withouut a sequence number, it iss impossible to determine which w Data Lin nk frame a Co onfirm frame iss answering. O On a serial poiint-to-point linnk, this is not a problem, butt on a WAN, Confirm C frame s could arrive out of order oor be lost. Usinng TCP in WA ANs addresses the issue on IP I networks, buut in theory, itt could still caause problems in serial radio o networks. In practice, it geenerally workss anyway. Thiss problem wass inherited from IEC 60870--5 and cannot be b changed witthout obsolesceence. ⎯ Sliding win ndow. One con nstant of DNP3 has been that only one transsaction can be outstanding att a time. In theory, a devicee could send several s responnse fragments very quickly for a particular mittee has decidded that interopperability is beest request, butt over the yearrs the DNP Tecchnical Comm served by enforcing a con nfirmation betw ween each fragm ment. ⎯ Access secu urity. The desiigners of DNP3 purposely avvoided dealingg with this issuue because of iits complexity. However, th he flexible sttructure of DN NP3 has perm mitted access security to bbe NP3 Secure A Authentication enables a D DNP3 master oor integrated as an optionaal feature. DN t unambiguou usly determinee that it is com mmunicating w with the correcct device and/oor outstation to authorized user. u ⎯ Version con ntrol. Most pro otocols tend to have an octet reserved to shhow the versionn of the protocol in use. Thiss was not inclu uded in the orig ginal DNP3 deefinition due too bandwidth reeasons; howeveer, the introducction of Objectt Group 0 addreesses this probblem. ⎯ Overall len ngth field. Seg gmentation and d fragmentatioon would havee been a lot eeasier and more robust, and the LAN impllementation wo ould have beenn easier if eachh fragment had a length field at ng. It was not included for bandwidth reasoons. Again, vaarious softwaree solutions makke the beginnin it work anyway, so perhap ps it was the rig ght decision.

xii Copyright © 2012 IEEE. All rightts reserved.


0.1.9

Compatib bility with IEC C protocols

As disscussed earlier, there were tw wo reasons wh hy the DNP3 ddesigners wantted it to be com mpliant with thhe IEC 60 0870-5 specificcations: ⎯ They wanteed to take adv vantage of thee excellent techhnical work ddone on reliability in the IE EC 60870-5 Daata Link Layer specifications. ⎯ They wanteed to increase th he acceptance of the protoco l by showing it was based onn standards worrk that was alrready well know wn. They were w so successsful in both effforts that even n now some peeople are confuused about whether DNP3 annd IEC 60 0870-5 are inteeroperable. The an nswer is that they t are not in nteroperable, although a the D DNP3 Data Linnk Layer couldd be considereed complliant to IEC 60870-5-1:1990 0 [B3] and IE EC 60870-5-2: 1992 [B5]. DN NP3 was baseed on the draffts availab ble at the timee of IEC 60870 0-5 Parts 1 thro ough 5. These Parts of the sppecification desscribed the Daata Link Layer L in great detail and thee Application Layer L in generral. There weree several optioons specified fo for the Daata Link Layer.. The DNP3 D designerss chose those options o of IEC C 60870-5-1:19990 [B3] and IIEC 60870-5-22:1992 [B5] theey though ht were most appropriate. a Un nfortunately, when w the IEC 660870-5-101:22003 [B4] com mpanion standarrd was reeleased with th he details of th he Application Layer, it spec ified different Data Link Layyer options thaan those the t DNP3 desiigners had chossen. Thereffore, DNP3 is considered com mpliant with IE EC 60870-5-1: 1990 [B3] andd 60870-5-2:19992 [B5] but not with IE EC 60870-5-10 01:2003 [B4]. Table 0-1 shows thee differences in n the Data Link k Layers of the two protocols.

xiii Copyright © 2012 IEEE. All rightts reserved.


Table 0-1—Comparison of IEC 60870-5 and DNP3 Data Link Layers

Feature

Addressing

Options permitted in IEC 60870-5-1:1990 [B3] and IEC 60870-5-2:1992 [B5]

Single address, length systemdependent

Chosen by DNP3 Two-octet Source address and two-octet Destination address. Considered a single fouroctet “structured” address for compliance purposes.

Chosen by IEC 60870-5-101:2003 [B4]

Single address, choice of either zero, one, or two octets in length

Choice of FT1.1, FT1.2, FT2, and FT3

FT3, transmitted asynchronously.

FT1.2

Varies per frame type

Multiple 16-bit CRCs over each 16 octets of a 255-octet frame. Start and Stop bits, but no parity.

Parity bits and one-octet checksum (not CRC) calculated over 255 octets

Hamming Distance

Varies per frame type

6 for the original FT3. Some debate about the value as currently used. See further discussion in this subclause.

4

Acknowledgments

Either fixed-length or singleoctet

Fixed 10-octet only.

Either fixed-length or singleoctet

Procedures

Balanced (no master) or Unbalanced (master polls)

Balanced only.

Either Balanced or Unbalanced

Method for MultiDrop Links

Unbalanced mode

Collision avoidance.

Unbalanced mode

Frame Format Reliability Mechanism

0.1.9.1

Hamming Distance

Some critics of DNP3 have disputed DNP3’s right to claim a Hamming Distance of six. The “Hamming Distance” of a protocol is the number of bit errors required in a frame before a receiver could incorrectly identify a corrupted incoming frame as a valid frame. Critics argue that the original calculation was made assuming the FT3 frame was transmitted synchronously, while DNP3 uses the FT3 frame format asynchronously. The main concern in this debate is inter-character gaps. If a gap is permitted between the octets of a 16octet block, noise could be introduced that might be misinterpreted as valid data. In fact, it has been shown that there exists at least one case where an inter-character gap of exactly 1-bit time at the end of a message can be misinterpreted, thereby resulting in a Hamming distance of 2. Critics claim that this standard has never required that all octets of a block be transmitted together, and this reduces the theoretical reliability of the protocol to below that of the FT1.2 frame. However, years of use in hundreds of systems have proven DNP3’s reliability to be more than sufficient for utility purposes. This may be due to the fact that most DNP3 devices transmit frames without intercharacter gaps, and receiving devices tend to start a timer or other mechanism that discards incoming frames when inter-character gaps appear. The inter-character concern with the DNP3 frame is similar to a problem that occurs in some IEC 608705101 systems. The FT1.2 frame’s reliability relies on the use of parity bits in each octet. However, many utilities mistakenly use the protocol with modems that do not add, or actually remove, such parity bits. The IEC is preparing an IEC 60870-5 standard that clarifies parity bits shall be used.

xiv Copyright © 2012 IEEE. All rights reserved.


0.1.9.2

Address sing of binary y outputs

The otther main issuee concerning DNP3 D compliance to IEC 60 870-5 was thee structure of thhe address fielld. The IE EC definition of o the address field states thaat it is a singlee address, always addressingg one end of thhe link. This T is the way IEC 60870-5-101:2003 [B4]] uses the addreess field. By inccluding both a source and a destination in every messagge, the DNP3 ddesigners perm mitted the use oof multip ple masters on n the same lin nk, and peer-tto-peer comm munications. Thhis proved to be a powerfful argum ment in the accceptance of DNP3. D Furtherm more, since IE EC 60870-5-2:1992 [B5] diid not specify a particu ular length off address, a fo our-octet addreess that just hhappened to be “structured”” with two subbaddressses could still be considered compliant. 0.1.9.3

Reality today t

Althou ugh it was the topic of lively y debate when n DNP3 was fiirst released, thhe question off whether DNP P3 compllies with IEC 60870-5 6 is esseentially a moott point today. D DNP3 may be considered coompliant to Parrts 1 and 2. One could even argue thaat DNP3 comp plies with the sspirit, if not thhe letter, of Part 5, the generral wever, the form mat of the IEC 660870-5-101 [[B2] Applicatioon Layer is verry Appliccation Layer definition. How differeent from that of DNP3. It is clear c the two prrotocols could never interopeerate. It is beetter to consideer the two proto ocol suites as cousins c with a common familly tree and leavve it at that. 0.1.10 0 Transportt Function The naaming of the Transport T Functtion always con nfuses newcom mers to DNP3. Is it a true Traansport Layer, is it a paart of the Data Link L Layer, or is it something g truly differennt? The an nswer is that itt really is someething differen nt, although it m most closely reesembles an addditional field in the Daata Link Layerr. It does not have h its own ad ddressing or accknowledgmennts, as a separaate layer woulld. There was no networrk layer in the original protoccol definition, so the transporrt header was tterminated at thhe k header. It doees not have thhe long sequennce numbers annd end off each physicaal link, just likee the data link other features f that would w really enfforce transmitting frames in ssequence. Therrefore, it does nnot seem to bee a Transp port Layer. Howev ver, if it were a field of the data d link headeer, it would bee included in eevery data linkk frame, and it is not. Only O those fram mes containing Application A Laayer data contaain a transport hheader. The reeasons this straange “half-layeer” exists are bo oth political annd technical. Thhe designers of DNP3 decideed they wanted w the App plication Layer data broken into small seggments suitablee for passing oover noisy linkks. This capability c woulld at a minimu um require a new n Data Link Layer field. H However, they did not want to add a new n field for tw wo reasons: a))

It would elliminate DNP3 3’s chances to o be consideredd compliant too IEC 60870-5. As discusseed earlier, this was considereed critical to DN NP3’s acceptannce by the induustry.

b)) Changing th he structure off the FT3 fram me could possibbly compromise the calculatted reliability oof the frame. Thereffore, the transp port header was placed in fron nt of the Appliication Layer hheader, in the uuser data field oof the Daata Link Layer frame. Howev ver, the next question was,, “What to caall it?” As nooted in this suubclause, it haad some of thhe characcteristics of a layer but not alll of them. Furrthermore, the designers knew w there would be resistance to any ad dditional layerrs in the protocol. It was baad enough thatt they were deedicating a whhole octet to thhe segmeentation and reaassembly functtions. xv Copyright © 2012 IEEE. All rightts reserved.


Thereffore, the name “Transport Fu unction” was ch hosen, thus cauusing years of questions on hhotlines, e-maills, and traaining presentaations. Whateever it is, it makes DNP3 diistinct. Along with w Applicatiion Layer fraggmentation, it ppermits a smalll, low-po owered device to report a neaarly unlimited amount of dataa reliably over a noisy link. 0.1.11 1 DNP Userrs Group One feature fe of DNP P3 that newcom mers do not allways appreciaate is the organ anization that sstands behind iit. Over the t years, the DNP Users Group G has conttributed at leasst as much to the protocol’ss success as thhe technical features off the protocol ittself. In roughly chronolog gical order, herre are the organ nizational featuures that helped DNP3 becom me popular: ⎯ Membership p that included d both utilities and vendors ⎯ Low membership fees ⎯ Low cost off the specificattions ⎯ A structure consisting of steering, s techniical, and markeeting committeees ⎯ The DNP3 Subset Definittions documentt ⎯ Suggested wordings w for uttilities to speciify DNP3 ⎯ Agreement that any no on-backward compatible c chhange shall be approved bby the Generral p Membership ⎯ The DNP3 hotline, later to o become an In nternet chat sesssion ⎯ Booths at major m trade shows ⎯ Publishing membership m lists so utilities could c see the llists of vendorss ⎯ The DNP3 bulletin board,, later to becom me a Web site ⎯ The DNP3 e-mail mailing g list ⎯ The DNP Technical T Comm mittee mailing list, which cann include non-ccommittee mem mbers ⎯ Publishing the t technical committee minu utes so the proccess remains oopen ⎯ Technical bulletins b clarify ying areas of diispute when innteroperability iissues arose ⎯ Agreement,, first informal and then form mal, that the preesident should always be from m a utility ⎯ The DNP3 IED Applicatio on Level Confo formance Test D Documentsc ⎯ The DNP3 WAN/LAN Sp pecification 0.1.12 2 Summary The fo ollowing design n goals, wheth her formally staated or not at th the time, had a major impact on the structuure of DN NP3: ⎯ Include the best features of o the utility prrotocols in use at the time. ⎯ Push the inttelligence in th he network tow ward the remotee device. ⎯ Try to comp ply as much ass possible with existing standaards efforts, esspecially IEC 660870-5.

c

Refer to t http//www.dnp..org.

xvi Copyright © 2012 IEEE. All rightts reserved.


⎯ Use as littlee bandwidth as possible. ⎯ Make it mo ore reliable than n anything thatt came before. It is easy to see thatt these goals are a necessarily contradictory.. The resultingg protocol was not perfect annd u over the yeears. However,, it remains poopular, open, reeliable, and m mostly backwarddhas beeen “patched up” compaatible. 0.1.13 3 Background: Origins of o the name “DNP3” Few people p seem to know what to call this proto ocol. Everyone knows it is DN NP3, but is it ““DNP 3,” “DN NP 3.0,” “DNP “ V3.0,” or any combiination of the above? Also, there are seveeral different subset levels oof implem mentation, and d a few non-bacckward-compaatible changes hhave been madde over the yeaars. As of Technical Bullletin TB2000-003: “Change Management,”” the official nname of the prootocol is DNP33xxxx, where xxxx is the year of rellease of the Test Procedures tto which a devvice complies. The subset levvel d, as in “DNP3 3-2000 Level 2.” 2 is speccified afterward This naming n convention representss an evolution of o the name ovver the years: ⎯ The originaal Basic 4 doccumentation referred to the pprotocol as “D DNP V3.00.” N No one has ever liked saying g the “V” part, so that name has h never caugght on. ⎯ For those who w were wond dering: DNP V1.00 V and DNP P V2.00 are prroprietary Wesstronic protocools that were raarely used even n at the time DN NP3 was releaased. ⎯ The user’s group is called d just the “DNP P Users Groupp.” That saves it from havingg to worry about mbers in markeeting informatio on. version num ⎯ The Subsett Definitions defined d the forrmat DNP3-Lxx, where x wass the subset leevel. That never caught on either, e since utilities preferred d to spell out thhe words “Leveel x” in their biid specs. ⎯ When the Test T Procedurres were first published in 22000, there haad to be somee mechanism to distinguish between an implementatio on that was compliant to the proceduures and earlier NP Technical C Committee therefore decidedd to use the year implementaations that werre not. The DN in the speecification, siimilar to the format usedd by the Intternational O Organization fo for Standardizaation (ISO), IEE EE, and IEC. ⎯ The intent is that there shall s never bee a DNP 4.0, or even a DN NP 3.1. To hellp illustrate thhis nt to backward d compatibility y, the DNP U Users Group chhanged the naame from “DN NP commitmen V3.00” to “DNP3.” The name therefo ore remains reccognizable whhile eliminatinng the “softwaare mpression that the t decimal poiint gave. version” im Some people rightly complain that it is redundantt to say “DNP33 protocol” sinnce the “P” in D DNP3 stands fo for ocol” already. However, H this truism does no ot seem to disccourage peoplee from using thhe phrase, and it “Proto is likely to be heard for years to come. Now if i one could ju ust figure out how h a protoco ol that originallly had no netw work layer endded up with thhe name “Distributed Network N Proto ocol.” One lon ng-standing D DNP3 user poiints out that tthe networks in on are SCADA A networks, which w “bear sccant resemblannce to other thhings that peoople usually caall questio networks.” Perhaps this t is the case. Ah weell, a protocol by b any other naame is just as interoperable an and reliable.

xvii Copyright © 2012 IEEE. All rightts reserved.


0.2

DNP3 ov verview

0.2.1

Basic mes ssages and data d flow

The document d is a brief, but inco omplete, overv view of DNP33 messages andd data flow. Its purpose is to preparre the reader for f what follow ws in the App plication Layerr, Transport Fuunction, and D Data Link Layyer specifi fications for DN NP3. NOTE— —Unless otherw wise noted, DNP P3 makes no reprresentation abouut how data is proocessed once it iis received.d

This in nitial discussio on of DNP3 usses the master– –outstation mo del illustrated in Figure 0-1. This subclausse purpossely omits man ny details to keeep the descripttion straightforrward. Master M

Binary Input I 8 6 5 4

8

Binarry Outpu ut

7

6

Analog Input Counter Input 4

5 4

O Outstation

Binary Input

Binnary Outtput

7 6

Analog Output

Analogg Input Counter Input 4

6 5 4

Analog Output

4

5 4

3

3

3

3

3

3

3

3

3

3

2

2

2

2

2

2

2

2

2

2

1

1

1

1

1

1

1

1

1

1

0

0

0

0

0

0

0

0

0

0

User U Layer

User Layer

DNP3 Appllication Layer

DNP3 Appplication Layer

Transsport Function

Traansport Function

DNP3 Datta Link Layer

DNP3 D Data Link Layer

Dig gits inside boxees represent indeex numbers

Physical Meedia

4

Requests

Solicited and Unsolicited U Respoonses Confirmations

Figure e 0-1—DNP3 3 master–outtstation mod del

d

Notes in text, tables, and figures of a stan ndard are given forr information onlyy and do not contaain requirements nneeded to implemeent this stan ndard.

xviii Copyright © 2012 IEEE. All rightts reserved.


The User U Layer in the master on n the left sidee of Figure 00-1 initiates a data transferr by causing iits Appliccation Layer to o send a requesst to the outstattion. The requeest contains a fu function code aand zero or more DNP3 objects that specify what data is wanteed. The Appliication Layer passes the reqquest on to thhe port Function for f partitioning g into transmisssion-sized uniits and then onn to the Data L Link Layer. Thhe Transp Data Link L Layer add ds addressing and a error detecction informatioon and transm mits the packet tto the outstatioon over th he physical meedia. At thee outstation on n the right sidee, the Data Link Layer receeives the octetss from the phyysical layer annd checkss for errors th hat were intro oduced while the t packet waas in transit. IIf no errors arre detected, thhe addresssing and errorr detection info ormation added d by the transm mitting Data L Link Layer is sttripped from thhe messaage, and the reemaining octetts are passed on o to the Appplication Layerr. If necessaryy, the Transpoort Functiion reassemblees multiple pacckets into a co omplete requesst. The Applicaation Layer theen interprets thhe functio on code and DN NP3 objects in n the message and a indicates too the User Layyer what data iss desired. The User U Layer in the t outstation initiates a resp ponse based onn what data thhe master requuested. It fetchees data, classifies c it, and presents thatt data to the Ap pplication Layyer. The Appliccation Layer crreates a messagge with data d formatted into DNP3 ob bjects, passes itt through the T Transport Funcction, and thenn on to the Daata Link Layer L for transsmission to thee master using methods simillar to those em mployed by thee master to sennd its req quest. Upon receipt of the response at th he master, the layers l perform m address and eerror checking and reassembly pplication Lay yer. This layer pparses the DNP into a complete messsage for the Ap P3 objects in tthe response annd presen nts the informaation to the Useer Layer. The User U Layer cann then store orr operate on thhat data in a waay that is suitable for th he end user. The master m always initiates contro ol commands. These actuatee device outpuuts or variabless internal to thhe outstattion. The DNP P3 User-to-App plication Layerr interface and transmission pprocedures are similar to those discusssed for data accquisition. A tran nsaction consistts of a single request followeed by a single rresponse. A maaster sends a reequest and waiits for thee response, or a timeout, beefore issuing an nother requestt. Multiple trannsactions mayy simultaneously occur within a system. For examplle, consider the case where ttwo masters eaach make requuests to the sam me outstattion. In som me systems thee master does not always directly d initiatee data transfer.. DNP3 has provision for thhe outstattion to automaatically send daata when it dettects a conditioon worthy of ttransmitting without a speciffic masterr request. “Un nsolicited Resp ponses” is the terminology t appplied to this type of operattion because thhe requesst is implied. 0.2.2 0.2.2.1

Layering General

ISO defines d a com mmunication arrchitecture thaat separates fuunctions into seven layers called the OS SI referen nce model. DNP3 D protocol is based on a simplified model termedd the Enhanceed Performancce Archittecture (EPA) that consists of o only three layers: l Appliccation, Data Liink, and Physiical. Figure 0--1 showss how DNP3 fitts the EPA stru ucture and com mmunication mo model. In theory, each layer in a layer staack performs a set of functioons required too communicatee with the sam me i another deviice, relying on the next lowerr layer for morre primitive funnctions. At the sending devicce, layer in each laayer below thee Application Layer L receives data from the layer above foor transmissionn. The layer addds more information i th hat enables the equivalent lay yer in the receiiver to properlly process the message. At thhe receiving device, lay yers examine their t layer specific informatiion added by tthe correspondding layer at thhe transm mission site and d process the message m approp priately. The l ayer control innformation is sstripped, and thhe messaage is passed to o the next higheer layer.

xix Copyright © 2012 IEEE. All rightts reserved.


The Transport Function within the Application Layer performs a layer-like function of partitioning large messages into smaller messages that the Data Link Layer is capable of handling. The Transport Function is sometimes referred to as a “pseudo layer.” In DNP3 the Application Layer, Transport Function, and the Data Link Layer in the transmitter add information to the message for enabling the same layer or pseudo layer in the receiver to process the message. 0.2.2.2

Fragments, segments, and frames

Figure 0-2 illustrates the partitioning of large messages at the Application Layer into smaller units and the addition of header information at each layer.

Figure 0-2—Fragmented Application Layer message Figure 0-2 shows a fragmented Application Layer message, segmentation of each fragment by the Transport Function, and how segments fit into Data Link Layer frames. This diagram does not show timing and confirmation details but serves to demonstrate how the higher level parts nest inside the lower layer structures. It also shows the relative positions of the Application Layer headers, the Transport Function headers, and the Data Link Layer headers. Table 0-2 provides a summary of the terminology and some brief information associated with each layer or function.

xx Copyright © 2012 IEEE. All rights reserved.


Table 0-2—D DNP3 layer s summary Lay yer or function

Uniit name

Information

Appliccation Layer

Appliication Fragm ment

Perm mits the setting of o an upper limitt on the memoryy requirements fo for message receeption. Requests shall fit into a ssingle fragment. Responses may require more than n one fragment.

Transp port Functiion

Transsport Segm ment

Segmentation break ks a Data Link frragment into piecces that fit into a Data Link me. Each segmen nt contains a Traansport header, bbut only the firstt segment of anyy fram frag gment contains an a Application heeader. Each segm ment may have a maximum of 250 octets including g the Transport hheader.

Data Link L Layer

Data Link Frame

A Frame may have as many as 292 octets includingg its header and C CRC octets. Fram mes are designed d for superior err rror detection.

0.2.3

Message sequences s

Figure 0-3 illustratees a hypotheticcal sequence and a the time reelationship of fragments andd frames as theey move between layerrs, and betweeen the master and the outstaation in a pollled environmennt. Readers juust beginn ning to learn th his standard arre cautioned to o only view thhe diagram as a means of gaaining a generral overviiew. Figure 0-4 illustratees a hypotheticcal sequence and a the time reelationship of fragments andd frames as theey n the master an nd the outstatioon in an unsollicited respon nse environmennt. move between layerrs, and between means of gaininng Readeers just beginniing to learn thiis standard are cautioned to oonly view the ddiagram as a m a geneeral overview. Later, after studying the details, refer back to this ffigure when iit may be more meaningful.

xxi Copyright © 2012 IEEE. All rightts reserved.


xxii

Copyright © 2012 IEEE. All rights reserved.

Figure 0-3—Polled sequence with Data Link Layer confirmation


xxiii


Figure 0-4—Unsolicited response sequence


0.2.4

Data loss and efficiency

One of o the fundameental goals of DNP3 is to prevent p loss off data transferrred from an ooutstation to thhe masterr. Of special concern is the transfer t of all binary b input sttates, in time ssequence, and without missinng any traansitions. To inccrease the efficciency, DNP3 provides for report-by-excep r ption wherebyy changes are ttransmitted sooon after they t occur, an nd an occasio onal integrity poll p is issued to synchroniize the masterr and outstatioon databaases. When an n outstation traansmits changees, it shall reqquest Applicatiion Layer connfirmation. Onnly after th he master conffirms receipt off the changes can c the outstatiion assume the changes arriveed at the masteer. Outstaation devices that t are able to report all off their currentt data in a single frame are not required to supporrt report-by-ex xception. 0.2.5

Unsolicite ed responses s

Unsoliicited responsees are messages spontaneouslly sent from ann outstation wiithout a specific request from ma masterr when “someething of signiificance” occu urs. The DNP33 protocol inccludes supportt for unsoliciteed respon nses. This method m of opeerating has ad dvantages in some s applicatiions. In a sysstem with a laarge number oof outstattions and a sin ngle master, ch hanges at an outstation o can reach the masster often muchh faster becausse there is i no delay whiile waiting for a master poll. The communiccation costs to achieve fasterr polling in som me installations can be prohibitive, p an nd the quickest notification off changes can occur if most of the messagees contain only changes and confirmaations. Unsoliccited operationn may reduce ccosts where thee owners choose a “cosst-per-byte” typ pe of service. On thee other hand, equipment e that implements un nsolicited resp onses is more complex becauuse the issues oof mediaa access and co ollision avoidaance should bee dealt with. T The DNP3 speccification requuires that mastter station n software is capable of acccepting messsages from anny of its outsttations at anyy time. Another disadv vantage is th hat system performance may m become unpredictablee during periods of heavvy comm munication. Emplo oying unsolicitted reporting requires r an en ngineering judggment based oon numerous ffactors for eacch individ dual system. There T are no guarantees that unsolicited reporting is uuniversally appplicable for aall system ms. A desscription and rules r for unso olicited respon nses are providded in Clausee 4 through C Clause 6 of thhis standaard. 0.2.6

IP networking

DNP3 was originally y designed forr serial octet sttreaming, poinnt-to-point com mmunications oover voice gradde wired, multi-drrop wire and fiber fi cabling. A As IP networkinng evolved, users recognizedd a audio links, or hard-w f devices to exchange e DNP3 messages ov ver these high-sspeed, packet-bbased, digital nnetworks. DNP P3 need for now in ncludes this cap pability. The ap pproach taken was to place DNP3 as the user u of an IP sstack and to reetain all the saame Applicatioon Layer,, Transport Fu unction, and Daata Link Layerr structures, obbjects, and form mats as in the original DNP P3. Thus, DNP3 Data Link L Layer frames are passsed transparenntly across an IP network aas TCP or User Datagrram Protocol (UDP) packets.. A desccription and sp pecial rules are described in Clause C 13 and A Annex C of thiis standard.

xxiv Copyright © 2012 IEEE. All rightts reserved.


0.3

Organiza ation of DNP3 Specific cation

The co omplete DNP3 3 Specification is organized into i separate cllauses whereinn details of thee DNP3 protocol are do ocumented as fo ollowse: Clausee 0 through Claause 3 and Ann nex A:

DNP P3 Introductionn (formerly knnown as Volum me 1)

Clausee 4 through Claause 7:

App plication Layerr (formerly knoown as Volumee 2)

Clausee 8:

Tran nsport Functionn (formerly knnown as Volum me 3)

Clausee 9:

Dataa Link Layer (fformerly know wn as Volume 44)

Clausee 10:

Layeer Independentt Topics (form merly known as Volume 5)

Clausee 11, Clause 12 2, and Annex A: A

Dataa Object Librarry (formerly knnown as Volum me 6)

Clausee 13 and Anneex C:

IP Networking N (foormerly known as Volume 7)

Clausee 14:

Interroperability (foormerly knownn as Volume 8))

0.4

Conventtions used in i this stand dard

0.4.1

Notes

NOTE Es within the text are inforrmative. They y are set aparrt as a separaate paragraph beginning with “NOT TE—”. 0.4.2

Examples s

Examp ples are preced ded with a box x describing wh hat is illustrateed below. The nnumber EX 0--1 represents thhe examp ple number.

EX 0-1 1

0.4.3

This exaample shows a request for all a of the staticc binary inputss. Assume there are 18 binaary inputs.

Single ma aster, single outstation perspective

The DNP3 D protocol is suitable for systems with one or more m master stationss, one or more outstations, annd peer-to o-peer arrangements. In geneeral, this standaard was writtenn from the persspective of a siingle master annd a sing gle outstation to make the documents eaasier to underrstand withoutt the additionnal complexitiees involv ved. A sep parate subclau use (13.2.3.5) is devoted to o discussion oof multi-masteer systems annd their speciial consid derations and requirements. r Statements ap ppear elsewherre only when it is necessarry to emphasizze specifi fic characteristiics or behaviorr for systems with w multiple m master or outstattion devices.

e

The DNP3 Specification n was identified by y volumes prior to IEEE Std 1815-20010 standardizatioon.

xxv Copyright © 2012 IEEE. All rightts reserved.


Conttents 0 0.1 0.2 0.3 0.4

Introduction ...................................................................... ................................................................... viiii y ............................................ ................................................................... viiii DNP3 purpose and history view ............................................................. ................................................................. xviiii DNP3 overv Organizatio on of DNP3 Sp pecification ............................. ...................................................................xxxv Convention ns used in this standard s ................................. ...................................................................xxxv

1.1 1.2 1.3

Overview .......................................................................... ...................................................................... 2 Scope ............................................................................. ...................................................................... 2 Purpose .......................................................................... ...................................................................... 2 Octet order..................................................................... ...................................................................... 2

1

2

Normative references ....................................................... ...................................................................... 3

3 3.1 3.2 3.3

Definitions, acronyms, a and abbreviations ....................... . ...................................................................... 5 Definitions..................................................................... ...................................................................... 5 a abbreviatio ons ......................................... ...................................................................... 9 Acronyms and Special term ms ................................................................. .................................................................... 112

4.1 4.2 4.3 4.4 4.5 4.6 4.7

Application Layer—part L 1 ............................................... .................................................................... 113 Application n Layer prefacee ............................................. .................................................................... 113 Message strructure .......................................................... .................................................................... 119 Fragment ru ules............................................................... .................................................................... 338 Detailed fun nction code pro ocedures ................................ .................................................................... 440 Detailed IIN N bit descriptio ons ......................................... .................................................................... 881 Unsolicited d responses .................................................... .................................................................... 888 Support forr functions sentt to a broadcastt address ........ .................................................................... 999

5.1 5.2 5.3 5.4 5.5

Application Layer—part L 2 ............................................... ...................................................................1001 Additional details .......................................................... ...................................................................1001 Using virtual terminal objects ....................................... ...................................................................1009 f transfer .................................................. ...................................................................1112 Sequential file Data sets ........................................................................ ...................................................................1220 Device attriibutes............................................................ ...................................................................1448

6.1 6.2 6.3 6.4 6.5 6.6

Application Layer—part L 3: State tables an nd diagrams .... ...................................................................1555 Outstation fragment f state table ...................................... ...................................................................1555 Outstation fragment f state diagram ................................ ...................................................................1661 Master soliccited response reception statee table ............ ...................................................................1663 Master soliccited response reception statee diagram ....... ...................................................................1667 Master unso olicited respon nse reception sttate table ........ ...................................................................1667 Master unso olicited respon nse reception sttate diagram ... ...................................................................1770

7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 0 7.10

Secure authen ntication ....................................................... ...................................................................1771 Purpose .......................................................................... ...................................................................1771 dressed .......................................................... ...................................................................1771 Threats add General prin nciples ......................................................... ...................................................................1771 Theory of operation o ....................................................... ...................................................................1773 Formal speccification ...................................................... ...................................................................1886 Interoperab bility requiremeents ........................................ ...................................................................2441 Special app plications ....................................................... ...................................................................2551 Compliancee with IEC/TS 62351-3 ................................ ...................................................................2554 Compliancee with IEC/TS 62351-5 ................................ ...................................................................2558 Compliancee with ISO/IEC C 11770 ................................. ...................................................................2660

4

5

6

7

xxvi Copyright © 2012 IEEE. All rightts reserved.


8 8.1 8.2

Transport Fun nction ........................................................... ...................................................................2667 Overview ....................................................................... ...................................................................2667 F descriiption ..................................... ...................................................................2668 Transport Function

9.1 9.2 9.3

Data Link Laayer ............................................................... ...................................................................2774 Layering ov verview ........................................................ ...................................................................2774 DNP3 Dataa Link Layer deescription ............................... ...................................................................2774 State tables and diagrams .............................................. ...................................................................2887

9

Layer-indepeendent topics ................................................. ...................................................................2995 10 10.1 Purpose of layer-independ dent topics ............................. ...................................................................2995 on and retry gu uidelines................................. ...................................................................2995 10.2 Confirmatio 10.3 Time synch hronization .................................................... ...................................................................2998 4 Handling multiple m messag ges.......................................... ...................................................................3005 10.4 11 Data object liibrary—basics .............................................. ...................................................................3007 11.1 Overview ....................................................................... ...................................................................3007 11.2 Library doccumentation organization ............................. ...................................................................3007 11.3 Primitive daata types ....................................................... ...................................................................3007 4 Object dataa type codes .................................................. ...................................................................3221 11.4 11.5 DNP3 objecct types......................................................... ...................................................................3221 6 Object flagss ................................................................... ...................................................................3222 11.6 11.7 Status codes ................................................................... ...................................................................3229 11.8 Group num mber categories .............................................. ...................................................................3331 11.9 Point types ..................................................................... ...................................................................3331 DNP3 object library—parsiing codes................................ ...................................................................3551 12 12.1 Subset parsing codes ..................................................... ...................................................................3551 12.2 Parsing guidelines ......................................................... ...................................................................3662 IP networking 13 g ................................................................... ...................................................................3776 13.1 IP networkiing overview ................................................ ...................................................................3776 13.2 Layer requiirements........................................................ ...................................................................3777 13.3 Security ......................................................................... ...................................................................3990 4 Time synch hronization .................................................... ...................................................................3990 13.4 13.5 UML stateccharts ............................................................ ...................................................................3990 14 Interoperabiliity ................................................................. ...................................................................3993 14.1 About this clause c ........................................................... ...................................................................3993 14.2 Overview ....................................................................... ...................................................................3994 14.3 Level 1 DN NP3 implementtation (DNP3-L L1) ................. ...................................................................3996 4 Level 2 DN NP3 implementtation (DNP3-L L2) ................. ...................................................................4000 14.4 14.5 Level 3 DN NP3 implementtation (DNP3-L L3) ................. ...................................................................4004 6 Level 4 DN NP3 implementtation (DNP3-L L4) ................. ...................................................................4111 14.6 14.7 Conformance ................................................................. ...................................................................4227 14.8 XML representation ...................................................... ...................................................................4228 14.9 Instructionss for creating a Device Profilee document .... ...................................................................4336 Annex x A (normattive) DNP3 daata object librarry—object des criptions ....................................................4338 A.1 Object grou up 0: device atttributes .................................. ...................................................................4338 A.1.1 Device attributes—seccure authenticaation version... ...................................................................4338 mber of security statistics perr association...............................................4339 A.1.2 Device attributes—num s for useer-specific attriibutes ..................................4440 A.1.3 Device attributes—ideentification of support mber of masterr-defined data set prototypes ...........................................4443 A.1.4 Device attributes—num mber of outstaation-defined daata set prototyppes ......................................4444 A.1.5 Device attributes—num mber of masterr-defined data sets ............................................................4445 A.1.6 Device attributes—num mber of outstaation-defined daata sets .......................................................4446 A.1.7 Device attributes—num xxvii Copyright © 2012 IEEE. All rightts reserved.


A.1.8 Device attributes—maaximum numbeer of binary ouutput objects peer request ............................4447 uracy ............... ...................................................................4448 A.1.9 Device attributes—loccal timing accu a ........ ...................................................................4550 A.1.10 Device attributes—durration of time accuracy pport for analo og output eventts ................................................................4552 A.1.11 Device attributes—sup g output index ...................................................................4553 A.1.12 Device attributes—maaximum analog mber of analog g outputs ........ ...................................................................4554 A.1.13 Device attributes—num pport for binary y output event s .................................................................4555 A.1.14 Device attributes—sup y output index . ...................................................................4556 A.1.15 Device attributes—maaximum binary mber of binary y outputs......... ...................................................................4557 A.1.16 Device attributes—num pport for frozen n counter evennts ...............................................................4558 A.1.17 Device attributes—sup pport for frozen n counters ...... ...................................................................4559 A.1.18 Device attributes—sup pport for countter events ....... ...................................................................4660 A.1.19 Device attributes—sup A.1.20 Device attributes—maaximum counteer index .......... ...................................................................4661 mber of counteer points ......... ...................................................................4662 A.1.21 Device attributes—num pport for frozen n analog input s .................................................................4663 A.1.22 Device attributes—sup pport for analo og input events ..................................................................4664 A.1.23 Device attributes—sup g input index .. ...................................................................4665 A.1.24 Device attributes—maaximum analog mber of analog g input points . ...................................................................4666 A.1.25 Device attributes—num pport for doublle-bit binary innput events..................................................4667 A.1.26 Device attributes—sup A.1.27 Device attributes—maaximum doublee-bit binary inddex .............................................................4668 mber of doublee-bit binary inpput points ...................................................4669 A.1.28 Device attributes—num pport for binary y input events ...................................................................4770 A.1.29 Device attributes—sup y input index ... ...................................................................4771 A.1.30 Device attributes—maaximum binary mber of binary y input points . ...................................................................4772 A.1.31 Device attributes—num mit fragment sizze ...............................................................4773 A.1.32 Device attributes—maaximum transm A.1.33 Device attributes—maaximum receive fragment sizee .................................................................4774 vice manufactu urer’s softwaree version .....................................................4775 A.1.34 Device attributes—dev vice manufactu urer’s hardwaree version ....................................................4776 A.1.35 Device attributes—dev A.1.36 Device attributes—useer-assigned loccation name .... ...................................................................4777 A.1.37 Device attributes—useer-assigned ID code/number ...................................................................4778 vice name ...... ...................................................................4779 A.1.38 Device attributes—useer-assigned dev vice serial num mber ................ ...................................................................4880 A.1.39 Device attributes—dev NP3 subset and d conformance ...................................................................4881 A.1.40 Device attributes—DN vice manufactu urer’s product nname and moddel .......................................4883 A.1.41 Device attributes—dev vice manufactu urer’s name .... ...................................................................4884 A.1.42 Device attributes—dev n-specific all attributes a requeest ...............................................................4885 A.1.43 Device attributes—non A.1.44 Device attributes—listt of attribute vaariations ......... ...................................................................4886 A.2 Object grou up 1: binary inp puts ........................................ ...................................................................4888 A.2.1 Binary input—packed i d format .................................. ...................................................................4888 i flaags ......................................... ...................................................................4889 A.2.2 Binary input—with A.3 Object grou up 2: binary inp put events .............................. ...................................................................4990 A.3.1 Binary input i event—w without time ........................... ...................................................................4990 i event—w with absolute tiime ................. ...................................................................4991 A.3.2 Binary input i event—w with relative tim me .................. ...................................................................4992 A.3.3 Binary input A.4 Object grou up 3: double-biit binary inputss ..................... ...................................................................4993 A.4.1 Double--bit binary inpu ut—packed forrmat................ ...................................................................4993 ut—with flags....................... . A.4.2 Double--bit binary inpu ...................................................................4994 A.5 Object grou up 4: double-biit binary input events ............ ...................................................................4995 A.5.1 Double--bit binary inpu ut event—with hout time......... ...................................................................4995 ut event—with h absolute time ..................................................................4996 A.5.2 Double--bit binary inpu ut event—with h relative time . ...................................................................4997 A.5.3 Double--bit binary inpu A.6 Object grou up 10: binary outputs o .................................... ...................................................................4998 A.6.1 Binary output—packe o d format ................................ ...................................................................4998 o t status with flaags ................. ...................................................................5000 A.6.2 Binary output—output A.7 Object grou up 11: binary output o events .......................... ...................................................................5001 A.7.1 Binary output o event— —status without time .............. ...................................................................5001 o event— —status with tim me ................... ...................................................................5003 A.7.2 Binary output xxviii Copyright © 2012 IEEE. All rightts reserved.


A.8 Object grou up 12: binary output o comman nds .................. ...................................................................5005 A.8.1 Binary output o comman nd—control relay output blocck—also know wn as CROB ........................5005 o comman nd—pattern co ontrol block—aalso known as PCB ...................................5111 A.8.2 Binary output o comman nd—pattern maask ................. ...................................................................5113 A.8.3 Binary output A.9 Object grou up 13: binary output o comman nd events......... ...................................................................5114 A.9.1 Binary output o comman nd event—com mmand status w without time ................................................5114 o comman nd event—com mmand status w with time .....................................................5116 A.9.2 Binary output A.10 0 Object gro oup 20: counteers .......................................... ...................................................................5117 A.10.1 Counterr—32-bit with flag ....................................... ...................................................................5117 A.10.2 Counterr—16-bit with flag ....................................... ...................................................................5118 A.10.3 Counterr—32-bit with flag, delta .............................. ...................................................................5119 A.10.4 Counterr—16-bit with flag, delta .............................. ...................................................................5220 out flag .................................. ...................................................................5221 A.10.5 Counterr—32-bit witho out flag .................................. ...................................................................5222 A.10.6 Counterr—16-bit witho out flag, delta......................... ...................................................................5223 A.10.7 Counterr—32-bit witho out flag, delta......................... ...................................................................5224 A.10.8 Counterr—16-bit witho A.11 1 Object gro oup 21: frozen n counters ............................... ...................................................................5225 A.11.1 Frozen counter—32-b c it with flag ............................ ...................................................................5225 c it with flag ............................ ...................................................................5226 A.11.2 Frozen counter—16-b c it with flag, deelta.................. ...................................................................5227 A.11.3 Frozen counter—32-b c it with flag, deelta.................. ...................................................................5228 A.11.4 Frozen counter—16-b c it with flag and d time ............ ...................................................................5229 A.11.5 Frozen counter—32-b c it with flag and d time ............ ...................................................................5331 A.11.6 Frozen counter—16-b c it with flag and d time, delta ... ...................................................................5333 A.11.7 Frozen counter—32-b c it with flag and d time, delta ... ...................................................................5335 A.11.8 Frozen counter—16-b c it without flag ...................... ...................................................................5337 A.11.9 Frozen counter—32-b c it without flag ...................... ...................................................................5338 A.11.10 Frozen counter—16-b c it without flag, delta ............ ...................................................................5339 A.11.11 Frozen counter—32-b c it without flag, delta ............ ...................................................................5440 A.11.12 Frozen counter—16-b A.12 2 Object gro oup 22: counteer events ................................. ...................................................................5441 A.12.1 Counterr event—32-bitt with flag .............................. ...................................................................5441 A.12.2 Counterr event—16-bitt with flag .............................. ...................................................................5442 A.12.3 Counterr event—32-bitt with flag, delta ................... ...................................................................5443 A.12.4 Counterr event—16-bitt with flag, delta ................... ...................................................................5444 A.12.5 Counterr event—32-bitt with flag and time .............. ...................................................................5445 A.12.6 Counterr event—16-bitt with flag and time .............. ...................................................................5447 A.12.7 Counterr event—32-bitt with flag and time, delta .... ...................................................................5449 A.12.8 Counterr event—16-bitt with flag and time, delta .... ...................................................................5551 A.13 3 Object gro oup 23: frozen n counter events..................... ...................................................................5553 A.13.1 Frozen counter c event— —32-bit with fllag .................. ...................................................................5553 c event— —16-bit with fllag .................. ...................................................................5554 A.13.2 Frozen counter c event— —32-bit with fllag, delta ........ ...................................................................5555 A.13.3 Frozen counter c event— —16-bit with fllag, delta ........ ...................................................................5556 A.13.4 Frozen counter c event— —32-bit with fllag and time ... ...................................................................5557 A.13.5 Frozen counter c event— —16-bit with fllag and time ... ...................................................................5559 A.13.6 Frozen counter c event— —32-bit with fllag and time, ddelta ............................................................5661 A.13.7 Frozen counter c event— —16-bit with fllag and time, ddelta ............................................................5663 A.13.8 Frozen counter A.14 4 Object gro oup 30: analog g inputs .................................. ...................................................................5665 A.14.1 Analog input—32-bit with flag ............................... ...................................................................5665 A.14.2 Analog input—16-bit with flag ............................... ...................................................................5666 A.14.3 Analog input—32-bit without flag .......................... ...................................................................5667 A.14.4 Analog input—16-bit without flag .......................... ...................................................................5668 A.14.5 Analog input—single--precision, floaating-point withh flag ..........................................................5669 A.14.6 Analog input—doublee-precision, floating-point witth flag ........................................................5770 A.15 5 Object gro oup 31: frozen n analog inputs ...................... ...................................................................5771 A.15.1 Frozen analog a input— —32-bit with flaag ................... ...................................................................5771 a input— —16-bit with flaag ................... ...................................................................5772 A.15.2 Frozen analog xxix Copyright © 2012 IEEE. All rightts reserved.


A.15.3 Frozen analog a input— —32-bit with tim me-of-freeze ... ...................................................................5773 a input— —16-bit with tim me-of-freeze ... ...................................................................5775 A.15.4 Frozen analog a input— —32-bit withoutt flag .............. ...................................................................5777 A.15.5 Frozen analog a input— —16-bit withoutt flag .............. ...................................................................5778 A.15.6 Frozen analog a input— —single-precisio on, floating-pooint with flag ...............................................5779 A.15.7 Frozen analog a input— —double-precisiion, floating-pooint with flag .............................................5880 A.15.8 Frozen analog A.16 6 Object gro oup 32: analog g input events ......................... ...................................................................5881 A.16.1 Analog input event—3 32-bit without time ............... ...................................................................5881 16-bit without time ............... ...................................................................5882 A.16.2 Analog input event—1 32-bit with tim me .................... ...................................................................5883 A.16.3 Analog input event—3 16-bit with tim me .................... ...................................................................5885 A.16.4 Analog input event—1 n, floating-poin int without time .........................................5887 A.16.5 Analog input event—ssingle-precision double-precisio on, floating-pooint without tim me ........................................5888 A.16.6 Analog input event—d n, floating-poin int with time ...............................................5889 A.16.7 Analog input event—ssingle-precision double-precisio on, floating-pooint with time ..............................................5991 A.16.8 Analog input event—d A.17 7 Object gro oup 33: frozen n analog input events e ............. ...................................................................5993 A.17.1 Frozen analog a input ev vent—32-bit without w time .... ...................................................................5993 a input ev vent—16-bit without w time .... ...................................................................5994 A.17.2 Frozen analog a input ev vent—32-bit with w time ......... ...................................................................5995 A.17.3 Frozen analog a input ev vent—16-bit with w time ......... ...................................................................5997 A.17.4 Frozen analog a input ev vent—single-p precision, floatiing-point withoout time ..............................5999 A.17.5 Frozen analog a input ev vent—double-p precision, floatting-point withhout time .............................6000 A.17.6 Frozen analog a input ev vent—single-p precision, floatiing-point with time ...................................6002 A.17.7 Frozen analog a input ev vent—double-p precision, floatting-point withh time ..................................6004 A.17.8 Frozen analog A.18 8 Object gro oup 34: analog g input reportin ng deadbands .. ...................................................................6006 A.18.1 Analog input reporting g deadband—1 16-bit .............. ...................................................................6006 g deadband—3 32-bit .............. ...................................................................6007 A.18.2 Analog input reporting g deadband—ssingle-precisionn, floating-poinnt ........................................6008 A.18.3 Analog input reporting A.19 9 Object gro oup 40: analog g output status ....................... . ...................................................................6110 A.19.1 Analog output status— —32-bit with flag .................. ...................................................................6110 —16-bit with flag .................. ...................................................................6111 A.19.2 Analog output status— —single-precisiion, floating-pooint with flag..............................................6112 A.19.3 Analog output status— —double-precission, floating-ppoint with flag ...........................................6113 A.19.4 Analog output status— A.20 0 Object gro oup 41: analog g outputs................................. ...................................................................6115 A.20.1 Analog output—32-bit............................................. ...................................................................6115 A.20.2 Analog output—16-bit............................................. ...................................................................6116 oating-point .... ...................................................................6117 A.20.3 Analog output—singlee-precision, flo A.20.4 Analog output—doublle-precision, floating-point... ...................................................................6118 A.21 1 Object gro oup 42: analog g output events ...................... ...................................................................6220 A.21.1 Analog output event— —32-bit withou ut time ............. ...................................................................6220 —16-bit withou ut time ............. ...................................................................6222 A.21.2 Analog output event— —32-bit with tim me .................. ...................................................................6223 A.21.3 Analog output event— —16-bit with tim me .................. ...................................................................6225 A.21.4 Analog output event— —single-precision, floating-pooint without tim me .......................................6227 A.21.5 Analog output event— —double-precission, floating-ppoint without tiime ......................................6228 A.21.6 Analog output event— —single-precision, floating-pooint with time .............................................6330 A.21.7 Analog output event— —double-precission, floating-ppoint with time ...........................................6332 A.21.8 Analog output event— A.22 2 Object gro oup 43: analog g output commaand events ..... ...................................................................6334 A.22.1 Analog output commaand event—32--bit without tim me ...............................................................6334 me ...............................................................6336 A.22.2 Analog output commaand event—16--bit without tim A.22.3 Analog output commaand event—32--bit with time . ...................................................................6337 A.22.4 Analog output commaand event—16--bit with time . ...................................................................6339 gle-precision, ffloating-point without time ......................6441 A.22.5 Analog output commaand event—sing uble-precision,, floating-pointt without time .....................6442 A.22.6 Analog output commaand event—dou gle-precision, ffloating-point with time............................6444 A.22.7 Analog output commaand event—sing uble-precision,, floating-pointt with time ..........................6446 A.22.8 Analog output commaand event—dou A.23 3 Object gro oup 50: time an nd date .................................. ...................................................................6448 xxx Copyright © 2012 IEEE. All rightts reserved.


A.23.1 Time an nd date—absolu ute time ................................. ...................................................................6448 nd date—absolu ute time and in nterval ............ ...................................................................6449 A.23.2 Time an nd date—absolu ute time at lastt recorded timee..................................................................6550 A.23.3 Time an nd date—index xed absolute tim me and long intterval .........................................................6551 A.23.4 Time an A.24 4 Object gro oup 51: time an nd date commo on time-of-occcurrences.....................................................6554 A.24.1 Time an nd date commo on time-of-occu urrence—absollute time, syncchronized ............................6554 nd date commo on time-of-occu urrence—absollute time, unsyynchronized ........................6556 A.24.2 Time an A.25 5 Object gro oup 52: time delays...................................... ...................................................................6558 A.25.1 Time deelay—coarse ................................................. ...................................................................6558 A.25.2 Time deelay—fine ..................................................... ...................................................................6559 A.26 6 Object gro oup 60: class objects o .................................... ...................................................................6660 A.26.1 Class ob bjects—Class 0 data ..................................... ...................................................................6660 bjects—Class 1 data ..................................... ...................................................................6661 A.26.2 Class ob bjects—Class 2 data ..................................... ...................................................................6662 A.26.3 Class ob bjects—Class 3 data ..................................... ...................................................................6663 A.26.4 Class ob A.27 7 Object gro oup 70: file-co ontrol ...................................... ...................................................................6664 A.27.1 File-con ntrol—file iden ntifier—superseded ............... ...................................................................6664 ntrol—authentiication .................................... ...................................................................6668 A.27.2 File-con ntrol—file com mmand .................................... ...................................................................6770 A.27.3 File-con ntrol—file com mmand status .......................... ...................................................................6774 A.27.4 File-con ntrol—file tran nsport ...................................... ...................................................................6777 A.27.5 File-con ntrol—file tran nsport status ............................ ...................................................................6779 A.27.6 File-con ntrol—file desccriptor .................................... ...................................................................6881 A.27.7 File-con ntrol—file speccification string g..................... ...................................................................6884 A.27.8 File-con A.28 8 Object gro oup 80: internaal indications ......................... ...................................................................6886 A.28.1 Internal indications—p packed format ...................... ...................................................................6886 A.29 9 Object gro oup 81: devicee storage ................................. ...................................................................6888 A.29.1 Device storage—buffeer fill status ............................ ...................................................................6888 A.30 0 Object gro oup 82: Devicee Profiles ............................... ...................................................................6889 A.30.1 Device Profile—funct P tions and index xes .................. ...................................................................6889 A.31 1 Object gro oup 83: data seets .......................................... ...................................................................6992 A.31.1 Data sett—private registration object ...................... ...................................................................6992 A.31.2 Data sett—private registration object descriptor ..... ...................................................................6994 A.32 2 Object gro oup 85: data seet prototypes .......................... ...................................................................6996 A.32.1 Data sett prototype—w with UUID .............................. ...................................................................6996 A.33 3 Object gro oup 86: data seet descriptors ......................... ...................................................................6998 A.33.1 Data sett descriptor—d data set contentts .................... ...................................................................6998 . A.33.2 Data sett descriptor—ccharacteristics ....................... ...................................................................7000 point index attrributes ............ ...................................................................7001 A.33.3 Data sett descriptor—p A.34 4 Object gro oup 87: data seets .......................................... ...................................................................7003 A.34.1 Data sett—present valu ue ........................................... ...................................................................7003 A.35 5 Object gro oup 88: data seet events................................. ...................................................................7005 A.35.1 Data sett event—snapsshot ........................................ ...................................................................7005 A.36 6 Object gro oup 90: applicaations..................................... ...................................................................7007 A.36.1 Applicaation—identifieer............................................ ...................................................................7007 A.37 7 Object gro oup 91: status of requested op perations ........ ...................................................................7008 A.37.1 Status of o requested operation—active configurationn .................................................................7008 A.38 8 Object gro oup 100: floatiing-point ................................ ...................................................................7110 A.38.1 Floating g-point—none— —general desccription commoon to all variatiions.....................................7110 A.39 9 Object gro oup 101: binarry-coded decim mal integers ..... ...................................................................7111 A.39.1 Binary-ccoded decimal integer—smalll .................... ...................................................................7111 dium ................ ...................................................................7112 A.39.2 Binary-ccoded decimal integer—med A.39.3 Binary-ccoded decimal integer—largee ..................... ...................................................................7113 A.40 0 Object gro oup 102: unsig gned integers .......................... ...................................................................7114 A.40.1 Unsigneed integer—8-b bit .......................................... ...................................................................7114 A.41 1 Object gro oup 110: octet strings .................................. ...................................................................7115 A.41.1 Octet strring—none—g general descrip ption common tto all variationns .........................................7115 xxxi Copyright © 2012 IEEE. All rightts reserved.


A.42 2 Object gro oup 111: octet string events ......................... ...................................................................7116 A.42.1 Octet strring event—no one—general description d com mmon to all varriations ...............................7116 A.43 3 Object gro oup 112: virtuaal terminal outp put blocks ...... ...................................................................7117 A.43.1 Virtual terminal t outpu ut block—nonee—general desccription comm mon to all variattions ............7117 A.44 4 Object gro oup 113: virtuaal terminal eveent data ........... ...................................................................7118 A.44.1 Virtual terminal t event data—none— —general descripption commonn to all variationns................7118 A.45 5 Object gro oup 120: autheentication ............................... ...................................................................7119 A.45.1 Authenttication—challlenge ...................................... ...................................................................7119 y ............................................. ...................................................................7222 A.45.2 Authenttication—reply r ............ ...................................................................7224 A.45.3 Authenttication—Aggrressive Mode request r ............ ...................................................................7226 A.45.4 Authenttication—session key status request A.45.5 Authenttication—session key status ......................... ...................................................................7227 A.45.6 Authenttication—session key changee ...................... ...................................................................7330 A.45.7 Authenttication—errorr.............................................. ...................................................................7333 A.45.8 Authenttication—user certificate .............................. ...................................................................7336 AC) .............................................................7441 A.45.9 Authenttication—messsage authenticaation code (MA . ...................................................................7443 A.45.10 Authenttication—user status change ....................... A.45.11 Authenttication—updaate key change request .......... ...................................................................7448 A.45.12 Authenttication—updaate key change reply.............. ...................................................................7550 . ...................................................................7552 A.45.13 Authenttication—updaate key change ....................... A.45.14 Authenttication—updaate key change signature ....... ...................................................................7554 A.45.15 Authenttication—updaate key change confirmation . ...................................................................7556 A.46 6 Object gro oup 121: securrity statistics........................... ...................................................................7558 A.46.1 Security y statistic—32--bit with flag .......................... ...................................................................7558 A.47 7 Object gro oup 122: securrity statistic eveents ................ ...................................................................7660 A.47.1 Security y statistic eventt—32-bit with flag ............... ...................................................................7660 y statistic eventt—32-bit with flag and time ...................................................................7662 A.47.2 Security Annex xB

(informaative) DNP3 quick q referencee ..................... ...................................................................7664

Annex x C (informaative) Associaations ..................................... ...................................................................7669 C.1 Introduction n ................................................................... ...................................................................7669 C.2 Association n definition ................................................... ...................................................................7669 C.3 Association n issues ......................................................... ...................................................................7669 C.4 UDP associiations .......................................................... ...................................................................7770 C.5 TCP associations ........................................................... ...................................................................7770 Annex xD

(normattive) UTF-8 reelated copyrigh ht .................... ...................................................................7772

Annex xE

(informaative) Sample CRC calculatiions ................ ...................................................................7773

Annex xF (informaative) Managiing Secure Autthentication uppdates ..........................................................7776 F.1 Introduction n ................................................................... ...................................................................7776 F.2 Secure Auth hentication verrsion updates ......................... ...................................................................7777 F.3 Recommendations ......................................................... ...................................................................7777 F.3 3.1 For outsstations ......................................................... ...................................................................7777 F.3 3.2 For masster stations................................................... ...................................................................7777 F.3 3.3 For DNP P3 system userrs ........................................... ...................................................................7778 F.3 3.4 Commeercial consideraations ..................................... ...................................................................7778 Annex xG

(informaative) Bibliography ..................................... ...................................................................7779

xxxii Copyright © 2012 IEEE. All rightts reserved.


Figures Figure 0-1—DNP3 master–outstation model ............................................................................................ xviii Figure 0-2—Fragmented Application Layer message .................................................................................. xx Figure 0-3—Polled sequence with Data Link Layer confirmation ............................................................. xxii Figure 0-4—Unsolicited response sequence ............................................................................................. xxiii Figure 4-1—Layering diagram ..................................................................................................................... 13 Figure 4-2—Point type arrays ...................................................................................................................... 14 Figure 4-3—Event buffering concepts ......................................................................................................... 19 Figure 4-4—Fragment structure ................................................................................................................... 20 Figure 4-5—Application request header ...................................................................................................... 21 Figure 4-6—Application response header .................................................................................................... 21 Figure 4-7—Application control octet fields ................................................................................................ 21 Figure 4-8—Internal indications octets ........................................................................................................ 28 Figure 4-9—Object header fields ................................................................................................................. 30 Figure 4-10—Qualifier octet fields .............................................................................................................. 32 Figure 4-11—Objects prefixed ..................................................................................................................... 32 Figure 4-12—Index list ................................................................................................................................ 33 Figure 4-13—Example exchange to activate configuration ......................................................................... 80 Figure 4-14—Event buffer overflow example.............................................................................................. 87 Figure 4-15—Unsolicited timing diagram.................................................................................................... 89 Figure 4-16—Ideal mixed unsolicited and solicited communications.......................................................... 94 Figure 4-17—Unsolicited response or confirmation not received ................................................................ 96 Figure 4-18—Regenerated unsolicited response .......................................................................................... 97 Figure 4-19—Read request received while awaiting unsolicited confirm .................................................... 98 Figure 4-20—Non-read request received ..................................................................................................... 99 Figure 5-1—Virtual channels illustrated .....................................................................................................110 Figure 5-2—Relationships...........................................................................................................................123 Figure 5-3—Sample data set with CTLS and CTLV elements ...................................................................139 Figure 5-4—Example control message exchange .......................................................................................141 Figure 6-1—Outstation fragment state diagram ..........................................................................................162 Figure 6-2—Master solicited response reception state diagram ..................................................................167 Figure 6-3—Master unsolicited response reception state diagram ..............................................................170 Figure 7-1—Assumed implementation architecture ....................................................................................174 Figure 7-2—Overview of interaction among authority, master, and outstation ..........................................179 Figure 7-3—Example of successful challenge of Critical ASDU ...............................................................180 Figure 7-4—Example of failed challenge of Critical ASDU.......................................................................180 Figure 7-5—Example of a successful Aggressive Mode Request ...............................................................181 Figure 7-6—Example of a failed Aggressive Mode Request ......................................................................181 Figure 7-8—Example of communications failure followed by Session Key Change .................................183 Figure 7-9—Example of successful User Status Change and Update Key Change ....................................184 Figure 7-10—Major state transitions for master..........................................................................................185 Figure 7-11—Major state transitions for outstation ....................................................................................186 Figure 7-12—Example of DNP3 Select/Operate authentication .................................................................193 Figure 7-13—Example of DNP3 Select/Operate authentication in Aggressive Mode ................................194 Figure 7-14—Example of failed DNP3 Select/Operate authentication .......................................................194 Figure 7-15—Example DNP3 initialization sequence.................................................................................195 Figure 7-16—Example DNP3 authentication of outstation polling data .....................................................196 Figure 7-17—Example of failed authentication of outstation data ..............................................................196 Figure 7-18—Successful User Status Change and Update Key Change .....................................................197 Figure 7-19—User changes masters ............................................................................................................198 Figure 7-20—Master state machine showing DNP3 function codes and object variations .........................199 Figure 7-21—Outstation state machine showing DNP3 function codes and object variations ...................200 Figure 7-22—Master state machine for Update Key Change ......................................................................201 Figure 7-23—Outstation state machine for Update Key Change ................................................................202 Figure 7-24—Behavior model for multiple users ........................................................................................204 Figure 7-25—Possible collision of confirmation challenge and next master request ..................................209 xxxiii Copyright © 2012 IEEE. All rights reserved.


Figure 7-26—Preventing Confirmation challenge collisions using Aggressive Mode................................209 Figure 7-27—Example use of Challenge Sequence Numbers (part 1) ........................................................212 Figure 7-28—Example use of Challenge Sequence Numbers (part 2) ........................................................213 Figure 7-29—Example of User Number and Association ID assignments .................................................226 Figure 7-30—Valid profiles using the Secure Authentication mechanism .................................................251 Figure 7-31—Example of user number assignments in a data concentrator ...............................................253 Figure 8-1—Transport Function location is between Application Layer and Data Link Layer .................267 Figure 8-2—Transport segment...................................................................................................................267 Figure 8-3—Header fields ...........................................................................................................................268 Figure 8-4—Reception state diagram ..........................................................................................................273 Figure 9-1—DNP3 protocol stack ...............................................................................................................274 Figure 9-2—Transaction diagram ...............................................................................................................276 Figure 9-3—DNP3 frame format ................................................................................................................276 Figure 9-4—Control octet bit definitions ....................................................................................................277 Figure 9-5—Destination address format .....................................................................................................280 Figure 9-6—Source address format .............................................................................................................280 Figure 9-7—CRC ordering ..........................................................................................................................281 Figure 10-1—Timing of non-LAN time synchronization ...........................................................................300 Figure 10-2—Timing of LAN time synchronization ...................................................................................302 Figure 11-1—Identification of non-originating devices (data concentrators) .............................................323 Figure 11-2—Analog input model ..............................................................................................................332 Figure 11-3—Analog output point type model............................................................................................335 Figure 11-4—Activation model...................................................................................................................337 Figure 11-5—Complementary latch model .................................................................................................338 Figure 11-6—Complementary, two-output model ......................................................................................339 Figure 11-7—Counter point type model......................................................................................................341 Figure 11-8—Double-bit binary input model ..............................................................................................345 Figure 11-9—Octet string model .................................................................................................................346 Figure 11-10—Single-bit binary input point type model ............................................................................347 Figure 11-11—Virtual terminal conceptual model ......................................................................................348 Figure 11-12—Security statistics model .....................................................................................................350 Figure 13-1—Protocol stack........................................................................................................................377 Figure 13-2—Single master connection ......................................................................................................385 Figure 13-3—Connection based on master IP address ................................................................................386 Figure 13-4—Connection based on port number ........................................................................................387 Figure 13-5—All connections accepted for browsing static data ................................................................388 Figure 13-6—Multiple outstation connections ............................................................................................389 Figure 13-7—Master station statechart for dual end point ..........................................................................391 Figure 13-8—Outstation statechart for dual end point ................................................................................392 Figure 14-1—Top level of DNP3 Device Profile Schema ..........................................................................432 Figure 14-2—Example of the Schema’s first element.................................................................................432 Figure 14-3—Example of Schema’s referenceDevice ................................................................................433

xxxiv Copyright © 2012 IEEE. All rights reserved.


Tables Table 0-1—Comparison of IEC 60870-5 and DNP3 Data Link Layers ...................................................... xiv Table 0-2—DNP3 layer summary ............................................................................................................... xxi Table 4-1—Reporting classes table .............................................................................................................. 18 Table 4-2—Function code table ................................................................................................................... 24 Table 4-3—IIN bits ...................................................................................................................................... 29 Table 4-4—Object prefix codes ................................................................................................................... 32 Table 4-5—Range specifier codes ................................................................................................................ 33 Table 4-6—Valid qualifier codes ................................................................................................................. 34 Table 4-7—Preferred qualifier codes ........................................................................................................... 35 Table 4-8—Qualifier codes used by subset requirements ............................................................................ 35 Table 4-9—Action to perform with next request after a select request ........................................................ 50 Table 4-10—Example status codes and IIN bits in control response ........................................................... 54 Table 4-11—Freezing schedule interpretation ............................................................................................. 57 Table 4-12—Object headers used for re-assigning event classes ................................................................. 63 Table 4-13—Broadcast addresses ................................................................................................................ 82 Table 4-14—Conditions for setting IIN2.1 .................................................................................................. 85 Table 4-15—Conditions for setting IIN2.4 .................................................................................................. 88 Table 4-16—Mandatory function codes and objects for broadcast messages .............................................100 Table 5-1—Static data included in Class 0 data response ...........................................................................105 Table 5-2—Event data included in events class responses ..........................................................................106 Table 5-3—Example of event buffering and reporting order ......................................................................107 Table 5-4—Electrical fault data set .............................................................................................................121 Table 5-5—Pump-valve data set example ...................................................................................................121 Table 5-6—Data type codes specific to data sets ........................................................................................128 Table 5-7—Descriptor codes .......................................................................................................................131 Table 5-8—Data set related group numbers and report classes ...................................................................136 Table 5-9—Group numbers used for point types ........................................................................................137 Table 5-10—Element types in control requests and responses....................................................................138 Table 5-11—CTLS element structure and contents ....................................................................................139 Table 5-12—Data set descriptor for electrical fault ....................................................................................142 Table 5-13—Data set descriptor for electrical fault with prototype ............................................................143 Table 5-14—Data set prototype for electrical fault .....................................................................................144 Table 5-15—Electrical fault data set ...........................................................................................................146 Table 5-16—Attribute data type codes ........................................................................................................150 Table 6-1—Outstation fragment state table .................................................................................................157 Table 6-2—Master reception state table, solicited responses ......................................................................165 Table 6-3—Master reception state table, unsolicited responses ..................................................................169 Table 7-1—Summary of symmetric keys used............................................................................................176 Table 7-2—Summary of asymmetric keys used (optional) .........................................................................177 Table 7-3—DNP3 master messages with correlation to IEC/TS 62351-5a .................................................187 Table 7-4—DNP3 outstation messages with correlation to IEC/TS 62351-5a ............................................190 Table 7-5—States used in the state machine descriptions ...........................................................................203 Table 7-6—Indexes of security statistics objects ........................................................................................206 Table 7-7—DNP3 Critical Request function codes .....................................................................................210 Table 7-8—Challenger state machine .........................................................................................................215 Table 7-9—Use of Error message objects in DNP3 ....................................................................................223 Table 7-10—Example of User Number and Association ID assignments ...................................................227 Table 7-11—When to use the reserved User Numbers ...............................................................................227 Table 7-12—User roles ...............................................................................................................................228 Table 7-13—Master state machine—Changing Session Keys ....................................................................231 Table 7-14—Master state machine—Changing Update Keys .....................................................................235 Table 7-15—Special statistic event thresholds ............................................................................................243 Table 7-16—Algorithms and objects used for each Update Key Change Method ......................................245 Table 7-17—Size of Challenge Data ...........................................................................................................246 Table 7-18—Configuration of cryptographic information ..........................................................................247 xxxv Copyright © 2012 IEEE. All rights reserved.


Table 7-19—Legend for configuration of cryptographic information.........................................................248 Table 7-20—Construction of AES-GMAC Initialization Vector ................................................................249 Table 7-21—Source of Initialization Vector components in each DNP3 object .........................................249 Table 7-22—Recommended cipher suite combinations ..............................................................................255 Table 7-23—Cryptographic notation...........................................................................................................262 Table 7-24—Compliance with ISO/IEC 11770...........................................................................................264 Table 8-1—Transport Function reception state table ..................................................................................272 Table 9-1—Primary-to-secondary (PRM = 1) function codes ....................................................................279 Table 9-2—Secondary-to-primary (PRM = 0) function codes ....................................................................279 Table 9-3—Special use addresses ...............................................................................................................282 Table 9-4—Primary Station variables .........................................................................................................285 Table 9-5—Secondary Station variables .....................................................................................................285 Table 9-6—Primary Station state table........................................................................................................288 Table 9-7—Secondary Station state table....................................................................................................292 Table 11-1—Primitive data types ................................................................................................................307 Table 11-2—BCD character coding ............................................................................................................311 Table 11-3—Preferred printable characters.................................................................................................313 Table 11-4—Object data type codes............................................................................................................321 Table 11-5—Flag descriptions ....................................................................................................................323 Table 11-6—Setting of OVER_RANGE flag examples .............................................................................327 Table 11-7—Control-related status codes ...................................................................................................329 Table 11-8—File-related status codes .........................................................................................................330 Table 11-9—Analog input point type object groups ...................................................................................334 Table 11-10—Analog output point type object groups ...............................................................................336 Table 11-11—BCD point type object groups ..............................................................................................336 Table 11-12—Binary output point type object groups ................................................................................340 Table 11-13—Counter point type object groups .........................................................................................342 Table 11-14—Double-bit binary input states ..............................................................................................345 Table 11-15—Double-bit binary input point type object groups.................................................................346 Table 11-16—Octet string point type object groups ...................................................................................347 Table 11-17—Single-bit binary input point type object groups ..................................................................348 Table 11-18—Virtual terminal point type object groups.............................................................................349 Table 11-19—Security statistics versus standard DNP3 counters ...............................................................349 Table 11-20—Security statistics point type object groups ..........................................................................350 Table 12-1—g0 device attribute objects ......................................................................................................352 Table 12-2—g1 binary input static objects ..................................................................................................352 Table 12-3—g2 binary input event objects .................................................................................................353 Table 12-4—g3 double-bit binary input static objects ................................................................................353 Table 12-5—g4 double-bit binary input event objects ................................................................................353 Table 12-6—g10 binary output static objects ..............................................................................................354 Table 12-7—g11 binary output event objects .............................................................................................354 Table 12-8—g12 binary output command objects ......................................................................................354 Table 12-9—g13 binary output command event objects .............................................................................354 Table 12-10—g20 counter static objects .....................................................................................................355 Table 12-11—g21 frozen counter static objects ..........................................................................................355 Table 12-12—g22 counter event objects .....................................................................................................356 Table 12-13—g23 frozen counter event objects ..........................................................................................356 Table 12-14—g30 analog input static objects .............................................................................................356 Table 12-15—g31 frozen analog input static objects ..................................................................................357 Table 12-16—g32 analog input event objects .............................................................................................357 Table 12-17—g33 frozen analog input event objects ..................................................................................357 Table 12-18—g34 analog input deadband objects ......................................................................................358 Table 12-19—g40 analog output status objects...........................................................................................358 Table 12-20—g41 analog output command objects ....................................................................................358 Table 12-21—g42 analog output event objects ...........................................................................................359 Table 12-22—g43 analog output command event objects ..........................................................................359 Table 12-23—g50–g52 time information objects ........................................................................................360 xxxvi Copyright © 2012 IEEE. All rights reserved.


Table 12-24—g60 class information objects ...............................................................................................360 Table 12-25—g70 file objects .....................................................................................................................360 Table 12-26—g80–g83 information objects ................................................................................................361 Table 12-27—g85–g88 data set objects ......................................................................................................361 Table 12-28—g90-g91 application & status of operation information objects ...........................................361 Table 12-29—g101–g102 numeric static objects ........................................................................................361 Table 12-30—g110–g113 string & virtual terminal static & event objects .................................................362 Table 12-31—g120–g122 security objects ..................................................................................................362 Table 12-32—Function codes not used with objects ...................................................................................362 Table 12-33—g0 device attribute objects ....................................................................................................364 Table 12-34—g1 binary input static objects ................................................................................................364 Table 12-35—g2 binary input event objects ...............................................................................................364 Table 12-36—g3 double-bit binary input static objects ..............................................................................364 Table 12-37—g4 double-bit binary input event objects ..............................................................................365 Table 12-38—g10 binary output static objects ............................................................................................365 Table 12-39—g11 binary output event objects............................................................................................365 Table 12-40—g12 binary output command objects ....................................................................................365 Table 12-41—g13 binary output command event objects ...........................................................................366 Table 12-42—g20 counter static objects .....................................................................................................366 Table 12-43—g21 frozen counter static objects ..........................................................................................366 Table 12-44—g22 counter event objects .....................................................................................................367 Table 12-45—g23 frozen counter event objects ..........................................................................................367 Table 12-46—g30 analog input static objects .............................................................................................367 Table 12-47—g31 frozen analog input static objects ..................................................................................368 Table 12-48—g32 analog input event objects .............................................................................................368 Table 12-49—g33 frozen analog input event objects ..................................................................................369 Table 12-50—g34 analog input deadband objects ......................................................................................369 Table 12-51—g40 analog output status objects...........................................................................................369 Table 12-52—g41 analog output command objects ....................................................................................370 Table 12-53—g42 analog output event objects ...........................................................................................370 Table 12-54—g43 analog output command event objects ..........................................................................371 Table 12-55—g50–g52 time information objects ........................................................................................371 Table 12-56—g60 class information ...........................................................................................................372 Table 12-57—g70 file objects .....................................................................................................................372 Table 12-58—g80–g83 information objects ................................................................................................372 Table 12-59—g85–g88 data set objects ......................................................................................................373 Table 12-60—g90 application & status of operation information objects...................................................373 Table 12-61—g101, g102 numeric static objects ........................................................................................373 Table 12-62—g110–g113 string and virtual terminal static and event objects ...........................................374 Table 12-63—g120–g122 security objects ..................................................................................................374 Table 12-64—Function codes not used with objects ...................................................................................375 Table 13-1—UDP port requirements ..........................................................................................................381 Table 13-2—Handling broken TCP connections.........................................................................................383 Table 13-3—Handling closed TCP connections .........................................................................................384 Table 14-1—Qualifiers used in the subset definitions.................................................................................396 Table 14-2—Level 1 implementation (DNP3-L1) ......................................................................................398 Table 14-3—Level 2 implementation (DNP3-L2) ......................................................................................401 Table 14-4—Level 3 implementation (DNP3-L3) ......................................................................................406 Table 14-5—Level 4 implementation (DNP3-L4) ......................................................................................413 Table A-1—Interoperable control commands .............................................................................................508 Table A-2—Actions performed by outstation for interoperable commands ...............................................508 Table A-3—Data included in the MAC Value calculation ..........................................................................723 Table A-4—Data included in the MAC Value calculation ..........................................................................729 Table A-5—Data included in the key wrap (in order) .................................................................................731 Table A-6—Example of key order ..............................................................................................................731 Table A-7—Example of wrapped key data .................................................................................................731 Table A-8—DNP3 Secure Authentication parameters in IEC/TS 62351-8 certificates ..............................740 xxxvii Copyright © 2012 IEEE. All rights reserved.


Table A-9—Data included in the HMAC Value calculation in Aggressive Mode......................................742 Table A-10—Creation of certification data .................................................................................................743 Table A-11—Encrypted Update Key data ...................................................................................................753 Table A-12—Data included in the digital signature ....................................................................................755 Table A-13—Data included in the MAC calculation ..................................................................................757

xxxviii Copyright © 2012 IEEE. All rights reserved.


Examples EX 0-1 .........................................................................................................................................................xxv EX 4-1 .......................................................................................................................................................... 35 EX 4-2 .......................................................................................................................................................... 36 EX 4-3 .......................................................................................................................................................... 36 EX 4-4 .......................................................................................................................................................... 36 EX 4-5 .......................................................................................................................................................... 37 EX 4-6 .......................................................................................................................................................... 37 EX 4-7 .......................................................................................................................................................... 38 EX 4-8 .......................................................................................................................................................... 38 EX 4-9 .......................................................................................................................................................... 42 EX 4-10 ........................................................................................................................................................ 43 EX 4-11 ........................................................................................................................................................ 44 EX 4-12 ........................................................................................................................................................ 45 EX 4-13 ........................................................................................................................................................ 46 EX 4-14 ........................................................................................................................................................ 47 EX 4-15 ........................................................................................................................................................ 47 EX 4-16 ........................................................................................................................................................ 48 EX 4-17 ........................................................................................................................................................ 51 EX 4-18 ........................................................................................................................................................ 52 EX 4-19 ........................................................................................................................................................ 53 EX 4-20 ........................................................................................................................................................ 56 EX 4-21 ........................................................................................................................................................ 57 EX 4-22 ........................................................................................................................................................ 58 EX 4-23 ........................................................................................................................................................ 59 EX 4-24 ........................................................................................................................................................ 61 EX 4-25 ........................................................................................................................................................ 63 EX 4-26 ........................................................................................................................................................ 65 EX 4-27 ........................................................................................................................................................ 66 EX 4-28 ........................................................................................................................................................ 69 EX 4-29 ........................................................................................................................................................ 70 EX 4-30 ........................................................................................................................................................ 71 EX 4-31 ........................................................................................................................................................ 73 EX 4-32 ........................................................................................................................................................ 74 EX 4-33 ........................................................................................................................................................ 75 EX 4-34 ........................................................................................................................................................ 76 EX 5-1 .........................................................................................................................................................111 EX 5-2 .........................................................................................................................................................114 EX 5-3 .........................................................................................................................................................116 EX 5-4 .........................................................................................................................................................118 EX 5-5 .........................................................................................................................................................141 EX 5-6 .........................................................................................................................................................143 EX 5-7 .........................................................................................................................................................145 EX 5-8 .........................................................................................................................................................146 EX 5-9 .........................................................................................................................................................148 EX 5-10 .......................................................................................................................................................150 EX 5-11 .......................................................................................................................................................151 EX 5-12 .......................................................................................................................................................152 EX 8-1 .........................................................................................................................................................270 EX 9-1 .........................................................................................................................................................281 EX 11-1 .......................................................................................................................................................309 EX 11-2 .......................................................................................................................................................311 EX 11-3 .......................................................................................................................................................319 EX 11-4 .......................................................................................................................................................320

xxxix Copyright © 2012 IEEE. All rights reserved.



IEEE Standard for Electric Power Systems Communications— Distributed Network Protocol (DNP3) IMPORTANT NOTICE: IEEE Standards documents are not intended to ensure safety, health, or environmental protection, or ensure against interference with or from other devices or networks. Implementers of IEEE Standards documents are responsible for determining and complying with all appropriate safety, security, environmental, health, and interference protection practices and all applicable laws and regulations. This IEEE document is made available for use subject to important notices and legal disclaimers. These notices and disclaimers appear in all publications containing this document and may be found under the heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.” They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.

1 Copyright © 2012 IEEE. All rights reserved.


IEEE Sttd 1815-2012 IEEE Standard d for Electric Pow wer Systems Com mmunications—D Distributed Netwo ork Protocol (DNP3)

1 1.1

Overview Scope

This document d speccifies the DNP P3 protocol sttructure, functtions, and inteeroperable appplication optionns (subseet levels). Thee specified sub bset level deffines the functtionality impleemented in eaach device. Thhe simpleest level is inttended for basiic devices. Mo ore advanced llevels supportt increasing fuunctionality. Thhe protoccol is suitable for f operation on o a variety of communicatioon media consistent with the m makeup of moost electriic power comm munication systtems.

1.2

Purpose e

The pu urpose of this standard is to document and d make availabble the specificcations for the DNP3 protocool. While a primary foccus of this prottocol is the Eleectric Utility Inndustry, other industries thatt deliver Energgy W are also using u DNP3. The T intent of this t DNP3 stanndard is to meeet the goal esttablished by thhe and Water Nation nal Institute of Standards and d Technology (N NIST) for a Sm mart Grid protoocol: ⎯ Provides a protocol p standaard from a reco ognized standaard institution ⎯ Provides intteroperability with w hundreds of operational systems and thhousands of deevices ⎯ Provides cy yber security baased on IEC/TS S 62351-5 ⎯ Provides Deevice data proffiles in a formaat that can be m mapped to IEC 61850 Object Models Vendo ors may use th his standard to o implement and a test the prrotocol in theiir products andd be assured oof interop perability. Useers may use thee document to specify the feaatures they wissh to apply. System Integratoors may use u this standard to assist in sy ystem integratiion and testingg.

1.3

Octet ord der

Unlesss specified elseewhere, the leaast significant octet o in multi-ooctet data valuees is transmitteed first.

2 Copyright © 2012 IEEE. All rightts reserved.


IEEE Std 1815-2012 IEEE Standard for Electric Power Systems Communications—Distributed Network Protocol (DNP3)

2

Normative references

The following referenced documents are indispensable for the application of this document (i.e., they must be understood and used, so each referenced document is cited in text and its relationship to this document is explained). For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments or corrigenda) applies. DNP3 Specification Supplement 1—Device Profile Template and XML Schema, DNP Users Group.1 FIPS 180-2, Secure Hash Standard (includes SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512).2 FIPS 186-2, Digital Signature Standard (DSS), USA NIST, February 2000 including Change Notice #1, October 2001.3 FIPS 198, The Keyed-Hash Message Authentication Code (HMAC), March 2002. IEC 60870-5, Telecontrol equipment and Systems—Part 5: Transmission protocols.4 IEC 61850, A New Approach to Substation Automation, Communications, and Integration. IEC/TS 62351-2, Power systems management and associated information exchange—Data and communications security. Part 2: Communication network and system security—Glossary. IEC/TS 62351-3, Power systems management and associated information exchange—Data and communications security. Part 3: Communication network and system security—Profiles including TCP/IP. IEC/TS 62351-5, Power systems management and associated information exchange—Data and communications security. Part 5: Communication network and system security—Security for IEC 60870-5 and derivatives. IEC/TS 62351-8, Power systems management and associated information exchange—Data and communications security. Part 8: Role-based access control. IEEE Std 754™, IEEE Standard for Floating-Point Arithmetic.5, 6 IETF RFC 768, User Datagram Protocol.7 IETF RFC 791, DARPA Internet Program Protocol Specification. IETF RFC 793, Transmission Control Protocol DARPA Internet Program Protocol Specification. IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication. IETF RFC 3174, US Secure Hash Algorithm (SHA-1). IETF RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. 1

DNP3 Publications are available at http://www.dnp.org/DNP3Downloads. FIPS publications are available from the National Technical Information Service (http://www.ntis.gov/). 3 Only the random number generation algorithms in the appendix are used. 4 IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch/). IEC publications are also available in the United States from the American National Standards Institute (http://www.ansi.org/). 5 The IEEE standards or products referred to in this clause are trademarks owned by the Institute of Electrical and Electronics Engineers, Incorporated. 6 IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/). 7 IETF documents (i.e., RFCs) are available for download at http://www.rfc-archive.org/. 2




IETF RFC 3394, Advanced Encryption Standard (AES) Key Wrap Algorithm. IETF RFC 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. IETF RFC 3629, UTF-8, a transformation format of ISO 10646. IETF RFC 5246, The Transport Layer Security (TLS) Protocol. IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF RFC 5755, An Internet Attribute Certificate Profile for Authorization. ISO/IEC 9798-4, Information technology—Security Mechanisms using a cryptographic check function.8

techniques—Entity

authentication—Part

4:

ISO/IEC 10646, Information technology—Universal Multiple-Octet Coded Character Set (UCS). ISO/IEC 11770-2:2008 Ed. 2, Information Technology—Security techniques—Key management—Part 2: Mechanisms using symmetric techniques. ISO/IEC 11770-3:2008 Ed. 2, Information Technology—Security techniques—Key management—Part 3: Mechanisms using asymmetric techniques. ISO/IEC 18033-2:2006, Information technology—Security techniques—Encryption algorithms—Part 2: Asymmetric ciphers. NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions.9 NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.

8

ISO/IEC publications are available from the ISO Central Secretariat (http://www.iso.org/). ISO publications are also available in the United States from the American National Standards Institute (http://www.ansi.org/). 9 NIST publications are available from the National Institute of Standards and Technology (http://www.nist.gov/).




3 3.1

Definitions, acronym ms, and ab bbreviation ns Definitio ons

For th he purposes of o this documeent, the follow wing terms annd definitions apply. The IIEEE Standardds Dictio onary Online sh hould be consu ulted for terms not defined in this clause.10 Application Servicee Data Unit (A ASDU): The data d presented bby the Applicaation Layer to lower layers fo for mission. Equivaalent to a Distributed Networrk Protocol (DN NP3) Applicatiion Layer fragm ment. transm associiation: The staate information required to maintain a loogical connectiion between a master and aan outstattion. Includes both b the DNP3 3 and the Intern net Protocol infformation. challeenger: A station that issues au uthentication challenges. c Mayy be either a m master or an outtstation. config gure: To set th he parameters of o a device so it i operates in a particular maanner. For instaance, a custom mer may configure c a dev vice so the dev vice never req quests data linkk confirmationns. A vendor oor customer maay config gure a device using u a variety of mechanism ms [e.g., parameeters in non-voolatile random m access memorry (NVR RAM), parameteers in read-only memory (RO OM), dip switchhes, or hardwaare jumpers]. contro ol direction: Transmission T frrom the masterr to the outstatiion. contro ol relay outpu ut block (CRO OB): A structurred data block appearing in rrequest and ressponse messagees associated with actuaating on-off typ pe output devicces. cyclic redundancy check c (CRC): Code that is generated g accorrding to a speccific algorithm, and transmitteed t message, for f the purpose of detecting g data corruptiion during com mmunication vvia the Physiccal with the Layer.. datagram end poin nt: A processs that can sen nd and receivee messages uusing the connnectionless User Datagrram Protocol (UDP). Deadb band: The min nimum amoun nt by which a measured m valuue must vary fr from the last reeported value in order for f an outstatio on to report thee change as an event. deprecated: Indicates that a featurre or requiremeent is still perm mitted althoughh its use is discouraged, and it is not guaranteed to be b a part of futture specification versions. Seee also: obsoleete. DNP3 3TIME: Univeersal Coordinatted Time (UTC C) time expresssed as the num mber of milliseeconds since thhe start of o January 1, 1970. The effecctive date for using u the UTC C time base is January 1, 20008. Prior to thiis, DNP3 did not requirre a specific tim me reference. dual end e point: A process that can both listeen for Transm mission Controol Protocol (T TCP) connectioon requessts and perform m a TCP activee open on the channel. A duall end point in aan outstation shhall also receivve User Datagram D Proto ocol (UDP) dattagrams to faciilitate broadcasst requests. end po oint: A processs on a computer that accepts and/or initiatees communicattion channel esstablishment annd provid des a service fo or other processses to send messages throughh the channel. event:: The occurrence of somethin ng significant happening. h

10

The IEEE Standardss Dictionary Onlline subscription is available at http://www.ieee.oorg/portal/innovatte/products/standarrd/ standard ds_dictionary.htmll.




event buffer: A vendor-specific structure used to hold event data in an outstation. DNP3 does not specify how many buffers an outstation maintains. When the plural buffers is used in this standard, it also refers to the single common structure that some implementation have. event data: The information that is retained regarding an event. Event data are saved at the outstation in vendor-specific structures and reported to the master using DNP3 event objects. Event data shall be kept in the outstation until confirmation has been received from the master indicating that a description of the event arrived at the master. Only after confirmation, may the outstation discard the corresponding event data. With a few exceptions, DNP3 does not define which events are worthy of transmission. event object: A DNP3 object used to report static data in the outstation to the master; a representation of event data that is formatted according to a group number and variation specific to the type of data. fragment: A packet of octets that is sized to fit into the buffers of the receiving device’s Application Layer. Each fragment has an application header and octets containing Application Layer request, response, or confirmation information. frame: A packet of octets transmitted from the Data Link Layer in one device to the Data Link Layer in another device over the Physical Layer. Each frame contains a link header, cyclic redundancy check (CRC) octets, and sometimes a segment from the Transport Function. identical retry: An identical retry of an unsolicited response is a repeat, octet-for-octet of the previously transmitted unsolicited response. The internal indications (IIN) octets shall be the same. The sequence number appearing in the application control octet of an identical retry and the previous unsolicited responses are the same. initiating end point: An initiating process that performs a Transmission Control Protocol (TCP) active open on the channel. input: Refers to values that are measured, read, or generated by the device and are reported by an outstation to a master. Examples are: ⎯ The level of fluid in a tank ⎯ The open-close state of a switch ⎯ The calculated sum of the power on all three phases of a power line Input sometimes refers to the physical source of the value such as a voltage sensor. internal indications (IIN): This bit field appears in response headers that indicate certain states or error conditions with the outstation. Least Significant Byte (LSB): DNP3 uses the term octet instead of byte; therefore, this abbreviation means the least significant octet. It is applied when there are two or more contiguous octets that together are used to hold a value and the lower order octet is intended. listening end point: A listening process that performs a Transmission Control Protocol (TCP) passive open and waits for connection requests. A listening end point shall also receive User Datagram Protocol (UDP) datagrams to facilitate broadcast requests. local issue or local matter: The subject of interest that is restricted to an individual device or system and not generally known to other devices, systems, vendors, or persons. The method of measuring analog quantities in an outstation is a local issue. local mode: An operating condition whereby outputs are prevented from being controlled remotely from a DNP3 master. The outputs can possibly be operated locally at the device where the output point is 6 Copyright © 2012 IEEE. All rights reserved.



physically located. Output points that are not configured for operation by DNP3 are not considered to be in local mode. master: Any entity that issues requests to gather data or perform controls using DNP3. message: A communication containing one or more DNP3 fragments sent from a master to an outstation, or from an outstation to a master. monitoring direction: Transmission from the outstation to the master. Most Significant Byte: DNP3 uses the term octet instead of byte; therefore, this abbreviation means the most significant octet. It is applied when there are two or more contiguous octets that together are used to hold a value and the higher order octet is intended. network address translation (NAT): An Internet standard that enables a local area network (LAN) to use one set of Internet Protocol (IP) addresses for internal traffic and a second set of addresses for external traffic. null response: A response message wherein the Application Layer fragment consists of only application control, function code, and internal indication octets. object: A representation of data that is formatted according to a group number and variation specific to the type of data, for transport in a message. obsolete: Indicates that a feature or requirement is no longer valid; vendors shall not implement them, and users shall disregard any past references in previous specification documents. See also: deprecated. octet: A group of eight contiguous digital information bits. output: Refers to values in an outstation or lower level device that are controlled by commands from the master. Examples are: ⎯ An analog signal that sets the desired pressure for a gas manifold ⎯ Electrical contacts, which when activated, cause a circuit breaker to trip or close Output sometimes refers to the physical device that receives a control signal such as a circuit breaker. parse: To resolve a request or response into component parts. In the context of DNP3 messages, to parse a message means a device can break the message into pieces, each of which consists of a header and sometimes some corresponding data. If a device is able to parse a message, it can recognize each piece of a message. It does not necessarily make use of the data found in that message. However, it shall make any confirmation responses or other responses that the message requires. polled report-by-exception operation: A data retrieval mode in which the master polls frequently for event data and occasionally for static data. polled static operation: A data retrieval mode in which the master polls only for static data; event data is not reported. The nonreporting of event data can cause the master to be unaware of alarm conditions. For example, if a binary input point changes from off to on to off between the static polls, the event data will not be reported, while both static polls will report that the point is off. point: An instance of a point type. point index: The zero-based numeric identifier that differentiates unique instances of points having the same point type within a DNP3 device. 7 Copyright © 2012 IEEE. All rights reserved.



point type: The classification for entities having a common set of characteristics and attributes. Examples include binary inputs, analog inputs, counters, frozen counters, binary outputs, and analog outputs. poll: A request for data from a master to an outstation. polling: An interrogate-reply scheme whereby a master schedules the transmission of requests for data to an outstation. Upon receipt of the request, the outstation returns the requested data in a response. The scheduled time of each poll and the specific data requested are a local matter. primary station (when used in context of the Data Link Layer): The device (master or outstation) that initiates a message transaction between its Data Link Layer and that of a secondary device. The secondary, or non-initiating station, sometimes, but not always, depending on which function code is used by the primary, sends a response to complete the transaction. private: Belonging to or restricted to an individual device or system and not generally known to other devices, systems, vendors, or persons. An example of a private application is a control loop implemented within a utility’s outstation. quiescent operation: A data retrieval mode in which, after startup sequences have been completed, all communication is unsolicited, with the outstation reporting event data in unsolicited responses. Communications loss or device failure, which may stop the transmission of unsolicited responses, should either be prevented or identified immediately in order to prevent loss of data. regenerated retry: The octets of this unsolicited response may contain some or all of the data from the previous unsolicited response and may also include updated data, new data, and changed internal indications (IIN) octets. The sequence number in the application control octet is incremented from the previously transmitted unsolicited response. Regeneration is permitted when the outstation does not receive confirmation to an unsolicited response. remote mode: An operating condition whereby outputs may be controlled from a remotely located master. The outputs may also be operated locally if the system permits this. Reply: A Secure Authentication message sent from an outstation or master in response to an originating Secure Authentication message. report: To actually send to a master device a particular object variation. Used only in connection with outstation devices. An outstation may parse requests for a larger subset of objects than it actually reports. request: An Application Layer message that asks an outstation to perform a specific action. A poll is only one type of request. There are other types of requests (e.g., actuate a control output and set the time). responder: A station that responds or reacts to authentication challenges. May be either a master or an outstation. response: An Application Layer message from an outstation that is returned to the master as the result of a request from the master. secondary station (when used in context of the Data Link Layer): The device (master or outstation) that receives a request from a primary station. segment: A packet of octets that is sized to fit into a Data Link Layer frame. Each segment contains a transport header and a portion of a fragment from the Application Layer. static data: Present values; the most-recently measured, computed, or obtained values.




static object: A DN NP3 object used d to report stattic data in the outstation to tthe master; a rrepresentation oof d that is form matted accordiing to a group number n and vaariation specifiic to the type of data. static data subsett: The complex xity of a DNP3 3 device depen nds on its intennded function w within a system m. Therefore, nnot all dev vices need to implement alll DNP3 functiionality. To asssure interoperrability, variouus levels, calleed subsett levels, are defined that speccify behavior and a parsing reqquirements. Eaach subset speccifies a selectioon of DN NP3 objects thatt a device shalll be capable off: ⎯ Parsing wheen they appearr in a message ⎯ Processing if the respectiv ve data type is supported ⎯ Formulating g appropriate requests r or resp ponses with theese objects Superrvisory Contro ol and Data Acquisition A (S SCADA): A geeneric term ussed to indicate monitoring annd contro olling devices that are physsically located d remotely froom a centralizzed computer. Some form oof comm munications are implied betweeen the central location and thhe outlying devvices. suppo ort: To be ablee to send or paarse a particulaar set of DNP33 objects, variiations, functioon codes, and/oor qualifi fiers. transm mitted unsoliccited response: Any unsolicitted response thhat has been seent from the ouutstation regard dless of whetheer it was an orig ginal, an identiical retry, or a regenerated retry response. unsoliicited report-by-exception operation: A data retrievaal mode in w which most coommunication is unsolicited, with th he outstation reporting eventt data in unsoolicited responnses, and the master sendinng infrequ uent periodic polls. p If multip ple outstations simultaneously s y report a flurrry of unsoliciteed responses, thhe network could becom me clogged witth collisions an nd retries. unsoliicited response: An Applicaation Layer meessage from ann outstation to a master for w which no expliccit requesst was received d. The request is i implied by th he act of a masster enabling uunsolicited repoorting of variouus points within an outsstation. unsoliicited responsse series: A seequence of unssolicited responnses that beginns with an origginal unsoliciteed respon nse, may contaain identical reetry messages, and terminate s when the ouutstation receivves the matchinng unsolicited applicatio on confirmatio on.

3.2

Acronym ms and abbrreviations

ASCIII

Am merican Standaard Code for In nformation Inteerchange

ASDU U

Ap pplication Serv vice Data Unit

ATM

Assynchronous Trransfer Mode

BCD

bin nary-coded deccimal

CA

cerrtificate authorrity

CON

A bit in the Appllication Layer’s control octett that specifies whether an Appplication Layyer nfirmation is required con

CRC

cyclic redundanccy check

CROB B

con ntrol relay outp put block

CSQ

Ch hallenge Sequeence Number 9 Copyright © 2012 IEEE. All rightts reserved.



DFC

Data Flow Control

DNP

Distributed Network Protocol

DNP3

Distributed Network Protocol

EFCB

expected Frame Count bit

EPA

Enhanced Performance Architecture

EPRI

Electric Power Research Institute

FCB

Frame Count bit

FCV

Frame Count Valid

FIN

Final Data Link frame or final Application Layer fragment in a message

FIR

First Data Link frame or first Application Layer fragment in a message

FT#

Frame Type #

GPS

global positioning system

HMAC

Hash Message Authentication Code

IANA

Internet Assigned Numbers Authority

IEC

International Electrotechnical Commission

IED

intelligent electronic device

IERS

International Earth Rotation Service

IIN

internal indications

IP

Internet Protocol

ISO

International Organization for Standardization

KSQ

key change sequence number

LAN

local area network

LSB

Least Significant Byte (see definition in 3.1)

MSB

Most Significant Byte (see definition in 3.1)

NAT

network address translation

NIST

National Institute of Standards and Technology

NVRAM

non-volatile random access memory

OSI

Open System Interconnection 10 Copyright © 2012 IEEE. All rights reserved.



PCB

Pattern Control Block

PCM

Pattern Control Mask

RMS

root mean square

ROM

read-only memory

RTU

remote terminal unit

SCADA

Supervisory Control and Data Acquisition

SEQ

Sequence number that differentiates subsequent Data Link frames or Application Layer fragments. Sequence numbers associated with unsolicited responses are distinct from sequence numbers used for solicited responses

SHA

Secure Hash Algorithm

SSL

Secure Sockets Layer

TCP

Transmission Control Protocol

TLS

Transport Layer Security

UCA

Utility Communications Architecture

UDP

User Datagram Protocol

UML

Unified Modeling Language

UNS

A bit in the Application Layer’s control octet that specifies whether a fragment (response and confirmation) pertains to an unsolicited response. When this bit is set, the sequence number in the SEQ field refers to the unsolicited sequence number

UTC

Universal Coordinated Time

UTF

Unicode Transformation Format

UUID

Universally Unique Identifier

VT

virtual terminal

WAN

wide area network

XML

Extensible Markup Language

XSLT

Extensible Stylesheet Language Transformations




3.3

Special terms t

intelligent electroniic device (IED D): These are usually u physicaally located cloose to sensors oor actuators thhat are mo onitored or con ntrolled. outsta ation: A process that has dataa, variables, orr information thhat another proocess wants to obtain or wannts to set to a new valuee. May also reffer to a device that contains aan outstation pprocess. An outtstation can bee a numbeer of differentt devices/systeems; some off these are inttelligent electrronic devices (IEDs) (remoote termin nal units, rellays, meters, programmab ble logic conntrollers, disttributed inputts/outputs, daata concen ntrators/protoccol converters, and substation n human–machhine interfaces)), master statioons, and regionnal operattion center masster stations. remotte terminal un nit (RTU): Sim milar to an inteelligent electroonic device (IE ED), these are nnormally placeed in thee field close to o sensors or actuators a that are monitoredd or controlledd. Often, RTU Us are mounteed outdoo ors and have deemanding enviironmental specifications.




4

Applicatio on Layer— —part 1

4.1

Applicattion Layer preface p

4.1.1

Layering

The Application A Lay yer is the top layer in the EPA E and OSI models. It inteerfaces with thhe DNP3 userr’s softwaare and with th he lower layerrs. Figure 4-1 shows where the layer fits w within the layeering stack. Thhe Appliccation Layer provides stan ndardized funcctions, data fformats, and procedures foor the efficiennt transm mission of data acquisition values, attributess, and control ccommands. DNP3 user’s softwarre is the application program that makes a ddevice unique, whether it is a master, IED, oor a dataa concentrator. It makes use of the Appliccation Layer’ss services to send messages to, and receivve messaages from, anotther DNP3 dev vice.

Master

O Outstation

Usser Layer

U User Layer

DNP3 D Appliccation Layeer

DNP3 Appliication Layyer

Transp port Functio on

Transpport Functiion

DNP3 D Data Link Layerr

DNP3 Dataa Link Layeer

Physiccal Media Figure 4-1— —Layering d diagram 4.1.2

Introduction to points and point ty ypes

In DN NP3, a point is a uniquely iden ntifiable physiccal or logical eentity. The term m “point” appliies to inputs likke analog gs, binaries, an nd counters and a to outputs like analogs and binaries. A single anaalog input is aan examp ple of a point. It is associaated with a sp pecific measureed signal or ccomputed anallog quantity. IIn additio on to a value, an a analog inpu ut may have a name, n a scale ffactor, a deadbband value for event detection, and otther attributes. A point type is a means m of categ gorizing pointss having relateed characteristtics, similar fuunctionality, annd onship to physsical hardware or logical spaace. Using thee example from m the previouus paragraph, aan relatio analog g input belongss to the analog input point typ pe. DNP3 models each point type as an independen nt array of poiints. Each poinnt is uniquely identified by iits DNP3 outstationn. index within the arraay. Figure 4-2 illustrates fivee basic point typpes within a D 13 Copyright © 2012 IEEE. All rightts reserved.



Figure 4-2—Point type arrays A few DNP3 concepts associated with points are as follows: ⎯ A point is identified by an index. ⎯ A point usually has a static value. ⎯ A point may generate events. ⎯ Information about a point is reported using one or more objects. Subclause 4.1.3 through 4.1.6 define these in detail. 14 Copyright © 2012 IEEE. All rights reserved.



4.1.3

Introduction to indexe es, groups, and a variation ns

Figure 4-2 shows a DNP3 Outstation having fivee point types thhat it can transsport. DNP3 caan also transpoort a other dataa forms. The transmitter t shaall suitably enncode point information apppearing within a files and messaage to enable the t receiving device to parsse and properlly interpret thiis data. The inndex and grouup numbeers identify a unique u point, an nd the variation n describes its data format. 4.1.3.1

Indexes

DNP3 uses index nu umbers to iden ntify points hav ving the same point type. Inddex numbers aare equivalent to bers. DNP3 indexes i are zero-based; thaat is, the low west element iis always zerro. array element numb nuing with the analog input example, the first f 10 analog input points aare referenced using indexes 0 Contin throug gh 9. 4.1.3.2

Groups

Group ps provide a means m of classiifying the typee or types of ddata within a message. Eachh group number sharess a common po oint type and method m of data generation or creation. Conttinuing with thhe example of aan analog g input point ty ype, group num mbers are used to t report data aas follows: Group p 30—current value v of the point Group p 31—frozen vaalue of the poin nt Group p 32—change of o current valuee event Group p 33—change of o frozen valuee event

The groupp numbers listeed are intendedd to illustrate tthe different daata types that ccan be reported ffor the analog iinput point type; it is not requirred that all deviices support thhese specific grroups and dataa types—discusssion of these isssues occurs laater.

Group p numbers are also a used for sp pecifying the type t of data neeeded for reporrting time valuues, file controlls, virtuall terminal charracters, and oth her information n. NOTE— —The term objeect group is often n used in lieu off group. Group hhas many commoon meanings andd is often intendeed as a collection of thing gs. Object group is more suggestiive of a set of pooint indexes assoociated with a sppecific point typee o Objects are discussed inn 4.1.4. whose data are conveyed by message objects.

4.1.3.3

Variation ns

DNP3 offers a choicce of encoding formats for maany of the dataa types. The chhoices are know wn as variationns. Every group numberr has an indepeendent set of vaariations. For ex xample, group 30 3 has the follo owing variations: 1—a 32-bit intteger value witth flag Thee flag refers to supplementaryy data that indiicates conditions such as the source beinng online, the ssource device hhaving resttarted, or the vaalue being outsside of the measurement rrange. Refer too nnex A for speccific details. An

2—a 16-bit intteger value witth flag 3—a 32-bit intteger value 4—a 16-bit intteger value 5—a 32-bit flo oating-point vaalue with flag 6—a 64-bit flo oating-point vaalue with flag

Variattions are somettimes used in DNP3 D to identtify attribute vaalues, counts oof octets, and oother formattinng issues. Annex A pro ovides details fo or all of the variations.




4.1.4

DNP3 obje ects

A DN NP3 object is an a encoded rep presentation of o data from a point, or otheer structure, thhat is formatteed accord ding to its grou up and variation n number for trransport in a m message. A messsage may conttain multiple objects, o each reepresenting thee value of a poiint at a given innstant in time oor a command to be issued to an outpu ut point. The teerm instance is sometimes useed to distinguissh one object ffrom another. F For example, a message withh 6 objectts holds the cu urrent value of 6 analog inp put points, exppressed as 32--bit integers. H Here, the grouup numbeer is 30, the varriation is 3, and there are 6 in nstances of 32--bit analog inpuut objects. Objectt specifics appeear in Annex A. A 4.1.5 4.1.5.1

Static, eve ent, and clas ss data Static

In DN NP3, the term sttatic refers to the t point’s currrent value, whiich is the most recently measured, computeed, or obtained value. Thus, static binaary input data refers to the prresent on or offf condition off a bi-state poinnt. d contains the t most recen ntly obtained v alue of an anaalog input poinnt. DNP3 allow ws Static analog input data ossibility to req quest some or all a of the static data from an ooutstation devicce. the po 4.1.5.2

Events

DNP3 events are asssociated with h something off significance happening. E Examples are sstate changes, a urement whosee value crosses some thresholld, an analog iinput changingg by more thann its deadband, a measu snapsh hot of data takeen at a particular time, transieent phenomenaa, and some new wly available iinformation. In maany cases, the logic associatted with pointss in an outstat ation can generrate events, buut other entitiees within n an outstation n can also causse creation of events. An ouutstation stores information about events in proprietary, vendor-sspecific structu ures. Examp ples of the stru uctured informaation stored forr each event arre as follows: ⎯ Type of eveent (binary inpu ut, analog inpu ut, etc.). ⎯ Value (on, off, o 387, etc.). ⎯ Point index x. ⎯ Time when event occurred d. ⎯ Class assign nment. ⎯ A representtative object is in transmit buffer (true or fallse). An ev vent is generateed or created when w somethin ng occurs thatt requires storaage of a new sset of structureed inform mation about th he event. It is im mportant to kn now the differrence between events and thhe DNP3 objeects that report events. Eveen though h some DNP3 objects are referred to as “eevent objects,” they are onlyy a representatiion of the evennt, and no ot the actual strructured inform mation stored in n the outstationn. The stored eevent information may only bbe deleted d from an outsstation after an event descripttion has been ttransmitted to tthe master (in a DNP3 objectt), and th he outstation haas received con nfirmation back k from the masster acknowleddging that it recceived the evennt.




The three fundamental principles in DNP3 are as follows: ⎯ The decision as to what constitutes an event is usually a local issue. ⎯ It is not permitted to lose or discard the stored structured event information until a representation of the event has been transmitted to and acknowledged by the master. ⎯ Duplicate reporting of an event should be avoided. The determination that a point has undergone a significant change may only be based on information from that point’s current or past value. Decisions based on information about any other point, directly or indirectly, are explicitly forbidden. There are DNP3 objects defined for reporting events with and without time stamps. 4.1.5.3

Classes

DNP3 uses the concept of classes to organize static data and events into several categories: ⎯ Class 0: Static data (may be a subset of the outstation’s total static data) ⎯ Classes 1, 2, 3: Events The points of most data types may be assigned to one of the four classes (see 5.1.4 for details of which data types may be assigned to which classes). If a point is assigned to Class 0, the point’s present value shall be reported by the outstation in its response to a Class 0 poll, but the outstation shall not store or report any events for that point. If a point is assigned to one of the event classes (Class 1, 2, or 3), the outstation shall store and report events for that point, and the point’s present value shall also be reported by the outstation in its response to a Class 0 poll. If a point is not assigned to any class, the outstation shall not include the point’s present value in its response to a Class 0 poll, nor shall it store or report events for that point. Note that if a point is not assigned to one of the four classes, the outstation shall still report its present value if the master performs a static poll for the specific data type. For example, if a master’s request for binary input static data specifies all binary input points, or specifies the index of such a point (not assigned to one of the four classes), the outstation shall include that point’s present value in its response. If a point is not assigned to one of the event classes (Class 1, 2, or 3), the outstation shall not store any events for the point. Therefore, even if a master requests events of a specific data type, the outstation shall not report events for points that are not assigned to an event class.




Table T 4-1—Re eporting clas sses table Poin nt not assigneed to any cllass

Point asssigned to Class 0

Point assigned to Class 1

Point assigned to Class 2

Point assigned too Class 3

Presentt value included in response to static data--type poll?

Yes Y

Yes

Yes

Yes

Yes

Presentt value included in response to Class 0 polll?

No N

Yes

Yes

Yes

Yes

Events stored and even nt nse to data included in respon Class 1 poll?

No N

No

Yes

No

No


No N

No

No

Yes

No


No N

No

No

No

Yes

DNP3 does not assig gn significancee to the three event e classes. O One strategy iss to assign the highest priority t Class 3, butt other strategiees may work bbetter in speciffic eventss to Class 1 and the lowest prriority events to system ms. Equipmentt manufacturerrs and personss configuring ddevices may ddecide which sstrategy is moost approp priate for their application. Masters M may req quest events froom one or morre of these classses. Subclaause 4.4.14 desscribes dynamiically assigning g events to eveent classes andd contains inforrmative materiial regard ding event classses and statemeents about outsstation configuuration. 4.1.6

Outstation n event buffe ering

This subclause is adv visory to aid understanding. u Its I purpose is tto discuss conccepts related too retaining event mation and to preventing losss or duplicatiion of event ddata. It is not the intention to explicitly oor inform impliccitly specify an n implementatio on design. An ev vent buffer is a structure in th he outstation ussed to temporaarily store evennt information.. When an event is gen nerated, softwaare places information about the event intoo the buffer w where it remainns until relevaant facts about a the eventt have been traansmitted to the master and th their delivery cconfirmed. Upoon receipt of thhe confirm mation, event information iss permanently removed from m the buffer. R Refer to 4.1.5..2 for additionnal discusssion of event information. i DNP3 does not speccify how many y buffers an ou utstation mainttains, one or m multiple. Buffeer structure, daata ntents are also not specified. These are con sidered vendorr-specific desiggn issues. organiization, and con These examples are meant to illusstrate event infformation. Deppending on othher implementaation details annd a other factorss, a design may y include more or less data foor each event. event types as well as As staated, event infformation is reetained in the buffer until ddata has been sent to and coonfirmed by thhe masterr. This guaranttees that eventss are not lost. 18 Copyright © 2012 IEEE. All rightts reserved.



Remov ving event info ormation from the buffer afteer transmissionn to, and confirrmation back ffrom, the mastter is suffficient to preveent reporting off the same even nt more than oonce when the ddevice is used in a polled-onnly enviro onment. Additional guards are required when w an outsstation is usedd in an unsollicited reportinng enviro onment. Figure 4-3 illustrattes buffering concepts. c Pleaase keep in m mind that the ddiagram does not represent a required design. Event Buffer

Buffered information is ddiscarded upon receipt of a confirmation from master .

Event objects representing r the eveents are put into a transmit bufffer to create a response message .

Shaded areaa shows event information in the buffer .

Shaded area shows even nt objects in the bu uffer .

Response Transm mit Buffer

Note: This diagram is intended to o illustrate conceptss and does d imply a requirred design .

Information about a new event is placed in the buffer at the time when the event is generated .

Fig gure 4-3—Ev vent buffering g concepts NOTE— —The descriptio ons in this standard sometimes use u the term evennt buffer and at oother times referrs to event bufferrs. There is i no significancce to the use of the t singular or plural p form, and the reader is cauutioned to think more about eveent buffering rather than ab bout the numberr of buffers.

4.2

Message e structure

Masters formulate and a send requeest messages for f an outstatioon to return ddata, carry out a command, oor perforrm a special acctivity. Upon reeceipt, an outsstation perform ms or initiates tthe requested aaction, generatees an app propriate respo onse message,, and transmitss it back to thhe master withh the data, ressults, or speciial inform mation. In certtain systems, an a outstation may m spontaneou usly transmit ann unsolicited reesponse messaage to the mastter on thee basis that the request is impllied.




4.2.1

Applicatio on Layer frag gments

A frag gment is a block of octets co ontaining requ uest or responsse information transported beetween a mastter and an n outstation. Each E fragment contains a fun nction code sppecifying how the receiver sshall process thhe fragmeent, zero or more m data objecct headers and data-filled obj bjects, and infoormation for chhecking that thhe fragmeent is received d in the propeer order. Subcllause 4.2.2 disscusses the innternal details of a fragmentt’s structu ure. DNP3 allows devices to limit thee amount of memory m reservved for sendinng and receivinng messages. It ves this by speecifying the maaximum length h of each fragm ment and allow wing response messages to bbe achiev divideed into one or multiple fragm ments. Small messages, m requiiring only a feew octets, can fit into a singgle fragmeent, whereas laarger messagess may require multiple m fragmeents. Fragm ments are someetimes broken into smaller blocks b when thhey are passedd to the lower layers and theen reassembled at the reeceiving end. This T is illustrateed in 0.2 of thiis standard. Fragm ment rules are detailed d in 4.3. 4.2.2 4.2.2.1

Applicatio on Layer frag gment structure General fragment strructure

Requeest and responsse fragments haave similar, butt slightly differrent, structuress (Figure 4-4). Start of Fraagment Request Fragm ment Application Request Header

First Object Header

Last Object Header

DNP3 Objects

DNP3 Objects

Response Frag gment Application Response Header

First Object Header

Last Object Header

DNP3 Objects

DNP3 Objeccts

Figure 4-4— —Fragment sttructure Each fragment f begin ns with an appllication headerr that contains m message controol informationn. This is true fo for all frag gments regardlless of whetherr they appear in n single or mulltiple fragmentt messages. The ap pplication resp ponse header contains an ad dditional field, called internaal indications. This field doees not ap ppear in an appllication requesst header. Often an application n header alone is insufficientt to convey com mplete informaation, and one or more sets oof P3 objects are included afterr the applicatioon header. Thhese provide thhe objectt headers and possibly DNP additio onal informatio on needed to form a compleete message. B Briefly, an objject header speecifies the typpe, formatt, and identificcation of the DN NP3 objects th hat follow. A ggeneral descripption of object headers appeaars in 4.2..2.7 of this doccument, and a complete list of o DNP3 objecct descriptions and encoding are presented in Annex x A of this stan ndard. 4.2.2.2

Applicattion request header

An application requeest header is used in requestss from masterss and has two ffields (Figure 4-5). Each field is one octet in length h. The fields are described in 4.2.2.4 and 4.22.2.5.




Figure 4-5—Application request header 4.2.2.3

Application response header

An application response header is used in responses from outstations and has three fields (Figure 4-6). The application control and function code fields are the same as in an application request header. The third field is two octets in length. The three fields are described in 4.2.2.4, 4.2.2.5, and 4.2.2.6.

Figure 4-6—Application response header 4.2.2.4

Application control octet

The application control octet provides information needed to construct and reassemble multiple fragment messages and to indicate whether the receiver’s Application Layer shall return an Application Layer confirmation message. It also provides information to assist in duplicate message detection. The bits in an application control octet form five fields as in Figure 4-7.

Figure 4-7—Application control octet fields 4.2.2.4.1

FIR field

The FIR field is a single bit which, when set, indicates that this is the first fragment of a message. ⎯ FIR = 0 indicates this is not the first fragment of a message. ⎯ FIR = 1 indicates this is the first fragment of a message. 4.2.2.4.2

FIN field

The FIN field is a single bit which, when set, indicates that this is the final fragment of a message. ⎯ FIN = 0 indicates that more fragments follow. ⎯ FIN = 1 indicates this is the final fragment of a message.




4.2.2.4.3

CON field

The CON field is a single bit which, when set, indicates that the receiver’s Application Layer shall return an application confirmation message. ⎯ CON = 0 indicates an Application Layer confirmation message shall not be returned. ⎯ CON = 1 indicates an Application Layer confirmation message shall be returned. An Application Layer confirmation message is a very brief message that is used to verify that a complete fragment arrived at its destination. ⎯ Rule 1: An outstation shall set the CON bit in response messages containing event data. Confirmation back from the master indicates that the event information arrived at the master was properly understood and processed and that the outstation can safely discard the events whose data appeared in the response. ⎯ Rule 2: The CON bit shall be set for each fragment of a multi-fragment response message with the exception of the last fragment. Setting the CON bit in the last fragment is optional; it may be set or cleared if desired unless other reasons require it to be set. Receipt of the confirmation signifies that the device may safely transmit the next fragment. ⎯ Rule 3: An outstation shall set the CON bit in unsolicited response messages. Receipt of the confirmation indicates that the master received the message and that the outstation can advance its state logic. NOTE—Outstations that have no events available when the master requests events are encouraged to clear the CON bit in the response (not request confirmation) unless there is another reason for setting that bit. Confirming the receipt of no events does not serve a useful purpose.

⎯ Rule 4: Masters shall never request Application Layer confirmation; i.e., the CON bit shall never be set in a request message. This practice is obsolete. 4.2.2.4.4

UNS field

The UNS field is a single bit which, when set, indicates the message contains an unsolicited response or a confirmation of an unsolicited response. ⎯ UNS = 0 indicates the sequence number is associated with a master request or a solicited response message. ⎯ UNS = 1 indicates the sequence number is associated with an unsolicited response message. Outstations set this bit in fragments that contain an unsolicited response. Masters set this bit in Application Layer confirmation fragments that confirm the receipt of an unsolicited response. Outstations clear this bit in solicited response fragments. Masters clear this bit in request fragments and in Application Layer confirmation fragments that confirm the receipt of a solicited response. 4.2.2.4.5

SEQ field

The SEQ field is 4 bits wide. It is used to verify that fragments are received in the correct order and to detect duplicated fragments. The SEQ field has a range of 0 to 15. After the sequence number of 15, the next value is 0. The number increments by one count, modulo 16, for the following, except when the message is sent as an Application Layer retry. ⎯ Master request fragments.




⎯ Subsequent fragments after the first in a multi-fragment message. ⎯ Unsolicited response fragments. A device that supports both solicited and unsolicited responses shall maintain independent sequence numbers for every other device with which it communicates: ⎯ One is used for solicited requests, responses, and confirmations. ⎯ The other is used for unsolicited responses and confirmations. No relationship exists between the two sequence numbers. 4.2.2.5

Function code octet

The function code octet identifies the purpose of the message. Request messages from masters use function codes in the range of 0 to 128, and response messages from outstations use function codes with values ranging from 129 to 255 as shown in Table 4-2. Table 4-2 gives a brief description of each function code. Subclause 4.4 of this document provides detailed procedures for each function code. The subclause numbers referenced in the right-hand column indicate where the respective details are located.




Table 4-2—Function code table Message type

Confirmation

Code

0 0x00

Brief description

Name

Confirm Function Code: Master sends this to an outstation to confirm the receipt of an Application Layer fragment.

CONFIRM

Reference: 4.4.1

Request

1 0x01

Read Function Code: Outstation shall return the data specified by the objects in the request.

READ

Reference: 4.4.2

Request

2 0x02

Write Function Code: Outstation shall store the data specified by the objects in the request.

WRITE

Reference: 4.4.3

Request

3 0x03

Select Function Code: Outstation shall select (or arm) the output points specified by the objects in the request in preparation for a subsequent operate command. The outstation shall not activate the outputs until a request with a matching Operate function code is received.

SELECT

Reference: 4.4.4

Request

4 0x04

Operate Function Code: Outstation shall activate the output points selected (or armed) by a previous select function code command.

OPERATE

Reference: 4.4.4

Request

5 0x05

Direct Operate Function Code: Outstation shall immediately actuate the output points specified by the objects in the request. A prior matching select command is not required.

DIRECT_OPERATE

Reference: 4.4.5

Request

6 0x06

Direct Operate—No Response Function Code: Same as function code 5 but outstation shall not send a response.

DIRECT_OPERATE_NR

Reference: 4.4.5

Request

7 0x07

Immediate Freeze Function Code: Outstation shall copy the point data values specified by the objects in the request to a separate freeze (or holding) buffer (or register).

IMMED_FREEZE

Reference: 4.4.6




Message type

Request

Code

8 0x08

Brief description

Name

Immediate Freeze—No Response Function Code: Same as function code 7 but outstation shall not send a response.

IMMED_FREEZE_NR

Reference: 4.4.6

Request

9 0x09

Freeze and Clear Function Code: Outstation shall copy the point data values specified by the objects in the request into a separate freeze (or holding) buffer (or register). After the copy operation, clear the point data values to zero.

FREEZE_CLEAR

Reference: 4.4.7

Request

10 0x0A

Freeze and Clear—No Response Function Code: Same as function code 9 but outstation shall not send a response.

FREEZE_CLEAR_NR

Reference: 4.4.7

Request

11 0x0B

Freeze at Time Function Code: Outstation shall copy the point data values specified by the objects in the request to a separate freeze (or holding) buffer (or register) at the time and/or time intervals specified in a special time data information object.

FREEZE_AT_TIME

Reference: 4.4.8

Request

12 0x0C

Freeze at Time—No Response Function Code: Same as function code 11 but outstation shall not send a response.

FREEZE_AT_TIME_NR

Reference: 4.4.8

Request

13 0x0D

Cold Restart Function Code: Outstation shall perform a complete reset of all hardware and software in the device.

COLD_RESTART

Reference: 4.4.9

Request

14 0x0E

Warm Restart Function Code: Outstation shall reset only portions of the device.

WARM_RESTART

Reference: 4.4.9

Request

15 0x0F

Initialize Data Function Code: Obsolete—Do not use for new designs.

INITIALIZE_DATA

Reference: 4.4.10

Request

16 0x10

Initialize Application Function Code: Outstation shall place the applications specified by the objects in the request into the ready to run state.

INITIALIZE_APPL

Reference: 4.4.11




Message type

Request

Code

17 0x11

Brief description

Name

Start Application Function Code: Outstation shall start running the applications specified by the objects in the request.

START_APPL

Reference: 4.4.11

Request

18 0x12

Stop Application Function Code: Outstation shall stop running the applications specified by the objects in the request.

STOP_APPL

Reference: 4.4.11

Request

19 0x13

Save Configuration Function Code: Outstation shall store into non-volatile memory the contents of a configuration file located in volatile memory. This code is deprecated—Do not use for new designs.

SAVE_CONFIG

Reference: 4.4.12

Request

20 0x14

Enable Unsolicited Responses Function Code: Enables outstation to initiate unsolicited responses from points specified by the objects in the request.

ENABLE_UNSOLICITED

Reference: 4.4.13

Request

21 0x15

Disable Unsolicited Responses Function Code: Prevents outstation from initiating unsolicited responses from points specified by the objects in the request.

DISABLE_UNSOLICITED

Reference: 4.4.13

Request

22 0x16

Assign Class Function Code: Outstation shall assign the events generated by the points specified by the objects in the request to one of the classes.

ASSIGN_CLASS

Reference: 4.4.14

Request

23 0x17

Delay Measurement Function Code: Outstation shall report the time it takes to process and initiate the transmission of its response. This allows the master to compute the propagation delay in the communications channel. Used for non-LAN time synchronization.

DELAY_MEASURE

Reference: 4.4.15

Request

24 0x18

RECORD_CURRENT_TIME

Record Current Time Function Code: Outstation shall save the time when the last octet of this message is received. Used for LAN time synchronization. Reference: 4.4.16

Request

25 0x19

Open File Function Code: Outstation shall open a file. OPEN_FILE Reference: 4.4.17




Message type Request

Request

Code 26 0x1A

27 0x1B

Brief description

Name

Close File Function Code: Outstation shall close a file. CLOSE_FILE Reference: 4.4.17 Delete File Function Code: Outstation shall delete a file.

DELETE_FILE

Reference: 4.4.17

Request

28 0x1C

Get File Information Function Code: Outstation shall retrieve information about a file.

GET_FILE_INFO

Reference: 4.4.18

Request

29 0x1D

Authenticate File Function Code: Outstation shall return a file authentication key.

AUTHENTICATE_FILE

Reference: 4.4.19

Request

30 0x1E

Abort File Function Code: Outstation shall abort a file transfer operation.

ABORT_FILE

Reference: 4.4.17

Request

31 0x1F

Activate Configuration Function Code: Outstation shall use the configuration specified by the objects in the request.

ACTIVATE_CONFIG

Reference: 4.4.20

Request

32 0x20

Authentication Request: Outstation shall process a Secure Authentication object

AUTHENTICATE_REQ

Reference: 4.4.21

Request

33 0x21

Authentication Request No Acknowledgment: Outstation shall process a Secure Authentication object, but outstation shall not send a response.

AUTH_REQ_NO_ACK

Reference: 4.4.22 Request

Response

34 to 128 0x22 to 0x80

129 0x81

Reserved.

Solicited Response: Master shall interpret this fragment as an Application Layer response to an Application Layer request sent by the master.

RESPONSE

Reference: 4.4.20

Response

130 0x82

UNSOLICITED_RESPONSE

Unsolicited Response: Master shall interpret this fragment as an unsolicited response that was not prompted by an explicit request. Reference: 4.4.24




Message type Response

Code 131 0x83

Brief description

Name

Authentication Response: Master shall interpret this fragment as an authentication response.

AUTHENTICATE_RESP

Reference: 4.4.25 Response

4.2.2.6

132 to 255 0x84 to 0xFF

Reserved.

Internal indications

The internal indications field appears in application response headers immediately following the function code octet. This field has two octets. The bits in these two octets indicate certain states and error conditions within the outstation (Figure 4-8).

Figure 4-8—Internal indications octets Each octet has 8 bit fields numbered 0 through 7 where bit 0 is the least significant bit. This standard uses the code IINx.b to reference or specify a particular bit where: ⎯ x is a 1 for the first octet and x is a 2 for the second octet. ⎯ b identifies the bit number. Thus, IIN2.0 refers to the first bit in the second octet. To simplify referencing the IIN bits in code and other documentation, each IIN bit has a name as shown in Table 4-3. A brief description of each bit is given in the table. Detailed descriptions are provided in 4.5 of this document. The subclause numbers referenced in the right-hand column indicate where the respective details are located. Readers are cautioned to read the detailed descriptions in 4.5 because the brief descriptions provided in Table 4-2 do not adequately express the complete requirements and interpretation of the IIN bits.




Table 4-3—IIN bits Bit IIN1.0

Brief description A broadcast message was received.

Name BROADCAST

Reference 4.5.1 The outstation has unreported Class 1 events. IIN1.1

CLASS_1_EVENTS Reference 4.5.2 The outstation has unreported Class 2 events.

IIN1.2

CLASS_2_EVENTS Reference 4.5.3 The outstation has unreported Class 3 events.

IIN1.3

CLASS_3_EVENTS Reference 4.5.4 Time synchronization is required.

IIN1.4

NEED_TIME Reference 4.5.5 One or more of the outstation’s points are in local control mode.

IIN1.5

LOCAL_CONTROL Reference 4.5.6 An abnormal, device-specific condition exists in the outstation.

IIN1.6

DEVICE_TROUBLE Reference 4.5.7 The outstation restarted.

IIN1.7

DEVICE_RESTART Reference 4.5.8 The outstation does not support this function code.

IIN2.0

IIN2.1

NO_FUNC_CODE_SUPPORT Reference 4.5.9 Outstation does not support requested operation for objects in the request.

OBJECT_UNKNOWN

Reference 4.5.10 A parameter error was detected. IIN2.2

IIN2.3

IIN2.4

IIN2.5

PARAMETER_ERROR

EVENT_BUFFER_OVERFLOW

ALREADY_EXECUTING

CONFIG_CORRUPT

Reference 4.5.11 An event buffer overflow condition exists in the outstation, and at least one unconfirmed event was lost. Reference 4.5.12 The operation requested is already executing. Support is optional. Reference 4.5.13 The outstation detected corrupt configuration. Support is optional. Reference 4.5.14 Reserved for future use. Always set to 0.

IIN2.6

RESERVED_2 Reference 4.5.15 Reserved for future use. Always set to 0.

IIN2.7

RESERVED_1 Reference 4.5.16




4.2.2.7

Object headers

DNP3 object headers and objects provide supplementary information as required when the application header alone cannot convey the complete message. To explain why object headers are needed, consider a master that wants to read 20 analog values from a remote terminal unit (RTU) device. In formulating the request message, the master uses the function code READ, which specifies the action. The object header (or headers) in the request specifies ⎯ The analog input point type data is wanted. ⎯ The integer or floating-point format the outstation should use when sending its data. ⎯ Which particular 20 input point indexes. DNP3 objects are not included in the request, only an object header (or headers), because the master is not sending values; it only sends enough information for the outstation to know which values and format are desired. The response message uses function code RESPONSE and contains the same or a similar object header (or headers) followed by the DNP3 objects. Each object consists of a single analog value from a single point index. This subclause elaborates on the construction of object headers. Clause 11 specifies the details of individual DNP3-supported objects. Object headers consist of mandatory object type and qualifier fields and a range field that is contingent on the code in the qualifier field. The object type field consists of a group octet followed by a variation octet (Figure 4-9). Object Header Object Type Field Group (1 octet)

Variation (1 octet)

Qualifier Field (1 octet)

Range Field (dependent upon qualifier)

Figure 4-9—Object header fields 4.2.2.7.1

Object group

The object group specifies what data type or values are included in a master request or in an outstation response. A complete collection of object groups appear in Annex A. A few examples are as follows: ⎯ Analog input, current value. ⎯ Binary input, event value. ⎯ Frozen counter, current value. ⎯ Control relay output block (CROB) value. ⎯ Time value. 4.2.2.7.1.1

Object group 60

Object group 60 is a special group number assigned for requesting data from one of the class categories. Only a master request may include this object group in a message. Depending on the associated object variation (explained in 4.2.2.7.2), the master includes this object in a message when it wants an outstation to return all or some of its Class 0 static data or Class 1, 2, or 3 event data. 30 Copyright © 2012 IEEE. All rights reserved.



The response does not use object group 60 because it is not specific enough to identify the data in the response. Instead, the outstation’s response shall contain specific group identifiers for each of the different data types in the message. As an example of an outstation’s response resulting from a request for data from group 60, variation 1, the device sends object headers with group 1, binary input data, and group 30, analog input data; each object header is followed by the respective data-filled objects. 4.2.2.7.2

Object variation

The object variation specifies the data format of DNP3 objects. For example, variations exist for reporting the current value of analog inputs as 16-bit integers, 32-bit integers, short floating-point quantities, and long floating-point quantities; the integer types may include an additional flag octet. Each alternative format has a unique variation number. The object group and object variation together uniquely specify the structure of a DNP3 object and the type of data that it references. 4.2.2.7.2.1

Variation 0

Variation 0 has special meaning, and only master requests may use it. Variation 0 indicates that the master does not have a preferred format for the outstation to use in its response—the outstation may determine which object variations to return. For example, when the master issues a request for analog inputs, group 30, variation 0, to outstation ABC, the response returned might contain group 30 objects formatted per variation 2, 16-bit value with flag (3 octets). And if the same request were issued to outstation DEF, it might respond with group 30 objects formatted per variation 1, 32-bit value with flag (5 octets). NOTE 1—It is suggested that outstation designers provide configuration for setting which variations are reported in responses when the master request specifies variation 0.

It is permissible for individual indexes of an object group to have different variations in a response when the master request specifies variation 0. It is not necessary for the outstation to transmit the identical variation for all of the objects having a common group number. Masters that use variation 0 shall be prepared to accept, as a minimum, all of the specific variations declared for the DNP3 implementation level that they support. See Clause 14 for more details. NOTE 2—From this point forward, this document uses the shorthand notation “gNNvMM” for referencing specific objects by group and variation number. gNN stands for object group NN, and vMM stands for object variation MM. As an example, g12v1 means group 12, variation 1.

4.2.2.7.2.2

Variations other than Variation 0

If the master requests a specific object variation other than Variation 0, the outstation shall report the data formatted as specified by the request, except as follows: ⎯ If the outstation does not support the requested object variation, the outstation shall set IIN2.1 [OBJECT_UNKNOWN] or IIN2.2 [PARAMETER_ERROR] in its response. See 4.5.10 for IIN2.1 details. See 4.5.11 for IIN2.2 details. ⎯ The outstation may report variations with or without flags according to the rules defined in 11.6.5. ⎯ If the request contains an event object variation, and the outstation does not have any events for the requested points, the outstation shall include neither an object header nor any event data for that object group in its response. ⎯ If the request contains only event objects, and the outstation does not have any events for the requested points, the outstation shall return a null response.




4.2.2.7.3

Qualifier and range fields

These two fields are discussed together because the structure and contents of the range field are dependent on the qualifier octet’s value (Figure 4-10).

Figure 4-10—Qualifier octet fields The qualifier octet is divided into three fields. 4.2.2.7.3.1

Res field

This field is reserved for future use. It is one bit wide and shall be set to 0 in current implementations. 4.2.2.7.3.2

Object prefix code

The object prefix code is three bits wide. It specifies what, if any, prefix value appears before each of the DNP3 objects that follow the object header. Prefixes are either an index number or an object size.

Figure 4-11—Objects prefixed Figure 4-11 illustrates objects preceded by a prefix. It is sometimes necessary to place a prefix before each of the objects to associate the object data with an index in the outstation. (Indexes were discussed in 4.1.3.1.) An example is a list of Class 1 events. The master cannot know ahead of time which input points changed state; therefore, when sending event data, it is normal for the outstation to prefix the object data with an index number. In this case, the prefix provides the information for the master to correctly correlate the new data value with a point in the outstation. At other times, when the object group and variation do not specifically imply the object size, it is necessary to place a prefix before each object giving its size. Table 4-4 enumerates the DNP3 object prefix codes. Table 4-4—Object prefix codes Code (Hex) 0 1 2 3 4 5 6 7

Description Objects are packed without an index prefix. Objects are prefixed with an index. Objects are prefixed with an index. Objects are prefixed with an index. Objects are prefixed with an object size. Objects are prefixed with an object size. Objects are prefixed with an object size. Reserved for future use.

Size of object prefix — 1-octet 2-octet 4-octet 1-octet 2-octet 4-octet —




In some cases, such as reading a list of non-sequential binary input points, the master needs to convey a list of point indexes to the outstation; there are no real data-filled objects for the master to transmit. In this circumstance, the master uses object prefix code 1, 2, or 3 and sends “null objects” (having zero octets) prefixed by a point index. This appears in the request as an object header followed by a list of point indexes. See Figure 4-12.

Figure 4-12—Index list In other situations, data is from contiguous point indexes. The range field specifies a start index and stop index, and a prefix is not necessary because the index correlates to the position of the data within the response. Bandwidth is saved by not including redundant index values. Code 0 is used to specify that no prefix codes appear before the objects. 4.2.2.7.3.3

Range specifier codes

The range specifier code indicates whether a range field is used and, if so, what it contains and how large it is. Table 4-5 enumerates the range specifier codes. Table 4-5—Range specifier codes Code (Hex) 0 1 2 3 4 5 6 7 8 9 A B C D E F

Description Range field contains 1-octet start and stop indexes. Range field contains 2-octet start and stop indexes. Range field contains 4-octet start and stop indexes. Range field contains 1-octet start and stop virtual addresses. Range field contains 2-octet start and stop virtual addresses. Range field contains 4-octet start and stop virtual addresses. No range field is used. This implies all values. Range field contains 1-octet count of objects. Range field contains 2-octet count of objects. Range field contains 4-octet count of objects. Reserved for future use. Variable format qualifier, range field contains 1-octet count of objects. Reserved for future use. Reserved for future use. Reserved for future use. Reserved for future use.

Number of octets in range field 2 4 8 2 4 8 0 1 2 4 — 1 — — — —

Range specifier codes 0 through 2 Used when the DNP3 objects are packed contiguously in index order. The index of the first object shall be the start index. The index of each succeeding object shall be one greater than the preceding object’s index. The index of the last object is the stop index. When the start and stop index values are identical, the range specifies only a single object.




Range specifier codes 3 through 5 Used for specifying contiguous address locations in a vendor-specific virtual memory space. These codes are not widely used, but when a vendor implements them, they are most often used with 8-bit unsigned integer objects. See group 102 in the Object Library. The address of the first object shall be the start address. The address of each succeeding object shall be one greater than the preceding object’s address. The address of the last object is the stop address. When the start and stop address values are identical, the range specifies only a single object. Range specifier code 6 Indicates the master desires values from all of the points specified by the object group. There is no range field. Range specifier codes 7 through 9 Indicate the range field contains a count of data objects or a count of object indexes. An outstation may respond with fewer objects if a master’s request uses qualifier codes 0x07, 0x08, or 0x09 and there is a practical reason for sending a lesser number. Outstations shall interpret these qualifiers as meaning “as many as, but not more than the count appearing in the range field.” An outstation shall send at least one object if it has data of the type requested. Range specifier code 0xB Indicates the data has a variable length format that cannot be predefined for all objects of this group and variation. 4.2.2.7.3.4

Valid qualifier codes

Table 4-6 shows the codes that are permitted if both transmitting and receiving devices support them. Shaded cells show codes reserved for future use. The qualifier codes that specify a four-octet index (0x02, 0x37, 0x38, and 0x39) should never be used unless a device has more than 65 536 points. Codes specifying four-octet sizes (0x6B) or counts (0x09, 0x19, 0x29, and 0x39) should be avoided because, in practice, object sizes and counts can be described using the one or two-octet codes. Table 4-6—Valid qualifier codes Valid Qualifier Codes (Hexadecimal) Range Specifier → Object Prefix 0 1 2 3 4 5 6 7

4.2.2.7.3.5

0

1

2

3

4

5

6

7

8

9

00

01

02

03

04

05

06

07 17 27 37

08 18 28 38

09 19 29 39

A

B

C

D

E

F

4B 5B 6B

Preferred qualifier codes

Only a few of the valid qualifier codes are recommended. The matrix in Table 4-7 shows which combinations of object prefix codes and range specifier codes are preferred for the sake of interoperability between devices. 34 Copyright © 2012 IEEE. All rights reserved.



Table 4-7—Preferred qualifier codes Preferred Qualifier Codes (Hexadecimal) Range Specifier → Object Prefix 0 1 2 3 4 5 6 7

0

1

00

01

2

3

4

5

6

7

8

06

07 17

08

9

A

B

C

D

E

F

28

5B

The subset definitions only use the preferred qualifier codes in specifying which codes master and outstation devices shall support. Table 4-8 lists the qualifier codes that were chosen for the subsets and examples of their intended use. Table 4-8—Qualifier codes used by subset requirements Qualifier code (Hex)

Use in a master request

Use in an outstation response

00, 01

A single point or range of static points.

Static objects.

06

All points.

Not permitted in a response.

07, 08

A limited quantity of events. A single quantity having no index (e.g., Time and Date).

A single quantity having no index (e.g., Time and Date).

17, 28

For controls or other functions, such as reading, that request multiple objects where the indexes are non-sequential or not consecutive.

Event objects (usually one or more unrelated points).

5B

To transmit objects whose size may be unknown to the receiver (e.g., File Open).

To transmit objects whose size may be unknown to the receiver (e.g., File data).

4.2.2.7.4

Qualifier examples Qualifier 0x00 example.

EX 4-1

This qualifier is used in requests and responses when objects from contiguous indexes are desired or being transported.

Range Field in Header: 1-octet start–stop indexes.




Data Objects: Three objects are shown having the consecutive indexes specified in the range field.

Qualifier 0x01 example. EX 4-2

This qualifier is used in requests and responses when objects from contiguous indexes are desired or being transported.

Range Field in Header: 2-octet start–stop indexes.

Data Objects: Four objects are shown having the consecutive indexes specified in the range field.


This qualifier is only used in requests to indicate all points defined by the group and variation in the object header.

Range Field in Header: No range field—implies all objects. Data Objects: There are no data objects. Qualifier 0x07 example. EX 4-4

This qualifier is used in requests to indicate a limited quantity of events or a single quantity that does not have an associated index (e.g., Time and Date). It is used in a response for a single value that is not associated with an index (e.g., Time and Date).

Range Field in Header: 1-octet count of objects.




Data Objects: When requesting events, there are no objects. There is only one object in a request to write a time, and responses to time and time delay requests contain only a single object.


This qualifier is used in requests to indicate a limited quantity of events or a single quantity that does not have an associated index (e.g., Time and Date). It is used in a response for a single value that is not associated with an index (e.g., Time and Date).


Data Objects: When requesting events, there are no objects. There is only one object in a request to write a time, and responses to time and time delay requests contain only a single object.


This qualifier is used in requests for controls for one or more non-contiguous points. It is used in responses to report events or other values where indexes are not contiguous.


Count

Data Objects: Example shows three objects, each with a 1-octet index prefix.




Qualifierr 0x28 examplee. EX 4-7

This quallifier is used in n request for co ontrols for onee or more non-ccontiguous poiints. It is used iin responses to report even nts or other vallues where inddexes are not coontiguous.

Rangee Field in Head der: 2-octet cou unt of objects. Count LSB

MS SB

Data Objects: O Examp ple shows threee objects, each h with a 2-octett index prefix.

Qualifier 0x5B examplee. EX 4-8 8

This quallifier is used in n requests and responses to trransmit data w whose size mayy be unknown to the receiv ver.

Rangee Field in Head der: 1-octet cou unt of objects. Count

Data Objects: O Examp ple shows two objects, each with w a 2-octet ssize prefix. Size LSB

Object MSB B

Size of first object

4.3

LSB

Size S MSB

Contents of firsst object (size specified by preeceding field )

Obbject

LSB

MSB

L LSB

MSB

Size S of second Coontents of second oobject object o (siize specified by preeceding fieeld)

Fragmen nt rules

NOTE 1—The FIR, FIN, CON, and UNS U bits and the SEQ values inn the rules referr to contents of tthese fields in thhe applicaation control octeet.

⎯ Rule 1: DN NP3 devices that t are able to t set their maaximum transm mit fragment size larger thaan 2048 octetss shall provid de the ability to limit the ssize (via conffiguration) to a maximum oof 2048 octets. ⎯ Rule 2: Alll devices shall accept a fragmen nts as small as 2 octets. ⎯ Rule 3: Ou utstations shall be prepared to o receive fragm ment sizes of aat least 249 octtets, and masteers shall be preepared to receiv ve fragment sizzes of at least 22048 octets. 38 Copyright © 2012 IEEE. All rightts reserved.



⎯ Rule 4: Master devices shall only send requests that fit within a single fragment. Any master that is capable of sending fragments larger than 249 octets shall be configurable to restrict the maximum fragment size of all requests to 249 octets. NOTE 2— The master shall transmit fragments to each outstation that are no larger than the fragment size that the outstation can receive. NOTE 3— Whenever a master has more data to send than fits within a single fragment (such as a file transfer, setting analog deadbands, etc.), it is the master’s responsibility to formulate smaller requests and send each separately.

⎯ Rule 5: Master devices shall accept multiple fragment responses. ⎯ Rule 6: An outstation device shall be able to return all of its event and static data together, within a single response. If necessary, it shall use multiple fragments to convey the entire response. ⎯ Rule 7: Each fragment shall be individually and completely parsable. A fragment shall only contain complete DNP3 objects and not portions of an object; that is, objects may not be divided across two or more fragments. ⎯ Rule 8: The FIR bit shall be set in the fragment that begins a message. ⎯ Rule 9: The FIN bit shall be set in the fragment that ends a message. ⎯ Rule 10: A message may consist of a single fragment having both the FIR and FIN bits set. ⎯ Rule 11: Masters shall never request Application Layer confirmation; i.e., they shall not set the CON bit in request messages. This practice is obsolete. ⎯ Rule 12: Outstations that receive a properly formatted fragment with the CON bit set shall immediately respond with an Application Layer confirm message (for backward compatibility). ⎯ Rule 13: Masters that receive a properly formatted fragment with the CON bit set shall respond with an Application Layer confirm message before sending any other request message to that outstation. ⎯ Rule 14: For each new, non-retry request fragment it sends, a master shall increment the SEQ number by one count (modulo 16) from its previous request fragment. ⎯ Rule 15: The first fragment of a solicited (polled) response message shall have the same SEQ number as the SEQ number in the request fragment. If the response requires multiple fragments, each subsequent fragment shall use a SEQ number incremented by one count (modulo 16) from the previous. ⎯ Rule 16: A master may send a retry request message if it uses the same SEQ number and all the other octets in the retry message match the original request message. There are exceptions where retries are prohibited, namely, if the request includes 1) Function codes DIRECT_OPERATE or DIRECT_OPERATE_NR—see 4.4.5 for more information. 2) Function codes DELAY_MEASURE or RECORD_CURRENT_TIME—see 10.3.4. 3) Function code WRITE with an Absolute Time object, g50v1, or with a Last Recorded Time object, g50v3—see 10.3.4. ⎯ Rule 17: An outstation shall not retry sending solicited response messages. (This requirement does not affect the Data Link Layer, which may retry Data Link frames if appropriate.) An outstation may retry sending unsolicited response messages—refer to the rules in 4.6.6. ⎯ Rule 18: A fragment containing a CONFIRM function code shall use the same SEQ number and UNS bit state as are in the fragment being confirmed. ⎯ Rule 19: Outstations shall ignore the SEQ number in broadcast request messages. 39 Copyright © 2012 IEEE. All rights reserved.



⎯ Rule 20: The T SEQ numb bers sent by an n outstation in unsolicited ressponses are diistinct from, annd have no relaationship to, th he SEQ numberrs it sends in soolicited responnses. ⎯ Rule 21: An A outstation th hat sends unsollicited responsses may choosee any SEQ num mber for its firrst message affter a restart. The T master shaall accept thesse messages. (There are addditional rules fo for devices thaat send unsoliccited messages in 4.6.6, buut briefly, an ooutstation’s innitial unsoliciteed response affter a restart shaall be a null message that doees not include any DNP3 objjects and has thhe IIN1.7 [DEVICE_RESTA ART] bit set.) ⎯ Rule 22: An A outstation th hat restarts shaall ignore the SEQ number in the first reqquest it receivees from a masster after the reestart but otheerwise shall exxecute the requuest. Thereafteer, the outstatioon should exam mine the SEQ numbers n in thee received requuests. ⎯ Rule 23: An A outstation sh hall request an Application L Layer confirmaation when it sends a fragmennt containing event objects. Receipt of thee confirmation message from m the master leets the outstatioon ormation arrived at the masster and, thereefore, that the outstation maay know that the event info discard corrresponding eveent data from itts event buffer s. NOTE 4—Itt is important to o differentiate event e data from m event objectss. An event is tthe occurrence of something significant happen ning, and event data is the inforrmation that is reetained in the ouutstation regardinng n outstation uses event data to create c event objjects that are traansmitted in respponse messages to an event. An the master. Only O after confirm mation may the outstation discarrd the corresponnding event dataa.

⎯ Rule 24: An A Application n Layer confirm mation is requuired for each fragment of a multi-fragmennt message ex xcept the last frragment. Appliication Layer cconfirmation iss optional for tthe last fragment of a multi-ffragment message unless theere is another rreason why connfirmation is m mandatory, succh as the last fragment f contaains events. Reeceipt of the coonfirmation siggnifies to the ooutstation that it may send th he next fragmeent. It also info orms the outstaation that it cann safely discardd any event daata in the conffirmed fragmeent. Outstation ns shall not seend the next ffragment of a multi-fragment response un ntil the master confirms c the ou utstation’s prevviously transm mitted fragmentt. ⎯ Rule 25: Application A Layer L confirmaation is requirred to acknow wledge receiptt of unsoliciteed response messages. m An outstation o shalll not discard any informatiion or make aany assumptionns about what the master received if it doess not receive a confirm messaage from the m master. ⎯ Rule 26: Outstations O are sometimes reequired to requuest Applicatioon Layer conffirmation after a master send ds a broadcastt request. The particular brooadcast addresss that the maaster uses in thhe message determines the need for confirm mation. See 4.55.1 for details.

4.4

Detailed function co ode procedures

This subclause s contaains implemen ntation informaation, rules, andd recommendaations for eachh of the functioon codes.. See 4.7 for informatiion on which functions fu must be supported aas broadcast fuunctions. 4.4.1 Function code c 0 Confirrm A masster sends a meessage with thiss function codee to confirm reeceipt of a response fragment. An Ap pplication Layer confirmation message is a very brief meessage. It conssists of the appplication contrrol octet and a the function code octet. There T are no ob bject headers o r DNP3 objectt octets. Masters only send co onfirmation meessages when outstations o requuest them. An ou utstation requeests the masterr to confirm the t receipt of a fragment byy setting the CON bit in thhe application control header. h See 4.2.2.4.3. 40 Copyright © 2012 IEEE. All rightts reserved.



A masster is obligateed to confirm messages m that it receives witth the CON bitt set in the appplication contrrol headerr. Refer to the rules in 4.3 for when outstations o shou uld request a c onfirmation. 4.4.2 Read

Function code c 1 (0x01 1)

The READ R function code is the basic code used by b a master to rrequest data frrom an outstation. The object o headers in the requestt specify whicch data the maaster desires aand/or how maany objects annd sometiimes what forrmat to use in n the response. A request m message may ccontain more tthan one objeect headerr, thereby effecctively combin ning several req quests into a sinngle message. Respo onses contain zeero, one, or mo ore object head ders; each objeect header is folllowed by its rrespective DNP P3 objectts. The geeneral formats of read requesst and responsee messages aree shown in the following disccussion. To keeep the diaagrams simple,, a single fragm ment response is i assumed. ⎯ AC is the Application A Con ntrol octet. ⎯ FC is the Fu unction Code octet. o ⎯ IIN1,2 repressents the Intern nal Indication octets. o ⎯ OHx is the xth Object Head der (shown shaaded). ⎯ DIOxy is thee yth Data Inforrmation Objectt associated wiith the xth objecct header. ►►► ► Request Messsage AC

FC C

OH1

OH2

•••

OHn

DIO O11

DIO12

•••

DIO O1i

DIO On1

DIOn2

•••

DIO Onk

◄◄◄ ◄ Response Message M (beginn ning) AC

FC C

IIN1,2

OH1

OH2

D DIO21

DIO222

◄ Continuation n of Response Message M ◄◄◄ ••• 4.4.2.1

DIIO2j

•••

OHn

Read Ru ules

⎯ Rule 1: Iff an outstation n is waiting for f an Appliccation Layer cconfirmation tto a previously transmitted solicited resp ponse message (because thee master requuested a read), and instead it n request of any kind, the outstation o shalll receives a new 1) Assum me the confirmaation is not fortthcoming. 2) Retain the event data. 3) Cancel the previous trransaction. 4) Processs and respond to the new reequest as if theere were no Appplication Layyer confirmatioon outstan nding. This ensurees that control operations an nd other vital ffunctions receiive priority ovver pending reaad operations. It also guaranttees that the maaster retains coontrol over pollling sequencess. 41 Copyright © 2012 IEEE. All rightts reserved.



⎯ Rule 2: An outstation shall delay formulation and transmission of a response when it receives a request having a READ function code while awaiting an Application Layer confirmation to a previously transmitted unsolicited response message. This requirement is necessary to prevent the outstation from prematurely removing events from its buffers. See 4.6.6 and 4.6.7 for detailed requirements and examples. ⎯ Rule 3: Only the events requested shall be returned in a response. For example, if only Class 1 and Class 2 events are requested, the outstation shall not include Class 3 events in the response. NOTE 1—Be aware that it is possible to report events out of order if an outstation assigns some binary input events to Class 1 and others to Class 2, as an example, and the master polls for only Class 1 or only Class 2 events. This is because events in the non-polled class may have been generated at an earlier time than those reported in the polled class.

⎯ Rule 4: An event should be reported only once within a response. If an event happens to meet the criteria appearing in two or more request objects, only report the event once—do not duplicate it. NOTE 2—Multiple events can originate from the same point. For example, a binary input changes from 0 to 1 and then within milliseconds changes from 1 back to 0. In this example, two different events would have been generated and both may be included in the same response. Rule 4 applies to a single event.

⎯ Rule 5: If event data is requested, the outstation shall place it in the response ahead of any static data values that were also requested in the same request. ⎯ Rule 6: A master shall process each DNP3 object returned in a response in the order that it appears in the received fragment. This causes the sequence of changes appearing in the master’s database to correspond to the sequence order observed in the field, and the final state of each database point should contain the most recently occurring event state. See 5.1.5.1 for additional details. 4.4.2.2

Examples

A few specific examples follow. These show a tiny fraction of all possible read requests and responses; their purpose is to illustrate various features of the protocol. Only enough details of the actual DNP3 objects are given in the examples to help the reader understand the concepts. Complete details are provided in Annex A. Message octet contents are shown in hexadecimal in the rows immediately below the gray lines.

EX 4-9

This example shows a request for the static analog values from indexes 4 through 7 returned as a 16-bit value with a flag octet.

►►► Request Message C3 AC

01 FC

1E Grp

02 Var

00 Qual

04 Range

07

1E Grp

02 Var

00 Qual

◄◄◄ Response Message (beginning) C3 AC

81 FC

00 IIN1

00 IIN2

04 Range

07

01 Flg4 ←

88 LSB4 DIO4




◄◄◄ Continuation of Response Message 13 01 MSB4 Flg5 →←

20 LSB5 DIO5

4E 01 MSB5 Flg6 →←

50 LSB6 DIO6

FB 01 MSB6 Flg7 →←

60 LSB7 DIO7

00 MSB7 →

In the example, all the flag octets indicated an on-line status and no exceptions or errors. Therefore, because the absence of a flag is equivalent to on-line and no exceptions, the following response is just as valid. ◄◄◄ Response Message (beginning) C3 AC

81 FC

00 IIN1

00 IIN2

1E Grp

04 Var

00 Qual

04 Range

07

88 13 LSB4 MSB4 ← DIO4 →

◄◄◄ Continuation of Response Message 20 4E 50 FB 60 00 LSB5 MSB5 LSB6 MSB6 LSB7 MSB7 ← DIO5 → ← DIO6 → ← DIO7 → Because all the flags would indicate an on-line status and no exceptions or errors, it is permissible to omit the flag octets. The variation number was changed from 02 to 04. The message without the flag octets is four octets shorter—a 20% savings in this example!

EX 4-10

This example shows a request for all of the static binary inputs. Assume there are 18 binary inputs.


01 FC

01 Grp

01 Var

06 Qual

Note that no range field appears when the qualifier 06 is specified; it means values from all points. ◄◄◄ Response Message (beginning) C3 AC

81 FC

00 IIN1

00 IIN2

01 Grp

01 Var

01 Qual

00 Range

11

0F ←

AA States

◄◄◄ Continuation of Response Message 03 → The states of the first eight binary inputs appear in the first value octet. In this example, the first octet contains 0F, which means that the state is 1 for indexes 0 through 3, and that the state is 0 for indexes 4 through 7. The states of indexes 8 through 15 alternate between 0 and 1. The last two states, indexes 16 and 17, are 1’s. The remainder of the last octet is padded with six 0 bits to complete the octet. NOTE 1—Qualifier 06, meaning all objects, cannot be used in a response because there would not be enough information to explicitly identify the indexes to the receiver.




EX 4-11

This example illustrates a request to read Class 1 and Class 2 event data. Event data is requested with object group 60.


01 FC

3C Grp

02 Var

06 Qual

3C Grp

03 Var

06 Qual

The reader should note that this is a multiple-object request because more than one object header appears in the request, namely a Class 1 and a Class 2 object header. NOTE 2—Only qualifiers 06, 07, and 08 may be used to request events because the requester does not know which indexes have events until the response is returned. Qualifier 06 specifies to send all of the events, and qualifiers 07 and 08 specify the maximum number of events to place in the response—fewer events may be returned if the outstation has less than the quantity requested. NOTE 3—While qualifier 09 is valid, it should be avoided—see 4.2.2.7.3.4.

The response, in this example, returns 3 binary input changes and 1 analog value change. Binary input events from indexes 3 and 20 are from Class 1, binary input from index 5 is from Class 2, and analog input 11 is from Class 2. (The index assignments are arbitrarily for use with this example only.) ◄◄◄ Response Message (beginning) E3 AC

81 FC

06 IIN1

00 IIN2

02 Grp ←

01 17 Var Qual 1st Event

01 Range

14 Index

81 02 Value Grp →←

01 Range

0B Index

◄◄◄ Continuation of Response Message 01 17 Var Qual 2nd Event

01 Range

05 Index

01 20 Value Grp →←

02 17 Var Qual 3rd Event

20 Flg

◄◄◄ Continuation of Response Message FF Value

FF

02 Grp →←

01 17 Var Qual 4th Event

01 Range

03 Index

81 Value →

There are four things worth noting in this response. The first is that the response does not identify the event class. The second is that bit 5 is set in the application control octet; this directs the master to send an Application Layer confirmation message back upon receipt of this response. NOTE 4—Outstations should request Application Layer confirmation in all responses that contain event data. When a confirmation with the same sequence number is received from the master, then event data for the events that were transmitted can be removed from the outstation’s buffers.

The next issue of note is that the events are not sent in class or index order. See 5.1.5.1 for the details of event reporting order requirements. In general, events are returned in the order that they occurred to permit 44 Copyright © 2012 IEEE. All rights reserved.



the master to reconstruct the history and proper ordering of states and values. The reader should notice that in this example, the event variations did not include time stamps. The fourth observation is that the response could have used a single object header for the first and second event. The same group, variation, and qualifier were used, the range could have specified two objects, and the second header could have been omitted. Outstation devices with enough computing power are encouraged to optimize the responses, when possible, to conserve bandwidth. ►►► Confirm Message C3 AC

00 FC

Rule 3 in 4.4.2.1 puts the onus on the master to formulate requests properly so that its application software receives the required information. If the outstation in the previous example had had a Class 3 event that occurred prior to the other events in the response, it would not have been transmitted because only Class 1 and Class 2 events were requested. Therefore, the master could not know that the Class 3 event occurred first.

EX 4-12

This example shows the master requesting a maximum of 20 binary events. When a master requests event data using a group number other than 60 (class data), as this example does, it expects to receive events from the respective point type without regard to the event class assignments for any of those points.


01 FC

02 Grp

00 Var

07 Qual

14 Range

The request uses variation 0. Variation 0 has special meaning, and only master requests may use it. Variation 0 indicates that the master does not have a preferred format for the outstation to use in its response—the outstation determines which object variations to return. ◄◄◄ Response Message (beginning) E3 AC

81 FC

06 IIN1

00 IIN2

02 Grp

01 Var

17 Qual

03 Range

14 81 Index Value 1st Event

05 Index 2nd

◄◄◄ Continuation of Response Message 01 Value Event

03 81 Index Value 3rd Event

This response is somewhat similar to the previous example’s response, but this only contains binary input events and no analog input events. It also uses a common object header for efficiency. The same requirements for time sequence order apply. If there had been a binary input event in Class 3, it too would have appeared. It is worth noting that even though the master requests a specific count of events, the count represents a maximum number, and it is acceptable to return less if the outstation does not have the requested number of events. Refer to 4.2.2.7.3.3 for more details when range qualifier codes 0x07, 0x08, and 0x09 are used. 45 Copyright © 2012 IEEE. All rights reserved.



►►► ► Confirm Message C3 AC

EX 4-13

00 0 FC C

This example illustratees returning wh hat is called a “null responsse” because noo data objects are included.. Outstations seend null respon nses when the master requessts events and nno events quallify for reporting back in a response. r

►►► ► Request Messsage C3 AC

01 C FC

02 Grp

00 Var

07 Quaal

14 Range

vious example’s request. This reequest is identiical to the prev ◄◄◄ ◄ Response Message M C3 AC

81 C FC

04 IIN1

00 IIN2

This is the null resp ponse. There were w no binary y events, and nnone were repported so onlyy the applicatioon contro ol octet, functio on code octet, and a internal ind dications octetts were reported. It is still posssible for analoog input events e to exist,, but because th hey did not quaalify accordingg to the requestt (namely binarry input eventss), they cannot appear in n the response.. NOTE 5—A null resp ponse consists off only the applicaation control, fuunction code, andd internal indicattions octets.

Also observe o that an n Application Layer L confirmaation was not rrequested in thhe response (i.ee., bit 5 was not set). The T outstation does not requ uire confirmation because it does not discaard any eventss from its event bufferr(s). 4.4.3 Write

Function code c 2 (0x02 2)

The WRITE W functio on code is com mplementary to o the READ fuunction code. W Writing copiess the contents oof DNP3 objects from m the master to the outsttation. Some uses for writting are clearring bit IIN1.7 RT], setting tim me in the outstation, setting analog deadbband values, annd downloadinng [DEVIICE_RESTAR config guration files. The object headers in the request specify which h objects the m master desires to write. The respective daata mation objects follow f each ob bject header. inform In most, but not all cases, c write ressponses are nu ull responses (ii.e., they only ccontain the appplication contrrol octet, function code octet, and interrnal indications octets). Writiing file data is one of the excceptions. The geeneral formats of write requeest and response messages aree shown as folllows. ⎯ AC is the Application A Con ntrol octet. ⎯ FC is the Fu unction Code octet. o 46 Copyright © 2012 IEEE. All rightts reserved.



⎯ IIN1,2 represents the Internal Indication octets. ⎯ OHx is the xth Object Header. (These are shown shaded.) ⎯ DIOx is the xth Data Information Object. ►►► Request Message (beginning) AC

FC

OH0

DIO0

DIO1

•••

DIOi

DIO1

•••

DIOk

OH1

DIO0

DIO1

•••

►►► Continuation of Request Message DIOj

•••

OHn

DIO0

◄◄◄ Response Message AC 4.4.3.1

FC

IIN1,2

Rules

⎯ Rule 1: Masters shall not retry write request messages at either the Application or Data Link Layers for time synchronization where the messages contain either an Absolute Time object, g50v1, or a Last Recorded Time object, g50v3. For more information, see 10.3.4. 4.4.3.2

Examples

This subclause provides a few write examples.

EX 4-14

This example shows a master clearing an outstation’s IIN1.7 [DEVICE_RESTART] bit.


02 FC

50 Grp

01 Var

00 IIN1

00 IIN2

00 Qual

07 Start Range

07 Stop

00 Value

◄◄◄ Response Message C3 AC

EX 4-15

81 FC

This example shows setting analog deadbands for indexes 6, 8, and 20.


02 FC

22 Grp

01 Var

17 Qual

03 Range

06 12 Index Value ← DIO6

00

08 4A Index Value → ← DIO8




►►► ► Continuation n of Request Message M 00 14 4 FF Value Ind dex Value → ← DIO20

FF →

◄ Response Message M ◄◄◄ C3 AC

EX 4-16

81 C FC

00 IIN1

00 IIN2

This exam mple shows setting the time.


02 2 FC C

32 Grp

01 Var

07 Quaal

01 Range

AC Time

E9

00

440

08

► Continuation n of Request Message M ►►► 01 Time ◄ Response Message M ◄◄◄ C3 AC

81 C FC

00 IIN1

00 IIN2

4.4.4 Function codes c 3 (0x0 03) and 4 (0x04) Selectt and Operate The SELECT functiion code is useed in conjunctiion with the O OPERATE funnction code as part of the twoos operate method d for issuing control requessts. This proccedure is used for controllinng step, select-before-o binary y11 and analog outputs. o Requeests with these function codees contain onee or more objeects that descriibe the desiredd output state oor level. An ou utstation’s selecct and operate responses con ntain the identiical set of objeect headers andd objects, and in the sam me order as th hey appear in the t master’s reequest, unless tthe outstation determines ann error conditioon exists.. In the case off an error, an outstation o sets a status code w within an objecct, possibly om mits objects from the ressponse, and/or sets IIN bits ass described elsewhere in this standard. 4.4.4.1

Select–o operate philo osophy

The general select–o operate proced dure is for the master to firstt send a selectt request contaaining all of thhe ndexes, timing gs, and valuess. The select response from m the outstatioon necesssary parameterrs, such as in contains object head ders and objects that exactly match m those inn the request. T The master com mpares the seleect 11

Somee output objects in the Object Librarry are not suitable for use with selecct–operate functionn codes because thhey do not providee a means for f reporting errorss. An example is a g10 v1.




response with the request, and if they match exactly, then the master issues an operate command with the identical object set of headers and objects that it sent in the select message. This approach assures, with miniscule probability of error, that the outstation understands which control the master intended. There are two verifications during a complete, two-step procedure: ⎯ The master receives a select response that matches the request, and that response indicates no errors; otherwise, the master shall abort the control. ⎯ The outstation is obligated to compare the operate request with the select request, and only if the two match, and there are no errors detected in the request, should it activate the outputs. 4.4.4.2

Multiple control objects

Select and operate requests may contain multiple objects if the outstation supports having multiple control objects in the same request. For example, it is permissible to send two or more CROBs, g12v1, in select and operate messages, or two or more analog output blocks (AOBs), group 41, any variation, may appear in select and operate messages. 4.4.4.2.1

CROBs and AOBs

Whenever the master sends select–operate commands with multiple objects, it is intended that the outstation shall execute them expeditiously. The master should not assume the points are executed simultaneously or in sequential order as the implementation details are private to the outstation. Although some outstations may be capable of executing the controls simultaneously, others cannot and shall queue the objects for execution one-after-the-other. Outstations are not required to support more than one DNP3 control object per request message. NOTE—The number of CROBs and AOBs that an outstation can accept in one message should be listed in its Device Profile. A statement should also appear in the outstation’s Device Profile indicating whether CROBs and AOBs are permitted in the same request.

4.4.4.2.2

Pattern Control Blocks and Masks

If the master desires simultaneous execution of controls, it should use Pattern Control Block and Pattern Mask objects, g12v2 and g12v3, respectively. For multiple controls to execute simultaneously, a Pattern Control Block and Pattern Mask shall be used, and the outstation must support this type of operation. Devices are not required to implement Pattern Control Blocks, g12v2, or Pattern Masks, g12v3. The device’s Device Profile shall indicate whether they are supported. 4.4.4.3

Control-related rules

⎯ Rule 1: Outstations shall start a selection timer upon receipt of a valid select request. If that timer times out prior to receiving a valid operate request, the outstation shall reject the operate request and return a status code indicating the timer is expired. ⎯ Rule 2: An outstation shall compare all of the octets following the function code octet in the operate request with all of the octets following the function code octet in the select request. The outstation shall only activate, or queue for operation, the specified point or points if the octets match exactly, and in its response to the corresponding select request, the outstation would not: 1) Return a non-zero status code in any of the objects. 2) Set IIN bit 2.0 [NO_FUNC_CODE_SUPPORT]. 3) Set IIN bit 2.1 [OBJECT_UNKNOWN]. 4) Set IIN bit 2.2 [PARAMETER_ERROR]. 49 Copyright © 2012 IEEE. All rights reserved.



5) Set IIN bit 2.4 [ALREADY_EXECUTING]. ⎯ Rule 3: If an outstation returns a non-zero status code in any object in its response to a select request, the outstation shall cancel the entire selection. ⎯ Rule 4: If a selection is in effect at the outstation, upon receipt of the next request, the outstation shall perform the action as listed in Table 4-9 depending on the function code and sequence number in the application control octet. Keys for understanding table: ⎯ N is the sequence number from the SEQ field in application control octet of the original selection message. ⎯ != means “Not Equal To”; e.g., !=N means the sequence number is not equal to N. Table 4-9—Action to perform with next request after a select request Next request contains Request function code

Sequence number modulo 16

Octets in the message after the function code octet match those in the original select request

Outstation action

select

N

Yes

This is a valid retry. Repeat the response to the original select request—do not restart the selection timer.

select

N

No

Discard fragment. Take no further action.

select

!=N

No

This is a new selection that overrides the current selection. Terminate the original selection, initiate a new selection, and restart selection timer.

operate

N+1

Yes

Check for other errors or other discrepancies, and if none are found, initiate the control execution.

operate

N+1

No

Non-matching octets. Terminate original selection and perform no control action.

operate

!=(N + 1)

Don’t Care

Improper sequence number. Terminate original selection and perform no control action.

Neither select nor operate

Don’t Care

Don’t Care

Operate did not follow select. Terminate original selection and perform no control action.

⎯ Rule 5: When multiple control objects are included in select and operate messages, the outstation has the option to stop parsing the remainder of a request upon detection of the first error or continue to the end of the request. ⎯ Rule 6: When an outstation receives a select or operate request, and operations to one or more of the points specified by the objects in the request are unsuccessful, its response shall include one of these: 1) No DNP3 objects if the request contains an unsupported function code or object variation. 2) All of the DNP3 objects. 3) Only objects for all of the points up to and including the first unsuccessful point. This is called a “truncated response.”




⎯ Rule 7: Each DNP3 object returned in the response shall contain the appropriate status code indication. The IIN bits 2.0, 2.1, 2.2, and 2.4 shall be set or cleared as applicable. If an error is reported, the IIN bits only need to reflect the state of the first error detected. ⎯ Rule 8: A master shall compare all of the octets following the two IIN octets in the select response with all of the octets following the function code octet in the request. If the octets do not match exactly or if any of the following conditions are true, then the master shall not issue the matching operate command: 1) the status code returned in any object is non-zero, 2) IIN bit 2.0 [NO_FUNC_CODE_SUPPORT] is set, 3) IIN bit 2.1 [OBJECT_UNKNOWN] is set, 4) IIN bit 2.2 [PARAMETER_ERROR] is set, 5) IIN bit 2.4 [ALREADY_EXECUTING] is set, The DNP3 requirements were less strict in older versions of the specifications. For the sake of backward compatibility, the outstation has two options if a master illegally issues an operate command after receiving an outstation’s select response in which the response had missing objects (truncated response; see Rule 6), non-zero status codes, or IIN bits 2-0, 2-1, 2-2, or 2-4 set. The outstation may ⎯ Choose to ignore the request and not operate any of the outputs. ⎯ Execute those points for which it returned objects with a zero status code. The outstation’s behavior is not guaranteed when the master violates Rule 8. ⎯ Rule 9: The master shall not retry the select–operate sequence in its entirety. If the select portion succeeds but the operate portion fails, a master shall not retry the select- operate requests as this can result in duplicate controls. The definition of a select–operate retry is sending select and operate requests using the same sequence numbers in the application control octet as were in the select and operate requests of the failed attempt. If a repeated operation is acceptable or desired, the master should send similar, but new messages with the sequence numbers properly incremented. 4.4.4.4

Examples This example shows select–operate messages for a CROB (g12v1) issued to point 10. The command is to close the point one time for 250 milliseconds.

EX 4-17

In the first exchange, the master sends a request with the SELECT function code. ►►► Select Request Message (beginning) C3 AC

03 FC

0C Grp

01 Var

17 Qual

01 Range

0A Prefix

00

00

41 ←

01 FA CROB

00

►►► Continuation of Select Request Message 00 00 00 CROB continued

00

00

→




◄◄◄ Select Response Message (beginning) C3 AC

81 FC

00 IIN1

00 IIN2

0C Grp

01 Var

17 Qual

01 Range

0A Prefix

00

00

00

00

41 ←

01

◄◄◄ Continuation of Select Response Message FA 00 CROB

00

00

00

→

The octets in select response message after the IIN octets match the octets in the select request after the function code. This is the expected response; therefore, the master may send an operate request message. ►►► Operate Request Message (beginning) C4 AC

04 FC

0C Grp

01 Var

17 Qual

01 Range

0A Prefix

00

00

41 ←

01 FA CROB

00

01

►►► Continuation of Operate Request Message 00 00 00 CROB continued

00

00

→

◄◄◄ Operate Response Message (beginning) C4 AC

81 FC

00 IIN1

00 IIN2

0C Grp

01 Var

17 Qual

01 Range

0A Prefix

00

00

00

00

41 ←

◄◄◄ Continuation of Operate Response Message FA 00 CROB

00

00

00

→

The operate request message is almost identical to the select message, except the sequence number in the application control octet is incremented by one, and the function code is OPERATE. The outstation shall compare the operate and select messages, and if all of the octets following the function code octets match, it is permitted to actuate the output.

EX 4-18

This example illustrates the use of a Pattern Control Block (PCB) and a Pattern Control Mask (PCM). Points 5, 10, and 15 are activated three times, each for 500 milliseconds with a 2 second period between actuations.

In the first exchange, the master sends a request with the SELECT function code. Notice that the PCB appears first in the message, and the PCM follows it. ►►► Select Request Message (beginning) C3 AC

03 FC

0C Grp

02 Var

07 Qual

01 Range

41 ←

03 PCB

F4

01

00




►►► Continuation of Select Request Message 00 D0 PCB continued

07

00

00

00

0C → Grp

03 Var

00 Qual

05 Range

0F

41 ←

03 PCB

F4

03 Var

00 Qual

►►► Continuation of Select Request Message 21 PCM

04

◄◄◄ Select Response Message (beginning) C3 AC

81 FC

00 IIN1

04 IIN2

0C Grp

02 Var

07 Qual

01 Range

00

00

04

◄◄◄ Continuation of Select Response Message 01 00 PCB continued

00

D0

07

0C → Grp

◄◄◄ Continuation of Select Response Message 05 Range

0F

This time, the control command is not issued because an error was reported in the status code of the PCB. It indicated that the index for one of the points was beyond the number configured. IIN2.2 [PARAMETER_ERROR] was also set specifying a parameter error. Notice that the PCB status code indicated the error rather than the PCM because a pattern mask does not have its own status code.

EX 4-19

Table 4-10 shows example responses from CROB or analog output requests containing four objects. These objects are identified as A, B, C and D. The responses are identical for requests having the SELECT, OPERATE or DIRECT_OPERATE function codes.

Keys: NR means Not Reported. Status codes are defined in Annex A. Some of the responses show two sets of choices for the object status codes; either is acceptable.




Table e 4-10—Exam mple status codes c and IIN N bits in con ntrol respons se R Response Condiitions in outstattion when requeest is received

S Status codes Obj A

IIN bits

O Obj B Obj C Obj D

1.5

2.0

2.1

2.2

2.4

No errors are detected; all points are succeessful.

0

0

0

0

0

0

0

0

0

The functiion code is not su upported regardlless of which indexes th he objects have.

NR

N NR

NR

NR

0

1

0

0

0

The outstaation does not su upport the specifi fic variation codee in the requ uest.

NR

N NR

NR

NR

0

0

1

0

0

choice 1 0 0

4

4

choice 2 0 0

0

0

0

1

0

4

NR

0

0 0

0

0

0

1

NR

NR

choice 1 8 0

8

8

choice 2 8 0

0

0

0

0

0

NR

NR

choice 1 0 0

9

0

choice 2 0 0

0

0

0

0

0

9

NR

choice 1 0 7

7

7

choice 2 N NR 7

1

0

0

0

0

NR

NR

A control output is requestted, and the CRO OB in object D’ss request contains an illegal control code.

0

0

0

3

0

0

0

0

0

An analog g output is requessted, and the vallue in object D’ss request ex xceeds the permittted level.

0

0

0

3

0

0

0

0

0

Indexes fo or objects C and D are beyond th he maximum number off points installed d in the outstation n.

choice 1 5 The point in object B is alrready executing when this requeest 0 arrives. choice 2 5 0 The outstaation is not able to t control more than one point at a a time.

The point in object C is tagged or blocked d to prevent its control.

The Remo ote/Local Switch h is in the Local position. p

4.4.5 Function codes c 5 (0x0 05) and 6 (0x06) Directt Operate and Direct D Operate— —No Acknow wledgment These direct operatee functions are similar to the OPERATE fuunction code eexcept that no ppreceding seleect mand is requireed. They are used for outputtting CROBs, Pattern Controol Blocks, andd analog outpuuts comm when the extra secu urity provided d by a two-steep control com mmand is not necessary. Annother use is to c con ntrol when otheer feedback is present. optimiize bandwidth utilization in closed-loop Directt operate requ uest messages look identicall to select andd operate requuest messagess except for thhe functio on code. They contain one orr more objects that describe thhe desired outpput state or levvel. Directt operate respo onses contain the t identical seet of object heeaders and objeects, and in thhe same order aas appearr in the masterr’s request unlless it determines an error ccondition existts. In the case of an error, thhe outstattion sets a staatus code with hin an object, possibly omitss objects, and/ d/or sets IIN bbits as describeed elsewh here in this stan ndard. 54 Copyright © 2012 IEEE. All rightts reserved.



The diiscussion in 4.4 4.4.2 regarding g multiple objeects applies to this function ccode. The operrate messages in the examples in 4.4.4 4.4 properly illlustrate direct operate o messagges. The reesponse to a DIRECT_OPER RATE comman nd does not verrify that execuution actually ooccurred. It onnly indicaates that the req quest was receeived. For this reason, system ms employing either of thesee function codees are encouraged to prrovide another means for deteecting that execcution did happpen. The DIRECT_OPER D RATE_NR fun nction code is similar to the DIRECT_OP PERATE function code exceppt that th he outstation do oes not send a response messsage; it does, hhowever, execuute the controll if no errors aare detected in the requeest. This functiion code is suittable for broaddcasting a contr trol request from one master to ple outstations,, where each outstation is identically i equuipped. It is im mportant to reealize that wheen multip emplo oying function code DIRECT T_OPERATE_ _NR in a requeest, there is noo direct feedbaack for assurinng that an n error-free req quest was received. There are a few ruless regarding direct operate fun nctionality: ⎯ Rule 1: Ev very master an nd outstation device d that suppports a direcct operate operration shall alsso provide sup pport for the seelect–operate operation. o Thiss allows the syystem owner orr user to choose the security y level appropriiate for the insttallation. ⎯ Rule 2: A master m shall neever retry send ding a messagee with a DIRE ECT_OPERAT TE function codde as this can result in dupliccate control acctions when, unnknown to thee master, an ouutstation restartts. The definitiion of a retry is a repeated reequest having tthe same sequeence number inn the applicatioon control octeet as the previous request. Iff a repeated opperation is accceptable or dessired, the mastter should send d a similar, but new, messagee with the sequeence number pproperly increm mented. 4.4.6 Function codes c 7 (0x0 07) and 8 (0x08) Immed diate Freeze an nd Immediate Freeze—No F Acknowledgmennt The pu urpose of this function is to copy c the curreent value of a ccounter or anallog point to a ssecond, separaate memo ory location asssociated with the t same point. The copied value is referrred to as the fr frozen value annd remain ns constant un ntil the next frreeze operation n to the samee point. These commands doo not affect thhe curren nt values of thee counter or anaalog points. NOTE— —Broadcast freeze commands can c be used to ob btain time synchhronized readinggs throughout an entire system.

For th he IMMED_FR REEZE functio on code, the reesponse is a nuull response. For the IMMED D_FREEZE_N NR functio on code, no response r is seent, and for th his reason, thhe IMMED_FR REEZE_NR fu function code is recom mmended for brroadcast freezin ng. 4.4.6.1

Objects in freeze req quests

Annex x A contains two point types that are freezzable, counterss and analog iinputs. Althouggh an outstatioon devicee is not requiired to have freezable f poin nts, some DNP P3 implementtation levels rrequire that thhe outstattion be able to parse freeze messages. m Freezee requests are sent s using objeect headers for the current vallue object grouup (20 or 30). F Frozen, snapshhot valuess are read using g object headeers for the frozzen object grouup (21 or 31). N Note that the oobject groups in freeze commands aree different than n the object gro oups used to reead the frozen vvalues. The ob bject variation n for all points specified in a freeze requesst is always zeero because frreezing does nnot apply to any particullar data format and no DNP3 objects are retturned in the reesponse.




4.4.6.2 EX 4-2 20

Example es In this ex xample, a master requests thee outstation to ffreeze all of itss counters.


07 7 FC C

14 Grp

00 Var

00 IIN1

00 IIN2

06 Quaal


81 C FC

4.4.7 Function codes c 9 (0x0 09) and 10 (0x x0A) Freezee-and-Clear and Freeze-and-C Clear—No Ack knowledgmentt These function codees are similar to t function co odes IMMED__FREEZE and IMMED_FRE EEZE_NR in aall respeccts except that after copying the current vaalue to the froozen value, thee current valuee is immediately cleared d to 0. An example is a cou unter that accum mulates pulses and is frozen aat periodic tim me intervals. At each freeze, thhe a resumes itts counting fro om zero. In ann electrical syystem, if the ccounts represent counteer is cleared and energy y, then the frozzen value repreesents demand. In a water sysstem, if the couunts represent vvolume, then thhe frozen n count represents a flow rate. For function f codee FREEZE_C CLEAR, the response is a null ressponse. For function codde FREEZE_CLEAR_N NR, no respon nse is sent, and d for this reasoon, function code FREEZE__CLEAR_NR is mmended for brroadcast freezin ng. recom See 4.4.6.1 regarding g which objectts appear in req quests with thesse function coddes. 4.4.8 Function codes c 11 (0x x0B) and 12 (0x0C) ( Freezee-at-Time and Freeze-at-Time—No Acknow wledgment These function codees initiate periiodic freezing of the specifiied points. Thhe request messsage contains a wed by object header(s) for the point(s) thhat Time-Date-and-Interrval object heaader and objectt, g50v2, follow M sched dules may be ssent in the sam me request. Upoon receipt of thhis are to obey the freezzing schedule. Multiple ms the freeze ooperations accoording to the schedule without type reequest, an outsstation automaatically perform furtherr commands from f the masteer station. Thee schedule mayy require the ooutstation to pperform either a single freeze operatio on or an infinitte number of frreeze operationns. The reesponse is a nu ull response. See 4.4.6.1 regarding g which objectts appear in req quests with thesse function coddes. The general formatss of function code c FREEZE_ _AT_TIME orr FREEZE_AT T_TIME_NR rrequests and thhe FREEZE_AT_TIME E function cod de response messages m are shhown as follow ws. No responnse is sent with on code FREEZE_AT_TIME E_NR. functio ⎯ AC is the Application A Con ntrol octet. 56 Copyright © 2012 IEEE. All rightts reserved.



⎯ FC is the function code octet. ⎯ IIN1 and IIN2 represent the Internal Indication octets. ⎯ TDHx is the xth Time-Date-and-Interval object Header (shown shaded). ⎯ TDOx is the xth Time-Date-and-Interval DNP3 Object (shown shaded). DOHxy is the yth Data Object Header specifying a point that is to be frozen according to schedule in the xth Time-Date-and-Interval object. ►►► Request Message (beginning) AC

FC

TDH0

TDO0

DOH00 DOH01 • • •

DOH0i TDH1

TDO1

DOH10

►►► Continuation of Request Message DOH11 • • •

DOH1j

◄◄◄ Response Message AC

FC

IIN1

IIN2

A Time-and-Date-with-Interval DNP3 object has a time-date field and an interval field. These two fields are used in a binary code-like scheme to indicate when to freeze the points. This is shown in Table 4-11. Table 4-11—Freezing schedule interpretation Time-date field

Interval field

Freeze timing

zero

zero

Freeze once immediately.

non-zero

zero

Freeze once at the specified time.

non-zero

Periodically freeze at intervals relative to the beginning of the current hour. Use the time interval from the interval field. Continue freezing forever or until a new function code FREEZE_AT_TIME or FREEZE_AT_TIME_NR freeze request is received.

non-zero

Periodically freeze at intervals relative to the time and date in the time-date field. Use the time interval from the interval field. Continue freezing forever or until a new function code FREEZE_AT_TIME or FREEZE_AT_TIME_NR freeze request is received.

zero

non-zero

NOTE—To cancel a freeze request, set the time-date field to all ones.

EX 4-21

This is an example of freezing all counters beginning on 15 June 2001 at 14 hours, 2 minutes, 0 seconds, and 0 milliseconds, and every 15 minutes thereafter.

►►► Request Message (beginning) C3 AC

0B FC

32 Grp

02 Var

07 Qual

01 Range

C0 ←

5F 63 1C E7 Time & Date w/ Interval Object

00 Var

06 Qual

►►► Continuation of Request Message 00 A0 BB 0D T & D w/ Intvl Obj Continued

00

14 → Grp 57




◄◄◄ ◄ Response Message M C3 AC

81 C FC

00 IIN1

00 IIN2

4.4.9 Function codes c 13 (0x x0D) and 14 (0x0E) ( Cold Restart R and Waarm Restart A COLD_RESTART T function cod de forces the outstation to peerform a compllete restart sim milar to what thhe on powering up p after a long-tterm power losss. Many devicces clear all outtput hardware to devicee would do upo a safe state and re-in nitialize themsselves with con nfiguration infformation and//or default valuues and clear aall queues. The specific actions perforrmed are device dependent annd not defined herein. A WA ARM_RESTAR RT function code c forces th he outstation tto perform a ppartial reset. O Only the DNP P3 application needs to reset, and no affect a to other subsystems annd processes wiithin the outstaation is requireed. P3 application n with configurration informattion and/or default values annd Some devices re-inittialize the DNP a event and control queuees. When pracctical, control operations in progress are tterminated. Thhe clear all specifi fic actions perfo ormed are deviice dependent and a not definedd herein. When an outstation receives a colld restart or warm w restart rrequest, it shalll immediately respond with a d then initiate its restart acttivities. The deelay time in thhe Delay Time DNP3 object, g52v1 or g52v2, and l of time during which the outstation expects to be bbusy and unabble to respond to objectt specifies the length requessts. NOTE— —The master sh hould honor the time delay in th he response and not attempt to ssend any requests until the periood has elaapsed.

EX 4-2 22

This is an n example of a cold restart wh here the responnse indicates 45 seconds.


0D D FC C


81 C FC

00 IIN1

00 IIN2

34 Grp p

01 Var

07 Qual

01 Rangge

2D 000 Time Delaay

4.4.10 0 Function code c 15 (0x0 0F) Initialiize Data (Obso olete) This function fu code iss obsolete, and d new designs shall s not implem ment it.12 Origin nally, it was in ntended to tell the outstation n to set configuurable data to the default, oor initial startuup, setting gs. The responsse to an initialiize data requesst is a null respponse.

12

The reason r for deprecatting function codee 15 was because older o versions of thhis specification ddid not provide suffficient details aboout how to use u the function co ode or clearly define the behavior off an outstation upoon receipt of such a request.




4.4.11 1 Function codes c 16 (0x x10) and 17 (0x11) and 18 8 (0x12) Initialiize Application n and Start Application and Stop S Applicatioon These function codees initialize, staart, and stop th he application((s) specified inn the request. A Applications are nd not defined d in the DNP3 protocol. A loocal closed-looop control is aan uniquee to the outstaation device an examp ple of such an application. a Appliccations are speecified in the request r with Application A Idenntifier objects using object ggroup 90. Wheen referen ncing a specifiic application in a message, the object quaalifier octet shaall be 0x5B. Q Qualifier 0x06 is used to o specify all ap pplications with hout identifyin ng a specific onne. The reesponse messag ges for each off the three funcction codes are null messagess. The in nitialize applica ation function is optional forr an outstation application andd depends on tthe requiremennts of the specific application in the outstation. o Nev vertheless, evenn though theree may be nothhing to initializze, outstattions that havee DNP3-controllable applicatiions shall parsee and respond to this functionn. NOTE— —An alternativee to using thesee function codes is for the outsttation to implem ment pseudo-binaary control poinnts that correspond to the application. a

EX 4-2 23

This is an n example of how h to control an outstation aapplication nam med CL6. Application identiffier objects do d not have a deefined format. For this exampple, the applicaation name, “C CL6,” is used.

► Request Messsage – Initializze Application n ►►► C3 AC

10 FC

5A Grp

01 Var

5B Qual Q

1 Rangee

03 00 Size Prefix

43 ‘C’

4C ‘L’

36 ‘6’


81 C FC

00 IIN1

00 IIN2

► Request Messsage – Start Application A ►►► C3 AC

11 C FC

5A Grp

01 Var

00 IIN1

00 IIN2

5B Quaal

1 Range

03 00 Size Prefix

43 ‘C’

44C L’ ‘L

36 ‘6’

5B Quaal

1 Range

03 00 Size Prefix

43 ‘C’

44C L’ ‘L

36 ‘6’

◄ Response Message M ◄◄◄ C3 AC • • • Ap pplication

81 C FC

runn ning • • •

►►► ► Request Messsage – Stop Application A C3 AC

12 2 FC C

5A Grp

01 Var




◄◄◄ ◄ Response Message M C3 AC

81 C FC

00 IIN1

00 IIN2

4.4.12 2 Function code c 19 (0x1 13) Save Configuration C This function f speciifies that the outstation sho ould store intto non-volatilee memory thee contents of a config guration file loccated in volatille memory. When an outstation receives r a Save Configuratio on request, it shhall immediateely respond witth a Delay Tim me d then initiate itts storage activvities. DNP3 object, g52v1 or g52v2, and Functtion code SAV VE_CONFIG is deprecated d, and new deesigns shall avvoid using it.133 Function codde ACTIV VATE_CONFIG was added, and in some situations, it maay be a suitablee replacement. 4.4.13 3 Function code c 20 (0x1 14) and 21 (0x x15) Enablee Unsolicited Responses R and d Disable Unsollicited Responsses A masster uses these functions to dy ynamically enaable and disablle which pointss may, or may not, be includeed in a sp pontaneous, unsolicited respo onse. Outstaations that do not support un nsolicited responses are not obligated to im mplement thesse functions annd may ignore i the rem mainder of this subclause. Outstations thhat do supporrt unsolicited responses shaall implem ment these two o function codees. An ou utstation may only o include event e objects in n an unsoliciteed response m message from ppoints that havve been enabled e by an enable unsollicited responsses request. Evvents that werre generated bbefore a point is enableed shall not bee reported in unsolicited u resp ponses until affter the point iis enabled andd if those evennts have not n already beeen read and con nfirmed by a master m poll (soliicited request, response and cconfirmation). As a minimum, m an outstation o shalll accept comm mands to enablee and disable uunsolicited respponses by event class (using ( object headers h with group g number 60) 6 even if thee device does nnot have Classs 1, 2, or 3 daata when the request arrives. Enabliing and disablling unsoliciteed responses on o a per pointt type and inddex is optionaal. When this is implem mented, the ob bject headers in n the request message m speciffy the group nuumber corresponding to stattic data of a point type and variation 0—the 0 requestt message shal l not use even nt type object hheaders. Masteers shall send s variation 0, but to acco ommodate legaacy systems, ouutstations mayy ignore the vaariation numbeer. An ob bject header and index list as shown in Figu ure 4-12 and itts accompanyiing descriptionn may be used in these requests. r Regard dless of the caause, when an n outstation is reset or restarrted, all of its points shall be disabled from initiatiing unsolicited d responses. Th his does not mean m the pointss do not generate events, jusst that the poinnts cannott initiate unsollicited reportin ng. An outstatiion shall not rreport unsoliciited events unttil its points aare explicitly enabled by y a request from m the master, and a then only ddata from the eenabled points are permitted to be inccluded in the response. Notte that devicess shall transmiit a data-less null message upon restartinng accord ding to the requ uirements in 5..1.1.1.1 even th hough no pointts are enabled aat the time. When an outstation receives a fun nction code DISABLE_UNS D SOLICITED rrequest to disaable initiation oof i by th he object headders in the requuest, it shall noo longer transm mit unsolicited responses from points identified any daata via an unso olicited response for those po oints. The requuest also canceels any pendingg expectation oof 13

The reason r for deprecatting function codee 19 was because older o versions of thhis specification ddid not provide suffficient details aboout how to use u the function co ode or clearly define the behavior off an outstation upoon receipt of such a request.



IEEE Sttd 1815-2012 d for Electric Pow wer Systems Com mmunications—D Distributed Netwo ork Protocol (DNP3) IEEE Standard

confirm mation for an unsolicited reesponse that has h already beeen sent from the outstationn, but for whicch confirm mation has nott yet been receiived. An ou utstation shall not n lose or disscard event datta as a result oof receiving thhe DISABLE_U UNSOLICITE ED functio on code; the outstation shall report events if they are reqquested in a maaster poll for tthose points thhat were disabled d from reporting r in un nsolicited respo onses. The reesponse to enab ble unsolicited d and disable unsolicited u requuests are null rresponses.

EX 4-24 4

This is an n example of enabling e an outtstation to transsmit all Class 11, 2, and 3 events.

► Request Messsage ►►► C3 AC

14 4 FC C

3C Grp

02 Var

00 IIN1

00 IIN2

06 Quaal

3C Grp

03 Var

06 Qual

3C Grp

004 V Var

06 Qual


81 C FC

4.4.14 4 Function code c 22 (0x1 16) Assign n Class A maaster uses this function code to assign th he events gennerated by poiints to event classes. Present assign nments may be altered using this t function co ode. Every device shall have h a default event e class forr each and everry point for whhich it supports events. This is w a master requests events by class, ann outstation onnly reports events from those necesssary so that when points whose class assignments a maatch the requesst. It is desirablle, but not manndatory, for deevices to providde ns of configuriing the default class assignmeents for each o f its points. a mean When an event is crreated, it is cllassified as a Class C 1, 2, or 3 event. The convention ussed by DNP3 to nment to Classs 0. The evennts are not reaally assigned to disable event generaation is to speecify an assign b using Classs 0 in the requuest allows DN NP3 to employy a Class 0 because thatt class specifiees static data, but mat. consisstent object form Static data is always assigned to Cllass 0 and is no ot re-assignablee to any other cclass. The reequest containss one or more sets s of assignm ments. Each asssignment set coontains one claass object headder follow wed by data objject headers thaat specify the points p whose evvents are to bee re-assigned. ⎯ AC is the Application A Con ntrol octet. ⎯ FC is the fu unction code occtet. ⎯ IIN1 and IIN N2 represent th he Internal Indication octets. ⎯ COHx is thee xth Class Object Header (sh hown shaded). ⎯ DOHxy is th he yth Data Objject Header asssociated with thhe xth class objject header.




►►► Request Message AC

FC

COH0

DOH00 DOH01 • • •

IIN1

IIN2

DOH0n COH1

DOH10 • • •

DOH1m

◄◄◄ Response Message AC

FC

Within each assignment set ⎯ The variation octet in the class object header specifies the new event class. All of the object headers that follow the class object header, until the next class object header or the end of the request, specify the points that shall re-assign their events to the new class, or shall disable event generation. The data object headers usually have a static data object group number even though just the events are being re-assigned. (The event reporting variation is not re-assigned; it is the events generated by the points whose indexes are specified in the static data object group headers that are being re-assigned to an event class.) An object header and index list as shown in Figure 4-12 and its accompanying description may be used in the requests if the outstation supports assignment of individual points. The class object headers in an assignment set always use object group 60 (class data) and qualifier 06 (all). Variations 2, 3, and 4 correspond to class assignments of 1, 2, and 3, respectively. Variation 1 specifies that event generation shall be disabled; it does not mean that events are reported in requests for Class 0 data! No other variations are permitted. Table 4-12 shows which object header groups and variations are used for specifying the points whose events are to be re-assigned.




Table 4-12—Object headers used for re-assigning event classes Object headers in the assignment message

Point type or data type

Group

Variation

Applies to events reported using group

Binary Input

1

0

2

Double-bit Binary Input

3

0

4

Analog Input

30

0

32

Frozen Analog Input

31

0

33

Counter

20

0

22

Frozen Counter

21

0

23

Binary Output Status

10

0

11

Binary Output Command

12

0

13

Analog Output Status

40

0

42

Analog Output Command

41

0

43

File

70

0

70 (variations 4, 5, 6, and 7)

Data Set

86

0

88

Octet String

110

0

111

Virtual Terminal

112

0

113

a

Authentication

120

0

120 (variation 7)

Security Statisticsb

121

0

122

a

Outstations shall not allow Authentication objects or Security Statistic Event objects to be assigned to no class, or to static Class 0. Therefore, outstations shall return a null error response with IIN2.0 [NO_FUNC_CODE_SUPPORT] set if they receive an ASSIGN_CLASS request that would cause points of Object Group 120 or 122 to be assigned to Class 0. b See footnote a.

Events receive their class attribute at the time they are created. Thus, a point that is requested to assign its events to another class does not have to change already buffered events to the new class; only events generated after the assign class request are assigned to the new class. The response to an ASSIGN_CLASS function code request is always a null response. NOTE—Masters should issue a poll for all three event classes in a single request immediately after issuing an assign class request. This picks up any events that were generated between the most recent event poll, or unsolicited response, and the assign class request and assures that the events are reported in the same sequence that they were generated. If the poll for all three classes is not issued, there is the potential for events to be reported out of order, depending on the circumstances of which events were generated before and after the assign class request and the specific event polls issued by the master.

Outstation devices that are able to store the most recent class assignments in non-volatile memory may use those assignments after a device restart; otherwise, devices shall revert to their default class assignments.

EX 4-25

This example illustrates assignment of binary input events to Class 1, analog input events to Class 2, and frozen counter events for indexes 0 to 2 to Class 2, and disabling of frozen counter events for indexes 3 to 10.


16 FC

3C Grp ←

02 06 Var Qual Assignment set

01 Grp

00 Var

06 Qual

3C Grp →←

03 Var

06 Qual




►►► ► Continuation n of Request Message M 1E 00 0 Grp Vaar Assignmentt set

06 Qual

15 Grp

00 Varr

00 Qual

00 Range

02

3C Grp →←

001 V Var

06 Qual

► Continuation n of Request Message M ►►► 15 00 0 Grp Vaar Assignmentt set

00 Qual

03 Range

0A →


81 C FC

00 IIN1

00 IIN2

s

4.4.15 5 Function code c 23 (0x1 17) Delay Measurement The master m uses thiss function cod de to measure the t communiccation channeel delay time. It is most ofteen used in the time syn nchronization process p for non n-LAN applicaations. The maaster shall meaasure delays thhat s that it can seend a time valuue that shall be accurate wheen exist in the modems and communiication media so it arriv ves. For more information, i seee 10.3. The reequest messagee contains no objects. The reesponse messag ge contains a single Fine Tim me Delay DNP33 object, g52v22. The Fine Tim me Delay objeect holds the outstation processing deelay, which is valid for a sinngle, one-time-only request aand is defined aas umber of millisseconds from the t arrival of th he leading edg e of the start bbit in the first ddata link octet oof the nu the recceived request message (geneerally at the intterface where tthe bit is detectable from the physical mediia, such as a at the outputt of the outstatiion modem if so s equipped) too the time of thhe leading edgge of the start bbit of thee first data link k octet in the transmitted reesponse messaage as it leaves the device ((generally at thhe interfaace where the bit b is placed on nto the physicaal media, such as at the inputt of the outstatiion modem if sso equipp ped). The proceessing delay in ncludes clear-to o-send timing. The master m shall reccord two times in order to compute c the ccommunicationn delay. The ffirst is the exaact instantt when the lead ding edge of th he start bit of the t first octet inn the transmittted request meessage leaves thhe masterr device (geneerally at the in nterface where the bit is placced onto the pphysical mediaa, such as at thhe input of o the master modem m if so eq quipped). The time t recorded is after RTS/C CTS handshakinng, if used. Thhis time iss identified as To (time out). The seecond time thatt the master sh hall record is th he exact instantt when the leadding edge of thhe start bit of thhe first occtet in the receeived response message arrivees at the masteer device (generrally at the inteerface where thhe bit is detectable d from m the physical media, such as a at the outputt of the masterr modem if so equipped.) Thhis time iss identified as Ti (time in).




The master m calculatees the communication channeel delay time ass follows14: Comm munication chan nnel delay timee = (Ti – To – outstation o proccessing delay) / 2 NOTE— —The frequenccy of measuring g the propagatio on delay is sysstem dependent.. Implementers need to considder whetheer the delay is fixed f or variablee. If variable, how h rapidly doees it change? Thhe results of thiis analysis shouuld indicatte whether a propagation delay measurement m is required only onnce, prior to eveery time synchroonization messagge or at an n interval somew where between th hose extremes.

4.4.15 5.1 Rules ⎯ Rule 1: Masters M shall not retry delay y measuremen nt requests, annd outstations shall not retrry correspondiing response messages at either e the Appplication or thee Data Link L Layer. For more information n, see 10.3.4. ⎯ Rule 2: An ny outstation th hat sets IIN1.4 [NEED_TIME E] to request a time synchronnization from thhe master shall support this function f code. ⎯ Rule 3: Alll masters that require time-staamped events sshall support thhis function code. 4.4.15 5.2 Example es EX 4-2 26

This is a sample delay measurement m where w the proceessing delay iss 18 milliseconnds.


17 7 FC C


81 1 FC C

00 IIN1

00 IIN2

34 Grp p

02 Var

07 Qual

01 12 0 00 ge Time Dela ay Rang

4.4.16 6 Function code c 24 (0x1 18) Record d Current Timee This function f code is used in the procedure forr time synchroonizing outstatiion devices thhat communicaate over a LAN. It requ uests a receiverr to record thee time of receippt of the last ooctet in a messsage having thhis functio on code. Later, the receiver compares c this time t with the ttime sent by thhe master in a ssubsequent wriite messaage having a Laast Recorded Time T object, g5 50v3. The receeiver uses thesee two pieces oof information to correcct its internal tim me reference. A masster that sends this message shall s also recorrd the time of ttransmission w when it sends thhe last octet off a messaage with this function fu code. The master usses that time vvalue in a subbsequent messaage to the sam me outstattion, having a Last L Recorded d Time object, g50v3. g For more information, see 10.3. 14

Theree are several assu umptions implicit in this computation. First is that tthe outbound com mmunication delayy is the same as tthe inbound d communication delay. d The second is that the master and outstation App pplication Layers hhave a means of woorking together wiith the loweer layers in order to t obtain the timess when start bits arre received and traansmitted. Third, tthe computed com mmunication delayy is applicab ble for the synchro onizing message used to write the tim me; that is, the soft ftware design is suuch that other unpredictable processinng delays (e.g., ( network delaays and task switch hes) do not affect the t accuracy.




The reequest messagee has no DNP3 objects, and th he response meessage is a nulll response. 4.4.16 6.1 Rules ⎯ Rule 1: Maasters shall not retry record current c time rrequest messagges at either thee Application oor the Data Lin nk Layer. For more m informatiion, see 10.3.44. ⎯ Rule 2: An ny outstation th hat has a TCP P/IP interface aand sets IIN1.44 [NEED_TIM ME] to request a time synchrronization from m the master sh hall support thi s function codee. ⎯ Rule 3: Alll masters that require time-stamped eventss and support T TCP/IP shall aalso support thhis function code. 4.4.16 6.2 Example es EX 4-2 27

This is an n example of a master’s request to record thhe current timee and the outstaation’s responsse.


18 8 FC C


81 C FC

00 IIN1

00 IIN2

4.4.17 7 Function codes c 25 (0x x19), 26 (0x1A A), 27 (0x1B)), and 30 (0x1E) Open File, Close Filee, Delete File, and Abort Filee The purpose of the OPEN_FILE function code is to make a file available for reading orr writing by thhe masterr and specifically for locking it so that no other process m may access the ffile during thiss time. When thhe masterr is finished, it i uses the CLOSE_FILE orr ABORT_FIL LE function coode to unlock tthe file, therebby makin ng it available to t another proccess. A master uses u the DELE ETE_FILE function code to rremove a file. Open and delete arre secure transsactions. A vaalid authenticaation key (seee 4.4.19) may be required to m these transacttions and expirres as soon as iit is used. A zeero value for thhe authenticatioon successsfully perform key im mplies world (o or guest) permissions. Two DNP3 D objects exist e to supportt the open, closse, delete, and abort functionnality. ⎯ A File Com mmand object, g70v3. g ⎯ A File Com mmand Status object, o g70v4. A Filee Command objject is used to initiate open an nd delete operaations. A Filee Command Sttatus object is used u to indicatte the success of open, closee, delete, and aabort commandds and to o return a file handle h during opens. It is allso used to iniitiate file closee and abort operations using a previo ously acquired file handle.




4.4.17.1 Preliminary notes 4.4.17.1.1

File handles

Most requests and all responses contain a file handle. This handle is a shorthand code for referencing a file using just four octets (32 bits). The outstation assigns file handles. File handle zero is reserved to indicate an invalid or illegal file handle; therefore, the outstation shall never assign this number to an opened file. NOTE—A master should never assume the same file handle is always associated with a particular file. Instead it should assume a different handle is assigned each time the file is opened or reopened.

If there is no activity referencing a file handle for a configurable length of time, the outstation shall automatically close the file. The timeout value shall be configurable up to one hour. When a file handle timeout condition occurs, the outstation shall send a File Transport Status event object, g70v6, using a status code value of file handle expired (17). The final state of the file closed under this condition is undefined. 4.4.17.1.2

File Command Status Objects

Since it may take some amount of time to determine the success of an operation, a File Command Status object, g70v4, is classified as an event object when it is used in a response. An instance of this DNP3 object is generated in every response to an open, close, delete, or abort request. Because they represent events, these objects may be configured for Class 1, 2, or 3 and returned when class data is transmitted (polled or unsolicited). The master may also explicitly poll for these objects. It is also acceptable for the outstation to return this object immediately in the response if the results are known without delay. If it is impractical to return the object immediately, the outstation shall instead immediately return a null response and then send the File Command Status object at a later time in an event report. A File Command Status DNP3 object does not represent an event when used in a request. NOTE—Because a File Command Status object is an event object when returned in a response, the outstation should request an Application Layer confirmation in the response’s application control octet.

4.4.17.1.3

File Transport Status objects

File Transport Status objects, g70v6, are used in the responses resulting from requests to write file data and in error responses resulting from requests to read file data. This object is also used to notify the master when the file status spontaneously changes such as happens when the open-file inactivity timer expires. This object is not used for open, close, delete, or abort requests. It is included in this portion of the document because of its similarity to a File Command Status object and because outstation files are automatically closed when conditions exist that necessitate a non-zero status code. A File Transport Status object is classified as an event object. Because the data in these objects represent events, they may be returned when class data is transmitted (polled or unsolicited). The master may also explicitly poll for this data using these object headers in a read request. It is also acceptable for the outstation to return this object immediately in the response if the results are known without delay. If it is impractical to return the object immediately, the outstation shall instead immediately return a null response and then send the File Transport Status object at a later time in an event report. When the outstation detects an error and returns this object with a non-zero status code, the outstation shall also close the file, and the outstation is no longer required to retain information relative to when the file 67 Copyright © 2012 IEEE. All rights reserved.



was opened. The final state of a file is undefined when it is closed by the conditions that create a File Transport Status event object with a non-zero status code value. 4.4.17.1.4

Additional information

Additional information about sequential file transfer is provided in 5.3. 4.4.17.2 Opening a file To open a file, the master issues an open command (OPEN_FILE function code) with the File Command object, g70v3. An open request directs the outstation to prepare to read or write the file and to assign a unique handle that shall serve as an alias for subsequent operations on the file. 4.4.17.2.1

Request messages

The master enters the file name string offset, file name string size, permissions, authentication key, request ID, and file name string octet fields into a File Command object. The file name string field shall be fully described as in Path\FileName If the file is to be opened for reading, the operational mode field is set to 0x01 and the file size and time of creation fields are set to zero. The maximum block size field is set to the maximum number of file octets the master can accept from the outstation in the response messages to each read request; the outstation may send less than this number. The virtual file position pointer in the outstation is set to zero15, which is the beginning of the file. If the file is to be opened for writing, the operational mode field is set to 0x02 to write a new file or to overwrite an existing file. The operational mode field is set to 0x03 to append octets to the end of an existing file. The time of creation and permissions fields are set to appropriate values that the outstation shall use for attributes of the new file. The maximum block size field is set to the maximum number of octets that the master shall send in each write request message; the outstation may negotiate a smaller value in the corresponding field of its response. The file size field is entered by the master and specifies the total number of file octets that shall be transferred by all of the write requests combined, after the file is open. A file size of 0xFFFFFFFF indicates that the actual file size is unknown. Outstation devices are not required to accept unknown file sizes and may reject the request. The Request ID in the request’s File Command object is a master-dependent parameter that the outstation is required to return in the request ID field of its corresponding response. It permits the master to associate a response with a particular request. Outstations do not interpret or deduce any meaning from the value in this field. When the outstation receives an open request with the operation mode set to 0x02, it shall truncate the file to a zero length, set the virtual file position pointer to zero, and set the time of creation and permission attributes per the respective fields in the File Command object. When the outstation receives an open request with the operation mode set to 0x03, it shall overwrite the time of creation and permission attributes per the respective fields in the File Command object, and it shall set the virtual file position pointer to one octet beyond the end of the file. When an outstation is opened for writing and it receives an end-of-file indication during the transfer of the file contents (by virtue of the Last bit being set in the File Transfer object, g70v5), and the total number of 15 The virtual file position pointer is an indicator, private to and maintained by the outstation, for tracking the octet position within the file, relative to the beginning, from where the next octet should be read or to where the next octet should be written. Each time an octet is read or written, the virtual file position pointer is incremented by one count; otherwise it remains constant between requests. The virtual file position pointer can only be set from the master via an open request, and its value cannot be read by the master.




octets transferred is less than the number specified by the file size field in this object, the outstation shall assume the file is completely received without error. However, if the total number of octets transferred is greater than the number specified in by the file size field in this object, the outstation shall consider this as an error. 4.4.17.2.2

Response messages

The outstation responds with a File Command Status DNP3 object, g70v4. See 4.4.17.1.2. A status code of zero indicates that the file was successfully opened. The application should use the returned file handle in future references to the file until it is closed. A non-zero status code indicates that the file was not opened, and that the file handle value is invalid. If the file was opened for reading, the file handle field contains the 32-bit handle to use in subsequent file request messages. If the status code field contains a non-zero value, indicating an error of some kind, then the file handle shall be set to zero. The file size field indicates the total number of octets in the file that was opened. The maximum block size field indicates the largest number of octets the outstation shall return with each read request; this value shall be less than or equal to the value in maximum block size field of the request. Note that the outstation may return fewer than this number in each read response. If the file is to be opened for writing, the file handle field contains the 32-bit handle to use in subsequent file request messages. If the status code field contains a non-zero value, indicating an error of some kind, then the file handle shall be set to zero. The file size field should contain a zero. The maximum block size field indicates the largest number of octets the outstation can accept in each write request; this value shall be less than or equal to the value in maximum block size field of the request. Note that the master may write fewer than this number in each write request.

This is an example of opening a file named “ABC” for reading where the outstation is unable to respond immediately. The block size specified is 192, and the request ID is 311. Assume that file events are configured for Class 3.

EX 4-28


19 FC

46 Grp

03 Var

5B Qual

01 Range

1D 00 Size prefix

1A ←

00

03

00

00

00

FF

01

00

00

00

00

01

00

C0

00

37

►►► Continuation of Request Message 00 00 00 File Command object

00

►►► Continuation of Request Message 00 00 00 00 File Command object continued ►►► Continuation of Request Message 01

41

42

43 → 69 Copyright © 2012 IEEE. All rights reserved.



◄◄◄ Response Message C3 AC

81 FC

00 IIN1

00 IIN2

• • • N master polls requesting a File Command Status object. Each request is followed by an outstation null response. • • • ►►► Request Message CE AC

01 FC

46 Grp

04 Var

07 Qual

01 Range

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

66 ←

08

00

00

C0

00

01

◄◄◄ Response Message (beginning) EE AC

81 FC

00 IIN1

00 IIN2

◄◄◄ Continuation of Response Message 77 88 99 00 File Command Status object

37

◄◄◄ Continuation of Response Message 00 → ►►► Confirm Message CE AC

00 FC

NOTE—The preceding example shows the master polling exclusively for File Command Status objects after requesting a file open. It is permissible, and even encouraged, for a master to interleave other requests during this time to more effectively utilize available bandwidth. It is not intended that other transactions be significantly delayed during file transfers. This philosophy holds for all file transfer activities whereby the master does not receive an immediate response.

EX 4-29

This is an example of opening a file named “ABC” for writing where the outstation is able to respond immediately. The master requests a block size of 2048 octets, but the outstation negotiates a size of 192.


19 FC

46 Grp

03 Var

5B Qual

01 Range

1D 00 Size prefix

1A ←

00

03

1F

EB

00

01

00

00

►►► Continuation of Request Message 00 80 4E File Command object

8F

FF




►►► Continuation of Request Message 00 00 00 08 File Command object continued

00

00

02

00

00

08

37

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

66 ←

08

00

00

C0

00

01

►►► Continuation of Request Message 01

41

42

43 →

◄◄◄ Response Message (beginning) E3 AC

81 FC

00 IIN1

00 IIN2


37

◄◄◄ Continuation of Response Message 00 → ►►► Confirm Message C3 AC

00 FC

4.4.17.3 Closing a file To close a file, the master issues a close command (CLOSE_FILE function code) with a File Command Status object, g70v4. A close request directs the outstation to invalidate the file handle, and if the file had been opened for writing or appending, to store the contents of the file in its final destination. Closing the file also releases the file, making it available to other processes in the outstation. In a request, the file handle field in the File Command Status object shall be set to the same handle returned during the open transaction. The file size, maximum block size, and status fields shall be cleared to zeros. Optional American Standard Code for Information Interchange (ASCII) characters can be included at the end of the File Command Status object for information, but outstations may ignore them; therefore, a master should not depend on those octets having any significance to the outstation. The outstation responds with a File Command Status object, g70v4. See 4.4.17.1.2. In the response, the file handle, file size, maximum block size, and optional ASCII characters fields shall match those in the request. A status code of zero indicates that the file was successfully closed. A non-zero status code indicates that an error was detected. NOTE—If the master chooses to end the operation for any reason including a timeout, it should send either a close or an abort command to the outstation to release the file for further use.

EX 4-30

This is an example of closing a file.





1A FC

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

66 ←

77

00

00

00

01

00

88

►►► Continuation of Request Message 99 00 00 00 File Command Status object

37

→


81 FC

00 IIN1

00 IIN2

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

66 ←

00

00

00

00

00

01


37


00 FC

4.4.17.4 Deleting a file To delete a file, the master issues a delete command (DELETE_FILE function code) with a File Command object, g70v3. A delete request directs the outstation to remove the file from its file store and to remove references to the file from the applicable file directory. The master enters the file name offset, file name size, permissions, authentication key, request ID, and file name octet fields into the File Command object with appropriate values. The file name field shall be fully described as in Path\FileName The master sets the operation mode field to 0x00 and the file size, time of creation, and maximum block size fields to zero. The outstation responds with a File Command Status object, g70v4. See 4.4.17.1.2. In the response, the file handle, file size, and maximum block size fields shall be zero. A status code of zero indicates that the file was successfully deleted. A non-zero status code indicates that an error was detected. NOTE—If the outstation receives a delete command for a file that is open, it should not delete the file and should return a status code 4, File Locked.




EX 4-31

This is an example of deleting a file.


1B FC

46 Grp

03 Var

5B Qual

01 Range

1D 00 Size prefix

1A ←

00

03

00

00

00

FF

01

00

00

00

00

00

00

00

00

37

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

00 ←

00

00

00

00

00

01

►►► Continuation of Request Message 00 00 00 File Command object

00

►►► Continuation of Request Message 00 00 00 00 File Command object continued ►►► Continuation of Request Message 01

41

42

43 →


81 FC

00 IIN1

00 IIN2


37


00 FC

4.4.17.5 Aborting a file transfer To abort a file transfer, the master issues an abort command (ABORT_FILE function code) with a File Command Status object, g70v4. An abort request indicates to the outstation that it shall immediately terminate the current read or write operation and close the file, without saving the file if the file were opened for writing or appending. In the request, the file handle field in the File Command Status object shall be set to the same handle returned during the open transaction. The file size, maximum block size, and status fields shall be cleared to 73 Copyright © 2012 IEEE. All rights reserved.



zeros. Optional ASCII characters can be included at the end of the File Command Status object for information, but outstations may ignore them; therefore, a master shall not depend on those octets having any significance to the outstation. The outstation responds with a File Command Status object, g70v4. See 4.4.17.1.2. In the response, the file handle, file size, maximum block size, and optional ASCII characters fields shall match those in the request. If the outstation cannot abort the operation, it shall return a status code 9, Cannot Abort. A status code of zero indicates that the operation was aborted and the file was successfully closed. A nonzero status code indicates that an error was detected. NOTE—After receipt of an abort command, in order to completely recover an original file that was being written, an outstation device may need to double-buffer the file during the file transfer operations; i.e., it may need an intermediate buffer to hold the file contents until a close command is received; at which time, the file data is written to the final destination.

EX 4-32

This is an example of aborting a file transfer.


1E FC

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

66 ←

77

00

00

00

01

00

88

►►► Continuation of Request Message 99 00 00 00 File Command Status object

37

→


81 FC

00 IIN1

00 IIN2

46 Grp

04 Var

5B Qual

01 Range

0D 00 Size prefix

66 ←

00

00

00

00

00

01


37


00 FC




4.4.18 8 Function code c 28 (0x1 1C) Get Fiile Information n The pu urpose of the GET_FILE_IN G NFO function code c is for thee master to retrrieve informatiion about a fille. The file type, file sizze, time of creaation, and perm missions are retu turned. A master obtains th he information n by issuing a GET_FILE_IINFO functionn code with a File Descriptoor objectt, g70v7, in thee request. The filename f offset, file name sizze, request ID,, and file namee octet fields aare filled in i with appropriate values. The file name field shall be fullly described aas in Path\F FileName The fille type, file sizee, time of creattion, and permissions fields in the request oobject are clearred to zero. If the file exists, the outstation resp ponds with a File F Descriptor object, g70v7.. This object iss an event objeect when it is used in a response, but it is not an eveent object wheen used in a reqquest. The fileename offset, fiile ID and file nam me octet fieldss are filled in w with the same data as in the request, and thhe name size, request ID, file typ pe, file size, tim me of creation, and permissions fields are coompleted with their actual vaalues. If the file does not exist, the outsstation respond ds with a File Command Staatus object, g770v4, having thhe F Not Found d. status code set to 3, File If the file referenced d is a directory file, the file typ pe field shall bbe zero to indiccate a directoryy file and the fiile he sub-directorry. To retrievee file informatioon on all files in size fieeld shall indicaate the numberr of entries in th the dirrectory, issue a file read on th he directory filee. See 5.3 for m more details.

EX 4-33

This is an n example of requesting r information about a file. Assumee that file evennts are configurred for Classs 3.

► Request Messsage (beginnin ng) ►►► C3 AC

1C C FC C

46 Grp

07 Var

5B Quaal

01 Range

17 00 Size prefix

14 ←

000

03

00

00

00

00

00

000

00

37

01

41

42

43

► Continuation n of Request Message M ►►► 00 01 00 ptor object File Descrip

00

► Continuation n of Request Message M ►►► 00 00 0 00 File Descrip ptor object

00

→

use the outstatiion cannot fetcch the file dataa immediatelyy, it sends a nuull response annd waits for thhe Becau masterr to poll for event data. ◄◄◄ ◄ Response Message M C3 AC

81 C FC

00 IIN1

00 IIN2 75 Copyright © 2012 IEEE. All rightts reserved.



• • • N master polls for f Class 3 dataa, each followeed by an outstaation null respoonse • • • ►►► ► Request Messsage CE AC

01 C FC

3C Grp

04 Var

06 Quaal

◄ Response Message M (beginn ning) ◄◄◄ EE AC

81 C FC

00 IIN1

00 IIN2

46 Grp p

07 Var

5B Qual

01 Rangge

17 000 Size prefixx

14 ←

00

00

08

00

00

80

4E

FF

01

37

01

41

442

43

◄ Continuation n of Response Message M ◄◄◄ 00 03 00 File Descrip ptor object

01

◄ Continuation n of Response Message M ◄◄◄ 8F 1F F EB 00 File Descrip ptor object con ntinued

→

► Confirm Message ►►► CE AC

00 0 FC C

4.4.19 9 Function code c 29 (0x1 1D) Authenticate File This function fu code iss used to obtain n an authenticaation key that m may be neededd to open or dellete a file. Wheen implem mented, an autthentication keey provides a form of securrity that assurees the requestoor can provide a user name and passw word acceptablee to the outstattion. Not alll outstations im mplement or reequire an autheentication key.. For those thatt do, the masteer shall submitt a requesst to obtain an authentication n key, and if the outstation reecognizes a vallid request, thee outstation shaall issue a key. The au uthentication key k is applicab ble to only a single transacction, and it iss entered in thhe ntication key fiield of the g70v v3 object used with an open oor delete requeest. authen The master m requestss an authenticaation key using g an Authenticcation object, g70v2. The usser name offseet, user name n size, passsword offset, password p size, user name occtet, and passw word octet fiellds shall contaain approp priate values. The T authentication key field is i cleared to zeero in the requeest. The ou utstation respo onds with an Authentication object, o g70v2. If the request is acceptable tto the outstation, the au uthentication key k field contaains a unique value that maay be issued iin an open orr delete requesst; otherw wise, if unacceeptable, a zero o appears in th he authenticatiion key field. T This implies w world (or guesst) permisssions. The useer name offset,, user name sizze, password of offset, and passsword size fieldds contain zeroos, and th here are no userr name octets or o password octets included inn the response for security reeasons.

EX 4-34

This is an n example of an a authenticatio on request and response.




►►► ► Request Messsage (beginnin ng) C3 AC

1D D FC C

46 Grp

02 Var

5B Quaal

01 Range

15 00 Size prefix

0C ←

000

05

00

00

00

00

00

53

43

45

42

52

41

►►► ► Continuation n of Request Message M 00 11 00 Authenticattion object

05

► Continuation n of Request Message M ►►► 41 44 4 41 5A Authenticattion object con ntinued

→

◄ Response Message M (beginn ning) ◄◄◄ C3 AC

81 C FC

00 IIN1

00 IIN2

46 Grp p

02 Var

5B Qual

01 Rangge

0C 000 Size prefixx

00 ←

00

00

00

AA

BB

DD

◄ Continuation n of Response Message M ◄◄◄ 00 00 0 00 Authenticattion object

00

C CC

→

4.4.20 0 Function code c 31 (0x1 1F) Activaate Configuratiion This function f instruccts the outstatiion to begin ussing the configguration or exeecutable code specified by thhe objectts included in th he request. Exeecutable code is i defined heree to mean proceessor instructioons that are useed for no ormal operation n of the outstaation device. Itt should not bee confused witth starting or sstopping speciial applications, which is i the purpose of function co odes 17 and 18 , start applicattion and stop aapplication. Thhe o called firm mware. executtable code disccussed here is often The co onfiguration data or executab ble code to bee activated by the use of thiss command shhall be loaded oor installed in the outstaation before issuing a requestt containing thhis function codde. Those conffiguration valuees de are not in usse yet, but they y are available to t use when thhe activate conf nfiguration reqquest is receiveed. or cod The acctivate configu uration requestt does not conttain new configguration valuees or processorr instructions but referen nces which of the available configuration c values v or sets oof configuratioon values or exxecutable code is to be activated. a Afteer processing th he request, the specified item ms shall becom me active in thee outstation from that time t onward until superseded by anoth her activate cconfiguration request or bby some othher implem mentation-depeendent method d of altering thee configurationn or code. Upon executing a reequest with thiis function cod de, the configuuration data orr executable coode specified bby bjects included in the requestt may be preseerved in some form of non-vvolatile storagee if the device is the ob capablle and shall be b the configurration data or processor insstructions that the device usses immediately follow wing the requesst’s execution. Objectts that are suitaable for inclusiion into an actiivate configuraation request aare ⎯ File Specifiication String, g70v8 ⎯ Octet String g, g110 77 Copyright © 2012 IEEE. All rightts reserved.



These objects shall specify which configuration or processor instructions to activate and shall not contain the actual configuration values or code. The configuration values or executable code being activated shall be available in the outstation prior to receipt of the activate configuration request. Requests shall include at least one object and may include more than one. If more than one object is included, the objects may have differing group and variation numbers. The contents of the objects may specify the complete outstation configuration or only a portion of the configuration and are vendor specific. Similarly, the contents of the objects may specify the entire outstation executable code or only specific code sections. The method by which the master station determines which objects to include in an activate configuration request, and the content of those objects, are matters beyond the scope of this standard. When an outstation receives an activate configuration request, it shall check the fitness or suitability of the corresponding objects in the request and may perform checks on the configuration data or executable code (such as a CRC check) referenced by objects in the request prior to initiating the activation operation. After completing the checking, the outstation shall immediately return a Status of Requested Operation object, g91v1. If no errors are detected, the outstation shall complete the transmission of the Status of Requested Operation object before initiating the activation. If any errors are detected during the checking, the outstation shall not activate any of the configurations or processor instructions, even if some of the objects or data referenced by the objects are valid. The state of the IIN bits in the activate configuration response shall reflect the current conditions and not the anticipated conditions. The status in object g91v1 is an indicator of whether the outstation expects the activate configuration operation to succeed or fail, and it is determined prior to initiating the activation. The device shall not set an internal indications bit, such as IIN2.5 [CONFIG_CORRUPT], due to failing a check that would cause a non-zero status code. This is because the new configuration data is not active; it is pending. The device shall not set the IIN1.7 [DEVICE_RESTART] bit in anticipation of restarting; it shall wait until after it has restarted to set that bit. IIN bits may be set for other reasons. A Status of Requested Operation object contains a delay time during which the outstation expects to be busy and shall not respond to requests. It is permissible for an outstation to restart during this period. The master is not obligated to honor this time and may send requests during the delay period; however, because the outstation may not reply, the master may conclude that the outstation is off-line. For some systems, this is a useful means for notifying operators that the outstation is not available. If the outstation does restart because of performing an activate configuration operation, its first response shall have the IIN1.7 [DEVICE_RESTART] bit set. Some outstations may detect that the new configuration is corrupt during the activation operation, or soon thereafter. When this happens, then the outstation shall set the IIN2.5 [CONFIG_CORRUPT] bit. The dashed points as follows describe a few examples that use this function code. Vendors may choose other schemes not described here. ⎯ The master station writes analog deadband data to a temporary file in the outstation named AnalogDeadbands.tmp. Next, the master reads the file and compares its contents to what it sent in order to assure that the outstation’s file is intact. The master then issues an activate configuration request with one object (g70v8) that identifies file AnalogDeadbands.tmp. The outstation now saves the deadband information from the file to non-volatile memory and uses the new deadbands for detecting analog events. ⎯ Alternately, if the outstation is designed to configure itself by reading from a file (e.g., AnalogDB.dat), instead of storing the new deadbands in non-volatile memory upon receipt of the activate configuration request, the outstation copies the contents of file AnalogDeadbands.tmp to AnalogDB.dat. 78 Copyright © 2012 IEEE. All rights reserved.



⎯ An outstation designed for water systems contains multiple configuration sets for controlling pump sequencing. The configuration sets are located in non-volatile storage when the device is manufactured; the sets are named “Pump Seq A,” “Pump Seq B,” and “Pump Seq C.” One of these sets shall be chosen to determine the operating sequence. An octet string (g110v10) containing “Pump Seq B” is included in the activate configuration request. After the request is processed, the “Pump Seq B” configuration set is used. ⎯ An outstation uses a data set with the name “Control duration time.” It has three values: a default control duration time, a beginning index number, and an ending index number. The master places 250 milliseconds, beginning at index 24 and ending at index 26 into a data set object (g87v1), and writes that data set to the outstation, where it is saved in volatile memory. No other action is initiated by the outstation at that time. The master then issues an activate configuration request with one object (g110v21) giving the name of the data set “Control duration time.” After the request is processed, the default on-times for control point at indexes 24, 25, and 26 are set to 250 milliseconds and saved in non-volatile storage. ⎯ A vendor fixes a bug in his embedded processor code. The code is downloaded to the outstation as a block of data octets in RAM. The master issues an activate configuration request with an object (g110v56) containing a privately defined ASCII command string “Store 120 188 octets at address 0x001374756 CRC 0x2D94AC8B.” Upon receipt, the outstation calculates a 32-bit CRC of all 120 188 octets at address 0x001374756 and compares the result to 0x2D94AC8B. If the CRC values compare, a g91v1 object with status 0 is sent back to the master and then the 120 188 octets are written to flash memory and a reboot is issued. If the CRC values do not compare, the outstation returns status code 2 indicating a problem in the 120 188 octets. The outstation does not set any IIN bits and continues on as usual as if it had never received the activate configuration request. NOTE 1— Depending on the system design, an outstation setting the IIN2.5 [CONFIG_CORRUPT] bit may be sufficient reason to download a new configuration. NOTE 2— The IIN1.7 [DEVICE_RESTART] bit should not be the sole indicator for a master to download a new configuration. The reason for this is due to outstations that restart as a normal activity when processing an activate configuration request. If IIN1.7 were used alone, the master and outstation could get into an endless loop of restarting, downloading, and activating configuration.




Figure F 4-13— —Example ex xchange to a activate confiiguration Figure 4-13 is an ex xample exchang ge between thee master and thhe outstation. T This example shhows the mastter ption of the filee did not occurr during its doownload. DNP33 does not reqquire these stepps. checkiing that corrup The ex xample also sh hows the behav vior when the outstation o doess, and when it ddoes not, detecct an error in thhe config guration requessted to be activated. 4.4.21 1 Function code c 32 (0x2 20) Authentication Requ uest The master m uses this function code when sending g authenticationn requests to thhe outstation. For more information, see Clause 7. 7 4.4.22 2 Function code c 33 (0x2 21) Authentication Requ uest No Acknow wledgment The master m uses th his function code when sen nding authentiication requessts to the outsstation. For thhe AUTH H_REQ_NR fu unction code, no response is sent. s For more information, see Clause 7. 7 80 Copyright © 2012 IEEE. All rightts reserved.



4.4.23 3 Function code c 129 (0x x81) Respo onse All ressponse messag ges except for unsolicited u resp ponse messagees use functionn code RESPON NSE. Whenever the master issues a request, regarrdless of what function codee appears in thhe request, thee response shaall NSE. always use function code RESPON Most of o the previouss examples illu ustrate this. 4.4.24 4 Function code c 130 (0x x82) Unsoliicited Responsse Unsoliicited responsees always use function codee UNSOLICIT TED_ RESPON NSE without rregard to whicch DNP3 objects are inccluded. 4.4.25 5 Function code c 131 (0x x83) Authentication Response The ou utstation uses this t function co ode to issue authentication m messages to the master. For more information, see Clause 7. 7

4.5

Detailed IIN bit desc criptions

This su ubclause proviides details forr each of the Internal Indicatioon bits. 4.5.1

IIN1.0—Brroadcast Mes ssage Received [BROAD DCAST]

For eaach master wiith which an outstation is communicating c g, the outstatioon shall mainntain a status to indicaate receipt of a broadcast message from that m master. That state is arbbitrarily nameed Broad dcastMessageR Received. The IIIN1.0 bit indicaates the status of o this BroadcaastMessageRecceived state: ⎯ IIN1.0 = 1 Indicates the outstation haas received a m message addreessed to one oof the broadcaast addresses. ⎯ IIN1.0 = 0 Indicates eitheer the outstatio on has not receeived a broadcaast message orr that the bit haas been cleared in accordancce with the conditions in Tab le 4-13. After receipt r of a req quest containin ng one of the Broadcast B addrresses16 (0xFFF FD to 0xFFFF F), the outstatioon shall set s the BroadccastMessageReeceived state. The T state is seet regardless oof whether the function in thhe broadccast command d is performed d. That state shall remain set until certtain conditionss are met. Thhe condittions depend on n the specific Broadcast B addrress in the messsage and are deescribed in Table 4-13. Outstaations shall nott respond to bro oadcast requests.

16

Addreesses appear in Daata Link Layer fram mes. The design of o the Data Link L ayer and Applicattion Layer providees a means to pass to the App plication Layer thee destination address in Broadcast meessages so that thee IIN1.0 bit and coonfirmations can be handled correctly.




Table T 4-13—B Broadcast ad ddresses Broa adcast add dress

Add dress name

Conditio ons for clearingg the BroadcasttMessageReceivved state he outstation shaall not request ann Application Laayer confirmatioon in the first Th reesponse to the master unless therre are reasons to do so other thann receipt of a brroadcast message.

0xFFFD D

BRO OADCAST_ DON NT_ he outstation shaall clear the BroaadcastMessageR Received state affter sending the Th CON NFIRM firrst response with h IIN1.0 set to thhe master. A master sends Broadcast messagges to this addresss when it wantss to minimize thee co ommunications traffic t and reducce bandwidth reqquirements. he outstation shaall set IIN1.0 andd shall request aan Application L Layer Th co onfirmation for all a response messsages while the BroadcastMessaageReceived staate is set. This confirm mation may be ccombined with cconfirmation for other reasons.

0xFFFE E

BRO OADCAST_ SHA ALL_ he outstation shaall clear the BroaadcastMessageR Received state affter receiving an Th CON NFIRM Application A Layerr confirmation fr from the master. A master sends Broadcast messagges to this addresss when it needss positive accknowledgment that the Broadcaast message wass received by thee outstations.

0xFFFF F

he outstation shaall choose eitherr the conditions sspecified for adddress 0xFFFD orr Th th he conditions speecified for addreess 0xFFFE. In oother words, it is optional as to whether w the outstaation shall requirre an Applicatioon Layer confirm mation in order too BRO OADCAST_ cllear the BroadcastMessageReceiived state. OPT TIONAL_ CON NFIRM his address prov vides backward ccompatibility witth older versionss of the DNP3 Th sp pecification. A master sends Broadcast messagges to this addresss if it or any of the outstations iin th he system were designed d before D DNP3 had multiiple Broadcast addresses.

4.5.2

IIN1.1—Ad dditional Cla ass 1 Event Data D Is Availa able [CLASS S_1_EVENTS S]

This bit b indicates wh hen the outstation has any Cllass 1 events thhat have not yet been reporteed in the current respon nse message. In I a polled env vironment, this bit signals thhe master thatt it needs to seend at least onne requesst to retrieve th he remaining Class C 1 events. Transmit T this bbit set when thhere are Class 1 events existinng that haave not been in ncluded in the current c responsse. 4.5.3


This bit b indicates wh hen the outstation has any Cllass 2 events thhat have not yet been reporteed in the current respon nse message. In I a polled env vironment, this bit signals thhe master thatt it needs to seend at least onne requesst to retrieve th he remaining Class C 2 events. Transmit T this bbit set when thhere are Class 2 events existinng that haave not been in ncluded in the current c responsse. 4.5.4


This bit b indicates wh hen the outstation has any Cllass 3 events thhat have not yet been reporteed in the current respon nse message. In I a polled env vironment, this bit signals thhe master thatt it needs to seend at least onne requesst to retrieve th he remaining Class C 3 events. Transmit T this bbit set when thhere are Class 3 events existinng that haave not been in ncluded in the current c responsse.




4.5.5

IIN1.4—Time Synchronization Req quired [NEED D_TIME]

This bit b is set when the t outstation requires r time synchronization s n from the masster. It shall noot set this bit iff it does not n require tim me synchronizattion. Reasons why w an outstattion would nott require time from the mastter includ de ⎯ It is synch hronized from another sourcce (such as a global positiooning system [GPS] clock oor another masster). ⎯ It never sen nds time-stamped data. If the outstation o sets this bit, it shalll support both ⎯ Time synch hronization messsages. ⎯ Clearing thee bit via a writte request from m the master sp ecifying objectt g80v1. If the outstation sets this bit, the master m shall prom mptly perform m a write time ssequence. If tim mekeeping is nnot m, the master should s simply issue a write reequest to clearr IIN1.4. required in the system If the master m clears this t bit by issuiing a write requ uest to object gg80v1, the outsstation shall ⎯ Assume a tiime synchronizzation messagee is not forthcooming. ⎯ Wait beforre setting this bit again forr at least the interval that it normally w waits after tim me synchronizaation is receiveed. Masters may send tim me synchronization messagess even if the ouutstation does nnot set the IIN1.4 bit. If an outstation o sets the bit, it shalll leave the bit set s until it is clleared by the m master. The ouutstation may nnot clear the t bit until thee master issues a time synchro onization messsage or writes a 0 to IIN1.4. In the past, vendors have h interpreteed this bit to mean one of twoo choices, namely, the outstattion sets IIN1.44: a))

Well beforee the timing reeference drifts beyond its rateed accuracy inn order to give the master tim me to completee its higher prio ority tasks befo ore sending thee time.

b)) After the outstation’s o inteernal clock haas drifted beyoond its rated aaccuracy. For tthis choice, it is assumed th hat the master performs timee synchronizatiion periodicallly without the need to set thhe IIN1.4 bit. Masters need to know w what interprretation is impllemented in eaach outstation. If the master ccannot be certaain her an outstattion has impllemented cho oice a), and the system ppermits sufficciently frequent wheth synchrronization to meet m specificatiion, it should use u interpretatioon b) for that ooutstation. Failure of an outstattion to receive time synchron nization shall nnot cause the ddevice to inhibbit any function; nly side-effectt of not receiv ving time is that the time information iit reports or uutilizes may bbe the on inaccu urate. NOTE— —Outstations th hat set the IIN1.4 4 bit at unreason nably short interrvals might adveersely impact system operation bby requirin ng a disproportio onate amount off the available baandwidth for nonn-data collectionn activities.

4.5.6

IIN1.5—So ome Output Points Are In n Local Mode e [LOCAL_C CONTROL]

This bit b shall be set whenever w at least one of the outstation’s o ouutput points aree in the local opperation mode..




This in ndication is no ot intended to inhibit i or preveent controls froom the master;; it is an advisoory that controols might not succeed. It I is the system m implementerr’s responsibillity to provide suitable lockoouts that disabble ol operation fro om the master when w points are in local modee. contro If the master directss a control com mmand to a point in local moode, the outstaation shall retuurn a status codde b in local mode. m indicaating failure due to the point being NOTE 1—Masters maay send control requests r to outsttations that set IIIN1.5 because tthis bit does not necessarily meaan bled for operatio on from the mastter. For examplee, in a data conceentrator applicattion, only one IE ED that alll points are disab may bee in the local mo ode thereby requiring the data co oncentrator to sett IIN1.5; howevver, control comm mands to the othher IEDs should succeed. NOTE 2—Outstations that have a locaal-remote switch h or logic are re sponsible for prreventing controol actions on thoose points that it places in local mode.

4.5.7

IIN1.6—De evice Trouble [DEVICE_T TROUBLE]

This bit b is set when n an abnormall condition ex xists in the ouutstation. This standard doess not enumeraate abnorm mal conditionss because they are device specific. They o ften result from m hardware prroblems such aas over-temperature or a subsystem failure. f IIN1.6 should only bbe set while thee condition exxists and anothher on. IIN bit cannot indicaate the conditio 4.5.8

IIN1.7—De evice Restarrt [DEVICE_R RESTART]

This bit b is set when an outstation restarts r for any reason. The onnly permissiblle method to cllear the bit is fo for the maaster to specificcally write a 0 to it using objeect g80v1 and index 7. NOTE— —The master should clear IIN N1.7 bits as soon n as possible affter detecting thhe bit is set so that it can deteect additio onal resets. The bit b should be cleared prior to dow wnloading new pparameters like aanalog deadbandds.

4.5.9

IIN2.0—Fu unction Code e Not Implem mented [NO_ _FUNC_CODE E_SUPPORT T]

This bit b shall be set in i responses when w the masterr request contai ains ⎯ A function code that is no ot supported by y the outstationn. ⎯ A function code that is no ot supported forr objects of thee type specifiedd in the requestt. For ex xample, an outstation that does not supportt frozen counteers may set IIN N2.0 in a respoonse to a requeest containing a freeze function f code. An example of a fun nction code thaat possibly is no ot supported foor objects of thhe type specifieed in the requeest is a freeeze command d, IMMED_FR REEZE, sent wiith counter obj ects in the messsage if the outtstation does nnot supporrt frozen countts. 4.5.10 0 IIN2.1—Ob bject Unknow wn [OBJECT T_UNKNOWN N] The ou utstation shall set this bit in responses accorrding to the connditions in Tab ble 4-14.




Tablle 4-14—Con nditions for s setting IIN2.1 1 Request from masterr contains

Non-ev vent data objectss

Set IIN2.1 bit b if

D Do not set IIN22.1 bit if

The outstattion does not sup pport the requested operation o on objects in the request witthout regard to th he indexes specified in n the objects.

The outstattion does not sup pport events of the types specified in the reequest objects

Outstation does support the requested operation oon objects in thee request, even iff one or morre of the objects in the request specifies ann index that the outstation does not have. The outstattion does supporrt events of the types speciified in the requeest objects, evenn though it ddoes not have anyy at the time of the requestt* or has fewer eevents to report than the m master requested - OR -

- AND Event data d objects. events relaating to the typess in the request objects aree not defined for the outstation’s particular DNP3 D subset im mplementation level.

the outstatiion does not suppport events of thhe types speciified in the requeest objects, but events are defined for the ooutstation’s particular D DNP3 subset im mplementation level*. * In both ccases where theree are no events tto report, the outstation returnns a null response.

An ex xample of an IIIN2.1 error is when a masterr requests a dirrect operate off an analog ouutput point wheen the ou utstation has no o analog outputts. Anoth her example off this error is when a masteer includes a P Pattern Controol Block object, g12v2, in thhe requesst in order to en nergize a relay and the outstaation only suppports a CROB oobject, g12v1. An ex xample where the t outstation shall s not set th he bit is when a master requeests to read anaalog input indeex 99 an nd the outstation does not have h a point with that indeex; the outstaation shall insstead set IIN2.2 [PARA AMETER_ER RROR]. 4.5.11 1 IIN2.2—Pa arameter Errror [PARAME ETER_ERRO R] The reeader requires a thorough und derstanding of the qualifier annd range fieldss in object headers and what is meantt by object prrefixes in ordeer to know when w an outstaation shall set this bit. Subclause 4.2.2.77.3 describ bes these in deepth. The outstation shall set this bit in n responses wh hen it supportts the requesteed operation onn objects in thhe o the points in the index rang ge or object inddex prefixes exxist in the outsttation. The bit is requesst, but not all of set eveen if some of the t points are available. It iss not set when the qualifier ooctet in the objject header doees not specify indexes in i the range fieeld or an objectt index prefix. This bit b shall also be b set in respo onses wheneveer the outstatioon is unable too parse the Appplication Layer fragmeent because eitther: ⎯ The messag ge was incorrecctly formed. ⎯ The request used an objeect variation th hat is includedd in the outstaation's particulaar DNP3 subsset implementaation level, but that the outstaation does not ssupport. ⎯ The requestt used a qualifiier or other opttion that the ouutstation does nnot support. 85 Copyright © 2012 IEEE. All rightts reserved.



An ex xample of this error e is a mastter that requestts a read of anaalog input poinnts in the range of 0 to 49 annd the ou utstation has on nly 32 analog in nputs with indeex numbers 0 tthrough 31. If the request contains a read funcction code, the outstation ressponse may retturn objects foor points that are ble and omit th hose for points that do not exist; however, thhis behavior iss not mandatoryy. availab 4.5.12 2 IIN2.3—Ev vent Buffer Overflow O [EV VENT_BUFFE ER_OVERFLO OW] This bit b indicates th hat an event buffer b overflow w condition exxists in the ouutstation and tthat at least onne uncon nfirmed event was w lost becau use the event bu uffers did not have enough rroom to store tthe information. See Fiigure 4-14. IIN2.3 3 shall be set in i responses fo ollowing the lo oss of at least one or more events due to overflow of thhe outstattion’s event bu uffers. After seetting this bit, the overflow condition conntinues until thhe outstation haas storage available in each e of its even nt buffers to ho old informationn for at least onne more event.. It is not sufficient to o report this biit as set in only y a single messsage followingg the overflow w. The outstatioon c to sett IIN2.3 in ressponses until the t master hass read and connfirmed enoughh events so thhat shall continue when a new event of o any type iss generated, itss information can be storedd in the event buffers without ng an event losss. causin Figure 4-14 illustrattes setting and d clearing of th he IIN2.3 bit. IIt assumes an ooutstation deviice has an event bufferr designed to hold h 200 even nts. The figuree shows the tim me relationshiips for the meessages with thhe earliesst time at the to op of the diagram. The longeer arrows pointting downwardd at an angle inndicate messagees in tran nsit to the outstation or masster. The rectaangular box reppresents the nnumber of evennts in the evennt bufferr. The hy ypothetical dev vice in this exaample may hav ve other event bbuffers, which for simplicity are empty. NOTE 1—The master in Figure 4-14 4 is poorly conffigured. It shoulld have polled ffor event data m more frequently in o remove eventss before any werre lost due to oveerflow. order to NOTE 2—In normal operation, o the master m should po oll often enoughh to retrieve eveents before an ovverflow conditioon occurs.. If the bit is sett, it may indicatte a problem in the system suchh as the master not polling freqquently enough or possiblly a high noise situation.




Figure e 4-14—Even nt buffer ove erflow examp ple 4.5.13 3 IIN2.4—Op peration Is Already A Exec cuting [ALRE EADY_EXECU UTING] This bit b is set when n the requesteed operation was w not perform rmed or initiatted because exxecution was in progreess on the speecified points, or application ns, when the rrequest arrivedd. Setting this bit is optionaal; outstattions are not reequired to impllement its funcctionality. 87 Copyright © 2012 IEEE. All rightts reserved.



IIN2.4 4 bit applies to only the function codes in Table 4-15 as foollows. Tablle 4-15—Con nditions for s setting IIN2.4 4 Function n code

Conditiions when IIN2.4 could be set

3

SELECT

An operatio on is in progresss that prevents a selection.

4

OPERATE

An operatio on is in progresss that prevents thhe control actionn.

5

DIRECT_O OPERATE

An operatio on is in progresss that prevents thhe control actionn.

16

INITIALIZ ZE_APPL

Application n is already runnning.

17

START_AP PPL

Application n is already runnning.

18

STOP_APP PL

Application n is not running..

19

SAVE_CON NFIG

Configurattion saving is currrently in progreess.

31

ACTIVATE E_CONFIG

The applicaation is currentlyy using the conffiguration specifi fied.

4.5.14 4 IIN2.5—Co onfiguration Corrupt [CO ONFIG_CORR RUPT] This bit b is set when n the outstation n detects a corrrupt configuraation that affeccts reliable funnctioning of thhe unit. It I may also bee set when oth her, non-criticaal configuratioons are corruppt. Setting this bit is optionaal; outstattions are not reequired to impllement its funcctionality. 4.5.15 5 IIN2.6—Re eserved Bit [RESERVED_ [ _2] This bit b is reserved for f future use. It I shall always be returned cleared to 0. 4.5.16 6 IIN2.7—Re eserved Bit [RESERVED_ [ _1] This bit b is reserved for f future use. It I shall always be returned cleared to 0. NOTE— —In older versiions of the DNP P3 specification, IIN2.6 and IIN N2.7 were descriibed as being reeserved for use bby agreem ment. Because th here was no asssurance of inteeroperability am mong different vvendors, these ttwo bits are noow reserveed by DNP3 for future requiremeents.

4.6

Unsolicited respons ses

Unsoliicited responsees are messages spontaneouslly sent from ann outstation wiithout a specific request from ma masterr when “something of significcance” occurs. The DNP3 D protocol includes suppo ort for unsoliciited responses. Masters and ooutstations are not obligated to implem ment unsoliciteed messaging as this feature is optional, buut vendors thaat do implemennt this operatioon metho od may have a broader b markett in which to seell. This method m of opeerating has ad dvantages in some s applicatiions. In a sysstem with a laarge number oof outstattions and a sin ngle master, ch hanges at an outstation o can reach the masster often muchh faster becausse there is i no delay whiile waiting for a master poll. The communiccation costs to achieve fasterr polling in som me installations can be prohibitive, p an nd the quickest notification off changes can occur if most of the messagees contain only changes and confirmaations. Unsoliccited responsess may reduce ccosts where thee owners choosse a “cosst-per-byte” typ pe of service. On thee other hand, equipment e that implements un nsolicited resp onses is more complex becauuse the issues oof mediaa access and co ollision avoidaance must be considered. M Master softwaree requires acceepting messagees from any a of its outsstations at any y time. Anotheer disadvantagge is that systeem performancce may becom me unpred dictable during g periods of heaavy communiccation.




Emplo oying unsolicitted reporting requires r an en ngineering judggment based oon numerous ffactors for eacch individ dual system. There T are no guarantees that unsolicited reporting is uuniversally appplicable for aall system ms. It is not the purpose of this subclaause to justify using u or not ussing unsoliciteed responses; rrather it presennts us requirementss and consideraations for thosee implementatiions that do suppport unsolicitted responses. variou 4.6.1

Unsolicite ed response timing

Figu ure 4-15—Un nsolicited tim ming diagram m Figure 4-15 illustrattes two timing parameters asssociated with eeach transmitted unsolicited rresponse. a))

First, is thee time that it taakes to transm mit the responsse from the ouutstation to thee master. This is shown as th he Unsolicited Message M Transsmit Time in thhe figure.

b)) The second d timing value is the duration n that the outsstation waits too receive a confirmation bacck from the master. This is shown s as the Unsolicited U Coonfirmation Tim meout Period. If the outstatioon sends an id dentical retry or a regeneraated retry unssolicited respoonse, it initiattes transmissioon immediately y upon confirm mation timer tim meout. This tim me does not neeed to be uniform from retry to retry. 4.6.2 4.6.2.1

Outstation n configuratiion Compuls sory configu uration

Devices that suppo ort unsolicited d responses shall s support end-user connfiguration off the followinng param meters: a))

The destinattion address of the t master device to send thee unsolicited responses to.

b)) The unsoliciited response moode (either on or o off). When unsolicited ressponse operatioon is configureed off, the dev vice shall neverr send an unsollicited responsee, but otherwisse responds to m master requestts.




c))

The timeout period for unsoolicited responsee confirmation. T This is the amoount of time thhat the outstatioon shall wait for f an Applicattion Layer con nfirmation backk from the masster. As a miniimum, the rangge of configurable values shall include tim mes from one seecond to one m minute; howevver, devices maay ger and sh horter timeou uts for systtems with slower or faster mediia. offer long d may include a random com mponent to mi minimize the chhances of multtiple outstationns This period reporting att the same timee when a comm mon event initiaates an unsoliccited response sseries.

d)) The numberr of unsolicited retries r . This is the number oof retries that aan outstation trransmits in eacch unsolicited response seriies if it doess not receive confirmation back from thhe master. Thhe nd regeneratedd retry messagges. The unsolicited responsse configured value includees identical an on is not receeived by the eend of the unssolicited confirrmation timeout series ends if confirmatio period of th he final retry. One O of the choiices shall proviide for an indeefinite (and pottentially infinitte) number of transmissions. t 4.6.2.2

Non-com mpulsory con nfiguration

Suggeested additionall, non-compulssory, configuraation parameterrs are: a))

Hold time beefore initiating an a unsolicited response. r Delayying for a conffigurable amouunt of time aftter

detecting eaach new eventt is often beneeficial for allow wing multiple changes to coomplete prior to transmitting g an unsolicited d response message. Vendorss may choose w whether the hoold-time timer is retriggered for each new event detected (increased ppossibility of ccapturing all thhe changes in a giving the masster a guarantteed update tiime), or is user single response), is not retriggered (g v of 0 indiccates that respoonses are not ddelayed due to tthis parameter.. selectable. A configured value b)) Number of queued events beffore initiating ann unsolicited ressponse. When eevents occur tooo often, and thhe hold time (previous ( paraameter) is relaatively long, thhe event buffe fer or queue m may continue to accumulate events beforee an unsolicited d response is ttransmitted. W Without this couunter, the bufffer or queue caan overflow caausing a loss off events. Withh the counter, a message is innitiated when iits count reach hes the configu ured amount. This T gives tim me to transmit a quantity of events and theen remove the acknowledged d events from the t queue, thuss making room for more. NOTE 1— Configuration C parameters a) and d b) are used toggether so that iff either one of thhe criteria are meet, an unsolicited response is traansmitted. Eitherr or both can be disabled by settiing their values tto 0. NOTE 2— It I is acceptable to have a separaately configurabble set of configuuration parameteers, a) and b), ffor each event cllass.

4.6.3

Support unsolicited u enabling and disabling

Every master and ou utstation devicce that supportts unsolicited responses shalll also supportt function codees BLE_UNSOLIC CITED and DIISABLE_UNS SOLICITED. S See 4.4.13 for ddetails. ENAB As a minimum, m an outstation o shalll accept comm mands to enablee and disable uunsolicited respponses by event class (using ( object headers h with grroup number 60), 6 even if thee device does not have Class 1, 2, or 3 daata when the request arrrives. Enablin ng and disabled d unsolicited rresponses on a per point typpe and index is nal. option 4.6.4

Confirmattion and app plication conttrol octet

All un nsolicited respo onse messages shall request Application A Laayer confirmattion, regardlesss of whether thhe respon nse contains daata or not (null response). Thiis is accomplisshed by settingg bit 5, CON, inn the applicatioon contro ol octet.




Outstaations always set s bit 4, UNS, in the applicattion control occtet of an unsollicited responsee. This indicatees that th he sequence nu umber, SEQ, in the same octet o is for an unsolicited reesponse and not the sequencce numbeer for a soliciteed response. Masters send Appliication Layer confirmations to unsolicitedd responses byy setting the UNS bit in thhe o and a seq quence numberr, SEQ, matchiing that in the unsolicited ressponse fragment application control octet being confirmed. 4.6.5

Device res start

for unsolicitedd reporting. Refer to the startup rules r in 5.1.1. These T include considerations c 4.6.6

Normal ru untime behav vior

Devices that supportt unsolicited responses shall obey o the follow wing rules: Unsoliicited sequencce numbers in the rules that follow refer tto the sequencce number thatt appears in thhe application control octet. o Whereever the word confirmation is used, it reffers to an Appplication Layerr confirmationn, function codde CONF FIRM. Data Liink Layer con nfirmations, if used, never suubstitute for, rreplace, or im mply Applicatioon Layer confirmations. ⎯ Rule 1: An n outstation sh hall only initiatte unsolicited rresponses to reeport changes on those poinnts that are assiigned to an eveent class and fo or which unsol icited reportingg has been enaabled. NOTE 1—Enabling and disaabling points forr initiating unsoolicited responsees is accomplished by sending thhe respective fu unction code, EN NABLE_UNSOLICITED or DIISABLE_UNSO OLICITED, withh event class typpe objects (grou up 60), or if supp ported by the maaster and outstattion, individual points may be sspecified using thhe appropriate static s object grou up, variation 0, and a the desired inndexes.

⎯ Rule 2: An n outstation shaall only includee event data inn an unsolicitedd response. Maasters shall parse static data in unsolicited responses. Previous veersions of the DNP3 D specificaation17 permittted sending staatic data for obbjects g10v2 annd g40v2, for which no ev vent objects existed. e This behavior, whhile still perm mitted, has beeen ut status and an nalog output sstatus event obbjects have beeen added to thhe deprecated. Binary outpu t use is preeferred. Data Objectt Library, and their ⎯ Rule 3: Un nsolicited respo onses shall fit within w a singlee fragment (FIR and FIN bits are both set in the applicattion control occtet). If the outtstation has moore data than fi fits within a sinngle fragment, it shall includ de only as mucch data as fits into a single fr fragment. The outstation shalll wait until thhat response is confirmed, an nd then it may create c new unssolicited responnses to transm mit the remaininng data. ⎯ Rule 4: A master m shall ign nore the state of o the FIR and FIN bits in thee application ccontrol octet off a received un nsolicited respo onse. The reaso on for this rulee is backward compatibility with outstationns designed to o older version ns of the DNP3 3 specificationn that allowed sending of muultiple fragmennt unsolicited responses. ⎯ Rule 5: Th he SEQ numbeer in the appliccation control ooctet is advancced for originaal responses annd regenerated d retry messag ges and is un nchanged for iidentical retriees. The SEQ number in thhe outstation’ss startup null message m (see 5.1 1.1.1) is used aas an initial unsolicited sequeence number.

17

Sendiing static data objeects for all analog,, binary input, cou unter, and other pooint types in the innitial unsolicited reesponse at outstation startup was w a part of the original o specificatio on. Early implemeentations with this behavior may stilll exist in the field..




⎯ Rule 6: A master shall return confirmations to unsolicited responses immediately upon receipt, regardless of where it is in its polling sequence, even if it is waiting for a response to a solicited request. ⎯ Rule 7: Masters shall examine the SEQ number in a received fragment and compare it with the previously received unsolicited fragment. If the SEQ numbers are different, it shall assume a new fragment has been received, but if the SEQ numbers are the same, it shall compare all of the octets following the IIN octets to determine if the response is new or a repeat. ⎯ Rule 8: An outstation shall not initiate an original, an identical retry, or a regenerated retry unsolicited response while it is waiting for confirmation to a solicited response until either confirmation is received or the confirmation timer times out. ⎯ Rule 9: An outstation shall not intentionally discard event information until it receives confirmation back that those events were received by the master. ⎯ Rule 10: An outstation may only accept confirmations from the master if the application control octet contains a sequence number that matches the most recently transmitted unsolicited response. Once an outstation has advanced the unsolicited sequence number, late arriving confirmations with a previous sequence number shall be discarded. ⎯ Rule 11: An outstation shall immediately clear corresponding event data from its event buffer(s) upon receipt of a confirmation during the confirmation timeout period shown in Figure 4-15. It shall perform the clearing action prior to responding to any pending requests or generating the next original unsolicited response. Receipt of a confirmation terminates the current unsolicited response series. ⎯ Rule 12: If confirmation to an unsolicited response is not received before the confirmation timer times out, and the configured number of unsolicited response retries have not been sent, the outstation may choose to send an identical retry, or it may send a regenerated retry unsolicited response. If an identical retry is chosen, the sequence number shall be the same, and the retried fragment shall match the previous unsolicited response, octet-for-octet. If a regenerated retry unsolicited response is chosen, the outstation shall increment the unsolicited sequence number and may add new data or update data or modify the IIN octets from the previous unsolicited response. ⎯ Rule 13: If the configured number of unsolicited response retries have been sent and confirmation is not received by the end of the final transmission’s confirmation timeout period, the outstation shall terminate the current unsolicited response series, assume the confirmation is not forthcoming, and make the events available to be reported in a subsequent solicited response or a subsequent original unsolicited response. See Rule 14 for re-initiating unsolicited reporting. ⎯ Rule 14: Implementers may choose an appropriate trigger to initiate a new unsolicited reporting series if confirmation is not received per Rule 13. The following alternatives may be used alone or in combination with each other: 1) A new event occurs. 2) The master issued to the outstation a read request for any data. 3) For connection-oriented systems, the master connected to the outstation and issued a request of any kind. 4) Wait for an extended time period after confirmation timeout of the final unsolicited response. This wait duration is usually much longer than the confirmation timeout period. The benefit of this option is that it does not depend on a stimulus from the field or from the master to begin again. Implementers may choose other methods not listed here. ⎯ Rule 15: If an outstation receives a request from the master having function code DISABLE_UNSOLICITED while it is waiting for a confirmation to an unsolicited response, regardless of which object headers appear in the disable request, it shall wait until either 92 Copyright © 2012 IEEE. All rights reserved.



1) Confirmation is received. At this time the outstation shall immediately clear the confirmed event data from its event buffer(s) according to Rule 11. 2) The confirmation timer times out. At this time the outstation shall terminate the current unsolicited response series18 and cancel any expectation of confirmation for the entire unsolicited response. Make the events that were in the unsolicited response available for reporting in future responses. If there are still any events available and enabled for reporting in unsolicited responses (because the request only disabled some but not all events), the outstation may initiate a new original unsolicited response at an appropriate time. ⎯ Rule 16: If the outstation receives a read request of any kind while waiting for a confirmation to an unsolicited response, it shall defer building a response until either 1) The unsolicited response confirmation is received. The outstation shall then i)

Immediately clear the confirmed event data from its event buffer(s) according to Rule 11.

ii) Respond to the deferred read request as though it had just been received. 2) Timeout occurs waiting for the unsolicited confirmation. At this time, the outstation shall not send a retry unsolicited response; instead it i)

Shall terminate the current unsolicited response series18, assume the confirmation is not forthcoming, and make the events available to be reported in a subsequent solicited response or a subsequent original unsolicited response.

ii) Respond to the deferred read request as though it had just been received and wait for confirmation to that read response if confirmation is required. iii) Thereafter, may formulate a new original unsolicited response for any remaining events that are permitted19 to be transmitted in an unsolicited response. NOTE 2—A timing diagram is provided in 4.6.7 illustrating the receipt of a read request while waiting for a confirmation to an unsolicited response.

⎯ Rule 17: If a non-read request of any kind is received during an unsolicited response series, the outstation shall respond immediately. The non-read request does not cancel any pending expectation of unsolicited response confirmation. If the response requires the outstation to set an IIN bit and request confirmation because, for example, a broadcast message to address 0xFFFE was received immediately prior, the outstation shall: 1) Set the IIN bit and request confirmation in the response and in future solicited and unsolicited responses until confirmation is received. 2) Clear the IIN bit, if appropriate, upon receipt of confirmation to a response in which the bit was set. NOTE 3—The outstation should coordinate the receipt of confirmations to unsolicited and solicited responses to assure that the IIN bit is only cleared if the IIN bit was set in the response being confirmed. For example, confirmation to an unsolicited response that did not have the IIN bit set does not imply the master received a solicited response with the IIN bit set, and vice versa.

18

Termination of the unsolicited series does not apply to the initial null unsolicited response. Events are only permitted after the initial null unsolicited response has been confirmed and unsolicited responses are enabled as per the startup rules in 5.1.1.1, which includes considerations for unsolicited reporting. 19




⎯ Rule 18: Iff a read respon nse is deferred (see Rule 16),, and another rrequest of any kind is receiveed from the maaster, then 1) If the new n request is a read requestt, it replaces thhe already deferrred request. Itt is deferred annd handled d according to Rule 16, as ap ppropriate. 2) If the new n request is a non-read reequest, the defe ferred read reqquest is discardded and the neew requestt is handled acccording to Rulee 17. 4.6.7

Unsolicite ed response timing exam mples

This su ubclause illusttrates the behav vior associated d with unsolicitted response m messages. Figure 4-16 shows the ideal situaation where un nsolicited respoonses are conffirmed and there is no overlaap between a master’s request r and thee outstation’s confirmation waait time.

Figure 4-16—Idea al mixed unso olicited and s solicited com mmunication ns a from m top to bottom in the diagram m. Time advances Each request, respo onse, or confirmation is giv ven a numberr inside squarre brackets [nn] to aid in thhe ption. descrip At thee top, the outtstation transm mits an unsoliccited responsee [1] and receeives a confirm mation [2]. Thhe outstattion removes or o clears from m its buffer(s) the t events that at it reported inn the unsolicitted response [1] becausse confirmation n [2] was receiived from the master m that the event(s) arriveed there. In the middle of thee diagram, thee master issuess a read requeest [3] and thee outstation ressponds [4]. Thhe diagraam assumes th hat the outstattion required a read confirrmation, and tthe master sennds it [5]. Thhe 94 Copyright © 2012 IEEE. All rightts reserved.



outstation removes or clears from its buffer(s) the events that it reported in the read response [4] because confirmation [5] was received from the master that the event(s) arrived there. Later, the outstation transmits another new unsolicited response [6] and receives confirmation [7] from the master. The outstation again removes or clears from its buffer(s) the events that it reported in the unsolicited response [6] because confirmation [7] was received that the event(s) arrived at the master. Everything worked as expected. Responses were transmitted and confirmations received. In Figure 4-17, an example is shown where confirmations to unsolicited responses are not received as expected. Figure 4-17 illustrates two retries of an unsolicited response before the unsolicited transaction is successful. At the top, the outstation sends an unsolicited response [1] that is not received by the master. The reason does not matter; it could be a collision, noise burst, or something else. The outstation waits for the confirmation back. The outstation waits for the confirmation timeout and then transmits an identical retry [2] of the original unsolicited response. This response contains the same Application Layer sequence number that the original used. The confirm [3] from the master does not reach the outstation, but the outstation keeps waiting until its confirmation timer times out. NOTE 1—The confirmation timeout durations for the original and retried unsolicited responses are not the same. In the diagram, the wait for a retry confirmation is much longer. The reader should only observe that the times are different but should not draw any conclusions regarding the relative time durations or which should be the longer. The specification allows implementers to vary the wait times according to their own strategy.

When retry confirmation times out, the outstation sends another identical retry [4]. This time confirmation [5] is received from the master, and the transaction is finally successful. The outstation shall now remove or clear from its buffer(s) the events that it reported in the unsolicited response [4] because confirmation [5] was received from the master. NOTE 2—The master is able to determine that the second retry [4] is a repeat because the received message has the same sequence number and the message contents are the same as before [2]. In this case, the master ignores the processing of the contents of the repeated message [4] and just repeats the confirmation [5].




Figure 4-17—Unsolicited response or confirmation not received Figure 4-18 illustrates two points—the outstation may regenerate unsolicited responses if new events occur and the outstation shall discard confirmations if the sequence number is not the same as the most recently transmitted. The outstation sends an original unsolicited response [1], but the master is otherwise occupied and unable to send the confirmation in a timely manner. In the meantime, new events occur in the outstation. The confirmation [2] arrives at the outstation after the confirmation timer has timed out and after the outstation initiated another unsolicited response [3]. At confirmation timeout for unsolicited response [1], the outstation has the option of transmitting an identical retry of the original response or regenerated retry unsolicited response. The outstation chooses to send a regenerated retry unsolicited response [3] that includes the new events. Notice that the outstation incremented the sequence number. The master sends a confirmation [4]. In this example, the master almost certainly received duplicate events because the sequence numbers in unsolicited responses [1] and [3] were different, and the master is obligated to treat response [3] as a new message. Inasmuch as situations like this are possible, it is suggested that outstations transmit events with time stamps if the master requires that duplicated events are not processed. Time stamps provide information that a master can use to sort out the sequence of events and duplicates.




Figure 4-18—Regenerated unsolicited response Figure 4-19 illustrates a read request received while the outstation is waiting for a confirmation to an unsolicited response. At the top of the diagram, the original unsolicited response [1] is transmitted, but its confirmation [2] does not make it back to the outstation. The outstation waits until the confirmation timer times out and then initiates the sending of an identical retry [3]. However, the retried unsolicited response [3] does not reach the master. By coincidence, the master issues a read request [4] that arrives at the outstation while the outstation is still waiting for the unsolicited response confirmation. The outstation defers the read request [4] and does not prepare a response. It continues to wait for a confirmation to its retried unsolicited response [3]. Because there is a deferred read request existing when the confirmation timer times out waiting for unsolicited response [3], the outstation makes all of the events that it transmitted in response [3] available for transmission in a solicited or unsolicited response. Now the outstation transmits a response [5] to the deferred read request [4] and the master confirms [6].




Figure 4-19—Read request received while awaiting unsolicited confirm Figure 4-20 illustrates the behavior when a non-read request arrives. As shown, the outstation sent an unsolicited response [1] that did not arrive intact at the master station. While the outstation waits for a confirmation, the master issues a select request [2] in order to perform a control operation. The outstation shall respond immediately to non-read requests, and it transmits a select response [3]. The master immediately follows up with an operate request [4], and the outstation initiates the control action and sends the operate response [5]. The control action caused new events. When the confirmation timer times out waiting for the confirmation to unsolicited response [1], the outstation chooses to regenerate an original unsolicited response [6] that contains the new events. The confirmation [7] does not make it to the outstation and the confirmation timer times out once again. This time, there are no new events, and the outstation retries the unsolicited response [8]. Finally, confirmation [9] is received and the outstation clears the reported events from its buffer(s).




Figu ure 4-20—No on-read reque est received d

4.7

Support for functions sent to a broadcastt address

An ou utstation that su upports the fun nctions and commands in thee requests listeed in Table 4-16 when sent to its ind dividual device address shall also support th he same functioons and comm mands when sennt to a broadcaast addresss. This capability may be con nfigurable. The ou utstation may optionally o supp port other funcctions (not listeed in Table 4-16) that are seent in requests to a broaadcast address. If a co ommand is nott supported in requests r sent to o the device’s individual adddress, it shall nnot be supporteed in requ uests sent to a broadcast b addrress. NOTE E—In Table 4-16, 4 the Gro oup, Variation n, and Qualifieer codes mark rked “Any” inndicate that thhe associated function is i to be supporrted in broadcast requests for the same com mbinations of G Group, Variation, and Qu ualifier code th hat are supportted by the devicce in requests ssent to the devvice’s individuaal address.




Table 4-16—Mandatory function codes and objects for broadcast messages




5

Applicatio on Layer— —part 2

5.1

Addition nal details

This subclause s conttains additionaal implementatiion informatioon and recomm mendations thaat are not founnd elsewh here in the document and pro ovides further elaboration e on ttopics already discussed. There is no particulaar ordering to th he presentation n of topics. 5.1.1

Device sta artup

Whenever a master or outstation starts s up after a reset for anyy reason, it shaall perform certtain activities to w the devicee with which itt communicate s. assuree coordination with 5.1.1.1

Outstatio on startup

The fo ollowing rules apply when an n outstation dev vice restarts. 5.1.1.1.1

Outs station requirrements

⎯ Rule 1: An n outstation ind dicates that it has h restarted byy asserting the internal indicaations restart bit, IIN1.7 [DE EVICE_RESTA ART] in its reesponses to a m master poll annd in unsolicited responses. It shall also assert a the internal indication ns time synchrronization bit,, IIN1.4 [NEE ED_TIME], if it requires tim me synchronizaation. The outsttation shall cleear IIN1.7 [DE EVICE_RESTA ART] only wheen it receives a “Clear Restaart” request (a write messagee with object 80, variation 11, index 7) from the master. Clear Restartt requests receeived by an ouutstation have no effect if IIIN1.7 is alreaddy clear. ⎯ Rule 2: An n outstation, co onfigured to peerform unsoliciited reporting, shall immediaately transmit aan unsolicited null response message m that has h no data obj ects. If an Appplication Layerr confirmation is d within the co onfigured timeo out period, the outstation shaall retry sendingg the unsoliciteed not received null respon nse. It shall con ntinue retrying g, ignoring thee number of coonfigured unsoolicited responsse retries, untiil it receives an n Application Layer L confirmaation from the master confirm ming the receipt of an unsoliicited null resp ponse message.. ⎯ Rule 3: An n outstation configured c to perform unsollicited reportinng shall not ssend data in aan unsolicited response unttil it receives a request frrom the mastter containingg function codde UNSOLICITE ED that enabless some or all pooints to initiatee an unsolicitedd response. Thhis ENABLE_U does not mean m the pointss do not generaate events, onlly that the poiints cannot iniitiate unsoliciteed reporting off those events.. The outstatio on shall ignore whatever unsolicited featurees were enableed prior to the restart; it may only apply tho ose that are enaabled after the restart. ⎯ Rule 4: An n outstation shaall not discard events after thhe restart. It shaall save the event data, even if it is configu ured to report unsolicited ressponses and it has not yet reeceived an enaable unsoliciteed responses message m from the t master to in nitiate unsoliciited responses. ⎯ Rule 5: An n outstation, co onfigured to peerform unsoliciited reporting, shall respond normally to anny requests thaat it receives from a master. NOTE—Outtstation devices that are able to o store the mostt recent class asssignments and analog deadbannd downloads frrom a master in non-volatile mem mory may use thhose assignmentts after a device restart; otherwisse, devices shou uld revert to theirr default class asssignments.

5.1.1.1.2

Mastter requireme ents

⎯ Rule 1: Th he master shall reply with an unsolicited appplication conffirmation whennever it receivees an unsolicitted null messag ge from an outsstation. 101 Copyright © 2012 IEEE. All rightts reserved.



⎯ Rule 2: Upon detection of the IIN1.7 [DEVICE_RESTART] bit in a response from an outstation, the master shall perform the following actions for that outstation in the order indicated below: 1) If both the master and outstation support secure authentication and are configured to use it, the master shall set the session keys. 2) Issue a request to clear IIN1.7 [DEVICE_RESTART] by writing the value zero to it. NOTE—This is performed early in this procedure sequence so that any subsequent outstation restart during the procedure is identified and shall cause the procedure to be recommenced. Any restart occurring between setting of authentication session keys and clearing IIN1.7 will cause loss of the session keys. This is detected by subsequent authentication failures, leading to reestablishment of the session keys as per the normal authentication procedures.

3) The following steps can then be performed in any sequence (if required by master and/or outstation configuration): i)

Read device attributes (object group 0).

ii) Perform time synchronization. iii) Issue class assignments. iv) Download analog deadbands. v) Read outstation-defined data set descriptors, and then write master-defined data set descriptors. vi) Write any required data set instances. vii) Perform optional event polls (including polls for limited numbers of events) and/or integrity polls. 4) Perform an integrity poll to read all outstation data (optionally preceded by one or more event polls, as described above). 5) If the master is configured to use unsolicited reporting with the outstation, and has received an unsolicited null message from the outstation, the master shall issue a request to enable unsolicited reporting for any or all of the event classes (Class 1, Class 2, and Class 3) configured in the device using the ENABLE_UNSOLICITED function code. Note that the actions described above each consist of one or more messages in each direction between the master and outstation. Each action shall consist of the complete message transaction sequences (requests, responses, application confirmation, etc.) required to perform that action. 5.1.1.2

Master startup

⎯ Rule 1: When the master restarts, the master shall perform the following actions for each outstation in the order indicated below: 1) If both the master and outstation support secure authentication and are configured to use it, the master shall set the session keys. 2) If the master is configured to use unsolicited reporting with the outstation, the master shall issue a request to disable unsolicited reporting of Class 1, 2, and 3 events using the DISABLE_UNSOLICITED function code. 3) The following steps can then be performed in any sequence (if required by master and/or outstation configuration): i)

Download XML Device Profile file.

ii) Read device attributes (object group 0). iii) Perform time synchronization. 102 Copyright © 2012 IEEE. All rights reserved.



iv) Isssue class assign nments. v) Do ownload analog g deadbands. vi) Reead outstation-d defined data seet descriptors, aand then write master-definedd data set descriptors. vii) Write any requireed data set insttances. viii) Peerform optionall event polls (in ncluding polls for limited num mbers of eventts) and/or inttegrity polls. NOTE—If XML X Device Pro ofiles are to be do ownloaded, theyy must be downlloaded before deevice attributes aare read, class asssignments are isssued, analog deeadbands are dow wnloaded, and ddata sets are readd or written.

4) Perform m an integrity poll p to read alll outstation datta (optionally ppreceded by onne or more event polls, as a described ab bove). 5) If the master m is conffigured to use unsolicited repporting with thhe outstation, tthe master shaall issue a request to en nable unsoliciteed reporting fo for any or all oof the event cclasses (Class 1, Class 2, 2 and Class 3)) configured in n the device ussing the ENAB BLE_UNSOLIC CITED functioon code. Note that t the actionss described abo ove each consiist of one or m more messages in each directtion between thhe masterr and the outtstation. Each action shall consist of thee complete m message transacction sequencees (requeests, responses,, application co onfirmation, etc.) required to perform that aaction. 5.1.2

Point inde ex range reco ommendatio ons

Point indexes serve to differentiatte one point from f another w within the sam me point type. Experience haas n that assigning g index numbeers contiguouslly starting from m zero results in transmissionns that are morre shown efficieent. Assigning indexes in th his manner alsso lowers the burden on soome less sophhisticated mastter softwaare designs. Th herefore, outstaations should fo ollow these reccommendationns: ⎯ Assign poin nt indexes con ntiguously starrting from indeex number zerro for memberrs of each point type. ⎯ Within a po oint type, gaps in the point in ndex range are permissible buut should be avvoided wherever possible. An example of an a acceptable gap might be w where a point is optional (i.ee., where it maay be installed d or uninstalled d without alteriing the point inndex values off the remainderr of the points oof the same po oint type). Thee assumption is i that all poinnts in the pointt index range ffrom zero to thhe maximum installed i point index always exist in the devvice, but somee may be “abseent” or currenttly not installed d. Consider assigning the larrgest point indeexes to the opttional points soo that if they aare not installed d, the remainin ng points still have h a contiguoous point indexx range. ⎯ Assume thaat memory and d database resou urces are requiired at the masster for each inndex in the rangge of zero to the t highest insstalled index nu umber, irrespeective of whethher all these point indexes aare actually tran nsmitted. ⎯ It is not accceptable to asssign point indeexes in a sparsse manner (e.gg., 0, 1, 2, 100, 101, 102, 2000, 201, and 202). Point ind dexes are not intended, andd should not bbe used, for grrouping data oor implying so ome relationshiip between data points. ⎯ Consider asssigning sets off optional poin nts to one or moore virtual devvices, each withh its own uniquue device addrress. When thee points are installed, the corrresponding viirtual device eexists, and if thhe points are not installed, the virtual device d does nnot exist. Thiss removes thee possibility fo for g gaps in the po oint index ranges when pointss are installed oor uninstalled. introducing ⎯ Consider providing p a co onfigurable maapping option that allows uusers to selecct which of thhe outstation’ss points are to be b reported to, or controlled bby, the master,, and in what inndex order thosse points appeear. In some situations, this makes it ppossible to keeep the DNP33 point indexees 103 Copyright © 2012 IEEE. All rightts reserved.



contiguous beginning at 0. 0 It also minim mizes bandwiddth requiremennts by not repoorting points fo for u has no inteerest. which the user 5.1.3

Event reporting

NOTE 1—In general, the t most bandwidth-efficient waay to update a m master is by frequuently polling foor events from thhe uesting static daata as an integri rity measure. If the number off events generateed outstation and only occcasionally requ betweeen outstation inteerrogations is low w, this allows th he master to polll a larger numbeer of outstations on a channel inn a given amount a of time. Each outstation n returns much less l data than iff the master had to retrieve all ddata on every pooll cycle.

DNP3 events are asssociated with h something significant happpening. Exampples are state changes, valuees ding some threeshold, an anallog exceeding its deadband, snapshots of ddata taken at a particular tim me, exceed transieent phenomenaa, and newly av vailable inform mation. NOTE 2—It is highly y recommended that all outstation devices, exccept for units haaving only a few w points, perforrm report-by-exception processing internaally and respond to class polls foor event data. Thhis makes possibble efficient use of bandwidth.

Event reporting shalll follow the folllowing rules: ⎯ Any devicee that generatess more than onee Data Link Laayer frame in a response to C Class 0 poll shaall support eveent reporting fo or: 1) Binary input points an nd double-bit binary b input pooints. 2) Analog g input points. 3) Counteer input points. ⎯ Events shalll be reported in n the order speecified in 5.1.55.1. It is not neccessary, but it is acceptable, to intermix bin nary events wiith analog even nts (and other events) to keepp every reporteed event in tim me sequenced order. o 5.1.4

Data types s in class da ata response es

Class data responsess are messagess sent by the outstation o resullting from a reead request byy the master thhat des an object header h specifyin ng object grou up 60. Object ggroup 60 is speecified in the oobject header oof includ class data d requests only o and never appears in thee object headerr of any responnse. Data objeects in class daata respon nses are reporteed using the ap ppropriate object headers for tthe data types being reportedd. Users may not want to include thee static or even nt data of all coonfigured poinnts in class dataa responses. Foor ple, outstationss may contain data d that may be b of little or nno use to somee users. Or perrhaps bandwiddth examp constrraints make it necessary to exclude e non-essential data. There may also be specificc reasons why a vendor or user wou uld want to im mplement a polling strategyy that omits ccertain items ffrom class daata nses. For all these reasons, it may be desiraable to exclude specific data ttypes or pointss from class daata respon respon nses. Thereforee, all devices ex xcept for very simple, low pooint-count deviices shall be coonfigurable as to which h points to inclu ude in class datta responses. This T is achievedd by assigning individual poiints to one of thhe four classes (static Class C 0 or even nt Class 1, 2, or 3) during connfiguration of the device. Soome devices alsso om a master to o assign points to specific classses. acceptt commands fro In resp ponse to a class data requestt, outstations shall s not reporrt static or eveent data for points that are not assign ned to one of th he four classes. Masters can obtain o the statiic data of such points (not assigned to one oof the fou ur classes) by issuing a read d request contaaining the resppective group nnumber and pooint index in thhe objectt header (e.g., specific s analog g inputs are acccessed by speccifying group 30 and approppriate indexes in the obj bject header), or o by issuing a read containin ng the respectivve group numbber and specifyying all points oof that daata type (e.g., all a analog inputts are accessed d by specifyingg group 30 and qualifier 06).




NOTE—It is strongly recommended that the included points be assigned the lowest index numbers, starting with zero, and all of the excluded points use higher index numbers.

For counters and analog point types, it is permissible to report both frozen and non-frozen values in the same response if the master is able to handle both; however, devices that are able to report both shall provide configuration to disable this feature and report either the non-frozen or the frozen variations but not both. 5.1.4.1

Static data, group 60, variation 1

Class 0 data responses are messages sent by the outstation resulting from a read request by the master that includes an object header specifying object group 60, variation 1. Object group 60 shall not be used in the responses; the responses shall instead include the appropriate static data object(s) (Table 5-1). Table 5-1—Static data included in Class 0 data response Data type Binary Inputs (Group 1) Double-Bit Binary Inputs (Group 3) Binary Output Status (Group 10) Counters and Frozen Counters (Groups 20 and 21) Analog Inputs and Frozen Analog Inputs (Groups 30 and 31) Analog Output Status (Group 40)

Static data included in Class 0 data response? All devices (except for very simple, low point-count devices) shall allow users to assign points of these data types to no class, or to one of the four classes (static Class 0 or event Class 1, 2, or 3), by changing the device’s configuration. The device shall then include the static data of all points assigned to any of the four classes in its Class 0 data response.

Data Sets (Group 87) Binary-Coded Decimal (Group 101) Unsigned Integer—8-bit (Group 102) Octet Strings (Group 110)

All devices that support these static data types shall be configurable as to whether any or all points of the specific data type are included in the Class 0 data responses.

Security Statistics (Group 121)

All devices that support Secure Authentication shall include the static data of all points of this data type in the Class 0 data responses.

Analog Input Reporting Deadbands (Group 34) Internal Indications (Group 80) Virtual Terminal (Group 112)

Points of these static data types are never included in Class 0 data responses.

5.1.4.2

Event data, group 60, variations 2, 3, and 4

Class 1, 2, and/or 3 data responses (events class responses) are messages sent by the outstation resulting from a read request by the master that includes object header(s) specifying object group 60, variation 2, 3, or 4. Object group 60 shall not be used in the responses; the responses shall instead include the appropriate event data object(s). Responses may also include Common Time of Occurrence objects (Group 51) if the event data objects are reporting relative time (Table 5-2).




Table T 5-2—Ev vent data inc cluded in eve ents class re esponses Data a type Binary y Inputs (Group 1) 1 Doublee-Bit Binary Inputs (Group 3) Binary y Output Status (Group 10) Counteers and Frozen Counters C (Group ps 20 and 21) Analog g Inputs and Frozzen Analog Inpu uts (Grroups 30 and 31)) Analog g Output Status (Group ( 40) Data Sets (Group 87) Octet Strings S (Group 110) Virtuall Terminal (Grou up 112)

Event dataa included in evvents class resp ponses? All deevices (except foor very simple, llow point-count devices) shall allow w users to assign points of these ddata types to no class, or to one oof the fo our classes (staticc Class 0 or evennt Class 1, 2, or 3), by changing the deevice’s configuraation. d shall thenn include the apppropriate event data for all pointss The device assign ned to event Claass 1, 2, or 3 in itts events class reesponses. All deevices that suppoort these static ddata types shall bbe configurable aas to wh hether appropriatte event data of aany or all points of the specific data type t are includedd in events class responses. All deevices that suppoort this data typee shall include thhe appropriate event data in events cclass responses. All deevices that suppoort Secure Autheentication shall iinclude the appro opriate event dataa in events classs responses.

File Trransfer Objects (Group 70)

Authen ntication (Group 120)

d shall not aallow points of tthis data type to be assigned to nno The device class or to static Classs 0. All deevices that suppoort Secure Autheentication shall aallow users to assign n points of this ddata type to one of the three evennt classes (1, 2, oor 3) by changing the deevice’s configuraation. Securitty Statistics (Gro oup 121)

d shall thenn include the apppropriate event data for all pointss The device assign ned to event Claass 1, 2, or 3 in itts event class ressponses. d shall not aallow points of tthis data type to be assigned to nno The device class or to static Classs 0.

Analog g Input Reporting Deadbands (Group p 34) Internaal Indications (G Group 80) Binary y-Coded Decimal (Group 101) Unsign ned Integer—8-b bit (Group 102)

5.1.5

Eventts are never geneerated for pointss of these static ddata types.

Data proc cessing order

5.1.5.1 5.1.5.1.1

Event an nd static data a Repo orting binary y input and double-bit bin nary input ev vents

When an outstation formulates a DNP3 D responsee containing biinary input andd/or double-bitt event data, thhe binary y input and double-bit binaary input even nts in the respponse shall bbe returned in event time-oofoccurrrence sequencee within the frragment regard dless of their ddata type or ppoint index (i.ee., oldest evennts first, and a newest eveents last). This rule applies irrrespective of w whether the eveent time is repoorted. As an example, Tab ble 5-3 illustraates eight bufffered events annd the order inn which those events shall bbe reported. (For simpliicity, only minutes and secon nds are shown ffor time.)




Table 5-3—Example of event buffering and reporting order Internal buffered ordering Point index

Data type BI

25

Time 4:17

Response fragment ordering Default variation 1

Point index

Data type DBI

10

Time 2:34

Default variation 2

DBI

12

2:51

2

BI

14

—

1

BI

14

2:37

1

BI

25

—

1

BI

25

2:55

1

BI

2

2:50

2

DBI

10

2:34

2

DBI

12

2:51

2

BI

2

2:50

2

BI

25

—

1

BI

25

2:38

1

BI

14

—

1

BI

14

3:05

1

BI

25

—

1

The four left-hand columns in Table 5-3 illustrate the hypothetical ordering of events within an event buffer and show the configured default variation to be used in responses when the master does not specify a reporting variation in its request. The four right-hand columns show the ordering of events in the response to a poll for Class 1, 2, and 3 data. The event at the top of the table appears in the fragment first, and the event at the bottom of the table appears last. The example shows another aspect of reporting—events shall be reported in time sequence order even if, as Table 5-3 shows, it is necessary to create multiple object headers for the same object group and variation. 5.1.5.1.2

Reporting non-binary input and non-double-bit binary input events

When a DNP3 response contains counter, analog, or other event data where more than one event is present for an individual point, then all events for an individual point shall be returned in event time-of-occurrence sequence, earliest first. It is not necessary, as it is with binary and double-bit binary inputs, for the outstation to examine all the point indexes before constructing a response. In responses to Class 1, 2, and 3 polls, there are no requirements for ordering data by point type, and events from the different point types may be inter-mixed or grouped together. 5.1.5.1.3

Mixed event and static data

If a DNP3 response contains event data and static data, the event data shall be reported before the static data. To allow for older outstations that build a response in the order of the object headers in the master’s read request, master requests shall be formulated such that event object headers precede static object headers. A master shall process DNP3 objects returned in a response in the same order that they appear in the received fragment. This causes the sequence of changes appearing in the master’s database to correspond to the sequence order observed in the field, and the final state of each database point contains the most recently occurring event state. If a response contains event data and static data and there has not been an event buffer overflow, the final state after processing the event data should be the same as the static data state. To update a master database in the same order as the corresponding field changes, it is necessary to precede static data reports with unreported event data for the same data points. The correct way to make this happen is for the master to make a single read request for the required event and static data, and for the outstation to respond with any events preceding the static data in the response fragments. This applies to master requests for class data or for data from specific indexes. 107 Copyright © 2012 IEEE. All rights reserved.



NOTE— —Masters should count changees, set operator alarms, a and log new states baseed on changes too the data in theeir databasse and not on wh hether the inform mation was conv veyed from the ouutstations via evvent or static objects.

Whenever a master restarts, an outstation devicce restarts or an outstation’s event bufferrs overflow, thhe potenttial exists for lo osing data. To recover from this t condition, masters shoulld issue an inteegrity poll to thhe outstattion, in order to t collect all pending events and the presennt values of alll points assignned to any of thhe four classes (static Class C 0 or even nt Class 1, 2, or o 3). At the coompletion of thhis processing,, the master wiill a up-to-date im mage of the staates of all poin nts assigned to any of the fouur classes in thee outstation. Thhe have an masterr can then procceed to collect just j events from m the outstatioon and update iits image of thee outstation daata with th he reported eveents. 5.1.5.2

Integrity y poll

A masster should issu ue an integrity poll immediattely after it dettects that an ouutstation restarrted (see 5.1.1.1) or afteer it restarts (seee 5.1.1.2), and occasionally y thereafter, forr data reliabilitty purposes, juust to make suure that th he master’s dataabase matches what is in the outstation. An inttegrity poll req quests all eventt data, followed d by the static data of all poiints assigned too one of the fouur classes (static Class 0 or event Claass 1, 2, or 3). The recommennded sequencee of objects in an integrity pooll is Class 1, Class 2, Class 3, and Class 0 data. In object grouup and variatioon terms, this is a single reaad requesst containing th he following ob bject headers in n the order listeed as follows: a))

Group 60, variation v 2, quaalifier 6

b)) Group 60, variation v 3, quaalifier 6 c))

Group 60, variation v 4, quaalifier 6

d)) Group 60, variation v 1, quaalifier 6 The ou utstation respo onds with all ev vent data, follo owed by the sttatic data of alll points assignned to one of thhe four classes, c in one or more messsage fragmentss. If a point is not assigned to one of the four classes, iits static data shall not be b included in the response. If a response ffragment contaains events, theen the outstatioon r an Application Layer confirm for th hat fragment. shall request 5.1.5.3

Outstatio on event bufffer overflow w processing

An ou utstation devicee indicates thaat it experienceed an event buuffer overflow w by asserting tthe event bufffer overflo ow bit, IIN2.3 [EVENT_BUFFER_OVERF FLOW], in ressponses to the m master. When a master deteccts this siituation, it sho ould issue an integrity i poll in i order to reeestablish the ccurrent state off all data in thhe outstattion device. 5.1.6

Services provided p

The Application A Lay yer provides sp pecific services to the layer abbove it. 5.1.6.1

Masters

The Application A Lay yer provides thee following serrvices for the D DNP3 User Layyer in a masterr: ⎯ Formats req quests directed to one or moree outstations. ⎯ Notifies thee DNP3 User Layer L when new w data or inform mation arrivess from an outstaation.




5.1.6.2

Outstatio ons

The Application A Lay yer provides thee following serrvices for the D DNP3 User Layyer in an outstaation: ⎯ Notifies thee DNP3 User Layer L when acttion requests, ssuch as controol output, analoog output, freezze and file opeerations, arrive from a masterr. ⎯ Requests data and inform mation from th he outstation th that is wanted by a master aand formats thhe responses reeturned to a maaster. ⎯ Assures th hat event dataa is successfu fully conveyedd to a masteer (using Appplication Layyer confirmatio on). ⎯ Sends notiffications to the master when the t outstation rrestarts, has quueued events, annd requires tim me synchronizaation. 5.1.7

Services required r

The Application A Lay yer requires speecific services from the layerrs beneath it. ⎯ Partitioning g of fragments into smaller po ortions for trannsport reliabilitty. ⎯ Knowledgee of which deviice(s) were the source of receeived messagess. ⎯ Transmissio on of messagess to specific deevices or to all devices. ⎯ Message inttegrity (i.e., errror-free receptiion and transm mission of messsages). ⎯ Knowledgee of the time wh hen messages arrive. a ⎯ Either preciise times of traansmission or th he ability to seet time values iinto outgoing m messages.

5.2

Using virtual termin nal objects

5.2.1

General

Many IEDs have separate, non-D DNP3, serial interfaces i usedd for configurration, diagnostics, and other u for connecttion to a dumbb terminal or P PC. The protocol ancillaary tasks. Thesse utility ports are often set up on theese ports is freequently an ASCII command set customizzed for the paarticular IED. V Virtual terminnal (VT) objects provid de a somewhaat transparent means to com mmunicate witth these ports by sharing thhe ng DNP3 bandw width. This sch heme eliminatees the need forr a parallel set oof communicattion links. existin Comm munications bettween the term minal equipmen nt and processses at each endd are transportted over what is called a virtual com mmunication ch hannel (Figuree 5-1). Each vvirtual communnication channnel is assigned a virtuall port number.




Contro olling Device

IED D DNP3 Outstatioon

Terminal 1

DNP3 Masterr

Port 1

Terminal 0

Port 0

Alternate Paths

Alternate Paths

Terminnal Command Innterpreter

Terminnal Command Innterpreter

Group 112 Objects O Group 113 Objects O

Figure 5-1—Virttual channels s illustrated The IE ED can be view wed as containiing one or morre terminal com mmand interpreters. Each terrminal commannd interprreter may be associated witth a physical port or a virttual port, or bboth, at the ddiscretion of thhe implem mentation. A key k issue is thaat the IED treaats the DNP3 virtual terminaal channel justt like it wouldd a physiccal channel. Iff the IED supp ports more than n one kind of command inteerpreter, uniquue DNP3 virtuual termin nal indexes are used to identiffy them. 5.2.2

Group 112 2 and 113 ob bjects

VT ob bjects emulate binary octet data d streams going g to and frrom a device. The Virtual T Terminal Output Block, group 112, is used for datta going to an outstation devvice, and the Virtual Terminal Event Datta, or data coming g from an outstaation device. M More details aree provided in A Annex A. group 113, is used fo The prrocedure for communicating g with these DN NP3 objects iss as follows. M Master devices transmit data to outstattion devices by y writing one or o more group 112 objects ussing the DNP3 point index nuumber to speciffy the virrtual port numb ber. Outstaations return information i to o the master by respondingg to read reqquests for objject group 113, respon nding to read requests for thee configured ev vent class, or trransmitting an unsolicited ressponse messagee. The co ontent of the data d in the VT objects is speccific to the partticular terminaal protocol. DN NP3 masters annd outstattions do not need n to know any a of the dettails of the terrminal protocool; DNP3 doess not assign anny signifiicance to any of o the data octeets in VT objects.




5.2.3

Virtual terrminal examp ple In the following hypotheetical example of a VT sessioon: Data octetts in the group p 112 and 113 objects follow w “data=” betw ween pairs of single quotes ‘ ’. The singlee quotes are no ot in the messag ges.

EX 5-1

represents the Carrriage-Return character c (0x0D D). The point index is not sh hown but is asssumed to be thee same in all m messages. Comments begin with a double forwarrd slash, //, andd continue to tthe end of the line. Commennts are to clarrify the examplle and do not ap ppear in the m message.

1) Masterr: Write g112v1 1, data=’ >’ // wakeup coommand 2) Outstattion: Null respo onse 3) Masterr: Read g113v0 0 4) Outstattion: Null respo onse // outstation has no dataa to send to master 5) Masterr: Read g113v0 0 6) Outstattion: Respond with w g113v3, data=’OK d >’ 7) Masterr: Write g112v6 6, data=’CLEA AR’ // cleear outstation ccommand 8) Masterr: Write g112v7 7, data=’LOGO OFF’ // eend the IED sesssion 9) Masterr: Read g113v0 0 10) Outstattion: Respond with w g113v7, data=’OK d >BYE’ 5.2.4

Discontinuous octet streams s

Data flowing f in eitheer direction can n be pictured as a “discontinuoous octet stream ms” whereby thhe gaps betweeen characcters are unpredictable—som me long and som me short. A seet of octets in tthe stream is “ppacketized” innto group 112 or 113 DNP3 D objects; however, h the packets p do nott necessarily ddelimit complette commands oor nses. In the preeceding example, packets do contain compllete commandss and responses, but that is nnot respon necesssary. The master m is permittted to send mu ultiple messag ges without inteervening polls for responses (see step 7) annd step 8)) of the example in 5.2.3). The ou utstation is permitted to accumulate and concatenate c ressponses to multiple commannds into a singgle event object (see sttep 10) of the example in 5.2.3). 5 It is al so acceptable for the outstaation to prepaare r the multtiple events in the t same mess age. separaate events and return Masters are permitteed to send parttial or multiplee commands w within a single write operatioon. Similarly, aan ond with partiaal information, and the masterr shall continuue to read the ddata until there is outstattion may respo no mo ore. 111 Copyright © 2012 IEEE. All rightts reserved.



5.2.5

Rules

DNP3 does not speccify any explicit rules for how w masters and outstations coooperate with eeach other in thhe g of terminal commands c and responses. The rules are a loocal issue that ddepend on the terminal desiggn. issuing It is in ncumbent on th he master and outstation useer software to ffully understannd the commannd structure annd the nature of the dataa streams betw ween themselves. Messaages can flow in either direcction at any tiime. There aree no DNP3 prrocedures for the initiation oor conclu usion of a VT session; s i.e., im mplicit connecttions exist by thhe mere presennce of a VT coompatible mastter and ou utstation. The master m and ou utstation split the responsib bility for VT maintenance. Masters are responsible fo for maintaaining an enviironment that allows outstations to return responses in a timely mannner. In a polleed system m, the master shall s periodicaally poll for ou utstation responnses wheneverr a response iss possible. In aan unsolicited response environment, both ends shalll check that thhe background data traffic is at a low enouggh level that t outstation responses r can be sent withou ut impacting moore important eevent data. 5.2.6

Virtual terrminal bandw width considerations

IEDs with w large amo ounts of data transportable t over o virtual coommunication channels shouuld be careful to limit their t usage of the t DNP3 link. One possibiliity is providingg a configuratiion to select which Class, 1, 2, or 3, th hat group 113 objects are asssigned. Anoth her possibility is i to limit the amount of virttual terminal ddata that outstaations transmit to less than thhe alloweed 255 maxim mum octets perr message. Lim miting the lenggth of messagge strings ensuures the greateest compaatibility with memory-limite m d devices and allows other higher priorityy messages to be intersperseed with VT V messages. Choosing a data size so that t responsess fit within a single Data L Link frame caan sometiimes simplify and a reduce thee amount of virrtual terminal trraffic. In an unsolicited u env vironment, it may m be desirablle for outstationns to implemennt a scheme that constrains thhe amoun nt of data they y transmit (com mbination of message m size annd message frrequency) in orrder to limit thhe overalll system bandw width utilized for f this functio on.

5.3

Sequenttial file trans sfer

Sequential file transffer implies thatt complete filess are read or w written, startingg from beginninng to the end. File trransfer objects defined for grroup 70 variatiions 2 throughh 7 are applicabble for sequenttial file transfeer. The orriginal File Ideentifier object g70v1 g has been n superseded. Sublau uses 4.4.17 thrrough 4.4.19 describe d the fu unction codes aassociated withh file transfer in detail, whicch are no ot repeated heree. This subclau use is intended to explain how w to use the funnctions and objjects for readinng and writing files and d for determinin ng which files exist in an outtstation. 5.3.1

Authentic cation

An ou utstation may reequire authentiication before opening or delleting a file. Thhis requires thhe master to paass requesst authenticatio on by issuing a request using g function codee AUTHENTIC CATE_FILE aand including aan Authentication objecct, g70v2. This request contaiins a user namee and passwordd. The outstation returrns an Authenttication objectt, g70v2, with an authenticaation key that is subsequenttly entered in the autheentication key field of the g70v3 object appearing in the following open or deleete v for one use u only. It exppires as soon as it is used, or upon timeout at requesst. The authenttication key is valid the ou utstation, which hever occurs firrst.




Outstaations should generate key ys using a prrivate pseudo random algoorithm; each request for aan authen ntication key should s yield a unique key. An A authenticatiion key value of 0 indicates that permissioon was deenied or that th he requested peermission was not n granted. It is possible p for th here to be a set s of user nam mes and passw words that havve different ppermissions, annd outstattions may use authentications to limit file access a as is deeemed suitable ffor the applicattion. The detaiils are a local issue beyo ond the scope of o this standard d. 5.3.2

File permiissions

The crreator of a filee sets its permiissions. Unlesss otherwise agrreed to by the capabilities off the master annd outstattion, the bits in n all three classsifications, wo orld, group, annd owner, shalll be set the sam me. Permissionns when returned in an ny response sh hall indicate th he current requuestor’s privileeges, and the bits in all threee b set the samee. classiffications shall be The reead privilege gives g the user th he right to ⎯ Read the fille using functio on code OPEN N_FILE with opperation mode READ. ⎯ Retrieve file information using u function code GET_FIL LE_INFO. The write w privilege gives g the user the t right to ⎯ Write the fiile using functiion code OPEN N_FILE with opperation modees WRITE and APPEND. ⎯ Delete a filee using functio on code DELET TE_FILE. The ex xecute privileg ges gives the usser the right to ⎯ Initiate actions that use the file’s contentts when using a function codde that includess a file specifier. 5.3.3

Reading a file

This subclause s prov vides an overviiew of the pro ocedures for reeading a file. T The reader shoould refer to thhe functio on code descriiptions in 4.4.1 17 for details of o each operatiion. Reading a file consists oof the followinng transactions: ⎯ Optional au uthentication. ⎯ Open file. ⎯ One or morre read requestss. ⎯ Close file. If the system requirees an authenticcation key to open o a file, thee master issuess an authentication request aas outlineed in 5.3.1. Open file, f read, and d close file req quests return ev vent objects. F File events havve an associateed event class in the sam me manner as other DNP3 events. e File ev vents are reporrted from an ooutstation to thhe master statioon using the standard DNP3 D event rettrieval methods. If the outstaation is able to respond immeediately to a fiile urn the approprriate event object. But if it ccannot, the out utstation responnds immediately requesst, it shall retu with a null response having no dataa objects, and thereafter it is the master’s reesponsibility too poll for evennts (assum ming unsoliciteed reporting is not used). Thee master may iissue polls eithher for event classes or for thhe specifi fic event object expected, deepending on sy ystem configurration, until thhe expected ressponse object is returned, or a local tiimer in the master times out.




NOTE 1—System designers need to coordinate which polls the master should issue while waiting for event file objects in the response. The outstation needs configuration for whether to return file event objects in polls for class event data. See 4.6.2. The master should accommodate whichever way the outstation is configured. NOTE 2—It is permissible to use unsolicited reporting to return file event objects if the master and outstation devices support it and the system designer chooses this alternative.

To open a file, the master issues a message using function code OPEN_FILE. This message requires File Command object, g70v3, containing the appropriate information. A File Command Status event object, g70v4, is returned. If the status code in the returned object is zero, the file was successfully opened, and the application shall use the returned 32-bit file handle during read requests to the file until it is closed. A nonzero status code indicates that the file was not opened, and that the file handle value is invalid. The maximum block size permitted for transferring file data is negotiated during the open process. For reading a file, the master states the maximum number of octets it can accept in the File Command object, g70v3. The outstation shall set a size, which is the lesser of the value in the master request or a limitation in the outstation, into the maximum block size field in the response’s File Command Status object, g70v4. The outstation shall not transfer more octets than the block size it returned in the response. To obtain the file data, the master issues one or more read requests using a File Transport object, g70v5, specifying the file handle and the block number. The block number starts at 0 in the first read request and shall increment by 1 for each subsequent read request. If no errors are detected, the outstation shall respond with a File Transport event object, g70v5, containing data read from the file. NOTE 3—The master should not assume that each block, except the last, has an identical size. Both the outstation and the master should update their local file offset indicators after each read request. NOTE 4—The master does not set the last bit in read requests, but the outstation does set it in the responses. See the description of a File Transport object, g70v5, in A.27.5.

If the outstation detects an error associated with the read request, it shall return a File Transport Status event object, g70v6, with an appropriate status code. After all of the file data has been transferred from the outstation, the last bit being set in the response object, the master issues a close file request having a File Command Status object, g70v4. This object is not an event object when used in the request. The outstation responds with a message containing an identical File Command Status object as that which appeared in the request.

EX 5-2

This is an example of a file read request. Assume that file events are configured for Class 3.


01 FC

46 Grp

05 Var

5B Qual

01 Range

08 00 Size prefix

66 ←

77

88

►►► Continuation of Request Message 99 02 00 00 File Transport Status object

00 →




Becau use the outstatiion cannot fetcch the file dataa immediatelyy, it sends a nuull response annd waits for thhe masterr to poll for event data. ◄◄◄ ◄ Response Message M C3 AC

81 C FC

•••

00 IIN1

00 IIN2

N maaster polls for Class C 3 data, eaach followed by y an outstationn null response.. ••• ►►► ► Request Messsage CE AC

01 C FC

3C Grp

04 Var

06 Quaal

◄ Response Message M (beginn ning) ◄◄◄ EE AC

81 C FC

00 IIN1

00 IIN2

46 Grp p

05 Var

5B Qual

01 Rangge

16 000 Size prefixx

66 ←

00

00

80

A5

A5

A A5

A5

A5 A5 5 A5 A5 A5 File Transp port Status objeect continued

A5

A5

A5

A5

A A5

◄ Continuation n of Response Message M ◄◄◄ 77 88 8 99 00 File Transp port Status objeect ◄ Continuation n of Response Message M ◄◄◄ →

► Confirm Message ►►► CE AC 5.3.4

00 0 FC C

Writing a file

This subclause s prov vides an overviiew of the pro ocedures for w writing a file. T The reader shoould refer to thhe functio on code descriiptions in 4.4.1 17 for details of o each operattion. Writing a file consists oof the followinng transactions: ⎯ Optional au uthentication. ⎯ Open file. ⎯ One or morre write requestts. ⎯ Close file. If the system requirees an authenticcation key to open o a file, thee master issuess an authentication request aas outlineed in 5.3.1. Open file, write, and a close file requests retu urn event objeects. If the ooutstation is aable to responnd diately, it shaall return the appropriate event e object. But if it cannnot, the outsstation respondds immed 115 Copyright © 2012 IEEE. All rightts reserved.



immediately with a null response having no data objects, and it is the master’s responsibility to poll for events (assuming unsolicited reporting is not used). The master can issue polls either for event classes or for the specific event object expected, depending on system configuration, until the expected response object is returned, or a local timer in the master times out. NOTE 1—System designers need to coordinate which polls the master should issue while waiting for event file objects in the response. The outstation needs configuration as whether to return file event objects in polls for class event data. See 4.6.2. The master should accommodate whichever way the outstation is configured. NOTE 2—It is permissible to use unsolicited reporting to return file event objects if the master and outstation devices support it and the system designer chooses this alternative.

To open a file, the master issues a message using function code OPEN_FILE. This message requires File Command object, g70v3, containing the appropriate information. A File Command Status event object, g70v4, is returned. If the status code in the returned object is zero, the file was successfully opened, and the application should use the returned 32-bit file handle during write requests to the file until it is closed. A non-zero status code indicates that the file was not opened and that the file handle value is invalid. The maximum block size permitted for transferring file data is negotiated during the open process. For writing a file, the master states the maximum number of octets it can transfer in the File Command object, g70v3, based on its own limitations. The outstation shall set a size, which is the lesser of the value in the master request or a limitation in the outstation, into the maximum block size field in the response’s File Command Status object, g70v4. The master shall not transfer more octets than the block size returned from the outstation. To write data, the master issues one or more write requests using a File Transport object, g70v5, specifying the file handle, the block number, and the data octets to be written. The block number starts at 0 in the first write request and shall increment by 1 for each subsequent write request. The master shall set the last bit in the last block. If the outstation is unable to save the data immediately, it shall return a null response (no data objects), and after the data is saved, it returns a File Transport Status event object, g70v6, with an appropriate status code to indicate the success of the operation. However, if the outstation is fast enough, it may return the File Transport Status immediately as the response to the write request. NOTE 3—The outstation should not assume that each block, except the last, has an identical size. Both the outstation and the master should update their local file offset indicators after each write request.

If there is an error during the write process, the status code in the File Transport Status event object, g70v6, shall indicate the problem. After all of the file data has been transferred to the outstation, the master issues a close file request having a File Command Status object, g70v4. This object is not an event object when used in the request. The outstation shall respond with a message containing an identical File Command Status object as that which appeared in the request.

EX 5-3

This is an example of a file write request.


02 FC

46 Grp

05 Var

5B Qual

01 Range

13 00 Size prefix

66 ←

77

88




►►► ► Continuation n of Request Message M 99 02 2 00 00 File Transp port Status objeect

80

A5

A5

A5

A5

A A5

A5

46 Grp p

06 Var

5B Qual

01 Rangge

09 000 Size prefixx

66 ←

00

00

80

00

► Continuation n of Request Message M ►►► A5

A5 5

A5

A5

A5 →

◄ Response Message M (beginn ning) ◄◄◄ E3 AC

81 C FC

00 IIN1

00 IIN2

◄ Continuation n of Response Message M ◄◄◄ 77 88 8 99 02 File Transp port Status objeect

→

► Confirm Message ►►► C3 AC 5.3.5

00 0 FC C

Retrieving g individual file f informatiion

The master m issues a request to the outstation usin ng function coode GET_FILE E_INFO with a File Descriptoor objectt, g70v7. The outstation o resp ponds with the requested infoormation in a F File Descriptor object. This is describ bed in 4.4.18. If the file is a directo ory, the file typ pe field in the response r shall bbe set to 0 andd the file size fiield specifies thhe numbeer of entries in that sub-directtory excluding any links to ittself or its pareent. 5.3.6

Retrieving g file directory informatio on

Directtory files are special s types of o files that holld informationn about all of tthe files withinn organizationnal units called c “directorries” and “sub-directories.” Each E directory file contains iinformation abbout a set of 0 oor more standard files and other direectory files, which w are know wn as sub-direectories. Regarrdless of how a ganizes its filing system, it shall have thee ability to maap to directory files. The terrm devicee internally org empty directory referrs to directoriees that contain no n informationn about other fiiles or sub-direectories. Inform mation can be retrieved r for alll the files in a directory by reeading the direectory file. Thee read request is as described in 5.3.2 2 where the filee handle is that obtained durinng the open fille request, whicch contained thhe for name of the directorry file. The reesponse to the read request ccontains a Filee Transport obbject, g70v5, fo d file reeferenced in thee read request.. each directory The data d returned in n File Transpo ort objects for directory filess is formatted similar to a ssequence of Fiile Descriiptor objects, g70v7. g An objject header is not n included in the data, annd there is one “file descriptoor elemen nt” for each fiile. Also, if on ne or more of the t returned fiiles are themseelves sub-direcctories, their fiile type fiields are 0 and their file size fields f indicate the t number off files in the resspective sub-diirectory file. Thhe file sizze reported for empty directories and sub-diirectories shalll be 0.




The file name string fields in the returned file descriptor elements only contain the base file name and do not include full path information as that information is already known from the File Descriptor object in the read request.

Assume that an outstation has the following directory structure:

file0 dir1 file1 EX 5-4

file2 dir2 file3 dir3 file4

NOTE—nn in the tables that follow represent appropriate hexadecimal numbers whose exact values are not important for the sake of illustration.

If the master were to read the root directory file, it would receive data in the File Transport object that appears like this (least significant octets are at left side of field): Filename offset (hex) 14 00 14 00 14 00

Filename size (hex) 05 00 04 00 04 00

File type (hex) 01 00 00 00 00 00

File size (hex) nn nn nn nn 03 00 00 00 01 00 00 00

Time of creation (hex)

Permissions (hex)

nn nn nn nn nn nn

00 00

nn nn nn nn nn nn

00 00

nn nn nn nn nn nn

00 00

Request Id (hex) nn nn nn nn nn nn

File name octets (ASCII) file0 dir1 dir3

If the master were to read the dir1 file, it would receive data in the File Transport object that appears like this (least significant octets are at left side of field):




Filenamee offset (hex) 14 00 14 00 14 00

Filename size (hex) 05 00 05 00 04 00

File type (hex) 01 00 01 00 00 00

File F size (hex) nn nn nn nn nn nn nn nn 01 00 00 00

Time of creattion (hex)

Perm missions ((hex)

nn n nn nn nn nn nnn

00 000


00 000


00 000

Reequest Id (h hex) nn nn nn nn nn nn

File n name octeets (ASC CII) file1 file2 dir2

When an empty direectory file is read, the responsse contains a F File Transport object header aas usual, but thhe associated File Transsport object haas no data octetts. 5.3.7

Deleting a file

This subclause s prov vides an overviiew of the procedures for deeleting a file. T The reader shoould refer to thhe functio on code descriptions in 4.4 for details of each operatioon. Deleting a file consists oof the followinng transactions: ⎯ Optional au uthentication. ⎯ Delete file. If the system requirees an authenticcation key to delete d a file, thee master issuess an authenticcation request aas outlineed in 5.3.1. The master m issues a request to thee outstation ussing function ccode DELETE E_FILE with a File Commannd objectt, g70v3. The outstation o respo onds when a File F Command Status event oobject, g70v4, iis returned. Thhis is desccribed in 4.4.17 7.1.2. 5.3.8

Rules rela ating to files

⎯ Rule 1: Ass is the case for f all event objects o returneed from the ooutstation, the outstation shaall request an Application A Laayer confirmatiion from the m master. ⎯ Rule 2: If a file is opened d for non-appen nded writing, itt shall be trunccated to zero leength. ⎯ Rule 3: If a file is open ned for writing g, the time off creation and permission fiields in the Fiile o g70v3, that appears in i the open fille request shalll be used as aattributes for thhe Command object, file in the outstation. ⎯ Rule 4: Thee outstation maay reject requeests to create filles with permissions that it ddoes not allow oor cannot supp port. ⎯ Rule 5: Outstations are no ot required to support s appendded writing. ⎯ Rule 6: If the t end of filee is indicated in n a device recceiving a file bbefore the expeected file size is satisfied, th he receiving device shall treatt the file as com mpletely receivved and not coonsider this to bbe an error con ndition. ⎯ Rule 7: If the end of a file fi is longer (h has more octetts) than the fille size expecteed, the receivinng y treat this as an n error and rejeect the transferr. device may ⎯ Rule 8: A file f size of 0xF FFFFFFFF is permitted p in a F File Commandd object in a w write request annd indicates th he actual size iss unknown. Devices are not reequired to acceept an unknow wn file size. ⎯ Rule 9: Filee handles are unique u to an ou utstation. No asssumptions shoould be made rregarding handdle numbers, an nd there shall be b no correlatio on between thee handle numbeer and any funnction or speciffic set of data. Outstations sh hall not reuse fiile handles exc ept after a resttart. 119 Copyright © 2012 IEEE. All rightts reserved.



⎯ Rule 10: Devices D may lim mit the numbeer of files simuultaneously opeened to any nuumber includinng just one. ⎯ Rule 11: An A opened filee may not be deleted. d If the master attemppts to delete aan open file, thhe outstation shall return a file locked errorr. ⎯ Rule 12: Iff a file is openeed and there is no activity refferencing the ffile handle, thee outstation shaall automaticallly close the fille. The timeoutt value shall bee configurable up to one hourr. The final staate of a file clo osed due to acctivity timeoutt is undefined. When this coondition occurss, the outstatioon shall send a File Transpo ort Status objecct using a statuus code value of HANDLE__EXPIRED (seee Table 11-8)). ⎯ Rule 13: When W an error is i detected by an a outstation uupon receipt off a read requesst, the outstatioon shall autom matically close the t file and forrce the file handdle invalid. ⎯ Rule 14: When W an error is detected by an a outstation uppon receipt of a write requesst, the outstatioon shall autom matically close the file and fo orce the file haandle invalid. T The contents oof the file in thhe outstation are a indeterminaate. ⎯ Rule 15: Directory files may m only be op pened for readinng. Masters aree not permittedd to write them m. ⎯ Rule 16: The root directo ory may not bee deleted. The vendor may choose whetherr none, some, oor D If a venndor allows the master to deelete a directorry, all sub-direectories may bee deleted via DNP3. the vendor may m also speciify whether thee included filess and sub-direcctories shall bee deleted first, oor whether delleting the direcctory also delettes all of its filees and sub-direectories.

5.4

Data sets

5.4.1

Preliminary background

It is ad dvantageous in n some systemss for DNP3 dev vices to be ablle to transport sstructured dataa that consists oof a posssibly non-homo ogeneous colleection of data types. t Prior to data sets, the emphasis wass on transportinng simplee binary inputss, analog and counter c values moving towarrd the master aand control andd analog outpuuts movin ng toward the field. f For ex xample, an eleectrical system relay might have h somethingg called a virtu tual fault objecct that it uses to report the system co onditions when n a fault event occurs. This oobject might ccontain the currrent in all threee phasess immediately before a break ker operation, which w parametters triggered tthe breaker opeeration, the fauult classiffication, and th he computed diistance to the faault. One advantage of daata sets is that the data can bee kept togetherr so that snapsshots of an objeect are availabble d of attemptin ng to form a view v of an ob bject from diffferent pieces oof data that w were collected at instead differeent times and th he necessity off having to put the pieces tog ether at the recceiving end. The vaalues placed in nto a data set are a not always available for rreading on dem mand. In the faault example, thhe valuess represent a trransient situatiion, one that only o occurs uppon detection oof a fault. Theere is no way to record d the distance to o a fault until there t is a fault. There are alsoo situations whhere the data dooes not fit neatly into one o of the exissting point typ pes such as an nalog inputs, bbinary inputs, or counters; the type of gaas transported in a pipeeline is an exam mple. It is helpful h to see the t contents of a few samplle data sets priior to getting into formal deetails. Using thhe electriical system fau ult from above as an example, the collectionn20 of data migght contain the elements show wn in Tab ble 5-4.

20

The term t “collection” is i used in this document as a noun to t represent a grouup or set of data. IIt was chosen to aavoid confusion wiith other terrms that have a specific meaning in DNP3.




Table T 5-4—Ellectrical faul t data set Data type

Descrription

Timee

When fault occcurred.

Floating-point

Current phase A. A

Floating-point

Current phase B. B

Floating-point

Current phase C. C

Floating-point

Ground currentt.

Bit string s

Parameters that triggered breakker.

Textt string

Fault classificaation.

Integ ger

One-hundredth hs of kilometer ddistance from subbstation.

There are eight data elements. Each has a basic data d type—tim me, floating-poiint value, bit sttring, text strinng, nteger. and in An eleectrically operaated pump is an nother examplee of a data set ((Table 5-5). Tablle 5-5—Pump p-valve data set example e Data D type

D Description

Integer

Open positiion 0 to 100 perccent.

Floating-p point

Flow rate.

Integer

Downstream m pressure.

Integer

Fluid tempeerature.

Floating-p point

Fluid’s specific gravity.

Integer

Motor voltaage.

Integer

Motor curreent.

Integer

RPM.

Integer (bo oolean)

Operating (on/off ( state).

There are many real-world examplles of where th he same data seet structure is rrequired repetiitively. Considder d to incluude the three-pphase voltages,, currents, wattts, an electrical feeder. If a data set sttructure were defined b reused for each e of the mulltiple feeders inn a substation. Another exam mple is a data sset VArs, etc., it could be ure for conveying the first 32 2 harmonics on n an electrical phase wire. Thhe same structuure is usable fo for structu each of o the three ph hases. Lastly, consider c the waater wells in m many municipaalities. If there were a data sset structu ure defined forr a well, the sam me structure ap pplies to each w well around thee city. 5.4.2

Data set, data d set desc criptor, and data set prottotype overv view

DNP3 uses three bassic constructs to t describe and d convey data ssets: a Data Set, a Data Set D Descriptor, andd a S Prototype. Data Set 5.4.2.1

Data sett

A Datta Set is a construct that conv veys the actual values in the ccollection. Dataa sets also conttain an identifier to ind dicate which sp pecific data co ollection and at a least one tiime value, thee time when thhe data set waas created d. A data set iss used during runtime r for traansferring a colllection of dataa values from tthe outstation to the maaster, or vice versa. To min nimize the com mmunications bbandwidth, a ddata set only ccontains enouggh overheead octets for the t receiver to parse p the objecct. Data sets s are constru ucted from a seequence of elem ments. Each eleement providess a single valuee. 121 Copyright © 2012 IEEE. All rightts reserved.



The specific DNP3 group numbers associated with data sets are 87 and 88. 5.4.2.2

Data set descriptor

A Data Set Descriptor is a construct containing meta-data describing the data appearing in a data set. Its purpose is to provide information regarding the structure, ordering, and type of data values within a data set. Data set descriptors are constructed from a sequence of elements called descriptor elements. Each describes a data element in the data set, a reference to a data set prototype or a name attribute. The specific DNP3 group number associated with data set descriptors is 86. NOTE—For the remainder of 5.4, when the term descriptor is used alone, it refers to data set descriptor.

5.4.2.3

Data set prototype

A Data Set Prototype is a construct that contains a list of descriptor elements that define a group or subset of elements that exist in a data set. Reference to a prototype appearing in a data set descriptor provides a shorthand method for indicating that the data set contains elements described by the list of descriptors in the prototype. Prototypes serve two main purposes. They allow vendors and third-party standards groups to predefine a subset of elements that shall appear within a data set. Second, they reduce the number of octets in messages transporting data set descriptors when the same pattern would otherwise appear repeatedly. The specific DNP3 group number associated with data set prototypes is 85. NOTE—For the remainder of 5.4, when the term prototype is used alone, it refers to data set prototype.

5.4.2.4

Relationship of data sets, data set descriptors, and data set prototypes

Data sets and descriptors occur in pairs. Data set prototypes are optional.




Figure 5-2—Relationships The descriptor provides information needed by the receiving device to interpret the sequence and type of elements in the data set. A data set transfers values during normal runtime. Its element ordering is as specified by the corresponding data set descriptor. A data set descriptor may reference one or more prototypes instead of including the descriptor elements from the prototype. 5.4.2.5

Read, write, and control

Depending on a data set’s purpose or reason for existing, a master can ⎯ Request to read a data set. ⎯ Request to write a data set. ⎯ Issue a control command incorporating a data set object. See 5.4.11 for an in-depth discussion about control commands.




A few examples: Data sets that convey values measured in the outstation are readable by the master. A master writes new parametric values to an outstation configuration data set and reads it back to confirm the values. A master issues a select–operate command to load new integral, derivative, and gain factors for a PID algorithm. 5.4.2.6

Data set and data set prototype definition

Data sets and data set prototypes are defined by an outstation or by a master depending on which is responsible for the structural design. 5.4.2.6.1

Outstation defined

A data set is defined by an outstation if the outstation determines its structure. Before transferring a data set defined by an outstation, the master shall know how its data is organized. A data set descriptor contains this information, and the master shall read the data set descriptor from the outstation. If a data set descriptor references a data set prototype, the master shall read the prototype from the outstation. NOTE—It is permissible for masters to save descriptor information in cache or configuration memory so that reading data set descriptors is not necessary.

Examples of data sets defined by the outstation are the faults and pump-valves discussed in 5.4.1 and outstation configuration. In these situations, the outstation defines the data structures. The outstation may not dynamically define data sets after it restarts. Outstation-defined data sets are determined by configuration. If new configuration is downloaded from the master (via file transfer or other means) that adds new, or revises or removes existing, outstation-defined data sets, the outstation shall restart its DNP3 application (and set IIN1.7) prior to the outstation using the changed definitions. The outstation may not dynamically define data set prototypes after it restarts. Outstation-defined prototypes are determined by configuration. If new configuration is downloaded from the master (via file transfer or other means) that adds new, or revises or removes existing, outstation-defined data set prototypes, the outstation shall restart its DNP3 application (and set IIN1.7) prior to the outstation using the changed definitions. 5.4.2.6.2

Master defined

A data set is defined by a master if the master determines its structure. In some situations, a master can define a data set in the outstation. Before an outstation can parse a data set defined by the master, the outstation shall know how its data is organized. A data set descriptor contains this information, and the master shall write the data set descriptor to the outstation. If the data set descriptor references a data set prototype, then the master shall also write the prototype if it does not already exist in the outstation. A data set containing a sequence of algorithmic values executable in a local automation application would be an example of a data set defined by master. In this example, the outstation cannot know ahead of time what steps it should execute until the master conveys them. Data sets defined by the master shall be readable and writable. This allows the master to read back, for verification purposes, the same information that it wrote. The outstation shall not change the definitions of master-defined data sets or data set prototypes.




Masters and outstations are not required to support data sets or prototypes defined by the master. This ability is optional, even for devices that support data sets and prototypes defined by the outstation. 5.4.2.7

Transmission sequence

Data sets are transmitted when appropriate. An outstation may send an event data set when an event occurs, or it shall send a static (present value) data set if requested by the master. A master may write data sets when it has new information for the outstation. Before a receiver can parse a data set, it is necessary for the receiver to know the data organization within the data set. Data set descriptors contain this information, and therefore, for data sets defined by an outstation, the master shall read the data set descriptors from the outstation, or retrieve them from cache or configuration memory. Similarly, for data sets defined by the master, the master shall write the data set descriptors to the outstation before that master can transmit the data sets. If a data set descriptor contains a reference to a data set prototype, then it is necessary to exchange the prototype. If both receiving and transmitting devices have knowledge of the prototypes, from cache, configuration tables, or reading them from a web server, it is not necessary to exchange the prototypes at startup. It is not mandatory to request a read or a write of descriptors immediately following an outstation restart; however, it is advisable to do so if the outstation transmits event data sets. It is not required that data descriptors be written or read if they are guaranteed to be known by both ends after the master or outstation restarts. After a restart, outstations are not required to remember data set descriptors written to them previously by a master. Likewise, masters are not required to remember descriptors they uploaded before a restart. Masters and outstations shall be able to transmit their descriptors even if it is unnecessary in certain systems. Devices may not assume that the other end shall never need transference of data set descriptors. This provides greater assurance of interoperability. Because the master station can restart at any time without the outstation being aware, outstations shall be prepared to receive requests to read or write descriptors at any time, even though similar requests were received previously. Data set prototypes are more likely to be standardized and pre-defined than are data set descriptors, and there is reason to believe some shall be available in libraries. It is not necessary to exchange prototypes if they are guaranteed to be known by both ends after the master or outstation restarts. As with descriptors, masters and outstations shall be able to transmit their prototypes even if it is unnecessary in certain systems. Devices may not assume that the other end shall never need transference of data set prototypes. This provides greater assurance of interoperability. Masters may write descriptors and prototypes in any order. Outstations shall not assume that master stations shall write data set prototypes before writing data set descriptors to the outstation. Outstations shall reject a master request to write a data set if the outstation does not have knowledge of the complete data set structure, which is obtained from the data set descriptor and any data set prototypes the descriptor references. It does this by setting IIN2.2 [PARAMETER_ERROR] in the response. Outstations shall accept a master-defined prototype that duplicates an already existing outstation-defined prototype, the only difference being the ID. This includes the ability for the master to read back the data set prototype with the same ID that it previously wrote. Because the master station can restart at any time without the outstation being aware, outstations shall be prepared to receive requests to read or write prototypes at any time, even though similar requests were previously received. 125 Copyright © 2012 IEEE. All rights reserved.



5.4.2.8 5.4.2.8.1

Identifiers Data set and data set descriptor identifiers

The identifier in a data set is the key that a parser uses to interpret the data set contents according to the information in the corresponding descriptor. Data set identifiers have integer values and differentiate one data set from another. They also serve as index numbers when a master requests to read a specific data set descriptor or data set. The same identifier shall be used for a data set that is readable and writable. If the master does not already know which descriptors are in the outstation, it shall first read all of the descriptors for the data sets defined by the outstation, and then for data sets defined by the master, transmit the master’s unique descriptors. The master shall use the identifiers appearing in descriptors obtained from the master’s initial read of data set descriptors from the outstation. The master may not re-number or provide duplicate identifiers for those data sets that are both read and written. Data set identifiers shall be contiguous. An outstation shall begin its numbering from zero and count upward without gaps. The burden of assuring that identifiers are sequential for the data sets defined by a master belongs to the master. When a master station defines data sets, the identifier numbers shall begin where the outstation left off. For example, the outstation defines N data sets and the master defines M data sets. The outstation sends descriptors 0 through (N – 1) when the master requests to read its descriptors. The master shall assign identifier N to its first descriptor, (N + 1) to its second, and so on, and writes them to the outstation. Because data sets can be unique from outstation-to-outstation and from vendor-to-vendor, each data set definition has an integer identifier that is unique to an outstation–master pair. Masters that communicate with multiple outstations shall keep separate lists of identifiers for each outstation. Similarly, outstations that communicate with multiple masters shall keep separate lists of identifiers for each master. It is not permitted to require a specific index ordering of data sets. An outstation is permitted to assign any index to any data set as long as the indexes are contiguous and numbering begins with zero. To aid the master station in determining the number of data sets that are available in the outstation, the outstation shall support Device Attributes, group 0, variations 214 and 215, at index 0. 5.4.2.8.2

Data set prototype identifiers

The identifier illustrated in Figure 5-2 of a data set prototype is unrelated to the identifier of the data set descriptors that reference the prototype. Prototype identifiers have integer values and indicate a sequential index into a list of prototypes in a specific outstation; they are used as index numbers when a master requests to read or write a specific prototype. The same identifier shall be used for a data set prototype that is readable and writable. If the master does not already know which prototypes are in the outstation, it shall first read all of the prototypes defined by the outstation, and then for data set prototypes defined by the master, transmit the master’s prototypes. Prototype identifiers shall be contiguous. An outstation shall begin its numbering from zero and count upward without gaps. The burden of assuring that identifiers are sequential for the data sets defined by a master belongs to the master. When a master station defines data set prototypes, the identifier numbers shall begin where the outstation left off. For example, the outstation defines N data set prototypes and the master defines M prototypes. The outstation sends descriptors 0 through (N – 1) when the master requests to read its prototypes. The master shall assign identifier N to its first prototype, (N + 1) to its second, and so on, and writes them to the outstation.




To aid d the master station in deteermining the number of daata set prototyypes that are aavailable in thhe outstattion, the outstaation shall supp port Device Atttributes, groupp 0, variations 2212 and 213, aat index 0. 5.4.3

Data sets are application specific

DNP3 does not attem mpt to define a suite of standard data sets.. Data set definnition dependss on the speciffic m possibilitiies for DNP3 too attempt standdardizing them m all. application, and therre are far too many This does d not precclude special interest group ps from develloping pre-deffined data setts and data sset prototy ypes. For exaample, it may be possible for f a relaying group to deffine a standardd fault data sset prototy ype. Likewise,, it might be acchievable to deefine collectionns of data sets that permit DN NP3 to transpoort data frrom non-DNP3 3, object-orientted protocols. The T definition of those data ssets is outside tthe scope of thhis standaard. 5.4.4 5.4.4.1

Data set details d List of elements

Data sets s consist off a list of dataa elements thaat contain dataa. The first ellement is alwaays the data sset identiffier, the secon nd element alw ways contains the t time of crreation, and the other elemennts contain daata valuess. ⎯ A data set is conveyed in a DNP3 objectt. ⎯ Each data set shall fit with hin a single Ap pplication Layeer fragment. ⎯ Within a sin ngle outstation n, event and staatic data sets thhat relate to thee same collectiion are based oon the same daata set descripto or and have an n identical objeect format. The first element, th he identifier, prrovides the corrrespondence too a data set desscriptor and serves as an indeex viously discusssed in 5.4.2.8.1 1. as prev The seecond elementt is the time off creation. This refers to the time associateed with the daata elements thhat follow w. If the data seet is an event data d set, the tim me of creationn is the time w when the event occurred. If thhe data seet is a static daata set, it is thee common timee when all of tthe subsequentt data element values were put togeth her into the dataa set. All off the other elem ments, beginnin ng with the thirrd, contain dataa values as speecified from thhe correspondinng data seet descriptor. 5.4.4.2

Event an nd static data a sets

Data sets s are applicaable to event and a static cond ditions. Events relate to whenn something off interest occurrs. DNP3 does not defin ne what “someething” is becaause “somethinng” is applicatiion specific. Inn the example oof he “something”” is the occurreence of a fault condition. In oother situationns, a system maay an electrical fault, th require a snapshot of certain valuees stored at 15--minute intervaals during a losss of communiications; the ennd 5-minute interv val is the “som mething” of inteerest. of a 15 Static data relates to o present cond ditions. The master m may pooll for specificc data sets in order to updaate ons. The masterr may write a ddata set to estabblish configuraation parameteers operattor displays or for other reaso or for another reason n. Not alll data sets hav ve a static valu ue because a complete c data set may not exxist until an evvent occurs. Foor examp ple, the elemen nts of an electriical fault data set s only have m meaningful vallues at the insttant when a fauult occurss. Data sets s defined by the master aree always static. An outstation shall not geneerate events forr this type. 127 Copyright © 2012 IEEE. All rightts reserved.



5.4.4.3

Data set names

Each data set definition may have a text string name. Data set names do not appear in the data set itself but may optionally appear in their corresponding data set descriptors. Subclause 5.4.8 provides more information regarding naming. 5.4.4.4

Data set identifiers

Within a single outstation, event and static data sets that relate to the same collection, use the same identifier. 5.4.4.5

Data type codes specific to data sets

Data sets are limited to the data types in Table 5-6 for the values that appear in each of its elements. Table 5-6—Data type codes specific to data sets Code

Code name

0

NONE

Description Data type does not exist or a placeholder.

1

√

VSTR

Visible ASCII characters suitable for print and display.

2

√

UINT

Unsigned integer.

3

√

INT

Signed integer.

4

√

FLT

Floating-point.

5

√

OSTR

Octet string.

6

√

BSTR

Bit string.

7

√

TIME

DNP3 time.

UNCD

Unicode strings (requires two octets per character).

8

Regarding data types: ⎯ Data type codes do not specify the number of octets required to convey the value. That information is encoded in the message by a length octet. ⎯ Floating-point types are limited to 4 and 8 octets for transporting 32-bit and 64-bit floating-point values. No other sizes are acceptable. Implementers that use 64-bit floating-point values shall carefully consider the consequences of possible non-interoperability. ⎯ The preferred size for integer types is 1, 2, and 4 octets (8, 16, and 32 bits). Implementers that use integers having more than four octets shall carefully consider the consequences of possible noninteroperability. ⎯ The bit alignment in bit string types requires the first bit to appear in bit 0 of the first octet of the value. If the number of bits in a bit string is not an integral of 8, the unused bits in the last octet of the value shall be cleared to 0. ⎯ Implementers that use Unicode shall carefully consider the consequences of possible noninteroperability in that this data type is not universally supported. ⎯ Master devices and outstations that accept data sets defined by the master shall support 1) Those data type codes marked with a √ symbol in Table 5-6. 2) 32-bit integers (types UINT and INT of size 4 octets). 3) 32-bit floating-point values. 128 Copyright © 2012 IEEE. All rights reserved.



5.4.5

Descripto or elements

5.4.5.1

Definitio ons

Beforee discussing deescriptor elemeents, it is best to define two terms, namesppaces and Uniiversally Uniquue Identiffier (UUID). 5.4.5.1.1

Name espaces

A nam mespace is a refference to a sett of names thatt are in some w way related to eeach other. Theey are helpful to preven nt confusion if a name such as a “Distribution n Feeder” appeears in two or m more named sppaces. Namespaces are used to qualify th he names used for data set prrototypes. Dataa set prototypes are most ofteen ump,” and “G Generator.” Ussing a namespace reduces thhe given generic namees such as “Faault,” “Well Pu nt the same nam me for their proototype. With a namespace, tthe World-Widde confussion if two organizations wan Relayiing Organizatio on and the Win nd Power Asso ociation (both ffictitious groupps) can define a DNP3 data sset prototy ype with the naame of “Distrib bution Feeder”” without conceern for user miisinterpretationn. Namespaces are inteended to reflectt the name of a standards orgganization, a sttandards speciffication, such aas 9 or a vendor, but th hat is not a requ uirement. “IEC 99099-9,” Namespaces shall bee registered on the DNP3 Weeb site21 in ordeer to assure unnique namespacces. A registereed ng is public info ormation. It is preferred that names within tthe namespacee be made publlic namesspace text strin by thee registering org ganization for the sake of inteeroperability, bbut they may bbe kept as privaate informationn. There are several rulles for generatiing acceptable namespaces: ⎯ The namesspace shall consist c of AS SCII letters, ddigits, spacess, underscoress, and hyphenns [A..Z,a..z,0..9, ,_,-]. No otheer characters arre permitted. ⎯ Namespacees shall begin with w a letter or digit. d ⎯ Namespacees are case seensitive; howeever, when chhecking for uuniqueness, a case-insensitivve comparison n shall be used. For example, “CaT” is unaccceptable if “Ca at” were alreaady reserved. ⎯ The namesp pace may not contain c two or more contiguoous space charaacters, two or m more contiguouus underscoress, or two or mo ore contiguous dashes. For exxample, “My--Name” is not acceptable. ⎯ The numberr of characters in the namespace shall not eexceed 32. ⎯ Names shalll not use profaanity or vulgar terms. This inccludes those thhat would be coonsidered racisst, hateful, sex xual, or obscenee in nature. 5.4.5.1.2

UUID D

A UUID is a unique 16-octet string g. There is a program available on the t DNP3 Web site22 that g enerates UUID Ds. This is thee only approveed metho od for generatin ng UUIDs for DNP3; D no otheer generators aare acceptable. The reason is because severral metho ods exist for gen nerating UUID Ds, and to provide uniquenesss, only one is ppermitted. For hu uman readabillity, UUIDs are often expreessed as an A ASCII string thhat includes tthe hexadecim mal characcters, hyphens, optional opening and closing g curly bracketts, and spaces, as in { C2F41010-65B B3-11D1-A29F-00AA-00 0C15A82 } 21 22

http:///www.dnp.org. See fo ootnote 21.




Only 16 octets are transmitted. Each pair of hexadecimal characters in the human-readable format represents the contents of one octet in the 16-octet string.23 The leftmost characters, “C2” in the example, are transmitted first in an octet having a hexadecimal value of 0xC2 or 194 decimal. The rightmost characters, “82” in the example, are transmitted in the 16th octet; its value is 0x82 or 130 decimal. 5.4.5.2

Descriptor element overview

Data set descriptors and data set prototypes are formed by a sequence of descriptor elements. Each descriptor element contains information about ⎯ A data element in the corresponding data set. ⎯ A reference to a data set prototype. ⎯ A namespace or name attribute of a data set or a data set prototype. Subclauses 5.4.6 and 5.4.7 describe how descriptor elements are used. Specifically, each descriptor contains ⎯ The length of the descriptor element. ⎯ The type of descriptor element. ⎯ A data type code. ⎯ The maximum data length. ⎯ An optional ancillary value. These are discussed as follows. 5.4.5.2.1

Descriptor element length

This is a single octet that a parser uses to learn the length, in octets, of the entire descriptor element. 5.4.5.2.2

Descriptor element type

There are different types of descriptor elements; these are enumerated by the code numbers in Table 5-7.

23

Computer programs written in C define a UUID as a structure consisting of a 32-bit unsigned long, two 16-bit unsigned short integer and an array of 8 characters. In an effort to define a UUID in DNP3 that is independent of the octet ordering used by a CPU, this standard requires transmitting octets in the same order as the ASCII string representation of a UUID. For the example in 5.4.5.1.2, the “C2F41010” represents the hexadecimal value, 0xC2F41010, of the 32-bit unsigned long value in the structure.




Table 5-7—Descriptor codes Code 1

Code name

Description Specifies an identifier attribute associated with a descriptor. Each descriptor has a unique identifier to differentiate it from all others.

ID

The ancillary value associated with this field is a UINT. The value is the identifier integer. Specifies a UUID associated with a data set prototype. 2

UUID

3

NSPC

The ancillary value associated with this field is an OSTR of exactly 16 octets that contain a UUID. Specifies a namespace attribute associated with a data set prototype. The ancillary value associated with this field is a VSTR. It is the namespace. Specifies a name attribute associated with the data set or data set prototype.

4

NAME

The ancillary value associated with this field is a VSTR. It is the data set’s or data prototype’s name. Specifies the occurrence in the data set of a simple data element.

5

DAEL

The ancillary value associated with this field is a VSTR. It is optional and specifies the name associated with the data value in the data set. Specifies the occurrence in the data set of a subset of elements defined in a data set prototype.

6

7

PTYP

CTLV

The ancillary value associated with this field is an OSTR that is the concatenation of a 16octet UUID followed by an optional prototype instance name VSTR. Specifies the occurrence in the data set of an element containing a value to be issued to the receiver when the data set appears in SELECT, OPERATE, DIRECT_OPERATE, and DIRECT_OPERATE_NR commands. The ancillary value associated with this field is a VSTR. It is optional and specifies the name associated with the value in the data set.

8

CTLS

Specifies the occurrence in the data set of an element intended to convey whether the subsequent CTLV values should be issued in SELECT, OPERATE, DIRECT_OPERATE, or DIRECT_OPERATE_NR commands, and to convey the control status in the corresponding response messages. The ancillary value associated with this field is a VSTR. It is optional and specifies the name associated with the data value in the data set.

5.4.5.2.3

Data type code

This is a single octet that specifies the general format for which the data in the corresponding element of the data set shall be transmitted. The data type codes are specified in Table 5-6. 5.4.5.2.4

Maximum data length

This is a single octet specifying the maximum number of octets permitted to express the data or control value in the corresponding data set. It provide192 s information for the receiver to allocate memory or otherwise limit some aspect of the parsing activities. 5.4.5.2.5

Ancillary value

The ancillary value completes the description when the codes are not enough.




The an ncillary valuess depend on th he descriptor element e type, aas described inn Table 5-7, aand the data seet, prototy ype, or data eleement to which h they refer. 5.4.6

Data set descriptor d de etails

5.4.6.1

General

Data set s descriptors specify the seq quence of elem ments that form data sets. ⎯ A data set desscriptor is conv veyed in a DNP P3 object. ⎯ Each data set descriptor shalll fit within a single Applicattion Layer fraggment. 5.4.6.2

Data sett descriptor construction c n

Descriiptors are constructed from a sequence of descriptor elem ments. Descriptoor elements aree used to speciffy severaal things—the data set descriiptor identificaation, the elemeents in a correesponding dataa set, a subset oof data ellements as foun nd in a data sett prototype, an nd a name. Des criptor elemennts are discusseed in 5.4.5. 5.4.6.2.1

First descriptor element e

The first descriptor element e in a daata set descripto or is always ann ID element. 5.4.6.2.2

Name e descriptor element

If the data set has a unique name,, that name sh hall appear as tthe second desscriptor element. The name is fic to the data set s having the same identifieer as is specifieed by the ID eelement. It is specified usingg a specifi NAME E type. To illu ustrate, assumee there is an ou utstation at each h of 200 pumpiing stations aloong a gas pipelline, and there is a data set defined forr each. All 200 0 data sets coulld utilize the iddentical constru ruction in that tthey all have thhe s of ellements that sp pecify pressuree, temperature, flow rate, etc.. It might be aadvantageous fo for same sequence the sy ystem engineerr to name eacch data set—““Pump Stationn 1,” “Pump S Station 2,” … or “Fox Hilll,” “Look kout Point,” … Those names might best desscribe the data set. On a smaller s geograaphic scale, each feeder of an n 8-feeder subbstation may hhave a different data set nam me: “Feeder 101,” “Feed der 102,” … or “Route 661,” “County Line R Road,” … Subclaause 5.4.8 prov vides more info ormation regarding naming. It is no ot required to have h names forr data sets and inclusion of a N NAME descripptor element iss optional. 5.4.6.2.3

Data descriptor elements e

A data set descripto or may includ de data elemen nt descriptors of type DAE EL. Each DAE EL element thhat appearrs in a data set descriptor specifies a single data value in thhe correspondiing data set. It is not n necessary to t have any DA AEL elementss if the data seet shall only bbe used for conntrol operationns, althou ugh it is permissible to include them. 5.4.6.2.4

Conttrol-related descriptor d ele ements

A dataa set descriptorr may include control-related d element desccriptors of typee CTLV and C CTLS. These are used to specify eleements to be controlled when w issued inn commands using SELEC CT, OPERATE E, CT_OPERATE E, and DIREC CT_OPERATE_ _NR function codes. Each C CTLV and CTLS element thhat DIREC appearrs in a data set descriptor specifies a single value in the coorresponding ddata set. 132 Copyright © 2012 IEEE. All rightts reserved.



5.4.6.2.5

Proto otype referen nce descripto or elements

A PTY YP element maay be included d in a data set descriptor as aan alias for a ssequence of DA AEL, CTLV, oor CTLS descriptor elem ments. A PTYP P element references a data sset prototype. When a PTYP appeears, software shall use the DAEL, CTLV V, and CTLS descriptor eleements from thhe prototy ype to determiine the data typ pe and ordering g of the elemennts in the correesponding dataa set. In essencce, the PT TYP implies that the elementss from the prottotype are to bee substituted foor the PTYP element. It is accceptable for the t same PTYP P to appear mu ultiple times inn the same descriptor. For exxample, if PTY YP “xyz” defines the haarmonics of a single phase, a data set desscriptor designned for three-phase power linne yz” PTYP elem ments. could have three “xy 5.4.6.2.6

Prohibited descriptor elemen nts

A dataa set descriptorr may not inclu ude NSPC or UUID U descriptoor elements. 5.4.6.2.7

Data value orderiing

It is peermissible to in ntermix DAEL L, CTLV, CTL LS, and PTYP eelements withiin in a descripttor. The order oof data values v in the daata set is the saame order that the DAEL, CT TLV, and CTL LS elements apppear in the daata set desscriptor and in the included PTYP P prototype elements. 5.4.7

Data set prototypes p

5.4.7.1

General

Data set s prototypes specify s the seq quence and typee of a subset off data elementss within a data set. ⎯ A data set prototype p is con nveyed in a DN NP3 object. ⎯ Each data set prototype sh hall fit within a single Appliccation Layer fraagment. 5.4.7.2

Data sett prototype construction c

Protottypes are consttructed from a sequence of deescriptor elemeents. Descriptoor elements aree used to speciffy severaal things—the data set protottype identification, the UUID D of the prototype, namespaace and name oof the pro ototype, and th he data elementts. Descriptor elements e are diiscussed in 5.44.5. 5.4.7.2.1

First element

The fiirst descriptor element in a data set protottype is alwayss an ID elemeent. It is not reelated to the IID memb ber of a data set s descriptor. It is used to access indiviidual prototypes using classsic DNP3 indeex numbeers. As an example, an outstation o has a repertoire off 12 prototypess. The master could, if it so desired, requeest g indexes 4 and 5 in the rangge field of an A Application Laayer header with the fiffth and sixth prrototypes using qualifi fier codes 0x00. The fiirst element, th he ID element, is the only eleement in a prottotype that is nnot considered when assigninng the pro ototype’s UUID D. See 5.4.7.2..2. 5.4.7.2.2

Seco ond element

The seecond descripto or element in a data set proto otype is alwayss a UUID elem ment. It is the U UUID associateed with one o and only one o prototype. If any membeer of an existinng prototype, eexcept the ID element, shouuld 133 Copyright © 2012 IEEE. All rightts reserved.



need to t change in any a respect, th he new prototy ype shall havee a new UUID D. This includdes namespacees, namess, types, maxim mum lengths, an nd so forth. When a standards orrganization or vendor definees a prototype, it shall also sppecify the UU UID. Thus, giveen s the exaact same inforrmation regarddless of where in the world it the saame UUID, it shall always signify appearrs. 5.4.7.2.3

Third d and fourth elements

If prottotype namespaace and name are a used, they shall s appear inn the third and ffourth descripttor elements; thhe third element e shall be b a NSPC elem ment, and the fourth f shall be a NAME. Theese refer to thee namespace annd name of the prototyp pe, not the indiv vidual or speciific data set wiith which it is aassociated. Eitherr NSPC and NA AME appear, or o they do not. It is not permisssible to have a NSPC without a NAME orr a NAME E without a NS SPC. Subclaause 5.4.8 prov vides more info ormation regarding naming. 5.4.7.2.4

Data descriptor elements e

A dataa set prototypee shall include at least one daata descriptor eelement of typpe DAEL if thee prototype doees not incclude a CTLV or CTLS elem ment. Each DA AEL element thhat appears in a data set protootype specifiess a single data value in the t correspond ding data set. 5.4.7.2.5

Conttrol-related descriptor d ele ements

A dataa set descriptorr may include control-related d element desccriptors of typee CTLV and C CTLS. These are used to specify eleements to be controlled when w issued inn commands using SELEC CT, OPERATE E, CT_OPERATE E, and DIREC CT_OPERATE_ _NR function codes. Each C CTLV and CTLS element thhat DIREC appearrs in a data set prototype speccifies a single value v in the co rresponding daata set. 5.4.7.2.6

Prohibited descriptor elemen nts

A dataa set prototype may not have PTYP elementts24; that is, proototypes may nnot be nested. 5.4.7.2.7

Data value orderiing

The orrder of data vallues in the dataa set is the sam me order that thhe DAEL, CTL LV, and CTLS elements appear in the data set protottype. 5.4.8

Naming guidelines

Names of various iteems are permittted within dataa set descriptorrs and data set prototypes. Naames are helpfful uman understaanding and can n serve as maachine-readablee identifiers w when the namees are carefully for hu chosen n. Names are optional and are not required, r but implementers i should considder the followiing issues wheen choosiing to provide names. For th he examples ap ppearing in thee following dasshed items, asssume that the iimplementer w wants to create a data seet descriptor fo or reporting thee harmonics off a three-phase feeder. In doinng so, he chooses to use a daata set pro ototype that describes the mag gnitudes of thee fundamental tthrough the nthh harmonic freequencies. 24

This requirement may be relaxed in the future if the need d arises. Until thenn, the prohibition against nesting m means parsers do nnot need to incorporate recurssion, which should d minimize their co omplexity.




⎯ The name of o a prototypee (see 5.4.7.2.3 3) should uniqquely identify a single protootype within thhe same namespace. The nam me should be general g so thatt it is applicablle regardless of which speciffic ype or how maany times the pprototype is reeferenced within data set desscriptors refereence the prototy the same daata set descripttor. For examp ple, use the terrm “Harmonic magnitude” innstead of “Phasse A Harmonics.” ⎯ The names associated witth data elementts within a proototype should be generic andd not referencee a or example, uuse “5th harm monic” and noot “5th voltagge specific insstance of the prototype. Fo harmonic” because the same s prototyp pe can then b e used for deescribing voltaage and current harmonics. ⎯ The names associated witth data set desccriptors (see 5..4.6.2.2) should be specific to the data set. It u among all data sets w within an outstaation so that thhe is strongly suggested thatt the name be unique nonym for the identifier i elem ment in the desccriptor. name can be used as a syn Avoid d using the worrds “Data Set” in the name because b these aare redundant aand minimizing the number oof characcters in a name is beneficial. Contin nuing with the example, a suiitable name forr the data set w would be “Harm monics feeder 1105.” This nam me includ des an indicatio on of which feeder f the harm monics are asssociated and thhe word Harm monics narrowly definees the specific data d set applicaation. ⎯ PTYP elem ments may conttain a name in the ancillary vvalue immediattely following the UUID. Thhis name shoulld be specific and apply to the particularr instance of a prototype. B Because data sset descriptors may include multiple m prototy ypes, the namee is useful for clarifying the ddifferences. Thhe for each phase. Suitable namees example daata set descripttor from abovee has three proototypes, one fo would be “P Phase A,” “Phaase B,” and “Phase C,” or thee names could be even more specific, “Phase A voltage,”” “Phase B volttage,” and “Phaase C voltage.”” NOTE— —The ancillary value actually contains c the 16 UUID U octets andd the name chara cters.

When implementerss use these gu uidelines for creating c namess, each elemennt within a daata set becomees xample, the 3rd harmonic on phase B at feeeder 105 can bbe identiffiable by hieraarchal name fieelds. As an ex referen nced as “Harm monics feeder 105.Phase B.3rd d harmonic” w where a period iis used to separrate the fields. In certtain cases, imp plementers may y choose to usse a text UUID D in lieu of thee name. This ppermits a crypttic metho od of uniquely identifying a specific data value. v Discussiion of this techhnique is outsiide the scope oof this do ocument. 5.4.9 5.4.9.1

DNP3 obje ect groups, classes, c and indexes Group numbers and class respo onses

Data sets, s prototypess, and descripttors are transpo orted using thee group numbeers specified inn Table 5-8. Thhe table indicates i when the objects maay appear in reesponses to requ quests for class data from the master.




Tab ble 5-8—Data a set related group numb bers and rep port classes Group

5.4.9.2

Descrription

Report classses

85

Data Set Pro ototype

May M not appear inn any class response.

86

Data Set Deescriptor

May M not appear inn any class response.

87

Static Data Set S

May M appear in Cllass 0 responses only if so configgured.

88

Event Data Set

May M appear in Cllass 1, 2, or 3 ressponses.

Point ind dexes

The id dentifiers associated with daata sets, descriiptors, and proototypes corresspond to indexx numbers—seee 5.4.2.8 8 and the ID ellement type in 5.4.5.2.2. Data set, s descriptor and a prototype transfers t use qu ualifier code 00x5B in the object headers duue to the variabble size of those objectss. This qualifieer requires the range field too specify the nnumber of objeects, and that aan c precede each e object. Th here is no prov vision with this qualifier for a point index. octet count When the master req quests to read a specific dataa set, descriptoor, or prototyppe, it shall use a qualifier codde pecifies a poin nt index. In theese situations, the t object headder’s qualifier and field codees specify indeex that sp numbeers having thee same values as the identiffiers of the deesired data setts, descriptorss, or prototypees. Qualiffier 0x00 is an example that specifies the objects o are not prefixed, and tthe range fieldd contains a staart and sttop index. A reead request forr group 86, vaariation 1, quallifier 0x00 andd range field vvalues 0x02 annd 0x02 shall s return thee single data set descriptor wiith an identifierr of 2. 5.4.9.3

Event ge eneration and class assig gnment

If an outstation o supports data set ev vents, ⎯ It shall be configurable c to o not send them m. This is neceessary for com mpatibility withh masters that ddo not support data sets. ⎯ It shall supp port function code 22, [ASSIG GN_CLASS]. The master m uses grou up 86 in the ob bject header of an assign classs request. (It ddoes not use thee static data typpe of grou up 87.) 5.4.10 0 Point inde ex attributes There are situations when it is dessirable to correelate the elemeents of a data sset to the indexxes for the morre primittive point typess. For examplee, an IED that reports the pow wer parameterrs on a 3-phasee feeder data sset can allso report 9 in ndividual analo og input pointts in traditionaal class scans (3 voltage, 3 current, grounnd curren nt, total megaw watts and total megaVArs m (MV VArs)). DNP3 provides a means to transpo ort the correlattion using a grroup 86, variattion 3 object. T This is a speciial s descriptor. Each element in variation 3 contains a poiint type, and ppoint index. Thhe variatiion of a data set structu ure of a group p 86, variation 3 object is prrovided in A.333.3. Point typpes are indicateed by the grouup numbeers shown in Table T 5-9. If a value in the data set does not correlate to a point typpe in the classsic databaase, group num mber 0 is used.




Table 5--9—Group nu umbers used d for point ty ypes Gro oup

Point tyype

0

No poin nt type is associaated.

1

Binary input

3

Doublee-bit binary inpuut

10

Control output

20 2

Counteer

30

Analog g input

41 4

Analog g output

90 9

Applicaation

10 01

BCD point

10 02

8-bit un nsigned integer

11 10

Octet string

11 12

Virtuall terminal

The elements in varriation 3 appear in the samee order as the DAEL descriiptor elementss of the data sset ptor. descrip The point indexes are a intended ass references only. In most ssituations, impplementers shoould not use thhe valuess in a data set to t update a maaster’s point daatabase. The reeason is becauuse the time rellationship of thhe data seet values is nott synchronized with the timin ng of the normaal database upddate mechanism m. Using analog inputss as an examplle, the master polls for statiic and event ddata and receivves static analoog v in group p 30 objects an nd events in grroup 32 objectss. DNP3 does not specify whhen data sets aare input values constrructed, when th he analog inpu ut values are obtained, o or w whether data seets shall be repported before oor after analog a input daata. If the valuees from a data set were usedd to populate thhe same databaase values as thhe normaal polling, it is possible p that an older value would w replace a more recentlyy obtained valuue, and thus, thhe databaase would be in naccurate. 5.4.11 1 Control co ommands an nd responses s Data set s objects of ty ype g87v1 may y appear in con ntrol requests aand their respoonses. In generaal, controls reffer to fun nction codes SELECT, S OPE ERATE, DIRE ECT_OPERAT E, and DIREC CT_OPERATE E_NR and theeir respon nses. Data sets used with h control com mmands may contain c multipple control vaalues, that is, values that thhe t logical or physical p end deevice. In some situations, thee designer mayy want to contrrol outstattion issues to the some of o the values in n one control command c and control other vvalues in the neext command. For example, in a dataa set designed d for cameras, one value seets the zoom, and two otheer values set tthe pan and tiilt param meters. An operrator may wan nt to control th he zoom indeppendently from m the pan and tilt. In addition, when pan and tilt vaalues are set, they t shall be output o atomicallly (meaning ttogether at the same instant in time). m also includ de values that are a not involveed in the contrrol but are usefful for reportinng The saame data set may the vaalues of other parameters. p Th he aperture opeening and shut utter speed in th the preceding ccamera exampple are no ot controllable but b are includeed in the data seet for reportingg from the outsstation. DNP3 does not speecify what valu ues a designerr may includee in a data sett. The developper shall decidde her it is better to have a sing gle data set thaat includes zo om, pan, tilt, aperture, and speed values oor wheth wheth her it is best to have two dataa sets, one with h zoom, pan, aand tilt for conttrols and anothher for reportinng apertu ure opening and d shutter speed d. DNP3 provid des the capabiliities needed foor all of these ppossibilities. 137 Copyright © 2012 IEEE. All rightts reserved.



The next paragraphs describe elements and rules for data sets used for controls. 5.4.11.1 CTLV, CTLS, and DAEL elements in control requests and responses Table 5-10 describes the use of CTLV, CTLS, and DAEL elements in control requests and responses. Table 5-10—Element types in control requests and responses

Element type

Controllable

Description Elements of this type represent the commanded values. In a request message, the values in the corresponding elements of a data set are the values that shall be issued to the receiving device, but only if the preceding CTLS element contains a value of zero.

CTLV

Yes

The values in response to SELECT, OPERATE, and DIRECT_OPERATE commands always mimic the values in the request. The master ignores the value in elements of this type in READ and UNSOLICITED responses, and the outstation ignores the value in elements of this type in WRITE requests. In request messages, elements of this type represent an indication to the receiver whether or not to issue the values in subsequent CTLV elements to the receiving device. A value of 0 indicates that the value shall be issued; a value of NON_PARTICIPATING (126) indicates that the receiving device shall not issue the values in subsequent CTLV elements to the receiving device.

CTLS

No

In responses to SELECT, OPERATE, and DIRECT_OPERATE commands, elements of this type represent a status code. The outstation always mimics the value in the request unless there is a reason why the command shall not succeed. In that situation, the value is set to an appropriate control status code as listed in Annex A. The master ignores the value in elements of this type in READ and UNSOLICITED responses, and the outstation ignores the value in elements of this type in WRITE requests. Elements of this type may appear in data sets that also have CTLV and CTLS elements. However, DAEL elements are not intended to convey information in control requests and responses.

DAEL

No

The master and outstations ignore the value in elements of this type in SELECT, OPERATE, and DIRECT_OPERATE requests and responses. The outstation shall mimic whatever values the master places in the DAEL elements of the request when it sends the response, but otherwise it shall disregard its value.

5.4.11.2 Control status element (CTLS) It is mandatory to include at least one control status element in any g87v1 object that is transmitted in a control command or response. A data set may include more than one CTLS if not all of the CTLV values are outputted atomically. A CTLS applies to all of the CTLV elements that follow it until either the next CTLS element appears or the end of the data set occurs. The term applied to a CTLS and its subordinate CTLV elements is a control-group. Figure 5-3 shows a sample data set having two control-groups.




Figure 5-3—Sample data set with CTLS and CTLV elements Table 5-11 specifies the definition of a CTLS descriptor element.25 Table 5-11—CTLS element structure and contents Field contents

Field description

Depends on ancillary value


0x08

ID descriptor code

0x02

UINT

0x01

Maximum data length

Developer’s choice

Ancillary value is name string

5.4.11.3 Control rules The following rules apply when data sets are used in control commands having function codes SELECT, OPERATE, DIRECT_OPERATE, and DIRECT_OPERATE_NR and their responses a)

All of the standard select-before-operate rules shall apply. These include, but are not limited to, requirements for the operate request to exactly match the select request, and for the select and operate requests to have sequential sequence numbers in the application control octets. The complete set of rules is not repeated here (see 4.4.4).

b) The requirements stated in Table 5-10 apply. c)

Each control-group within a data set shall begin with a control status CTLS element. The structure and contents shall be as specified in Table 5-11. Developers may choose the name in the ancillary value field. Alternates or custom-designed CTLS elements are not permitted.

d) A data set may include multiple control groups. 25

See objects g85v1 (A.32.1) and g86v1 (A.33.1) for a generic definition of descriptor elements.




e)

All of the CTLV values associated with a control group shall be issued atomically.

f)

For data sets with multiple control groups: 1) The outstation may issue the control values in each control group independently of the other control groups. 2) The master prevents issuing control values for some of the control groups by setting the value of their respective CTLS elements to NON_PARTICIPATING (126).

g) If there is an error or a reason why the control operation shall not succeed for a CTLV element within a control group, the outstation reports the appropriate status code in only that control group’s CTLS element. The outstation shall not alter CTLS elements due to errors detected for CTLV elements that are not members of the same control group. h) If the CTLS value in a request is NON_PARTICIPATING, the master does not want the outstation to issue the CTLV values in that control group; therefore, no errors can result, and the outstation shall return the same CTLS value in the response. 5.4.11.4 Message exchange illustration Figure 5-4 provides an overview of a control message exchange. It includes a few other messages to demonstrate when g87v1 and g88v1 objects are used. The diagram is not intended to be comprehensive and only illustrates one out of many possibilities.




Master

Ou utstation SELECT Request (g87v1))

Operator wishes w to command d output

R (g87v11) SELECT Response Master M compares response r wiith request. If theey match and status code = SU UCCESS, issues operate reequest

O Outstation notes rrequest , changes status code c if ccontrol will not ssucceed andd replies with sam me object

OPERATE E Request (g87v11)

OPERATE Response (g87vv1)

Spontaneou us Event (g88v11) Masster notes the chaange and ackn nowledges receipt of event

CO ONFIRM

Spontaneou us Event (g88v11) Masster notes the chaange and ackn nowledges receipt of event

Outstation comppares operate reqquest with select request , and if OK K, initiates the conntrol operation . Sennds a response w with appropriate status coode . O Output changes sttate duee to control comm mand andd transmits and evvent .

Vallue or quality chaanges . Outtstation sends an event.

CO ONFIRM

READ (alll data or g 87v1))

Master M issues reaad request for an integritty scan

RESPO ONSE (g87v1)

Master updates database

O Outstation replies with curr rrent values and quality q

Figure 5-4—Example 5 e control me essage excha ange 5.4.12 2 Example data d descriptors, prototy ypes, and datta sets Table 5-12 through h Table 5-15 illustrate the structure andd contents of data set descrriptors, data sset prototy ypes, and data sets.

Electricaal fault examplee 1. EX 5-5 5

Table 5--12 shows the construction of o a data set deescriptor for thhe electrical faault data set froom Table 5--4. All of the descriptor d elem ments are includded in the dataa set descriptoor, and prototyppes are not used.




Table 5-12—Data set descriptor for electrical fault Descriptor element

1st

2nd

3rd

4th

5th

6th

7th

8th

9th

Element contents

Element description

0x05


0x01

ID descriptor code

0x00

No data type code (placeholder code)

0x00

Maximum data length

0x0000

Ancillary value is data set identifier

0x11


0x04

NAME descriptor code

0x00


0x00

Maximum data length

“Fdr 11-A Fault”

Ancillary value is the data set name

0x10


0x05

DAEL descriptor code

0x04

FLT data type code

0x08

Maximum data length

“Current Phs A”

Ancillary value is the data element name

0x10


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Phs B”

Ancillary value is the data element name

0x10


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Phs C”

Ancillary value is data element name

0x0E


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Gnd”


0x0B


0x05


0x06

BSTR data type code

0x02

Maximum data length

“Triggers”


0x0E


0x05


0x01

VSTR data type code

0x08

Maximum data length

“Fault Class”


0x07


0x05


0x02

UINT data type code

Element data

Mandatory DNP3 identifier element

Optional data set name

Current phase A

Current phase B

Current phase C

Current ground

Parameters that triggered breaker

Fault classification

1/100th kilometers distance to fault




Descriptor element

Element contents

Element description

0x04

Maximum data length

“Dist”


Element data

Electrical fault example 2. EX 5-6

Table 5-13 shows the construction of a data set descriptor for the electrical fault data set from Table 5-4. Table 5-14 shows the data set prototype that is referenced in the data set descriptor.

Table 5-13—Data set descriptor for electrical fault with prototype Descriptor element

Element contents 0x05

1st

2nd

3rd

Element description

Element data


0x01

ID descriptor code

0x00


0x00

Maximum data length

0x0000

Ancillary value is data set identifier

0x11


0x04


0x00


0x00

Maximum data length

“Fdr 11-A Fault”


0x1D


0x06

PTYP descriptor code

0x00


0x00

Maximum data length

0xC2 0xF4 0x10 0x10 0x65 0xB3 0x11 0xD1 0xA2 0x9F 0x00 0xAA 0x00 0xC1 0x5A 0x82 “Fault Data”

Ancillary value is the mandatory UUID, which is followed by an optional instance name


Optional data set name

Reference to a data set prototype




Table 5-14—Data set prototype for electrical fault Descriptor element

Element contents 0x05

1st

2rd

3rd

4th

5th

6th

7th

8th

Element description

Element data


0x01

ID descriptor code

0x00


0x00

Maximum data length

0x0099

Ancillary value is prototype identifier

0x13


0x02

UUID descriptor code

0x00


0x00

Maximum data length

0xC2 0xF4 0x10 0x10 0x65 0xB3 0x11 0xD1 0xA2 0x9F 0x00 0xAA 0x00 0xC1 0x5A 0x82

Ancillary value is the UUID

0x15


0x03

NSPC descriptor code

0x00


0x00

Maximum data length

“Earth Relaying Org”


0x0F


0x04


0x00


0x00

Maximum data length

“Feeder Fault”


0x10


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Phs A”

Ancillary value is the data name

0x10


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Phs B”


0x10


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Phs C”


0x0E


0x05


0x04

FLT data type code

0x08

Maximum data length

“Current Gnd”



UUID assigned to prototype

Optional prototype namespace

Optional prototype name

Current phase A

Current phase B

Current phase C

Current ground




Descriptor element

Element contents 0x0B

9th

10th

11th

Element description

Element data


0x05


0x06

BSTR data type code

0x02

Maximum data length

“Triggers”


0x0E


0x05


0x01

VSTR data type code

0x08

Maximum data length

“Fault Class”


0x07


0x05


0x02

UINT data type code

0x04

Maximum data length

“Dist”


Parameters that triggered breaker

Fault classification

1/100th kilometers distance to fault

Electrical fault example 3. EX 5-7

Table 5-15 shows a typical event data set returned after a fault. This data set is reported with a group 88, variation 1 object. It is an appropriate data set for the data set descriptors in Table 5-12 and Table 5-13.




Ta able 5-15—E Electrical fau lt data set Data set element 1st

2rd

3rd 4th 5th 6th 7th 8th 9th

Element conttents

Element description

0x02 0

Value length

0x0000 0

Value is data set identtifier

0x06 0

Value length

0xF5 0 0x7C 0x38 0x01 0xF7 0 0x00

Value is time when evvent occurred

0x04 0

Value length

1328.98 1

Value

0x04 0

Value length

420.17 4

Value

0x04 0

Value length

1048.43 1

Value

0x04 0

Value length

342.95 3

Value

0x01 0

Value length

0x0B 0

Value

0x03 0

Value length

“ACG” “

Value

0x01 0

Value length

141 1

Value

Ellement data Identtifier Timee of evennt Curreent phasee A Curreent phasee B Curreent phasee C Curreent grounnd Param meters that triggered breaker Faultt classsification 1/1000th kM distaance to fault

5.4.13 3 Example Messages M EX 5-8 8

This is an a example of the master reaading all of thee data set desccriptor in an ouutstation, and tthe outstation n returning a siingle descripto or described in Table 5-12.


01 C FC

56 Grp

01 Var

06 Quaal

◄ Response Message M (beginn ning) ◄◄◄ C3 AC

81 C FC

00 IIN1

00 IIN2

56 Grp p

01 Var

5B Qual

01 Rangge

7D 000 Size prefixx

05 ← len

00 max

64 d

◄ Continuation n of Response Message M ◄◄◄ 01 ID

00 0 typ pe

00 max

00 00 identifier

11 → ← len

04 00 NAME none

446 F




◄◄◄ Continuation of Response Message 72 20 31 31 2D r 1 1 – ◄◄◄ Continuation of Response Message

41 A

20

46 F

61 a

75 u

6C l

74 10 05 04 08 max t → ← len DAEL FLT ◄◄◄ Continuation of Response Message

43 C

75 u

72 r

72 r

65 e

6E n

73 s

20

41 A

10 → ← len

65 e

6E n

74 t

08 max

68 h

74 t

20

50 P

68 h

05 04 DAEL FLT

08 max

20

50 P

68 h

73 s

43 C

75 u

72 r

72 r

65 e

73 s

20

43 C

0E → ← len

72 r

65 e

6E n

74 t

20

47 G

6E n

02 max

54 T

72 r

69 i

67 g

67 g

65 e

08 max

46 F

61 a

75 u

6C l

74 t

04 max

44 D

◄◄◄ Continuation of Response Message 43 C

75 u

72 r

72 r

◄◄◄ Continuation of Response Message 20

42 B

10 → ← len

05 04 DAEL FLT

◄◄◄ Continuation of Response Message 6E n

74 t

20

50 P

05 04 DAEL FLT

◄◄◄ Continuation of Response Message 08 max

43 C

75 u

72 r

◄◄◄ Continuation of Response Message 64 d

0B → ← len

05 06 DAEL BSTR

◄◄◄ Continuation of Response Message 72 r

73 s

0E → ← len

05 01 DAEL VSTR

◄◄◄ Continuation of Response Message 20

43 C

6C l

61 a

73 s

73 s

07 → ← len

05 02 DAEL UINT

◄◄◄ Continuation of Response Message 69 i

73 s

74 t

→




This is an a example off an electrical fault data set event returneed in a response to request for Class 1, 2, 2 and 3 eventss.

EX 5-9 9

►►► ► Request Messsage C8 01 3C 02 C Grp AC FC Var ◄ Response Message M (beginn ning) ◄◄◄ E8 AC

81 C FC

00 IIN1

00 IIN2

06 Quaal

3C Grp

03 Var

06 Qual

3C Grp

004 V Var

06 Qual

58 Grp p

01 Var

5B Qual

01 Rangge

26 000 Size prefixx

02 ← len

7C

38 time

01

F7

00

5C

C3

15 D2 current phhs B

43

04 → ← len

C C3

0D

79

AB

01

0B

003

41

◄ Continuation n of Response Message M ◄◄◄ 00

00 0 ID

06 → ← len

F5

004 → ← len

◄ Continuation n of Response Message M ◄◄◄ 1F A6 6 current phs A

44

04 → ← len

◄ Continuation n of Response Message M ◄◄◄ 83

44 4 04 current phs p C.. ← len →

9A

currrent gnd

43

→ ← lenn

trig → ← len

A

◄◄◄ ◄ Continuation n of Response Message M 43 C

47 7 G

01 → ← len

8D dist →

► Confirm Message ►►► C3 AC

5.5

00 0 FC C

Device attributes a

DNP3 provides a means m to electro onically discov ver various outtstation featurees and attributtes. The originnal purposse was to sim mplify the burrden of config guring master stations. Ideaally, when eithher a master oor outstattion starts up, the master can ask for information i frrom the outstaation and thenn perform sellfconfig guration. Being g able to read and a write the atttributes has othher benefits thhat are beyond tthe scope of thhis docum ment. DNP3 provides a set of standardizzed device attriibutes and an extensible meaans for vendorrs to incorporaate vendor or user-specific attributes. 5.5.1

Group 0 and a attribute sets

Objectt group 0 is assigned a for atttributes that reelate to the ouutstation devicce itself. Variaations for objeect group 0 represent atttributes in the outstation o deviice. 148 Copyright © 2012 IEEE. All rightts reserved.



A dev vice may suppo ort multiple setts of device attrributes. These are differentiaated using indeex numbers. Thhe set of standardized device d attributtes defined by DNP3 are acccessible at indeex 0. Vendorss or users definne utes at indexes 1 and upward for private usee and applicatioons. attribu Object variations

5.5.2

Attribu ute variation numbers n begin at 255 and deecrease downw ward. This connvention is dessigned to perm mit adding g attribute variaations in a con nsistent mannerr to other objecct groups in thee future. Two special s variatio ons are designed to assist master m stations in collecting tthe attributes ssupported by aan outstattion. Outstatio ons that implem ment attribute objects shall include suppoort for these tw wo variations at each in ndex correspon nding to an attrribute set. ⎯ Variation 255 is used to reequest a list off the attribute vvariation numbeers supported bby an outstation. ⎯ Variation 254 is used to reequest all of th he attribute objeects from an ouutstation in a single responsee. Index 0 variations 1 through 253 arre pre-assigned d or reserved foor assignment bby the DNP Users Group. Function codes c

5.5.3

All atttribute variatio ons are readab ble from a maaster by usingg a read requeest, function code 1 [READ D]. Variattions 254, 255, and many otthers cannot bee written, but some variationns may optionnally be writabble depend ding on the outstation capabiilities. Function n code 2 [WRIITE] is used forr the write requuests. General attribute obje ect formats

5.5.4

Every attribute objecct, except variaation 254, has a data type coode, length, annd value formaat. The data typpe a length pro ovide keys for master and ou utstation devicces to interprett the value. Thhe value is sellfcode and explan natory. 5.5.4.1

Pictoriall

octet o transmisssion order ↓ 5 4 7 6

3

2

1

0

← bit position Attribute data type codee Length Attribute value

5.5.4.2

Formal structure s

UINT T8: Attribute daata type code. Speciffies the attributte data type cod de as described d in 5.5.4.3. UINT T8: Length. Speciffies the numberr of octets requ uired to convey y the attribute vvalue that folloows. VARIIANT: Attributte value Encod ding of the attrribute value is dependent on n the variation’’s data type coode. If more thhan one octet is required for a numeeric formatted attribute, the least significannt octet is trannsmitted first. The number oof he length field.. octets in this field is specified by th 149 Copyright © 2012 IEEE. All rightts reserved.



5.5.4.3

Attribute e data type codes c

Every attribute valu ue is construccted according g to one of tthe attribute ddata type codees described in Table 5-16. Tab ble 5-16—Attribute data type codes Code 1 2 3 4 5 6 254 255

Code name VS STR UIINT IN NT FL LT OS STR BS STR U8 8BS8LIST U8 8BS8EXLIST

Descriptioon Visible charracters suitable ffor print and dispplay. Unsigned in nteger. Signed integ ger. Floating-po oint. Octet string g. Bit string. List of UIN NT8–BSTR8 pairrs. Extended list of UINT8–BS STR8 pairs. Objeect length is 2566 plus the value iin the object’ss length octet.

Attribu ute data type codes c do not specify s the num mber of octets required to coonvey the attriibute value. Thhe second d octet in a DN NP3 attribute object o always specifies s the nnumber of octeets. For example, an outstatioon would d most likely reeport an unsign ned integer with h 1, 2, or 4 octeets. Floatin ng-point typess are limited to o 4 octets and 8 octets for ttransporting 322-bit and 64-bbit floating-point valuess. No other sizzes are acceptaable. Implemeenters that use 64-bit floatinng-point valuess shall carefully consid der the consequ uences of possiible non-interoperability. The biit alignment in n bit string typees requires the first bit to apppear in bit 0 off the first octett of the attribuute value. If the number of bits in a bitt string is not an a integral of 8, the unused biits in the last ooctet of the valuue b cleared to 0.. shall be Code 254 2 indicates that t the data ty ype is a list of UINT8–BSTR U R8 pairs and thaat the length occtet in the objeect specifi fies the object’ss true length. Code 255 2 indicates that t the data ty ype is an extend ded list of UIN NT8–BSTR8 ppairs and that thhe true length oof the obj bject is 256 plus the contents of o the length octet in the objeect. NOTE— —A list of UINT T8–BSTR8 pairs contains one or more sets of a UINT8 value foollowed by a BST TR8 value.

5.5.5

Reading attributes a

The fo ollowing examp ples illustrate reading r attributtes.

EX 5-10

This exam mple shows a request r to read d the maximum m receive fragm ment size in the outstation.


01 C FC

00 Grp

F1 Var

00 Quaal

00 Range

00




◄◄◄ ◄ Response Message M (beginn ning) C3 AC

81 C FC

00 IIN1

00 IIN2

0 Grp p

F1 Var

00 Qual

00 Rangge

00

002 ←

02

◄ Continuation n of Response Message M ◄◄◄ DC

05 5 →

bject. Observee that the firstt octet specifiees the data typpe (2, unsigneed The reesponse contaiins a single ob integer); the second octet specifiess the number of octets (2) in tthe actual attriibute value (0xx05DC) reporteed by thee next two octetts. The receivee fragment size was reported aas being 1500 octets. 5.5.6

Reading a list of attrib bute variation ns

This su ubclause descrribes reading a list of attributee variations sup upported in an ooutstation. 5.5.6.1

Variation n 255

Variattion 255 has sp pecial meaning g. It is used to retrieve a list of attribute vaariation numbeers supported bby an outtstation. This object o has a vaariable length that t depends onn the count off attribute variaations supporteed by thee outstation. Th he list does not include variatiions 254 and 2255. 5.5.6.2

Retrievin ng a list of sttandard attribute variatio ons

The prrocedure for up ploading a list of DNP3-defin ned device attriibutes from ann outstation is aas follows: a))

The master issues a read request, using g the read funcction code for object group 00, variation 255, from index 0.

b)) The outstattion responds with w a list of the t device attriibute variationns, and the prooperties of thosse attribute vaariations, that itt supports. Thee response usees qualifier codde 0x17, and thhe 1-octet rangge field holds a count of 1.

EX 5-11

This exaample shows a request to reead a list of aattribute variattions from thee outstation. T The outstation n in this exam mple supports 26 2 different deevice attribute variations: 2117 to 233, 2377 to 241, 248 to 250 and 252 2.


01 C FC

00 Grp

FF Var

00 Quaal

00 Range

00

◄ Response Message M (beginn ning) ◄◄◄ C3

81

00

00

00

FF

17

01

AC

C FC

IIN1

IIN2

Grp p

Var

Qual

Rangge

DB Varr

00 Prop

DC Var

00 Prop

00 Index Prfx

F FE D Data T Type

34

DD Var

000 P Prop

DE Var

Lengthh

◄ Continuation n of Response Message M ◄◄◄ D9 Var

00 0 Prop

DA Var

00 Prop




◄◄◄ Continuation of Response Message 00 Prop

DF Var

00 Prop

E0 Var

00 Prop

E1 Var

00 Prop

E2 Var

00 Prop

E3 Var

00 Prop

E6 Var

00 Prop

E7 Var

00 Prop

E8 Var

00 Prop

E9 Var

00 Prop

EF Var

00 Prop

F0 Var

01 Prop

F1 Var

00 Prop

FA Var

00 Prop

FC Var

00 Prop

◄◄◄ Continuation of Response Message E4 Var

00 Prop

E5 Var

00 Prop

◄◄◄ Continuation of Response Message 00 Prop

ED Var

00 Prop

EE Var

◄◄◄ Continuation of Response Message F8 Var

00 Prop

F9 Var

00 Prop

Note that variations 254 (0xFE) and 255 (0xFF) are not included in the list even though the device shall support these. Also notice that attribute 240 (0xF0), Maximum Transmit Fragment Size, is writable and all others are not. 5.5.6.3

Retrieving a list of private attribute variations

The procedure for uploading a list of DNP3-defined device attributes from an outstation is as follows: a)

The master issues a read request, using the read function code for object group 0, variation 255, from the index corresponding to the attribute set, index 1 or higher.

b) The outstation responds with a list of the device attribute variations, and the properties of those attribute variations, that it supports. The response uses qualifier code 0x17, and the 1-octet range field holds a count of 1.

EX 5-12

This example shows a request to read a list of all variations available in the user-specific attributes set for ABC Corp defined at index 1.


01 FC

00 Grp

FF Var

00 Qual

01 Range

01

◄◄◄ Response Message (beginning) C3

81

00

00

00

FF

17

01

AC

FC

IIN1

IIN2

Grp

Var

Qual

Range

01 Index Prfx

FE Data Type

0A Length




◄◄◄ ◄ Continuation n of Response Message M F0 Var

00 0 Prop

F6 Var

00 Prop

F7 Varr

00 Prop

F8 Var

00 Prop

F9 Var

000 P Prop

The reesponse showss that the ABC C Corp set of attributes a has vvariation numbbers 240 and 2446 through 249, and all of those attrib butes are read only. Note thatt variations 25 4 (0xFE) and 2255 (0xFF) aree not included in t device shalll support thesee. the list even though the 5.5.7

Reading all a attributes single reque est

There are two metho ods to read all of o the attributes associated wiith a single poiint. 5.5.7.1

Specific variations re equest

The sp pecific variatio on approach req quires the mastter to know whhich attributes aare available fi first. To find ouut, the maaster sends a reequest for a listt of attributes using u variation 255 in the reqquest as describbed in 5.5.6. The seecond step req quires the mastter to constructt a request conntaining one obbject header inn the request fo for each attribute a it desires in the ressponse. This method m can cauuse a lengthy request messaage but does not affect the response leength. As an example, supp pose an outstattion supports the t variations 2221, 224, 229,, 233, and 239 at index 0. Thhe requesst would includ de 5 object heaaders: a))

Group 0, vaariation 0xDD, qualifier 0x00 0 and range 0xZ ZZ, 0xZZ.

b)) Group 0, vaariation 0xE0, qualifier q 0x00 and range 0xZ ZZ, 0xZZ. c))

Group 0, vaariation 0xE5, qualifier q 0x00 and range 0xZ ZZ, 0xZZ.

d)) Group 0, vaariation 0xE9, qualifier q 0x00 and range 0xZ ZZ, 0xZZ. e))

Group 0, vaariation 0xEF, qualifier 0x00 and range 0xZ ZZ, 0xZZ.

Wheree 0xZZ specifiees the index co orresponding to o the desired atttribute set. 5.5.7.2

Non-spe ecific variatio ons request

The non-specific vaariation approach requires thee master to coonstruct a requuest containingg a single objeect headerr having variattion 254: ⎯ Group 0, vaariation 0xFE, qualifier 0x00 0 and range 0xxZZ, 0xZZ (whhere 0xZZ speecifies the indeex correspondiing to the desirred attribute set). The master m can then n choose any, or o all, of the atttribute objects returned in thhe response forr which it has aan interesst. 5.5.8

Writing atttributes

Those attributes in an n outstation that are writable can be set from m the master sttation. To dettermine which of the attributes are writablee, the master shhall first send a request for a list of attributees using variation 255 in the request as described in i 5.5.6. Only those attributees in the returnned list with thhe ble property bitt set can be wriitten; all otherss cannot. writab 153 Copyright © 2012 IEEE. All rightts reserved.



The objects in a write message are formatted according to 5.5.4. The allowed values that may be written to numeric-valued attributes are not specified unless limits appear in the descriptions in Annex A. Vendors may limit the range to values suitable for their device. If a master writes a value that is unacceptable to the outstation, the outstation shall not change its existing attribute value, and the internal indications bit IIN2.2 [PARAMETER_ERROR] shall be set in the response. Vendors are not required to store attribute values in non-volatile memory. Therefore, attributes that were written by the master are not guaranteed to retain their values after a reset of any kind and for any reason.




6 6.1

Applicatio on Layer— —part 3: Sta ate tables a and diagra ams Outstatio on fragmen nt state table e

The pu urpose of this state table is to o specify an ou utstation’s behhavior with reggard to fragmennt reception annd transm mission. The ou utstation needss to examine th he FIR, FIN, and a UNS bits aand the SEQ vvalue in the appplication contrrol octet of o received fraagments. It shall also inspect the Applicatioon Layer functtion code. In adddition, it needds to rem member the SE EQ value and all a of the octetts in request frragments that it accepts and in the responsse fragmeents that it tran nsmits. The ou utstation accep pts request frag gments if they contain a valiid request andd meet the criteeria in the tablle; otherw wise it discard ds the fragmen nts and remaiins in the sam me state. The outstation dooes not need to remem mber applicatio on control octett bits or values or any of the ooctets from fraagments that it discards. In thiss subclause, th he term “valid request” referrs to a fragmennt received wiith a function code that has a value in the range of o 1 to 128 an nd that is listeed in Table 6--1, and the FIIR, FIN, and U UNS bits in thhe o have the following f cond ditions: application control octet ⎯ FIR = 1 ⎯ FIN = 1 ⎯ UNS = 0 The ou utstation shall maintain m severral local variab bles for each maaster with whicch it communiicates. ⎯ FirstValidR RequestAccepteed. This Booleean variable is used to synchhronize the proocessing of SE EQ values in valid v requests. The value off this variable is cleared to false at startuup, immediately following a restart. It is seet to true when the first valid request is receeived as shownn in the table. ⎯ ECSN.26 Th his variable’s name n stands forr Expected Coonfirm Sequencce Number. (Thhe name is shoort so that it fitts in the state taable.) If the outstation is expeecting a confirm mation to a sollicited responsse, the value of o this variablee contains the sequence num mber that appeears in the appplication contrrol octet of thee solicited ressponse awaitin ng confirmatioon; otherwise, it has a valuee of NE, whicch stands for Nothing Expeected. Only so olicited confirm mations that aare received w with a sequencce number maatching ECSN are processed;; all others aree discarded. Thhis variable dooes not have anny significancee for unsoliciteed responses, although a its vallue may be sett or examined w while awaitingg a confirmatio on to an unsoliccited response. ⎯ The SEQ vaalue from its most m recently acccepted valid rrequest fragmennt. ⎯ The Application Layer octets from its most m recently acccepted valid reequest fragmennt. ⎯ The FIR, FIIN, and CON bits b and the SE EQ value in its most recently transmitted soolicited response fragment. ⎯ The Application Layer octets from its most m recently traansmitted soliccited response fragment. ⎯ The FIR, FIN, F and CON bits and the SEQ S value froom its most reccently transmitted unsoliciteed response fraagment. ⎯ The Application Layer octets from its most m recently traansmitted unsoolicited responnse fragment. Outstaation software requires r three states s for propeer reception. 26

This standard uses ECS SN only to explain n the intended beh havior. Alternativee approaches are aacceptable provideed they yield correect results.




a)

Idle state: The software is idle waiting for a fragment to arrive or for an event to occur that would trigger an unsolicited response. In some cases, a deferred request may be available upon entry to this state as a consequence of actions in another state. When there is such a deferred request available, it shall be processed immediately as though it had just been received. The software starts up in the idle state.

b) Wait Solicited Confirm state (abbreviated WaitSolCfm in table): The device received from the master a request that caused the outstation to send a response requiring a confirmation (e.g., includes events or has multiple fragments), and the outstation is waiting for the confirmation. c)

Wait Unsolicited Confirm state (abbreviated WaitUnsolCfm in table): The device transmitted an unsolicited response and is waiting for a confirmation from the master. It should be noted that expectation of a solicited confirm can occur while the software is in the Wait Unsolicited Confirm state due to a non-read request being issued by the master for which the outstation is obligated to set the CON bit in the solicited response.

Keys for understanding Table 6-1: ⎯ Labels inside square brackets [ ] in column B are triggering event names associated with the specific state in which it occurs. Note that the same name may be used in different states. ⎯ X means don’t care. ⎯ == means “Is Equal To” (For example, ECSN == NE.) ⎯ != means “Not Equal To” (For example, !=N means not equal to N.) ⎯ The dash symbol “—” means “Not Applicable.” ⎯ In column B, fragments that are received are assumed to be addressed to the outstation unless “with broadcast address” is stated. Fragments having other destination addresses are ignored. ⎯ N and M represent sequence numbers in an application control octet. N is used with regard to the SEQ number received from a non-broadcast, valid master request, or its response. M is used in regard to the SEQ number in the previous (most recently sent) unsolicited response transmited from the outstation. ⎯ When “txCON = 0” or “txCON = 1” appears in columns D and E, it refers to whether the confirm bit is set to zero or one in the application control octet of the outstation’s response. ⎯ When “no response” appears in column E, it refers to the case where a request is received that does not require a response from the outstation. ⎯ Whenever a solicited response is transmitted that requires confirmation, it is assumed that a solicited confirmation timer is re-started. Whenever an unsolicited response is transmitted, it is assumed that an unsolicited confirmation timer is re-started. These timers are different from each other and may need to run concurrently. ⎯ Upon entering the Idle state, if a deferred read request exists, it is handled as though it were received immediately after entering the Idle state. ⎯ For each row of Table 6-1, the software should behave as follows: 1) If the software is currently in the state listed in column A, 2) and the event occurs as shown in column B, 3) and the UNS bit, SEQ number, and Function Code in the received fragment are as shown in column C, 4) then perform the actions stated in column D, 5) and, after performing the action in column D, transition to the state specified in column E; column E specifies one of the states listed under column A. 156 Copyright © 2012 IEEE. All rights reserved.



Idle

If the software state is

A

Current state C

0

0

X

[REPEAT_FRAG_RCVD] Request fragment received.

[CONFIRM_RCVD] Confirm received.

X

0

[NEW_FRAG_RCVD] Request fragment received.

—

—

X

N

Confirm

Valid Request

Valid Request

157

—

If no response or txCON = 0, Idle; else WaitSolCfm


Idle

Idle

If no response or txCON = 0, Idle; else WaitSolCfm Accept fragment and process request. Send response if If no response or required. If txCON set to 1, then set ECSN to sequence txCON = 0, Idle; number in transmitted fragment. else WaitSolCfm Accept fragment then send same response. Do not process the request.

Discard confirm fragment; do not remove any events.

No

Yes

Accept fragment and process request. Set variable FirstValidRequestAccepted to true. Send response if required. If txCON set to 1, then set ECSN to sequence number in transmitted fragment. Accept fragment and process request. Send response if required. If txCON set to 1, then set ECSN to sequence number in transmitted fragment. Compare octet-by-octet with previous request fragment. Do they match?

Accept fragment and process request. Never send a response.

Valid Request

WaitUnsolCfm

If txCON = 0, Process read request and send response if required. If txCON set to 1, Idle; then set ECSN to sequence number in transmitted fragment. else WaitSolCfm Increment M, modulo 16, and send unsolicited response with UNS and CON bits set.

Valid Request

and go to this state

E

Transition to state

Send unsolicited NULL response with UNS, CON and IIN1.7 bits set WaitUnsolCfm and seq = any legal value.

D

Action

—

—

—

then perform this action


!=N

X

—

—

0

—

—

and received fragment contains Function UNS SEQ Code

[FIRST_FRAG_RCVD] First request fragment received following a restart.

[RESTART] A restart occurred and outstation is configured to send unsolicited responses. [DEFERRED_READ_EXISTS] A read request exists that was deferred in another state. [UNSOL_TRIGGER] The outstation is configured to send unsolicited responses, ECSN == NE and something occurs to initiate a new original unsolicited response sequence. [BROADCAST_FRAG_RCVD] Fragment received with broacast address.

and this occurs

B

Event that triggers an action and possible transition

Table 6-1—Outstation fragment state table


10

9

8

7

6

5

4

3

2

1


Wait Unsolicited Confirm

Wait Solicited Confirm


A

Current state

0

[MATCHING_SOL_CONFIRM_RCVD] Solicited confirm received, seq number == 0 ECSN. [NON-MATCHING_SOL_CONFIRM_RCVD] Solicited confirm received, seq number != 0 ECSN.

—

[SOL_CONFIRM_TIMOUT] Timeout of solicited confirmation timer.


158


!= Confirm ECSN

Yes

Accept fragment then send same response and restart confirmation timer. Do not process the request. Assume confirmation failed and set ECSN to NE. Accept fragment and process request. Send response if No required. If txCON set to 1, then set ECSN to sequence number in transmitted fragment. Note failure to confirm and set ECSN to NE. Do not remove any events, do not send retries.

Assume confirmation failed and set ECSN to NE. Accept fragment and process request. Never send a response. Assume confirmation failed and set ECSN to NE. Accept fragment and process request. Send response if required. If txCON set to 1, then set ECSN to sequence number in transmitted fragment. Compare octet-by-octet with previous request fragment. Do they match?

Process the confirmation and set ECSN to NE.

—

Valid Request

Valid Request

Valid Request

== Confirm ECSN

—

N

!=N

0

0

X


Confirm

X

WaitUnsolCfm

WaitUnsolCfm

Idle


WaitSolCfm

—


Idle

WaitSolCfm

WaitSolCfm

If fragment is transmitted and txCON = 1, WaitSolCfm; else Idle

Accept fragment, set ECSN to NE, and process confirm. If one fragment of multi-fragment message is being confirmed, and a subsequent fragment is necessary, then increment N, modulo 16, and send the next fragment. If txCON set to 1, then set ECSN to sequence number in transmitted fragment. Discard confirm fragment; do not remove any events.


E

Transition to state


D

Action

!= Confirm ECSN

== Confirm ECSN

0

[REPEAT_FRAG_RCVD] Request fragment received. (N is SEQ value in last valid request received.)

[BROADCAST_FRAG_RCVD] Fragment received with broadcast address. [NEW_FRAG_RCVD] Request fragment received. (N is SEQ value in last valid request received.)

C and received fragment contains Function UNS SEQ Code

[NON-MATCHING_SOL_CONFIRM_RCVD] Confirm fragment received. (N is SEQ value 0 sent in response awaiting confirm.) [UNSOL_CFM_RCVD] 1 Unsolicited confirm received.

[MATCHING_SOL_CONFIRM_RCVD] Confirm fragment received. (N is SEQ value sent in response awaiting confirm.)

and this occurs

B



21

20

19

18

17

16

15

14

13

12

11



A

Current state

0 0

0

0

[BROADCAST_FRAG_RCVD] Fragment received with broadcast address.

[READ_REQ_RCVD] Read request received.

[NON-RD_REQ_RCVD] A non-read request is received.

[REPEAT_NON-RD_ RCVD] A non-read request is received.

—

—

—

[UNSOL_CONFIRM_TIMOUT_NO_DEFER] Timeout waiting for confirm. A read request is — not deferred.

—

—

—

Non-read Valid Request

Non-read Valid Request

Read Request

Valid Request

Confirm

D

Action

159

If ECSN == NE, Idle; else WaitSolCfm

—

Idle

Note failure to confirm and terminate expectation of an unsolicited confirm. Terminate unsolicited response series. Note failure to confirm. Have configured number of unsolicited retries been transmitted? Assume confirmation failed and terminate expectation Yes of an unsolicited confirm. Terminate unsolicited response series.

WaitUnsolCfm

Accept fragment then send same response. Do not WaitUnsolCfm process the request. Set ECSN to NE. Accept fragment and process request. Send response if required. If txCON set to 1, then set WaitUnsolCfm ECSN to sequence number in transmitted fragment.

—

WaitUnsolCfm

WaitUnsolCfm

WaitUnsolCfm

WaitUnsolCfm

If ECSN == NE, Idle; else WaitSolCfm


E

Transition to state

Set ECSN to NE. Do not remove any events, do not send retries.

No

Yes

Set ECSN to NE. If a deferred read request exists, discard it. Accept fragment and process request. Never send a response. Set ECSN to NE. If a deferred request already exists, replace it with this request. Defer building the read response by holding request until the software enters the Idle state. Set ECSN to NE. If a deferred read request exists, discard it. Accept fragment and send response. If txCON set to 1, then set ECSN to sequence number in transmitted fragment. If a deferred read request exists, discard it. Compare octet-by-octet with previous request. Do they match?

Discard confirm fragment.

Accept fragment and process confirm.



—

N

!= N

X

X

!=M

—

[SOL_CONFIRM_TIMOUT] Timeout of solicited confirmation timer. [UNSOL_CONFIRM_TIMOUT_ DEFER] Timeout waiting for confirm. A read request is deferred.

1

[NON-MATCHING_UNSOL_CFM_RCVD] Confirm fragment received.

Confirm

[MATCHING_UNSOL_CFM_RCVD] Unsol confirm received. M

1

and this occurs

C and received fragment contains Function UNS SEQ Code

B



33

32

31

30

29

28

27

26

25

24

23

22



A

Current state

and this occurs

B

160

No

D

Action

Transmit an identical or regenerated retry unsolicited response.



and received fragment contains Function UNS SEQ Code

C



WaitUnsolCfm


E

Transition to state

34


6.2

Outstatio on fragmen nt state diag gram

Figure 6-1 diagramss the outstation n fragment statee.



Authorized licensed use limited to: UNIVERSIDADE FEDERAL DA BAHIA. Downloaded on August 10,2015 at 14:58:21 UTC from IEEE Xplore. Restrictions apply. No Resp or txCON=0

No

Yes

No Resp or txCON=0

NON-MATCHING_SOL_CFM_RCVD UNSOL_CFM_RCVD REPEAT_FRAG_RCVD (compare=yes)

MATCHING_SOL_CFM_RCVD

Yes

Response transmitted with txCON=1

No

Idle

Yes

ECSE=NE

MATCHING_SOL_CFM_RCVD NON-MATCHING_SOL_CFM_RCVD NON-MATCHING_UNSOL_CFM_RCVD BROADCAST_FRAG_RCVD READ_REQ_RCVD NON_RD_REQ_RCVD REPEAT_NON_RD_RCVD SOL_CONFIRM_TIMEOUT UNSOL_CONFIRM_TIMOUT_NO_DEFER (Cfgd retries not exhausted)


Wait Unsolicited Confirm

MATCHING_UNSOL_CFM_RCVD UNSOL_CONFIRM_TIMOUT__NO_DEFER (Cfgd retries exhausted)

No

RESTART UNSOL_TRIGGER

UNSOL_CONFIRM_TIMEOUT_DEFER

Figure 6-1—Outstation fragment state diagram

MATCHING_SOL_CFM_RCVD

Yes

FIRST_FRAG_RCVD NEW_FRAG_RCVD REPEAT_FRAG_RCVD (compare=no) DEFERRED_READ_EXISTS

NEW_FRAG_RCVD REPEAT_FRAG_RCVD (ocmpare=no)

Wait Solicited Confirm

No

SOL_CONFIRM_TIMEOUT BROADCAST_FRAG_RCVD

BROADCAST_FRAG_RCVD CONFIRM_RCVD REPEAT_FRAG_RCVD (compare=yes)



6.3

Master solicited s res sponse rece eption state e table

The pu urpose of this reception r state table is to speecify a master’ss behavior wheen fragments aare received with the UN NS bit equal to o 0 in the appliication controll octet. The maaster software needs to exam mine the FIR annd FIN biits and the SEQ Q value in the application a con ntrol octet. It aalso needs to reemember the FIR and FIN bitts, the SE EQ value, and all of the octetts from the preeviously acceppted solicited rresponse fragm ment. The master acceptts the fragmentt if it meets thee criteria in thee table; otherwiise it discards tthe fragment. T The master doees not neeed to rememb ber application control octet bits or values or any of thee octets from ffragments that it discard ds. The master shall also remember the SEQ S value from m the last requuest fragment that it sent in a requesst to the outstattion. A masster should keeep a separate seet of variables for f each outstaation with whicch it communiccates. The vaariables include, as a minimu um: ⎯ The FIR an nd FIN bits an nd the SEQ value v from thee most recentlly accepted soolicited response fragment ⎯ The octets from f the most recently r accepted solicited reesponse fragmeent ⎯ The SEQ vaalue in the mosst recent request fragment it ttransmitted The master m maintain ns a separate and a independen nt set of variabbles for solicitted and unsoliicited responsees. The sttate machines should s run concurrently in maasters that suppport unsolicitedd responses. An ou utstation should d also maintain additional infformation from the Transport FFunction (Clausee 8) and from thhe Data Link L Layer (Clau use 9).

Master software for handling h soliciited responses requires three states for propper operation. a))

Idle state: The T master is waiting w for the DNP3 user sooftware at a higgher layer to innitiate a requesst. The master starts in this sttate immediateely following a reset.

b)) AwaitFirstt state: The sofftware is waitin ng for the firstt fragment of thhe expected reesponse to arrivve from the ou utstation. c))

Assembly state: s While in n this state, the master is awaaiting more fragments from a multi-fragmennt response.

Keys for f understandiing Table 6-2: ⎯ X means do on’t care. ⎯ The dash sy ymbol “—” meeans “Not Appllicable.” ⎯ N is any valid sequence nu umber. ⎯ N + 1 is N plus p 1 modulo 16. ⎯ != means “N Not Equal To” (For example,, !=N means noot equal to N.) ⎯ For each row of the Tablee 6-2, the softw ware should behhave as follow ws: 1) If the software is currrently in the staate listed in collumn A, 2) and thee user initiates transmission of o a request, thhe response tim mer times out or a fragment is receiveed with the fields of the appliccation control octet as shownn in column B, 163 Copyright © 2012 IEEE. All rightts reserved.



3) and the fields of the application control octet in the most recently accepted solicited fragment were as shown in column C, 4) and the sequence number in the request’s application control octet was as shown in column D, 5) then perform the actions stated in column E, 6) and, after performing the action in column E, transition to the state specified in column F; column F specifies one of the states listed under column A.




Assembly

AwaitFirst

Idle


A

Current state

X

X

0

0

1

0

1

1

0

0

0

1

0

0

0

0

0

N

!=N and != N+1 N+1 != N+1

N+1

N

1

X

X

X

X

1

0

0

0

N

X X X

1 X !=N 1 1 N Response timer times out

N

X

—

X

C

D

E

Action

0

0

0

0

0

0

0

X X X

X

X

—

N

N

N

N

N

N

N

X X X

X

X

—

Idle

Idle

165

Compare octet-by-octet with previous accepted fragment. If octets If octets match, match, send confirm if requested, take no further action, and start Assembly; fragment receive timer. If octets do not match, discard fragment else Idle and do not confirm.

Discard fragment and do not confirm.

Send confirm if requested, accept fragment, and process fragment. Idle



N

X

X

X

X

X

X

N N X

N

X

—


F

Transition to state

Idle If response Transmit the user request and if response expected, start fragment expected receive timer. AwaitFirst; else Idle. Discard fragment and do not confirm. AwaitFirst Send confirm if requested, accept fragment, process fragment, and Assembly start fragment receive timer. Discard fragment and do not confirm. AwaitFirst Send confirm if requested, accept fragment, and process fragment. Idle Note lack of response. Idle Compare octet-by-octet with previous accepted fragment. If octets If octets match, match, send confirm if requested, take no further action, and start Assembly; fragment receive timer. If octets do not match, discard fragment else Idle and do not confirm. Discard fragment and do not confirm. Idle Send confirm if requested, accept fragment, process fragment, and Assembly start fragment receive timer.

and field and the fields in the most in recently accepted solicited request then perform this action fragment were was FIR FIN SEQ SEQ X X X X Discard fragment and do not confirm.

User initiates a request

and the user initiates a new request, the response timer times out or a fragment is received with these fields FIR FIN SEQ X X X

B


Table 6-2—Master reception state table, solicited responses


14

13

12

11

10

9

8

5 6 7

4

3

2

1



A

Current state

and the user initiates a new request, the response timer times out or a fragment is received with these fields FIR FIN SEQ 1 0 N 1 0 !=N 1 1 X Response timer times out

B

D

166

Idle Idle Idle Idle

Discard fragment and do not confirm. Discard fragment and do not confirm. Discard fragment and do not confirm. Note lack of response.

F

Transition to state


E

Action



and field and the fields in the most in recently accepted solicited request fragment were was FIR FIN SEQ SEQ 0 0 N X X 0 N X X X X X X X X X

C



15 16 17 18


6.4

Master solicited s res sponse rece eption state e diagram

Figure 6-2 diagramss the master solicited responsse reception staate. Request R Sent No Response N Expected

Unexpected Fragment Received Idle

Fragment Receeived FIR R = 1, FIN = 1, SEQ S =N or FIR R = 1, FIN = X, SEQ S != N

Request Sent Response Expected Response R Timeout

Fragmeent Received F FIR = 0 AwaitFirst

Fraagment Receivedd FIR = 1, 1 FIN = 0, SEQ Q=N

Frragment Receiveed FIR = 0,, FIN = 0, SEQ = N + 1 or FIR, FIN, SEQ Q and octets maatch previous

Fragment R Received A All other conditioons that do not reesult in loop bacck to Assembly

Response Timeout Assembly

Fig gure 6-2—Ma aster solicited d response rreception sta ate diagram

6.5

Master unsolicited u response re eception sta ate table

The pu urpose of this reception r state table is to speecify a master’ss behavior wheen fragments aare received with the UN NS bit equal to t 1 in the app plication contrrol octet. The m master softwarre needs to exxamine the SE EQ value in the applicattion control occtet. It also neeeds to remembber the SEQ vaalue and all off the octets from pted unsolicited d response frag gment. the preeviously accep A masster should keeep a separate seet of variables for f each outstaation with whicch it communiccates. The vaariables include, as a minimu um: ⎯ The SEQ vaalue from the most m recently accepted a unsoliicited responsee fragment ⎯ The octets from f the most recently r accepted unsolicitedd response fraggment The master m maintain ns a separate and a independen nt set of variabbles for solicitted and unsoliicited responsees. The sttate machines should s run concurrently in maasters that suppport unsolicitedd responses. 167 Copyright © 2012 IEEE. All rightts reserved.



An outstation should also maintain additional information from the Transport Function (Clause 8) and from the Data Link Layer (Clause 9). Master software for handling unsolicited responses requires three states for proper operation. a)

Startup state: The master just started after a reset for any reason and has not performed an initial integrity poll. Refer to 5.1.1.1.2 for more details.

b) FirstUR state: The master started up, completed an initial integrity poll, and is waiting for the first unsolicited response from the outstation. c)

Idle state: The software is idle waiting for a unsolicited response fragment to arrive.

Keys for understanding Table 6-3: ⎯ ‡ means possible data loss or duplicate data. ⎯ X means don’t care. ⎯ The dash symbol “—” means “Not Applicable.” ⎯ N is any valid sequence number. ⎯ N + 1 is N plus 1 modulo 16. ⎯ != means “Not Equal To.” (For example, !=N means not equal to N.) ⎯ IIN1.7 means IIN1.7 [DEVICE_RESTART] bit is set in the response. ⎯ For each row of the Table 6-3, the software should behave as follows: 1) If the software is currently in the state listed in column A, 2) and the SEQ number in the application control octet in the received fragment is as appears in column B, 3) and SEQ number application control octet in most recently accepted fragment is as shown in column C, 4) then perform the actions stated in column D, 5) and, after performing the action in column D, transition to the state specified in column E; column E specifies one of the states listed under column A.




Idle

FirstUR

Startup


A

Current state C

N N N N

N

N+1

!= (N + 1)

X and IIN1.7


169

Send confirm if requested, accept fragment, and process fragment. Send confirm if requested, accept fragment, process fragment, and send reset IIN1.7 request and perform integrity poll. Send confirm if requested. Compare octet-by-octet with previous fragment. If octets match, take no further action. If octets do not match, accept fragment, process fragment, and perform integrity poll. Send confirm if requested, accept fragment, and process fragment Send confirm if requested, accept fragment, process fragment ‡, and optionally perform integrity poll. Send confirm if requested, accept fragment, process fragment, and send reset IIN1.7 request and perform integrity poll.

— —

Prepare to receive unsolicited responses.



D

Action

—

—

and the SEQ number in the most recently accepted unsolicited fragment was

X and IIN1.7

X Initial integrity poll completed X

and a fragment is received with SEQ number

B


Table 6-3—Master reception state table, unsolicited responses


Idle

Idle

Idle

Idle

Idle

Idle

FirstUR

Startup


E

Transition to state

8

7

6

5

4

3

2

1


6.6

Master M unso olicited resp ponse recep ption state d diagram

Figure 6-3 diagrams the master m unsolicited response reception r state..

Startup

Integrity Poll Completed

FirstUR

First Unsoolicited Fragment R Received

IIdle

Unsolicited Fragment Received

Figu ure 6-3—Master unsolicite ed response e reception s state diagram m




7

Sec cure authe entication

7.1

Purpose P

The purposse of this stand dard is to definee a protocol meechanism that: ⎯ A DNP3 outstation can use to unambiguouslly determine itt is communicaating with a usser who is authhorized vices of the ou utstation. to access the serv ⎯ A DNP3 master can use to unaambiguously deetermine that itt is communicaating with the ccorrect outstatiion. This speciffication is fund damentally baseed on IEC/TS 62351-5. 6

7.2

Threats T addressed

This standaard shall addresss only the folllowing security y threats, as deefined in IEC/T TS 62351-2: ⎯ Sp poofing ⎯ Modification M ⎯ Reeplay ⎯ Eaavesdropping - on exchanges of cryptograph hic keys only, not on other data.

7.3

General G prin nciples

This subclaause describes the guiding priinciples behind d this standard,, based on the iidentified threaats. 7.3.1

Authentication n only

This standaard addresses authentication n only, not encryption or otther security m measures. It ddoes not rule oout the possibility of such measu ures being addeed to DNP3 later or through tthe use of exterrnal measures such as “bumpp in the e wire” link encryptors. 7.3.2

Application La ayer only

This stand dard describes authentication n at the Appliication Layer.. Application Layer authenttication is neccessary because: ⎯ DN NP3 must be used u over a vaariety of differrent physical nnetworks and m may be “bridgged” from one to the otther, as in the case c of a TCP/IP terminal seerver or IP raddio. Only autheentication at thhe Applicationn Layer wiill ensure end-tto-end security y. ⎯ Ap pplication Lay yer authenticatiion permits thee possibility off protection agaainst “rogue appplications” that may bee co-resident with w the DNP3 application a and d attempt to usse the DNP3 linnk without authhorization. ⎯ Ap pplication Lay yer authenticatiion permits thee possibility o f authenticatinng individual uusers, as discusssed in 7.3 3.9. 7.3.3

Bi-directional

This stand dard describes a mechanism m that can bee used in eithher transmissiion direction, master-to-outtstation (controlling g direction) or outstation-to-m master (monito oring direction)).




7.3.4

Challenge-res sponse

The mechaanism described d in this standaard is based on n the common security conceept of challengge and response. This principle haas been applied d for the follow wing reasons: ⎯ It places the resp ponsibility for security on thee device that reequires authenntication, whichh is more practtical in d networrk such as those found in the utility industryy. a diverse ⎯ It permits somee communicattion to be lefft unsecured iif desired, redducing bandw width and proccessing requirements. ⎯ It works effectiv vely in a non-co onnection-orien nted environm ment. Because “response” is a keyword k in DN NP3, the term used u in this stanndard is “replyy”. 7.3.5

Prre-shared ke eys

This standaard permits pree-shared keys to o be used by default. This priinciple recogniizes the fact thhat many utilitiees may choose nott to manage seecurity credenttials in a moree sophisticatedd manner but nnevertheless reequire some leevel of protection. This stand dard also prov vides optional methods to remotely r channge pre-sharedd keys using either symmetric or asymmetricc (public key) cryptography. c 7.3.6

Ba ackwards tolerance

This standaard recommends that the following conditiions be satisfieed when a seccure device (onne implementinng this authenticattion mechanism m) communicattes with a non--secure device:: ⎯ Th he secure deviice must be ab ble to detect th hat the non-seecure device ddoes not suppoort the authenttication mechanism. ⎯ Th he non-secure device must continue c to op perate normallyy after being ccontacted by tthe secure devvice. In otther words, the authentication n message cann not cause the noon-secure deviice to fail. ⎯ Th he two devicess must be able to t continue to exchange e inforrmation that is not consideredd critical. However, the t mechanism m’s ability to meet m these cond ditions is largelly dependent onn the quality oof the implemenntation on any partticular device. This standard therefore recommends that ssecure devices avoid sendingg security messsages if it is not kno own whether th he remote deviice supports security. 7.3.7

Upgradeable

This standaard permits sysstem administrrators to change algorithms, kkey lengths, annd other security parameters to deal with futuree requirements.. In keeping wiith the principlle of backwardd tolerance, it aalso permits onne end of a linkk to be upgraded at a a time. 7.3.8

Pe erfect forwarrd secrecy

This standaard follows thee security prin nciple of perfecct forward secrrecy, as defineed in IEC/TS 662351-2. If a ssession key is com mpromised, this mechanism only puts dataa from that paarticular sessioon at risk, andd does not perrmit an attacker to authenticate daata in future seessions. 7.3.9

Multiple users s and auditin ng

This standaard assumes th hat there may be b multiple useers of the systeem located at tthe site of the master. It provvides a method to authenticate a eaach of the userss separately fro om each other aand from the m master itself. 172 Copyright © 2012 IEEE. All rightts reserved.



The intent of this principlle is to permit the outstation to conclusivelyy identify the iindividual userr (not just the ddevice) mits any protoco ol message. Th his information n can be used tto create an auudit trail, whichh NIST definess as “A that transm record sho owing who haas accessed an n Information Technology ((IT) system aand what operrations the usser has performed during a given n period”. Thee creation of su uch an audit trrail is out of thhe scope of thiis standard, buut some dations are given in 7.4.1. recommend This standaard permits outtstations to lim mit access to cerrtain functionss, either based on the individuual identities oof users or based on o the “roles” the users perfform. This rolee-based accesss control is onnly possible iff one of the opptional methods fo or remotely chaanging pre-sharred keys is imp plemented.

7.4

Theory T of op peration

This subclaause describes the operation of the authentiication mechannism in generaal terms for thee benefit of first-time readers. In the case of dissagreements beetween this oveerview subclauuse and 7.5, 7.55 shall be takenn as correct. 7.4.1

Na arrative desc cription

This subclaause describes the operation of o the authenticcation mechaniism as a text narrative. The assumed implementaation architectu ure of this mecchanism is show wn in Figure 77-1. Multiple uusers may eitheer send m or may m choose to authenticate sselected messaages. The authhentication meessages unauthenticcated DNP3 messages, have the ab bility to disting guish between users, while no ormal DNP3 m messages do noot. The authenttication messagges are formatted as a additional DNP3 D function codes and objeect variations. The softwaare architecturee used to parsee, process, and distinguish beetween normal messages and security messages is beyond thee scope of this document. d Implementeers should notee that logging and auditing of security evennts such as authhentication faillures is a criticcal part of informattion security. Itt is recommend ded that all imp plementations at a minimum log all successsful and unsucccessful authenticattions and key changes, c includ ding the time, the t DNP3 addrresses, and the affected user. For the best foorensic results, DN NP3 implemen ntations should d log entire meessages, includding all failedd authenticationn information,, so an auditor can n evaluate the authenticity off the messagess. However, thee provisioningg of logging, reepudiation, andd audit trail is outside the scopee of this stand dard. Guidancee regarding theese capabilitiess may be founnd in the deveeloping o IEEE Std 168 86™-2007 [B8 8]. revisions to




Figure 7-1—Assumed implementation architecture 7.4.1.1

Basic concepts

The authentication mechanism is based on two concepts: ⎯ A challenge and response protocol, as discussed in 7.3.4. The general mechanism is illustrated in Figure 7-3. Because “response” is a keyword in DNP3, the term used here is “reply”. ⎯ The concept of a Message Authentication Code (MAC) that both the outstations and masters calculate based on each Application Service Data Unit (ASDU, or protocol message) that is to be authenticated. A MAC algorithm is a mathematical calculation that takes a protocol message as input, produces a smaller piece of data as output, and has the following characteristics: ⎯ The value of the output is sensitive to small changes in the input message, so the output of the MAC can be used to detect if the message was modified. ⎯ The calculation makes intrinsic use of a secret key that is shared by both ends of the communication. ⎯ It is extremely difficult to determine the secret key by viewing the MAC output. ⎯ It is nearly impossible to determine the original message from the MAC. ⎯ It is difficult to find two messages that produce the same MAC. There are several different types of MAC algorithms. In this version of the standard, the term “MAC” may refer to different variations of either the SHA-HMAC algorithm or the AES-GMAC algorithm. This challenge-response mechanism using a MAC is a “unilateral, two-pass authentication” mechanism as described in ISO/IEC 9798-4. 174 Copyright © 2012 IEEE. All rights reserved.



7.4.1.2

Initiating the challenge

The challenge may be initiated either by the master or the outstation. Devices shall issue challenges to protect specific ASDUs that the device considers to be critical. The challenger issues the challenge immediately after receiving the critical ASDU, before taking any action on it. Outstations shall consider all output operations (controls, setpoint adjustments, parameter settings, etc.) to be critical. Other mandatory critical operations are described in 7.5.2.3.2. Each implementation may define additional mandatory critical operations. To protect against replay attacks, the challenge message contains data that changes randomly each time a challenge is issued. The challenger specifies in the challenge message the Message Authentication Code (MAC) algorithm for the responder to use when building the reply. 7.4.1.3

Replying to the challenge

The device (either master or outstation) that receives the challenge must reply before communications can continue. The responder performs the MAC algorithm specified in the challenge message to produce the reply. A shared Session Key known to both devices is an integral part of the computation. The following types of information are included in the computation: ⎯ A number specifying the user on the Master side is included. ⎯ The Challenge Data is included, to protect against replay attacks. ⎯ If the challenger is protecting a specific critical ASDU, data from that ASDU is also included in the computation. This protects against modification of the ASDU by an attacker. The reply includes the resulting MAC Value. 7.4.1.4

Authenticating

Upon receiving the reply, the challenger performs the same calculation on the same data used by the responder. If the results match, the challenger permits communications to continue. If the challenger was protecting a particular ASDU, it processes the ASDU. 7.4.1.5

Authentication failure

If the authentication fails, the challenger shall not use data from the challenged message. If the challenger is an outstation, it shall not perform the operation requested by the master. The challenger may then choose to transmit an error message. To help protect against denial-of-service attacks and attackers learning from repeated challenges, the challenger shall cease to transmit error messages after a configurable number of failures. Refer to 7.6.1.4.2 for more details about the configurable maximum error count. 7.4.1.6

Aggressive Mode

To reduce bandwidth usage, a responder attempting a critical operation may optionally “anticipate” the challenge and send the MAC Value in the same ASDU being protected. This practice is known as “Aggressive Mode”. It eliminates the challenge and reply messages. For this reason, Aggressive Mode is optional in IEC/TS 62351-5. However, the value of Aggressive Mode is considered high enough for DNP3 that all DNP3 implementations of this authentication mechanism are required to support it. Per IEC/TS 62351-5, however, all DNP3 implementations are also required to permit it to be disabled by configuration, so that individual projects can use only challenge and reply if they choose. 175 Copyright © 2012 IEEE. All rights reserved.



Aggressive Mode is a “unilateral, one-pass authentication” mechanism as described in ISO/IEC 9798-4. However, it is somewhat more secure against replay attacks than the mechanism described there, because the Aggressive Mode Request includes information from the most recently received challenge in addition to the sequence number required by ISO/IEC 9798-4. 7.4.1.7

Changing keys

Table 7-1 and Table 7-2 summarize how cryptographic keys are used and updated in this authentication mechanism. At a minimum, keys are managed by the master and by the outstation. Optionally, a trusted third party known as an authority may also help to manage the keys. Table 7-1—Summary of symmetric keys used Type

Use

Change mechanism

Range of expected change interval

Monitoring Direction Session Key

Used to authenticate data transmitted in the monitoring direction by the outstation

The master encrypts the Session Key in a Key Change message using the Update Key

Minutes up to weeks (for infrequently communicating systems)

Control Direction Session Key

Used to authenticate data transmitted in the control direction by the master

The master encrypts the Session Key in a Key Change message using the Update Key

Minutes up to weeks

Update Key

The master shall use the Update Key to periodically change the Session Keys

The Update Key may be pre-shared between two devices, or if it is considered to be compromised, it may be changed remotely using either symmetric or asymmetric cryptography

Months or years

Authority Certification Key (optional)

The authority shall use the Authority Certification Key to change Update Keys. The master shall forward the Update Key encrypted by the authority to the outstation.

The Authority Certification Key is pre-shared by the authority and the outstation and can be changed only by means external to the protocol

Years, if ever

Instead of using the Authority Certification Key, the authority, master, and outstation may optionally use asymmetric cryptography, also called public key cryptography, to remotely change Update Keys. A brief summary of asymmetric cryptography follows. Asymmetric cryptography is based around the idea that each user or device has two keys, one public and one private. The two keys are generated together and linked mathematically such that the public key may be safely transmitted in the clear as long as the private key is kept secret. An attacker cannot deduce the private key from knowing the public key. This permits the following operations: ⎯ An entity may digitally sign a message using its private key. Anyone holding the public key may then verify that the message was sent by that entity and was not tampered with in transit. ⎯ An entity may encrypt a message using someone else’s public key. Only the entity holding the private key will be able to successfully decrypt the message. ⎯ A trusted authority may certify the public key of another entity by digitally signing it. The authority usually also specifies a time period after which the public key is no longer considered valid. 176 Copyright © 2012 IEEE. All rights reserved.



Table 7-2 summarizes how these concepts may optionally be used to change Update Keys remotely. Table 7-2—Summary of asymmetric keys used (optional) Type

7.4.1.7.1

Use

Change mechanism

Range of expected change interval

Authority Private Key

The authority shall use its Private Key to certify the User Public Key of a user.

The Authority Private Key is kept secret by the authority and may only be changed by means external to the protocol.

Years, if ever

Authority Public Key

The outstation shall use the authority’s Public Key to validate the Public Key of a User.

The Authority Public Key may be transmitted anywhere in the clear but must be securely installed in the outstation by trusted personnel.

Years, if ever

User Private Key

The master shall use the user’s Private Key to digitally sign a new Update Key.

The User Private Key shall be generated by the user and ideally should be carried to the master in a physical token by the user. In any case, the mechanism by which the master station accesses the user’s private key must be secure.

Months or years

User Public Key

The outstation shall use the user’s Public key to validate the Update Key of a user.

The User Public Key shall be generated by the user and may be transmitted anywhere in the clear, but the process by which the authority certifies it must be secure.

Months or years. Even if it is not changed, it shall expire periodically and its certification by the authority must be renewed

Outstation Private Key

The outstation shall use its Private Key to decrypt a new Update Key.

The Outstation Private Key shall be generated by the outstation and stored securely on the outstation.

Years if ever

Outstation Public Key

The master shall use the outstation’s Public Key to encrypt a new Update Key for a user.

The Outstation Public Key shall be generated by the outstation and may be transmitted anywhere in the clear, although it must be installed and stored securely in the master by trusted personnel.

Years if ever

Managing session keys

The Session Keys that each device uses to hash the Challenge Data are the most frequently used keys. A different Session Key is used in each direction, so that if the key for one direction is compromised, it does not compromise communications in the other direction. There is a different set of Session Keys and a different Update Key for each user at the master end, identified by a User Number. The master initializes the Session Keys immediately after communications is established and regularly changes the Session Keys thereafter. This practice of periodically changing the Session Keys protects them from being compromised through analysis of the communications link. The master uses a second key, called the Update Key, to encrypt the new Session Keys, together with the Challenge Data, inside a Key Change message. The use of a second key permits the master to change the Session Key even if the original Session Key was compromised. Both the Session Keys and the Update Key are symmetric keys.




The sequence for changing the Session Keys is shown in Figure 7-7 and Figure 7-8. Like the normal authentication mechanism, it is also based on challenge and reply: ⎯ The master sends a Key Status Request message, which contains no data but serves to initiate the process. It does include a User Number which indicates the particular Update Key and set of Session Keys being queried. ⎯ The outstation replies with a Key Status message containing the current status of the keys and some Challenge Data. ⎯ The master updates the Session Keys with a Key Change message. Besides changing the keys, the Key Change message also constitutes a reply to the challenge and permits the outstation to authenticate that the correct entity is attempting to change the Session keys. ⎯ The outstation replies with a new Key Status message. This Key Status message indicates whether the Key Change was successful (i.e.,properly received and authentic) and includes freshly generated Challenge Data. ⎯ Thereafter, the master can send another Key Change message at any time, replying to the most recent Challenge Data it received. The algorithm used to encrypt both the Session Keys together with the Challenge Data is known as a “key wrap” algorithm. The minimum required key wrap algorithms are specified in 7.6.1.2. If either device determines that the communications between them has failed, it shall assume the most recent set of Session Keys have been compromised and shall refuse to use them to authenticate any further Challenge or Aggressive Mode Request messages. The master shall send a Key Status Request at the earliest opportunity after detecting the communications failure, and re-initialize the Session Keys. 7.4.1.7.2

Managing update keys

As discussed in 7.3.9, this authentication mechanism permits multiple users of the system to be authenticated separately from the master itself. Each user is identified by his or her own User Number and has his or her own Update Key and set of Session Keys. Each user may be assigned a Role designating specific actions that the user is permitted to perform. Each user’s Update Key is rarely changed. The reason for such a change is dependent on the security policy of the organization, but may include the Update Key being compromised, or a user leaving the organization. It is vital for security that each device keeps Update Keys secret. The mechanism used to do so is out of the scope of this standard, but implementers should note that if Update Keys are entered or stored on the device in an insecure fashion, the entire authentication mechanism is compromised. It is the responsibility of each master to ensure that users are personally authenticated and securely associated with the Update Keys used to identify them. By default, Update Keys are pre-shared by the master and outstation and must be changed by a mechanism external to the protocol. Such a mechanism must ensure that the Update Key is kept secret and cannot be obtained by eavesdropping in transit. As already discussed, Update Keys may optionally be changed remotely using DNP3 and methods either based on symmetric cryptography or asymmetric (public key) cryptography. An overview showing the difference between the two methods is illustrated in Figure 7-2. Devices may support the symmetric method for remotely changing Update Keys, both symmetric and asymmetric methods, or neither method. Either method requires the participation of a trusted third party known as an authority. The authority is necessary to certify that users are to be added or removed, or that their roles should be changed. It separates the functions of secure communications from the functions of managing Update Keys and users. No particular user of a master or outstation shall be trusted with the capability to add or remove users from an outstation, or to change the actions a user is permitted to perform. That function must be performed by a central authority whose scope is the entire 178 Copyright © 2012 IEEE. All rights reserved.



organizatio on. The authorrity may or maay not be whaat is commonlly known as a Certificate A Authority, althoough it performs a similar functio on. As shown in Figure 7-2 2, the master’ss job is merely y to forward ccertifications oof users to thee outstation froom the authority, and a to ensure that t the new Update U Key is securely transm mitted. The coommunicationss between the master and the autthority for the purpose p of certtifying a user iss out of the scoope of this docuument but musst also be securre.

Figure 7-2 2—Overview of interactio on among au thority, mastter, and outs station 7.4.1.8

Security S stattistics

An importaant feature of the secure auth hentication meechanism is thhat it provides the ability forr the operators of the DNP3 netw work to detect some kinds of attacks. Any A outstation implementingg secure autheentication musst keep statistics on n the operation n of the protoccol state mach hines and reporrt those statistiics using objeccts similar to nnormal DNP3 coun nter objects. If I some statistiics, e.g., autheentication failuures, begin to frequently excceed event repporting thresholds, it may indicaate that an attack is underwaay. Outstations may report seecurity statisticcs objects to m masters d in the authenttication. This permits p the opeerators of the D DNP3 network to detect attaccks that other than those involved monitoring. may be occcurring on otheer DNP3 associiations than thee one they are m 7.4.2 7.4.2.1

Ex xample mess sage sequen nces Overview O

This subclause contains diagrams illu ustrating examp ples of how tthe authenticattion mechanissm shall behavve and provides an n overview of the mechanism m. In the case of o disagreemennts between thhis overview suubclause and 77.5, 7.5 (which pro ovides a formaal description of o the mechanism) shall be taken as correect. Bold arrow ws in these diaagrams represent au uthentication-sspecific messag ges. 7.4.2.2

Challenge C off a critical AS SDU

Figure 7-3 and Figure 7--4 illustrate thee challenge and d reply to a Criitical ASDU.




Responde er

C Challengerr Non-Critical ASDU

Sttandard protocoll response

Processs ASDU U

Critica al ASDU Autthentication C Challenge

Authenticatio on Response Authen nticate Sttandard protocoll response

Proce ess ASDU U

Fig gure 7-3—Example of suc ccessful cha allenge of Criitical ASDU

Responde er

C Challengerr Non-Critical ASDU

Sttandard protocoll response Critica al ASDU

Proce ess ASDU U

Autthentication C Challenge Authenticatio on Response Authen nticate Authentication n Error Not tra ansmitted if Maximum m Error Count exc ceeded

Behave e as if Critical A ASDU had nott been transm mitted

Figure 7-4— —Example of failed f challe nge of Critic cal ASDU 7.4.3

Ag ggressive Mode

Figure 7-5 5 and Figure 7--6 illustrate autthentication off a Critical ASD DU using Aggrressive Mode.




Responde er

C Challenger Non-Critical ASDU A

Sta andard protocol response r A ggressive M ode Request including Cri r tical ASDU

Processs ASDU

Authenticate Sta andard protocol response r

Processs ASDU

Figu ure 7-5—Exa ample of a su uccessful Ag ggressive Mo ode Request

Responde er

C Challengerr Non-Critical ASDU Execu ute

Sttandard protocoll response A ggressi ve M ode Request including Critica l ASDU

Authen nticate Authentication Error E Not tra ansmitted if Maximum m Error Count exc ceeded

Behave e as if Critical A ASDU had nott been transm mitted

Figure F 7-6—E Example of a failed Aggre essive Mode e Request 7.4.4

In nitializing and d changing keys k

Figure 7-7 7 and Figure 7--8 illustrate how w the master in nitializes and cchanges the Seession Keys on startup, perioddically, and after a communicatio ons failure. Fig gure 7-9 illustraates how the auuthority and m master may channge the role off a user g the user different d accesss permissions) and initialize or change the Update Key ffor that (e.g., add a new user or give user.




Figure 7-7—Example of Session Key Initialization and Periodic Update




Figure 7-8—Example of communications failure followed by Session Key Change



….


Figure 7-9— —Example of successful User U Status C Change and Update Key y Change 7.4.5

Sttate machine e overview

Figure 7-1 10 and Figure 7-11 show the major state transitions t for the protocol, excluding the changing of U Update Keys. Thesse diagrams are not normativ ve, nor are they y comprehensiive. However, these figures aare intended too show the generall operation of th he authenticatiion protocol. The detailss of the state machines aree specified in 7.5. If these diagrams diffe fer from 7.5, tthat section shhall be considered to be correct. Subclause 7.5 5 also containss similar figurees for the statee machine usedd to remotely cchange ys. Update Key The Securiity Idle and Wa ait for Reply staates are comm mon to both massters and outstations. The othher states are specific to each type of device.




Rx Invalid Reply and Max Auth Fail Exceeded OR Comms Failure / Tx Key Status Req

Wait for Reply

Rx Valid Reply / Process Critical ASDU & Tx normal protocol

Rx Invalid Reply OR Reply Timeout / Tx Error & Increment Statistics

Security Idle

Comms Failure OR Key Change Timeout / Tx Key Status Req

Key Status <> OK, OR Reply Timeout / Tx Key Status Req

Rx Challenge / Tx Reply

Wait for Key Change Confirmation

Rx Critical ASDU / Tx Challenge

Rx Aggressive Mode Request / Process Data and Tx normal protocol OR Tx Error & Increment Statistics Rx Non-Critical ASDU / Process data & Tx normal protocol

Rx Key Status = OK / Start Key Change Timer

Rx Challenge / Tx Error & Increment Statistics

Max Error Count Exceeded / Start Key Change Timer

Rx Key Status / Tx Key Change

Init

Tx Key Status Req

Wait for Key Status

Reply Timeout / Tx Key Status Req

Event for Other User / Queue until Idle

Rx Challenge / Tx Error & Increment Statistics

Figure 7-10—Major state transitions for master




Figure 7--11—Major sttate transitio ons for outsttation

7.5

Formal F spec cification

This subclaause formally describes d the protocol p used for f this authenttication mechannism. If this suubclause differrs from 7.4, this sub bclause shall be b considered to o be definitive. 7.5.1

Message defin nitions

This subclaause describes the DNP3 meessages used to o implement thhe authenticatiion mechanism m. The DNP3 oobjects used are deefined in Annex A. 7.5.1.1

Master authe entication im mplementatio on

DNP3 massters shall imp plement the au uthentication mechanism m usiing the functioon codes and objects descriibed in Table 7-3. The first co olumn of thee table shows how these ffunction codes and objectss correspond to the 351-5 specificaation and the sttate machines in i 7.5.2. IEC/TS 623




Table 7-3—DNP3 master messages with correlation to IEC/TS 62351-5a

IEC/TS 62351-5 message

Challenge

Reply

Aggressive Mode Request

Key Status Request

Key Change

Message from master contains Description

Requests authentication of the preceding outstation DNP3 Response or Unsolicited Response

DNP3 function codes

0x20 Authentication Request

Provides 0x20 authentication of a Authentication Challenge from Request the outstation

DNP3 objects

g120v1 Authentication Challenge object

g120v2 Authentication Reply object

Provides authentication for the current DNP3 Request

g120v3 Authentication Aggressive Mode Request object. Must be first object. ••• Whatever function code is Objects appropriate in the DNP3 for standard DNP3 Request request ••• g120v9 Authentication MAC object. Must be last object

Requests the current status of the Session Keys


Changes the symmetric Session Keys 0x20 subsequently used Authentication by master and Request outstation for authentication

g120v4 Session Key Status Request object

g120v6 Session Key Change object

Outstation responds with DNP3 function codes

DNP3 objects

0x83 Authentication Response


0x81 Response If authentication was successful

Whatever objects are appropriate for the normal response to the master request that caused the outstation to issue the challenge

0x83 Authentication Response If authentication failed

g120v7 Authentication Error object

0x81 Response If authentication was successful

Whatever objects are appropriate for the normal response to the master request

0x83 Authentication Response If authentication failed



g120v5 Session Key Status object


g120v5 Session Key Status object






DNP3 function codes

DNP3 objects

Error

Indicates the authentication provided in the challenge reply from outstation was incorrect or that the outstation’s Aggressive Mode DNP3 response did not correctly authenticate

0x21 Authentication Request – No Ack


User Status Change

The master informs the outstation that the authority has 0x20 added or deleted a Authentication user or changed Request the information associated with a user

g120v10 Authentication User Status Change OR g120v8 User Certificate

Update Key Change Request

The master begins the process of changing the 0x20 Update Key Authentication associated with a Request particular user by specifying the name of the user

Update Key Change Confirmation

Instead of actually changing the Update Key, the 0x20 master may verify Authentication the outstation has Request the correct Update Key


None

None


None

0x83 Authentication Response If the outstation could g120v7 not validate the User Authentication Error Status Change using object the authority’s credentials 0x83 Authentication Response

g120v11 Authentication Update Key Change Request 0x83 Authentication Response If Request is invalid

g120v15 Update Key Change Confirmation (only)

DNP3 objects

g120v12 Authentication Update Key Change Reply g120v7 Authentication Error object


g120v15 Update Key Change Confirmation

0x83 Authentication Response If authentication invalid






Update Key Change

a


The master encrypts the new Update Key and sends it to the outstation, authenticating it with either an asymmetric digital signature or a symmetric MAC

DNP3 function codes


DNP3 objects g120v13 Update Key Change AND g120v14 Update Key Change Signature (asymmetric method) OR g120v15 Update Key Change Confirmation (symmetric method)


DNP3 objects


g120v15 Update Key Change Confirmation

0x83 Authentication Response If authentication invalid


Shaded cells indicate optional messages.

7.5.1.2

Outstation authentication implementation

DNP3 outstations shall implement the authentication mechanism using the function codes, objects, and Internal Indications described in Table 7-4. The first column shows how they correspond to the IEC/TS 62351-5 specification and the state machines in 7.5.2.




Table 7-4—DNP3 outstation messages with correlation to IEC/TS 62351-5a

IEC/TS 62351-5 Description message

Message from outstation contains

Message initiated because master sent

DNP3 function codes

DNP3 function Codes

DNP3 objects

Challenge

Requests authentication of the preceding master DNP3 Request

Request Secure Confirmation

0x81 Response Sends normal or DNP3 data and requests the 0x82 master to confirm Unsolicited it securely (using Response Aggressive Mode) with CON bit set

Reply

Provides g120v2 authentication of a 0x83 Authentication Authentication Reply Challenge from Response object the master

Provides authentication for Aggressive Mode the outstation’s Request current DNP3 Response

Key Status

Response providing the outstation’s current status of the Session Key.

g120v1 0x83 Authentication Any valid Authentication Challenge function code Response object

0x81 Response or 0x82 Unsolicited Response

Objects appropriate for standard DNP3 response ••• g120v1 Authentication Challenge object

g120v3 Authentication Aggressive Mode Request object. Must be first object. ••• Objects appropriate for standard DNP3 response May also include Challenge Object as in “Request Secure Confirmation” ••• g120v9 Authentication MAC object. Must be last object

g120v5 0x83 Authentication Session Key Status Response object

DNP3 objects

Whatever is appropriate to a solicited request

Any valid request function code, or Master may not have Objects appropriate sent anything but to the request, if the the Outstation Master sent one sent an Unsolicited Response 0x20 Authentication Request

g120v1 Authentication Challenge object

Any valid request function code, or Master may not have Objects appropriate sent anything but to the request, if the the Outstation Master sent one sent an Unsolicited Response


g120v4 Session Key Status Request object





Key Change

Changes the symmetric Session Keys subsequently used by master and outstation for authentication

User Status Change Response

Response indicating the outstation has received a User Status Change

Update Key Change Reply

Acknowledges that an Update Key is being changed and provides a User Number and random data to be used as part of the process



DNP3 function codes

DNP3 function Codes

DNP3 objects


g120v6 Session Key Change object


g120v10 User Status Change OR g120v8 User Certificate


g120v11 Authentication Update Key Change Request

DNP3 objects

0x83 Authentication g120v5 Response Session Key Status If authentication object was successful 0x83 Authentication g120v7 Response Authentication Error If authentication object failed 0x83 Authentication Response None If validation was successful 0x83 Authentication g120v7 Response Authentication Error If validation failed object 0x83 Authentication g120v12 Response Update Key Change If specified user Reply exists 0x83 Authentication g120v7 Response Authentication Error If specified user object does not exist 0x83 Authentication g120v15 Response Update Key Change If authentication Confirmation was valid


Confirms the new Update Key OR Verifies the 0x83 Authentication current Update g120v7 Response Key Authentication Error If authentication object was invalid


g120v13 Update Key Change AND g120v14 Update Key Change Signature OR g120v15 Update Key Change Confirmation g120v15 Update Key Change Confirmation by itself





Error

a

Indicates authentication provided in the previous challenge reply from master was incorrect or that an Aggressive Mode Request did not authenticate



DNP3 function codes

DNP3 function Codes

DNP3 objects



Any valid function code

g120v3 Authentication Aggressive Mode Request object. ••• Objects appropriate for standard DNP3 request ••• g120v9 Authentication MAC object

DNP3 objects

0x83 Authentication Response g120v7 If authentication Authentication Error failed object

Shaded cells indicate optional message.

7.5.1.3

DNP3 sequence numbering

Each DNP3 authentication Challenge, Reply, or Error message shall have the same DNP3 application sequence number as the critical DNP3 fragment that was challenged. Figure 7-12 illustrates how this rule would be applied for a Select/Operate control sequence using challenge and reply. DNP3 application sequence numbers are shown in parentheses. Figure 7-13 illustrates that when Aggressive Mode is used, the sequence numbering is identical to normal non-authenticated DNP3. Implementers should note that the additional challenge and reply messages may require that certain timing parameters, such as the select-operate timeout, be increased. Unless otherwise described in this subclause, normal DNP3 sequence numbering rules apply.




Figure 7-12—Example of DNP3 Select/Operate authentication




Figure 7-13—Example of DNP3 Select/Operate authentication in Aggressive Mode

Figure 7-14—Example of failed DNP3 Select/Operate authentication




7.5.1.4

More DNP3 message examples

Figure 7-15 illustrates several of the messages described in the preceding subclauses as part of a typical initialization sequence. The outstation generates an unsolicited response to notify the master that it has restarted. Rather than confirm the unsolicited response, the master first initializes the Session Keys. Then, when the outstation re-attempts the restart unsolicited response, the master authenticates it before supplying a confirmation. The confirmation is not authenticated, but the outstation requires authentication of the Write operation. Following this sequence, both sides are permitted to use the Aggressive Mode because a complete challenge-reply sequence has taken place in both directions.

Figure 7-15—Example DNP3 initialization sequence Figure 7-16 illustrates how a poll-response sequence could be authenticated in Aggressive Mode. The poll is not considered critical by the outstation, but the confirmation is. Since Responses and Confirms are optionally critical functions, it is up to the master to require that the Analog Change Events are critical, and up to the outstation to require that Confirms are critical.




Figure 7-16—Example DNP3 authentication of outstation polling data

Figure 7-17—Example of failed authentication of outstation data Figure 7-18 illustrates how the authority and a master would change a user’s role (e.g., add the user or change the user’s access permissions) and change the user’s Update Key.



….


Figure 7-18—Successful User Status Change and Update Key Change Figure 7-19 illustrates how a user may change masters and continue communications with an outstation from a different location. Note that the data supplied by the user shall be provided in a secure manner but the details are out of the scope of this standard.




User

New Master

Outstation

User Name and Update Key (not sent via DNP3)

0x20 Authentication Request g120v11 Update Key Change Request

Initiate with User Name. Generate Random Data

0x83 Authentication Response g120v12 Update Key Change Reply

Verify user has been previously created and is still valid. Generate Random Data, and User Number for the supplied User Name.

0x20 Authentication Request g120v15 Update Key Change Confirmation

Verify the confirmation data. If valid, begin session key initialization

0x83 Authentication Response Confirmation g120v15 Update Key Change

Verify the confirmation data.

0x20 Authentication Request g120v4 Key Status Request

Figure 7-19—User changes masters 7.5.1.5

DNP3 state machine overviews

This subclause describes the state transitions in diagrams, using DNP3 function codes and object variations. These overview diagrams show only the major transitions; the tables in 7.5.2 are definitive. 7.5.1.5.1

Authentication and session key change state machines

Figure 7-20 and Figure 7-21 are reproductions of Figure 7-10 and Figure 7-11, respectively, but with DNP3 function codes and object variations substituted for the authentication message names. They are provided here to illustrate how the IEC/TS 62351-5 authentication mechanism is mapped to DNP3. Note that the top portion of the diagram remains the same for both master and outstation although the function codes used for transmitting and receiving the object variations are reversed.




Figure 7-20—Master state machine showing DNP3 function codes and object variations




Figure 7-21—Outstation state machine showing DNP3 function codes and object variations 7.5.1.5.2

Update key change state machines

Figure 7-22 and Figure 7-23 illustrate the state machines for the master and outstation, respectively, when changing the status, role, or Update Key of a user.




Reply Timeout / Tx Update Key Change g120v13 AND g120v14 OR g120v15

Rx Confirmation g120v15 Use New Update Key

Rx Invalid Confirmation g120v15 OR Max Timeouts OR Rx Error g120v7 / Log Event

Wait for Update Key Confirm

Rx Valid Reply g120v12 / Tx Update Key Change g120v13 AND Signature g120v14 OR Confirmation g120v15

Reply Timeout / Tx Request g120v11

Wait for Update Key Reply

Rx Null Response / Tx Request g120v11

Invalid Reply g120v12 OR Max Timeouts OR Rx Error g120v7 / Log Event

Reply Timeout / Tx Status Change g120v10 Wait for User Change Response

Time to Change Update Keys / Tx User Change g120v10 OR g120v8

Error IIN OR Max Timeouts OR Rx Error g120v7 / Log Event

Security Idle Rx other messages / Use other state machines

Tx = Function Code 0x20 Authentication Request Rx = Function Code 0x83 Authentication Response = Need not happen immediately; could return to Security Idle between these states Figure 7-22—Master state machine for Update Key Change




Fig gure 7-23—Outstation sta ate machine for Update K Key Change 7.5.2

Fo ormal proced dures

This subclaause formally describes d the procedures p useed by devices iimplementing tthis authenticaation mechanissm as a part of each h protocol. If th his subclause differs d from 7.4 4, this subclausse shall be connsidered definittive. The state machines m in thiss subclause desscribe the proto ocol in terms oof IEC/TS 623551-5 “messagees”. Refer to 7..5.1 for a description of how eaach of these messages m is im mplemented ussing DNP3 funnction codes aand objects, inn each direction. 7.5.2.1

States S

Table 7-5 describes the states s used by these t state macchines, in the ggeneral order iin which they m might be expected to occur. Refeer to 7.5.1.5 forr an overview of how the statte machines woork together.




Table 7-5—States used in the state machine descriptions State

Implemented in

Description

Refer to Table

Master

Outstation

Wait for Key Status

YES

No

The master has either just initialized, or its Session Keys have expired. It has just transmitted a Request Key Status message and is waiting for the outstation to transmit a Key Status message.

Table 7-13


YES

No

The master has transmitted a Key Change message and is waiting for the outstation to send confirmation that the Key Change has been accepted, by transmitting a Key Status message with the Key Status = <1> OK.

Table 7-13

Wait for Reply

YES

YES

The Session Keys have been initialized and an authentication is in progress. One of the devices has transmitted a Challenge message and is waiting for the other end to transmit a Reply message. The critical ASDU that was challenged has been queued, waiting to be processed if the Reply is valid. It will be discarded if the Reply is invalid or an error condition occurs.

Table 7-8

Security Idle

YES

YES

There is no authentication in progress. The device is executing the standard DNP3 protocol. The Session Keys may or may not be initialized.

Table 7-8

Wait for User Change Response

YES

No

The master has transmitted a User Status Change message and is waiting for the outstation to validate the Certification Data supplied by the authority indicating a change of status, role, or Update Key for a user.

Table 7-14


YES

No

The master has transmitted an Update Key Change Request and is waiting for an Update Key Change Reply from the outstation.

Table 7-14

Wait for Update Key Confirm

YES

No

The master has transmitted a Update Key Change and is waiting for an Update Key Change Confirmation from the outstation.

Table 7-14

In each of these states except Security Idle, the device is waiting for a reply concerning a particular user. Devices shall keep a separate set of timers and states for each user. However, only one user may be in a state other than Security Idle at a time. As illustrated in Figure 7-24, if an event occurs in a state other than Security Idle, and the event concerns a user other than the one which entered that state, the device shall either queue the event or treat it as an error, as described in the state machines. As an example of queuing, consider the case of initialization. If there are three users at the master, the master begins by sending a Request Key Status message for the first user and entering Wait for Key Status for that user. The initialization event for the other two users is queued by the master. The second user does not enter Wait for Key Status until the first user has reached Security Idle by either succeeding—or failing—to initialize its Session Keys. As a different example, consider the case when an outstation is in Wait for Reply state waiting for User 1 to reply to a challenge, when the master unexpectedly sends a valid Aggressive Mode Request message for User 2. Per rows 15 through 17 of Table 7-8, the outstation stops waiting for the master to reply regarding User 1 and processes the request for User 2. The outstation does not process messages for two users at the same time. Any events not covered by these state machines and procedures shall be ignored.




Figure 7-24—Behavior model for multiple users 7.5.2.2

Security statistics

DNP3 implementations shall monitor the use of the Secure Authentication mechanism by counting a variety of protocol events. Outstations shall report the totals in DNP3 objects. Each outstation that implements secure authentication shall report security statistics using the following objects: ⎯ Security Statistic (g121v1) ⎯ Security Statistic Change Event (g122v1) ⎯ Security Statistic Change Event with Time (g122v2) Table 7-6 lists the indexes (point numbers) of each security statistic. They shall be the same for either group 121 (static) or group 122 (event) objects. Each outstation shall maintain a local relative threshold for each statistic determining how often to report the statistic as an event object, as described in 7.6.1.4.2. In addition, the state machines shall use the following moving thresholds to determine when to react to error conditions: ⎯ Max Authentication Failures ⎯ Max Reply Timeouts ⎯ Max Authentication Rekeys ⎯ Max Error Messages Sent ⎯ Max Rekeys Due to Restarts Each time the state machine “resets” one of these Max values, it shall add the configured reporting threshold for that statistic to the current value of the statistic. Devices shall reset all the Max values at startup. Table 7-6 summarizes the action to be taken for each statistic. The state machine tables describe the precise conditions under which the statistics are to be incremented, and the specific actions to be taken. The exception is the 204 Copyright © 2012 IEEE. All rights reserved.



Total Messages Sent and Total Messages received, which are incremented too frequently to be documented specifically. An outstation may report Security Statistic objects on DNP3 associations other than the one the statistics are measuring. This practice permits a master to detect a potential attack on a different DNP3 association by monitoring that association’s statistics. Each statistic object shall contain its Association ID. An association ID of 0 shall indicate the statistic is being reported on the same association it is measuring. The following rules apply regarding statistics reporting on multiple associations. a)

Each association shall report its “own” statistics as points 0 to “n – 1”, where “n” is the number of standard statistics listed in Table 7-6. In this version of the specification, “n” is 18.

b) Statistics for any other associations shall be allocated in blocks of “n” points at the discretion of the outstation. The indexes listed in Table 7-6 become offsets within these blocks. For instance, the second set of statistics reported by an outstation (if it chooses to report more than one set) are always points “n” to “2n – 1” c)

Masters must therefore know what “n” is for any given version of the protocol, based on the Device Attribute variation 210 indicating the number of security statistics.

d) The combination of the Association ID and the point number modulo “n” will always uniquely identify the statistic within the outstation. e)

Association IDs are not necessarily sequential or follow any other pattern. They simply allow the outstation to uniquely identify the association.




Table 7-6—Indexes of security statistics objects Index

Name

Increment whenever…

Default threshold

Additional action

0.

Unexpected Messages

The other device has responded with a message that was not the expected next step in the state machine.

3

Log each occurrence.

1.

Authorization Failures

The other device has replied with the correct authentication information, so the user is authentic, but the user is not authorized to perform the requested operation.

5

Log each occurrence.

2.

Authentication Failures

The other device has provided invalid authentication information such as an incorrect MAC.

5

Report the value of this statistic whenever a Session Key change occurs. If Max Authentication Failures has been exceeded, change session keys and increment the Rekeys Due to Authentication Failure.

3.

Reply Timeouts

The other device has not replied within the configured time required as described in 7.6.1.4.1.

3

If Max Reply Timeouts has been exceeded, cancel the current transaction.

4.

Rekeys Due to Authentication Failure

An Authentication Failure has occurred that causes the master station to change the session keys (i.e., the Authentication Failure threshold was exceeded).

3

If Max Authentication Rekeys has been exceeded, stop changing session keys due to Authentication Failures. Start changing keys due to Authentication Failures again only if they are first changed successfully for other reasons.

5.

Total Messages Sent

The device sends an Application Layer fragment.

100

None.

6.

Total Messages Received

The device receives an Application Layer fragment.

100

None.

7.

Critical Messages Sent

The device receives a Challenge message or transmits an Aggressive Mode Request message.

100

None.

8.

Critical Messages Received

The device transmits a Challenge message or receives an Aggressive Mode Request message.

100

None.

9.

Discarded Messages

The device discards a received message.

10

None.

10.

Error Messages Sent

The device has sent a fragment containing an Error object indicating an authentication failure or potential configuration error.

2

If Max Error Messages Sent has been exceeded, stop sending Error objects. Start sending Error objects again only if session keys are successfully changed.

11.

Error Messages Rxed

The device has received an Error object.

10

None.

12.

Successful Authentications

The device successfully authenticates a message.

100

None.

13.

Session Key Changes

A user successfully changes session keys.

10

None.

14.

Failed Session Key Changes

A user fails to change session keys.

5

None.

15.

Update Key Changes

The master and authority change the Update Key for a user.

1

None.

16.

Failed Update Key Changes

The master and authority fail to change the Update Key for a user.

1

None.




Index 17.

Name

Increment whenever…

Rekeys Due to Restarts

Only used by a master. Set to zero in outstations. The master rekeyed the session keys because the outstation restarted.

7.5.2.3

Default threshold 3

Additional action If Max Rekeys Due to Restarts has been exceeded, stop changing session keys due to outstation restarts until the next Key Change Timeout.

Challenger procedures

7.5.2.3.1

Challenger role

A device, either master or outstation, that requires authentication from the other device in order to communicate, shall be called a Challenger. Challengers shall issue Challenge messages in reply to Critical ASDUs, according to the state machine described in Table 7-8. The Challenger shall calculate pseudo-random Challenge Data according to FIPS 186-2 and include it in the Challenge message. Challengers shall never intentionally retransmit the same Challenge message. Any time a Challenge is issued, it shall be created using new Challenge Data and a new Challenge Sequence Number. Note that in order to reach either of the two states described in Table 7-8, the Challenger must have established a set of Session Keys using the Master state machine in Table 7-13. Each fragment of a multi-fragment Response shall be challenged individually. If a master issues a challenge to a multi-fragment response (function codes 129 or 130) from an outstation, it shall issue a challenge for each fragment in the response. The CON (confirm) bit is never set in Authentication Response fragments transmitted by the outstation unless multiple fragments are sent, or an Aggressive Mode confirmation is requested by sending an Authentication Challenge with the CON bit set, as described in 7.5.2.3.2. 7.5.2.3.2

Critical functions

Each Challenger shall distinguish between Critical ASDUs and Non-Critical ASDUs. A Critical ASDU shall be a message implementing a function that the Challenger requires to be authenticated. IEC/TS 62351-5 states the following minimum requirements: ⎯ Outstations shall consider all output operations (controls, setpoint adjustments, parameter settings, etc.) to be critical. ⎯ Challengers may optionally consider additional functions beyond this minimum subset to be critical. The following rules are used to identify the DNP3 operations that shall be considered critical, requiring authentication. a)

Any Application Layer DNP3 Requests identified with a “MANDATORY” in the “Critical” column of Table 7-7 shall be considered critical operations. DNP3 outstations complying with this authentication mechanism shall require masters to authenticate all DNP3 Request fragments that contain these function codes.

b) DNP3 outstations may optionally require authentication of any other Request fragments.




c)

There are no DNP3 responses that are mandatory for a DNP3 master to designate as critical operations. DNP3 masters may optionally require authentication of any DNP3 response, but are not required to do so for compliance.

d) If a DNP3 device claims compliance with this authentication mechanism, information identifying those function-codes and objects the device considers critical, requiring authentication, shall accompany the Device Profile for the device. e)

Implementers of outstations should note that if an outstation considers Confirm (0x00) function codes to be critical and issues a challenge, the master may not be expecting the message. On half-duplex or multi-drop links, it is possible that the challenge would collide with the master’s next request as shown in Figure 7-25. Outstations that wish to consider confirmations critical shall include an Authentication Challenge object (g120v1) following the regular DNP3 data in the response to be confirmed, as shown in Figure 7-26. Master stations receiving a response with the CON bit set and an Authentication Challenge object included shall issue the confirmation in Aggressive Mode.

f)

Note that this case is an exception to the rule that a complete Challenge-Reply must be completed before Aggressive Mode can be used. There is sufficient information in the Challenge object to create the Aggressive Mode MAC, and the Aggressive Mode confirmation therefore essentially constitutes a Reply.

g) If an outstation wishes to send an Aggressive Mode response or unsolicited response and wishes the master to send the confirmation in Aggressive Mode, the Authentication Challenge object (g120v1) shall be the second-last object and the Authentication MAC (g120v9) shall be the last object. Refer to Table 7-4 for more details. h) An outstation shall not send an Authentication Challenge object (g120v1) in the initial NULL unsolicited response after a restart. i)

A similar problem may occur if a master sends any of the following function codes: 1) Direct Operate—No Acknowledgment (0x06) 2) Immediate Freeze—No Acknowledgment (0x08) 3) Freeze-and-Clear—No Acknowledgment (0x0A) 4) Freeze-at-Time—No Acknowledgment (0x0C) When sending one of these function codes, a master shall either: ⎯ Wait to see if the outstation challenges them before proceeding. ⎯ Send them only in Aggressive Mode.

j)

Any device may arbitrarily decide that a fragment is critical and can therefore initiate a challenge for any reason. The burden is on the replying station to process the challenge regardless of whether it is expected.

k) Any messages capable of changing security configuration parameters shall be considered critical. l)

An outstation receiving a properly authenticated message that is intended to cause a restart (e.g., Warm Restart, Cold Restart, or Activate Configuration) may send a response to the master and restart without waiting to discover whether the response was challenged by the master. A master is therefore not required to challenge such a response even if responses (function code 129) are generally considered critical.




Master

Outstation 0x01 Read g60v2 Class 1 Data

0x81 Response g32v2 16-Bit Analog Change w/o Time Process Analogs 0x00 Confirm

0x83 Authentication Response g120v1 Authentication 0x01 Read Challenge g60v2 Class 1 Data

Figure 7-25—Possible collision of confirmation challenge and next master request

Figure 7-26—Preventing Confirmation challenge collisions using Aggressive Mode




Table 7-7—DNP3 Critical Request function codes Function code Decimal

Description

Hex

Critical

0

0x00

Confirm

optional

1

0x01

Read

optional

2

0x02

Write

MANDATORY

3

0x03

Select

MANDATORY

4

0x04

Operate

MANDATORY

5

0x05

Direct Operate

MANDATORY

6

0x06

Direct Operate—No Acknowledgment

MANDATORY

7

0x07

Immediate Freeze

optional

8

0x08

Immediate Freeze—No Acknowledgment

optional

9

0x09

Freeze-and-Clear

optional

10

0x0A

Freeze-and-Clear—No Acknowledgment

optional

11

0x0B

Freeze-at-Time

optional

12

0x0C

Freeze-at-Time—No Acknowledgment

optional

13

0x0D

Cold Restart

MANDATORY

14

0x0E

Warm Restart

MANDATORY

15

0x0F

Initialize Data (obsolete)

optional

16

0x10

Initialize Application

MANDATORY

17

0x11

Start Application

MANDATORY

18

0x12

Stop Application

MANDATORY

19

0x13

Save Configuration (deprecated)

MANDATORY

20

0x14

Enable Unsolicited Responses

MANDATORY

21

0x15

Disable Unsolicited Responses

MANDATORY

22

0x16

Assign Class

optional

23

0x17

Delay Measurement

optional

24

0x18

Record Current Time

MANDATORY

25

0x19

Open File

MANDATORY

26

0x1A

Close File

MANDATORY

27

0x1B

Delete File

MANDATORY

28

0x1C

Get File Information

MANDATORY

29

0x1D

Authenticate File

MANDATORY

30

0x1E

Abort File

MANDATORY

31

0x1F

Activate Configuration

MANDATORY

32

0x20

Authentication Request

Not applicable

33

0x21

Authentication Request—No Ack

Not applicable

129

0x81

Response

optional

130

0x82

Unsolicited Response

optional

131

0x83

Authentication Response

Not applicable




7.5.2.3.3

Use of Challenge Sequence Numbers

Challengers and Responders shall maintain a Challenge Sequence Number (CSQ) between them to match Replies with Challenges, according to the following rules: a)

Devices shall set their CSQ to zero on startup.

b) Devices shall increment the CSQ each time they transmit a Challenge message. c)

Devices shall set the CSQ of each Reply message to that of the most recently received Challenge message.

d) Devices shall set the CSQ of each Reply or Aggressive Mode Request message to that of the most recently received Challenge message, plus the number of Aggressive Mode Request messages or Reply messages the device has transmitted since receiving the Challenge message. Note that rule c) is a special case of rule d). e)

A device that receives an Aggressive Mode Request message with a valid MAC shall set the CSQ in its next outgoing Challenge message to that found in the Aggressive Mode Request message plus one, unless either: 1) The MAC on the Aggressive Mode Request is invalid. 2) The resulting CSQ would be smaller than the one the device would have sent normally.

f)

If the value of the CSQ reaches 4 294 967 295, the next time a device increments the CSQ, it shall become zero.

g) Challenge Sequence Numbers shall be independent of User Number. In other words, each device need only store a single value of CSQ locally for each direction, regardless of how many users it is communicating with. h) Devices using unsolicited responses shall maintain two sets of Challenge Data, one for Challenges sent in DNP3 responses and one for Challenges sent in DNP3 unsolicited responses. Examples of the effect of these rules are illustrated in Figure 7-27 and Figure 7-28. The notation “Data=A”, “Data=B”, and so on indicates when the outstation changes the Challenge Data and which instance of this data the master uses to construct its Reply or Aggressive Mode Request. Figure 7-27 illustrates a simple case in which a Challenge–Reply sequence is followed by two Aggressive Mode Requests. The CSQ of the Reply matches the Challenge, and the CSQ of each Aggressive Mode Request increments thereafter. The same Challenge Data from the original Reply is used for all transactions. Figure 7-28 illustrates a much more complex case. Following the sequence in Figure 7-27, the outstation sends an unsolicited response at the same time the master requests a critical operation. The messages cross in transit, and the devices must use the CSQs to match transactions. In the middle of this example, the outstation has two Challenges outstanding, one with CSQ=4 and Data=B, and the other with CSQ=5 and Data=C. Following the example in Figure 7-28, one of the following cases may occur depending on what happens first: ⎯ If the master sends an Aggressive Mode Request, it will do so with CSQ=6 and Data=C, the last Challenge Data it received. ⎯ If the master sends a critical ASDU and the outstation challenges it, the new Challenge will contain CSQ=6 and new Data=D. ⎯ If the outstation sends an unsolicited response containing a Challenge, the new Challenge will also contain CSQ=6 and new Data=D.




Figure 7-27—Example use of Challenge Sequence Numbers (part 1)




Figure 7-28—Example use of Challenge Sequence Numbers (part 2)

7.5.2.3.4

Authentication procedures

If the Challenger is in the states Wait for Key Status, or Wait for Key Change Confirmation, when it receives a Reply message, it shall consider the Reply message to be an Rx Invalid Reply event because the Session Keys are not valid. Similarly, if the Challenger receives an Aggressive Mode Request in any of these states, the Challenger shall consider it to be an Rx Invalid Aggressive Mode Request event. Upon receiving a Reply message, the Challenger shall calculate the MAC Value from the information it transmitted in the Challenge message, as described in the definition of the Authentication Challenge object. 213 Copyright © 2012 IEEE. All rights reserved.



If the MAC Value from the Reply matches the calculated MAC Value, and the Challenge Sequence Numbers from the Challenge and Reply messages also match, the Challenger shall consider the Reply message to be a Rx Valid Reply event. Otherwise, the Challenger shall consider the Reply message to be an Rx Invalid Reply event. Upon receiving an ASDU containing an Aggressive Mode Request, the Challenger shall calculate the MAC Value from the information in the ASDU as described in the definition of the Authentication Aggressive Mode Request object. If the MAC Value in the Aggressive Mode Request matches the calculated MAC Value and the Challenge Sequence Number in the Aggressive Mode Request is correct as described in the definition of the Authentication Aggressive Mode Request object, the Challenger shall consider the ASDU to be a Rx Valid Aggressive Mode Request event. Otherwise, the Challenger shall consider the Aggressive Mode Request message to be an Rx Invalid Aggressive Mode Request event. In particular, the Challenger shall consider any Aggressive Mode Request to be an Rx Invalid Aggressive Mode Request event if the Challenger has not previously received at least one Rx Valid Reply event from the Responder. This rule follows from the definition of the Aggressive Mode Request, because the Challenge Sequence Number in an Aggressive Mode Request is derived from the Challenge Sequence Number found in the Challenge most recently received by the Responder. 7.5.2.3.5

Challenger state machine

Challengers (either master or outstation) shall implement the state machine described in Table 7-8. Note that whenever the outstation sets the Key Status to a value other than OK, the set of Session Keys for the identified user shall be considered invalid and all authentication attempts for that user shall fail until the Key Status is OK again.




B

MASTER ONLY. The master receives an unsolicited ASDU that does not require authentication.

The Challenger receives an ASDU that does not require authentication.

The Challenger receives an ASDU that requires authentication.

Rx Unsolicited Non-Critical ASDU

Rx NonCritical ASDU

Rx Critical ASDU

Event description

A

Event

Wait for Key Status (Table 7-13)

IF MASTER and Session Keys are Invalid: Transmit a Key Status Request Message. Start the Reply Timer. Increment the Critical Messages Received statistic.


215

Wait for Reply

Security Idle

Security Idle

D

IF (MASTER and Session Keys are valid) OR IF OUTSTATION: Increment the Challenge Sequence Number (CSQ). Create and transmit a Challenge message calculated from the Critical ASDU. Start the Reply Timer. Queue the Critical ASDU for execution later. Increment the Critical Messages Received statistic.

Process the Non-Critical ASDU and transmit any appropriate response required by the standard protocol.

Process the ASDU and issue a Confirm.

C

Action

Increment the Critical Messages Received statistic Increment the Unexpected Messages statistic. Log the occurrence. Discard the new Critical ASDU. Increment the Discarded Messages statistic.

Increment the Unexpected Messages statistic. Log the occurrence. Discard the new Non-Critical ASDU. Increment the Discarded Messages statistic.

Process the ASDU and issue a Confirm.

E

Next state

Wait for Reply

Wait for Reply

Wait for Reply

Wait for Reply

F

The device is waiting for the other device to authenticate itself.

Next state

The device is executing the standard DNP3 protocol. Action

Wait for Reply

State Security Idle

Table 7-8—Challenger state machine


4

3

2

1


B

The Challenger receives a Reply message that correctly authenticates the other device based on the most recently transmitted Challenge.

The Challenger receives a Reply message that does not correctly authenticate the other device.

The Reply Timer started when entering Wait for Reply state has expired. This may be the standard response timer for the protocol. Refer to 7.6.1.4.1 for details regarding the Reply Timer.

Rx Valid Reply

Rx Invalid Reply

Reply Timeout

Event description

A

Event Action

Next state

Security Idle

Security Idle

Security Idle

D


216

Should not occur—this is an error condition.

Discard the message. Increment the Unexpected Messages statistic. Log the occurrence. Increment the Discarded Messages statistic.

Discard the message. Increment the Unexpected Messages statistic. Log the occurrence. Increment the Discarded Messages statistic.

C

Action

Increment the Reply Timeouts statistic. Cancel the Reply Timer. Discard any ASDUs that were queued pending an authentication Reply. Increment the Discarded Messages statistic.

If the Max Error Messages Sent has not been exceeded, transmit an Error Message with reason <1> Authentication Failed. If the Max Authentication Failures has been exceeded, behave according to the “Max Authentication Failures Exceeded” event below.

Increment the Authentication Failures statistic Cancel the Reply Timer. Reset Max Reply Timeouts. Discard the ASDU that was queued pending authentication. Increment the Discarded Messages statistic.

IF a critical ASDU is queued awaiting the challenge reply, then process the ASDU and transmit the ASDU’s reply. Cancel the Reply Timer. Reset Max Reply Timeouts. Increment the Successful Authentications statistic.

E

Next state

Security Idle

Security Idle

Security Idle

F

Wait for Reply The device is waiting for the other device to authenticate itself.

Security Idle The device is executing the standard DNP3 protocol.

State


7

6

5


B

— The Reply Timeouts statistic has exceeded Max Reply Timeouts — The protocol has detected a communications failure for some other reason. This event affects all users. Refer to 7.6.1.4.1 for details regarding the Reply Timer.

The Authentication Failures statistic has exceeded Max Authentication Failures. This may be due to a Rx Invalid Reply event, or a Rx Invalid Aggressive Mode Request event.

Max Reply Timeouts Exceeded Or Comm Failure Detected

Max Authentication Failures Exceeded

Event description

A

Event Next state

Security Idle

MASTER or OUTSTATION IF Rekeys Due to Authentication Failure statistic is > Max Authentication Rekeys: Reset Max Authentication Failures. IF operating over TCP: Close TCP connection. Log the event.


217


MASTER: IF the Rekeys Due to Authentication Failure statistic is <= Max Authentication Rekeys: Transmit a Key Status Request Message. Start the Reply Timer. Increment the Rekeys Due To Authentication Failure statistic. Reset Max Authentication Failures.

Security Idle

OUTSTATION: Set the current Key Status to COMM_FAIL. Reset Max Reply Timeouts.

D Wait for Key Status (Table 7-13)

Action MASTER: Transmit a Key Status Request Message. Start the Reply Timer. Reset Max Reply Timeouts.

C

Action

MASTER or OUTSTATION: IF Rekeys Due to Authentication Failure statistic is > Max Authentication Rekeys: Reset Max Authentication Failures. IF operating over TCP: Close TCP connection. Log the event.

MASTER: IF the Rekeys Due to Authentication Failure statistic is <= Max Authentication Rekeys: Transmit a Key Status Request Message. Start the Reply Timer. Increment the Rekeys Due To Authentication Failure statistic. Reset Max Authentication Failures. Discard the pending Critical ASDU. Increment Discarded Messages statistic.

OUTSTATION: Discard the critical ASDU that was queued pending authentication. Increment the Discarded Messages statistic. Set the current Key Status to COMM_FAIL Reset Max Reply Timeouts.

MASTER: Discard the critical ASDU that was queued pending authentication. Increment the Discarded Messages statistic. Transmit a Key Status Request Message. Start the Reply Timer. Reset Max Reply Timeouts.

E

Next state

Security Idle


Security Idle


F



State


11

10

9

8


B

The Challenger receives an Error Message.

For MASTER only. Either the Key Change timer has expired, or The Key Change Count has been exceeded. Refer to 7.6.1.4.

For OUTSTATION only. The outstation has not received a valid Key Change message within the Session Key Change interval or Session Key Change count configured at the outstation. Refer to 7.6.1.4.

Rx Error Message

Key Change Timeout

Expected Key Change Timeout

Event description

A

Event

Security Idle


Security Idle


218

Set Key Status = NOT_INIT for the user specified in the timeout. Invalidate those session keys.

Transmit a Key Status Request Message. Start the Reply Timer. Reset Max Rekeys Due to Restarts

Log the Error message, noting that the message was unexpected. Increment the Error Messages Rxed statistic.

Security Idle

OUTSTATION: IF the Rekeys Due to Authentication Failure statistic is <= Max Authentication Rekeys Set the current Key Status to AUTH_FAIL. Increment the Rekeys Due To Authentication Failure statistic. Reset Max Authentication Failures.

Next state D

C

Action

Action

Set Key Status = NOT_INIT for the user specified in the timeout. Invalidate those session keys.

Queue the event and process it after returning to Security Idle state.

Log the error message. If the Error Code is <5> MAC algorithm Not Permitted, use a different MAC algorithm to send the next Challenge. Do not send another Challenge immediately, but wait for an appropriate event to cause the Challenge. Discard the pending ASDU. Increment the Discarded Messages statistic. Increment the Error Messages Rxed statistic. Cancel the Reply Timer. Reset Max Reply Timeouts.

OUTSTATION: IF the Rekeys Due to Authentication Failure statistic is <= Max Authentication Rekeys Set the current Key Status to AUTH_FAIL. Increment the Rekeys Due To Authentication Failure statistic. Reset Max Authentication Failures. Discard the pending Critical ASDU. Increment Discarded Messages statistic.

E

Next state

Wait for Reply

Wait for Reply

Security Idle

Security Idle

F



State


15

14

13

12


B

For OUTSTATION only. The outstation receives a Key Status Request message.

The Challenger receives an ASDU containing an Aggressive Mode Request message that correctly authenticates the other device.

Rx Key Status Request

Rx Valid Aggressive Mode Request

Event description

A

Event Action

Next state

Security Idle

Security Idle

D


219

IF Aggressive Mode is enabled: Perform the operations specified in the ASDU containing the Aggressive Mode Request and transmit any appropriate response required by the standard protocol. Increment the Successful Authentications statistic.

IF USR is valid: Transmit a Key Status message containing the current Key Status. ELSE: Increment the Unexpected Messages statistic. Discard the Key Status Request. Increment the Discarded Messages statistic.

C

Action

Next state

18

Wait for Reply

Wait for Reply

IF Aggressive Mode is enabled for OUTSTATION and the Aggressive Mode Request is an Application Layer Confirm: Process the Aggressive Mode Request, e.g., release buffered events as appropriate. Increment the Successful Authentications statistic. IF Aggressive Mode is enabled for MASTER Process the Aggressive Mode Request and send Confirm if appropriate. Increment the Successful Authentications statistic.

19

17

16

Security Idle

Wait for Reply

F

IF Aggressive Mode is enabled for OUTSTATION and the Aggressive Mode Request is not an Application Layer Confirm: Discard the previously pending Critical ASDU. Increment the Unexpected Messages statistic. Increment the Discarded Messages statistic. Perform the operations specified in the ASDU containing the Aggressive Mode Request and transmit any appropriate response required by the standard protocol. Increment the Successful Authentications statistic. Cancel the Reply Timer. Reset Max Reply Timeouts.

Increment the Unexpected Messages statistic. Discard the Key Status Request. Increment the Discarded Messages statistic.

E



State



B

The Challenger receives an ASDU containing an Aggressive Mode Request that does not correctly authenticate the other device. Note that all Aggressive Mode Requests are invalid until at least one valid challenge reply has been received.

Rx Invalid Aggressive Mode Request

Event description

A

Event

Security Idle


220

IF Aggressive Mode is enabled: Increment the Authentication Failures statistic. IF the Error Messages Sent statistic is <= Max Error Messages Sent: Transmit an Error Message with reason <1> Authentication Failed.

IF the Error Messages Sent statistic is <= Max Error Messages Sent, transmit an Error Message with reason <2> Aggressive Mode Not Supported.

IF Aggressive Mode is enabled: Increment the Authentication Failures statistic. Increment the Unexpected Messages statistic. Discard the Aggressive Mode Request. Increment the Discarded Messages statistic.

IF Aggressive Mode is disabled AND the Error Messages Sent statistic is <= Max Error Messages Sent: In addition to the steps above Discard the pending critical ASDU. Increment the Discarded Messages statistic. Transmit an Error Message with reason <4> Aggressive Mode Not Supported. Cancel the Reply Timer. Reset Max Reply Timeouts.

IF Aggressive Mode is disabled: Discard the Aggressive Mode Request. Increment the Unexpected Messages statistic. Increment the Discarded Messages statistic.

Security Idle

IF Aggressive Mode is disabled: Discard the Aggressive Mode request. Increment the Unexpected Messages statistic. Increment the Discarded Messages statistic.

Action E

Next state D

C

Action

Next state

Wait for Reply

Security Idle

Wait for Reply

F



State


22

21

20


B

For OUTSTATION only. The outstation receives a correctly authenticated Key Change message.

For OUTSTATION only. The outstation receives an improperly authenticated Key Change message.

The device receives a Challenge message.

For MASTER only. The master receives from the authority some new Certification Data for a particular user.

Rx Valid Key Change

Rx Invalid Key Change

Rx Challenge

Authority Changes User Status

Event description

A

Event

Wait for User Change Response (Table 7-14)

Security Idle

Security Idle

Security Idle


221

IF the master and outstation support remotely changing Update Keys: Transmit the Certification Data in a new User Status. Change message or User Certificate message as appropriate. Start the Reply Timer.

Reply as described in 7.5.3.

Set Key Status = AUTH_FAIL. Transmit Key Status message.

Store new keys. Set Key Status = OK. Transmit Key Status message. Reset Max Error Messages Sent. Reset Max Authentication Rekeys.

Security Idle

IF Aggressive Mode is disabled: Discard the Aggressive Mode Request. Increment the Unexpected Messages statistic. Increment the Discarded Messages statistic. IF the Error Messages Sent statistic is <= Max Error Messages Sent: Transmit an Error Message with reason <2> Aggressive Mode Not Supported.

Next state D

C

Action

Action

Queue the event and process it after returning to Security Idle state.

Reply as described in 7.5.3.

Discard the invalid Key Change message. Increment Unexpected Messages statistic. Increment Discarded Messages statistic.

Discard the previously pending Critical ASDU. Store new keys. Set Key Status = OK. Transmit Key Status message. Cancel the Reply Timer. Reset Max Reply Timeouts. Reset Max Error Messages Sent. Reset Max Authentication Rekeys.

IF Aggressive Mode is disabled: Increment the Unexpected Messages statistic. Discard the Aggressive Mode Request. Increment the Discarded Messages statistic.

E

Next state

Wait for Reply

Wait for Reply

Wait for Reply

Security Idle

Wait for Reply

F



State


27

26

25

24

23


For MASTER only. The master receives a response or unsolicited response with the RESTART internal indication set when it was not set previously. If this occurs, execute this row rather than the row that would be normally executed.

Outstation Restarted

This would normally indicate that the outstation Session Keys need to be re-initialized. In case of an attack, the re-keying is throttled using the Rekeys Due to Restarts statistic.

B

Event description

A

Event Action

Next state

Security Idle


D


222

IF Rekeys Due to Restarts > Max Rekeys Due to Restarts Discard ASDU with the RESTART indication: Increment Discarded Messages statistic.

IF Rekeys Due to Restarts <= Max Rekeys Due to Restarts Discard ASDU containing the RESTART indication: Increment Discarded Messages statistic. Increment Rekeys Due to Restarts statistic. Transmit a Key Status Request Message. Start the Reply Timer. Reset Max Reply Timeouts.

C

Action

IF Rekeys Due to Restarts > Max Rekeys Due to Restarts: Discard ASDU with the RESTART indication. Increment Discarded Messages statistic.

IF Rekeys Due to Restarts <= Max Rekeys Due to Restarts: Discard the critical ASDU that was queued pending authentication. Discard ASDU containing the RESTART indication. Increment the Discarded Messages statistic twice. Transmit a Key Status Request Message. Start the Reply Timer. Reset Max Reply Timeouts.

E

Next state

Wait for Reply


F



State


29

28


7.5.2.4

Error messa ages

As described more formaally in Table 7-8, devices may m initially reespond to erroor conditions bby transmittingg Error messages. Error messagees contain a co ode indicating the type of errror, and optioonally contain a UTF-8 textt string TF RFC 3629 describing thee error in moree detail for deebugging purpooses. To help pprotect encoded acccording to IET against den nial-of-service attacks, a dev vice shall stop transmitting E Error messagess after it has ccounted a num mber of errors that exceeds a Maax Error Messaages Sent desccribed in 7.6.1 .4.2. Devices may also chooose to not sendd error a any time, reg gardless of erro or count. messages at Note that error e messagess may be transmitted on a DNP3 associatioon other than tthe one on whhich authenticaation is performed. This may be b extremely useful for deetecting attackks and is theerefore recom mmended. It iis also ded that all erro ors be logged. recommend Table 7-9 illustrates i how w error messagees are implemented in DNP3.. Table 7-9 9—Use of Errror message e objects in D DNP3 Object varia ation

Behavior

0x83 Authen ntication Respon nse 0x21 Authen ntication Requesst – No Ack

Function F code

g120v7 Authenticaation Error (ass an Info object)

Re Response to a seccurity m message on the saame D DNP3 associationn

Notify other device of a possiblle configuration error or lack of synchronizattion

Purpose

0x81 Respon nse 0x82 Unsoliicited Response

g120v7 Authenticaation Error (ass an Event object)

Inncluded with othher daata in an event reesponse on the otther D DNP3 associationn

Detectiion of an attack (see NO OTE)

NOTE—Wh hen the Error Meessage is sent as an event using function f codes 00x81 or 0x82, thee CON bit shall be set. The rule regarding CO ON bits in Autheentication Respo onses in 7.5.2.3.1 1 does not applyy.

7.5.3 7.5.3.1

Re esponder prrocedures Responder role r

A device, either e master or o outstation, th hat supplies au uthentication ddata shall be caalled a Responnder. Each Respponder shall follow w the procedurees described in n this subclausee. 7.5.3.2

Responding to challenge es

A Respond der shall respo ond to a Challenge message with a correcctly-formed Reeply message w within an acceeptable Reply Timeeout defined peer system as deescribed in 7.6.1.4.1. If the follow wing condition ns are met: ⎯ Th he Responder is i a master ⎯ Th he Authenticatiion Challenge object is in a normal n DNP3 rresponse (functtion code 0x811 or 0x82) ⎯ Th he CON bit is set s in the respo onse Then, the master shall, instead of tran nsmitting an Authentication A n Reply objectt, shall transm mit a Confirm (0x00) n Aggressive Mode, M i.e., contaaining: message in ⎯ Fu unction Code 0x00 0 Confirm ⎯ Au uthentication Aggressive A Mo ode Request objject (g120v3) 223 Copyright © 2012 IEEE. All rightts reserved.



⎯ Authentication MAC object (g120v9) The rationale for this rule and an example are found in 7.5.2.3.2. A Responder shall not proceed with further communications until it has successfully responded to the Challenge message. This rule includes not responding to any subsequent Challenge messages until the current Challenge is completed. Upon responding to a Challenge, the Responder shall increment the Critical Messages Sent statistic, counting the original critical ASDU that was challenged. 7.5.3.3

Aggressive Mode

Aggressive Mode, in which a device supplies authentication information in the same ASDU as the data it is authenticating, shall be implemented by all DNP3 devices conforming to this standard. These devices shall also provide a mode of operation in which Aggressive Mode is disabled. A Responder that uses Aggressive Mode shall place a correctly-formed Aggressive Mode Request within the ASDU being authenticated. A Responder shall not transmit an Aggressive Mode Request until it has successfully responded to at least one Challenge message each time the master changes the Session Keys. In other words, the Responder shall send the first critical ASDU after a Session Key change as a normal DNP3 message, not as an Aggressive Mode Request. Upon transmitting an Aggressive Mode Request, the Responder shall increment the Critical Messages Sent statistic. 7.5.3.4

Authentication errors

If the Responder receives an Error Message with reason <1> Authentication Failed after sending an Authentication Reply or Aggressive Mode Request object, the most likely reason is that the Session Keys used in the authentication have become invalid due to a timeout. This may indicate that the master’s Session Key change interval or the outstation’s expected Session Key change interval or the corresponding counts are incorrectly configured to be too small. The other reason a Responder may receive an Error Message with reason <1> Authentication Failed is that an attacker may be trying to provoke the Responder into taking action resulting in a denial of service. For these reasons, the following rules apply: a)

An outstation shall not automatically retry sending an Aggressive Mode Request in an Unsolicited Response if the master sends an Error message.

b) An outstation may retry sending an Aggressive Mode Request in an Unsolicited Response only due to an Application Layer Timeout. Since Application Layer retries are not permitted in DNP3 except for Unsolicited Responses, this is the only case in which an authentication retry might occur. c)

If a user queues critical data for transmission by the master and the master is in the Security Idle state, the master shall transmit the data even if the last Key Status it received from the outstation was not OK; i.e., the Session Keys are invalid and the master was waiting for the Session Key change interval before changing the keys. If the outstation then returns an Error message with reason <1> Authentication Failed, the master shall send a Key Status Request and enter the Wait for Key Status state, attempting to change the Session Keys. This shall only occur when the user queues critical data.

d) If the master receives an Error Message with reason <1> Authentication Failed, but it later succeeds in changing the Session Keys, it may optionally reduce the Session Key change interval and count, with the intent of preventing a subsequent failure. It may do so only once. 224 Copyright © 2012 IEEE. All rights reserved.



7.5.4 7.5.4.1

Master proced dures Master role

In addition to acting as a Challenger and d a Responder,, masters shall follow the proocedures descriibed in this subbclause in order to initialize and change c user key ys, status, and roles at the ouutstation. 7.5.4.2

Changing C se ession keys

There shalll be two Session Keys, on ne used for au uthenticating ddata in the M Monitoring Dirrection, and oone for authenticatting data transm mitted in the Control C Directio on, as describeed in Table 7-1. The outstatiion and masterrs shall maintain a unique set of Session S Keys for f each user off the outstationn, and a defaultt set of Sessionn Keys used foor cases m acts forr multiple userrs (as in the caase of a poll, ffor instance), oor when the ouutstation initiaates the when the master security meessage sequencce. Each masteer shall initializze the Session Keys upon esttablishing com mmunications oor when it detects the outstatiion has restarted, and a periodicallly change the Session Keys as described in Table 7-133. The change interval shall be set using a con nfigurable paraameter as discu ussed in 7.6.1.4 4.3. The masterr shall use a sy ymmetric Updaate Key to enccrypt the Sessi on Keys and ttransmit them tto the outstatioon in a Key Chang ge message. An n Update Key shall s be separaately assigned ffor each combiination of userr and outstationn. Each master shalll also act as a default user off the outstation n under the connditions describbed in Table 77-11. There shaall be a separately assigned Updaate Key and sett of Session Keys K for that deefault user on tthe outstation. It is possible ffor this y user. default user to be the only The masterr shall considerr an attack to be b underway iff the MAC on a Session Key Status object iis found to be iinvalid using the most m recently vaalid Monitorin ng Direction Seession Key. 7.5.4.3

Deriving key ys

All keys ussed in implem menting this staandard shall bee derived in a ppseudo-random m manner that makes it diffiicult to predict whaat the next key y will be. A vaariety of algoritthms exist for deriving crypttographic keyss, and the approopriate algorithm may m vary depeending on the environment in i which DNP P3 is used. Thhe key derivation algorithm cchosen shall be an n open standard d, appropriate for the use beiing made of D DNP3, consisteent with the security policies of the organizatio on implementin ng this standaard and compliant with anyy regulatory rrequirements. Some recomm mended standards for f key derivattion are NIST SP 800-108 an nd ISO/IEC 188033-2:2006. T The Device Prrofile for each device shall speciffy the key deriv vation algorith hm used. 7.5.4.4

Assigning A us ser numbers s

The masterr and outstation shall identify fy with a uniqu ue User Numb er each set off Session Keys that they sharre. The master shaall be responsib ble for initiatin ng the assignm ment of User N Numbers; the outstation shaall be responsibble for choosing th he actual numb ber for each user. Each security message coontains the appplicable User N Number and theerefore specifies th he applicable set s of Session n Keys. The pu urpose of Useer Numbers is to make indivvidual human beings accountable for the criticaal operations th hey perform remotely on the outstation. Figure 7-2 29 shows an ex xample of how User Numberss may be assiggned. In this exxample, there aare two masters, each of which has two users, communicating c g with a singlee outstation. W When a user inittiates a criticall operation thatt sends m to an ou utstation, the master m is respoonsible for authhenticating thaat operation usiing the DNP3 messsages from a master appropriatee User Numberr and correspon nding Session Keys K for that uuser.




Figure 7-29—Example of User Number and Association ID assignments Note that in the example in Figure 7-29, both Bob and Donald have the same User Number. User Numbers need not be unique within the entire outstation, only within a particular DNP3 association. The precise definition of a DNP3 association is found in Annex C, but it essentially means the logical connection between a particular master and a particular outstation. In the example, there are two associations, one from the single outstation to each master. The figure shows a separate software process for each association, but this is done purely for illustration; the associations may be implemented many different ways. Each association uses a particular set of addresses for the master and the outstation. The addresses may include DNP3 Data Link Layer addresses, IP addresses, TCP or UDP port numbers, serial port numbers, and internal software identifiers. Within a particular association, the User Number uniquely identifies a particular user. For most of the security messages, this is sufficient identification. However, there is one exception. As noted in 7.5.2.4, this standard recommends that Error messages be transmitted on associations other than that on which the error occurred, in order to help with intrusion detection. Devices must therefore include in each Error message an Association ID, which is an integer uniquely identifying the DNP3 association and the complete set of addresses it uses. The combination of Association ID and User Number shall uniquely identify a user with an entire device. Table 7-10 shows that in the example, the Association IDs are simply the numbers “1” and “2”.




Table 7-10—Example of User Number and Association ID assignments Association ID

User number

User

Master

Outstation process

1

0

Unknown

X

A

1

1

Default

X

A

1

7

Alice

X

A

1

12

Bob

X

A

2

0

Unknown

Y

B

2

1

Default

Y

B

2

5

Charlie

Y

B

2

12

Donald

Y

B

Note that in each association, the outstation uses the reserved User Number <0> when it is issuing a Challenge but does not yet know the user associated with the critical ASDU it is challenging. The outstation and master also use a second reserved User Number <1> as the default User Number in a number of different situations, as illustrated in Table 7-11. Table 7-11—When to use the reserved User Numbers

7.5.4.5

Case

User number

Outstation sends Challenge

Unknown <0>

Outstation sends Aggressive Mode unsolicited response

Default <1>

Outstation sends Aggressive Mode response

Default <1>

Master Challenges unsolicited response from outstation

Default <1>

Master Challenges response from outstation

Default <1>

Master sends common request (e.g.,poll) for data to be processed by multiple users.

Default <1>

Any other case

<2…65 535>

Changing user status

A master or outstation may optionally permit remotely changing Update Keys using DNP3. There are two possible methods for changing Update Keys based on the type of cryptography used: symmetric or asymmetric. Asymmetric cryptography is sometimes known as public key cryptography. A master or outstation may implement one of the following options with respect to remotely changing Update Keys: ⎯ Do not implement either method. ⎯ Implement the symmetric method only. ⎯ Implement both symmetric and asymmetric methods. The process of changing Update Keys is based on the ISO/IEC 11770 standard (ISO/IEC 11770-2:2008 and ISO/IEC 11770-3:2008). Subclause 7.10 describes how it complies with this standard and summarizes the process using cryptographic notation. The process of changing Update Keys begins with changing the status of a user. The status of a user includes the user’s name, role, key, and expiry interval, as described later in this subclause.




If the master and outstation both permit remotely changing Update Keys, the master shall promptly inform the outstation of changes made by an authority to the status of a user and to the user’s Update Keys, as described in Table 7-14. The authority shall not be the master station itself, but is otherwise not described by this standard. The communication between the authority and the master station shall be secured but is assumed to be a protocol suite other than DNP3. It is therefore not discussed in this standard. Similarly, the authentication of the actual user and the association of the user with the User Name and other information described below must be a secure process, but one that is out of the scope of this standard. Subclause 7.6.1.4.10 contains some notes on this topic. The authority may add users, delete users, or change the information associated with a user via the master station. The information associated with each user (known as the Certification Data) shall be specified in either the User Status Change (g120v10) object or the User Certificate (g120v8) object, and shall include: ⎯ User Name. The name of the user shall be unique within the organization managed by the authority, with one exception: the null-terminated UTF-8 string “Common” shall be used to identify the default Update Key, User Number <1>, used between the master and the outstation. The format of the User Name is otherwise outside the scope of this standard. ⎯ User Role. The authority may change the Role of the user. The Role of the user shall determine what actions a user is allowed to perform on the outstation, as described in Table 7-12. These roles are defined in IEC/TS 62351-8. No user is permitted to change the Role of another user; only the authority may do so. ⎯ User Public Key (optional). The authority may change the Update Key for the user. The master shall provide the new Update Key to the outstation in a confidential, authenticated manner as described in Table 7-14. If the Update Key Change Method is asymmetric, the master shall supply the user’s Public Key to the outstation, un-encrypted but digitally signed by the authority using the Authority Private Key, in the User Status Change (g120v10) object, and shall supply the new Update Key later in the process. ⎯ Expiry Interval. The authority may change the time when the Role of the user and the validity of the Update Key will expire. Table 7-12—User roles Value

Name

Permissions Monitor data

Operate controls

Transfer data files

Change config

Change security config

Change code

Local login

<0>

VIEWER

Yes

No

No

No

No

No

No

<1>

OPERATOR

Yes

Yes

No

No

No

No

No

<2>

ENGINEER

Yes

No

R/W/D

Yes

No

No

Yes

<3>

INSTALLER

Yes

No

R/W

Yes

No

Yes

Yes

<4>

SECADM

No

No

No

No

Yes

Yes

Yes

<5>

SECAUD

Yes

No

R

No

No

No

Yes

No

D

Yes

Roles only

No

No

R/W/D

Yes

Yes

Yes

Yes

<6>

RBACMNT

Yes

<7..32 767>

RESERVED

For future use.

<32 768>

SINGLEUSER

Yes

<32 769 .. 65 535>

PRIVATE

Defined by external agreement. Not guaranteed to be interoperable.

Yes

The SINGLEUSER role in Table 7-12 should be used only for those installations where a single user will regularly require all permissions. It should not be used as the default role. The authority, master, and outstation may use either symmetric or asymmetric cryptography to change the status, Role, Expiry Interval, or Update Key of a user. The method used, including the set of cryptographic algorithms and 228 Copyright © 2012 IEEE. All rights reserved.



DNP3 objects, shall be preconfigured at the master as described in 7.6.1.4.9 and the master shall specify it to the outstation in the User Status Change (g120v10) object or the User Certificate (g120v8) object. The certificate shall conform to the X.509 format as described in IETF RFC 5280, IETF RFC 5755, and IEC/TS 62351-8. The key used to produce the Certification Data shall not be known to the master. If it is symmetric, it shall be known only to the authority and the outstation. If it is asymmetric, it shall be a private key known only to the authority, with the corresponding public key known to the outstation. If the authority changes the Role or Expiry Interval of a user, the authority shall also change the Update Key of that user. The authority shall not re-use Update Keys for the same user over the lifetime of the system. The authority shall provide the master with Certification Data for the default user before the master begins communicating with the outstation. If the outstation is not pre-configured with the default user, the master shall add that user before beginning secure communications with the outstation. 7.5.4.6

Changing update keys

If the master and outstation both permit remotely changing Update Keys, the master may change the Update Key of a user at any time after it has forwarded the Certification Data to the user in a User Status Change (g120v10) or User Certificate (g120v8) object. The master shall do so by sending an Update Key Change Request (g120v11) object containing the User Name of the user and some random Challenge Data. It is recommended that the master begin the Update Key Change process soon after the status change, since any changes to Role or Expiry Interval shall not take effect until the master completes this process. Upon receiving an Update Key Change Reply (g120v12) object from the outstation, the master shall obtain the Encrypted Update Key Data to send to the outstation in an Update Key Change object (g120v13). As described in the definition of that object, the Encrypted Update Key Data shall consist of the following data, encrypted together: ⎯ The name of the user ⎯ The random Challenge Data sent from outstation in the Update Key Change Reply ⎯ The new Update Key for the user The master shall take different actions to obtain the Encrypted Update Key Data and to authenticate the transfer of this data depending on the Update Key Change Method in use: ⎯ If the Update Key Change Method is symmetric, the master shall obtain the Encrypted Update Key Data from the authority. The method used to do so is outside the scope of this standard but the communication must be secured. The authority shall encrypt the Update Key Data using the symmetric key it shares with the outstation (i.e., the Authority Certification Key described in Table 7-1). The master shall authenticate the transfer of the Encrypted Update Key Data by sending an Update Key Change Confirmation (g120v15) object with the Update Key Change (g120v13) object in its request. In this way, the master authenticates the transfer of the Encrypted Update Key Data using the new Update Key itself. ⎯ If the Update Key Change Method is asymmetric, the master shall create the Encrypted Update Key Data using the outstation’s Public Key. The master shall authenticate the transfer of the Encrypted Update Key Data by sending an Update Key Change Signature object (g120v14) with the Update Key Change (g120v13) object in its request. In this way, the master authenticates the transfer of the Encrypted Update Key Data by signing it with the User’s Private Key. The authority securely provided the outstation with the User’s Public Key in the User Status Change (g120v10) object, so the outstation can verify that the master is authentic and the master and authority agree on the new Update Key.




⎯ Using either method, if the master does not wish to actually change the Update Key, it can instead authenticate itself to the outstation and verify that the outstation has the correct Update Key by sending only an Update Key Change Confirmation (g120v15) object, which will cause the outstation to reply with an Update Key Change Confirmation. Upon receiving an Update Key Change Confirmation (g120v15) object from the outstation, the master shall verify that the Message Authentication Code (MAC) in that object is valid. The master calculates this MAC using the random Challenge Data from both itself and the outstation, the user’s name, the User Number (USR), and the Key Change Sequence Number (KSQ). If the MAC is valid, the master shall begin using the new Update Key and User Number for Session Key changes. If the Update Key change process fails at any point, as discussed in Table 7-14, the master shall inform a human of the failure and shall continue to use the previous Update Key for Session Key changes. It is expected that the process will be reinitiated by a human rather than being automatically re-initiated. However, that is beyond the scope of this standard. 7.5.4.7

Master state machine

The master shall execute the state machine described in Table 7-13 and Table 7-14.




B

The master has initialized.

The master receives a Key Status message with the Key Status set to a value other than <1> OK.

The master receives an authentic Key Status message with the Key Status set to <1> OK.

The Reply Timer has expired while the master was waiting for a response from the outstation.

— The Reply Timeouts statistic has exceeded Max Reply Timeouts — The protocol has detected a communications failure for some other reason. This event affects all users. Refer to 7.6.1.4.1 for details regarding the Reply Timer.

Init

Rx Key Status <> OK

Rx Key Status = OK

Reply Timeout

Max Reply Timeouts Exceeded

Event description

A

Event

Action

Security Idle

Wait for Key Status



Wait for Key Status

D

Next state


231

Increment Failed Session Key Changes statistic. Start the Key Change timer and reset the Key Change counter.

Increment Reply Timeouts statistic. Transmit a Key Status Request message. Start the Reply Timer.

Transmit a Key Change message. Start the Reply Timer.


Transmit a Key Status Request message. Start the Reply Timer.

C

The master is waiting for the outstation to send any Key Status message.

Wait for Key Status


Increment Failed Session Key Changes statistic. Start the Key Change timer and reset the Key Change counter.

Increment Reply Timeouts statistic. Transmit a Key Status Request message. Start the Reply Timer.

Start the Key Change timer and reset the Key Change counter. Reset Max Authentication Failures. Reset Max Authentication Rekeys

Increment Unexpected Messages statistic.

Not possible.

E

Action

Security Idle

Wait for Key Status

Security Idle


Not possible

F

Next state

The master is waiting for the outstation to send confirmation that the Key Change has been accepted, by transmitting a Key Status message with the Key Status = <1> OK

State

Table 7-13—Master state machine—Changing Session Keys


5

4

3

2

1


B

Either the Key Change Timer has expired on the master, or the number of transmitted or received protocol messages has exceeded the Message Count Threshold. This event should not happen in either of these states for the current user.

The master receives a Challenge message or Aggressive Mode Request message even though the Session Keys are not yet valid.

The master receives an ASDU that requires authentication even though the Session Keys are not yet valid.

The master receives an ASDU that does not require authentication and was spontaneously transmitted by the outstation.

Key Change Timeout

Rx Challenge message

Rx Critical ASDU

Rx Unsolicited NonCritical ASDU

Event description

A

Event

232

Wait for Key Status

Wait for Key Status

Wait for Key Status

Wait for Key Status

D

Next state


Process the ASDU and issue a Confirm if required.

Increment Unexpected Messages statistic. Increment Authentication Failures statistic. Discard the Critical ASDU. Increment Discarded Messages statistic.

Increment Unexpected Messages statistic. Increment Authentication Failures statistic. Discard the Challenge message. Increment Discarded Messages statistic.

IF the timer is for the same user, discard. IF the timer is for a different user, queue the event and process it when next in Security Idle state.

C

Action


Wait for Key Status



Increment Unexpected Messages statistic. Increment Authentication Failures statistic. Discard the Critical ASDU. Increment Discarded Messages statistic.

Increment Unexpected Messages statistic. Increment Authentication Failures statistic. Discard the Challenge message. Increment Discarded Messages statistic.

IF the timer is for the same user, discard. IF the timer is for a different user, queue the event and process it when next in Security Idle state.

E

Action





F

Next state


State


9

8

7

6


B

The master receives a non-critical, nonauthentication ASDU in response to its previous authentication message, or receives some other indication that the outstation may not be capable of processing authentication messages.

A user wishes to transmit from this master. May be either a critical or non-critical ASDU.

The master receives a Key Status message for a user other than the one which is currently in Wait for Key Status or Wait for Key Change Confirmation state. This event should not occur because the outstation should be responding to a request for THIS user.

Rx Inappropriate NonCritical ASDU

A User Wants to Transmit an ASDU

Rx Unexpected Key Status

Event description

A

Event

233

Wait for Key Status

Wait for Key Status

Security Idle

D

Next state


Increment Unexpected Messages statistic. Discard the Key Status message. Increment Discarded Messages statistic.

Queue the ASDU until the next time the master enters Security Idle state.

Increment Unexpected Messages statistic. Increment Failed Session Key Changes statistic. Process the ASDU and issue a Confirm if required. Start the Key Change Timer and reset the Key Change Counter.

C

Action


Wait for Key Status


Increment Unexpected Messages statistic. IF the Key Status message was not authentic: Increment Authentication Failures statistic. Discard the Key Status message. Increment Discarded Messages statistic.


Increment Unexpected Messages statistic. Increment Failed Session Key Changes statistic. Process the ASDU and issue a Confirm if required. Start the Key Change Timer and reset the Key Change Counter.

E

Action

Wait for Key Status


Security Idle

F

Next state


State


12

11

10


B

Receives a Key Status = OK, but the message is not authentic.

Receives a Key Status = OK, but the Master has just restarted, so the session keys are not yet valid and the Master cannot authenticate the message.

As a result any of the other events, the Max Authentication Failures for this user was exceeded. The master has unsuccessfully tried several times to reset the Session Keys for this user. Must give another user a chance to initialize keys.

Rx Invalid Key Status

Rx Initial Key Status

Max Authentication Failures

Event description

A

Event

Security Idle


Wait for Key Status

D

Next state


234

Start the Key Change Timer. Reset the Key Change Counter. Increment Failed Session Key Changes statistic.


Increment Authentication Failures statistic. Discard the Key Status message. Increment Discarded Messages statistic.

C

Action


Wait for Key Status


Start the Key Change Timer. Reset the Key Change Counter. Increment Failed Session Key Changes statistic.

As in Rx Unexpected Key Status, above.

As in Rx Unexpected Key Status, above.

E

Action

Security Idle

Wait for Key Status

Wait for Key Status

F

Next state


State


15

14

13


B

None

g120v12

Rx Null Response (with no IINs set)

Rx Update Key Change Reply

Event description

A

Event

235

Restart the Reply Timer. Reset Max Reply Timeouts.

Transmit Signed Update Key Change (g120v13) and either Update Key Change Signature (g120v14) or Update Key Change Confirmation (g120v15). OR Transmit only an Update Key Change Confirmation (g120v15).

Log the event. Increment the Unexpected Messages statistic.

E

Action



Security Idle

IF the User Status Change need not be applied immediately, take no further action.

Discard the Reply. Increment the Unexpected Messages statistic. Increment the Discarded Messages statistic.


D

Next state

IF the User Status Change must be applied immediately: Transmit Update Key Change Request (g120v11). Restart the Reply Timer. Reset Max Reply Timeouts.

Action

Wait for Update Key Confirmation


F

Next state

The master is waiting for the outstation to reply to an Update Key Change request.

The master is waiting for the outstation to send a response to a User Status Change request.

C



State

Table 7-14—Master state machine—Changing Update Keys


Restart the Reply Timer. Increment Reply Timeouts Statistic.

Transmit Signed Update Key Change (g120v13) and either Update Key Change Signature (g120v14) or Update Key Change Confirmation (g120v15). OR Transmit only an Update Key Change Confirmation (g120v15).

Log the event. Increment the Unexpected Messages statistic.

G

Action



H

Next state

2

1

The master is waiting for the outstation to send an Update Key Confirmation response.



B

g120v15

g120v15

Rx Valid Update Key Change Confirmation

Rx Invalid Update Key Change Confirmation

Event description

A

Event

Discard the Confirmation. Increment the Unexpected Messages statistic. Increment the Discarded Messages statistic.


C

236



E

Action




D

Next state



F

Next state


The master is waiting for the outstation to send a response to a User Status Change request. Action



State Wait for Update Key Confirmation

IF Error Messages Sent <= Max Error Messages Sent: Transmit Error (g120v7). Increment Error Messages Sent. Log the event.

Discard the Confirmation. Increment the Discarded Messages statistic. Increment the Authentication Failed statistic. Increment the Failed Update Key Changes statistic. Cancel the Reply Timer.

Increment the Successful Authentications statistic. Increment the Update Key Changes statistic IF the key was changed. Cancel the Reply Timer. Begin using the new Update Key for subsequent authentications.

G

Action

Security Idle

Security Idle

H

Next state

4

3




B

None

None

None

g120v7

Varies

Varies

Reply Timeout

MaxReply Timeouts Exceeded

Rx Error Internal Indication

Rx Error

Rx Critical ASDU

A User Wants to Transmit an ASDU

Event description

A

Event



Increment Failed Update Key Changes statistic. Log the event. Cancel the Reply Timer.


Increment Failed Update Key Changes statistic.

Transmit User Status Change (g120v10). Restart the Reply Timer. Increment Reply Timeouts statistic.

C

237




Increment Unexpected Messages statistic. Log the event.


Transmit Update Key Change Request (g120v11). Restart the Reply Timer. Increment Reply Timeouts statistic.

E

Action




Security Idle

Security Idle

Security Idle


D

Next state



Security Idle


Security Idle


F

Next state









Increment Unexpected Messages statistic. Log the event.


Restart the Reply Timer. Increment Reply Timeouts statistic.

Transmit Update Key Change (g120v13) and either Update Key Change Signature (g120v14) or Update Key Change Confirmation (g120v15). OR Transmit only an Update Key Change Confirmation (g120v15).

G

Action



Security Idle


Security Idle


H

Next state

10

9

8

7

6

5




B

Varies

Varies

Rx Unsolicited Non-Critical ASDU

Rx Inappropriate Non-Critical ASDU

Event description

A

Event

Log the event.

Increment Unexpected Messages statistic. Increment Discarded Messages statistic. Discard the non-critical ASDU.


C

238

Increment Unexpected Messages statistic. Increment Discarded Messages statistic. Discard the non-critical ASDU. Log the event.


E

Action




D

Next state



F

Next state






Increment Unexpected Messages statistic. Increment Discarded Messages statistic. Discard the non-critical ASDU. Log the event.


G

Action



H

Next state

12

11




7.5.5 7.5.5.1

Outstation n procedures s Outstatio on role

In add dition to acting as a Challengeer and a Respo onder, each outtstation shall foollow the proceedures describeed in thiss subclause, peermitting the Master M to initialize and channge Session K Keys and to chhange the statuus, Role, Expiry E Intervaal, and Update Keys K of users. 7.5.5.2

Key stattus

The ou utstation shall maintain an in nternal variablee having the poossible values of Key Status described in thhe definittion of the Au uthentication Key K Status objeect, and returnn this value inn response to eeach Key Statuus Requeest Message. The ou utstation shall set the Key Staatus to <1> NO OT_INIT upon startup of the outstation. If the number of Key y Status Requeests received by b the outstatioon exceeds a coonfigured threshold within thhe hall notify a hum man as describbed in 7.6.1.4.66. Expeccted Session Keey Timeout, the outstation sh The ou utstation shall calculate pseudo-random Ch hallenge Data aaccording to FIIPS 186-2 and include it in thhe Key Status message.. 7.5.5.3

Authenticating session key chan nges

Wrap Data in the Key Changge Upon receiving a Keey Change messsage, the outsttation shall unw wrap the Key W urrent Update Key. K messaage using the cu If the Key Status infformation in the Key Wrap Data D matches thhe last Key Staatus informationn transmitted bby utstation, the ou utstation shall consider c the Keey Change messsage authenticc and valid. the ou If any of the unwrap pped Key Statu us information does d not matchh the last Key Status informaation transmitteed by thee outstation, thee outstation shaall consider thee Key Change m message invaliid. 7.5.5.4

Changin ng session ke eys

The outstation shall respond to a Key Change message m withinn an acceptablle Reply Timeeout defined per m as described in 7.6.1.4.1. system The ou utstation shall be configured d with a timer such that it shhall invalidate a set of Sessioon Keys if it haas not recceived a Key Change C messag ge within that in nterval as desccribed in 7.6.1.4.5 7.5.5.5

Changin ng user statu us

Upon receiving a Usser Status Chan nge (g120v10) object or a Usser Certificate ((g120v8) objecct, the outstatioon v the Ceertification Datta (including User U Name, Roole, Expiry Intterval and new w Update Key oor shall validate publicc key for the usser) in that objeect as follows: ⎯ Verify that the outstation supports the sp pecified Updatee Key Change Method (see 77.6.1.4.9). ⎯ Verify that the Certificatiion Data was created by thee authority, usiing the authorrity’s credentiaals a the outstation: that were prre-configured at 1) If the Update U Key Ch hange Method is symmetric,, validate the M MAC of the Ceertification Daata using the t symmetricc key shared between b the ooutstation and the authorityy (the Authority Certificcation Key). 2) If the Update U Key Change C Method d is asymmetrric, validate thhe authority’s ddigital signatuure againstt the Authority Public Key.




⎯ Verify that the Status Change Sequence Number is larger than any previously received for this user. ⎯ If a User Certificate was supplied, verify the Area of Responsibility text string in the certificate matches at least one such string preconfigured for this outstation. If the User Status Change or User Certificate is invalid (and the Maximum Error Count has not been exceeded), the outstation shall transmit an Error message (g120v7) with the error <8> Update Key Change Method Not Permitted, or <9> Invalid Signature, or <10> Invalid Certification Data. If the User Status Change is valid, the outstation shall store the Certification Data for later use. If the authority deletes a user, the outstation shall invalidate all keys associated with that user immediately. If the authority adds a user or changes the Role or Expiry Interval of a user, the outstation shall not apply the changes until the Update Key has been successfully changed, including mutual authentication of the master and outstation. When the Update Key has been successfully changed, the outstation shall calculate the new Expiry Interval of the User Role based on the last User Status Change object it received. The Expiry Interval shall be the specified number of days from the reception of the User Status Change object, to the nearest second. The outstation shall ensure that the Expiry Interval is correct relative to the reception of the User Status Change regardless of what time is set at the outstation or how many times it is changed. NOTE—If the authority changes the Role or Expiry Interval of a user, the authority shall also change the Update Key of that user.

7.5.5.6

Changing update keys

Upon receiving a Key Change Request (g120v11) object, the outstation shall verify that the specified User Name was previously validated and stored at the outstation, and the Expiry Interval of the User has not been exceeded. If the User Name is non-existent or expired, the outstation shall respond with an Authentication Error (g120v7) object having the reason <11> Unknown User. If the User Name is valid, the outstation shall respond with an Update Key Change Reply (g120v12) object containing a new Key Change Sequence Number, a User Number to be used to identify the user, and random Challenge Data calculated according to FIPS 186-2. The next step of the Update Key change process, the reception and authentication of the Update Key Change, shall differ depending on the method used: ⎯ If the Update Key Change Method used by the outstation is symmetric, upon receiving an Update Key Change (g120v13) object from the master, the outstation shall validate the accompanying Update Key Change Confirmation (g120v15). If the Message Authentication Code is valid, the outstation shall begin using the new Update Key for session key changes. ⎯ If the Update Key Change Method used by the outstation is asymmetric, upon receiving a Update Key Change (g120v13) object from the master, the outstation shall validate the digital signature of the user with the User Public Key previously certified by the authority. If the signature is correct, the outstation shall begin using the new Update Key for session key changes. ⎯ Using either method, upon receiving an Update Key Change Confirmation (g120v15) without an Update Key Change (g120v13) object, the outstation shall validate the Update Key Change Confirmation object. If the Message Authentication Code is valid, the outstation may proceed with the next step.




If the Update Key Change or th he Update Key y Change Connfirmation waas correctly auuthenticated, thhe d a response con ntaining an Up pdate Key Channge Confirmattion (g120v15) object. If it waas outstattion shall send not co orrectly authen nticated and thee Max Error Messages M Sent has not been exceeded, the outstation shaall respon nd with an Erro or (g120v7) objject with error code <1> Autthentication Faailed. 7.5.5.7

Enforcin ng user roles s

An ou utstation shall enforce the user u Roles assigned by the authority as ddescribed in T Table 7-12. Thhe outstattion shall not permit p users to o perform actio ons they do noot have permisssion to perform m, as designateed by theeir Role, regardless of wheth her the user is authentic. Thhe outstation shhall reject suchh non-permitteed action ns by sending an n Error (g120v v7) object with h the value <5> > Authorizationn Failed. If the authority deleetes a user or if i the Role of the t user expirees, an outstatioon shall invaliidate the Updaate nd any active Session S Keys or o Public Keys associated witth the user. The outstation shhall not make thhe Key an expiry y of the Updatee Key dependen nt on the time and date at thee outstation. Thhis standard asssumes there iss a reliablle interval timeer available at the t outstation that t is separatee from the timee and date. Ideaally, this intervval timer would w continu ue even while the t device was powered dow wn, but this is nnot required. U Upon startup, thhe outstattion shall assu ume that only the t default Upd date Key is vaalid until there is a trusted tim me source at thhe outstattion (either thrrough the proto ocol or some otther source) wiith which to vaalidate the Expiiry Interval.

7.6

Interope erability requirements

This su ubclause descrribes which cap pabilities shall be consideredd to fall into thee following cattegories: ⎯ Mandatory to ensure interroperability bettween devices ⎯ Optional bu ut required to be b tested if imp plemented ⎯ Recommended practices 7.6.1

Minimum requirementts

This subclause s desccribes the mandatory minimu um capabilitiess required for a device to coomply with thhis standaard. 7.6.1.1

MAC alg gorithms

Each device d shall im mplement the MAC M algorithm ms listed in this subclause. 7.6.1.1.1

HMA AC-SHA-1

Each device d shall peermit the use of HMAC-SHA A-1, as describeed in IETF RF FC 2104, IETF F RFC 3174, annd FIPS 186-2 to calcu ulate the MAC Value. The MAC M Value shhall be the 1600 bits (20 octetts) output of thhe C algorithm, trruncated to eith her the leftmosst 8 octets or thhe leftmost 10 octets. If this standard is useed HMAC over TCP/IP, T the truncated value sh hall be 10 octeets. If it is usedd over serial linnks, the truncatted value can bbe 8 octets. However, th he longest pracctical MAC sho ould be used w whenever possibble. This iss a mandatory MAC algorith hm intended forr use by devicees with limitedd processing poower that cannnot otherw wise implemen nt DNP3 Seccure Authentication with aacceptable peerformance. A All masters annd outstattions shall im mplement this algorithm forr compatibilityy with such llimited perforrmance devicees. Howev ver, this is nott the preferred MAC algorith hm. All device s shall providee a means to eenable or disabble the usee of HMAC-SH HA-1 by configuration. 7.6.1.1.2

HMA AC-SHA-256

Each device d shall peermit the use of o HMAC-SHA A-256, as desccribed in FIPS S 180-2, to calcculate the MA AC Value. The MAC Vaalue shall be th he 256 bits (32 octets) outputt of the HMAC C algorithm, truuncated to either ost 16 octets. When W this authhentication mechanism is useed over TCP/IP P, the lefftmost 8 octetss or the leftmo 241 Copyright © 2012 IEEE. All rightts reserved.



the truncated value shall be 16 octets. On serial implementations, it can be 8 octets. However, the longest practical MAC should be used whenever possible. This shall be the default MAC algorithm. 7.6.1.2

Key wrap / transport algorithms

Each device shall implement key wrap algorithms or key transport schemes as described in this subclause. 7.6.1.2.1

AES-128 key wrap

Each device shall permit the use of the Advanced Encryption Standard Key Wrap mechanism, as described in IETF RFC 3394, to encrypt and decrypt Session Keys or Update Keys. The Key Encryption Key (KEK) referred to in the Key Wrap specification shall be the Update Key. The default initialization vector shall be used. 7.6.1.3

Fixed values

Each device shall fix the following parameters to comply with this standard: 7.6.1.3.1

Minimum session key size

The minimum size of the Session Keys used to calculate the MAC Value shall be 128 bits. 7.6.1.3.2

Minimum update key size

The minimum size of the Update Key used to encrypt and decrypt Session Keys shall be 128 bits. 7.6.1.4

Configurable values

Each device shall permit changes to the parameters described in this subclause. Changes to these parameters shall be permanently retained over restarts of the device. 7.6.1.4.1

Reply timeout

The reply timeout used by devices to detect communication failures shall be settable in hundreds of milliseconds. The default value shall be 2 seconds. The maximum value shall be no less than 120 seconds. 7.6.1.4.2

Security statistic event thresholds

Each device shall permit an event threshold to be configured for each of the security statistics listed in Table 7-6 in 7.5.2.2. If the statistic has incremented by the amount of the threshold since either startup or the last time the statistic was reported as an event object (g122), the device shall generate an event object for that statistic. The maximum value of each threshold shall be 65 535. The default value of each threshold is listed in Table 7-6. Note that when some of these thresholds are reached, the event shall cause the outstation to take specific actions—other than just reporting the change—as described in 7.5.2.2 and the state tables. The value of the statistic at which the threshold will next be reached is referred to by a particular name in the state tables. This maximum value is reset to its current value plus the configured value of the threshold each time the event occurs. These special statistics and the name of the corresponding maximum values are given in Table 7-15.




Table 7-15—Special statistic event thresholds Statistic

7.6.1.4.3

Name of maximum value (at which the statistic will next reach the threshold)

Authentication Failures

Max Authentication Failures

Reply Timeouts

Max Reply Timeouts

Rekeys Due to Authentication Failure

Max Authentication Rekeys

Error Messages Sent

Max Error Messages Sent

Rekeys Due to Restarts

Max Rekeys Due to Restarts

Session Key change interval

The session key change timeout used by the master to determine when to change Session Keys shall be settable in seconds up to 2 hours. The default value shall be 15 minutes. To accommodate systems which communicate infrequently (for instance every few hours or days), it shall be possible to disable the Session Key change interval and use only the Session Key change count. Alternatively, the device may permit Session Key change intervals measured up to 1 week in length. IMPORTANT: a)

Implementers should not increase the Session Key change interval beyond 30 minutes unless they also increase the size of the MAC Value. FIPS 198 requires MAC output to be truncated to no less than half its standard size, “unless an application or protocol makes numerous trials impractical”. In the case of this authentication mechanism, the requirement for frequent changes of Session Keys fulfills this criterion and makes it possible to use shorter MAC Values.

b) An attacker could try to change Session Keys extremely frequently in order to deny service to legitimate users. It is recommended that outstations implement a “watchdog” function over the Update Key Change and Failed Update Key Change statistics to prevent excessive Session Key changes. The details of such a mechanism are not discussed here. c)

An attacker could try to force a master to change Session Keys frequently by repeatedly sending Key Status objects with Status <> OK. As described in Table 7-13, the master shall not send Session Key Change messages any faster based on the Key Status it receives.

d) A master may optionally decrease the Session Key change interval if authentication failures are occurring, in case the failures are due to an incorrectly configured Expected Session Key change interval at the outstation. It may do so only once. e)

If the AES-GMAC algorithm is used, the Session Keys and Update Keys shall be changed frequently enough that AES-GMAC is used no more than 221 times with the same key.

7.6.1.4.4

Session Key change count

The master shall also change Session Keys whenever a configured number of authentication ASDUs has been transmitted in either direction since the last key change. The value shall be settable from one in increments of one. The default value shall be 1000. The maximum value shall be no less than 10 000 and no more than half the maximum value of the Key Change Sequence Number (KSQ). 7.6.1.4.5

Expected Session Key change interval and message count

The outstation shall maintain a timer and a count between successive Key Change messages in the same manner as the master. The outstation shall invalidate the current set of Session Keys if they have not been changed within the configured interval. This rule will cause the Session Keys to become invalid whenever 243 Copyright © 2012 IEEE. All rights reserved.



either the master or the outstation times out, whichever happens sooner. To avoid excessive message exchanges, it is recommended that the outstation interval and count be configured for twice the interval and count configured at the master. 7.6.1.4.6

Maximum Session Key status count

If the number of Session Key Status Requests received by the outstation exceeds this value within the Expected Session Key Change Interval, the outstation shall alert a human. If a different DNP3 association is in use, the outstation shall send an Error (g120v7) event object on that association with the code <12> Max Session Key Status Requests Exceeded. This value shall be configurable up to a maximum of 255 or down to 2. The default value shall be 5. This default means five session key changes were attempted within the time that one was expected. This count shall be kept per user of the outstation. 7.6.1.4.7

Use of Aggressive Mode

Aggressive Mode is considered optional by IEC/TS 62351-5. However, it is not optional for DNP3. All DNP3 implementations claiming conformance to this standard shall implement it. They shall also permit it to be configured as disabled. If an outstation requests Aggressive Mode authentication of a Confirm (0x00) message as described in 7.5.2.3.2, the master shall do so regardless of whether Aggressive Mode is disabled. 7.6.1.4.8

Disabling authentication

Each device that supports this authentication mechanism shall permit this mechanism to be completely disabled by configuration on a per-association basis. It shall not be possible to change this configuration parameter remotely. The authentication mechanism shall be enabled by default. 7.6.1.4.9

Update Key Change Method

The method used for changing Update Keys shall be pre-configured at the master and specified to the outstation when the authority changes the status of a user. Each key change method specifies a particular set of cryptographic algorithms and DNP3 objects that shall be used. Only one method shall be active between a particular master and outstation. Table 7-16 lists the possible values of the Key Change Method. Numbers less than 64 represent the use of symmetric keys and algorithms, while numbers 64 through 127 represent the use of mostly asymmetric (public) keys and algorithms. Devices are permitted to not implement remote changing of Update Keys, user status, and Roles. If the master or outstation does not implement this feature and an Update Key is compromised, the Update Key must be changed via a mechanism outside the protocol. All devices that permit remote changing of Update Keys shall also implement Key Change Method <4>, the symmetric method employing AES-256 Key Wrap for encrypting keys and HMAC-SHA-256 for authentication. This method shall be the default. All other Update Key Change Methods shall be optional. If a device implements Key Change Method <67>, the asymmetric method using HMAC-SHA-1, it shall permit this method to be disabled by configuration. If asymmetric RSA algorithms are used for key transport, then the RSAES-OAEP algorithm shall be used for key transport as described in 7.6.2.2.2.




Table 7-16—Algorithms and objects used for each Update Key Change Method Key Change Method

Key transport

Algorithm

Authentication and integrity of user credentials

Objects

<0>

Not used

<1>

Obsolete. Do not use.

Algorithm

Objects

Authentication of master to outstation and outstation to master Algorithm

Object

Update Key Length (bits)

<2>


<3>

AES-128 Key Wrap

g120v13

SHA-1-HMAC

g120v10

SHA-1HMAC

g120v15

128

<4>

AES-256 Key Wrap

g120v13

SHA-256HMAC

g120v10

SHA-256HMAC

g120v15

256

<5>

AES-256 Key Wrap

g120v13

AES-GMAC

g120v10

AES-GMAC

g120v15

256

<3..63>

Reserved for future symmetric methods.

<64>


<65>


<66>


<67>

RSAES-OAEP1024 / SHA-1

g120v13

DSA SHA-1 (L=1024 N=160)

g120v10, g120v14

SHA-1HMAC

g120v15

128

<68>


g120v13

DSA SHA-256 (L=2048 N=256)

g120v10, g120v14

SHA-256HMAC

g120v15

256

<69>


g120v13

DSA SHA-256 (L=3072 N=256)

g120v10, g120v14

SHA-256HMAC

g120v15

256

<70>


g120v13

DSA SHA-256 (L=2048 N=256)

g120v10, g120v14

AES-GMAC

g120v15

256

<71>


g120v13

DSA SHA-256 (L=3072 N=256)

g120v10, g120v14

AES-GMAC

g120v15

256

<72..127>

Reserved for future asymmetric methods.

<128..256>

Reserved for vendor-specific choices. Not guaranteed to be interoperable.

The pseudo-random Challenge Data chosen by the master and outstation for changing Update Keys shall be as shown in Table 7-17 calculated according to FIPS 186-2.




Table 7-17—Size of Challenge Data Authentication algorithm

7.6.1.4.10

Size of Challenge Data

SHA-1-HMAC

160 bits, 20 octets

SHA-256-HMAC or AES-GMAC

256 bits, 32 octets

Cryptographic information

Although this standard permits changing cryptographic keys remotely, each device must always have some information pre-configured. The type and number of keys and other cryptographic information that must be configured varies depending on the chosen Update Key Change Method, as shown in Table 7-18. Devices shall retain all the information listed in Table 7-18 and the correspondence between these pieces of information over restarts, except the Session Keys. They are reinitialized after each restart.




Table 7-18—Configuration of cryptographic information Update Key Change Method None Information

code

Update Key Change Method User Number

USR

Master

Outstn

Symmetric

Asymmetric

Auth

Master

Outstn

Auth

Master

Outstn

—

—

NOTE 5

NOTE 5

Rx

NOTE 5

NOTE 5

Rx

NOTE 4

Config

—

Rx

Derive

—

Rx

Derive


Derive

Rx

—

Derive

Rx

—

Derive

Rx


Derive

Rx

—

Derive

Rx

—

Derive

Rx

Update Key

K

Config

Config

Derive

Rx

Rx

NOTE 1

Derive

Rx

User Name

IDA

—

—

Config

Rx

Rx

Config

Rx

Rx

IDB

—

—

Config

Config

Config

Config

Config

Config

Authority Certification Keys

MC, BC

—

—

Config

Config

Config

—

—

—

Authority Private Key

C’

—

—

—

—

—

Derive

—

—

Authority Public Key

C

—

—

—

—

—

Derive

NOTE 2

Config

User Private Key

A’

—

—

—

—

—

NOTE 3

NOTE 3

—

User Public Key

A

—

—

—

—

—

NOTE 3

Rx

Rx

Outstation Private Key

B’

—

—

—

—

—

—

—

Derive

B

—

—

—

—

—

—

Config

Derive

Outstation Name

Outstation Public Key




NOTE 1—Using the assymmetric metho od, it is possiblee for the Update Key to be derivved by the masteer and not knownn a at all. This T is not possib ble using the sym mmetric method.. to the authority NOTE 2—It is not neccessary for the master m to know the t authority’s ppublic key for aany DNP3 transaaction. Howeverr, blic key for otheer reasons unrelaated to this standdard. the masster may need the authority’s pub NOTE 3—The master must know thee user’s private key in order too sign the Updaate Key for thee outstation. Thee he user’s public key k to certify it to the outstationn. One solution ffor achieving theese requirements authoritty must know th may be for the authoritty to derive both h keys and encod de them on a tokken for the user tto carry and inseert at the masterr. Another may be for th he master to derrive both keys and a securely proovide the user’ss public key to tthe authority for certificaation. There may y be other solutions. The solutio on chosen is out of the scope of tthis standard. Thhe master always receives the user’s publlic key in certificcation by the autthority, even if itt was originally derived by the m master. NOTE 4—If the Update Key is not to o be changed reemotely, the Uppdate Key and tthe correspondinng User Number (USR) must m be pre-con nfigured at the ou utstation. The Up pdate Key must also be pre-conffigured at the maaster. The masteer may alsso have the USR R pre-configured d, but this is nott strictly necessaary. The master can obtain the USR by sendingg the outsstation an Updatte Key Change Confirmation C witthout an Update Key Change as described in 7.55.4.6. NOTE 5—The Update Key Change Method M is configu ured at the mastter and sent to tthe outstation inn the User Status 10). The User Sttatus information n supplied by thhe authority withhin that object m must make use oof Changee object (g120v1 the con nfigured method. It is outside th he scope of thiss standard whethher the authorityy learns the corrrect Update Keyy Changee Method from th he master or vicee versa.

Table e 7-19—Lege end for config guration of c cryptographiic informatio on Cell C text

7.6.1.5

Meaniing

Cod de

Notation for the in nformation, founnd in 7.10.2

Auth

Au uthority

Outstn

Ou utstation

Derrive

Th his device derivees (creates) the in information

Rx

Th his device receiv ves the informatiion via data com mmunications

Con nfig

Th his device must have h this inform mation pre-configgured

-

Th his device does not n use the inforrmation

Protocol versions

The development d off DNP3 Securre Authentication has requirred non-backw ward-compatiblle changes. Thhe version of Secure Authentication described d in IE EEE Std 1815™ ™-2010 has beeen deprecatedd and should not be useed in new impleementations. 7.6.2

Options

This subclause s describes capabilitties that are no ot required forr compliance w with this standaard, but may bbe implem mented as optiions. If a devicce implements these capabilitties, they shall be verified foor compliance. If a deviice implementss any capabilitiies not listed in n this subclausse, the device m must provide a mode in whicch these capabilities c aree disabled. 7.6.2.1 7.6.2.1.1

MAC alg gorithms AES--GMAC

Each device d may op ptionally permiit the use of th he AES-GMA AC algorithm, aas described inn NIST SP 800038D, for f authenticatiing data. If imp plemented, AE ES-GMAC shalll be used in thhe following maanner: ⎯ No data shaall be encrypted d; i.e., this algo orithm is AES--GMAC, not A AES-GCM. 248 Copyright © 2012 IEEE. All rightts reserved.



⎯ The length of the output, known as the tag length, shall be 96 bits (12 octets). ⎯ The length of the Initialization Vector (IV) shall also be 96 bits. ⎯ The IV for each invocation of AES-GMAC shall be constructed as shown in Table 7-20, with the rightmost or most significant octets listed first in normal DNP3 fashion. ⎯ The components (KSQ, SCS, CSQ) used to construct each IV shall come from the sources listed in Table 7-21, depending on the DNP3 object variation that contains the MAC. Table 7-21 also names which key is used to calculate the MAC in each object variation. Table 7-20—Construction of AES-GMAC Initialization Vector Field Fixed

Invocation

Bits

Description

8

Least significant octet of sender’s DNP3 address

8

Most significant octet of sender’s DNP3 address

16

User Number (USR) associated with the data being authenticated

32

Key Change Sequence Number (KSQ) or Status Change Sequence Number (SCS)

32

Challenge Sequence Number (CSQ) or zero

Table 7-21—Source of Initialization Vector components in each DNP3 object g120 Variation

Authentication object name

Initialization Vector KSQ / SCS

CSQ

Key used to calculate MAC

2

Reply

Last KSQ sent by outstation

CSQ in this object.

Session Key

5

Session Key Status

KSQ in this object

Last CSQ exchanged between master and outstation, whether it was sent by the master in g120v3 or by the outstation in g120v1. Zero if neither exchange has happened yet.

Session Key (Note that if the Session Key is not valid, there is no MAC calculated.)

9

Message Authentication Code


CSQ in this same message (g120v3).

Session Key

10

User Status Change

SCS in this object

Zero.

Authority Certification Key

15



Last CSQ exchanged between master and outstation, whether sent by master in g120v3 or by outstation in g120v1. Zero if neither exchange has happened yet.

Update Key

Note that while AES-GMAC offers enhanced efficiency in a MAC algorithm, it places some additional requirements on the implementation, particularly on the uniqueness of the Initialization Vector (IV). NIST SP 800-38D states that: The probability that the authenticated encryption function ever will be invoked with the same IV and the same key on two (or more) distinct sets of input data shall be no greater than 2-32. Compliance with this requirement is crucial to the security of GCM. Across all instances of the authenticated encryption [AES-GMAC] function with a given key, if even 249 Copyright © 2012 IEEE. All rights reserved.



one IV is ever repeated, then the implementation may be vulnerable to the forgery attacks that are described in Ref [5] and summarized in Appendix A. In practice, this requirement is almost as important as the secrecy of the key. Table 7-20 describes what NIST SP 800-38D defines as a “deterministic construction” of the IV. That specification also clarifies the previous statement by saying: For any given key, no two distinct devices shall share the same fixed field, and no two distinct sets of inputs [i.e. two messages] to any single device shall share the same invocation field. This strict requirement means that DNP3 Secure Authentication implementations that use AES-GMAC must implement the following rules in addition to those described elsewhere in this standard: a)

The most recently transmitted value of the Key Change Sequence Number (KSQ) shall be retained by both the master and the outstation over restarts.

b) The outstation shall not follow the usual rule, found in the object definition of (g120v5), that it must initialize the KSQ to zero after a restart. Instead, after a restart, it shall increment the KSQ that was retained over the restart to create its first KSQ for transmission. c)

The master and the authority shall change the Update Key often enough that it occurs before the KSQ wraps around.

d) The DNP3 Address of each device shall be unique across the network administered by the key distribution authority. This is a difficult requirement for some implementations, but it is vital if using the AES-GMAC algorithm. If this requirement cannot be met, then all keys (including Session Keys) used for calculating MACs must be unique across the network, a requirement that may be even more difficult to meet. e)

The Session Keys and Update Keys shall be changed frequently enough that AES-GMAC is used no more than 221 times with the same key.

7.6.2.1.2

Other MAC algorithms

Each device may implement additional MAC algorithms in addition to those listed as mandatory. If the device receives an Error message with the Error Code <5> MAC algorithm Not Permitted, it shall change to use a mandatory MAC algorithm in its next Challenge. A device may be configured to reject particular mandatory MAC algorithms, but it must also support configuration to support all the mandatory MAC algorithms. 7.6.2.2 7.6.2.2.1

Key wrap / transport algorithms AES-256 key wrap

Each device may optionally permit the use of the Advanced Encryption Standard Key Wrap mechanism, as described in IETF RFC 3394, to encrypt and decrypt Session Keys or Update Keys. If implemented, the Key Encryption Key (KEK) referred to in the Key Wrap specification shall be the Update Key, which shall be 256 bits long. The default initialization vector shall be used. 7.6.2.2.2

RSAES-OAEP

If the device implements an asymmetric Update Key Change Method using RSA algorithms as described in 7.6.1.4.9, it shall use the RSA Encryption Scheme with Optimal Asymmetric Encryption Padding (RSAESOAEP) as described in IETF RFC 3447. The hash function used shall be either SHA-1 or SHA-256 as listed in 7.6.1.4.9. The Mask Generation Function shall be MGF1 as described in IETF RFC 3447.




7.6.2.2.3

Othe er key wrap algorithms a

Each device d may im mplement additiional Key Wraap algorithms inn addition to thhose listed as m mandatory. If aan outstattion receives an a Error messag ge with the Errror Code <6> E Encryption Alggorithm Not Peermitted, it shaall change to use a mand datory Encrypttion Algorithm m in its next Keey Status Messaage. A dev vice may be configured to rejject particular mandatory enccryption algoriithms, but it m must also suppoort config guration to supp port all the man ndatory encryp ption algorithm ms.

7.7

Special applications a s

This su ubclause defin nes how this staandard shall bee applied in a feew specific situuations. 7.7.1

Use with the t internet protocol p suitte

DNP3 implementatiions over TC CP/IP requiring g confidentialiity shall use both this Appplication Layyer T Layeer Security (TL LS) internet staandard as descrribed in 7.8. mechaanism and the Transport DNP3 implementatio ons over UDP/IP shall use th his Applicationn Layer authenntication mechhanism by itsellf. ons may choosee to use other security s measuures (such as IP PSec) along wiith this standarrd, Some implementatio but theey are out of th he scope of thiss standard. Figure 7-30 illustraates the stand dard protocol profiles p that aare permitted using Secure Authentication. mentations thatt support the C Confidential T TCP profile shaall Shaded areas indicatte security measures. Implem upport the Auth henticated TCP P profile. also su

Figure 7-30—Valid 7 profiles p using g the Secure e Authenticattion mechan nism When operating oveer IP, it may bee possible to change and disttribute Updatee Keys by makking use of other G intends to develop sppecifications fo for this purposse. IP-bassed security prrotocols. The DNP Users Group Howev ver, such mech hanisms are alsso outside the scope s of this sttandard as of thhe date of its puublication. 251 Copyright © 2012 IEEE. All rightts reserved.



NOTE— —When operating over TCP, iff the maximum number n of authenntication failure s is exceeded, thhe implementatioon shall drop d the TCP co onnection as specified in Table 7-8, in order too permit other cconnections to bbe made. It is also recomm mended that the event be logged d and the Address Resolution Prootocol (ARP) cacche be cleared iff possible.

7.7.2

Use with redundant r ch hannels

When used with red dundant chann nels the commu unications shaall not be conssidered to havee failed and thhe on Keys invalid dated until all channels c have been b tried. Sessio 7.7.3

Use with external e link encryptors

mechanism may This authentication a m be used along a with extternal link enccryptors to proovide protectioon againsst the threat of eavesdropping g. It is reecommended for fo simplicity th hat a common set of keys be used for both authentication and encryption. Howev ver, the definittion of such rulles is out of sco ope of this stanndard. 7.7.4

Use with data d concenttrators

This subclause s desccribes special requirements when the autthentication m mechanism is used by a daata concen ntrator. 7.7.4.1

Definitio on of a data concentrator c r

Figure 7-31 illustrates an example of a typical system makinng use of a DN NP3 data concentrator. A daata ntrator does no ot pass DNP3 messages m throu ugh itself intacct, as a router oor bridge doess. Instead, a daata concen concen ntrator terminaates multiple connections c off DNP3 or othher protocols aand stores the data from eacch directiion in an intern nal run-time daatabase. This permits p the conncentrator to fiilter the data, pprocess it within internaal software app plications, or convert it into other o protocols . Data may m pass throu ugh a data con ncentrator eith her “upstream””, toward DNP P3 masters, orr “downstream m”, toward d DNP3 outstaations, also kno own as Intellig gent Electronicc Devices (IED Ds). DNP3 poiint numbers annd DNP3 addresses useed on any given connection may m be the sam me or differentt than those ussed on any other umbers used onn one connectiion to the corrresponding point connection. The dataa concentrator maps point nu t the run n-time databasee. numbeers on the otherr connections through




Figure 7-31—Example of user number assignments in a data concentrator 7.7.4.2

Authentication procedures for data concentrators

When a data concentrator makes use of DNP3 secure authentication, it shall follow the general rule that whenever it can distinguish the particular user who initiated an operation, it shall identify that user to downstream outstations. This rule is intended to deter repudiation by permitting concentrators or outstations to log which user initiated critical DNP3 operations. The following rules shall apply as clarifications of that rule: a)

The data concentrator shall identify each user having a DNP3 User Number (USR) on the upstream side with a separate DNP3 User Number on the downstream side. For instance, in Figure 7-31, Alice and Bob have User Numbers on both the upstream DNP3 link used by process “A” and the downstream DNP3 links used by process “C”. 253 Copyright © 2012 IEEE. All rights reserved.



b)) If an upstreeam protocol cannot c distingu uish individuaal users, the daata concentratoor shall identif ify each upstreeam protocol connection c witth a separate User Number on the downsstream side. Foor instance, prrocess “B” can nnot distinguissh whether prootocol commannds are initiateed by Charlie oor Donald. Therefore the datta concentratorr uses a single U User Number oon the downstrream DNP3 linnk used by pro ocess “C” to rep present all userrs on Master 2.. c))

The data co oncentrator sha all identify loccal users and aapplications wiith separate U User Numbers oon the downsttream side. Fo or instance, lo ocal applicatioon “E” has itts own User N Number on thhe downstream m DNP3 link k. If the dataa concentratorr had a locaal user interfa face capable oof distinguishiing different lo ocal users, it wo ould identify eeach of these loocal users with a different User Number on the downstreaam DNP3 link.

d)) User Numb bers shall be unique within a DNP3 assoociation. Refeer to 7.5.4.4 ffor more detaiils regarding th his rule. User Numbers N need d not be sequenntial, but the ccombination off Association IID and User Number N must uniquely u identiffy a user withiin a device, annd a unique Uppdate Key andd a set of Sessio on Keys shall be b associated with w that user. e))

The User Number N used to o identify a useer on any givenn association m may be differennt than that useed on any otheer association. For instance, Alice’s User N Number on thee upstream DN NP3 link is 7, but her User Nu umber on the liink between th he data concenttrator and Outsstation 3 is 22. She may havee a different Usser Number on n the link with Outstation O 1.

f)

If no pointss are mapped between b an upsstream or locall user and a doownstream outs tstation, the data concentrato or need not ma ap User Numb bers either. Thhe Figure 7-331 illustrates thhat all the useers identified in n the diagram have the poteential to make use of Outstattion 3. Howevver, not all useers may have the t potential to o access Outsttation 1, for innstance, and thherefore Outstaation 1 may not have any User Numbers to o distinguish th hem.

g)) When upstrream or loca al users initiate critical DN NP3 requests that are passsed through to downstream m outstations, the t data concen ntrator shall coorrectly identiffy the user makking the requesst. If Alice iniitiates a binary y output operaation on a poinnt that is mappped to Outstaation 3, the daata concentrato or first authentiicates the requeest with Masterr 1 using Alicee’s upstream U User Number (77). Next, the daata concentrato or issues the co orresponding b inary output opperation to Ouutstation 3, and it uses Alice’s downstream User Numberr (22) when Ouutstation 3 reqquests the dataa concentrator to he local autom mation process iinitiates a Freeeze and Clear oon authenticatee that request. Similarly, if th several cou unters and Outtstation 3 con nsiders it a criitical operationn, the data cooncentrator shaall authenticatee the request with w Outstation 3 specifying U User Number 112. h)) When the data d concentra ator spontaneo ously or perioddically initiatees a critical DN NP3 request oon behalf of mu ultiple users, itt shall identify itself as the usser using the “ “default” User Number=1. Foor instance, prrocess “C” periiodically initiattes regular Claass Data polls tto gather data tthat will later bbe distributed to Alice, Bob and Charlie, even e though nnone of those uusers specificaally initiated thhe poll requesst. It is not mandatory m thaat Class Data polls be connsidered criticaal. However, if Outstation 3 chose to challlenge a Class Data poll from m the data conccentrator, the ddata concentratoor would autheenticate the poll identifying itself (User Num mber 1) as the initiating userr.

7.8

Complia ance with IE EC/TS 62351 1-3

DNP3 implementatiions that use Transport Layer Security (TLS) shall comply withh the followinng requirements taken from IEC/TS 62351-3. Itallicized text is a direct quottation from Eddition 1 of thhat fication. specifi 7.8.1

Deprecation of non-en ncrypting cip pher suites

Any cipher suite thatt specifies NUL LL for encrypttion shall not bbe used.




The lisst of deprecated suites includ des, but is not liimited to: ⎯ TLS_NULL L_WITH_NUL LL_NULL ⎯ TLS_RSA_ _NULL_WITH H_NULL_MD5 5 ⎯ TLS_RSA_ _NULL_WITH H_NULL_SHA A 7.8.2

Mandatory y cipher suitte

DNP3 implementatio ons that use TL LS shall supporrt the followingg cipher suite aat a minimum: ⎯ TLS_RSA_ _WITH_AES_128_SHA This iss the mandatorry cipher suite for f TLS versio on 1.2. 7.8.3

Recomme ended cipherr suites

It is recommended d that DNP3 implementatiions using T TLS support tthe followingg cipher suitees. mentations maay also choose to t implement cipher c suites noot listed here. Implem Table 7-22— —Recommen nded cipher suite combin nations Key exchange e Algorithm m

7.8.4

Encryyption

Hash

Signature

TLS_RSA_ _

WITH_RC4_1128_

SHA

TLS_RSA_ _

WITH_3DES__EDE_CBC_

SHA

TLS_DH_

DSS_

WITH_3DES__EDE_CBC_

SHA

TLS_DH_

RSA_

WITH_3DES__EDE_CBC_

SHA

TLS_DHE_

DSS_

WITH_3DES__EDE_CBC_

SHA

TLS_DHE_

RSA_

WITH_3DES__EDE_CBC_

SHA

TLS_DH_

DSS_

WITH_AES_1128_

SHA

TLS_DH_

DSS_

WITH_AES_2256_

SHA

TLS_DH_

WITH_AES_1128_

SHA

TLS_DH_

WITH_AES_2256_

SHA

Negotiatio on of version ns

Only TLS 1.0 correesponding to SSL S version 3.1 (or higher) shall be allow wable (see IETF RFC 52466). p to SSL 3..1 shall result in no connectioon being establlished. Proposal of version prior 7.8.5

Cipher ren negotiation

Implem mentations cla aiming conform mance to this standard shalll specify thatt the symmetriic keys shall bbe renego otiated based upon u a time perriod and a maxximum allowedd number of paackets/octets seent. It is a PIXI XIT issue, of the referenccing standard, to specify the constraints c on the renegotiatiion. The reenegotiation va alues shall be configurable. c DNP3 implementatio ons using TLS S shall renegottiate the TLS ssymmetric keyys when the Appplication Layyer on Key Changee Interval expirres or the Sessiion Key Changge Count is excceeded. It is reccommended thhat Sessio TLS reenegotiation taake place beforre the Applicatiion Layer key change.




The in nitiation of the change cipherr sequence sha all be the respoonsibility of thhe TCP entity tthat receives thhe TCP-O OPEN indicatio on (e.g.,the callled entity). A request r to channge the cipher, r, issued from tthe calling entiity (e.g.,th he node that issued the TCP-OPEN) shall be b ignored, There shall be a timeout associateed with the resp ponse to a chaange cipher reqquest. A timeouut of the changge onnection being g terminated. T The timeout vaalue shall be coonfigurable. cipherr request shall result in the co DNP3 implementatio ons using TLS shall use a chaange cipher reqquest timeout cconfigurable inn the same rangge meout described in 7.6.1.4.1. as the application seccurity reply tim 7.8.6

Message authenticatio a on code

The Message M Authen ntication Code shall be used. Note: TLS has this capability c speccified as an op ption. This stanndard mandatees the use of thhis capability to m ddle attacks. aid in countering and detection of man-in-the-mid 7.8.7

Certificate e support

DNP3 implementattions using Transport T Lay yer Security (TLS) shall comply with the followinng om IEC/TS 622351-3. requirements for certtificate manageement taken fro 7.8.7.1

Multiple certificate authorities a (C CAs)

An im mplementation, claiming con nformance to this standard,, shall supporrt more than one Certificaate Authorrity. DNP3 implementatio ons using TLS shall support at a least four Ceertificate Authoorities. The acctual number shall s be declareed in the impleementation’s D Device Profile. The crriteria and seleection of a CA is out-of-scopee of this standaard. 7.8.7.2

Certifica ate size

A prottocol, specifyin ng the use of th his standard, shall s specify thhe maximum siize of certificatte allowed to bbe used. It I is recommen nded that this size shall be lesss than or equaal to 8192 octetts. DNP3 implementatio ons using TLS shall support a minimum-maaximum certifiicate size of 81192 octets. It iss a i if larger certificates c are supported. local issue An im mplementation that receives a certificate laarger than the size that it caan support shaall terminate thhe connection. 7.8.7.3

Certifica ate exchange e

The certificate exch hange, and va alidation, shalll be bi-directiional. If eitheer entity does not provide iits certificcate, the conneection shall be terminated. 7.8.7.4

Certifica ate comparison

Certifi ficates shall bee validated by both b the callin ng and called nnodes. There aare two mechaanisms that shaall be con nfigurable for certificate c veriffication. ⎯ Acceptancee of any certificcate from an au uthorized CA ⎯ Acceptancee of individual certificates c fro om an authorizeed CA 256 Copyright © 2012 IEEE. All rightts reserved.



7.8.7.4.1

Verification based upon CA

An implementation, claiming conformance to this standard, shall be capable of being configured to accept certificates from one or more Certificate Authorities without the configuration of individual certificates. 7.8.7.4.2

Verification based upon individual certificates

An implementation, claiming conformance to this standard, shall be capable of being configured to accept specific individual certificates from one or more authorized Certificate Authorities (e.g.,configured). 7.8.7.4.3

Certificate revocation

Certificate revocation shall be performed as specified in RFC 3280. The management of the Certificate Revocation List (CRL) is a local implementation issue. An implementation, claiming conformance to this standard, shall be capable of checking the local CRL at a configurable interval. The process of checking the CRL shall not cause an established connection to be terminated. An inability to access the CRL shall not cause the connection to be terminated. Revoked certificates shall not be used in the establishment of a connection. An entity receiving a revoked certificate during connection establishment shall refuse the connection. The revocation of a certificate shall terminate any connection established using that certificate. Other standards, referencing this standard, shall specify recommended default evaluation intervals. The referencing standard shall determine the action that shall be taken if a certificate, currently in use, has been revoked. DNP3 implementations using TLS shall evaluate CRLs every twelve hours by default. The evaluation interval shall be configurable with hourly resolution. DNP3 devices shall terminate a connection when one of the certificates used to establish the connection is revoked. Note: Through the normal application/distribution of CRL(s) connections may be terminated creating an inability to perform communications. Thus system administrators should develop certificate management procedures to mitigate such an occurrence. 7.8.7.4.4

Expired certificates

The expiration of a certificate shall not cause connections to be terminated. An expired certificate shall not be used or accepted during connection establishment. 7.8.7.4.5

Signing

Signing through the use of RSA or DSS algorithms shall be supported. Other algorithms may be specified in standards that reference this document. 7.8.7.4.6

Key exchange

The key exchange algorithms shall support a maximum size of at least 1024 bits for the key. Both RSA and Diffie-Hellman mechanisms shall be supported.




7.8.8

Co-existence with non n-secure pro otocol traffic

Refereencing standarrds shall provvide a separatee TCP/IP porrt through whiich to exchangge TLS secureed traffic. This will allow for the possibility off un-ambiguouus secure andd non-secure ccommunicationns simulttaneously. DNP3 implementatiions using TLS shall use th he TCP port nnumber 19 9999 by default too initiate secuure connections. DNP3 implementations using the Application Layer Secure A Authentication mechanism buut not TLS shaall ort 20 000 by default. d use po DNP3 implementatio ons that do nott use any securrity measures shall continue to use port 200 000 by default. 3.2.2.2. See 13 Implem mentations thaat use other thaan the default TCP port num mbers for DNP P3 shall be connfigurable to usse the defaults.

7.9

Complia ance with IE EC/TS 62351 1-5

IEC/T TS 62351-5 states that protocols claiming g compliance to it must innclude certainn items in theeir specifi fication. This su ubclause descrribes where in this t standard thhose items are located. 7.9.1

Selected options o

Appliccation Layer authentication a security s in DN NP3 is providedd through an iimplementationn of the IEC/T TS 62351-5 standard. IE EC/TS 62351-5 5 states: ⎯ The protocol specificatio on shall identiffy which of thhe options idenntified in clauuse 8.3 [IEC/T TS f the protoco ol (if any). 62351-5] arre mandatory for ⎯ The protocol specificatio on shall identif ify any additioonal security aalgorithms, fixxed parameterrs, configurablle parameters or o features sup pported by the pprotocol beyonnd the mandato tory set specifieed in clause 8.2 [IEC/TS 623 351-5]. The Device D Profile for each DNP P3 device supp porting IEC/TS S 62351-5 autthentication shhall identify thhis capabiility. Authenticcation is considered a subseet of either maaster or outstaation functionaality to which a devicee may claim co ompliance, sepaarate from any other subset. All DNP3 D devices shall support IEC/TS 6235 51-5 Aggressivve Mode authhentication in order to claim complliance to IEC//TS 62351-5 and DNP3. As A noted in thhe specificatioon, devices m must also perm mit Aggreessive Mode to be disabled viia configuration n. All DN NP3 devices sh hall permit the Error Count to o be configurabble. The Device D Profile for DNP3 dev vices claiming compliance w with IEC/TS 662351-5 shall aalso include thhe follow wing informatio on: ⎯ A list of an ny and all hasshing algorithm ms supported bby the device in addition too the mandatorry algorithms identified i in IE EC/TS 62351-5 5. ⎯ A list of an ny and all enccryption algoriithms supporteed by the deviice addition too the mandatorry algorithms identified i in IE EC/TS 62351-5 5.




7.9.2

Operation ns considered critical

IEC/T TS 62351-5 stattes: ⎯ The protocol specificatio on shall identiffy which protoocol operationns (e.g.,functioon codes, ASD DU ges) shall be cconsidered Crittical, requiringg authenticatioon types, contrrol commands,, setting chang through thiss mechanism. ⎯ The protoco ol specification n shall specify that certain op operations desccribed in clausse 7.3.3.2 of thhis specificatio on [IEC/TS 623 351-5] are alwa ays Critical. The mandatory m and optional o criticaal operations fo or DNP3 are sppecified in 7.5.2.3.2. 7.9.3

Addressin ng informatio on

IEC/T TS 62351-5 stattes: ⎯ The protoco ol specification n shall identify which addresssing informatioon from the low wer layers of thhe protocol sha all be included d in the MAC calculation, c as described in cllauses 7.2.3.5 and 7.2.4.5, annd the order off their octets in n the calculatio on. DNP3 does not inclu ude any addressing informatio on in the MAC C calculation, aas described in the Data Objeect 0. Librarry insert sheets for Group 120 7.9.4

Message format f mapp ping

IEC/T TS 62351-5 stattes: ⎯ The protoccol specificatio on shall descrribe how eachh of the messaages describedd in clause 77.2 [IEC/TS 62 2351-5] shall be implemented d using the prottocol. ⎯ The messag ge formats desscribed in the protocol speccification messsage formats sshall include aall information n found in the messages m descrribed in this staandard. ⎯ In general, the protocol specification s shall use the seequence, layouut, and namingg of informatioon n this standard d. The only excception to this requirement occurs if an equuivalent piece of described in information n already existts elsewhere in n a protocol A ASDU (such ass a length parrameter). Undeer such condiitions the form mat and layou ut described in this standaard may be aaltered. Such a parameter shall s not be rem moved from thee protocol entiirely. ⎯ The timesta amp included in i the Error message m shall bbe in a formatt defined by the protocol. Thhis format shalll represent an unambiguous absolute time,, not a relativee time, e.g.,“miilliseconds sincce midnight on o the followin ng date…” iss acceptable, but not “millliseconds sincce the previouus midnight”. ⎯ The protoco ol specification n shall not red duce the size orr range of anyy information ddescribed in thhis standard. The mapping m of messsage formats is described in n 7.5.1 and thee Data Object Library for Grroup 120. Notees there describe how the length off Challenge Daata and some other fields aare implemented using DNP P3 fier codes. The timestamp useed is six-octet DNP3 D absolutee time. qualifi 7.9.5

Reference e to procedures

IEC/T TS 62351-5 stattes: ⎯ The protoccol specificatio on shall speciffy how the prrocedures desccribed in clauuse 7.3 [IEC/T TS 62351-5] sh hall be implemented using thee protocol.




⎯ If there is a disagreementt between the procedures p desscribed in the pprotocol specif ification and thhe procedures described in th his standard, th his standard shhall be deemedd to be the corrrect descriptionn. The DNP3 D procedurres are describeed in 7.5.2 and d are intended to be identicall to those described in IEC/T TS 62351-5.

7.10

Complia ance with IS SO/IEC 1177 70

The methods m for rem motely changin ng Update Key ys described inn this documeent are based oon the followinng internaational standarrds: ⎯ Key Establlishment Mech hanism 9 with h 5-pass mutuual authenticatiion using a K Key Distributioon Centre and random numbeers in ISO/IEC C 11770-2:20088 ⎯ Key Transp port Mechanissm 3 with 2--pass mutual authenticationn; and Public Key Transpoort Mechanism m 3: Public key distribution ussing a trusted thhird party in IS SO/IEC 11770-3:2008 This subclause s descrribes how the steps described d in these speccifications havve been implem mented using thhe DNP3 objects descriibed earlier in this t document. NOTE— —While the DNP3 D Secure Authentication A mechanism m is b ased on these standards, therre are differencces significcant enough to make m the DNP3 implementation i with ISO/IEC 111770. In particullar, the encryptioon non-compliant w functio on specified by y ISO/IEC 1177 70 for steps 7 and 8 in Tab ble 7-24 has been replaced with a Messagge Authen ntication Code (M MAC). This chaange was made to t avoid sendingg the same inforrmation both enccrypted and in thhe clear, while w retaining th he effectiveness of the authenticcation.

When comparing th he process in this t document with ISO/IEC C 11770-3:2008, it should bee noted that thhe o “A” and “B B” are reversed d in the notation. In two of the exchangess, the role “M M” for the DNP P3 roles of masterr is introduced, as distinct fro om “A”, the useer. 7.10.1 1 Requirements This subclause s desccribes the requ uirements defin ned when devveloping the m method for rem motely changinng Updatte Keys that aree described in this t standard. 7.10.1 1.1 Function nal requirements This subclause s descrribes the functional requirem ments that mustt be met by thee method for cchanging Updaate Keys. 7.10.1 1.1.1

Chan nge update keys k remotely y

The method m shall peermit utility peersonnel to chaange the Updatte Keys for anyy given user w without travelinng to rem mote sites. 7.10.1 1.1.2

Enab ble centralize ed key manag gement

The method m shall permit Update Keys K to be manaaged by a centrral authority w within the utilityy. It shall perm mit a mastter station to distribute d new Update U Keys to t an outstationn, but prevent any entity associated with thhe masterr station from changing c Updaate Keys witho out authorizatioon from the cenntral authority. 7.10.1 1.1.3

Perm mit global nam mes

The method m shall peermit a user to be b associated with w a name thhat is unique accross the utilityy. There shall bbe no technical limit to the length of th his unique nam me.




7.10.1 1.1.4

Perm mit assignme ent of role-ba ased access

The method m shall permit p a user to t be assigned d a particular role. An outsstation may deecide to enforcce particu ular access priivileges based on the assigneed role. This ddocument doess not attempt to suggest whhat those roles r may be. 7.10.1 1.1.5

Perm mit revocation n of update keys k

The method m shall peermit the centraal authority to revoke the privvileges of a usser and therefore invalidate thhe Updatte Keys associaated with that user. One way y to do so wouuld be to assignn the user a roole designated aas “no lo onger valid”. 7.10.1 1.1.6

Perm mit expiry of update u keys

The method m shall peermit the central authority to assign an exppiry interval to a set of Updaate Keys, so thhat the ou utstation will co onsider the key ys invalid after that interval. 7.10.1 1.1.7

Perm mit assignme ent of user nu umber (USR))

The method m shall permit p the outtstation to asssociate a shorrt identifier, i..e., the User Number (USR R) describ bed in the DN NP3 Secure Autthentication sp pecification, wiith the long, gglobally uniquee name provideed for thee user. The Usser Number sh hall be used for all subsequen ent authenticatiion operations associated with this usser. The method shall ensure that the masterr station authennticates this association operaation. 7.10.1 1.1.8

Follo ow standards s

The method m shall be based on interrnational standards. 7.10.1 1.2 Qualitatiive requirem ments This su ubclause descrribes qualitativ ve goals that thee method shouuld attempt to aachieve. 7.10.1 1.2.1

Minim mize key vulnerability

The method m shall atttempt to preven nt keys from beeing compromi mised as much aas possible. 7.10.1 1.2.2

Minim mize messag ges and octe ets required

The method m shall attempt to use as a few messagees and octets aas possible forr the cryptograp aphic technologgy used. 7.10.1 1.2.3

Minim mize configu uration required

The method m shall attempt a to use as little precconfigured infoormation as ppossible for thhe cryptographhic techno ology used. The preconfigureed information required is desscribed in detaiil in 7.6.1.4.100. 7.10.1 1.2.4

Minim mize process sing power required r

The method m shall atttempt to use as little processin ng power as poossible. 7.10.2 2 Notation The no otation used fo or describing co ompliance with h ISO/IEC 117770 is describedd in Table 7-233.




Table 7-23—Cryptographic notation Notation

Meaning

+

Concatenation within a message.

[x]

The portion of the message known as “x” is optional.

a

A particular user.

b

The outstation.

c

A central authority trusted by both “a” and “b”. The equivalent of a certificate authority. Most likely to be some device, person or organization within the utility.

m

The DNP3 master, which acts on behalf of “a”.

A

a’s public key.

A’

a’s private key.

AC

a’s symmetric key, shared between it and “c”.

B

b’s public key.

B’

b’s private key.

C

B

b’s symmetric key, shared between it and “c”.

C

c’s public key.

C’

c’s private key.

IDA

A globally unique identifier representing the user “a”.

IDB

A globally unique identifier representing “b”.

RA

A random number chosen by “m” on behalf of “a”.

RB

A random number chosen by “b”.

RMC

A random number chosen by “m” for communication with “c”.

A(x)

“x” is encrypted with a’s public key.

A’(x)

“x” is encrypted with a’s private key.

MC(x)

“x” is encrypted with the symmetric key shared between “m” and “c”.

B(x)

“x” is encrypted with b’s public key using a key transport scheme.

BC(x)

“x” is encrypted with the symmetric key shared between “b” and “c” using a key wrap algorithm.

SA(x)

“x” is digitally signed with a’s private key.

SB(x)

“x” is digitally signed with b’s private key.

SC(x)

“x” is digitally signed with c’s private key.

K

The new Update Key to be used between “m” and “b” representing the user “a”.

fK(x)

A MAC function is performed upon "x" using the Update Key, K.

fC(x)

A MAC function is performed upon "x" using the symmetric key shared between “b” and “c”.

K(x)

“x” is encrypted using a symmetric encryption algorithm and the Update Key, K.

USR

The shorthand user number chosen by “b” to represent the user “a” in all future communications.

KSQ

Key change sequence number chosen by “b” and kept the same throughout the message exchanges described here.

SCS

Status Change Sequence number managed by authority, unique between authority and outstation.

Ack

Data identifying whether “b” accepted “a’s” authentication and change of the Update Key.

Role

Data indicating the role, e.g.,operator, viewer, admin, config that “a” is to take.

Opr

Operation to be performed, i.e.,Add, Delete, or change the specified Update Keys.

Interval

The length of time for which “c” will certify “a”.

CertA

Certificate for a’s public key, signed by “c”.

CertB

Certificate for b’s public key, signed by “c”.




7.10.3 3 Sequence e Table 7-24 uses thee notation described in 7.10 0.2 to describee the DNP3 m method of key management in referen nce to ISO/IEC C 11770. Note that steps 1, 5,, and 6 are out of the scope off this standard..




Change User Status by Authority

Change User Status (g120v10)

Update Key Change Request (g120v11)

Update Key Change Reply (g120v12)

Request Key

mb

mb

mb

cm

2

3

4

5

Name

cm

Direction

1

Step

Sym only, Not DNP3

Both


IDA + RMC + RB + IDB

KSQ + USR + RB

IDA + RA

SCS +Opr + IDA + Interval + Role + fC(SCS + Opr + IDA + Interval + Role)

Sym

Both

SCS + Opr + IDA + Interval + Role + A + SC(SCS + Opr + IDA + Interval + Role + A)

SCS + Opr + IDA + Interval + Role + fC(SCS + Opr + IDA + Interval + Role)

Sym Not DNP3

Asym

SCS + Opr + IDA + Interval + Role + A + SC(SCS + Opr + IDA + Interval + Role + A)

Contents (Refer to the DNP3 Object Definitions for a complete list of parameters in the objects)

Asym Not DNP3

Method

Table 7-24—Compliance with ISO/IEC 11770

7.3 (2)

7.3 (1) KSQ + USR added

Not specified. Step 1 already provided a certificate.

11.4 A1 Text1 = KSQ+USR

Not specified.

n/a

Not specified. Not specified.

12.2.1 A1 and B1

Part 3 (Asym)

n/a

Part 2 (Sym)

ISO/IEC 11770 steps


In the symmetric case, the master requests the new Update Key from the authority.

The outstation challenges the master, assigns a User Number to the user, and assigns a Key Sequence Number.

The master initiates the key change sequence by naming the user and providing random data.

The master passes the certified status change information from the authority through to the outstation, without modification.

The authority certifies that a particular user has been added, deleted, or its role has otherwise changed, for a specified interval.

Description


Key for M and B

Update Key Change (g120v13)


mb

mb

7

7a

Name

cm

Direction

6

Step


265

fK (IDB + RA + RB + KSQ + USR)

7.4 (4) As above in step 7.

7.4 (4) Text2= null Text3=IDB+ KSQ+USR Added KSQ+USR plain Uses an MAC instead of encryption

KSQ + USR + BC(IDA + K + RB) + fK (IDB + RA + RB + KSQ + USR)

Sym (g120v15)

Both. Optional instead of steps 5, 6 and 7. (g120v15)

n/a

7.3 (3) Text1 = null Text2 = null

Part 2 (Sym)

n/a

11.4 B1 Text2 = RB Text3 = KSQ+USR Text4 = KSQ+USR

Not specified. Step 1 already provided a certificate.

Part 3 (Asym)

ISO/IEC 11770 steps

KSQ + USR + B(IDA + K + RB) + SA(IDB + RA + RB + KSQ + USR + B(IDA + K + RB))

MC(IDB + K + RMC) + BC(IDA + K + RB)

Contents (Refer to the DNP3 Object Definitions for a complete list of parameters in the objects)

Asym (g120v14)

Sym only, Not DNP3

Method


The master authenticates itself to the outstation and confirms which key is in use, but does not change the key. (optional instead of steps 5, 6, and 7)

The master passes through the new Update Key to the outstation, encrypted with the symmetric key shared between the central authority and outstation, and authenticated using the Update Key itself.

The master sends the new Update Key to the outstation, encrypted with the outstation’s public key and authenticated by digitally signing with the user’s private key.

In the symmetric case, the authority provides the Update Key (K) to the master and authenticates the key change to both the master and outstation.

Description


8

Step

mb

Direction


Name

Both (g120v15)

Method


266

fK (IDA + RB + RA + KSQ + USR)

Contents (Refer to the DNP3 Object Definitions for a complete list of parameters in the objects) 7.4 (4) Text4=IDA+ KSQ+USR Uses an MAC instead of encryption

Part 2 (Sym) Not specified.

Part 3 (Asym)

ISO/IEC 11770 steps


The outstation confirms the key change and authenticates itself using the new Update Key.

Description


8

Transportt Function

8.1

Overview w

8.1.1

Layering

The Transport T Funcction is actuallly a sublayer of the Applicaation Layer thhat fits below the Applicatioon Layer just above thee Data Link Laayer (Figure 8-1). 8 All messaages to and froom the Applicaation Layer paass gh the Transporrt Function on their way from m and to the othher station. throug

Master

Outtstation

User U Layer

Useer Layer

DNP3 App plication Laayer

D DNP3 Appliccation Layerr

Tran nsport Function

Transport Function

DNP3 Datta Link Lay yer

D DNP3 Data L Link Layer

Physsical Media Figure 8-1—Transp port Function n location is between Ap pplication Lay yer and Data Link Lay yer 8.1.2

Purpose

The siize of a DNP3 Application Laayer message fragment f may bbe larger than tthe number of octets permitteed in a siingle Data Link k Layer frame.. The Transporrt Function dissassembles Appplication Layer fragments into Data Link Layer-siized data unitts (called tran nsport segmennts; see Figurre 8-2) for trransmission annd o appliccation fragmennt on receptionn. The series oof reassembles these trransport segmeents into the original u to transmit an Applicatio on Layer fragm ment is called a transport segm ment-series. transport segments used f is brroken into smaaller portions, and a header is At thee transmission site, an Appliication Layer fragment added containing seq quencing inform mation for each h portion. The header and appplication data form a transpoort ways passed oone-at-a-time, in segmeent that is passsed to the Datta Link Layer.. Transport seggments are alw sequen nce, from the first f to the last. Header

Application Layer Daata

← 1 octet →

← fro om 1 to 249 octe ts →

Figure 8-2— —Transport s segment




At thee receiving sitee, transport seg gments passed from the Dataa Link Layer aare checked for sequencing bby examining the headeer. Any transpo ort segments th hat are receivedd out of order w will cause the segment and thhe Any transport seegment that is received and is entire,, in-progress trransport segmeent-series to bee discarded. A identiccal to the previously received d segment willl be discarded,, but will not ccause the in-prrogress transpoort segmeent-series to be b discarded. Only when a complete appplication fraggment is assem mbled does thhe Transp port Function notify n the Appllication Layer that it is availaable.

8.2

Transpo ort Function n description n

8.2.1

Transportt header

The trransport headerr consists of a single s octet. Th he header is thhe first octet in a transport seggment. A headder is prep pended to eacch portion of Application A Laayer data befoore submissionn to the Data Link Layer fo for transm mission. Upon receipt of a traansport segmeent from the D ata Link Layeer, the header iis stripped awaay beforee assembly of an a application fragment. f The transport headerr octet is composed of three fields, f as shownn in Figure 8-33.

Bit B #

7

6

5

4

Fields F

FIN F

FIR

SEQUENCE S

3

2

1

0

Figure 8--3—Header ffields 8.2.1.1

FIN field d

The FIN field is a siingle bit which h, when set, ind dicates that thiis is the final oor last transporrt segment in thhe fragmeent. ⎯ FIN = 0 ind dicates more traansport segmen nts follow. ⎯ FIN = 1 ind dicates the final transport segm ment in a seriees of transport ssegments. 8.2.1.2

FIR field d

The FIR F field is a single bit which, when set,, indicates thaat this is the ffirst transport segment in thhe fragmeent. ⎯ FIR = 0 ind dicates this is not the first tran nsport segmentt in a series of ttransport segm ments. ⎯ FIR = 1 ind dicates this is th he first transpo ort segment in a series of transport segmentss. 8.2.1.3

SEQUEN NCE numberr field

The SEQUENCE nu umber is a 6-bit b field. It is used u to verify that transportt segments are received in thhe correcct order and guards g against duplicated or missing transsport segmentss. It has a rannge of 0 to 63. Sequence numbers increment by one, modulo 64, for each transport segm ment in a serries of transpoort her hold a sin ngle Applicatio on Layer fragm ment. After seequence numbber 63, the next segmeents that togeth sequen nce number vaalue is 0. 8.2.1.4

Rules

⎯ Rule 1: A transport segm ment-series may y only begin w with a transporrt segment havving the FIR bbit set. ⎯ Rule 2: A transport t segmeent-series endss with a transpoort segment haaving the FIN bbit set.




⎯ Rule 3: Wh hen no transpo ort segment-serries is in progrress, any transpport segment rreceived without the FIR bit set shall be disscarded. ⎯ Rule 4: A transport segm ment with the FIR F bit set maay have any seequence numbber from 0 to 663 gard to prior hisstory. without reg ⎯ Rule 5: Aftter a transport segment-series s s has been startted: 1) Each su ubsequent receeived transport segment shall have a sequennce number thaat is incrementeed by one (modulo 64) from f the preceeding transportt segment. A reeceived transpoort segment thhat t requiremen nt becomes thee next member of the transporrt segment-seriies. meets this 2) A receeived transportt segment hav ving the FIR bit set shall cause the enttire, in-progress transpo ort segment-serries to be discaarded, and a nnew transport ssegment-series shall be starteed with th he newly receiv ved transport seegment as its fi first member. 3) A receeived transport segment thaat is octet-for--octet identicaal to the precceding transpoort segmen nt shall be disccarded. 4) A receiived transport segment s havin ng the FIR bit ccleared and a seequence number other than thhe expecteed incrementall number, that is not octet-fo for-octet identiical to the precceding transpoort segmen nt, shall be disscarded and sh hall also causee the entire, inn-progress trannsport segmenntseries to t be terminateed and discardeed. ⎯ Rule 6: A transport t segment-series may y consist of a siingle transportt segment havinng both FIR annd FIN bits sett. ⎯ Rule 7: When a complette transport seegment-series iis assembled, only then mayy its applicatioon data be passsed to the Appllication Layer. 8.2.2

Applicatio on Layer data a

A tran nsport segment consists of a trransport headeer followed by 1 to 249 Appliication Layer ddata octets. NOTE— —The recommeended practice fo or maximum effficiency is to usee a transport seggment size as larrge as possible ffor the com mmunication env vironment.

The fo ollowing rules apply: ⎯ Rule 1: Eaach transport segment may contain c 1 to 2449 Applicationn Layer data ooctets. Transpoort segments may m contain feewer than 249 Application L Layer data octtets. It is not rrequired that aall segments, except e the last,, have the sam me size; it is perrmissible to vaary the segmennt sizes withinn a segment-serries. The receiv ver shall accep pt transport seggments of varyiing sizes. ⎯ Rule 2: Th he Transport Fu unction preserrves the octet oorder of the A Application Layyer fragment, aas illustrated by b the examp ple in 8.2.3. At A the receiviing end, Application Layerr fragments are reassembled d in sequence. 1) Application data is diivided into suittably sized port rtions or sets off octets.27 2) The firrst application data portion, with octet num mber 0, is trannsported by thhe first transpoort segmen nt; that segmen nt has the FIR bit b set in the heeader and a seqquence numberr N. 3) The neext application n data portion, if there is onne, is then plaaced into a traansport segmennt having sequence num mber (N + 1) mo odulo 64. 4) This pattern, p of placing the Application Layerr data portionns into transpoort segments in ascendiing sequence, continues c untill the last portioon is sent. 5) The FIN N bit is set in the t header of th he last segment nt. 27

The word w portion is purrposely used to av void the term packeet. The concepts arre essentially the ssame; however, paacket often infers tthe octets trransmitted at the Physical P Layer.




8.2.3

Segmenting example

The fo ollowing examp ple illustrates the t Transport Function. F

This exam mple illustratess a 600-octet Application A Layyer fragment bbeing divided innto three portioons and the organization o off that data withiin transport seggments. EX 8-1 Octet num mbers for the application a datta are shown innside the elemeents. The letterrs “TH” stand for Transporrt Header. Octeets are transmittted in left-to-rright order.

A Lay yer fragment is divided into th hree portions. The Application 0

1

…

247 2 248 249 250 …

← 1st po ortion

496 497 498 499 …

→ ← 2nd portion

→ ← 3rd portiion

598 599 →

First trransport segmeent: 0 TH

1

…

247 248

n data portion ← 1st application

→

Transport header: h FIR = 1, 1 FIN = 0, SEQ QUENCE = n ((any number 00–63, e.g.: 25).

nd transport seg gment: Secon 249 9 250 … TH

496 497

n data portion ← 2nd application

→

Transport header: h FIR = 0, 0 FIN = 0, SEQ QUENCE = (nn+1) modulo 644 (e.g.: 26). ment: Third transport segm 498 8 499 … TH

598 599

n data portion ← 3rd application

→

Transport header: h FIR = 0, 0 FIN = 1, SEQ QUENCE = (nn+2) modulo 644 (e.g.: 27). 270 Copyright © 2012 IEEE. All rightts reserved.



8.2.4

Reception n state table

Assum me the Transpo ort Function so oftware has a fragment buffe fer where appliication data froom the receiveed transport segments are a temporarily y stored before presenting the fragment to thhe Application Layer. The so oftware requirees two states fo or proper operaation. a))

Idle state: The T software iss idle waiting for fo a transport ssegment to arriive with the FIR R bit set.

b)) Assembly state: s The frag gment buffer ho olds applicatioon data from aat least one traansport segmennt. While in this t state, the software is awaiting a addittional transport segments tto complete thhe fragment. Keys for f understandiing Table 8-1: ⎯ X means “d don’t care”. ⎯ SAME meaans the sequen nce number is identical i to thee sequence num mber in the traansport segmennt immediately y preceding thiis transport seg gment. ⎯ +1 means the t sequence number is inccremented by one count, m modulo 64, from m the sequencce number in the t transport seegment immediiately precedinng this transporrt segment. ⎯ +M, 1 < M < 64 means th he sequence nu umber is increm mented by morre than one couunt and less thaan nce number in the transport s egment immeddiately precedinng this transpoort 64 counts frrom the sequen segment. ⎯ Read Tablee 8-1 as follows: If the softw ware is currently y in the state sh hown in colum mn A, and a transp port segment iss received with h the fields in itts Transport Header as shownn in column C,, then perform m the action stated in column n D, and go into the software state specified in i column E. Column B contains c comm ments regarding g the received ttransport segm ment.




Assembly

Idle

X 0 1

1 0 0

0 1 1

Transport segment is octet-for-octet identical to previous.

Transport segment is NOT octet-for-octet identical to previous.

Expected segment received, more segments 0 are expected. 0

First of multiple segments.

Expected segment received, final segment.

SEQ is out of order.

First of multiple segments.

Entire application data fits within the segment.

SEQ

Assembly

Clear the fragment buffer and place transport segment’s data into the fragment buffer.

272

10

Clear contents of fragment buffer, place transport segment’s data into the fragment buffer and pass fragment buffer to Application Layer. X

Idle

9

Clear contents of fragment buffer and place transport Assembly segment’s data into the fragment buffer.

X

8

Discard transport segment and the entire, in-progress Idle transport segment-series.

+M 1 < M < 64

7

Idle

Append transport segment’s data to contents of fragment buffer and pass fragment buffer to Application Layer.

+1

6

5

4

3

2

1

Assembly

Discard transport segment and the entire, in-progress Idle transport segment-series.

Assembly

Idle

Clear the fragment buffer, place transport segment’s data into the fragment buffer and pass fragment buffer to Application Layer.

Discard transport segment.

Idle

Discard transport segment.


E

Transition to state

Append transport segment’s data to contents of fragment buffer.

+1

SAME

SAME

X

X

X


1

0

X

X

0

1

1

FIN X

Entire application data fits within the segment.

FIR


with these fields in its transport header 0

and a transport segment is received (comments appear below)


D

Action

C

Not a first segment.

B


A

Current state

Table 8-1—Transport Function reception state table



8.2.5

Reception n state diagra am

The teext at the begin nning of 8.2.4 regarding frag gment buffers and the two sttates applies too the diagram in Figure 8-4. The term m “segment” in n the diagram refers r to a transsport segment. FIR=0, FIN=X, SEQ=X

Discard segment

Idle State S FIR= =1, FIN= =1, SEQ Q=X

FIR=1, FIN=0, SEQ=X

Pass s fragment buffer to t application layer

Clear ccontents of fragme ent buffer

Dis scard segment & entire series Place se egment’s data into fragment uffer bu

Append d segment to fragm ment buffer

FIR R=0, FIN=X, SEQ=+M, M<64 1
FIR=0, FIN=X, SE EQ=SAME Se egment not id dentical to preceding p

Place seg gment’s data into frragment bufffer

Pass fra agment pplication buffer to ap laye er

FIR=1, FIN=0, SEQ=X FIR=0, FIN=1, EQ=+1 SE

FIR=1, FIN=1, SEQ=X

Ass sembly State S

Discaard segment

Clear co ontents of fragmen nt buffer

Segment octet o for octet identical to ng precedin

Append segment to fragme ent buffer FIR R=0, FIN =0, SEQ Q=+1

Fig gure 8-4—Re eception statte diagram

273 Copyright © 2012 IEEE. All rightts reserved. Authorized licensed use limited to: UNIVERSIDADE FEDERAL DA BAHIA. Downloaded on August 10,2015 at 14:58:21 UTC from IEEE Xplore. Restrictions apply.


9 9.1

Data Link Layer Layering g overview

The Data D Link Layer provides an n interface bettween the Tran ansport Functioon and the phhysical media oor network connection management layer. Clause 13 and Anneex C together describe the interface to thhe ment layer for IP I networking. In particular, ssee Figure 13--1 and 13.2.3. connection managem The main m contributio ons of the Datta Link Layer are a station adddressing and errror detection. This layer addds the lasst DNP3-speciffic overhead occtets when tran nsmitting over the communication channel. The DNP3 D Data Lin nk Layer assum mes that commu unication is seent to and receiived from a low wer layer where data is represented as a continuo ous stream, regardless of thhe actual physsical communiication medium m. ples include assynchronous seerial and data packet p interfac es such as TCP P/IP and UDP//IP, all of whicch Examp are treeated as a generric data stream m by the DNP3 Data Link Layyer. The DNP3 D Data Link L Layer is suitable for both connecttion-less and connection-orriented system ms. Conneection-oriented d infers physicaal networks th hat require dialling, logging iin, or otherwisse establishing a comm munication chan nnel before data transfer to th he destination ddevice can trannspire. This doccument does not includ de connection service s requireements. These requirements aare system deppendent and beeyond the scoppe of the DNP3 protoco ol (Figure 9-1)).

Master

O Outstation

Usser Layer

U User Layer

DNP3 D Appliccation Layeer

DNP3 Appliication Layyer

Transp port Functio on

Transpport Functiion

DNP3 D Data Link Layerr

DNP3 Dataa Link Layeer

Physiccal Media / Network Connectionn Managem ment Layerr Figure 9-1—DNP3 protoc col stack

9.2

DNP3 Da ata Link Lay yer descripttion

9.2.1

Introduction

In DN NP3, the Data Link L Layer has two main purp poses. First, it bbi-directionallyy transports Appplication Layyer data across the comm munication chaannel to the deestination devicce. When perfo forming transm mission tasks, thhe L Layer software encodees the Transpo ort Function seegments passedd down from upper layers bby Data Link constrructing or building a data lin nk frame, and then sends thhe frame to thhe communicattion channel fo for



transm mission. When performing reeception tasks, transport segm ments are extraacted from incooming validateed data liink frames and are passed to upper u layers. Secon nd, the Data Liink Layer man nages data link k frame synchrronization, floow control, andd error handlinng and prrovides indicatiion of link stattus. 9.2.2

Services

The Data D Link Layerr provides the following f serv vices to the oveerall protocol: ⎯ Encapsulatiion of transp port segmentss into data link frames for transmisssion over thhe communicaation channel ⎯ Decoding of o data link fram mes received frrom the commu munication channnel into transpport segments ⎯ Error detecttion ⎯ Source and destination ad ddressing ⎯ Optional co onfirmation of each data link frame ⎯ Optional deetection of lost or repeated daata link frame rrequests ⎯ Optional flo ow control 9.2.3

Transactio on model

The Data D Link Layeer uses transacttions for conveeying data to thhe Data Link L Layer in anothher DNP3 devicce and to o perform link management m fu unctions (Figure 9-2). A trannsaction consists of one or tw wo messages. a))

A request message m from th he device initiaating the transaaction, called tthe Primary Staation, to anothher device, called the Secondaary Station.

b)) Optionally, a response meessage from thee Secondary Sttation back to tthe Primary Staation. NOTE— —Data Link Laayer requests and d responses are independent froom the requests and responses iin the Applicatioon Layer.

Messaages originating g from the Prim mary Station allways contain a data link funnction code thaat determines thhe action n the Secondary y Station is to perform. p Somee function codees are private bbetween both D Data Link Layeers and arre intended forr managing thee link. Other function fu codes are used for m moving data paayloads from aan upper layer in the Prrimary Station to t the correspo onding upper laayer in the Secondary Stationn. Some,, but not all, of the Data Lin nk Layer functiion codes in thhe primary-to--secondary messages require a respon nse at the Dataa Link Layer level. The resp ponse may sim mply acknowleddge the receiptt of the Primarry Station n’s message, or o it may conttain informatio on about the S Secondary Stattion’s Data Linnk Layer, but it never contains data from f the higherr layers. The main m job of th he Data Link Layer is to carry c data from m upper layerrs called Userr Data which is sometiimes referred to t as the payloaad data. The Data D Link Layeer always transm mits user data in a Primary-tooSecon ndary Station reequest messagee. The Data D Link Layeer in each DNP P3 device acts as a both a Prim mary Station annd as a Secondary Station. Thhe behaviior as a Secondary Station iss independent of o its behaviorr as a Primary Station. For eexample, whenn a masterr station issuess a poll, its App plication Layerr passes inform mation to the D Data Link Layerr requesting it to initiatee a transaction n to send the in nformation to the Applicatioon Layer in ann outstation. Thhe master is thhe Primarry Station, and d the outstation n is the Second dary Station. W When the Appllication Layer iin the outstatioon has daata to return to the master, it passes that information to itts Data Link L Layer requestinng it to initiatee a transaction to send the t data to thee Application Layer L in the m master. In this instance, the ooutstation is thhe



Primarry Station and d the master iss the Secondarry Station. In aall cases, whenn a station traansmits a fram me, wheth her it is the Prim mary Station orr Secondary Station: ⎯ If the station is a Master, the t DIR bit shaall be set. ⎯ If the station is an Outstattion, the DIR bit shall be cleaared. Maaster Outgoing Usser Data

Incoming Usser Data

Outstation Framees with PRM = 1 DIR = 1

Primary Station

Seccondary S Station

Framees with PRM = 0 DIR = 0 Framees with PRM = 1 DIR = 0

Secondary Station

Prrimary S Station

Framees with PRM = 0 DIR = 1

Incoming User Data

Outgoing User Data

Figure F 9-2—T Transaction diagram 9.2.4

Frame forrmat

This subclause s desccribes the DNP P3 data link frrame format (F Figure 9-3). A data link fraame has a fixeed length h header block, block 0, follow wed by optionaal data blocks. Each block ennds with a 16-bbit CRC. Octet transmission orrder

Block B transmissiion order

Start S Destinationn Source CRC C Len Ctrl 0x05 5 0x64 LSB MSB B LSB MSB LSB MSB Head der Block (Block k 0) User Data (16 octets)

CRC LSB MSB B

User Data (16 octets)

CRC LSB MSB B

1st Data D Block (Blocck 1)

2nd Data D Block (Blocck 2)

CR RC LSB MSB

User Data (1 ( to 16 octets) Nth Data D Block (Blocck N)

Figure 9-3— —DNP3 frame e format 9.2.4.1

Data Lin nk Layer head der frame fie elds

This subclause descrribes Block 0, or o header, of a data link fram me. The headerr fields consist of 2 start octetts, gth octet, 1 link k control octet, a two-octet deestination addreess, and a two--octet source adddress. 1 leng



9.2.4.1.1

START field

The START field is 2 octets in length. The first octet is a 0x05, and the second octet is a 0x64. 9.2.4.1.2

LENGTH field

The LENGTH field is 1 octet in length and specifies the count of non-CRC octets that follow in the header and data blocks. This count includes the CONTROL, DESTINATION, and SOURCE fields in the header and the USER DATA fields in the body. CRC fields are not included in the count. The minimum value for this field is 5, indicating only the header is present, and the maximum value is 255. 9.2.4.1.3

CONTROL field

The CONTROL field is 1 octet in length and contains information about the frame’s direction, transaction initiator, error and flow control, and function. Figure 9-4 shows the control octet fields.

DIR PRM Bit

7

6

FCB FCV 0

DFC

5

4

FUNCTION CODE 3

2

1

0

Figure 9-4—Control octet bit definitions 9.2.4.1.3.1

DIR bit field

The Direction bit is independent from the Data Link Layer transmission originating from the Primary Station or from the Secondary Station. The transmitting device shall set the Direction bit to indicate the physical transmission origin of the data link frame. ⎯ DIR = 1 indicates a frame from a Master. ⎯ DIR = 0 indicates a frame from an Outstation. Receiving devices should ignore this field. This bit may be used for debugging or testing. 9.2.4.1.3.2

PRM bit field

The Primary Message Bit indicates the direction of the data link frame with respect to the initiating station. PRM = 1 indicates a Data Link Layer transaction is being initiated by either a master or an outstation, and the function code is chosen from Table 9-1. The FCB and FCV fields function in their Data Link Layer synchronization mode as described in 9.2.4.1.3.3 and 9.2.4.1.3.4. ⎯ PRM = 0 indicates a Data Link Layer transaction is being completed by either a master or an outstation, and the function code is chosen from Table 9-2. Bit 5 shall always be 0. The DFC field (bit 4) functions in its Data Link Layer flow control mode as described in 9.2.4.1.3.5. 9.2.4.1.3.3

FCB bit field

The FCB and FCV bit fields function together to maintain synchronization for Confirmed User Data services. Typically devices should use Unconfirmed User Data services. For more information, see 10.2. The FCB is only valid in Data Link Layer request messages sent from the Primary Station to the Secondary Station with the FCV bit set. Table 9-1indicates the usage of the FCV bit. 277 Copyright © 2012 IEEE. All rights reserved. Authorized licensed use limited to: UNIVERSIDADE FEDERAL DA BAHIA. Downloaded on August 10,2015 at 14:58:21 UTC from IEEE Xplore. Restrictions apply.


The Frame Count bit (FCB) is used to detect losses and duplication in primary-to-secondary frames. The Data Link Layer in a Secondary Station can detect that a request is new when it receives a frame having the FCV bit set and an FCB that matches the state expected by the Secondary Station. When the Secondary Station detects this condition, it toggles the state that it expects for the FCB in the next message with the FCV bit set. If the received FCB bit in a message does not match the expected FCB state when the FCV is set, the Secondary Station recognizes the message as being a repeat of a previous message and acts according to 9.2.6.3. The Primary Station toggles its FCB upon receiving a frame with the ACK function code back from the Secondary Station. FCB and FCV shall be cleared by the Primary Station, and not checked by the Secondary Station, when using UNCONFIRMED_USER_DATA links service. 9.2.4.1.3.4

FCV bit field

The Frame Count Valid (FCV) bit appears in every primary-to-secondary frame and specifies whether the Secondary Station is to examine the FCB bit. Table 9-1 indicates the usage of the FCV bit. ⎯ FCV = 1 indicates the state of the FCB bit is valid and that the state of the FCB bit in the received message shall be checked against its expected state. ⎯ FCV = 0 indicates the state of the FCB bit is ignored. Before a station acting as a Primary Station can transmit primary-to-secondary frames with the FCV bit set, it shall first verify that the Secondary Station’s expected FCB (EFCB) is properly synchronized. The Primary Station does this by sending a request to reset the Secondary Station’s link states. It should send this message upon detection of communication loss or whenever either station restarts. Each Secondary Station, after Data Link Layer startup or transaction failure, shall not accept any Primary Station request messages having the FCV bit set until its FCB state has been reset by receiving a reset link states request from the Primary Station. 9.2.4.1.3.5

DFC bit field

The Data Flow Control (DFC) bit appears in every response from a Secondary Station regardless of the function code in the control octet. It is used to report an insufficient number of Data Link Layer buffers to hold a receive frame. It is also used to indicate that the Secondary Station’s Data Link Layer is busy. ⎯ DFC = 1 indicates receive buffers were not available or that the Secondary Station’s Data Link Layer was busy. ⎯ DFC = 0 indicates receive buffers were available and the Secondary Station’s Data Link Layer was ready. 9.2.4.1.3.6

FUNCTION CODE field

The Function Code identifies the function or service associated with the data link frame. The definition of the values placed in this field depends on whether Data Link Layer messages are sent from the Primary Station to the Secondary Station or from the Secondary Station to the Primary Station. Table 9-1 and Table 9-2 specify the codes and associated FCV states. A detailed description of each function is provided in 9.2.6 and 9.2.7.

278 Copyright © 2012 IEEE. All rights reserved. Authorized licensed use limited to: UNIVERSIDADE FEDERAL DA BAHIA. Downloaded on August 10,2015 at 14:58:21 UTC from IEEE Xplore. Restrictions apply.


Table 9-1—Primary-to-secondary (PRM = 1) function codes Primary function code

Function code name

FCV bit

Service function

Response function codes permitted from Secondary Station

0

RESET_LINK_STATES

Reset of remote link

0

0 or 1

1

—

Obsolete

—

15 or no response

2

TEST_LINK_STATES

Test function for link

1

0 or 1 (no response is acceptable if the link states are UnReset)

3

CONFIRMED_USER_DATA

Deliver application data, confirmation requested

1

0 or 1

4

UNCONFIRMED_USER_DATA

Deliver application data, confirmation not requested

0

No Secondary Station Data Link response

5

—

Reserved

—

15 or no response

6

—

Reserved

—

15 or no response

7

—

Reserved

—

15 or no response

8

—

Reserved

—

15 or no response

9

REQUEST_LINK_STATUS

Request status of link

0

11

10

—

Reserved

—

15 or no response

11

—

Reserved

—

15 or no response

12

—

Reserved

—

15 or no response

13

—

Reserved

—

15 or no response

14

—

Reserved

—

15 or no response

15

—

Reserved

—

15 or no response

Table 9-2—Secondary-to-primary (PRM = 0) function codes Secondary function code

Function code name

Service function

0

ACK

Positive acknowledgment

1

NACK

Negative acknowledgment

2

—

Reserved

3

—

Reserved

4

—

Reserved

5

—

Reserved

6

—

Reserved

7

—

Reserved

8

—

Reserved

9

—

Reserved

10

—

Reserved

11

LINK_STATUS

Status of the link

12

—

Reserved

13

—

Reserved

14

—

Obsolete

15

NOT_SUPPORTED

Link service not supported



All devices shall accept and process messages received with primary-to-secondary function codes 0, 2, 3, 4, and 9. It is not permissible to reply to these messages with secondary-to-primary function code 15. A Primary Station shall use the UNCONFIRMED_USER_DATA function code when transmitting to a broadcast destination address (i.e., 0xFFFD, 0xFFFE, or 0xFFFF). A Secondary Station shall not reply to any request that contains a broadcast destination address regardless of which function code appears in the request. 9.2.4.1.4

DESTINATION field

The Destination address field is two octets in size and specifies the address of the station to which the frame is directed. The first octet of the address is the low order octet, and the second octet is the high order octet (Figure 9-5).

Figure 9-5—Destination address format Refer to 9.2.5 for more information regarding addresses. 9.2.4.1.5

SOURCE field

The Source Address field is two octets in size and specifies the address of the station from where the frame originates. The first octet of the address is the low order octet, and the second octet is the high order octet (Figure 9-6).

Figure 9-6—Source address format Refer to 9.2.5 for more information regarding addresses. 9.2.4.2

User data

User data refers to the link user’s data; in other words, the data belonging to the higher layers that use the Data Link Layer. One philosophy behind the link layer design is that of layer independence. The Data Link Layer provides services to the higher layers but is unaware of the content of the payload that it transports. As shown in Figure 9-3, the blocks following the header block hold the User Data (also referred to as the payload). The maximum number of user data octets that a single frame can hold is 250. (5 octets in the link header are included in the octet count, thus leaving a maximum 250 for user data.) Each block, except the Header and the last User Data block, shall contain exactly 16 octets of link user’s data. The last block holds the remaining octets if the total number of user data octets is not evenly divisible by 16. Each user data block has a 2-octet CRC appended to it. Not all frames convey user data. Some are used for managing the link. 9.2.4.3

CRC fields

A 2-octet cyclic redundancy check is appended to each block in a frame. The START, LENGTH, CONTROL, DESTINATION, and SOURCE fields are all included when calculating the CRC for the header.



Each transmitted t fraame contains a 2-octet CRC for every 16 data octets annd one for the data link fram me headerr. These CRC words are cheecked in each received fram me so that onlyy valid data arre passed to thhe Transp port Function. The 2--octet CRC ch heck is generateed from the following polynoomial and thenn inverted befoore being placeed in the block for transsmission: 1 X16 + X13 + X12 + X11 + X10 + X8 + X6 + X5 + X2 + 1

Annex x E provides methods m for com mputing this CR RC. Figure 9-7 shows th he ordering of the 2-octet CRC C within each hheader or user data block.

llast octet

firsst octet Header H or user data octets

CRC LSB MSB

Figure 9--7—CRC ord ering

EX 9-1

This exam mple shows th he CRC for a Test T Link Statees frame from a Source Addrress with address 65 519 to o Destination Address A with ad ddress 1.

►►► Reequest Messagee 05 64 START 9.2.4.4

05 LEN

F2 01 00 EF FF ESTINATION SOURCE CTRL DE

BF CRC

B5

Inter-octtet and inter--frame gaps

Each Data D Link Layeer frame should d be transmitteed without inteer-octet gaps. Receiv vers may optio onally choose to t discard an en ntire frame andd begin waitinng for start octeets if they deteect a gap between octeets within the frame. Howev ver, this is a pprocessing effficiency concerrn because it is possib ble for receiverrs to recover frrom errors with hout such a feaature. DNP3 ddoes not speciffy the timing fo for this op ption. In DN NP3, a device is permitted to transmit two messages m conssecutively withhout an intervaal between them m. Receiv ving devices sh hall not requirre an inter-fram me gap to idenntify new framees. Frames shaall also meet thhe requirements in 9.2.9 9. See 10 0.4 for more in nformation. 9.2.5

Addressin ng notes

DNP3 requires both source and destination addreesses to enable multiple mastters and multipple outstations to t communicaation channel. share the 9.2.5.1

Choosin ng addresses s

Each master and ou utstation devicce on a single link shall utiilize a DNP3 address in thee range 0x00000 gh 0xFFEF thatt is unique from m all other dev vices on the linkk. throug 281 Copyright © 2012 IEEE. All rightts reserved. Authorized licensed use limited to: UNIVERSIDADE FEDERAL DA BAHIA. Downloaded on August 10,2015 at 14:58:21 UTC from IEEE Xplore. Restrictions apply.


9.2.5.2

Reserve ed and specia al use addres sses

Addreesses in the ran nge 0xFFF0 th hrough 0xFFFF F are reserved by DNP3 for special use, annd devices shaall not use these for theiir individual ad ddress assignm ment (Table 9-33). Table T 9-3—Special use ad ddresses Address

Sp pecial use

0xFF FFF

Broadcasst, Application Layer L Confirmatiion to clear IIN11.0 [BROADCA AST] is optional

0xFF FFE

Broadcasst, Application Layer L Confirmatiion to clear IIN11.0 [BROADCA AST] is mandatorry

0xFF FFD

Broadcasst, Application Layer L Confirmatiion shall not be rrequired to clearr IIN1.0 [BROAD DCAST]

0xFF FFC

Self-addrress

0xFF FF0 to 0xFFFB

Reserved d

9.2.5.2.1

Broa adcast addres sses

Addreesses 0xFFFD to t 0xFFFF are defined as bro oadcast addres ses, and all staations shall acccept frames with the deestination addreess set to thesee values. See Clause C 4 throug ugh Clause 6 foor more inform mation regardinng behaviior specific to o these three addresses. a Messsages transmiitted to these addresses shalll never use thhe confirm med delivery function f code CONFIRMED_ C _USER_DATA A. The Data D Link Layeer shall pass to o higher layerss information rregarding whicch address is rreceived when a broadccast message is i received. Th his is because the Applicatioon Layer is obbligated to behhave in speciffic ways depending d on which w destinatiion address waas received. 9.2.5.2.2

Self-a address

Addreess 0xFFFC is called the “S Self-address,” and a it shall onnly appear in the destinatioon address fielld. Suppo ort for it is optiional. Devices that support th his address, andd have the selff-address featurre enabled, shaall processs frames with destination ad ddress 0xFFFC C as if the messsage had used the device’s unnique individuual addresss. Responses always a includee the device’s individual i adddress in the souurce address fieeld. This featuure can sim mplify the com mmissioning, trroubleshooting g and maintenaance of devicess because it is nnot necessary to know the receiving g device’s add dress ahead of o time. Oncee the destinattion device’s true address is vered, testing can resume with h the proper in ndividual addreess. discov Devices that supportt the self-addreess shall have a means to disaable it. NOTE— —Only enable a single devicee at a time for processing messsages with thee self-address destination so thhat multiplle devices do not respond.

9.2.5.2.3

DNP3 3 reserved addresses

Addreesses 0xFFF0 to o 0xFFFB are reserved for fu uture use by DN NP3, and userss shall not assiign these for anny reason n. Messages with w a destinatiion address in this range shaall not be passed to the higgher layers; theey should d be discarded. 9.2.6

Primary-to o-secondary y function codes

These function codes apply when the t PRM field is i a 1 in the heeader block conntrol octet.



9.2.6.1

Function code 0

RESET_LINK_STATES

This function code is utilized for synchronizing a Secondary Station’s states so that it properly processes primary-to-secondary frames with the FCV bit set. This function code is only required if data is transmitted using function code CONFIRMED_USER_DATA. A DNP3 device shall treat every device that it communicates with independently. The following applies to each Primary Station–Secondary Station pair. The states and messages between a pair of stations are unrelated to the states and messages between any other pair. When a Secondary Station re-starts or if it loses communication with the Primary Station, the Secondary Station’s link states are unsynchronized. A Secondary Station may not pass confirmed user data (received with primary-to-secondary function code CONFIRMED_USER_DATA) to the higher layers until it has been synchronized from the Primary Station. The Primary Station shall send the RESET_LINK_STATES function code to the Secondary Station prior to communicating using confirmed user data requests. The Primary Station should perform the synchronization after it starts up (reboots), after recovery from a communications failure with the Secondary Station, or when loss of synchronization is detected. The RESET_LINK_STATES function code synchronizes the FCB bit between the Primary Station and the Secondary Station. After completing the reset link states transaction, a Secondary Station shall expect the FCB bit to be 1 in the next message with the FCV bit set. Similarly, after completing the reset link states transaction, a Primary Station shall set the FCB bit to 1 in the next message it sends with the FCV bit set. When a device X transmits a reset link states message to device Y, X is the Primary Station and Y is the Secondary Station. Confirmed communications are only enabled in one direction, from X to Y. Before Y can send confirmed communications to X, Y shall transmit a reset link states request to X. Both X and Y behave as Primary Station and as Secondary Station depending on what services are required by the higher layers. 9.2.6.2

Function code 2

TEST_LINK_STATES

The test link states request is utilized for testing the states of the Secondary Station’s Data Link Layer. Upon reception of this function code by a Secondary Station, it checks the value of the FCB bit in the primary message and compares it against the FCB state it expects from that Primary Station. ⎯ If the FCBs match, the Secondary Station should send an ACK confirm response frame and toggle the expected FCB state from that Primary Station. The Secondary Station sets the DFC bit in the response in accordance with 9.2.4.1.3.5. ⎯ If the FCBs do not match, then the Secondary Station shall send a repeat of the most recent ACK or NACK response frame that it transmitted. ⎯ If the Secondary Station receives a test link states request without there having been a previous link reset states request, it shall either not respond or respond with a NACK with DFC = 0. 9.2.6.3

Function code 3

CONFIRMED_USER_DATA

This function code is utilized for sending user data to a Secondary Station with the requirement that the Secondary Station returns confirmation of the data’s arrival. The frame contains the data provided from the Primary Station’s upper layers (Data Link Layer user). At the Secondary Station, the data from the received frame are passed to the Secondary Station’s user. Before this service can succeed, the Secondary Station’s link states shall be reset as described in 9.2.6.1. Upon reception of this function code by a Secondary Station, it checks the value of the FCB bit in the primary message and compares it against the FCB state it expects from that Primary Station.



⎯ If the FCBss match, the Seecondary Station should sendd an ACK connfirm responsee frame, pass thhe user data to o the higher lay yers, and togg gle the expecteed FCB state fr from that Primaary Station. Thhe Secondary Station S sets thee DFC bit acco ordingly in the response. ⎯ If the FCBss do not match h, the Secondaary Station shoould send an A ACK confirm response fram me, but it does not pass the data d to the hig gher layers, andd it does not ttoggle the expected FCB staate P Station n. The Secondaary Station set s the DFC bit in the responsse in accordancce from that Primary with 9.2.4.1 1.3.5. Devices should not use CONFIRM MED_USER_D DATA when uusing TCP or U UDP over an IP network (seee 13.2.1.1). 9.2.6.4

n code 4 Function

UNCONFIR RMED_USER_ _DATA

This function f code is utilized fo or sending useer data to thee Secondary S Station withouut requiring thhe Secon ndary Station to o return confirrmation of the data’s arrival. The frame coontains the dataa provided from the Prrimary Station’s upper layers (Data Link Layer L user). A At the Secondaary Station, thhe data from thhe received frame are passed to the Seecondary Statio on’s user. This function fu reducees bandwidth reequirements beecause fewer m messages are trransmitted. Thiis is the requireed functio on code when sending paylo oad data to a broadcast b destiination addresss and is the preferred functioon code for f sending all other payload data. 9.2.6.5

Function n code 9

REQUEST_ _LINK_STAT US

The reequest link stattus function is utilized to obttain the status oof the Secondaary Station’s D Data Link Layeer. The Prrimary Station may send this function at an ny time. This fuunction can be used for “Are you there?” annd keep-aalive messagess when the env vironment calls for knowingg that the otherr end is still connected or onnline. NOTE— —When DNP3 is transported ov ver a Network Connection C Mannagement Layer,, the REQUEST T_LINK_STATU US functio on shall be periodically transmittted by both the Master M Station aand the Outstatioon to verify thatt the connection is online and active. Thiss should be man naged independeently for each coonnection. See 113.2.3.3.1 for a description of thhe keep-alive mechanism..

9.2.7

Secondarry-to-primary y function co odes

These function codes apply when the t PRM field is 0 in the headder block contrrol octet. The D Data Link Layyer nses that return n these function n codes never include i user daata blocks. Reffer to 9.2.4.1.3..2. respon NOTE— —The DFC bit is i always set to an a appropriate value (see 9.2.4.11.3.5) in every Secondary Stationn response.

9.2.7.1

Function n code 0

ACK

The Secondary Statiion returns an ACK responsee as a positivee confirmation that the intendded request waas acceptted from the Primary Station. An ACK response is only applicabble to request function codees RESET_LINK_STA ATES, TEST_L LINK_STATES S, and CONFIR RMED_USER R_DATA. 9.2.7.2

Function n code 1

NACK

The Seecondary Station returns a NA ACK responsee as a negative confirmation tthat the request is not accepteed from the t Primary Staation for one off these reasonss: ⎯ The Second dary Station’ss link state is not reset whhen either a pprimary-to-secoondary functioon TEST_LINK_STATES orr CONFIRMED D_USER_DAT TA frame is reeceived with thhe FCV bit set. ⎯ The Second dary Station’s link l is busy.



⎯ The Second dary Station’s Data D Link Layeer receive bufffers are full. A NACK respon nse is only applicable to t request ffunction coddes RESET_L LINK_STATES, TEST_ _LINK_STAT TES, and CONF FIRMED_USE ER_DATA. 9.2.7.3

Function n code 11

LINK_STAT TUS

A Seecondary Stattion respondss with the LINK_STATU US function code when it receives a REQU UEST_LINK_S STATUS from a Primary Stattion. 9.2.7.4

Function n code 15

NOT_SUPP PORTED

The fu unction is utilizzed in responsees returned by the Secondaryy Station when the Primary Sttation requestss a functio on code that is not supported or has not beeen implementedd. Link contrrol variables

9.2.8

A DN NP3 device shaall maintain a separate set of variables forr every devicee with which iit communicatees using confirmed Datta Link Layer services. The minimum m sets are shown in T Table 9-4 andd Table 9-5. Thhe ble names show wn are for illusttration purposees only. variab Ta able 9-4—Primary Station n variables Variable V

D Description

Secondary yStationIsReset

This is a boolean b variable that indicates thhat the Primary S Station sent a RESET_L LINK_STATES frame to the Seccondary Station and received an ACK confirmattion back.

SoftwareO OperatingState

This variaable indicates thee current state inn which the softw ware is operatingg. The states are shown in column c A of Table 9-6.

NFCB B) (Next FCB

The 1 or 0 state of the nex xt FCB bit to be iincluded when ttransmitting a neew primary-tosecondary y frame with the FCV bit set.

Tab ble 9-5—Seco ondary Statio on variables Variable V

D Description

LinkIsResset

This is a boolean b variable that indicates w whether the link w was reset via recceipt of a RESET_L LINK_STATES frame from the P Primary Station..

SoftwareO OperatingState

This variaable indicates thee current state inn which the softw ware is operatingg. The states are shown in column c A of Table 9-6.

EFCB d FCB) (Expected

The state of o the FCB bit ex xpected in the nnext frame from tthe Primary Stattion with the FCV bit set.

9.2.9

Frame errror detection

The reeceiving devicee’s Data Link Layer L shall insspect frames beefore acceptannce and if any oof the followinng condittions are false, discard the fraame. ⎯ The starting g octets shall be 0x05 followeed by 0x64; seee 9.2.4.1.1.



⎯ The destinaation address sh hall match onee of the addressses that the Daata Link Layer is configured to accept; seee 9.2.4.1.4. Addresses A inclu ude the speciaal addresses 00xFFFC throuugh 0xFFFF aas described in n 9.2.5.2. ⎯ The source address shall match one off the addressess that the Dataa Link Layer iis configured to onally choose to accept fram mes from any adddress. accept; see 9.2.4.1.5. A deevice may optio ⎯ Correct CR RC values shall appear at the designated d locaations; see 9.2..4 and 9.2.4.3. ⎯ The frame length l shall maatch the value in i the length fiield; see 9.2.4.11.2. ⎯ Function codes shall co omply with th hose specified for the prim mary-to-seconddary requests in a the secondaary-to-primary y responses in T Table 9-2. Table 9-1 and ⎯ The FCV bit b shall be set s in primary y-to-secondary frames, depeending on the function codde, according to o Table 9-1. 9.2.10 0 Collision avoidance a For sy ystems that require collision n avoidance an nd where the physical mediia does not prrovide it, DNP P3 provid des functionality for collision n avoidance. Many M systems do not requirre collision avoidance, and iits implem mentation is optional. A device d providiing DNP3 colllision avoidaance shall detect whether iits transm mission would occur while another a device is transmittingg. If this weree to happen, thhe transmissionns “collid de” and can caause communiccation errors att the listening ddevice or devices. A device that implemennts collision avoidance shall s delay its pending p messaage communicaation until the cchannel is avaiilable. Devices detect collissions in one of two ways. a))

Detecting carrier existence in the physiccal layer.

b)) Detecting reeception of datta octets. NOTE 1—DNP3 doees not specify the physical layer. Neverthheless, many communications are based oon ysical layers thatt do have carrierrs (modems andd radios are an exxample), the Daata EIA-RS-232-F [B1], and for those phy s may provide an indication n of carrier preseence. Carrierr Detect (DCD) signal NOTE 2—Other physiical layers use base-band techniq ques (EIA-RS-4485-A [B2] and fiber optics are examples) and ddo ve a carrier. A teechnique for dettecting the absen nce of another ddevice transmittiing is to wait unntil no octets havve not hav been reeceived for a con nfigurable amoun nt of time.

A dev vice that is read dy to transmit should wait for f a backoff ddelay time afteer detecting noo other device is transm mitting. The baackoff delay sh hould consist of two parts addded together— —a configurablee fixed time annd a rand dom time: backoff_time = fixed d_delay + rand dom(max_rando om_delay) These times are systtem dependentt and not speciified by DNP33. The backofff timing beginss when no othher devicee transmissionss are detected; this instant may m begin priorr to the device having a message fully readdy for traansmission. The master m shall be given g priority access a to comm munication chaannels by havinng a shorter baackoff_time thaan any off the outstation ns. System ms with multip ple masters can prioritize acceess of those maasters by approopriate selection of parameterrs. NOTE 3—Access to the channel may y be prioritized by b selection of tthe backoff_tim me parameters. P Priority groups aare on of common fixed_delay and d max_random__delay parameteers for all devicces in that grouup. establisshed by selectio Typicaally the backoff_ _time is zero for a master and non n-zero for outstaation devices.



9.3

State tab bles and dia agrams

9.3.1

Primary Station S state requirementts

9.3.1.1

Explanatory stateme ents

This subclause s describes the statee requirements for a Primaryy Station that ttransmits a reqquest to another devicee, the Secondarry Station. Keys for f understandiing Table 9-6 and Figure 9-8 8: ⎯ The tables are a provided to o assist understtanding of the D Data Link Layyer operation bbut do not inferr a specific im mplementation nor completeely describe all conditionss that implem mentations muust consider. ⎯ Columns in n the table are identified by th he letters A throough E. ⎯ Rows in thee table are num mbered from 1 to t 35. ⎯ The circles in the figure represent statees, and the linnes represent trransitions to a new state. Thhe n the lines correespond to the respective r row in the table. numbers on ⎯ Read the tab ble as follows: ⎯ The state machine m waits in one of the states shown iin column A uuntil an event initiates furthher action. 1) The cau use for action (event) ( is descrribed in colum mn B. 2) The acction performed d is described in columns C and D. The aaction in colum mn C, if any, is perform med before sen nding a message with the funcction code speccified in colum mn D. 3) After performing p thee actions in columns c C annd D, the soft ftware transitioons to the staate specifieed in column E. E Column E sp pecifies one off the states listeed under colum mn A. ⎯ NFCB mean ns Next Framee Count Bit. It is the 1 or 0 sttate of the nexxt FCB bit to bee included wheen transmitting g a new primarry-to-secondary y frame with thhe FCV bit set.. ⎯ The ▲ sym mbol indicates that t variable SeecondaryStatioonIsReset is sett to true. ⎯ The ▼ sym mbol indicates that t variable SeecondaryStatioonIsReset is sett to false. ⎯ Except for rows 27 and 28, the table does not show w the behaviorr when the Seecondary Statioon response sets the DFC bit (see 9.2.4.1.3..5). If this happpens, the Primaary Station hass the option of 1) Waiting g a reasonable time before traansmitting useer data. 2) Sendin ng a REQUEST T_LINK_STAT TUS message aand then proceeeding to the i)

UR R-LinkStatusW Wait state if varriable SecondarryStationIsResset is set to falsse.

ii) R-LinkStatusWaait state if state variable SeconndaryStationIsReset is set to true. 3) Setting g variable SecondaryStationIssReset to false and proceedinng to the SecUnnResetIdle statee. ⎯ Where “Imp plementation dependent” d or “Implementatiion dep.” appeears in the tablle, it means thhat the cause for f action is a private reason or that the action to be pperformed is pparticular to thhe software deesign.



UR–LinkStatusWait

ResetLinkWait-2

ResetLinkWait-1

SecResetIdle

SecUnResetIdle

Implementation dependent

Function code 11 (LINK_STATUS) received

0

0

3

0

9

4

3

2

0

9

4

0

D

─

─

RESET_LINK_STATES

─

─

CONFIRMED_USER_DATA

RESET_LINK_STATES

─

─

─

REQUEST_LINK_STATUS


CONFIRMED_USER_DATA

TEST_LINK_STATES

RESET_LINK_STATES

REQUEST_LINK_STATUS


RESET_LINK_STATES

RESET_LINK_STATES

and transmit this function code (with user data if appropriate)


288

Note error (implementation dependent)

Increment retry count

Timeout, no response, retries remaining

Non-11 function code received

▼ Act on failure (implementation dependent)

▲ Set NFCB = 1. ▼

Function code 0 (ACK) received


Timeout, no response, retry count exceeded



▲ Set NFCB = 1. ▼


Non-0 function code received ▼ Act on failure (implementation dependent)

Set retry count = 0

Keep-alive or implementation dep.


─

User request to send unconfirmed data

Set retry count = 0 Set retry count = 0

User request to test link

User request to send confirmed data

Set retry count = 0 Set retry count = 0


─

User request to send unconfirmed data

Keep-alive or implementation dep.

Set retry count = 0

Perform this actiona Set retry count = 0

Cause for action


C


B

A

Action

Table 9-6—Primary Station state table

User request to send confirmed data


Primary Station state table

Current state

9.3.1.2


SecUnResetIdle

SecUnResetIdle

ResetLinkWait-2

SecUnResetIdle

SecUnResetIdle

CfmdDataWait

ResetLinkWait-1

SecUnResetIdle

SecUnResetIdle

SecResetIdle

R–LinkStatusWait

SecResetIdle

CfmdDataWait

TestWait

ResetLinkWait-1

UR–LinkStatusWait

SecUnResetIdle

ResetLinkWait-2

ResetLinkWait-1

and then go to this state

E

Transition to state

19

18

17

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1


─ ─

▼ ▼ ▼ Act on failure (implementation dependent) Increment retry count Implementation dependent Note error (implementation dependent) ▼ Act on failure (implementation dependent) Increment retry count

Function code 1 (NACK) received, DFC = 1

Non-0, non-1 function code received



Function code 11 (LINK_STATUS) received




REQUEST_LINK_STATUS

─

CONFIRMED_USER_DATA

─

─

─

RESET_LINK_STATES

The ▲ symbol indicates that variable SecondaryStationIsReset is set to true. The ▼ symbol indicates that the variable SecondaryStationIsReset is set to false.

9

3

0

▼ Set retry count = 0.

Function code 1 (NACK) received, DFC = 0

TEST_LINK_STATES ─

Increment retry count Toggle NFCB.

─

─

─

REQUEST_LINK_STATUS


2

9

─


▼ Act on failure (implementation dependent)

▼



Toggle NFCB.

D and transmit this function code (with user data if appropriate)

Action

R–LinkStatusWait

SecUnResetIdle

SecResetIdle

SecResetIdle

CfmdDataWait

SecUnResetIdle

SecUnResetIdle

SecUnResetIdle

ResetLinkWait-2

SecResetIdle

TestWait

SecUnResetIdle

SecUnResetIdle

SecResetIdle

UR–LinkStatusWait

SecUnResetIdle

and then go to this state

E

Transition to state

35

34

33

32

31

30

29

28

27

26

25

24

23

22

21

20


289

NOTE—Table 9-6 does not show potential error conditions such as misbehaving Secondary Stations. Implementers are encouraged to incorporate defensive programming techniques to prevent endless looping and other problems.

a

R–LinkStatusWait

CfmdDataWait

TestWait



Perform this actiona


Cause for action


C

Act on failure (implementation dependent)

B

A



Current state



9.3.1.3

Primary Station state e diagram 3 Startup

SecUnReset Idle RettryCount =0

1

18, 19 & 220 4 15 & 1 6

23 & 24 4

11 & 12

URLinkStattus Wait

34

28, 29 & 30

ResettLink Waiit-1

13

2

21

ResetLink Wait-2

14

117 CfrrmdData Wait

31

Test Wait

25

10 5

22

6

7

27

R-LinkStatus Wait

26

SeecReset Idle RettryCount =0

9

35

32 & 33

8

Figurre 9-8—Primary Station s state diagram m 9.3.2 9.3.2.1

Secondarry Station sta ate requireme ents Explanatory stateme ents

This subclause s desccribes the state requirements when a devvice is a Secoondary Station and receives a messaage from anotheer device with the PRM bit seet to 1. See 9.22.4.1.3.2. The so oftware requirees two states fo or proper operaation. a))

UnReset staate: The Secon ndary Station was w re-started, ppower was resttored, or a com mmunication loss with the Priimary Station was w detected.

b)) Idle state: The T software iss idle waiting for fo a message too arrive from th the Primary Staation. The correct DFC sttate is includeed in the link control octet of every respponse returned to the Primarry n. It is not show wn in the tablee. Station If the PRI bit is 0 in n the received request, r no acttion is taken annd no responsee is transmittedd. The PRI bit is o the Primary Station. S These bbits are not shoown in the table. always set to 0 in ressponses sent to



Keys for understanding Table 9-7 and Figure 9-9: ⎯ Columns in the table are identified by the letters A through E. ⎯ Rows in the table are numbered from 1 to 24. ⎯ The circles in the figure represent states, and the lines represent transitions to a new state. The numbers on the lines correspond to the respective row in the table. ⎯ The values in the “Func” columns refer to the function code numbers in the respective received or transmitted link control octet. ⎯ X means don’t care. ⎯ .. (double dot) means consecutively through, or the entire range beginning with the number on the left through the number on the right. ⎯ EFCB means Expected Frame Count Bit. It is the state of the FCB bit expected in the next frame from the Primary Station with the FCV bit set. ⎯ == means is the same as. ⎯ != means is not the same as. ⎯ The ▲ symbol indicates that variable LinkIsReset is set to true. ⎯ Read the table as follows: If the software is currently waiting in the state shown in column A, and a frame is received from the Primary Station with the control octet fields as shown in column B, then perform the action stated in column C, then send a reply frame back to the Primary Station with a function code in the control octet as shown in column D, and go into the reception state specified in column E. Column E specifies one of the states listed under column A.



Idle

X 0

X

X == EFCB

!=EFCB

== EFCB

X 1

0

1

1 0 1 0 1

X X X X X

!=EFCB

0

X

3

2

1, 5, … 8, 10, ... 15

0

9

4

B and a frame is received with link If the software control octet fields state is FCB FCV Func X 0 0 X 1 1, 5, … X X 8, 10, ... 15 X 0 2 X 1 UnReset X 0 3 X 1

A


Secondary Station state table

Current state

9.3.2.2

15 1 15 1

Do nothing. Do nothing. Do nothing. Do nothing. Send request to application parsing routine. Do nothing. Do nothing. Do nothing. Set EFCB = 1. Do nothing.

May optionally not transmit anything. May optionally not transmit anything. May optionally not transmit anything. May optionally not transmit anything.

May optionally not transmit anything.

0

0

15

–

15 0

15

11 15 0 15

Ack.

Ack.

May optionally not transmit anything. Ack. Re-transmit most recent response that contained function code 0 (ACK) or 1 (NACK). May optionally not transmit anything.

May optionally not transmit anything.

Status of link. May optionally not transmit anything. Ack. May optionally not transmit anything.


292

Do nothing. Send request to application parsing routine. Toggle EFCB. Do nothing.

Do nothing.

Do nothing. Toggle EFCB

Do nothing.

15

Do nothing.

Idle

Idle

Idle

Idle

Idle Idle

Idle

UnReset UnReset UnReset Idle Idle

UnReset

UnReset UnReset UnReset UnReset

UnReset

Idle UnReset


and send this reply Comments Ack. May optionally not transmit anything.

E

Transition to state D

Do not transmit anything

Func 0 15

▲ Set EFCB = 1 Do nothing.

then perform this actiona

C

Action

Table 9-7—Secondary Station state table


20

19

18

17

15 16

14

9 10 11 12 13

8

4 5 6 7

3

1 2


a

1 0 1

X X X 9

4

C

11 15

Status of link. May optionally not transmit anything.

Idle Idle Idle

Idle


and send this reply Comments

E

Transition to state D

Do not transmit anything

Func

Action


293

Send request to application parsing routine. Do nothing. Do nothing. Do nothing.

then perform this actiona

The ▲ symbol indicates that variable SecondaryStationIsReset is set to true.

Idle

0

X

B and a frame is received with link control octet fields FCB FCV Func

A



Current state


22 23 24

21


9.3.2.3

Secondary Station state diagram

Figure 9-9—Secondary Station state diagram




10

Layer-inde ependent topics t

10.1

Purpose e of layer-ind dependent topics

The pu urpose of this subclause s is to elaborate on a number of toppics that apply to more than a single layer.

10.2

Confirma ation and re etry guidelines

10.2.1 1 Recomme endations a))

In general, disable Data Link L Layer conffirmations.

Note that t even thou ugh a device does d not requesst data link coonfirmations, itt shall respondd with data linnk confirm mations when requested by another a device. b)) Implementeers should prov vide configurab ble Applicationn Layer fragmeent sizes. This enables the user to set largeer fragment siizes in low noise n environm ments and smaaller fragmentss in high noise environmen nts. c))

Disable App plication Layerr retries in systtems where thee master polls ffrequently.

10.2.2 2 Background 10.2.2 2.1 Data Lin nk Layer conffirms and Ap pplication La ayer confirms s DNP3 has two types of confirmatio ons, Data Link k Layer and Appplication Layeer. A Datta Link Layer confirm appliies when a priimary-to-seconndary Data Linnk Layer fram me is transmitteed with function f code CONFIRMED D_USER_DAT TA. The seconndary is obligaated to return a function codde ACK frame f as confirrmation (assum ming there is no o reason not too). The ack respponse only connfirms receipt oof a singlle Data Link Layer L frame. An Ap pplication Lay yer Confirm ap pplies to an en ntire Applicatioon Layer fragm ment, regardlesss of how manny Data Link L Layer fraames are requirred to transporrt the whole fraagment. The ooutstation requests Applicatioon Layer confirmation of o a fragment by b setting the CON C bit in thee Application L Layer control ooctet. Whenever s it is obligaated to return aan Applicationn Layer confirrm the maaster receives a fragment haaving this bit set, messaage having funcction code CON NFIRM. 10.2.2 2.2 Why con nfirmations are a necessarry Certain operations performed by outstation o devicces require a m mechanism to vverify that the m master correcttly received responses. A classsic example is i the processiing of binary input data chaanges queued in the outstatiion device. Thhe outstattion shall transsmit data to the master statio on in the propeer chronologicaal order so thaat the end user is able to re-create thee real-world sequence s of sttatus changes in the outstatiion. The mechhanism shall bbe mented so that no data is lostt in the transmission process. implem Contin nuing with thee preceding ex xample, an ou utstation devicee may have 100 binary chaanges queued to report to its master station. However, the master station s may reqquest a maxim mum of only 20 in the responsse. utstation uses confirmations c for f determining g whether the m master receiveed the 20 changges so that it caan The ou ⎯ Remove tho ose changes fro om its change queue. q ⎯ Know whatt to return in th he next request.. 295 Copyright © 2012 IEEE. All rightts reserved.



Anoth her use for con nfirmation is to o inform the outstation o that its unsolicitedd Application L Layer fragmennts reacheed the master. Confirmation also assures that t each Appllication Layer fragment in a multi-fragmennt respon nse arrives at th he master beforre permitting trransmission off the next fragm ment. 10.2.2 2.3 Retransm missions When a DNP3 devicce requests either an Applicaation Layer orr a Data Link L Layer confirm mation, it expeccts a within a configurable time. t If the connfirmation is nnot received wiithin this periood, the confirmation to arrive quest is declareed “timed-out,” and the device can either ggive up for thiss transmission or try again, rrethe req transm mitting the exaact same messsage. The num mber of times that devices rretry is often configured to a relativ vely low numbeer, such as 3. Retran nsmissions can n cause synchro onization errorss in the dialog between an ouutstation devicee and a master if one paarty retransmitts when the otther was not expecting e it. Inn particular, thhis can cause collisions in aan enviro onment where polling p is frequ uent. Retries can be used in i some cases, but require carreful consideraation ⎯ In half-duplex systems, itt is possible to o configure poolling intervalss and timeouts long enough to r from a device. How wever, this practice sometimes results in allow for all possible retries g intervals. unacceptablly long polling ⎯ The use of collision c avoid dance in the Daata Link and/orr physical layerrs makes retriees possible. ⎯ Retries are required in the t case of un nsolicited respponses. Even tthough collisioon avoidance is a a matter of course, there is i the possibiliity of losing a master confirm mation messagge necessary as due to noisse or some oth her cause. Outstations shall rrequire confirm mation that thee master statioon received its responses. The successful appllication of rettries using colllision avoidannce techniquess depends on several factorrs. ng the most imp portant are the robustness of the collision aavoidance mechhanism employyed and the loaad Amon on thee communicatio ons channel. Iff the mechanissm is unable too avoid a collission, retries maay aggravate thhe situation by causin ng more collissions and thu us significantlly reduce the effective banndwidth of thhe munications chaannel. comm As witth any communications systeem, the designeer should pay ccareful attentioon to bandwidtth allocation annd manag gement for a successful sy ystem design. In particular, overloading communicatioons circuits haas undesiirable effects on system peerformance. In n a frequentlyy polled confiiguration, oveerloaded circuiits elongaate polling cy ycles (e.g., deecrease scans per second). In an unsoliccited responsee configuration, overlo oaded circuits can c render resp ponse times non n-deterministicc during periodds of peak activvity. 10.2.3 3 Discussio on 10.2.3 3.1 Why App plication Lay yer confirms are preferre ed 10.2.3 3.1.1

Data Link Layer confirms c are e redundant

The daata returned in many outstatio on responses fit fi into a single Data Link Layyer frame. Thiss results in there being one Data Link k Layer frame for f each Application Layer m message. Becauuse outstationss are required bby t request an Application Layer L confirma mation for critiical data, a D Data Link Layyer the prrotocol rules to confirm mation is redun ndant. 10.2.3 3.1.2

Band dwidth

Assum ming that every y Data Link Laayer frame con ntains the maxiimum 292 octeets, then the 100 octets requireed for Daata Link Layer confirmation n account for only 3.3 perceent of the trannsmission timee. However, thhe percen ntage increasess dramatically when w latenciess in the channeel (such as proppagation delayy and request-too296 Copyright © 2012 IEEE. All rightts reserved.



send, clear-to-send timings) are included, and when the message size decreases. For example, at 9600 baud, with 32 octets of user data, and channel latency of 15 milliseconds, the confirmation message consumes 29 percent of the bandwidth. 10.2.3.1.3

Assures understanding not just reception

Application Layer confirmations verify that properly assembled messages arrive at the master and that the master’s Application Layer understands the data that it received. Data Link Layer confirmations only assure that Data Link Layer frames arrive without bit errors. For critical data, arrival with no bit errors is insufficient justification to delete the information from an outstation’s event queues. 10.2.3.1.4

Noisy environments

Smaller packet sizes are recommended when bit error rates are high. In high bit-error-rate (noisy) environments, the probability of one or more bit errors appearing in a packet increases as the packet size increases. Conversely, the smaller the packet size, the lower the probability of an error occurring in a packet. The original belief was that it would be better to accept the overhead of confirming each Data Link Layer frame of a multi-frame message, and re-transmit corrupted frames, than to re-send an entire Application Layer fragment. However, there is another alternative—reduce the fragment size and use only Application Layer confirmations. When fragments are reduced to the size of a Data Link Layer frame, the overhead of Application Layer confirmations, and the probability of noise corrupting those confirmation messages, is nearly the same as for Data Link Layer confirmations. NOTE—There is a limit to reducing the size of an Application Layer fragment. Its size should be large enough to hold entire DNP3 objects—objects may not be divided between fragments. Refer to Clause 4 through Clause 6 of this standard.

10.2.3.2 Retries and polling 10.2.3.2.1

Media access control

Use of outstation Application Layer and Data Link Layer retries are discouraged in frequent polling environments. When an outstation device requests a confirmation from the master and does not receive it, the outstation should wait for the next master request to send the information again. The reason is that it is highly likely the master has moved on to poll the next outstation in its list, and if the remote device were to retry, there is a high probability of a collision with the master’s request message or the other outstation’s response. Even in the case where there is a single outstation, the outstation device could retry while the master is sending the next request to this outstation. In a polling environment, each master request can be viewed as an invitation for an outstation device to transmit data on the shared communications circuit. The master controls which device can transmit so that collisions do not occur, and the timing of responses is predictable under all situations. Masters can ask again if a response is not received, and this provides an opportunity for the outstation to re-send its data. Thus, a master effectively manages access to the media if it does not have to contend with outstations unexpectedly transmitting on their own. 10.2.3.2.2

Unsolicited responses

Retries are a requirement when unsolicited responses are used. Unsolicited data is by definition not expected by the master, and therefore the master does not know to request the data it is missing. The burden is therefore on the outstation to verify that data gets through.




10.2.3 3.3 Exceptio ons Despitte the recommeendations in 10 0.2.1, there are times when D Data Link Layerr confirms are useful. ⎯ Certain dev vices (especiallly older devicces) are unablee to receive uunconfirmed D Data Link Layyer frames back k-to-back. ⎯ Experience has shown thaat communicatiions are more dependable in some environm ments where thhe ming, and otheer circumstancces make Dat ata Link Layeer confirmationns noise charaacteristics, tim successful. Thereffore, Master and a Outstation n device desig gns should havve the ability to request D Data Link Layyer confirm mation, and th hey should haave a configurrable means oof enabling annd disabling thhis feature (i.ee., choosiing to send user data witth CONFIRM MED_USER_D DATA or UNCONFIRMED D_USER_DAT TA functio on codes). Wh hether a devicce always, nev ver, or sometiimes (e.g., onlly when confiigured, only fo for certain n messages) reequests data lin nk CONFIRM frames shall bbe documentedd in the Devicee Profile for thhe devicee.

10.3

Time syn nchronization

10.3.1 1 General DNP3 outstation dev vices are often required to tim me tag events tto the nearest m millisecond, annd some devicees quired to automatically freezze accumulato ors or perform some activityy at specific tim mes. In order to are req supporrt these time-related activitiees, an outstatio on shall have a dependable tiime source. It may use a loccal sourcee, such as a GPS G receiver, or it can requ uest time synnchronization ffrom the mastter using DNP P3 messaages. An outstaation with acceess to, and usin ng, an accuratee local time souurce may chooose not to set iits curren nt time with th he time that itt receives in a time synchroonization messsage from the master, but thhe outstattion shall reply y as if it had seet its local time from the time in the message. 10.3.2 2 Time base e DNP3 time correspo onds to Universsal Coordinated d Time (UTC)..28 UTC does d not shift with daylight saving (summer) time and ddoes not changge depending oon the local tim me zone. Thus, events that occur at seeparate geograp phical locationns, but at the ssame instant, arre reported with identiccal DNP3 timee values. UTC, and thereforee DNP3 time values, are adjusted a approopriately whenn leap-secondds are added oor me subtraacted by the Intternational Earrth Rotation Seervice (IERS)299 so that UTC agrees with asstronomical tim based on the rotation n of the earth. Values within DNP3 3 time objects contain c the num mber of milliseeconds from thhe DNP3 time epoch, which is defineed as 1970-01-0 01T00:00:00.00030 UTC. Thee DNP3 time eepoch assumes there were exaactly 86 400 0000 milliseeconds in every y day during th he intervening years (i.e., it ddoes not includee leap-secondss). DNP3 cannot represent times that occur o within th he 1000 milliseecond period w when a leap-seccond is added to e to co ontinue countiing milliseconnds as usual dduring periods of leap-seconnd UTC. Devices are expected ments until th he outstation is re-synchron nized. There m may be an unncertainty in tthe DNP3 tim me adjustm measu urement during g this interval, and a time stamp ps recorded in tthat period mayy be in error.

28

The effective e date for using u the UTC timee base is 1 January y 2008. Prior to thiis date, DNP3 did not require a speccific time referencee. http:///www.iers.org/. 30 The date d format is YY YYY-MM-DDThh:mm:ss.sss where ss.sss represents seconds and milliiseconds and wheere a capital letterr T separatees the date and tim me fields. This notaation conforms to ISO I 8601 [B10]. 29




As an example of a DNP3 time computation, c co onsider that thhe correctly coomputed DNP33 time value fo for 01-01T00:00:0 00.000 UTC is 0x011732A5C C400. 2008-0 NOTE— —DNP3 transm mits time values least significant octet o first as 00 C C4 A5 32 17 01.

The eq quivalent decim mal number is 1 199 145 600 000. IERS added 23 leap-seconds between 197 70 and 20088. Because oof the addedd leap-secondds, m acctually elapsed between the sstart of 1970 annd the start of 2008. Howeveer, 1 199 145 623 000 milliseconds t the simplifieed rule that eveery day containns 86 400 000 milliseconds, the DNP3-tim mein order to conform to nversion negleects these leap-seconds. In thhe same way, DNP3 time sshall ignore anny to-caleendar-time con future leap-second ad djustments of UTC. U For an nother examplle, the correcttly computed DNP3 D time vaalue for 1998-01-01T00:00::00.000 UTC is 0x00C CDBB6D5400 (decimal 883 612 800 000). IERS added tw wo leap-seconnds between Jaanuary 1998 annd Januarry 2008; howeever, comparisson of the DN NP3 time valuues shows a ddifference of 3315 532 800 0000 milliseeconds, demon nstrating that DNP3 D time doess not include thhese leap-seconnds. 10.3.3 3 Messages s for time syn nchronizatio on When an outstation anticipates thaat its timing reference (such as a crystal osscillator) may ddrift beyond thhe d accuracy, it should set the IIN1.4 [NEED D_TIME] bit iin responses. T The master shaall send the tim me needed promp ptly after receiv ving a responsee with this bit set. s NOTE— —Outstations th hat set the IIN1 1.4 [NEED_TIM ME] bit at unreaasonably short intervals could adversely impaact system m operation by deedicating a disproportionate amo ount of processinng to non-data coollection activitiies.

10.3.3 3.1 Non-LAN N procedure Figure 10-1 shows the sequence and a relative tim ming of messaages used to tiime synchronize an outstatioon t master. Tw wo separate req quest messagess are transmitteed from the maaster, delay meeasurement annd from the write. The first meassures the propaagation delay in n the physical layer and the ssecond sends thhe time that it is n the message arrives a at the ou utstation. expectted to be when There are seven crittical time pointts in the sequeence. Letters innside square bbrackets [A] through [G] shoow these. These pointss, except [G], are the times when the leeading edge oof the start bit either beginns mission over th he physical meedia or is detecctable at the rreceiving end. This would bee in the startinng transm 0x05 octet o in the Datta Link Layer frame. f [G] reprresents the tim me when the cloock is set.




Master Application Layer

Data Link Layer

Outstation Physical Media

Phys Layer

Phys Layer

Data Link Layer

Application Layer

[A] DELAY_MEASURE Request

[B] [C]

Response to DELAY_MEASURE

Time [D]

[E]

WRITE Request [G] [F]

Set Clock

Response to WRITE

Figure 10-1—Timing of non-LAN time synchronization The steps for time synchronization are as follows: a)

The first request message sent from the master uses function code DELAY_MEASURE. The master records the exact instant when the leading edge of the start bit of the first octet in the transmitted request message leaves the master device. This is critical time point [A] in the diagram.

b) The outstation records the time at the instant when the leading edge of the first start bit is detected. This is critical time point [B] in the diagram. c)

The outstation needs to formulate a response containing a single Fine Time Delay DNP3 object, group 52, variation 2. The Fine Time Delay object holds the outstation processing delay that is the time difference, in milliseconds, from critical time point [B] to critical time point [C]. In order to formulate such a message, the outstation shall either 1) Anticipate when [C] will occur (using a guaranteed time of transmission or other technique). 2) Dynamically create the response message on the fly.

d) The master shall record the exact instant when the leading edge of the start bit of the first octet in the received response message arrives at the master device. This is critical time point [D]. e)

The master calculates the propagation delay time as follows: 300 Copyright © 2012 IEEE. All rights reserved.



(Time at [D] – Time at [A] – outstation processing delay) / 2. f)

The master transmits a message with an Absolute Time and Date object, group 50, variation 1, having a value that is the time that it will be at critical time point [F]. This requires the master to add the propagation delay time computed in step e to the true time at critical time point [E]. In order to formulate such a message, the master shall either 1) Anticipate when [E] will occur (using a guaranteed time of transmission or other technique). 2) Dynamically create the response message on the fly.

g) The outstation shall record the exact instant when the leading edge of the start bit of the first octet in the received write request message arrives at the outstation device. This is critical time point [F]. h) The outstation sets its internal clock using the time in the write request and knowing the difference in time between critical time points [F] and [G]. Critical time point [G] is the instant when the clock is set. The outstation’s time is calculated as: Time in request + (Number of milliseconds from [F] to [G]) NOTE—The designers of masters and outstations should consider that there can exist internal delays caused by the operating system and other issues. Furthermore, in systems where the clear-to-send signal from a modem controls when transmission begins, this timing can be imprecise. It is important to accommodate these variables when accurate time synchronization is mandatory.

i)

The outstation sends a response.

10.3.3.2 LAN procedure Figure 10-2 shows the sequence and relative timing of messages used to time synchronize an outstation from the master. Two separate request messages are transmitted from the master, record current time and write. The first requests the outstation to record the time of receipt of the last octet in the message, and the second sends the time that the message should have arrived at the outstation.




Figure 10-2—Timing of LAN time synchronization A different method is used for time synchronization over a LAN than is used in non-LAN applications. The reasons are that the propagation delay measurement is negligible and that recording the time at the first bit of the first octet does not account for network collisions. NOTE 1—It is not practical to perform time synchronization over IP routers and gateways as their delays are inconsistent and vary with network loading.

There are three critical time points in the sequence. Letters inside square brackets [A] through [C] show these. [A] represents the instant when the last message octet has left the Ethernet hardware, and [B] represents the instant when the last octet of the message is received in the Ethernet hardware. The last octet is the second octet of the last CRC value in a Data Link Layer frame. [C] represents the instant when the clock is set. The steps for time synchronization are as follows: a)

The master sends a message having function code RECORD_CURRENT_TIME. The master records the time when the last octet leaves the Ethernet hardware. This is critical time point [A] in the diagram.

b) The outstation records the time (or starts a timer) when the last octet of the request arrives in its Ethernet hardware. This is critical time point [B] in the diagram.




c))

The outstatiion sends a nulll response.

d)) The master sends a messaage having fun nction code W WRITE with a L Last Recordedd Time and Daate up 50, variation n 3. The value in this object contains the tim me that the maaster recorded in object, grou step a). e))

The outstatiion sets its inteernal clock usin ng the time in tthe write requeest and knowinng the differencce in time betw ween critical time t points [B B] and [C]. Criitical time poinnt [C] is the innstant when thhe clock is set.. The outstation n’s time is calcculated as: Time in req quest + (Numb ber of millisecoonds from [B] tto [C])

f)

The outstatiion sends a nulll response. IIN N1.4 [NEED_T TIME] should bbe cleared in thhis response.

A masster should tran nsmit the writee request messsage soon afterr the record cu urrent time reqquest, the closer the better; however, intervening meessages are perrmitted. Outstaations shall be prepared p to recceive and proceess other mess ages, from the same master oor from different masterrs, which arrive between the first and secon nd time synchroonization messsages. If an outstation recceives anotherr record curreent time messsage without an intervening write requeest ginal recorded d time and savve the newer time from thee most recenttly messaage, it shall diiscard the orig received record currrent time message. This procedure p may use broadcastt messages to synchronize s m multiple outstatiions simultaneeously since it is assum med that the reccord current tiime and write messages are received by alll of them at thhe same instannt. The master m uses UDP to send the broadcast b datag gram. Outstatioons do not resppond to broadcaast messages. NOTE 2—This proceedure requires that t the Etherneet driver providde the ability tto record the laast octet time oon mission and receiive. Processor sp peed, interrupt latencies, Interneet protocol stackk design, and soo on greatly affeect transm the tim me synchronizatio on process. Timee accuracy to wiithin a milliseconnd is not possiblle without this caapability. NOTE 3—If a master or o outstation dev vice cannot reco ord time at the Etthernet driver, itt should do so ass close as possibble nterface. This in ntroduces an errror factor in the synchronizationn process. A deevice may wish to to the Internet stack in minimiize this error by adding a predettermined bias vaalue that reflectss an average dellay through the Internet stack annd Ethernet driver. This compensation factor f does not take into accouunt the delay caaused by Ethernnet collisions annd retransmission; however, it may reducee the average errror to a level thaat can be tolerateed in the system.

10.3.4 4 Time sync chronization retries 10.3.4 4.1 Requirem ments Masters and outstatiions shall not retry time syn nchronization messages at eeither the Application or Daata L These messages m apply y to those having Applicationn Layer functioon codes: Link Layers. ⎯ DELAY_M MEASURE req quest from maaster and corrresponding ressponse (RESPONSE functioon code) from outstation. ⎯ RECORD_CURRENT_T TIME requests from f master. ⎯ WRITE req quests from maaster with an Ab bsolute Time oobject, group 550, variation 1. ⎯ WRITE req quests from maaster with a Lasst Recorded Tim me object, grooup 50, variatioon 3. Both master m and outtstations shall transport t time synchronizatioon messages ussing Data Linkk Layer functioon code UNCONFIRM U ED_USER_DA ATA.




If a master does not receive the expected response on the first try, it shall send a new request and not retry the message. New requests have a different sequence number in the application control octet of the application header and cause the response content to be re-generated. The following subclauses explain why these requirements are necessary. 10.3.4.2 Justification for non-LAN applications A master sends the time via a write (function code WRITE) with object group 50, variation 1 to the outstation. The outstation records the time when the first bit of the first octet is received and returns a null response. Here is what happens when the master sends a repeat Application Layer fragment with the same time as in the original transmission. If the outstation misses the original transmission, but receives the repeated message, the outstation will set its time incorrectly. This is because the time in the repeated message specifies what time the first bit of the original message should arrive at the outstation; it does not specify what time the first bit of the repeated message should arrive. The master can erroneously compute the time delay in the communication channel when a retry happens while sending a request to measure the delay (function code DELAY_MEASURE). If the request does not arrive at the outstation on the first try but does on the second, then when the response returns from the outstation, the master would incorrectly compute the time for the round trip by using the time when it sent the first try as a reference. In another scenario, the outstation receives both requests to measure the channel delay, but its first response does not arrive at the master. Upon receipt of the retried request, the outstation simply repeats its first response. However, this would be incorrect if the time required for the outstation to process the message varies from message to message—typical of multi-tasking software. The value in the returned Time Delay Fine object would not represent the true outstation processing time for the retry, consequently causing the master to compute the channel delay time incorrectly. Based on similar logic, it follows that repeated Data Link Layer frames can also affect time computations. 10.3.4.3 Justification for LAN applications A problem can occur when a master sends a repeat of an Application Layer function code RECORD_CURRENT_TIME message. The master records the time upon sending the original transmission. If the outstation misses the original transmission, but receives the repeated message, the outstation will calculate an erroneous new time upon receipt of the follow-up write request having a time object (group 50, variation 3). This is because the outstation bases the computation on the repeated message and the master bases the time on the original. Another error condition can occur when the master records the current time in the original message and then re-records the current time in the repeated record current time message. If the outstation receives the first transmission but its response does not arrive at the master, and the master sends a repeat request to record the time, the outstation will not process it. Then subsequently when the master transmits the write request with the time object (group 50, variation 3), that time is with respect to the repeated message and not to the original message that the outstation used to record its time. Again, based on similar logic, it follows that repeated Data Link Layer frames can also affect time computations. NOTE—Ethernet retransmissions are not considered retries because they are not a part of the DNP3 protocol. They do, however, limit the accuracy of the time synchronization scheme.




10.4

Handling g multiple messages m

In DN NP3, reception frequently inv volves more th han a single seet of request orr response octets. Devices aare permittted to transm mit two messaages consecutiv vely without an interval beetween them. This subclause provid des requiremen nts for handling g multiple messsages, or mulltiple parts of a message, andd discusses hoow these situations s can occur. o 10.4.1 1 Requirements ⎯ Rule 1: Maasters shall be able to receivee a minimum oof one more thhan the total of all of the Daata Link Layer frames necesssary for a maxiimum-sized Ap Application Layyer fragment w without requirinng a gap betweeen Data Link Layer frames. To evaluate thhis requirementt, transmit the application daata from the ou utstation using Data Link Lay yer function codde UNCONFIR RMED_USER R_DATA. ⎯ Rule 2: Ou utstations shall be able to reeceive an Appplication Layeer confirm (Appplication Layyer CONFIRM function cod de) immediateely followed bby an Appliccation Layer rrequest without requiring a delay betweeen them. To evaluate this reequirement, traansmit the Appplication Layyer from the the Data Link Layer ffunction codde master ussing confirm RMED_USER R_DATA. UNCONFIR 10.4.2 2 Back-to-b back confirma ation and req quest/respon nse Back-tto-back Data Link L Layer fram mes can happeen when, for exxample, a mastter sends an Appplication Layyer requesst to the outstaation using a Data D Link Lay yer frame withh the CONFIRM MED_USER__DATA functioon code. The outstation n shall return a Data Link co onfirm frame ffollowed immeediately by a D Data Link Layyer L responsee data. In outsttations with fasst processors, iit is possible fo for frame containing thee Application Layer t be no gap occcurring between the transmittted frames. there to Back-tto-back Appliccation Layer frragments can happen h when ann outstation seends event dataa. The outstatioon shall request r the master to return Application A Laayer verificatioon that the messsage arrived. T The master maay transm mit the confirm mation (using th he CONFIRM Application A Laayer function ccode) immediattely followed bby anotheer request— —both messages being transmittedd using the Data Link Layyer UNCO ONFIRMED_U USER_DATA function code. Thus, both masters and a outstation devices shall be b prepared to receive back-to-back messaages without anny g separating g messages. time gaps 10.4.3 3 Back-to-b back without confirmation n Outstaations can send d Application Layer L fragmentts that require m more than one Data Link Layyer frame. A fuull Appliccation Layer frragment having g a size of 204 48 octets requiires nine framees, assuming m maximum length framess. DNP3 does not specify th he time between frames; theerefore, masterrs shall be preepared to accept multip ple Data Link Layer framess, one-after-thee-other, when the outstationn does not reqquest Data Linnk confirm mation. 10.4.4 4 Multi-drop p communica ations In som me communicaation systems, outstations arre able to receeive octets froom the master station and thhe respon nses from otherr outstations. Thus, T with fast processor devvices in the systtem, the masteer station requeest messaages and outstaation responsee messages maay abut each oother with litttle or no gapss between them m. Althou ugh there is not a specific DNP3 D requirem ment for this ssituation, outsstations shouldd be prepared to receive multiple Datta Link Layer frames, f withoutt intervening ggaps, addressedd to itself and to other devicess.




10.4.5 5 Unsolicite ed responses s Masters that supporrt unsolicited responses r shalll be prepared to accept meessages at randdom times from ple outstations.. Furthermore, masters shall anticipate thatt an unsolicitedd response cann arrive from aan multip outstattion while the master is waiting for a sollicited responsse to a requestt it sent to anoother outstation. Software shall be deesigned to prop perly process Application A Layyer fragments, Transport Funnction segmentts, y arrive. and Data Link Layerr frames as they




11

Data objec ct library—basics

11.1

Overview w

DNP3 uses objects to communicaate values and information bbetween devicees. An analog input point, fo for ple, has a valu ue and may hav ve other attribu utes such as w whether that vaalue exceeds thhe measurement examp range. In order to traansport the valu ue and attributtes, a standardiized way to reppresent this infformation withhin D so that receivers r know w how to interppret the messagge contents. D DNP3 uses grouup a messsage exists in DNP3 numbeers to categorizze the data typ pe, and generallly, it uses variiation numberss to specify hoow the data from 31 within n the group is encoded. e Each h instance of an a encoded infoormation elemeent, defined byy a unique grouup and vaariation within n the message, is called a DNP3 D object. Point index nnumbers differrentiate multipple instances of DNP3 objects o of the saame type. The DNP3 D Object Liibrary containss a description and encoding for all of the D DNP3 objects. T The library doees not sp pecify anything g about the physical p devicees that are reppresented by tthese objects. Subclause 11.9 provid des description ns of various point types and a guidance for choosing objects. A D DNP3 vendor is generaally free to sellect which DN NP3 object is used u to represeent each of thee tangible item ms. Neverthelesss, there are guidelines specified in the t standard DNP3 D implemeentation levelss and industryy norms that are de the scope of this document. outsid

11.2

Library documentat d tion organiz zation

The DNP3 D Object Liibrary documen ntation is organ nized into two parts: ⎯ This clausee contains gen neral informatiion and the ruules needed too interpret the objects. It alsso contains definitions and descriptions d thaat are common to all or manyy of the objects. ⎯ Annex A co ontains descrip ptions of the individual DNP33 objects.

11.3

Primitive e data types s

11.3.1 1 Summary of types The fo ormal definitio on of object grroup and variaations depends on primitive data types thaat are commonnly known n to software developers. d A list l of the typess and a brief deescription appeear in Table 11-1. Subsequent paragrraphs describe the types in deetail. Table 11-1— —Primitive da ata types Basic B data type BS STRn UIN NTn INTn FL LTn BC CDn VS STRn OS STRn SE ET of n VA ARIANT UN NCDn

31

Brief desccription nn bit bit string. nn bit unsigned in nteger. nn bit signed integ ger. nn bit floating-poiint, formatted peer IEEE Std 754™ ™. nn BCD characteer binary-coded decimal. d nn octet printable ASCII text strin ng, not null-term minated. nn octet octet strin ng. n sets where each h set is similarly constructed of a sequence of otther basic data tyypes. The T basic data type depends on th he specific objecct instance. nn octet Unicode UTF-8 U string, no ot null-terminateed.

Theree are some situations where the variaation specifies morre information thann just the data form mat.




11.3.2 2 Numeric notation n conventions This su ubclause discu usses how vario ous numeric vaalues are expreessed in the librrary. 11.3.2 2.1 Decimal values Decim mal values use the t digits 0 thro ough 9 and maay include a siggn. Examples aare 20, –245, + +7, and 12 345. 11.3.2 2.2 Binary-c code decimal values Binary y-coded decim mal values use the digits 0 th hrough 9 and m may have a siggn. The suffix,, bcd, is used to explicitly identify a value v as being the BCD type. Examples aree 0341bcd, –011991bcd, and 9999999bcd. 11.3.2 2.3 Hexadec cimal values Hexad decimal valuess use the digiits 0 through 9, and the leetters A througgh F, in eitheer uppercase oor lowerccase. All hexad decimal valuess are preceded d with the charracter pair 0x. Examples are 0x3C, 0xF7A A5, and 0x x5D40F790. 11.3.2 2.4 Binary values v Binary y values use the digits 0 and 1 and have the suffix letter b.. Examples aree 0110b, 0b, annd 1100b. 11.3.2 2.5 Floating-point values s Floatin ng-point valuees are expresseed in one of tw wo ways. The first uses the digits 0 throuugh 9, a decim mal point, and may incllude a sign. Examples E are 25.6, –195.23 , 0.0, and +78841.01. The ddecimal point is mandaatory. The seecond method uses u scientific notation and taakes the form oof a mantissa ffollowed by an exponent stateed as a power of ten. The T mantissa uses the digits 0 through 9, a decimal pointt, and may incllude a sign. Thhe mal point is maandatory. The exponent e begin ns with the lettter E, in eitheer uppercase orr lowercase. A An decim option nal sign followss the E and thee digits 0 throug gh 9. Examplees are –25.11E––2 and 1.037 6625 148E12. 11.3.3 3 Bit strings s Bit strring fields or values v use the notation n BSTR Rn, where n reppresents the nuumber of bits inn the string. Foor examp ple, BSTR7 hass seven bits. Bit strings are ex xpressible withh binary valuess such as 1100110b. The righhtmost bit b of the string g corresponds to t the least sign nificant bit of tthe binary valuue—zero in thee example giveen in the preceding senttence. When bit strings app pear in an octeet, the least sig gnificant bit o f the string occcupies the low west bit positioon n the field. Heere are two exaamples, one where w the fieldd begins in thee octet’s bit 0 and the seconnd within where the field begin ns in the octet’’s bit 3. A BST TR4 having a vvalue of 1100bb is illustrated iin the shaded bbit positio ons. 7

7

6

5

4

3

2

1

0

1

1

0

0

2

1

0

6

5

4

3

1

1

0

0

← bit position

← bit position




Long bit strings wrap into subseq quent octets beginning in thhe lower bit positions. The next illustratioon ving a value off 10111100001 1010b in the shhaded bit positiions. Two octeets are requiredd. showss a BSTR14 hav octeet transmission n order ↓ 7 6 5 4 0

0

0 1

0 0

3

2

1

0

1 1

0 1

1 1

0 1

← bit position

Anoth her example sh hows a BSTR18 having a vallue of 110011 1111000010100b in the shadeed bit positionns. The field begins in bit b 2 of the firstt octet and conttinues into the third octet. octeet transmission n order ↓ 7 6 5 4 0 1

0 1

1 1

0 1

3

2

1

0

1 1 1

0 1 1

0 0

0 0

← bit position

11.3.4 4 Unsigned and signed integers Unsign ned integer fieelds or values use the notatiion UINTn, w where n represeents the numbeer of bits in thhe integer. For examplee, UINT32 den notes a 32-bit unsigned inteeger. Signed innteger fields orr values use thhe on INTn, wherre n represents the number off bits in the intteger includingg the sign bit, w which appears in notatio bit possition n – 1. Fo or example, INT16 specifies a 16-bit signedd integer. The ch haracteristics of o signed and unsigned u integeers are: ⎯ Unsigned in ntegers always have a positiv ve value that ran anges from 0 too 2n – 1. ⎯ Signed integers are expresssed as a twos--complement vvalue that rangees from –2(n-1) tto 2(n-1) – 1. ⎯ Unless otheerwise specifieed on an objeect descriptionn in Annex A A, integers reqquire an integrral number of 8 bits. Thus, ty ypically the ob bjects state them m as INT16, IN NT32, UINT16, UINT32, annd UINT48. ⎯ Unless otheerwise specifieed on an objecct description in Annex A, integers are trransmitted littleendian stylee; that is, the leeast significantt octets are trannsmitted first, aand the most ssignificant octeets are transmittted last. ⎯ Unless otheerwise specifieed on an objecct description in Annex A, the least signiificant bit of aan integer occu upies the bit 0 position in an n octet, and thee most significcant bit of an iinteger occupiees the bit 7 position in an octtet. This is an n example of a 16-bit 1 signed integer having a vaalue of –22 000 ffollowed by a 322-bit unsigned integer having h a value off 4 000 000 000.

EX 11-1

octet o transmisssion order ↓ 5 4 7 6 0 b15 b 1 0 0 0 b31 b 1

0 0 0 0 1 1

0 1 0 1 1 1

1 0 0 0 0 0

3

2

1

0

0 1 0 1 1 1

0 0 0 0 0 1

0 1 0 0 1 1

0 0 0 0 1 0

← bit position b00 INT16 vaalue = –22 000 b00 UINT32 vvalue = 4 000 0000 000




Noticee that the first and a last bit of each e value is sh hown in the prreceding figuree. b0 is the leasst significant bit, and b1 15 and b31 are the most signiificant bits. 11.3.5 5 Floating-p point values Floatin ng-point valuees use the nottation FLTn, where w n repressents the num mber of bits inn the value. Foor examp ple, FLT32 denotes a 32-bitt floating-pointt value. DNP33 uses two flooating-point forrmats, and eacch type has h a name. ⎯ FLT32 form mat is called flo oat or single-prrecision or shoort floating-poinnt. ⎯ FLT64 form mat is called do ouble-precision n. NOTE— —Early DNP3 documentation referred to FLT T64 as a “long ffloating-point.” This was changged to conform to commo on programming g practices.

Floatin ng-point numb bers are constru ucted in conforrmance with IE EEE Std 754. T The basic formaat is: 1.*2 where the sign, manttissa, and biaseed exponent vaalues are obtainned from speciffic bit fields ass shown: ⎯ FLT32 valu ues are formatteed as 31 Sign

30

23

Biaased Exponent

22

0

← bit posittion

Mantissa

A sign n bit of 0 repressents a positivee number, and a 1 in the signn bit position sppecifies a negattive value. The mantissa m is a 23-bit value. Theere is an implieed 1 and a binaary point to the left of bit 22. The exponent e is a power of two o. The true ex xponent is obttained by subttracting 127 ffrom the biaseed expon nent. The legal ranges of the biased b exponen nt are 1 to 254 , correspondinng to true exponnents of –126 to +127. This leaves tw wo special case biased exponeent values of 0 and 255. When the biased exp ponent is 255 and the mantissa is all zeross, this represennts ±infinity deepending on thhe sign bit. b When the biased b exponen nt is 255 and the t mantissa iss not zero, theen this represennts NAN, not-anumbeer. When the biased exp ponent is 0, thee mantissa reprresents a de-noormalized num mber. The impliied 1 in the 24th bit dissappears and th he value is less than 2–126. ⎯ FLT64 valu ues are formatteed as 63 Sign

62

52

Biaased Exponent

51

0

← bit posittion

Mantissa

A sign n bit of 0 repressents a positivee number, and a 1 in the signn bit position sppecifies a negattive value. The mantissa m is a 52-bit value. Theere is an implieed 1 and a binaary point to the left of bit 51. The exponent is a power p of two. The true exp ponent is obtaained by subtrracting 1023 ffrom the biaseed expon nent. The legal ranges of the biased b exponen nt are 1 to 20446, correspondiing to true exponents of –10222 to +10 023. This leavees two special case c biased exp ponent values oof 0 and 2047.




When the biased exp ponent is 2047 7 and the mantiissa is all zeroos, this represennts ±infinity ddepending on thhe b When the biased b exponen nt is 2047 and the mantissa iis not zero, theen this represennts NAN, not-asign bit. numbeer. When the biased exp ponent is 0, thee mantissa reprresents a de-noormalized num mber. The impliied 1 in the 53rrd bit dissappears and th he value is less than 2–1022. ⎯ FLT32 valu ues are capablee of expressing numbers betw ween 0 and ±3.44 × 1038. ⎯ FLT64 valu ues are capablee of expressing numbers betw ween 0 and ±1.77 × 10308. ⎯ Unless otherwise specifiied on an objject descriptioon in Annex A, floating-ppoint values aare transmitted little-endian style; that is, th he least significcant octets are transmitted firrst, and the moost o are transsmitted last. significant octets ⎯ Unless otheerwise specified on an objeect descriptionn in Annex A A, the least siignificant bit oof floating-poiint value occu upies the bit 0 position in aan octet, and the most signnificant bit of a floating-poiint value occup pies the bit 7 po osition in an occtet. EX 11-2

This is an n example of a FLT64, F double-prrecision, floatingg-point value haaving a value of –2.325 88 89 034 4e+03.

octet o transmisssion order ↓ 5 4 7 6 0 0 1 0 1 0 1 b63 b 1

1 1 0 1 0 1 1 0

0 1 0 0 1 0 0 1

0 1 0 0 0 0 0 0

3

2

1

0

0 0 0 1 0 1 0 0

0 1 1 1 1 0 0 0

0 0 0 1 1 1 1 0

0 0 1 1 1 1 0 0

← bit position b00

FLT64 vaalue = –2.325 8889 034 4e+03

Noticee that the first and last bit of the value is sh hown in the preeceding figure. b0 is the leasst significant bit, and b6 63 is the most significant s bit. The exponent bit positions aare shaded for vvisual referencce. 11.3.6 6 Binary-co oded decimall Binary y-coded decim mal values use the notation BCDn, B where n represents thhe number of B BCD characterrs. For ex xample, BCD8 requires 8 BCD characters. 11.3.6 6.1 Coding practice p Each BCD B characterr requires 4 bitss and is coded as in Table 111-2. er coding Table T 11-2—B BCD characte 3 0 0 0 0 0 0

2 0 0 0 0 1 1

1 0 0 1 1 0 0

0 0 1 0 1 0 1

osition within BC CD character ← bit po 0 1 2 Equivalent E characcter value 3 4 5




3 0 0 1 1 1 1 1 1 1 1

2 1 1 0 0 0 0 1 1 1 1

1 1 1 0 0 1 1 0 0 1 1

0 0 1 0 1 0 1 0 1 0 1

← bit po osition within BC CD character 6 7 8 9 – – In the most signifiicant BCD charaacter, any of – theese bit combinattions indicates a negative value. In all other BCD ccharacter positionns, these bit – combinations are iillegal. – –

11.3.6 6.2 Characte eristics ⎯ The value of o a positive BCD B number iss

n

 (BCD_ chharacter_ valuee)(10 i −1 ) , wheere i is the BCCD

i =1

digit numbeer (i = 1 for thee least significaant BCD digit) . ⎯ Binary-codeed decimal values range from m –10(n–1) +1 to 10n – 1. Neegative valuess require at leaast two BCD ch haracters. ⎯ Typically, the t objects usee values that fit into 2, 4, or 8 octets and uuse the types B BCD4, BCD8, oor BCD16. Other octet lengths are permitteed. ⎯ If it is neceessary to fit an n odd number of BCD charaacters into an integral number of octets, thhe BCD numb ber shall be paadded with a 0 digit in the m most significannt digit position. For examplle, 173bcd is trransmitted as 0173bcd, 0 and –57bcd – is transm mitted as –0577bcd. ⎯ Unless otheerwise specifieed on an objectt description inn Annex A, B BCD characterss are transmitteed little-endian n style; that is,, the least sign nificant BCD ccharacters are ttransmitted first, and the moost significant BCD B characterrs are transmittted last. ⎯ Unless otheerwise specified on an object description inn Annex A, thee least significaant bit of a BC CD value occup pies either bit position p 0 or 4 in an octet. 11.3.7 7 Printable ASCII strings Printab ble ASCII striings are non-n null-terminated d strings whos e character seet is limited too characters thhat display y textual charaacters or perforrm common printer control coommands. Gennerally, these sstrings are meaant for hu umans to read d or write. Th hey are typicaally used for names, instruuctions, error reports, loggeed inform mation, display notices, user identifiers, and passwords. Printab ble ASCII strin ngs use the notation VSTRn,, where n repreesents the num mber of octets. The V in VST TR comess from the word d “visible” and d is intended to o represent charracters that aree visible on a pprinter or displaay devicee. 11.3.7 7.1 Printable e characters s Table 11-3 shows prrintable characcters in the non n-shaded cells. Only characteers with valuess greater than 331 and less than 127 aree guaranteed to o be interoperab ble.




Table 11-3—Preferred printable characters Character value Dec

Printable symbol

Hex

Description

0

00

Null

1

01

SOH (Start of heading)

2

02

STX (Start of text)

3

03

ETX (End of text)

4

04

EOT (End of transmission)

5

05

ENQ (Enquiry)

6

06

ACK (Acknowledge)

7

07

BEL (Bell)

8

08

Backspace

9

09

Horizontal tab

10

0A

Line feed

11

0B

Vertical tab

12

0C

Form feed

13

0D

Carriage return

14

0E

SO (Shift out)

15

0F

SI (Shift in)

16

10

DLE (Data link escape)

17

11

DC1 (Device control 1)

18

12


19

13


20

14


21

15

NAK (Negative acknowledgment)

22

16

SYN (Synchronous idle)

23

17

ETB (End of transmission block)

24

18

CAN (Cancel)

25

19

EM (End of medium)

26

1A

SUB (Substitute)

27

1B

ESC (Escape)

28

1C

FS (File separator)

29

1D

GS (Group separator)

30

1E

RS (Record separator)

31

1F

US (Unit separator)

32

20

33

21

!

Exclamation mark

34

22

"

Quotation mark

35

23

#

Number sign

36

24

$

Dollar sign

37

25

%

Percent sign

Space

38

26

&

Ampersand

39

27

'

Apostrophe

40

28

(

Left parenthesis




Character value Dec

Printable symbol

Hex

Description

41

29

)

Right parenthesis

42

2A

*

Asterisk

43

2B

+

Plus sign

44

2C

,

Comma

45

2D

-

Hyphen

46

2E

.

Period

47

2F

/

Slash

48

30

0

0

49

31

1

1

50

32

2

2

51

33

3

3

52

34

4

4

53

35

5

5

54

36

6

6

55

37

7

7

56

38

8

8

57

39

9

9

58

3A

:

Colon

59

3B

;

Semicolon

60

3C

<

Less than

61

3D

=

Equals sign

62

3E

>

Greater than

63

3F

?

Question mark

64

40

@

Commercial at

65

41

A

A

66

42

B

B

67

43

C

C

68

44

D

D

69

45

E

E

70

46

F

F

71

47

G

G

72

48

H

H

73

49

I

I

74

4A

J

J

75

4B

K

K

76

4C

L

L

77

4D

M

M

78

4E

N

N

79

4F

O

O

80

50

P

P

81

51

Q

Q

82

52

R

R

83

53

S

S




Character value 84

54

Printable symbol T

85

55

U

U

86

56

V

V

Dec

Hex

Description T

87

57

W

W

88

58

X

X

89

59

Y

Y

90

5A

Z

Z

91

5B

[

Left bracket

92

5C

\

Backslash

93

5D

]

Right bracket

94

5E

^

Caret

95

5F

_

Underbar

96

60

`

Grave accent

97

61

a

A

98

62

b

B

99

63

c

C

100

64

d

D

101

65

e

E

102

66

f

F

103

67

g

G

104

68

h

H

105

69

i

I

106

6A

j

J

107

6B

k

K

108

6C

l

L

109

6D

m

M

110

6E

n

N

111

6F

o

O

112

70

p

P

113

71

q

Q

114

72

r

R

115

73

s

S

116

74

t

T

117

75

u

U

118

76

v

V

119

77

w

W

120

78

x

X

121

79

y

Y

122

7A

z

Z

123

7B

{

Left brace

124

7C

|

Vertical bar

125

7D

}

Right brace

126

7E

~

Tilde




Character value Dec 127

7F

128

80

129

81

130 131

Printable symbol

Hex

Description DEL

€

Euro

82

‚

Comma

83

ƒ

Script f

132

84

„

Down double quote

133

85

…

Dots

134

86

†

Dagger

135

87

‡

Double dagger

136

88

ˆ

Circumflex

137

89

‰

138

8A

Š

139

8B

‹

Left caret

140

8C

Œ

OE ligature

141

8D

142

8E

143

8F

144

90

145

91

‘

Left quote

146

92

’

Right quote

147

93

“

148

94

”

149

95

•

Big center dot

150

96

–

Dash

151

97

—

Double dash

152

98

˜

Tilde

153

99

™

Trade mark

154

9A

š

155

9B

›

Right caret

156

9C

œ

oe dipthong

157

9D

158

9E

ž

159

9F

Ÿ

160

A0

161

A1

¡

Inverted exclamation

162

A2

¢

Cent sign

163

A3

£

Pound sterling

164

A4

¤

Currency sign

165

A5

¥

Yen sign

166

A6

¦

Broken vertical bar

167

A7

§

Section sign

168

A8

¨

Umlaut

169

A9

©

Copyright

Ž

Y umlaut Non-breaking space




Character value

Printable symbol

Description

Dec 170

Hex AA

ª

Feminine ordinal

171

AB

«

Left angle quote

172

AC

¬

Not sign

173

AD

-

Soft hyphen

174

AE

®

Registered trademark

175

AF

¯

Macron

176

B0

°

Degree sign

177

B1

±

Plus or minus

178

B2

²

Superscript two

179

B3

³

Superscript three

180

B4

´

Acute accent

181

B5

µ

Micro sign

182

B6

¶

Paragraph sign

183

B7

·

Middle dot

184

B8

¸

Cedilla

185

B9

¹

Superscript one

186

BA

º

Masculine ordinal

187

BB

»

Right angle quote

188

BC

¼

One-fourth

189

BD

½

One-half

190

BE

¾

three-fourths

191

BF

¿

Inverted question

192

C0

À

A grave

193

C1

Á

A acute

194

C2

Â

A circumflex

195

C3

Ã

A tilde

196

C4

Ä

A umlaut

197

C5

Å

A ring

198

C6

Æ

AE ligature

199

C7

Ç

C cedilla

200

C8

È

E grave

201

C9

É

E acute

202

CA

Ê

E circumflex

203

CB

Ë

E umlaut

204

CC

Ì

I grave

205

CD

Í

I acute

206

CE

Î

I circumflex

207

CF

Ï

I umlaut

208

D0

Ð

Eth

209

D1

Ñ

N tilde

210

D2

Ò

O grave

211

D3

Ó

O acute

212

D4

Ô

O circumflex




Character value Dec 213

Hex D5

Printable symbol Õ

O tilde

214

D6

Ö

O umlaut

215

D7

×

Multiply sign

216

D8

Ø

O slash

217

D9

Ù

U grave

218

DA

Ú

U acute

219

DB

Û

U circumflex

220

DC

Ü

U umlaut

221

DD

Ý

Y acute

222

DE

Þ

Uppercase thorn

223

DF

ß

sz ligature

224

E0

à

a grave

225

E1

á

a acute

226

E2

â

a circumflex

227

E3

ã

a tilde

228

E4

ä

a umlaut

229

E5

å

a ring

230

E6

æ

Ae ligature

231

E7

ç

c cedilla

232

E8

è

e grave

233

E9

é

e acute

234

EA

ê

e circumflex

235

EB

ë

e umlaut

236

EC

ì

i grave

237

ED

í

i acute

238

EE

î

i circumflex

239

EF

ï

i umlaut

240

F0

ð

Eth

241

F1

ñ

n tilde

242

F2

ò

o grave

243

F3

ó

o acute

244

F4

ô

o circumflex

245

F5

õ

o tilde

246

F6

ö

o umlaut

247

F7

÷

Division sign

248

F8

ø

o slash

249

F9

ù

u grave

250

FA

ú

u acute

251

FB

û

u circumflex

252

FC

ü

u umlaut

253

FD

ý

y acute

254

FE

þ

Lowercase thorn

255

FF

ÿ

y umlaut

Description




11.3.7 7.2 Characte eristics ⎯ Each characcter occupies a single octet. ⎯ The order for f printing or display d of the characters c in thhe string is froom the first octet transmitted to the last octeet transmitted. 11.3.8 8 Octet strin ng Octet strings use the notation OSTR Rn, where n reepresents the nuumber of octetts. These stringgs contain codeed mation whose meaning m depen nds on the con ntext where theey are used. O One way of loooking at an octtet inform string is to consider it i as an array of o binary-coded d 8-bit elementts. The ch haracteristics of o an octet strin ng are: ⎯ Unless otheerwise specifieed on an objeect descriptionn in Annex A A, the first (low west numberedd) element in the t array, is traansmitted first. ⎯ Unless otheerwise specifieed on an objecct description in Annex A, the least signiificant bit of aan octet string octet occupiees the bit 0 possition in an occtet, and the m most significannt bit of an octtet string octet occupies the bit b 7 position in n an octet. EX 11-3

An examp ple of an octet sttring having threee elements { 0xx0A, 0x3F, 0xC77 } would appearr as shown:

octeet transmission n order ↓ 7 6 5 4 0 0 1

0 0 1

0 1 0

0 1 0

3

2

1

0

1 1 0

0 1 1

1 1 1

0 1 1

← bit position

11.3.9 9 SET of n SET of o n is a notation for indicatting repetitive,, similarly connstructed sets consisting of oother basic daata types. For an n example, consider a hypotheetical object deescription that contains multiiple point indexx descriptions. SET of o n: Point indeex elements { UINT T8: Length. Speciffies the numberr of octets in th he point type an nd point index fields. UINT T8: Point type. Speciffies the point ty ype with which h the index is associated. a Poiint type valuess are the group number used to convey y static data.




UINT Tn: Point index x. An ind dex number reelative to the point p indexes used u to conveyy data values ffor the specifieed point type in traditio onal DNP3 reaad or write requ uests. } Opening and closing g curly bracketts { } are used d to enclose thhe elements wiithin a set. Eacch curly brackket appearrs on a line by itself, as show wn. The “n n” in SET of n may have a specific s value, such as 8, if tthe number of sets is knownn in advance; thhe descrip ption would th hen specify SET T of 8. Or desccriptions can uuse the “n” to rrepresent a varriable number oof sets where w ‘n’ depen nds on some oth her factor. 11.3.1 10 Variant The variant data typ pe is used to denote that the actual data typpe cannot be sspecified withoout knowing thhe xt or values thaat appear in oth her members off an object. contex An example of this data d type appeaars in the description of dataa set prototypess and descriptoors, object grouup 85, vaariation 1 and object o group 86 6, variation 1. Both objects hhave a descripttor code field aand an ancillarry value field. The ancillary value field f contains UINT, OSTR R or VSTR daata depending on what valuue iptor code field d. appearrs in the descrip 11.3.1 11 Unicode string s Unicode strings arre non-null-terrminated octeet sequences that are bassed on the U UTF-8 Unicodde mat of ISO/IEC C 10646, which h encodes eachh Unicode charracter in from 1 to 6 octets. Transfformation Form Unicode strings shalll not prepend the Unicode character c U+F EFF (also knoown as a zero--width, no breaak s to hin nt that the strin ng contains Unnicode characters and uses U UTF-8 encodinng. space)) for use as a signature DNP3 always speciffies the data typ pes, and this prractice is superrfluous. For more m informatio on including th he encoding sch hema, the readder is referred tto IETF RFC 33629,32 ISO/IE EC 33 10646 6, and the Unico ode website.

EX 11-4 4

The follo owing examplees are copied from fr IETF RFC C 3629. The heexadecimal octtets shown in thhe examplees are transmitted in left-to-rig ght order.

The character sequeence U+0041 U+2262 U+03 391 U+002E ""A >." is encoded in UTF-8 ass follows: 0x41

0x xE2

0x89

0xA2

0xC CE

0x91

00x2E

c sequ uence U+D55C U+AD6D U+C5B4 (Koorean ”hanguugeo,” meaninng “the Koreaan The character languaage”) is encodeed in UTF-8 ass follows: 0xED

32 33

0x x95

0x9C

0xEA

B5 0xB

0xAD

00xEC

0x96

0xB4

Anneex D contains a nottice of copyright th hat permits using this t material. http:///www.unicode.org g.




The character c sequ uence U+65E5 U+672C U+8A9E U (Japaanese “nihonggo,” meaning “the Japanesse languaage”) is encodeed in UTF-8 ass follows: 0xE6

0x x97

0xA5

0xE6

C 0x9C

0xAC

00xE8

0xAA A

0x9E

The ch haracter U+233 3B4 (a Chinesee character meaaning “stump oof tree”) is enccoded in UTF-88 as follows: 0xE0

11.4

0x xA3

8E

B4

Object data d type co odes

Some of the DNP3 objects o require a number (cod de) to indicate a type of data but without sppecifying exacttly m bits or occtets are needed d. The data typ pe may referennce one of the pprimitives from m Table 11-1 oor how many a deriived type, such as time, wh hich is formattted as a UIN T48. Data typpe codes are iincluded in thhis docum ment to help assure that objeccts designed in the future assiign the same ccode numbers. Table 11-4 lissts the codes. Ta able 11-4—O Object data ty ype codes Code C

Co ode name

Description

0

NONE E

Data D type does not n exist or a plaaceholder.

1

VSTR

Visible V ASCII ch haracters suitablle for print and ddisplay.

2

UINT

Unsigned U integeer.

3

INT

Signed S integer.

4

FLT

Floating-point. F

5

OSTR

Octet O string.

6

BSTR

Bit B string.

7

DNP3T TIME

DNP3 D time (in th he form of an U UINT48): Absoluute time value exxpressed as the number n of millisseconds since thee start of January ry 1, 1970.

8

UNCD D

Unicode U strings (requires up to 6 octets per charracter).

254 4

U8BS8 8LIST

List L of UINT8–B BSTR8 pairs.

255 5

U8BS8 8EXLIST

Extended E list of UINT8–BSTR88 pairs. Object leength is 256 pluss the value in the t object’s leng gth octet.

Regard ding the data ty ype codes: ⎯ Data type codes do nott specify the number of ooctets requiredd to convey tthe value. Thhat n is obtained elsewhere. information ⎯ Floating-po oint types are limited to 4 and 8 octets for transporting 32-bit and 64-bbit floating-point values. No other sizes arre acceptable. Implementerss that use 64-bbit floating-pooint values shaall onsider the con nsequences of possible p non-innteroperability.. carefully co ⎯ Implementeers that use Unicode U shall carefully connsider the connsequences off possible nonninteroperability in that this data type is not n universally supported.

11.5

DNP3 ob bject types

DNP3 objects are brroadly categoriized into types depending onn whether the oobject contains a current valuue, c dataa, or is used as information. contains an event value, contains control-related command




11.5.1 1 Static type e Static data is non-ev vent data that refers r to the prresent value off points locateed in an outstaation device. Foor ple, single-bit binary b input daata, object gro oup 1, is of stat atic type becauuse it is a repreesentation of thhe examp most recently r measu ured, obtained, or calculated value v from a phhysical or virtuual two-state pooint. 11.5.2 2 Event type e Event refers to DNP P3 objects thaat convey chan nge informatioon or values thhat result from m “something oof ppened. For ex xample, a singlle-bit binary innput event, obbject group 2, is of event typpe interesst” having hap becausse the value rep presents a chan nge of state or quality that haas occurred on a single-bit binnary input poinnt. 11.5.3 3 Command d (Cmnd) typ pe Comm mand type objects are includeed in requests and a responses tthat relate to controlling the state or value oof an outtput. 11.5.4 4 Informatio on (Info) type e Inform mation refers to o DNP3 objectts that completee the understannding of a requuest or responsse. For examplle, absolu ute time, objectt group 50, varriation 1, contains the informaation required to set time intoo an outstation. 11.5.5 5 Attribute (Attrib) ( type Attribu ute refers to ob bjects used to convey c attributtes about data oor devices. Thhe values in objjects of this typpe do nott represent reall-time data for an operating sy ystem.

11.6

Object fllags

Many of the readablle data objects have variation ns that include flags consistinng of bit stringg (BSTRn) fieldds ns or attributes of the associatted data value. to indiicate condition 11.6.1 1 Flag defin nitions The pu urposes and meeanings of DN NP3 Object Flag gs are defined aas follows. In the following desccriptions: ⎯ An “originating device” is one that gathers g field ddata directly (ffor inputs) or issues controols t field (for ou utputs). directly to the ⎯ A “non-oriiginating devicce” is one thaat obtains inpuut data or isssues control coommands via a communicaations link. ⎯ A “reportin ng device” is a device that acts a as a DNP33 outstation, sending DNP3 messages to aan upstream deevice. Data from f an originating device may m arrive at th he master via oone or more ““data concentraator” devices. IIn this caase each devicce in the com mmunications chain, c other thhan the masterr, is a reportinng device. Thhis identiffication of variious devices is illustrated in Figure F 11-1. T The terms “upsttream” and “doownstream” thhat indicaate relative deviice hierarchy are a also shown in this diagram m.




Figure 11-1—Identification of non-originating devices (data concentrators) Each flag bit is described in Table 11-5. The ONLINE, RESTART, COMM_LOST, REMOTE_FORCED, and LOCAL_FORCED flags are common to all object group types that contain flags. The other flags are specific to particular object groups as identified in the table. Non-originating devices always pass flags through unchanged unless otherwise indicated in the following discussion. Each flag is “set” (has the value 1) when active and is “clear” (has the value 0) when inactive.

Table 11-5—Flag descriptions

Name

Functional description For input data objects: If clear, the point is inactive or disabled (for example: powered-down, faulty, etc.) and unable to obtain field data. The flag may optionally be cleared by a non-originating device if communications to the originating device fail. In this case the COMM_LOST flag shall also be set.

ONLINE

For output status objects: If clear, the output point is inactive, unavailable, out-of-service, not installed, or operating in local mode. The point may not be observable or may be not controllable. Commands sent to the point may fail. When an output point is in local mode, it shall clear this flag.





Name

Functional description The RESTART flag indicates that the data has not been updated from the field since device reset. Originating devices shall set this bit immediately upon restarting and keep the bit set until they have an updated value in their database. Non-originating devices shall set this bit immediately upon restart and keep the bit set until it is overwritten by collecting data from a reporting device.

RESTART

For input data objects:If set, the object is in the initialization state, having a value that has never been updated from the field since restart. The bit is cleared when the object is first updated. In an originating device, this is when the field value is first acquired. In a non-originating device, the bit remains set until it is overwritten by collecting data from a reporting device and that data does not have the RESTART flag set. For output status objects: The RESTART flag shall only be set while a device is restarting. In an originating device, the flag shall be cleared after the device is available to accept commands, irrespective of whether or not an output value (control) has been sent to the output object. In a non-originating device, the bit remains set until it is overwritten by collecting output status information from a reporting device and that data does not have the RESTART flag set. COMM_LOST indicates that there is a communication failure in the path between the device where the data originates and the reporting device. This flag indicates that the value reported for the object may be stale.

COMM_LOST

If set, the data value reported shall be the last value available from the originating device before communications were lost. An originating device never sets this flag. A non-originating device sets this flag if it loses communication with the adjacent downstream device; otherwise it propagates the state of COMM_LOST flag as received from the downstream device. Once set, this flag may only be cleared when data for this point is received from the adjacent downstream device and the COMM_LOST flag received with that data is cleared. If set, the data value is overridden in a downstream reporting device. Only a non-originating device may set this flag. The flag is set when an overridden value is received. The REMOTE_FORCED flag shall be set in an object if either the REMOTE_FORCED or LOCAL_FORCED flags (see below) are set in an object received from a downstream device.

REMOTE_FORCED

An originating device may never set this bit.

See flag description 11.6.1.1, NOTE 3.





Name

Functional description If set, the data value is overridden by the device that reports this flag as set. This may be due to the device operating in a diagnostic or temporary mode or due to human intervention.

LOCAL_FORCED

If the value is forced in a non-originating device and overridden in a downstream device, then the nonoriginating device shall set both REMOTE_FORCED and LOCAL_FORCED flags.

See flag description 11.6.1.1, NOTE 3. Only applicable to single-bit binary input and double-bit binary input object groups. If set, the binary data value is presently changing between states at a sufficiently high enough rate to activate a chatter filter. The binary data value reported does not necessarily represent the actual state because the chatter filter may clamp the reported value to a single state during the time it is active.

CHATTER_FILTER

The purpose of the chatter filter is to suppress event reporting for binary and double-bit binary inputs that are experiencing a rapid series of state changes. The determination of what constitutes “chattering” is device-dependent. While a binary input is chattering, the originating device shall set the CHATTER_FILTER flag. When the chattering input again becomes stable, the originating device shall clear the flag and report the current state of the input. The CHATTER_FILTER bit indicates that the binary input point has been filtered in order to remove unneeded transitions in the state of the point. Events are generated when the CHATTER_FILTER flag is set and cleared. Only applicable to counter object groups. This flag is obsolete and should not be set in new designs. Information is presented here for historical reasons.

ROLLOVER There is no mechanism within DNP3 for the outstation to report the value at which counter rollover occurs (i.e., the maximum possible counter value). Hence outstations shall not set the ROLLOVER flag and master devices shall ignore the ROLLOVER flag. If polled data reporting is used, the master is responsible for polling counter data frequently enough to detect rollover. Only applicable to analog input and analog output object groups. OVER_RANGE

If set, the data object’s true value exceeds the valid measurement range of the object. See flag description 11.6.1.1, NOTE 4, for more details.





Name

Functional description Only applicable to counter object groups. If set, the reported counter value cannot be compared against a prior value to obtain the correct count difference.

DISCONTINUITY

The resetting of a counter through the use of freeze and clear commands, [FREEZE_CLEAR] and [FREEZE_CLEAR_NR], is a normal operation that shall not cause setting of the DISCONTINUITY flag. The flag is cleared after a new value has been acquired and transmitted to an upstream device. Only applicable to analog input, analog output status, and analog output event object groups.

REFERENCE_ERR

If set, the measurement process determined that the object’s data value might not have the expected level of accuracy. For example: the reference signal used in the analog-to-digital conversion process is out of limits or a calculated value has been contaminated with noise. Only applicable to single-bit binary input and binary output object groups. The flag’s state indicates the state of the single-bit binary input or output point.

STATE STATE bits do not “flag” an exception condition per se. (See 11.6.1.1, NOTE 1.) They occupy a flag bit as a convenience in order to reduce the number of octets transmitted; however, the reported state values may be used to indicate error conditions.

11.6.1.1 Flag description notes NOTE 1—The RESTART, COMM_LOST, LOCAL_FORCED, REMOTE_FORCED, CHATTER_FILTER, ROLLOVER, OVER_RANGE, DISCONTINUITY, and REFERENCE_ERR flags all indicate “exception conditions.” In normal operation, the ONLINE flag is set (1) and the exception condition flags are all cleared (0). Any other combination of the ONLINE and exception condition flags indicates that the data value might not correctly indicate the value of the corresponding field point. NOTE 2—When an outstation reports a variation that has no flags, the master shall interpret this as if the flags were included with the ONLINE flag set and all the exception condition flags clear. If any other condition holds, then the outstation shall report a variation with flags. NOTE 3—For output status objects, the LOCAL_FORCED and REMOTE_FORCED flags indicate that the reported value has been overridden. This value might not correspond to the state of the output point. These flags do not indicate that a control was issued “locally” or “remotely” to the output point to set it to the reported state. NOTE 4—Rules for setting the OVER_RANGE flag. Some analog input data gathered by an outstation may inherently have a certain size, for example, devices that use 12bit A/D converters. However, a master may request this data in a particular format such as a 16-bit or 32-bit integer. The following rules govern reporting this type of data:

⎯ Rule 1: If a master requests a particular object variation, for example a 16-bit analog input, and the

measured value of the data point within the outstation is within the range for the DNP3 variation (–32 768 to 32 767 for the 16-bit example), then the outstation reports the value without modification within the requested variation. For a data value stored within the device having lower resolution than the requested data size, this simply involves the sign extending the value to the requested size. Since DNP3 analog values are signed, sign extension is not considered a modification of the value. For example, a device internally saves analog measurements as 12-bit two’s complement numbers; if the master requests a variation calling for a size of 16 or 32 bits, the outstation sign extends its 12-bit values for the response.




⎯ Rule 2: If a master requests a 16-bit variation and the value of the data point is outside of the range – 32 768 (0x8000) to 32 767 (0x7FFF), then the outstation reports the value as either –32 768 (for a negative over-range) or 32 767 (for a positive over-range) and it sets the OVER_RANGE flag of the object.

⎯ Rule 3: If a master requests a 32-bit variation and the value of the data point is outside of the range – 2 147 483 648 (0x80000000) to 2 147 483 647 (0x7FFFFFFF), then the outstation reports the value as either –2 147 483 648 (for a negative over-range) or 2 147 483 647 (for a positive over-range) and sets the OVER_RANGE flag of the object.

⎯ Rule 4: If an input exceeds the range measurable by the hardware on the outstation, the outstation sets the OVER_RANGE flag of the object. It does not alter the value reported by its hardware. For example, an outstation with a 12-bit A/D converter shall set OVER_RANGE when the input exceeds the full scale limit of the converter, and the outstation shall report the converter’s output as its maximum 2047 value in the analog input object.

⎯ Rule 5: Floating-point data types shall report a value that is less than or equal to the measurement range

minimum, or greater than or equal to the measurement range maximum, when the OVER_RANGE flag is set.

These rules are illustrated in Table 11-6. The outstation sets the OVER_RANGE flag in each case except in the example of 33 000 (decimal) requested as a 32-Bit Analog Input. This is a case of Rule 2 applying but not Rule 3. The term “full scale,” as used in Table 11-6, refers to the input levels to an A/D converter that results in either the minimum or the maximum converted output value.

Table 11-6—Setting of OVER_RANGE flag examples

A/D converter type (min / max output value)

Input level

input > full scale input < full scale input > full scale 8 bits unsigned (0 to 255) input < full scale input > full scale 12 bits signed (–2048 to 2047) input < full scale input > full scale 16 bits signed (–32768 to 32767) input < full scale input > full scale 32 bits signed input converts to (–2147483648 to 2147483647) value of 33 000 decimal input < full scale

0x007F 0xFF80 0x00FF 0x0000 0x07FF 0xF800 0x7FFF 0x8000 0x7FFF

0x0000007F 0xFFFFFF80 0x000000FF 0x00000000 0x000007FF 0xFFFFF800 0x00007FFF 0xFFFF8000 0x7FFFFFFF

0x7FFF

0x00080E8a

0x8000

0x80000000

input > full scale

0x7FF0

0x00007FF0

input < full scale

0xFFFF

0xFFFF8000

8 bits signed (-128 to 127)

12-bit signed (scaled to range of –16768 to 16752)b

Value reported in Value reported in 16-bit variations 32-bit variations (hexadecimal) (hexadecimal)

a

OVER_RANGE is not set in this case, but it is set in all other cases. In some devices, native analog ranges are “normalized” to fit into a 16-bit range and the measured value is scaled prior to being reported. For example, the output value of a 12-bit A/D converter could be scaled by multiplying by 16. This results in values in the range of –32 768 to 32 752 with steps of 16 between adjacent contiguous values. In cases where scaling is employed, the minimum and maximum scaled values are related to negative and positive “full-scale” values at the input. If the input quantity exceeds the full-scale input value, the respective minimum or maximum scaled value is reported and the OVER_RANGE flag is set.

b

NOTE 5—Non-originating devices that obtain data from downstream devices by a method other than DNP3 communication should do their best to set the flag bits to the appropriate states.




11.6.2 2 Interaction or combina ations of flag gs Each flag f indicates a separate condition. The settting or clearinng of a flag dooes not necessaarily cause othher flags to t set or clear. In I particular: Clearing C of the ONLINE flagg shall not requuire that any othher flag be set. The COMM_LOST C flag indicates that communication has faileed somewheree in the downsttream path. Thhis flag caan only be set by b a non-origin nating device. The reporting device shall noot alter the objject value or anny other flag received from f a downsttream device iff the communiication is lost, except that thhe ONLINE flaag o be cleared. c Thus, the value and other flags inndicate the statte of the input or output point may optionally when data was last collected c prior to communicaation failure. A data object with the COMM M_LOST flag sset ndication of thee last known vaalue of the inpput or output iff the other exceeption conditioon can bee used as an in flags are a not set. The REMOTE_FOR R RCED and LOC CAL_FORCED D flags indicatte that data hass been overriddden. The state oof these flags f shall not affect or alterr the state of any other flag. In particular, tthe setting of tthese flags shaall not cleear the ONLIN NE flag or set the t RESTART T flag unless thhat is what the reporting deviice actually doees to the data object. Setting g the CHA ATTER_FILT TER, ROLLO OVER, OVE ER_RANGE, DISCO ONTINUITY flags f shall not clear the ONLINE flag.

REFERENC CE_ERR,

annd

If a deevice is capablle of reporting g data (commu unicating with an upstream ddevice) prior too the clearing oof the RE ESTART flag in the reported d objects, then the ONLINE flag shall be ccleared at initiaalization and thhe follow wing conditionss shall hold: ⎯ If the ONL LINE flag is reeported set wh hile the RESTA ART flag is seet, the object iis operating annd reporting itss default start-u up value, but itt has not yet haad its data updaated from the ffield. ⎯ If the ONLIINE flag is cleaar, the object has h not compleeted its start-upp process and iss still off-line. 11.6.3 3 Implemen ntation rules If the value and flag gs of an object are preserved through a colld start or restaart, the RESTA ART flag of thhat hanged. objectt may optionallly remain unch When the data object is first updateed with field daata, the RESTA ART flag shalll be cleared. If a deevice overridess the initial vallue of objects, then during thhe period betw ween initializatiion and the tim me that th he data object is i first updated d with field datta, the objects may optionallly set their LO OCAL_FORCE ED flag to o indicate that the t value has been b overridden n. 11.6.4 4 Considera ations for da ata concentra ators (non-orriginating de evices) Data concentrators are non-origiinating devices acting as ““reporting devvices” that collect data from nating devices” or other repo orting devices. A data concenntrator accepts data and flag values sent to it “origin from a reporting dev vice and passess these on to a master m device. The data conccentrator may aalter some of thhe flags as a follows: ⎯ Unless otheerwise specified d, all flags are passed throughh unchanged. ⎯ When the data d concentrattor undergoes a cold start, iit shall set the RESTART fllag and clear aall other flags for all database points. Theese flags shall stay in this sttate until the ffirst data updaate orting device; at a which time,, the value andd flags shall bee set to the staate from the lower level repo reported fro om that downsstream device.. The data objjects may optiionally be inittialized with thhe ONLINE an nd LOCAL_FO ORCED flags set as outlinedd in the precedding discussionn. Alternativelly, the data co oncentrator maay choose to not n respond unntil the first daata update from the reportinng device. 328 Copyright © 2012 IEEE. All rightts reserved.



⎯ If a downsstream reportin ng device faills to communnicate with thee data concenntrator, the daata concentrato or may set the COMM_LOST C T flag for all daata objects from m that reportinng device. It maay optionally also a clear the ONLINE flag but shall not alter any otheer flag. When communicatioon with the low wer level devicce is establisheed or restored, the data conceentrator updatees all flags to thhe state reported by the dow wnstream devicce when data i s received (subbject to the foollowing rule fo for handling the forced data flags). f ⎯ If the LOCAL_FORCED D or REMOTE_ _FORCED flaags are set for an object from m a downstreaam s set the R REMOTE_FOR RCED flag thatt it passes to thhe reporting deevice, the dataa concentrator shall master. If th he data concen ntrator overrides a data pointt’s value, it shhall set the LO OCAL_FORCE ED flag; otherw wise this flag sh hall be cleared. 11.6.5 5 Object gro oups having variations with w flags and d without fla ags Some object groupss have variatio ons that include flags and otther variations that do not. F For these objeect d if it shall report a variation withh flags or a variation without groupss, a device is permitted to determine flags. The variation without flags shall only be reported if thhe flag status ffor all data repported with thhat E and none off the exception flag bits are sset. If any dataa point is not O ONLINE or haas variatiion is ONLINE some exception e cond dition flag bein ng set, then a variation v with fflags shall be uused to report tthat data. Hencce, if a vaariation without flags is used, the receiving device shall innterpret this to m mean that the ddata is ONLIN NE with no n exception co onditions. Note that t the sendin ng device may determine if fllags should or should not bee sent for objecct groups havinng variatiions with and without flags. Even if the master m device reequests a specific variation oof an object, thhe outstattion may respo ond with a diffferent variatio on (with or wiithout flags) ass appropriate aaccording to thhe condittion stated earlier. Other attrib butes of a speccific variation rrequested by a master, for exxample, 16-bit oor 32-bit data, shall be observed by th he outstation when w respondingg.

11.7

Status codes

mmon to multtiple variationss are listed here Many of the DNP3 objects return n status codes. The codes com d of repeating the t same inform mation on each h of the object insert sheets. instead 11.7.1 1 Status cod des for control-related objects Status codes appear in the responsses for controll output comm mands associateed with controol blocks (objeect utput blocks (o object group 41 1), and output command eveents (object grooups 13 and 433). group 12), analog ou Table 11-7 providess a list of valid status codes. Table 11-7—Con ntrol-related s status codes s Cod de numb ber

Identifier I namee

Descrip ption

0

SUCCES SS

Requ uest accepted, innitiated, or queueed.

1

TIMEOU UT

Requ uest not accepte d because the opperate message w was received aftter the arm a timer timed out. The arm tim mer was started when the select operration for the sam me point was recceived.

2

NO_SEL LECT

Requ uest not accepte d because no preevious matchingg select request existts. (An operate m message was sennt to activate an output that was not previously p arme d with a matchinng select messagge.)

3

FORMA AT_ERROR

Requ uest not accepte d because there were formattingg errors in the conttrol request (eithher select, operatte, or direct operrate).

4

NOT_SU UPPORTED

Requ uest not accepte d because a conttrol operation is not supported fo for this point.

5

ALREAD DY_ACTIVE

Requ uest not accepte d, because the ccontrol queue is ffull or the point is alreaady active.




Cod de numb ber

Identifier I namee

Descrip ption

6

HARDW WARE_ERROR

Requ uest not accepte d because of conntrol hardware pproblems.

7

LOCAL

Requ uest not accepte d because Locall/Remote switchh is in Local position.

8

TOO_MA ANY_OBJS

Requ uest not accepte d because too m many objects apppeared in the sam me requ uest.

9

NOT_AU UTHORIZED

Requ uest not accepte d because of inssufficient authoriization.

10

AUTOM MATION_INHIB BIT

Requ uest not accepte d because it wass prevented or innhibited by a local auto omation process.

11

PROCES SSING_LIMITE ED

Requ uest not accepte d because the deevice cannot proocess any more activ vities than are prresently in progrress.

12

OUT_OF F_RANGE

Requ uest not accepte d because the vaalue is outside thhe acceptable rang ge permitted for tthis point.

13 to 12 25

RESERV VED

Reseerved for future use.

126

NON_PA ARTICIPATING G

Sentt in request messsages indicating that the outstation shall not issuue or peerform the contrrol operation.a

127

UNDEFIINED

Requ uest not accepte d because of som me other undefinned reason.

a

Control status code 126, NON_PARTICIPA N ATING, may be ussed as a test or “noo-op”. Specific coontrol-related objeccts may have furthher c An outstatio on shall not reject requests with thiss status code or reeport parameter errror in IIN2.2 unleess explanatiion for using this code. there is so ome other reason to t do so.

11.7.2 2 Status cod des for file-rrelated objec cts A statu us code appearrs in the respon nse to each of the t request typpes. Table 11-88 provides a lisst of valid statuus codes for all file tran nsfer operations. Ta able 11-8—File-related sta atus codes Code numberr

Identtifier name

Deescription

Used with function coodes

0

SUCCESS

The requessted operation w was successful.

2, 25, 26, 277, 30

1

PERMISSION N_DENIED

Permission n was denied duee to improper auuthentication keyy, user name or password.

25, 27

2

INVALID_M MODE

An unsupp ported or unknow wn operation moode was requested.

25

3

FILE_NOT_F FOUND

The requessted file does nott exist.

25, 27, 28

4

FILE_LOCK KED

The requessted file is alreaddy in use by anotther user.

25, 27

5

TOO_MANY Y_OPEN

File could not be opened bbecause the numbber of ously opened filees would be exceeeded. simultaneo

25

6

INVALID_H HANDLE

There is no o file opened witth the handle in tthe request.

1, 2, 26, 30

7

WRITE_BLO OCK_SIZE

The outstattion is unable to negotiate a suitable write blockk size.

25

8

COMM_LOS ST

Communiccations were lostt or cannot be esstablished with the end dev vice where the fi file resides.

1, 2, 25, 26, 27, 28, 30

9

CANNOT_A ABORT

An abort reequest was unsuuccessful becausee the outstation iis unable or not n programmedd to abort, or the outstation know ws that abortin ng the file wouldd make it unusabble.

30

10 to 15

RESERVED

Reserved for f future use.

16

NOT_OPENE ED

File handlee does not refereence an opened ffile.

26




Code numberr

Identtifier name

Deescription

Used with function coodes

17

HANDLE_EXPIRED

File closed d due to inactivity ty timeout. This code is sent in a file transpo ort status event oobject (object grooup 70, variationn 6) when the timeout occurss.

None

18

BUFFER_OV VERRUN

Too much file data was recceived for outstaation to process.

2

19

FATAL

An error haappened in the fi file processing thhat prevents any further actiivity with this fille.

1, 2, 25, 26, 27, 28, 30

20

BLOCK_SEQ Q

The block number did not have the expecteed sequence number.

1, 2

21 to 254 4

RESERVED

Reserved for f future use.

255

UNDEFINED D

Some otherr error not listedd here occurred. Optional text explaining the error may apppear in the octeets following thee status codee.

11.8

1, 2, 25, 26, 27, 28, 30

Group number cate egories

DNP3 group numberrs generally falll into categories as follows: Device Attributes

group num mber 0

Binary y Inputs

group num mbers 1 to 9

Binary y Outputs


Countters


Analog Inputs


Analog Outputs


Time


Class


Files


Devices


Data Sets S


Appliccations


Altern nate Numerics

group num mbers 100 to 10 09

Other


Securiity


Unuseed group and vaariations are reeserved. Only the t DNP Userss Group may asssign new num mbers.

11.9

Point typ pes

Many of the objects in the library are organized according to tthe traits that ddifferentiate pooints of one typpe t other pointt types. In DNP P3, a point is a uniquely idenntifiable physiical or logical entity. The terrm from the 331 Copyright © 2012 IEEE. All rightts reserved.



“pointt” applies to in nputs like anallogs, binaries, and counters and to outputss like analogs and binaries. A single analog input is i an example of a point. It is i associated w with a specific measured signnal or computeed g quantity. In addition a to a vaalue, an analog g input may haave a name, a scale factor, a deadband valuue analog for eveent detection, and a other attrib butes. A point type is a means m of categ gorizing pointss having relateed characteristtics, similar fuunctionality, annd onship to physsical hardware or logical spaace. Using thee example from m the previouus paragraph, aan relatio analog g input belongss to the analog input point typ pe. In most cases, each point type hass one set of zeero-based indeex numbers to uniquely idenntify the speciffic point instances i withiin the point typ pe. This su ubclause discu usses the characcteristics and attributes a for thhe point types tthat appear in tthis library. 11.9.1 1 Analog input point typ pe 11.9.1 1.1 General description The an nalog input point type is used to monitor and a report the ssigned numericc values of physical or logiccal analog g quantities. Analog quantities generally g havee a continuouss range of po ssible values, subject to quuantization, thhat y be signed, suuch as positivee and negative DC currents, oor represent a physical amount. The quantities may c represent a magnitude on nly such as an AC RMS volltage; howeverr, all values arre transported in they can DNP3 messages as signed s quantitiees. There are almost no o restrictions pllaced upon thee source of vallues for analogg input points. The values caan come from measurin ng field inputs or from valu ues collected from other deevices or from m the result off a utation. Analog g inputs can reepresent positio on informationn such as a trannsformer tap nnumber. Another compu use is representing states; s e.g., a negative n valuee could indicatte below limit,, 0 could meann normal, and a positiv ve, non-zero vaalue could indiicate above lim mit. 11.9.1 1.2 Analog input i model Figure 11-2 diagram ms the analog in nput model sup pported by DN NP3. Frozen n Analog Inpu ut Value

To event queue q

Upon Freeze Analog Input Value V

Device-specific Evaluation n Function

Optional

Analog Inputt Deadband Valuue

Measureed, obtained or comp puted value

Figure F 11-2— —Analog inp ut model An an nalog input po oint always haas a present vaalue, which iss the most reccently measureed, obtained, oor compu uted value. 332 Copyright © 2012 IEEE. All rightts reserved.



A device with analog input points may optionally generate analog input events when something of interest occurs. Examples include the present value changes by an amount which is “enough to be interesting,” the present value crosses a threshold, or a specific time or time interval is reached. The value reported in an analog input event object is the present value of the analog input at the instant when the event is detected. It is permissible for applications to omit reporting intermediate values if more than one analog event for the same point is generated before being reported to the master; i.e., only the most recent event is reported. An analog input point may optionally support frozen analog input values and frozen analog input events. This is useful for reporting the analog values existing in points from multiple outstations at the same instant in time. Typically freezing is requested at regular intervals appropriate for the system. Upon a freeze, the present value of the analog input point is copied to a separate variable. The act of freezing an analog input point can be initiated from the master via a freeze request within a DNP3 message or from a local, internal or external source. By doing this, the master can read the frozen values, which do not change between freeze commands, at a somewhat leisurely pace instead of attempting to simultaneously read all of the analog input points in all of its outstations, an act that may be impossible. There shall be an underlying analog input existing within the point in order to report frozen analog values. Freeze operations take two forms—freeze and freeze-and-clear. With a freeze-and-clear type operation the underlying analog input value is preset to a suitable, possibly non-zero number after its value is copied to the frozen analog variable. Two applications where freeze-and-clear would be useful are when the underlying analog input holds either a peak value (minimum or maximum) or an integrated value that is reinitialized by the clear action from a freeze-and-clear request. If an analog input point is capable of generating frozen analog input events, a new event shall be created each time the analog input point is frozen. If events are supported, a change in one of the object flags (see 11.6.1) shall trigger creation of an event. 11.9.1.3 Analog deadbands One of the possible approaches for determining an “interesting value” is the use of a deadband. An analog input event is generated based on the difference of its current value and the value that was most recently queued as an event, when compared to a deadband value. There are two methods commonly used for detection of analog input events based on a deadband. ⎯ Fixed Deadband. If the absolute value of the difference between the present value of an analog input point and the value that was most recently queued as an event for that point exceeds the deadband value, then an event is generated for that point. ⎯ Integrating Deadband. The difference between the present value of an analog input point and the value that was most recently queued as an event for that point is integrated over time. An event is generated when the absolute value of the integral exceeds the deadband value. DNP3 does not specify which algorithm shall be used for deadbanding, and outstation vendors may choose to implement any deadbanding method, or none on any point. Deadband values may be downloaded via the protocol. Devices that support analog input reporting deadbands are not required to maintain the deadband values through a reset and may revert to default values immediately following the reset. Vendors of devices that are able to preserve updated deadband values through a reset should note this in the Device Profile for that device. 11.9.1.4 Applicable DNP3 object groups Table 11-9 shows which object groups are associated with analog input point types. A specific point index number associated with any of these group numbers always references the same point. 333 Copyright © 2012 IEEE. All rights reserved.



Table 11--9—Analog in nput point ty ype object grroups Grroup num mber

Used foor

30

Reporting the present value v

31

Reporting the frozen vaalue

32

Reporting analog input events or changges to the flag bitts

33

Reporting frozen analog g input events

34

Reading g and writing an nalog deadband vvalues

11.9.1 1.5 Non-froz zen and froze en data in the same mes sage Masters shall differeentiate between n static analog g input data andd static frozenn analog input data returned in polls for f Class 0 dataa. It is importaant that the masster update its ddatabase with the proper object and does nnot overw write a frozen vaalue with an un n-frozen value or vice-versa. In resp ponse to a Classs 0 poll, an ou utstation devicee shall report eiither: ⎯ The analog input value. ⎯ The frozen analog input value. v ⎯ Both valuess; however, if the t device is capable of repoorting both, thee point shall bee configurable to report just one, o the analog g input value orr the frozen anaalog input valuue. 11.9.2 2 Analog ou utput point ty ype 11.9.2 2.1 General description The an nalog output point p type is ussed to provide an analog outpput signal for controlling phyysical or logiccal quantiities. Analog outputs geneerally have a co ontinuous rang ge of possible vvalues, subject to quantization, that represennt A output values v are transported in DNP P3 messages uusing signed vaalues. a physsical amount. Analog Analog outputs are frequently f used to set the deesired operatingg level or posiition of a proccess or hardwaare a outputs are sometimees referred to as set-point ooutputs in othher mechaanism; this is why DNP3 analog protoccols. Uses incllude setting in nternal numbeers, parameter values and pphysical outputts (e.g., voltagge signals and loop currrents). Physiccal analog outp puts are usually y derived from m digital-to-anaalog conversionn hardware, whhereas virtual oor pseudo o analog outpu uts are most oftten software vaariables.




11.9.2.2 Analog output model

Figure 11-3—Analog output point type model An analog output value is set with a DNP3 request message having one of the Application Layer controlrelated function codes. In some devices, the value can also be set by other sources within the outstation, such as a local manual operator control or another software process. An analog output status value is used to monitor an analog output. The value returned shall represent the analog output value; it should not come from feedback of the process being controlled by the analog output value34 (e.g., not from the output of the plant or controlled device in Figure 11-3). The choice of where to obtain the analog output status value is device dependent. Because of this, analog output status values do not need to exactly match the analog output value. The accuracy of the value returned is device dependent. A device with analog output points may optionally generate events when something of interest occurs. Examples include the output value changes by an amount that is “enough to be interesting,” the present value crosses a threshold, or a specific time or time interval is reached. The value reported in an analog output event object is the present value of the analog output at the instant when the event is detected. If events are supported, a change in one of the object flags (see 11.6.1) shall trigger creation of an event. An analog output point may use deadbands to determine when there is a change of output value sufficient to be of interest. See 11.9.1.3 for more information on deadbands. A command from any source to set an analog output may also generate an event. Command events are used to notify the master whenever:

34 An analog input point is often used to monitor the controlled process’s output. Correlations between output points and the analog input points are outside the scope of DNP3.




⎯ An outstatio on receives a control c from an nother master oor a data concenntrator. ⎯ A control reequest is made from an intern nal application . ⎯ A control iss issued by a lo ocal operator paanel. 11.9.2 2.3 Applicab ble DNP3 objjects Table 11-10 shows which object groups are associated with analog outputt point types. A specific point index number associiated with any of these group numbers alwaays references tthe same pointt. Table 11-10—Analog output o point ttype object g groups Grroup num mber

Used foor

40

Reporting present valuee of analog outpuuts

41

Controllling analog outp put values

42

Reporting changes to th he analog outputt or flag bits

43

Reporting output pointss being commandded from any soource

11.9.3 3 BCD point type 11.9.3 3.1 General description DNP3 does not charracterize BCD values other th han to specify the binary-codded decimal foormat within thhe D points may bee used for inpu uts or outputs. Devices may cchoose to provvide BCD poinnts DNP3 objects. BCD p method d of reading values v from oth her already deefined point tyypes such as aanalog inputs oor as a parallel counteers. Becau use of the deviice dependency y, the device shall also mannage or coordiinate point inddexes associateed with BCD B points. Users and vendors of o equipment that t support BC CD point typees should be aw ware that interroperability with uipment may not n be practical or possible beecause of the deevice dependenncies. anotheer vendor’s equ 11.9.3 3.2 Applicab ble DNP3 objjects Table 11-11 shows which w object groups g are associated with BC CD point types. object group Table e 11-11—BCD D point type o ps Grroup num mber 101

Used foor To conv vey device-dependent values in B BCD form.

11.9.4 4 Binary output point ty ype 11.9.4 4.1 General description The binary output point p type is ussed to providee a digital on-ooff drive signaal or a pulsed drive signal fo for olling a real or pseudo output device. contro There are three ou utput models that t apply to binary outputts, Activation,, Complementtary Latch, annd o-Output. A deescription of eaach is providedd as follows. Complementary Two 336 Copyright © 2012 IEEE. All rightts reserved.



11.9.4.2 Activation model Figure 11-4 diagrams the binary output activation model supported by DNP3.

Figure 11-4—Activation model The activation model has a single virtual or physical output. The purpose of this type output is to initiate an action (i.e., “cause it to happen”). Examples include Initiate Test, Acknowledge Alarm, and Trip Breaker. Two binary output points (separate indexes) based on the activation model can be used as a pair to perform complementary functions—on-off, trip-close, raise-lower, etc. 11.9.4.3 Complementary latch model Figure 11-5 diagrams the binary output complementary latch model supported by DNP3.




Figure 11-5—Complementary latch model A complementary latch model has a single virtual or physical output that remains latched in an active or non-active state depending on which command is received. Examples include illumination on-off, enabledisable, and auto-manual. A complementary latch model always has a meaningful output state and, therefore, always generates Binary Output status events. 11.9.4.4 Complementary, two-output model Figure 11-6 diagrams the binary output complementary, two-output model supported by DNP3.




Figure 11-6—Complementary, two-output model A complementary, two-output model has two virtual or physical outputs, named close and trip at a single index. One or the other output is set active momentarily depending on which command is received. Examples include Run-Stop motor, Trip-Close breaker, Raise-Lower transformer tap, and Open-Close valve. 11.9.4.5 Common features of models In some devices, the output action can also be initiated by other sources within the outstation, such as a local manual operator control or another software process. All models of a binary output point type can report the output drive state if the characteristics of the point are such that the drive retains a meaningful state for a significant amount of time after a control command (from DNP3 or another source) is issued to the point. This is shown as the Binary Output Status Value block in the upper right corner of each figure. The output status is not obtained from the state of the driven device.35 If the output drive is stateless or does not change to a meaningful state for a significant time following a control command, then the output status is reported as 0. All models of a binary output point type may generate two types of events. ⎯ A Binary Output event is generated if the characteristics of the point are such that the drive retains a meaningful state for a significant amount of time after a control command is issued to the point (from DNP3 or another source) and the drive changes state. However, if the output drive is stateless or does not change to a meaningful state for a significant time following a control command, a Binary Output event is not generated. A device that supports Binary Output events shall generate an event if any of the object flags change. (See 11.6.1.) ⎯ A Binary Output Command event is generated whenever a command is issued to the point from either a DNP3 command or another source. 35 The state of a driven device, such as a circuit breaker, valve, or logical device, is often monitored with a binary input or double-bit binary input point. Correlation between the output point and the input point that monitors the driven output is outside the scope of DNP3.




11.9.4 4.6 Applicab ble DNP3 Ob bjects Table 11-12 shows which object groups are associated with binary output point types. A specific poinnt index number associiated with any of these group numbers alwaays references tthe same pointt. Table 11-12—Binary output point ttype object g groups Grroup num mber

Used foor

10

Reporting the present output status

11

Reporting changes to th he output status oor flag bits

12

Issuing control comman nds

13

Reporting control comm mand was issuedd regardless of itt source

The reecommended approach a for peerforming on-o off and close-triip controls is tto use the selecct and operate oor the dirrect operate fu unction codes with w group 12 objects. o Note that t using App plication Layerr function code write with a group 10 objject to control a binary output point is i not recommeended because: ⎯ The response to a write requ uest does not in ndicate whetheer the operationn was successfuul. ⎯ Devices may not n support wrrite operations to object groupp 10. 11.9.5 5 Counter point p type 11.9.5 5.1 General description The counter point type t is used to o monitor and d report the vaalues of monootonically increeasing unsigneed integer values. Countting is a basicc function app pearing in man ny DNP3 devvices. Typical examples incllude monitorinng energy y (KWHrs), flu uid usage (liters) and the num mber of circuit bbreaker re-clossures (operationns count). The values v stored in i counters may m be obtaineed directly froom field inputts such as eleectro-mechaniccal switch hes or from com mputed values.. Countter points often n support freeziing the counts. This is useful for reporting tthe count valuees existing in thhe points from multiple outstations at a the same in nstant in time.. Typically freeezing is requuested at regular i copyiing the contennts of a continnuously runninng intervaals appropriatee for the systeem. Freezing involves counteer into a separaate register or variable v upon receipt of a freeeze request frrom a DNP3 m master or another sourcee. By doing th his, the masteer can read th he frozen couunts, which doo not change between freezze comm mands, at a som mewhat leisureely pace insteaad of attemptinng to simultaneeously read alll of the countter points in all of its ou utstations, an acct that may be impossible. 11.9.5 5.2 Counterr model Figure 11-7 diagram ms the binary co ounter model supported s by D DNP3.




Figure 11-7—Counter point type model It is recommended that DNP3 counter points be based on modulo 65 536 or modulo 4 294 967 296 arithmetic and require either 16- or 32-bit unsigned binary values. During the counting process, the count always increases monotonically until the counter’s maximum value, 65 535 or 4 294 967 295, respectively, is reached, at which time the count rolls over to zero and the counter continues counting. Rollover values other than 65 536 and 4 294 967 296 are permitted. Counters may be preset to a value, including 0, by DNP3 commands, such as freeze-and-clear or write requests, or from other sources within the device where they reside. Freeze operations take two forms—freeze and freeze-and-clear. With a freeze-and-clear type operation, the counter value is zeroed after its counts are copied to the frozen counter. Freeze operations may also come from other software processes or hardware within the outstation. A device may configure counter support in any manner consistent with the following rules: a)

A binary counter shall exist for every counter point.

b) A frozen counter may exist for each binary counter (but not necessarily). c)

If a frozen counter exists, its index shall match that of the corresponding binary counter.

When a device restarts, frozen counter values may be undefined prior to processing the first freeze operation. Devices that maintain frozen counter values in non-volatile memory and that continue accumulation during a loss-of-power condition may possibly maintain valid frozen counter values across a device restart operation. Counters point types may optionally support events. The determination as to what makes a count significant to report as an event is vendor specific. As only one example, an event may be created if the difference between the present count and the count value in the last queued event exceeds a specific amount. If the point supports frozen counter events, the point creates an event at every freeze. The value in a frozen counter event is the same value that is copied to the frozen count at the time of the freeze. A device that supports counter events shall generate an event whenever any of the object flags change. (See 11.6.1.) 341 Copyright © 2012 IEEE. All rights reserved.



11.9.5.3 Implementation precedence Implementation of a frozen count value, counter events, and frozen count events are optional; however, there shall be an underlying counter existing within the point in order to report that data. (See Figure 11-7.) Frozen count events may only be implemented if the point implements a frozen counter. (See Figure 11-7.) 11.9.5.4 Positive and negative accumulations There are counting applications where the totals can be positive or negative. An example is a co-generation facility that sometimes purchases energy and sometimes supplies it. When power flows from the facility, the accumulation might have a positive total, and when power is consumed by the plant, the accumulation is negative. In cases where the accumulation has a mathematical sign, + or –, the use of two DNP3 counter points is required. One of the points is incremented when the polarity is positive and the other point is incremented when the polarity is negative. This maintains the rule that counters shall always increase monotonically and yet still provides the ability to report positive and negative accumulations. 11.9.5.5 Counts and frozen counts in the same message Masters shall differentiate between static counter data and static frozen counter data returned in polls for Class 0 data. It is important that the master update its database with the proper object and does not overwrite a frozen value with an un-frozen value or vice versa. In response to a Class 0 poll, an outstation device shall report either ⎯ The count value. ⎯ The frozen count value. ⎯ Both values; however, if the device is capable of reporting both, the point shall be configurable to report just one, the count value or the frozen count. 11.9.5.6 Applicable DNP3 objects Table 11-13 shows which object groups are associated with counter point types. A specific point index number associated with any of these group numbers always references the same point. Table 11-13—Counter point type object groups Group number

Used for

20

Reporting the count value

21

Reporting the frozen count value or changed flag bits

22

Reporting counter events

23

Reporting frozen counter events

11.9.5.7 Counter processing rules This subclause describes rules and requirements related to the existence and interaction between Running and Frozen Counters. The following terms are adopted for use within this subclause: Report and Reportable: Include, or the ability to include, the value of a specific object in response to a DNP3 request for data. 342 Copyright © 2012 IEEE. All rights reserved.



Running Counter Group/Object: Another name for the current Counter Object Group, Object Group 20, or an object within that group. Subset Admissible Request: A message to which an Outstation must respond according to rules of the subset to which the Outstation conforms. ⎯ Rule 1: Object index ‘n’ within each Counter Object Group refers to the same underlying Counter. For example, Frozen Counter ‘n’ records the value of Running Counter ‘n’ at the most recent freeze time for object ‘n’. ⎯ Rule 2: The Frozen Value for a particular object is generated when a Freeze action is initiated on the underlying Running Counter object, either through DNP3 or any other Freeze method supported by the Outstation. DNP3 Freeze requests are always addressed to the underlying Running Object Group (20), and generate Frozen Object (21) and Frozen Object Event (23) values. ⎯ Rule 3: While the DNP3 Freeze process implies the existence of both Running and Frozen Counter values for each object, both need not exist as DNP3 reportable values. ⎯ Rule 4: For each Counter object, an Outstation must have the ability to report a Running value, a Frozen value, or both. ⎯ Rule 5: Even though an Outstation may contain the ability to report both a Running and a Frozen value for the same Counter object, it must be configurable to report only one or the other, but not both, in response to a Class 0 poll. The choice need not be the same for each object, as long as each object reports either a Frozen value or a Running value, but not both. Determination of which Counters to report as Running and which as Frozen is not defined by DNP3. ⎯ Rule 6: If an Outstation elects to report only a Running value for a specific physical counter and only a Frozen value for another physical counter, then those two Counter objects cannot have the same index (corollary to rule 1). ⎯ Rule 7: If a value is reported in response to a static Class 0 poll, it must also be reported in response to a Subset Admissible Request for the same Object Group as reported in the Class 0 response (assuming the index is within scope of the request). For example, if a Class 0 response includes a Frozen Value for a specific object, then a Subset Admissible Request for Frozen Counters (Object Group 21) must include that object as long as its index is within the scope of the request. ⎯ Rule 8: Similar to rule 7, if event data can be returned in response to an event poll (Classes 1, 2, and/or 3), it must also be able to be returned in response to a Subset Admissible Request for the same Event Object Group as reported in the event poll response. ⎯ Rule 9: If an Outstation reports the Frozen value for an object in response to a Class 0 poll or other Subset Admissible Request, it may, but does not have to, report the Running value for the same object in response to a Subset Admissible Request for the Running Counter Object Group. ⎯ Rule 10: If the Outstation reports a Running value in response to a Class 0 poll or other Subset Admissible Request, it may, but does not have to, report a Frozen value for the same object in response to a Subset Admissible Request for the Frozen Counter Object Group. ⎯ Rule 11: The response to a read request for a Counter Object Group with no objects should be the same as the response to a read request for any other valid Object Group with no objects. Specifically, the response to a request for Running Counters, where all objects are reported as Frozen Counters only, should be generated in the same manner as if no Running Counter Objects exist. ⎯ Rule 12: The response to a read request for a range of objects (start/stop qualifier) where not all objects in the range exist should be the same as the response to a similar read request for any other valid Object Group where not all objects exist within the range of the request. For example, consider a range of Counters reported as Running Counters only except for an object in the middle 343 Copyright © 2012 IEEE. All rights reserved.



of the rangee reported as a Frozen Coun nter only. The rresponse to a R Running Counnter read requeest for the entirre range should d proceed as iff no object exissts for the indeex correspondinng to the Frozeen Counter onlly object. ⎯ Rule 13: Iff an Outstation n can report a Counter Eventt (Object Grouup 22) for Objject Index ‘n’ in response to o Subset Adm missible Requesst, it must repport the underrlying Counterr Value (Objeect Group 20) in i response to an appropriatee Subset Admiissible Requestt that includes the same indeex. If an Outsttation can repo ort a Frozen Counter C Event (Object Groupp 23) for Objeect Index ‘n’ in response to o Subset Adm missible Request, it must repport the underrlying Frozen Counter Valuue (Object Gro oup 21) in resp ponse to an app propriate Subseet Admissible R Request that inncludes the sam me index. ⎯ Rule 14: Ru ules 5 and 13 together t requirre that, if an Ouutstation suppoorts Counter evvents, it must bbe configurablle (on an Object or Object Group G basis) too support Runnning Counter eevents or Frozeen Counter eveents, but not bo oth. 11.9.6 6 Double-bit binary inpu ut point type 11.9.6 6.1 General description Doublle-bit binary in nput points hav ve two stable states, s such as on and off, annd an in-transitt state. A fourrth state can c represent a condition that does not occur during normaal operation. Motorr-operated pow wer line switchees and motor-o operated valvess are exampless of field devicces whose statuus monito oring benefits by using a dou uble-bit binary input point. T These devices hhave three statees: open, closeed, and traansitioning bettween opened and closed (an nd vice versa). Typically, it rrequires secondds to move from one en nd position to the other. Durring the transittion, there is a possibility off something going wrong annd causin ng the device to t stall; reportiing the interm mediate or transsitioning state is advantageoous because if it exists for too long, a problem may be indicated. The do ouble-bit binarry input point type t is suitablee for bi-stable ddevices, like sw witches, wheree the field wirinng utilizees form-C contaacts instead off form-A. Form m-C wiring requuires two inputts. When a form m-C device is at rest, one input is asserted and the other o is not, butt while the conntact moves beetween one inpuut and the otheer, uring contact bouncing, theree is an intermed diate condition . If the form-C C contact is of ttype and du ⎯ Break-beforre-make, then neither input is asserted duuring the interm mediate condittion (third statte) and the fourrth state indicaates that both in nputs are shortted together. ⎯ Make-beforre-break, then both inputs arre asserted durring the interm mediate condittion (third statte) and the fourrth state indicaates open circuiited inputs (dissconnected wirring). Users are not preven nted from usin ng double-bit binary b input p oints for otherr devices that have up to fouur y should not bee used to repressent two uncorrrelated single--bit binary inpuuts. states; however, they 11.9.6 6.2 Double-b bit binary inp put model Figure 11-8 diagram ms the double-b bit binary inputt model supporrted by DNP3.




Figure 11-8—Double-bit binary input model A double-bit binary input point is modeled as two single-bit binary inputs that are indivisibly linked together. The four input states are defined in Table 11-14. Table 11-14—Double-bit binary input states State value (UINT2)

State name

Description

Corresponding state if a single-bit binary input were used instead

0

INTERMEDIATE

Transitioning between end conditions

—

1

DETERMINED_OFF

End condition, determined to be OFF

0

2

DETERMINED_ON

End condition, determined to be ON

1

3

INDETERMINATE

Abnormal or custom condition

—

DNP3 does not define whether the end conditions, DETERMINED_OFF and DETERMINED_ON, represent Opened-Closed, Raised-Lowered, On-Off, etc., as this is an implementation detail. It is recommended that outstation vendors provide a clear definition for users, and that masters provide configuration to accommodate either situation. Vendors shall explicitly state what each state represents if a double-bit binary input is used to monitor some other type of three or four-state device. State 1 corresponds to what would be reported as a 0, and state 2 corresponds to what would be reported as a 1, if double-bit binary inputs were not available and a single-bit binary input were used instead. The logical states listed previously are independent of the values read from the physical inputs. The outstation is responsible for mapping the physical inputs to the correct logical states. A double-bit binary input point always has a current value, which is the most recently measured, obtained, or computed state. A double-bit binary input point may optionally generate an event whenever the state changes. Only a single event is generated, not two events, if both inputs change simultaneously or within a device-dependent interval. A device that supports double-bit binary input events shall generate an event whenever any of the object flags change. (See 11.6.1.)




11.9.6 6.3 Point sp pace Doublle-bit binary in nputs occupy a different po oint space thann do single-biit binary inputts. A double-bbit binary y input point an nd a single-bit binary b input po oint having thee same index ddo not necessarrily represent thhe same physical p or log gical entity. DN NP3 provides no n mechanism m to correlate ddouble-bit poinnts and single-bbit binary y input points even though itt may be apprropriate in certtain situations. This does noot prevent poinnts from being b correlated privately. 11.9.6 6.4 Applicab ble DNP3 objjects Table 11-15 shows which w object groups g are asso ociated with doouble-bit binary ry input point ttypes. A speciffic point index i number associated a with h any of these group g numberss always refereences the samee point. Table 11-15—D Double-bit bin nary input po oint type objject groups Grroup num mber

Used foor

3

Reporting present state value

4

Reporting double-bit biinary input eventts and flag bit chhanges

11.9.7 7 Octet strin ng point type e 11.9.7 7.1 General description Octet strings may bee used to repressent any block k of 8-bit quanttities. Often, thhey are used foor ASCII stringgs, but th hey may also be b used for no on-printing striings, arbitrary--length coded data, or memoory dumps. Thhe conten nt of an octet sttring is a local matter unless otherwise o speccified in the DN NP3 documenttation. Readin ng and writing g of 8-bit memo ory locations can be implemeented using thiss object togethher with absoluute addresssing qualifierss. In this case there t is no poin nt index, and uusers shall neeed to creativelyy determine hoow to diffferentiate one memory m region n from another.. 11.9.7 7.2 Octet strring model Figure 11-9 diagram ms the octet striing model supp ported by DNP P3. To event queue

Devvice-specific Evaluuation Function

Octet String

Measured, obtainedd or computed c value

Figure 11-9— —Octet strin g model The reelationship bettween an octett string point index numberr and a physiccal or logical eentity is a loccal matterr. Devices may create octet o string eveents. The criterria for generatiing an octet strring event is a llocal matter.




11.9.7 7.3 Applicab ble DNP3 objjects Table 11-16 shows which w object groups g are asso ociated with occtet string poinnt types. A speccific point indeex numbeer associated with w any of thesse group numbers always refeerences the sam me point. Table 11--16—Octet sttring point ty ype object grroups Grroup num mber

Used foor

110

To conv vey the present value v

111

Reporting an octet strin ng event

11.9.8 8 Single-bit binary inputt point type 11.9.8 8.1 General description The single-bit binarry input pointt type is used to monitor aand report the state of interrnal or physiccal o two possib ble values: 0 and 1. quantiities that have only There are almost no o restrictions placed p upon th he source of vaalues for singlle-bit binary innput points. Thhe fr values colllected from otther devices orr from the resuult valuess can come from sampling fieeld inputs or from of a Boolean computtation. 11.9.8 8.2 Single-b bit binary inp put model Figure 11-10 diagrams the single-b bit binary inpu ut model suppo rted by DNP3.. To eventt queue Change Deteccted Binary Innput Value

Change-oof-State Detecctor

Measured d, obtained or compu uted value

Figure 11-1 10—Single-bit binary inpu ut point type e model gle-bit binary input i point alw ways has a currrent value, whiich is the mostt recently meaasured, obtaineed, A sing or com mputed state. DNP3 does not speccify what a 0 or 1 state indiicates, and venndors are perm mitted to assign either state to o active or in nactive, etc. Paarameters speccifying debounnce timing, timerepresent opened or closed, on or off, d off times, maaximum togglee rates, and maaximum number stamp accuracy and resolution, miinimum on and utside the scopee of DNP3—thhese are factorrs that vendorss and users shaall of chaanges per unit of time are ou consid der for the inten nded applicatio on. A dev vice that suppo orts single-bit binary b input ev vents shall gennerate events w whenever the ssingle-bit binarry input value v changes state or wheneever any of the object flags chhange. (See 11.6.1.) 11.9.8 8.3 Applicab ble DNP3 objjects Table 11-17 shows which object groups g are asso ociated with siingle-bit binaryy input point tyypes. A speciffic point index i number associated a with h any of these group g numberss always refereences the samee point. 347 Copyright © 2012 IEEE. All rightts reserved.



Ta able 11-17—S Single-bit bin nary input po oint type obje ect groups Grroup num mber

Used foor

1

Reporting the present value v of a single--bit binary input

2

Reporting single-bit bin nary input eventss and flag bit chaanges

11.9.9 9 Virtual terrminal point type 11.9.9 9.1 General description Many IEDs have separate, non-D DNP3, serial interfaces i usedd for configurration, diagnostics, and other ancillaary tasks. These utility portts are often seet up for connnection to a duumb terminal or PC, and thhe protoccol on these ports p is often an a ASCII com mmand set cusstomized for thhe particular IIED. VT poinnts provid de a somewhatt transparent means m to comm municate withh these ports bby sharing the existing DNP P3 bandw width. This scheeme eliminatess the need for a parallel set off communication links (Figure 11-11). Contrrolling Device

IED Devicee DNP3 Outstatioon

Terminal 1

DNP3 Masterr

Terminal 0

Port 1

Terminaal Command Intterpreter

Port 0

Terminaal Command Intterpreter

Group 112 Objects O Group 113 Objects O

Figure 11-11—Virtua al terminal co onceptual model Inform mation between n the terminal equipment or process at eacch end are trannsported over what is called a virtuall communicatio on channel. Eaach virtual com mmunication chhannel is assignned a virtual poort number. The prrocedure for co ommunicating with virtual terrminal points iis as follows. M Master devices transmit data to outstattion devices by y writing one or o more group 112 objects ussing the DNP3 point index nuumber to speciffy the virrtual port numb ber. Outstaations return information i to o the master by respondingg to read reqquests for objject group 113, respon nding to read requests for thee configured ev vent class, or trransmitting an unsolicited ressponse messagee. The Device D Profile shall s list the po oint index numb ber(s) assignedd to virtual term minals. 11.9.9 9.2 Applicab ble DNP3 objjects Table 11-18 shows which object groups g are associated with vvirtual terminall point types. A specific point index number associiated with any of these group numbers alwaays references tthe same pointt. 348 Copyright © 2012 IEEE. All rightts reserved.



Table 11-18 8—Virtual terrminal point type object groups Grroup num mber

Used foor

112

Convey ying data to the command c interprreter at the outsttation

113

Convey ying data from th he command inteerpreter at the ouutstation

11.9.1 10 Security statistics s point type 11.9.1 10.1 General description Securiity statistics arre used to mo onitor the use of the DNP3 secure authenntication protoccol described in Clausee 7. Objects off this point type are used to count c and repoort the number of times that pparticular evennts occur when two DN NP3 devices aree attempting to o authenticate each other or to change crypptographic keyys. a to mon nitor the num mber and frequ uency of erroors and messaage exchangess during secuure The ability authen ntication proviides an additio onal level of security. s If cerrtain statistics have large vaalues or quickkly increaasing values, th his may indicatee an attack is underway. u Securiity statistics are a monotonicaally increasing g unsigned intteger values. A As such, theyy are essentially counteers. However, security statistics differ from f the counnters describeed in 11.9.5 aas described in Table 11-19. ecurity statistics versus s standard DN NP3 counters s Table 11-19—Se Featurre

Security statistics

Stan ndard DNP3 coounters

Sourcee of Data

Incremen nted by the DNP3 software implemen nting the secure authentication specificattion.

Mayy be incrementedd by software logicc or external harrdware events.

Point Numbers N

Table 7-6 6 specifies the use u and meaning of particularr point numbers for security stati tistics. Every DN NP3 device mustt use these pointt numbers and must report all of the speciffied statistics to be compliant with the secure authenticcation specificatiion. The pointt number used fo or the static and event objects reefers to the samee statistic.

The meaning of poinnt numbers is lefft for tthe user to decidde. The point number used for the staticc, frozzen, and event obbjects refers to thhe me counter. sam

Variatiions

Always reported r as 32-biit values with flaag. Timestam mp is optional.

Mayy be reported in oother variations..

Rollov ver

Statistics rollover to 0 aftter exceeding 7 295 and contin nue counting. 4 294 967

Mayy rollover at otheer values.

Freezin ng and Clearing

Not perm mitted. Providing g these features w would create seccurity vulnerabillities.

Optiional.

Retentiion over Restartss

Device allways retains thee value in non-voolatile memory over restarts.

Optiional.

Event Reporting R

Device generates events when w the statistiic exceeds a threshold.

Evalluation function determining wheen to generate ann event is userdefinned.

DNP3 Associations

Security statistics may bee reported on a ddifferent DNP3 association than th he one they are ng. For instance, master “B” mayy receive describin notification that the statisstics for master ““A” are E device assiggns a reaching critical levels. Each 6-bit Association n ID for each DN NP3 unique 16 associatio on. This ID is rep ported in the staatistic object.

DNP3 associationn Appply only to the D on w which they are reeported.




11.9.10.2 Security statistics model

Figure 11-12—Security statistics model The security statistics model is shown in Figure 11-12. The value of each statistic is incremented by the DNP3 software as described in Clause 7. Each statistic has a pre-configured reporting threshold, similar to the deadbands for analog inputs. However, the statistic threshold cannot be set remotely as with analog inputs because that would create a potential vulnerability. Security statistics thresholds operate similarly to fixed analog deadbands. Whenever the difference between the current value and the last reported value of a statistic exceeds the reporting threshold, the device generates an event. The value in the event becomes the last reported value. The default threshold for each statistic is specified in Clause 7. There are other maximum thresholds for specific security statistics beyond the reporting thresholds. Their use is described in Clause 7. 11.9.10.3 Applicable DNP3 objects Table 11-20 shows which object groups are associated with security statistic point types. A specific point index number associated with any of these group numbers always references the same point. Table 11-20—Security statistics point type object groups Group number 121 122

Used for Reporting the current value of the statistics Reporting changes to the statistics




12 12.1

DNP3 obje ect library— —parsing codes Subset parsing p cod des

The taables that follo ow summarizee the combinattions of groupps, variations, function codees, and qualifier codes that apply to DNP3 D subset leevels. A masterr or outstation shall be able too parse the coddes shown in thhe 3 subset level it i claims. Hav ving the abilityy to parse doess not require a device to havve tables for the DNP3 points, attributes, etcc. that would be b transferred by objects of tthe particular group and variation. A devicce o parsee groups, variaations, function n codes, and quualifiers that aare in addition to the minimuum may optionally requirements of the subset level it claims. Subclaause 12.2 proviides suggestionns for using D DNP3 objects nnot bed in the sub bset parsing tab bles. Every dev vice shall be aable to limit thhe objects, funcction codes, annd describ qualifi fier codes that it transmits to those required d by the subseet level of the receiving mastter or outstatioon devicee. 12.1.1 1 How to intterpret the subset parsin ng tables 12.1.1 1.1 Requestt and response column in ndependenc ce The reeader should consider c each of the followin ng subset parssing tables as a merger of ttwo independent tables:: a request tablle and a respon nse table that arre combined foor conveniencee. When interprreting the tablees, use thee columns desccribed in 12.1.1 1.2 or 12.1.1.3. The reeader shall no ot assume a reelationship bettween the tablle entries in bboth the request and responsse colum mns (for the sam me row). In som me cases, DNP P3 responses inndicated in the Response coluumn do apply to corresponding DNP P3 requests ind dicated in thee Request coluumn, but this is not alwayys true. In moost mstances, DNP3 responses aree returned as a result of requeests not listed iin the same row w. circum 12.1.1 1.2 Interpretting the subs set parsing tables t for ou tstation deviices Find th he group and variation v numb ber and then the subset level of the outstatioon. The outstattion device shaall be cap pable of parsin ng all of the fu unction and qualifier codes liisted under thee Request coluumn. For greatter flexibiility, vendors may choose to o implement a device so thhat it parses fuunction and quualifier codes in higherr subset levels, or from Tab ble 12-1 throug gh Table 12-332. The outstattion device maay only transm mit functio on and qualifieer codes listed under the Ressponse columnn to masters baased on the subbset level of thhe masterr. The device may m transmit the t function an nd qualifier coodes in other suubset levels orr from 12.2.2, if the maaster supports them. t Wheree the Request column is in ndicated with “—” (dash) m marks, supportt for the grouup and variatioon (indicaated on that row w) is not requiired for the giv ven subset leveels. Where the Request colum mn is shaded, thhe table row is not ap pplicable to ou utstation parsiing. An exampple of this is a table row representing aan unsolicited response for master parrsing. 12.1.1 1.3 Interpretting the subs set parsing tables t for ma aster devices s Find the t group and variation num mber and then the t subset leveel of the masteer. The masterr device shall bbe capablle of parsing alll the function and qualifier codes c listed undder the Responnse column. Thhe master devicce may only o transmit to o outstations fu unction and quaalifier codes lissted under the Request colum mn, based on thhe subsett level of the ou utstation. The master device may transmit ffunction and qqualifier codes in higher subsset levels or from Tablee 12-1 through Table 12-32, if i the outstationn supports them m. Wheree the Response column is indicated i with “—” (dash) m marks, supportt for the grouup and variatioon (indicaated on that ro ow) is not requ uired for the giiven subset levvels. Where thee Response coolumn is shadeed, the tab ble row is not applicable a to master m parsing. An example oof this is a tablle row represennting variationn 0 of an object o for outsttation parsing. 351 Copyright © 2012 IEEE. All rightts reserved.



12.1.2 2 Subset pa arsing tables s Suppo ort for all objeccts of group 0 became mand datory for subsset level 4 connformant devicces from DNP332007. The paarsing informaation in Table 12-1 applies to o DNP3 group 0 attribute objjects for index 0. Parsing rulees for useer-specific grou up 0 attribute sets s (indexes 1 and above) aree device depenndent. Tab ble 12-1—g0 device attrib bute objects Subset levels

Request R Respon nse (outstatio on must parse ) (master shaall parse ) Group p Variation Function codees Quallifier codes F Function codes Qualifier codess 1 2 3 4 (decimal) (hexxadecimal ) (hexadecimal ) (decimal) 0 209 - 239 EAD) 00 129 ((RESPONSE ) 00, 17  1 (RE 0 209 - 243 x x x — — — — 0 240 EAD) 00 129 ((RESPONSE ) 00, 17  1 (RE a 0 240 2 (WR RITE) 00  0 241 - 243 EAD) 00 129 ((RESPONSE ) 00, 17  1 (RE 0 245 - 247 EAD) 00 129 ((RESPONSE ) 00, 17  1 (RE 0 245 - 247 RITE) a 00  2 (WR 0 245 - 250 x x x — — — — 0 248 - 250 EAD) 00 129 ((RESPONSE ) 00, 17  1 (RE 0 252 EAD) 00 129 ((RESPONSE ) 00, 17  1 (RE 0 252 x x x — — — — 0 254 1 (RE EAD) 00, 0 06  0 254 - 255 x x x — — — — 0 255 EAD) 00, 006 129 ((RESPONSE ) 00, 17  1 (RE a WRITE function codes in i this table are sh hown as examples of attributes that m may be writeable in subset level 1, 22, and 3 conformaant s levels 1, 2, and 3 is device dependent. d A mastter may read groupp 0, variation 255 to determine whiich devices. Actual usage at subset group 0 attributes are writteable for a particu ular device.

Table e 12-2—g1 binary b input s static objects s

Group p

Subset levels

Variation

1 2 3 4 1 1 1 1 1 1 1 1

0 0 0 0 1 1 2 2

x             

Request R (outstatio on must parse ) Function codees Quallifier codes (decimal) (hexxadecimal ) — — 1 (RE EAD) 06 1 (RE EAD) 00, 001, 06 22 (A ASSIGN_CLASS ) 00, 001, 06 — — 1 (RE EAD) 00, 001, 06 — — 1 (RE EAD) 00, 001, 06

Respon nse (master shaall parse ) F Function codes Qualifier codess (hexadecimal ) (decimal)

129 ((RESPONSE ) 129 ((RESPONSE ) 129 ((RESPONSE ) 129 ((RESPONSE )

00, 01 00, 01 00, 01 00, 01




Table 12-3—g2 binary input event objects

Table 12-4—g3 double-bit binary input static objects

Table 12-5—g4 double-bit binary input event objects




Table 12-6—g10 binary output static objects

Table 12-7—g11 binary output event objects

Table 12-8—g12 binary output command objects

Table 12-9—g13 binary output command event objects




Table 12-10—g20 counter static objects Subset levels

Request (outstation must parse) Group Variation Function codes Qualifier codes 1 2 3 4 (decimal) (hexadecimal) 20 0 x — — 20 0 1 (READ) 06 20 0 7 (IMMED_FREEZE) 06 20 0 8 (IMMED_FREEZE_NR) 06 20 0 9 (FREEZE_CLEAR) 06 20 0 10 (FREEZE_CLEAR_NR) 06 20 0 1 (READ) 00, 01, 06 20 0 7 (IMMED_FREEZE) 00, 01, 06 20 0 8 (IMMED_FREEZE_NR) 00, 01, 06 20 0 9 (FREEZE_CLEAR) 00, 01, 06 20 0 10 (FREEZE_CLEAR_NR) 00, 01, 06 20 0 22 (ASSIGN_CLASS) 00, 01, 06 20 1 — — 20 1 1 (READ) 00, 01, 06 20 2 — — 20 2 1 (READ) 00, 01, 06 20 5 — — 20 5 1 (READ) 00, 01, 06 20 6 — — 20 6 1 (READ) 00, 01, 06

Response (master shall parse) Function codes Qualifier codes (decimal) (hexadecimal)

129 (RESPONSE) 129 (RESPONSE) 129 (RESPONSE) 129 (RESPONSE) 129 (RESPONSE) 129 (RESPONSE) 129 (RESPONSE) 129 (RESPONSE)

00, 01 00, 01 00, 01 00, 01 00, 01 00, 01 00, 01 00, 01

Table 12-11—g21 frozen counter static objects Subset levels

Request (outstation must parse) Group Variation Function codes Qualifier codes 1 2 3 4 (decimal) (hexadecimal) 21 0 x — — 21 0 1 (READ) 06 21 0 1 (READ) 00, 01, 06 21 0 22 (ASSIGN_CLASS) 00, 01, 06 21 1 x — — 21 1 — — 21 1 1 (READ) 00, 01, 06 21 2 x — — 21 2 — — 21 2 1 (READ) 00, 01, 06 21 5 x x x — — 21 5 1 (READ) 00, 01, 06 21 6 x x x — — 21 6 1 (READ) 00, 01, 06 21 9 x — — 21 9 — — 21 9 1 (READ) 00, 01, 06 21 10 x — — 21 10 — — 21 10 1 (READ) 00, 01, 06

Response (master shall parse) Function codes Qualifier codes (decimal) (hexadecimal)

— 129 (RESPONSE) 129 (RESPONSE) — 129 (RESPONSE) 129 (RESPONSE) — 129 (RESPONSE) — 129 (RESPONSE) — 129 (RESPONSE) 129 (RESPONSE) — 129 (RESPONSE) 129 (RESPONSE)

— 00, 01 00, 01 — 00, 01 00, 01 — 00, 01 — 00, 01 — 00, 01 00, 01 — 00, 01 00, 01




Table 12-12—g22 counter event objects

Table 12-13—g23 frozen counter event objects

Table 12-14—g30 analog input static objects




Table 12-15—g31 frozen analog input static objects

Table 12-16—g32 analog input event objects

Group

Subset levels

Variation

1 2 3 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32

0 0 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 7 7 7 8

x

x x x

x x x

x x x

x x x x x x

x x x

Request Response (outstation must parse) (master shall parse) Function codes Qualifier codes Function codes Qualifier codes 4 (decimal) (hexadecimal) (decimal) (hexadecimal) — — 1 (READ) 06, 07, 08 — — 129 (RESPONSE) 17, 28 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 — — 129 (RESPONSE) 17, 28 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x — — — — — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 — — — —

Table 12-17—g33 frozen analog input event objects




Table 12-18—g34 analog input deadband objects

Table 12-19—g40 analog output status objects

Group

Variation

Subset levels 1 2 3 4

40 40 40 40 40 40 40 40 40 40

0 0 0 1 1 2 2 3 3 4

  x x

    

    x x x  x x x x

Request (outstation must parse ) Function codes Qualifier codes (decimal) (hexadecimal ) 1 (READ) 06 1 (READ) 00, 01, 06 22 (ASSIGN_CLASS ) 00, 01, 06 — — 1 (READ) 00, 01, 06 — — 1 (READ) 00, 01, 06 — — 1 (READ) 00, 01, 06 — —

Response (master shall parse ) Function codes Qualifier codes (decimal) (hexadecimal )

— 129 (RESPONSE ) 129 (RESPONSE ) 129 (RESPONSE ) — 129 (RESPONSE ) —

— 00, 01 00, 01 00, 01 — 00, 01 —

Table 12-20—g41 analog output command objects




Table 12-21—g42 analog output event objects

Group

Subset levels

Variation 1

42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42

0 0 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 7 7 7 8

x x

x

x

x

x

x x

x

Request Response (outstation must parse) (master shall parse) Function codes Qualifier codes Function codes Qualifier codes 2 3 4 (decimal) (hexadecimal) (decimal) (hexadecimal) x x — — 1 (READ) 06, 07, 08 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x x — — — — x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x x — — — —

Table 12-22—g43 analog output command event objects

Group

Subset levels

Variation 1

43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43 43

0 0 1 1 1 2 2 2 3 3 3 4 4 4 5 5 5 6 7 7 7 8

x x

x

x

x

x

x x

x

Request Response (outstation must parse) (master shall parse) Function codes Qualifier codes Function codes Qualifier codes 2 3 4 (decimal) (hexadecimal) (decimal) (hexadecimal) x x — — 1 (READ) 06, 07, 08 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x x — — — — x x — — — — 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 130 (UNSOL_RESP) 17, 28 x x x — — — —




Table 12-23—g50–g52 time information objects

Table 12-24—g60 class information objects

Table 12-25—g70 file objects




Table 12-26—g80–g83 information objects

Table 12-27—g85–g88 data set objects

Table 12-28—g90-g91 application & status of operation information objects

Table 12-29—g101–g102 numeric static objects




Table 12-30—g110– –g113 string & virtual term minal static & event obje ects

Group p

Subset levels

Variation

1 2 3 4 110 110 111 112 113 113

0 1 - 255 1 - 255 1 - 255 0 1 - 255

x x x x x x

x x x x x x

x x x x x x

x x x x x x

— — — — — —

Request R (outstatio on must parse ) Function codees Quallifier codes (decimal) (hexxadecimal ) — — — — — —

Respon nse (master shaall parse ) F Function codes Qualifier codess (hexadecimal ) (decimal) — — —

— — —

—

—

Table 12-31—g12 20–g122 sec curity objects s

Group p

Subset levels

Variation

1 2 3 4 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 120 121 121 122 122

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 1 2

x x x x x x x x x x x x x x x x x x x x




— — — — — — — — — — — — — — — — — —

Request R Respon nse (outstatio on must parse ) (master shaall parse ) Function codees Quallifier codes F Function codes Qualifier codess (decimal) (decimal) (hexxadecimal ) (hexadecimal ) — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Table 12-3 32—Function n codes not used with ob bjects Subset levels

Requeest (outstation mu ust parse )

Responsse (master shalll parse )

1 2 3 4

Function codess (decimal)

Function codes (decimal)

            

12.2

0 (C CONFIRM ) 13 (COLD_RESTAR ( RT ) 23 (DELAY_MEASU ( UREMENT ) 24 (RECORD_CURR ( RENT _TIME)

Parsing guidelines

Table 12-33 throug gh Table 12-6 64 are intended d as guidelinees for usage oof groups, variiations, functioon codes,, and qualifier codes that aree outside of thee minimum reequirements off DNP3 subset definitions. Foor complleteness, the taables that follo ow also includ de the informaation from thee subset parsinng tables in thhe previo ous subclause.




These tables do no ot provide an exhaustive lisst of all validd DNP3 objecct / function ccode / qualifier combiinations. Devicces may impleement differentt combinationss to those shoown in the tablles and still use DNP3 in a valid way y. Havin ng the ability to o parse does no ot require a dev vice to have po ints, attributes, etc. that woulld be transferreed by objjects of the paarticular group and variation. Every devicee shall be ablee to limit the oobjects, functioon codes,, and qualifier codes that it trransmits to tho ose required byy the subset leevel of the receeiving master oor outstattion device. 12.2.1 1 How to intterpret the parsing p guide eline tables 12.2.1 1.1 Requestt and response column in ndependenc ce The reeader should consider each of o the followin ng tables as a m merger of twoo independent ttables: a requeest table and a a response table that are combined c for convenience. c W When interpretiing the tables, use the columnns describ bed in 12.2.1.2 2 or 12.2.1.3. The reeader shall no ot assume a reelationship bettween the tablle entries in bboth the request and responsse colum mns (for the sam me row). In so ome cases, DN NP3 responses indicated in thhe response funnction code annd qualifi fier columns do o apply to corrresponding DNP3 D requests indicated in tthe request funnction code annd qualifi fier columns, but b this is not always true. In most circum mstances, DNP P3 responses arre returned as a result of requests nott listed in the same s row. 12.2.1 1.2 Interpretting the pars sing guideline tables for o outstation devices Find the t group and variation num mber. The outsstation device may parse som me or all of thhe function annd qualifi fier codes listed d under the Request column. The outstationn device may ttransmit functiion and qualifier codes as listed underr the Response column. Wheree the Request column c is shad ded, the table row r is not app licable to outsstation parsing.. An example oof this is a table row rep presenting an unsolicited u resp ponse for mastter parsing. 12.2.1 1.3 Interpretting the pars sing guideline tables for master devic ces Find th he group and variation v numb ber. The masterr device may pparse some or aall of the functiion and qualifier codes listed under the t Response column. The master devicee may transmiit to outstationns function annd fier codes listed d under the Req quest column if the outstationn supports them m. qualifi Wheree the Responsee column is sh haded, the table row is not aapplicable to m master parsing. An example oof this is a table row rep presenting variiation 0 of an object o for outsttation parsing.




12.2.2 2 Parsing guideline tablles Table 12-33—g0 0 device attrib bute objects s Request (outsstation must parsee ) Group p Variation Function codes Qualifier Q codes (decim (hexadecimal ) mal) 0 209 - 239 1 (READ) 00 0 0 240 1 (READ) 00 0 0 240 2 (WRITE) 00 0 0 241 - 243 1 (READ) 00 0 0 245 - 247 1 (READ) 00 0 0 245 - 247 2 (WRITE) 00 0 0 248 - 250 1 (READ) 00 0 0 252 1 (READ) 00 0 0 254 1 (READ) 00, 0 06 0 255 1 (READ) 00, 0 06

Response (m master shall parsse ) Functioon codes Qualifier codes (hexadecimal ) (deciimal) 129 (RESPONSE ) 00, 17 129 (RESPONSE ) 00, 17 129 (RESPONSE ) 129 (RESPONSE )

00, 17 00, 17

129 (RESPONSE ) 129 (RESPONSE )

00, 17 00, 17

129 (RESPONSE )

00, 17

Table e 12-34—g1 binary b input static objectts Request Response (outsstation must parsee ) (m master shall parsse ) Group p Variation Function codes c Qualifier Q codes Function n codes Qualifier codes (hexadecimal ) (decima al) (hexadecimal ( ) (decim mal) 1 0 1 (READ) 00 0, 01, 06, 17, 28 1 0 22 (ASSIGN_CLA ASS ) 00 0, 01, 06, 17, 28 1 1 1 (READ) 00 0, 01, 06, 17, 28 129 (RESPONSE ) 00, 01, 17, 28 1 2 1 (READ) 00 0, 01, 06, 17, 28 129 (RESPONSE ) 00, 01, 17, 28

Table e 12-35—g2 binary b input event objectts Request Response (outsstation must parsee ) (m master shall parsse ) Group p Variation Function codes Qualifier Q codes Functioon codes Qualifier codess (decim (hexadecimal ) mal) (deciimal) (hexadecimal ) 2 0 1 (READ) 06, 0 07, 08 2 1 1 (READ) 06, 0 07, 08 129 (RESPONSE ) 17, 28 2 1 130 (UNSOL_RE ESP) 17, 28 2 2 1 (READ) 06, 0 07, 08 129 (RESPONSE ) 17, 28 2 2 130 (UNSOL_RE ESP) 17, 28 2 3 1 (READ) 06, 0 07, 08 129 (RESPONSE ) 17, 28 2 3 130 (UNSOL_RE ESP) 17, 28

Table 12-36 6—g3 double e-bit binary iinput static o objects Request Response (outsstation must parsee ) (m master shall parsse ) Group p Variation Function codes c Qualifier Q codes Function n codes Qualifier codes (hexadecimal ) (decima al) (hexadecimal ( ) (decim mal) 3 0 1 (READ) 00 0, 01, 06, 17, 28 3 0 22 (ASSIGN_CLA ASS ) 00 0, 01, 06, 17, 28 3 1 1 (READ) 00 0, 01, 06, 17, 28 129 (RESPONSE ) 00, 01, 17, 28 3 2 1 (READ) 00 0, 01, 06, 17, 28 129 (RESPONSE ) 00, 01, 17, 28




Table 12-37—g4 double-bit binary input event objects

Table 12-38—g10 binary output static objects

Table 12-39—g11 binary output event objects

Table 12-40—g12 binary output command objects




Table 12-41—g13 binary output command event objects

Table 12-42—g20 counter static objects

Table 12-43—g21 frozen counter static objects




Table 12-44—g22 counter event objects

Table 12-45—g23 frozen counter event objects

Table 12-46—g30 analog input static objects




Table 12-47—g31 frozen analog input static objects

Table 12-48—g32 analog input event objects




Table 12-49—g33 frozen analog input event objects Request Response (outstation must parse) (master shall parse) Group Variation Function codes Qualifier codes Function codes Qualifier codes (decimal) (hexadecimal) (decimal) (hexadecimal) 33 0 1 (READ) 06, 07, 08 33 1 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 1 130 (UNSOL_RESP) 17, 28 33 2 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 2 130 (UNSOL_RESP) 17, 28 33 3 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 3 130 (UNSOL_RESP) 17, 28 33 4 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 4 130 (UNSOL_RESP) 17, 28 33 5 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 5 130 (UNSOL_RESP) 17, 28 33 6 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 6 130 (UNSOL_RESP) 17, 29 33 7 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 7 130 (UNSOL_RESP) 17, 28 33 8 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 33 8 130 (UNSOL_RESP) 17, 28

Table 12-50—g34 analog input deadband objects

Table 12-51—g40 analog output status objects




Table 12-52—g41 analog output command objects

Table 12-53—g42 analog output event objects




Table 12-54—g43 analog output command event objects Request Response (outstation must parse) (master shall parse) Group Variation Function codes Qualifier codes Function codes Qualifier codes (decimal) (hexadecimal) (decimal) (hexadecimal) 43 0 1 (READ) 06, 07, 08 43 1 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 1 130 (UNSOL_RESP) 17, 28 43 2 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 2 130 (UNSOL_RESP) 17, 28 43 3 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 3 130 (UNSOL_RESP) 17, 28 43 4 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 4 130 (UNSOL_RESP) 17, 28 43 5 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 5 130 (UNSOL_RESP) 17, 28 43 6 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 6 130 (UNSOL_RESP) 17, 29 43 7 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 7 130 (UNSOL_RESP) 17, 28 43 8 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 43 8 130 (UNSOL_RESP) 17, 28

Table 12-55—g50–g52 time information objects




Table 12-56—g60 class information

Table 12-57—g70 file objects

Table 12-58—g80–g83 information objects




Table 12-59—g85–g88 data set objects

Table 12-60—g90 application & status of operation information objects

Table 12-61—g101, g102 numeric static objects




Table 12-62—g110–g113 string and virtual terminal static and event objects

Table 12-63—g120–g122 security objects Request Response (outstation must parse) (master shall parse) Group Variation Function codes Qualifier codes Function codes Qualifier codes (decimal) (hexadecimal) (decimal) (hexadecimal) 120 0 22 (ASSIGN_CLASS) 06 120 1 32 (AUTHENTICATION_REQ) 5B 131 (AUTHENTICATION_RESP) 5B 120 2 32 (AUTHENTICATION_REQ) 5B 131 (AUTHENTICATION_RESP) 5B 120 3 1 – 31 (ANY) 07 (Qty = 1) 129 (RESPONSE) 07 (Qty = 1) 120 3 130 (UNSOL_RESP) 07 (Qty = 1) 120 4 32 (AUTHENTICATION_REQ) 07 (Qty = 1) 120 5 131 (AUTHENTICATION_RESP) 5B 120 6 32 (AUTHENTICATION_REQ) 5B 120 7 33 (AUTH_REQ_NR) 5B 131 (AUTHENTICATION_RESP) 5B 120 8 32 (AUTHENTICATION_REQ) 5B 120 9 1 – 31 (ANY) 5B 129 (RESPONSE) 5B 120 9 130 (UNSOL_RESP) 5B 120 10 32 (AUTHENTICATION_REQ) 5B 120 11 32 (AUTHENTICATION_REQ) 5B 120 12 131 (AUTHENTICATION_RESP) 5B 120 13 32 (AUTHENTICATION_REQ) 5B 120 14 32 (AUTHENTICATION_REQ) 5B 120 15 32 (AUTHENTICATION_REQ) 5B 131 (AUTHENTICATION_RESP) 5B 00, 01, 06, 17, 121 0 1 (READ) 28 00, 01, 06, 17, 121 0 22 (ASSIGN_CLASS) 28 00, 01, 06, 17, 121 1 1 (READ) 129 (RESPONSE) 00, 01, 17, 28 28 00, 01, 06, 17, 122 0 1 (READ) 28 122 1 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 122 1 130 (UNSOL_RESP) 17, 28 122 2 1 (READ) 06, 07, 08 129 (RESPONSE) 17, 28 122 2 130 (UNSOL_RESP) 17, 28




Table 12-64—Function codes not used with objects




13

IP networking

13.1

IP netwo orking overv view

This standard defines the method for f transporting g DNP3 messagges over the Innternet Protocool suite. 13.1.1 1 IP networking purpose e DNP3 was originally y designed for serial point-to-point SCADA A communicatiion (e.g., RS-232) with limiteed plex serial nettworks (e.g., RS-485). R Manny users recoggnized a needd for devices to supporrt for half-dup exchan nge DNP3 messsages over hig gh-speed digitaal networks. T This standard ddefines how to transport DNP P3 traffic across a netwo ork using the Internet Protoco ol suite. 13.1.2 2 IP networking scope This standard applies to all end dev vices that can interpret i and geenerate DNP3 messages on a local (LAN) oor a network (W WAN). It doess not cover dev vices that pass messages thatt may contain D DNP3 as part oof wide area the neetwork infrastrructure (e.g., routers, switch hes, gatewayss, etc.) or devvices that perfform a physiccal converrsion of the data d (e.g., brid dges, port serv vers, modems,, etc.). This sstandard emplooys the Internnet Protoccol suite for meessage transporrt and does nott redefine any oof the existing DNP3 layers. 13.1.3 3 IP networking suite an nd device ide entification The In nternet Protoco ol suite is someetimes referred d to as the TCP P/IP protocol. F For this docum ment, the Internnet Protoccol suite is defiined to includee the protocols specified in IE ETF RFC 793 ((TCP), IETF R RFC 768 (UDP P), and IE ETF RFC 791 (IP). ( Throu ughout this docu ument, the term m “device” as it applies to a D DNP3 device m may be interprreted to be eithher a physsical unit (e.g.,, a standalone product, RTU, IED, etc.) orr a logical entitty within a phyysical unit (e.gg., logicaal RTU, virtual IED, etc.). 13.1.4 4 Protocol stack s The most m attractive reasons r for cho oosing the Inteernet Protocol ssuite as a transsport mechanism for DNP3 aare as folllows: ⎯ Seamless in ntegration of th he SCADA LA AN to the corpoorate WAN ⎯ Leverage ex xisting equipm ment and standaards The In nternet Protoco ol suite is platfo orm independeent and supportted universallyy. It is highly sccalable (LAN to WAN)), and many qu uality implementations exist for f both embeddded and workkstation operating systems. Thhe growth h of the Intern net has fueled d the large availability of eequipment andd has proved tthat the Internnet Protoccol suite is capaable of transpo orting tremendo ous quantities aand types of daata. The In nternet Protoco ol suite and DNP3 D use a lay yering paradiggm; each piecee of the protoccol stack in onne station n logically com mmunicates wiith the correspo onding piece iin the other staation(s). It is thherefore easy tto build DNP3 D “on top of" the Interneet Protocol suite since the Intternet layers apppear transpareent to the DNP P3 layers (see Figure 13 3-1).




Figure 13--1—Protocoll stack This subclause s speciifies how to lin nk the DNP3 layers l with thee Internet Protoocol suite layerrs as well as thhe config guration param meters and meth hods to facilitaate the networkk connection. T The “Connectioon Managemennt Layer”” encapsulates this functionallity.

13.2

Layer requirements s

13.2.1 1 DNP3 link k, transport, and a application The DNP3 D Link, Trransport and Application A Lay yer definitionss, described thhroughout this standard, apply equally when commu unicating oven n serial channels as over IP nnetworks, exceppt for the time synchronizatioon metho ods described in i 10.3. Link frames f are tran nsported unchaanged over thee Internet Protoocol suite undder the con ntrol of the con nnection manaagement layer. 13.2.1 1.1 Confirmations Devices shall not transmit t confiirmed Data Link Layer fraames (CONFIR RMED_USER R_DATA) wheen municating via the Internet Protocol suitte. Applicationn Layer conffirmation is tthe same wheen comm comm municating overr IP networks as a over serial ch hannels. 13.2.1 1.2 Message e transfer Once the connection n managementt layer has estaablished a TCP P connection oor provided a socket for UD DP L may transsfer frames as needed. The tyype of polling, either soliciteed datagrrams, the DNP3 Data Link Layer or unssolicited, is ind dependent from m the connecttion establishm ment. For exam mple, a typicall case is for thhe masterr to establish a TCP connecttion with an outstation, o perfform a Class 11,2,3,0 request (integrity polll), enablee unsolicited reesponses, and operate o in an un nsolicited modde from then onn.




13.2.2 2 Internet Protocol P suite e The In nternet Protoco ol suite is com mposed of seveeral protocols tthat work togeether to providde data transpoort services. The interfface between the connection n managemennt layer and thhe protocol suuite is typically mented with an n Application Programming Interface (APII) into the IP T Transport Layeer with the moost implem comm mon being a “so ockets” interfacce (either Berkeeley or Winsocck derived). 13.2.2 2.1 Configuration requirrements The In nternet Protoco ol suite is com mposed of two protocols at tthe Transport L Layer. Each iss designed for a specifi fic type of dataa delivery depeending on the characteristicss of the networrk and the endd devices. DNP P3 network devices shalll support the use u of both TCP and UDP. a))

Master stations shall prov vide the abilitty to select thee type of Interrnet Protocol cconnection with which to esstablish commu unication with an outstation. The selectionns shall be (1) a TCP initiatinng end point, (2) a datagram end point, or (3) a TCP dual end point.

b)) Outstations shall provide the ability to select s the typee of Internet Prrotocol connecction with whicch h communicatio on with a mastter station. Thee selections shhall be (1) a TC CP listening ennd to establish point or (2)) a datagram en nd point. The outstation o mayy also offer thee option of (3) a TCP dual ennd point. NOTE—Theese selection requ uirements denotte functional cappabilities. The acctual naming, styyle, and manner of the configuraation options aree device specific.

c))

An outstatiion may proviide multiple end points to ssupport multipple master stattions. A mastter station shou uld provide mu ultiple end poin nts to support m multiple outstattions. See 13.22.3.5.

13.2.2 2.2 Registerred port num mber The po ort number 20 000 has been registered r with h the IANA (Innternet Assigneed Numbers Auuthority) for use with DNP3. D All DN NP3 network devices shall support comm munications ussing this port number. DNP P3 network devices usin ng TLS shall ad dditionally sup pport port numbber 19 999. Seee 7.8.8. 13.2.2 2.2.1

Optio onal port num mbers

DNP3 network devices are free to o use additionaal Internet Portt numbers as llong as the bassic requiremennts e an ouutstation manuufacturer may wish to providde for using the DNP3 port number are met. For example, port redundanccy features or alternate com mmunication ennd points in thhe other TCP listening ports to supp a to chang ge the Internet destination porrt numbers andd addresses useed devicee. Masters shall provide the ability for esttablishing a con nnection with an a outstation. 13.2.2 2.3 IP addre ess assignme ent This document d does not specify thee method for IP P address assiggnment for DN NP3 devices. 13.2.3 3 Connectio on managem ment 13.2.3 3.1 TCP usa age TCP iss the recommended transportt protocol to usse for most DN NP3 network coonnections. It hhas facilities thhat substaantially improv ve the reliability y of the data trransfer and is tthe best choicee for wide areaa networks. TC CP provid des a serial daata stream betw ween devices for the DNP33 Data Link L Layer and thuss may assist thhe integraation with exissting serial imp plementations. Since TCP is a connection-ooriented protoccol, both devicees shall participate p in th he defined syncchronization sccheme in orderr to establish thhe connection.




13.2.3.1.1

Initiating end point

Masters shall support a TCP initiating end point. A master in this mode initiates the connection by performing a TCP active open. 13.2.3.1.2

Listening end point

Outstations shall support a TCP listening end point. An outstation in this mode listens for a connection request by performing a TCP passive open. 13.2.3.1.3

Dual end point

Masters shall support and outstations may support a TCP dual end point. A dual end point is defined as a process that can both listen for connection requests and perform an active open on the channel if required. If the device does support a dual end point, only one connection shall be in place to the same connecting device at the same time. The quiescent state of both the master and the outstation is in listen mode. Either side may initiate the connection; the master to send controls, integrity polls, etc. and the outstation to report the initial null response and unsolicited data. Once the connection is established, it may or may not be kept open by both ends. Either end may choose to close the connection after data transfer is complete or on a device-specific timeout. Each side shall return to the listen mode after the connection is closed. If both sides simultaneously initiate the connection, the connection initiated by the master shall be maintained while the other shall be dropped (i.e., the master has priority on the creation of TCP connections). See 13.5 for the UML statecharts describing dual end point operation. These statecharts are provided to give guidance when implementing dual end points and do not provide all of the details necessary for DNP3 message transfer. 13.2.3.1.4 a)

Basic requirements

Outstations shall support a listening end point. Outstations may support a dual end point. An outstation should provide the ability to validate connection requests from masters by IP address.

b) Master stations shall support both an initiating end point and a dual end point. A master operating as a dual end point shall provide the ability to validate connection requests from outstations by IP address. c)

Master stations shall be able to initiate a TCP connection with an outstation to port number 20 000. Outstations shall be able to listen for connection requests on port 20 000. Masters shall and outstations should provide the option to operate on other port numbers.

d) Outstations configured as dual end points shall be able to initiate a TCP connection with a master to port number 20 000. Masters configured as dual end points shall be able to listen for connection requests on port 20 000. Masters shall and outstations should provide the option to operate on other port numbers. 13.2.3.1.5 a)

Configuration parameter guidance

If an outstation supports a dual end point, it shall provide a configuration option that determines the end point type. This option shall have these selections: (1) listening end point or (2) dual end point.

b) If an outstation supports a dual end point, it shall provide configuration parameters setting the IP address and port number of the master with which to make a connection.




c)

An outstation should provide a configuration parameter setting the IP address of the master to support connection validation.

d) Masters shall provide a configuration option that determines the end point type. This option shall have these selections: (1) initiating end point or (2) dual end point. e)

Depending on the type of multiple master support, outstations shall provide configuration parameters setting the IP address of the master or the listening port number.

f)

Masters shall provide configuration parameters setting the IP address and port number for each outstation.

g) Masters shall provide a configuration option to set the DNP3 destination address for each logical device in an outstation. The DNP3 destination address should be unique for all logical devices within an outstation. 13.2.3.2 UDP usage All IP network devices shall support the UDP transport protocol (IETF RFC 768). UDP provides the ability to broadcast to multiple destinations on a subnet. UDP can also be used on a highly reliable network where the additional overhead of TCP reliability is not needed. Because of its connectionless design, UDP has a lower octet overhead than TCP. This characteristic is important for pay-per-byte networks such as Cellular Digital Packet Data (CDPD). 13.2.3.2.1

UDP ports

Table 13-1 outlines the basic requirements for assignment and configuration of ports when using UDP.




The port number to which the master sends requests and confirmations must be configurable. 20 000 must be one of the choices.

Pm may have any value. It shall be the port at which the master expects to receive responses.

Piu may be fixed at 20 000 or configurable. If configurable, 20 000 must be one of the choices.

The port number to which the master sends requests and confirmations must be configurable. 20 000 must be one of the choices.

Pm may have any value. It shall be the port at which the master expects to receive responses.

Master must be able to broadcast either to port 20 000 or a configurable port number. If configurable, 20 000 must be one of the choices.

Pm may have any value.

Master requirements


381

UDP With Unsolicited Messages

UDP No Unsolicited Messages

TCP

Pictorial

Table 13-1—UDP port requirements


Outstation must be configurable to send responses to: Case 1: A fixed port at master. Case 2: The port from which the master sent request.

Initial unsolicited response sent to either 20 000 or to a configurable port number. If configurable, 20 000 must be one of the choices.

Po must either be fixed at 20 000 or configurable. If configurable, 20 000 must be one of the choices.

Outstation must be configurable to send responses to: Case 1: A fixed port at master. Case 2: The port from which the master sent request.


The outstation shall not restrict or qualify from which master port, Pm, it will accept broadcast datagrams.


The outstation must provide a UDP port, Po, to accept broadcast datagrams from the master.

Outstation requirements


13.2.3.2.2 a)

Basic requirements

Masters shall provide configuration setting the IP address and port number for each outstation.

b) Masters shall send request and confirmation datagrams from the same UDP port where they expect to receive responses. c)

A master shall provide user configuration for the outstation IP addresses from which it will accept UDP responses. The master may reject responses from all other IP addresses.

d) An outstation shall be configurable to accept UDP requests only from specific master IP addresses or from any IP address. e)

When using TCP, outstations should only accept broadcast UDP messages from masters whose IP address is associated with a valid TCP end point.

13.2.3.2.3

Multiple frames

A master station shall be capable of parsing multiple DNP3 Data Link Layer frames from a single UDP datagram. A DNP3 Data Link Layer frame shall not span multiple UDP datagrams. 13.2.3.2.4

Broadcast address

If UDP is used to broadcast a datagram to multiple devices on a LAN, the DNP3 address shall be set to one of the DNP3 broadcast addresses (0xFFFF, 0xFFFE, or 0xFFFD) and all logical DNP3 devices at all IP addresses on the subnet must process the encapsulated DNP3 Data Link Layer frame. Examples of broadcast events include freezes, enable/disable unsolicited, and time sync. NOTE—Routers typically are not configured to forward broadcast messages. In practice, broadcast messages are only effective on a subnet.

13.2.3.3 TCP connection status If the listening end point of a TCP connection goes down (without purposely being disconnected by the software) and comes back up, the other end has no way of knowing until it sends a message. All DNP3 devices are required to provide a keep-alive mechanism as described in 13.2.3.3.1 so that each end of the connection can determine the on-line status of the other end when appropriate. NOTE 1—TCP provides a keep-alive timer, but a typical implementation is 2 hours, which is not sufficient for the critical nature of the data carried by DNP3. Some Internet Protocol implementations allow this timeout to be changed, but this capability is not universal.

Outstations shall reject new connection requests from a master station that is already connected if the master initiated the connection. NOTE 2—An outstation may transmit a keep-alive message on the current connection when a new connection request is received in order to immediately determine the status of the current connection.

13.2.3.3.1

Keep-alive mechanism

All masters and outstations shall incorporate a keep-alive timer to monitor the status of an active TCP connection. This timer shall be restarted whenever any message is received from the other end. If the timer times out, the device shall transmit a keep-alive message. The keep-alive message shall be a DNP3 Data Link Layer status request (REQUEST_LINK_STATUS). If a response is not received to the keep-alive message, the connection shall be deemed broken and the appropriate action taken (see Table 13-2).




Devices shall not explicitly disable transmission of keep-alive messages but may set the keep-alive interval sufficiently large to disable their transmission during periods of normal communication. As an example, in a polled environment, the time between normal polls for data may be shorter than the keep-alive interval. Each timely received poll request restarts the keep-alive timer, and as a result, the timer never times out. The device would only transmit keep-alive messages if polling were to cease. NOTE—In a testing environment, it may be advantageous for a device to provide the ability to effectively disable the keep-alive mechanism so that the connection is maintained when the message traffic is intentionally very low. An example would be the case where a test set is used to send specific manually generated requests and to verify the responses. In this case, testing may be simplified if the master and outstation disable their keep-alive timers or provide the ability to set the timers to a very high interval. This mode is not required nor does it nullify the keep-alive requirement described in the preceding discussion.

Keep-alive messages are only needed when the connection is open. If the keep-alive timeout is configurable, the vendor should publish the default keep-alive timer value as well as the range in the Device Profile. 13.2.3.3.2

Broken connections

Table 13-2 describes the handling of broken TCP connections. Table 13-2—Handling broken TCP connections Device

Symptom

Action

1

master

Loss of power or restart

Issue new connection request.

2

outstation

Loss of power or restart

3

master

Failure to receive a response to a keep-alive message

Either create new listening end point or initiate connection to generate unsolicited response if configured as a dual end point. Close connection. If a new connection is required, issue a new connection request.

4

outstation

Failure to receive a response to a keep-alive message

5

master

6

outstation

Receive TCP RST (IETF RFC 793) flag indicating that the outstation has reset the connection Receive TCP RST (IETF RFC 793) flag indicating that the master has reset the connection

13.2.3.3.3

Configured as: Listening end point—close connection and commence listening for new connections. Dual end point—close connection, commence listening for new connections, and wait for need to connect. Close connection. If a new connection is required, issue a new connection request. Configured as: Listening end point—close connection and commence listening for new connections. Dual end point—close connection, commence listening for new connections, and wait for need to connect.

Closed connections

Table 13-3 describes the handling of closed TCP connections.




Table 13-3—Handling closed TCP connections Device

Symptom

Action

1

master

Receive TCP FIN flag indicating that the outstation has closed the connection

Close connection and issue new connection request.

2

outstation

Receive TCP FIN flag indicating that the master has closed the connection

Configured as: Listening end point—close connection and commence listening for new connections. Dual end point—close connection, commence listening for new connections, and wait for need to connect.

13.2.3.4 Single master connection Figure 13-2 depicts the TCP connection between a single master and outstation with the master configured as the initiating end point and the outstation as the listening end point. Alternatively, both devices may be configured as dual end points if the outstation supports it.




Figure 13-2—Single master connection In this setup, the outstation listens on port 20 000 and the master makes a connection request to the IP address of the outstation at port 20 000. An outstation may support more than one logical DNP3 device; in which case, each logical device is accessed by a unique DNP3 destination address. The master shall have a corresponding configuration table for each logical device. The outstation shall maintain a set of state information (i.e., an association) for each logical device. 385 Copyright © 2012 IEEE. All rights reserved.



13.2.3.4.1

Requirements

All masters and outstations shall support a single master connection at port 20 000. 13.2.3.5 Multiple master connections In some systems, it is desirable to have multiple DNP3 master stations simultaneously accessing the same outstation. This may be required for some redundant schemes or if there are multiple users of the outstation data. Such a setup can require that the outstation have some manner for uniquely identifying the various masters depending on how the data needs to be reported. Each master may need access to different data or have different access permissions. The outstation shall maintain a set of state information that may consist of variables and event buffers for each master with which it communicates. There are a few different methods for establishing connections between multiple masters and an outstation. The following subclauses define the methods applicable to DNP3. All methods require a single physical network connection and allow, but do not require, an outstation to have multiple DNP3 logical devices within the physical device. 13.2.3.5.1

Connection establishment—method 1

Connection based on master IP address (Figure 13-3).

Figure 13-3—Connection based on master IP address This method requires that each collection of logical DNP3 devices has a unique and defined address of the DNP3 master. When a connection request is accepted, the connection management layer assigns the socket to the collection with the matching source IP address and proceeds to route all DNP3 messages from that master to this collection of logical devices. The individual logical devices are accessed in the collection based on the DNP3 destination address.




13.2.3.5.2


Connection based on IP port number (Figure 13-4).

Figure 13-4—Connection based on port number This method requires the connection management layer to listen on different TCP ports. Each collection of logical DNP3 devices is assigned to a specific port so the DNP3 message routing is predefined. The individual logical devices are accessed in the collection based on the DNP3 destination address. 13.2.3.5.3


All connections accepted for browsing static data (Figure 13-5).




Figure 13-5—All connections accepted for browsing static data This method is useful for allowing multiple masters to connect with the outstation to “browse” for static data. The outstation allows connections from any master. The outstation simply responds to requests for data based on the DNP3 destination address. The outstation may be configured to limit the IP addresses that can establish a connection. It is also possible to support events by mapping, through configuration, the logical DNP3 devices to the DNP3 destination address and requiring each master to only access specific logical devices. 13.2.3.5.4

Requirements

Outstations are not required to support multiple master connections. If an outstation supports multiple master connections, it shall provide connection establishment using method 1 outlined in 13.2.3.5.1. If an outstation supports multiple master connections, it should provide connection establishment using method 2 outlined in 13.2.3.5.2. If an outstation supports multiple master connections, it may provide connection establishment using method 3 outlined in 13.2.3.5.3.




13.2.3.6 Multiple outstation connections In most systems, it is desirable to have multiple DNP3 outstations simultaneously accessible from a master station. The master shall be configurable to support the characteristics of the utility network so that it can make a connection with all outstations. Figure 13-6 depicts TCP connections between a single master with a single physical network connection and multiple outstations. The master is configured as the initiating end point. Alternatively, both ends of any of the connections may be configured as dual end points if the outstation supports it.

Figure 13-6—Multiple outstation connections 13.2.3.6.1

Requirements

Master stations should support multiple outstation connections. If a master supports multiple outstation connections, it shall provide the ability to configure the destination IP address of the outstation and the destination port number of the outstation. 389 Copyright © 2012 IEEE. All rights reserved.



13.3

Security y

13.3.1 1 Rudimenttary All deevices should be able to lim mit connection n establishmennt based on IIP address, adddress range, oor validaation features provided p by hiigher level seccurity layers. T This recommenndation is desiigned to proteect againsst incorrectly configured c systtems where mu ultiple devicess attempting coonnections to tthe same devicce may cause data loss or inadvertent commands. 13.3.2 2 Advanced d Refer to Clause 7 forr information on o DNP3 Securre Authenticatiion. 13.3.3 3 External Virtuaal private network (aka VPN)) routers and secure s Internet Protocols (e.gg., IPSec) are rrecommended to provid de site-to-site security, in acco ordance with th he security pollicies of the orgganization.

13.4

Time syn nchronization

The so ource of the tim me on the netw work is system dependent andd may be a masster station or a dedicated tim me serverr. Time can be distributed on the network ou utside of DNP 3 using variouus standardizedd methods. It caan also bee distributed, with w some limittations, using specific s DNP3 messages. See 10 0.3 for the DNP P3 network tim me synchronizaation method.

13.5

UML statecharts

13.5.1 1 Dual end point—master Figure 13-7 depicts the master stattion statechart for dual end pooint.




Legend Iniit

SLISTEN – Socket listening g for connection n requests from outsstation SIN – Soccket initiated by outstation to maaster SOUT – So ocket initiated by b master to outsstation S’ IN – So ocket initiated by y outstation to master m while already connected

do: • Create sockket S LISTEN for incoming coonnections • Bind to port rt • Put in listenn mode

Connecction failed

CreaateConnection n do: • Creatte socket S OUT for f outgo oing connection • Conn nect to outstation n

Requestt pending (e.g. Inttegrity poll , control//setpoint, etc.)

Connectio on success / use S OUT

Conn nected W WaitForNeed dToConnect [RequestPeending] [Else ]

SeendRequest

Responsee Not Expectted

Socket error or connection closed by peer / closee socket

Resp ponse Expected Requ uest Pending

WaitForResp R Receive Respon nse

Idle Idlee Timeout (o optional)

# of no respponses > threshold / close socket Disconnect / close socket

Keep-Alive Timeout

Incominng connection on SLISTTEN / use S IN

SendLinkSttatusRequest

Un nsolicited respon nse / pro ocess response and a sen nd confirm

If usin ng S IN and incom ming connecction S’ IN on SLISTEN L / rejectt S’ IN

If ussing S OUT and incooming connectioon S’ INN on SLISTEN / cloose S’ INN

Figure 13-7— —Master stattion statecha art for dual e end point 13.5.2 2 Dual end point—outsttation Figure 13-8 depicts the outstation statechart for dual d end point..




Figure 13-8—Outstation statechart for dual end point




14

Interopera ability

14.1

About th his clause

14.1.1 1 Purpose of o this clause e This clause c presentss a standard tem mplate for desscribing configguration param meters associateed with a DNP P3 devicee and defines th he implementaation subsets, or o levels, for thhe DNP3 Application Layer. It is intended to be useed as a referen nce for determ mining compatib bility betweenn implementatiions of the DN NP3 Applicatioon Layer.. This clause c describees several subssets of the protocol, for the purpose of givving vendors aand customers a comm mon set of termss for describing g what they have implementeed and what theey require, resppectively. 14.1.2 2 Who shou uld use this clause c This clause c is intend ded to be used by the followiing people, althhough its audieence is not neccessarily limiteed to thosse listed here: ⎯ Designers responsible r for determining what w portion off the protocol too implement. ⎯ Systems engineers respon nsible for determ mining compattibility betweenn components of a network. ⎯ Purchasing agents or ceertification ageencies responssible for deteermining whetther a vendorr’s product meets customers’ standards. 14.1.3 3 How this clause c is org ganized The orrganization of this t clause is described d as folllows: 14.2 Overview O desccribes basic con ncepts concern ning DNP3 subbsets: basic term minology, how w to interpret thhe implem mentation tables, and the du uties of devices implementinng the subsets. It briefly disccusses the goaals used to o develop the subsets. s 14.3 Level L 1 DNP3 implementation (DNP3-L1) describes thee minimum subbset of the prottocol that can bbe implem mented, typically between a master m station and an IED. 14.4 Level L 2 DNP3 3 implementattion (DNP3-L2) describes a subset of thee protocol, sligghtly larger thaan Level 1. It is typicallly implemented d between a maaster station annd a large IED or small RTU. 14.5 Level L 3 DNP3 implementattion (DNP3-L3 3) describes a subset of the protocol, largeer than Level 2, that caan be implemen nted between a master station n and a more ad advanced RTU.. 14.6 Level L 4 DNP3 implementattion (DNP3-L4 4) describes a subset of the protocol, largeer than Level 3, incorp porating data ty ypes and funcction codes thaat were added to DNP3 afteer definition oof the first threee original subset levelss. 14.7 Conformance describes the conditions un C nder which a ddevice is said to conform too a given DNP P3 subsett. 14.8 XML X represeentation descrribes how the Device Profi le document iis representedd in a machinnereadab ble format to allow a for more efficient and accurate devicce setup. It alsoo allows mappping DNP3 Daata Pointss to IEC 61850 Object Modells. 14.9 Instructions fo or creating a Device D Profile document proovides the inforrmation a deviice vendor needds d implem mentation of D DNP3. to creaate a documentt describing a device’s 393 Copyright © 2012 IEEE. All rightts reserved.



14.2

Overview w

This su ubclause descrribes various co oncepts concerrning DNP3 prrotocol subsets in general. 14.2.1 1 Terminolo ogy This su ubclause defin nes some of thee terms used thrroughout this cclause. When a master or outstation satiisfies all the requirements of a particulaar DNP3 subseet, it is said to ment a particular level of thee protocol. Thee term “Level”” is chosen so as to not confflict with DNP P3 implem data classes or the OSI O concept off layers. The ab bbreviation forr a DNP3 subsset implementaation consists oof d “L” followed d by the level nu umber. “DNP3,” a dash, and For ex xample, a vend dor may be able to say, “Thiss device implem ments the DNP P3 Applicationn Layer protocol Level 1,” or just “Th his device impllements DNP3 - L1.” NOTE— —This clause specifies s only th he minimum req quirements for a particular impllementation level. A device maay implem ment extra featurres in addition to o these requiremeents and still connform. Refer to 114.7 for more deetails.

14.2.2 2 Reading the subset ta ables The subsets of the DNP3 protoccol are describ bed in a comm mon format. E Each subclause describing aan mentation leveel contains a table t having th he following ccolumns definiing the functioon and qualifier implem codes used for both request r and ressponse messages: These fields describe the set of DNP3 obj bjects, functionn codes, and quualifiers an hall be able to parse p as a part of an incominng request in orrder to have outstation sh implemented d the subset. Requeest colum mn

odes: A liist of the requeest function coddes that the outtstation shall Function Co accept as operators on this object. A liist of the qualiffier codes the ooutstation shalll parse in Qualifier Codes: w this objectt. association with ds are blank, it means the outsstation does noot need not be aable to parse thhe If these field specified objject in order to o implement thee subset. These fields describe the set of DNP3 obj bjects, functionn codes, and quualifiers a masteer device shall be able to parsse from an incooming responsse or unsoliciteed response in d the subset. Thhese fields alsoo define the minimum subset order to have implemented of responsess an outstation may make.

Respo onse colum mn

odes: A liist of the responnse function coodes the masteer shall accept aas Function Co operators on n this object. A liist of the qualiffier codes the m master shall paarse in Qualifier Codes: w this objectt. association with ds are blank, it means the masster does not nneed not be ablee to parse the If these field specified objject in order to o implement thee subset.

There are four levels of implemen ntation of DNP P3 defined with thin this docum ment. Each levvel builds on thhe p it. level preceding 394 Copyright © 2012 IEEE. All rightts reserved.



NOTE— —The subset deescribes the min nimum set of ob bjects, function ccodes, and qualiifiers the devicees should parse in order to implement thee subset. If an ob bject is supported d, it should be uused with the funnction and qualiffier codes in ordder pecify that an ou utstation should actually report iinputs, outputs, aand data for all of to impllement the subseet. It does not sp the objects in the subseet.

For ex xample, supposse a subset tablle contains the following linee:

DN NP3 OBJECT GROUP G & VAR RIATION

Group num m

30

Var num

4

Descrip ption

REQ QUEST Master may issue n shall parse Outstation Function codes (dec)

An nalog Input—16-bit without 1 (read) flaag

Qualifier codes (hex)

00, 01 (start-stop)

06

RES SPONSE Masterr shall parse Outstatiion may issue n Function codes (dec)

129 (response)

Qualifierr codes (hex)

00, 01 (start-stopp)

(no range,or alll)

......

This entry e indicates the t following: ⎯ An outstatio on shall accep pt and respond to any read rrequest (Functiion Code 1) of 16-Bit Analoog Input witho out flag objectss. The read req quest may use either 8-bit staart and stop indexes (Qualifier Code 0x00)), 16-bit start and a stop indexees (Qualifier C Code 0x01), or no range field (Qualifier Codde 0x06). The outstation neeed not parse reead requests fo for 16-Bit Anaalog Input withhout flag objeccts o Qualifier Codes. The master m device caannot include a 16-Bit Analoog Input without using any other flag object in i any request containing a fu unction code oother than read d. ⎯ The outstation need not actually a report any analog inp nputs. It may seet an Internal IIndication bit in ull response, ass discussed in C Clause 4 throuugh Clause 6. its responsee, or return a nu ⎯ A master device d shall be able to parsse a responsee (Function Coode 129) from m the outstatioon containing 16-Bit Analog g Input withou ut flag objects. The responsee shall use 8-bit start and stoop ualifier Code 0x00) 0 or 16-bitt start and stopp indexes (Quaalifier Code 0xx01). The mastter indexes (Qu device need d not parse ressponses or unso olicited responnses containingg 16-Bit Analoog Input without flag objectss using any other Qualifier Co odes. ⎯ The master need not use the t data supplieed by the outsttation for any ppurpose but cann discard it aftter y necessary con nfirmation. sending any 14.2.3 3 Goals and d assumption ns These subset definitiions were prepared with the following f goalss: ⎯ Minimize th he complexity y of implementtation. Where complexity m must be added, it was added at the master rather r than at th he outstation. ⎯ Minimize th he bandwidth used. u ⎯ Allow all daata provided by y an outstation n to be retrievedd at any level. ⎯ Allow flexibility for a varriety of differen nt, but interopeerable, implem mentations. 395 Copyright © 2012 IEEE. All rightts reserved.



It was assumed that the simpler thee outstation, th he fewer pointss it would provvide. Therefore, there would bbe less neeed for the morre complex poiint range specifications availaable in DNP3. As a result r of thesee goals and asssumptions, thee lower level ssubset definitioons are based around polls oof Class Data Objects. In a typical minimum m impllementation, itt is expected tthat a master device will pooll d interspersed with infreequent Class 0 data polls. More advanceed frequeently for Classs 1, 2, or 3 data, implem mentations maay take advan ntage of unsoliicited respons es and the m more complex polling featurees availab ble in DNP3. Qualiffiers are a com mplex part of DNP3, D so the number n of quaalifiers requireed to be suppoorted by either a masterr or an outstatiion was limited d. Table 14-1 illustrates the subset of quallifiers chosen aand the intendeed use off each qualifier. There may bee a few exceptiions to these ruules. Table 14-1—Qualifiers used in the subset defin nitions Qua alifier (h hex)

Usee in a request

Use in a respoonse

00, 01

A rang ge of static pointts, or a single po oint with a point numbeer

Static objectss

06

All po oints

Not valid

07, 08

A limiited quantity of events e A sing gle point with no o number (e.g., Time T and Date)

A single poinnt with no numbeer (e.g., Time annd Date)

17, 28

Contro ols (usually one or more unrelateed points)

Event objectss (usually one orr more unrelatedd points)

14.3

Level 1 DNP3 D imple ementation (DNP3-L1)

This subclause s describes the minimum subset of the DNP3 A Application Layyer that can bee supported annd still bee said to implem ment the proto ocol. This impleementation levvel is called Leevel 1 (L1). 14.3.1 1 Intended use u This level of impllementation iss intended to represent thhe simplest im mplementationn of DNP3 fo for municating betw ween a master and a a typical IE ED. It would ttypically be useed between a m master station oor comm data concentrator an nd a small end device (e.g., meter, m relay, auuto-recloser, orr capacitor bannk controller). It nded for use with w an outstatio on whose input and output pooints are local tto the device. is inten 14.3.2 2 General description The Level L 1 subset is based aroun nd Class Data polling, p as desscribed in 14.22.3. A Level 1 outstation shaall acceptt requests for: ⎯ READs of Class C Data Objjects ⎯ READs of Binary B Output and Analog Output objects, iif such outputss exist on the ooutstation. NOTE—If su uch objects do not n exist, the outsstation is alloweed to respond OB BJECT UNKNO OWN.

⎯ READs of specific s variatiions of group 0 (Device Attrib ibutes) objects ⎯ Control opeerations to Bin nary Outputs or o Analog Outpputs, if they eexist on the ouutstation. If succh objects do not n exist, the ou utstation is allo owed to responnd OBJECT UN NKNOWN. ⎯ WRITEs to the RESTART T Internal Indiccation 396 Copyright © 2012 IEEE. All rightts reserved.



⎯ COLD_RESTARTs ⎯ DELAY_M MEASUREMEN NTs and WRIITEs to Time and Date, if the outstationn sets the Tim me Synchronization Required d (NEED_TIM ME) Internal Inddication The vendor shall pro ovide an XML L Device Profiile that describbes the device's DNP3 impleementation. Thhis m be obtain ned by meanss other than DNP3 File T Transfer, suchh as generatedd by PC-baseed file may config guration softwaare. A Lev vel 1 master shall accept a subset of objeect variations tthat is approxximately one thhird of the tottal numbeer defined in DNP3 D but includes most basicc data types: ⎯ Binary Inpu uts and Events ⎯ Counters an nd Counter Eveents ⎯ Analog Inpu uts and Eventss ⎯ Binary and Analog Outpu ut Status The fo ollowing are sp pecifically NOT T included: ⎯ Frozen objeects ⎯ Time-stamp ped objects, with w the exceeption of Binnary Inputs bbecause Sequeence of Evennts information n is a common industry requirrement NOTE— —Although a Level 1 master sh hall be able to paarse many objectts, a Level 1 outtstation is not reqquired to generaate them. For F example, an n outstation need d not provide Bin nary Output Stattus or Analog O Output Status objjects if it does nnot controll any of these ou utputs. The outsstation may also o choose to repoort Binary Input Without Time objects instead of Binary y Input Change With W Relative Tim me objects.

A Lev vel 1 outstatio on may send unsolicited responses r of ssome objects, but this capability shall bbe config gurable. Althou ugh not required, an outstatiion device should be tested tto the applicabble subset defiinition using thhe curren nt IED certification procedurres available.366 As these proocedures are uupdated from ttime to time (aas often as annually), it is suggested d that the read der make a prractice of checcking for updates to the IE ED ures. Equipmeent purchaserss are strongly encouraged tto specify a rrequirement fo for certificcation procedu equipm ment certificatiion. 14.3.3 3 Implemen ntation table Table 14-2 describes the objects, function f codes,, and qualifierss used in a Level 1 DNP3 impplementation.

36

See http://www.dnp.org h g.




Table 14-2—Level 1 implementation (DNP3-L1)

DNP3 OBJECT GROUP & VARIATION

REQUEST Master may issue Outstation shall parse

RESPONSE Master shall parse Outstation may issue Function codes (dec)


Binary Input— Packed format

129 (response)

00, 01 (start-stop)

2

Binary Input— With flags

129 (response)

00, 01 (start-stop)

1

Binary Input Event— Without time

129 (response) 17, 28 (index) 130 (unsol. resp)

2

Binary Input Event— With absolute time


2

3

Binary Input Event— With relative time


10

0

Binary Output— Any Variation

10

2

Binary Output— Output status with flags

Group num

Var num

Description

1

1

1

2

2

12

1

Binary Command— Control relay output block (CROB)

Function codes (dec)

1 (read)


06 (no range,or all)

3 (select) 4 (operate) 5 (direct op)

17, 28 (index)

6 (dir op, no ack)

17, 28 (index)

129 (response)

00, 01 (start-stop)

129 (response)

echo of request

20

1

Counter— 32-bit with flag

129 (response)

00, 01 (start-stop)

20

2


129 (response)

00, 01 (start-stop)

20

5

Counter— 32-bit without flag

129 (response)

00, 01 (start-stop)

20

6


129 (response)

00, 01 (start-stop)

22

1

Counter Event— 32-bit with flag


22

2











Analog Input— 32-bit with flag

129 (response)

00, 01 (start-stop)

2


129 (response)

00, 01 (start-stop)

30

3

Analog Input— 32-bit without flag

129 (response)

00, 01 (start-stop)

30

4


129 (response)

00, 01 (start-stop)

32

1

Analog Input Event— 32-bit without time


32

2



40

0

Analog Output Status— Any Variation

40

2

Analog Output Status— 16-bit with flag

Group num

Var num

Description

30

1

30

41

2

Analog Output— 16-bit


1 (read)


06 (no range, or all)


17, 28 (index)

6 (dir. op, no ack)

17, 28 (index)

2 (write)

07 (limited qty = 1)

129 (response)

00, 01 (start-stop)

129 (response)

echo of request

1

Time and Date— Absolute time

51

1

Time and Date CTO— Absolute time, synchronized

129 (response) 130 (unsol. resp)

07 (limited qty) (qty = 1)

51

2

Time and Date CTO— Absolute time, unsynchronized



52

1

Time Delay— Coarse

129 (response)


52

2

Time Delay— Fine

129 (response)


50




Table 14-2—Level 1 implementa ation (DNP3--L1)

DNP3 OBJECT GR ROUP & VARIA ATION

REQUE EST Master maay issue Outstation s hall parse

Group p num

Var num

Description n

Fun nction codes (dec)

Qualifier codees (hex)

60

1

Class Objectss— Class 0 dataa

1 (read)

06 (no range, or alll)

2


3


60

4


80

1

Internal I Indicatio ons— Packed form mat

60

60

14.4

1 (read)

1 (read) 1 (read) 2 (write)

No Object (fun nction code only y)

0 (confirm)


13 (cold restart)


23 (delay meeasurement)

RESPONSE Masterr shall parse Outstattion may issue n Function codes (dec)

Qualifierr codes (hex)

06 (no range, or alll) 07, 08 (limited qty) 06 (no range, or alll) 07, 08 (limited qty) 06 (no range, or alll) 07, 08 (limited qty) 00 (start-stop)) index=7


This subclause s descrribes the secon nd smallest sub bset of the DN NP3 Applicatioon Layer. This implementatioon level is i called Level 2 (L2). 14.4.1 1 Intended use u This leevel contains a few more feattures than the Level L 1 implem mentation. It iss intended for ccommunicationns between a master staation or data co oncentrator and d a device that could be calleed either a largee IED or a smaall put points of su uch a device woould be local too the device. RTU. Typically, the input and outp 14.4.2 2 General description A Lev vel 2 outstation n implementatio on is the same as a Level 1 ooutstation impllementation wiith the followinng additio ons: ⎯ A Level 2 outstation acccepts FREEZE E requests on Binary Countter objects (noot Analog Input F Counterrs). objects or Frozen ⎯ A Level 2 outstation o parsees READ requeests for variatioon 0 of specifiic objects. 400 Copyright © 2012 IEEE. All rightts reserved.



⎯ A Level 2 outstation parrses READ req quests for variiations 1, 2, annd 3 of Binarry Input Changge objects. ⎯ A Level 2 outstation parses READ req quests for Frozzen Counter obbjects and maay report Frozeen F Delta Counters). C Counter objjects (but not Frozen 14.4.3 3 Implemen ntation table Table 14-3 describes the objects, function f codes,, and qualifierss used in a Level 2 DNP3 impplementation.


DNP3 3 OBJECT GRO OUP & VARIA ATION

Group p Var num num

REQUE EST Master mayy issue Outstation sh hall parse

Description

Funcction codes (dec)

Q Qualifier codess (hex)

1 (read)

06 ((no range,or all))

RES SPONSE Masterr shall parse Outstatiion may issue Function codes (dec)


1

0

Binary Input— — Any Variation

1

1

Binary Input— — Packed format

129 (response)

00, 01 (start-stop))

1

2

Binary Input— — With flags

129 (response)


2

0

Bin nary Input Even nt— Any Variation

1 (read)

06 ((no range, or all)) 07, 08 (limited qty)

2

1

nary Input Even nt— Bin Without time

1 (read)


129 (response) 130 (unsol. resp))

17, 28 (index)

2

nary Input Even nt— Bin With W absolute tim me

1 (read)



17, 28 (index)

2

3

nary Input Even nt— Bin With W relative tim me

1 (read)



17, 28 (index)

10

0

Binary B Output— — Any Variation

1 (read)


10

2

Binary B Output— — Outtput status with flags f

129 (response)


129 (response)

echo of request

2

12

1

Biinary Command d— Contrrol relay output block (CROB)

3 (select) ( 4 (o operate) 5 (d direct op)

17, 28 (index)

6 (dir. op, no ack)

17, 28 (index)






Group Var num num


Description



1 (read) 7 (freeze) 8 (freeze noack) 9 (freeze clear) 10 (frz. cl. noack)




20

0

Counter— Any Variation

20

1


129 (response)

00, 01 (start-stop)

20

2


129 (response)

00, 01 (start-stop)

20

5


129 (response)

00, 01 (start-stop)

20

6


129 (response)

00, 01 (start-stop)

21

0

Frozen Counter— Any Variation

21

1

Frozen Counter— 32-bit with flag

129 (response)

00, 01 (start-stop)

21

2


129 (response)

00, 01 (start-stop)

21

9

Frozen Counter— 32-bit without flag

129 (response)

00, 01 (start-stop)

21

10


129 (response)

00, 01 (start-stop)

0

Counter Event— Any Variation

1



17, 28 (index)

2



17, 28 (index)

22

22

22

1 (read)

1 (read)


06 (no range, or all) 07, 08 (limited qty)






Group Var num num


Description



1 (read)




30

0

Analog Input— Any Variation

30

1


129 (response)

00, 01 (start-stop)

30

2


129 (response)

00, 01 (start-stop)

30

3


129 (response)

00, 01 (start-stop)

30

4


129 (response)

00, 01 (start-stop)

0

Analog Input Event— Any Variation

1



17, 28 (index)

32

2



17, 28 (index)

40

0


40

2


129 (response)

00, 01 (start-stop)

129 (response)

echo of request

32

32

41

50

51

51

2


1 (read)

1 (read)




17, 28 (index)

6 (dir. op, no ack)

17, 28 (index)

2 (write)


1


1




2








DNP3 3 OBJECT GRO OUP & VARIA ATION

Group p Var num num

REQUE EST Master mayy issue Outstation sh hall parse Funcction codes (dec)

Description

Q Qualifier codess (hex)

RES SPONSE Masterr shall parse Outstatiion may issue Function codes (dec)


52

1


129 (response)

07 (limited qtyy) (qty = 1)

52

2

Time Delay— Fine

129 (response)

07 (limited qtyy) (qty = 1)

60

1

Class Objects— — Class 0 data

1 (read)


2


1 (read)


60

3


1 (read)


60

4


1 (read)


80

1

Intternal Indications— Packed format

2 (write) (

00 (start-stop) index=7

60

14.5

No Object (function code only))

0 (Confirm)


13 (cold restart)


23 (delay meaasurement)


This subclause descrribes a subset of o the DNP3 Application A Layyer that contaiins more functiionality than thhe Level 2 subset. 14.5.1 1 Intended use u This level l of impleementation off DNP3 is forr communicatiing between a master and a medium-sizze outstattion device (e.g g., RTU or Datta Concentrato or). 14.5.2 2 General description A Lev vel 3 implemen ntation uses a larger range of o objects, vari ations, functioons, and qualiffier codes thann a Level 2 implementattion. 404 Copyright © 2012 IEEE. All rightts reserved.



A Lev vel 3 outstation n implementatio on is the same as a Level 2 im mplementation with the follow wing additionss: ⎯ A Level 3 outstation o shalll process read requests r for maany specific obbjects and variaations. ⎯ A Level 3 outstation o shalll process read requests r for alll group 0 (Deviice Attribute) vvariations ⎯ A Level 3 outstation sh hall process write requests ffor specific vaariations of group 0 (Devicce Attributes) objects ⎯ A Level 3 outstation o shalll process a larg ger range of reqquests with a laarger range of ffunction codess. ⎯ A Level 3 implementatio on supports enabling and dissabling unsoliccited responsess on a class-byyclass basis. A master can enable or disaable unsolicitedd responses forr Class 1, Classs 2, and Class 3 y. The request fragment may y contain one oor more of the following objeect headers onnly objects only (refer to Claause 4 through h Clause 6): 1) Class 1 (group 60, vaariation 2, qualiifier 06) 2) Class 2 (group 60, vaariation 3, qualiifier 06) 3) Class 3 (group 60, vaariation 4, qualiifier 06) ⎯ A Level 3 implementatio on supports th he assigning aand re-assigninng of data obbjects to classees y (i.e., during runtime). An assign class (Function Codde 22) requestt shall contain a dynamically Class 0, 1, 2, 2 or 3 object header h followed by one or moore static data object headerss. Several sets oof class and data d object heaaders may be contained c in a single requesst fragment (reefer to Clause 4 through Claause 6). 14.5.3 3 Implemen ntation table Table 14-4 describes the objects, function f codes,, and qualifierss used in a Level 3 DNP3 impplementation.









00, 01 (start-stop) 06 (no range, or all)

129 (response)

00, 01 (start-stop)

1 (read)


129 (response)

00, 01 (start-stop)

Binary Input Event— Any Variation

1 (read)


1


1 (read)



17, 28 (index)

2


1 (read)



17, 28 (index)

3


1 (read)



17, 28 (index)

0


1 (read)


2


1 (read)


129 (response)

00, 01 (start-stop)



17, 28 (index)

129 (response)

echo of request

6 (dir. op, no ack)

17, 28 (index)

Group Var num num

Description



0

Binary Input— Any Variation

1 (read) 22 (assign class)


1


1 (read)

1

2


2

0

1

1

2

2

2

10

10

12

RESPONSE Master shall parse Outstation may issue

1










129 (response)

00, 01 (start-stop)

1 (read)


129 (response)

00, 01 (start-stop)

5


1 (read)


129 (response)

00, 01 (start-stop)

6


1 (read)


129 (response)

00, 01 (start-stop)

0




21

1


1 (read)


129 (response)

00, 01 (start-stop)

21

2


1 (read)


129 (response)

00, 01 (start-stop)

9


1 (read)


129 (response)

00, 01 (start-stop)

10


1 (read)


129 (response)

00, 01 (start-stop)

Group Var num num

Description



0


1 (read) 7 (freeze) 8 (freeze noack) 9 (freeze clear) 10 (frz. cl. noack) 22 (assign class)


1


1 (read)

2


20

20

20

20

20

21

21

21











17, 28 (index)

1 (read)



17, 28 (index)

0

Frozen Counter Event— Any Variation

1 (read)


1

Frozen Counter Event— 32-bit with flag

1 (read)



17, 28 (index)

2


1 (read)



17, 28 (index)

0




1


1 (read)


129 (response)

00, 01 (start-stop)

30

2


1 (read)


129 (response)

00, 01 (start-stop)

30

3


1 (read)


129 (response)

00, 01 (start-stop)

4


1 (read)


129 (response)

00, 01 (start-stop)

Group Var num num

22

22

22

23

23

23

30

30

30

Description



0


1 (read)


1


1 (read)

2







32

32

40

40

40

41

41

50





17, 28 (index)

1 (read)



17, 28 (index)

0


1 (read)


1


1 (read)


129 (response)

00, 01 (start-stop)

2


1 (read)


129 (response)

00, 01 (start-stop)


17, 28 (index)

129 (response)

echo of request

6 (dir. op, no ack)

17, 28 (index)


17, 28 (index)

129 (response)

echo of request

6 (dir. op, no ack)

17, 28 (index)

1 (read)


129 (response)


2 (write)


Group Var num num

32


Description



0


1 (read)


1


1 (read)

2


1

2

1












1




2




52

1


129 (response)


52

2

Time Delay— Fine

129 (response)


1

Class Objects— Class 0 data

Group Var num num

51

51

60

60

60

2

3


Description




1 (read)


22 (assign class)


1 (read)


20 (enable unsol.) 21 (disable unsol.) 22 (assign class)


1 (read)







Table 14-4—Level 3 implementa ation (DNP3--L3) REQUEST T Master may isssue Outstation O shalll parse

DNP3 OBJECT O GROUP & VARIAT TION

Group Var num num

60

4

80

1

Description

Class C Objects— Class 3 data

— Interrnal Indications— Packed P format

Function n codes (dec)

Quaalifier codes (hex)

1 (reaad)

06 (no rrange, or all) 07, 08 (lim mited qty)

20 0 (enable unsol.) u 21 1 (disable unsol.) 22 2 (assign class)

06 (no rrange,or all)

1 (reaad)

00, 01 (sstart-stop)

2 (write)

00 (sstart-stop) iindex=7

No N Object (functtion code only)

0 (Con nfirm)


13 3 (cold reestart)


23 3 (delay measureement)

RESPONSE Master shall parse Outstatioon may issue Function cod des (dec)

Qualifieer codes (hex)

129 (response))

00, 01 (start-stoop)

NOTE— —The following g objects were previously requ uired for DNP3 Subset Level 3 conformance aand are no longger requireed as of 2007:

⎯ Binary Comm mand—Pattern control c block (g1 12v2) ⎯ Binary Comm mand—Pattern mask m (g12v3)

14.6


This subclause s descrribes a subset of the protoco ol, incorporatinng all of Levell 3 and addingg data types annd functio on codes that were w found to be b useful or were created aftter definition oof the first threee original subsset levels.. 14.6.1 1 Intended use u This level l of impleementation off DNP3 is forr communicatiing between a master and a medium-sizze outstattion (e.g., RT TU or Data Concentrator). C Level 4 may be used wheere additional capabilities aare required.




14.6.2 2 General description A Lev vel 4 outstation n implementatio on is the same as a Level 3 im mplementation with the follow wing additionss: ⎯ Self-Addresss Reservation n—If a device receives r a messsage with a deestination addrress of 0xFFFC C, and the “seelf-address” feature is suppo orted and enabbled, it shall reespond normallly with its ow wn source addrress instead of 0xFFFC. ⎯ Double-bit Binary Input Objects. O ⎯ Variations with w time for Frozen F Counterrs, Frozen Coun unter Events, annd Analog Inpuut Events. ⎯ Floating-po oint variations for f both Analo og Inputs and A Analog Outputss. ⎯ Analog Inpu ut Reporting Deadband. D ⎯ Event Objects for Binary and Analog Ou utputs. ⎯ Device Attrributes ⎯ LAN Time Synchronizatio on method 14.6.3 3 Implemen ntation table Table 14-5 describes the objects, function f codes,, and qualifierss used in a Level 4 DNP3 impplementation.




Table 14-5—Level 4 implementation (DNP3-L4) REQUEST Master may issue Outstation shall parse



Description





209

Device Attributes— Secure authentication version

1 (read)

00 (start-stop)

129 (response)

00 (start-stop) 17 (index)

210

Device Attributes— Number of security statistics per association

1 (read)

00 (start-stop)

129 (response)


211

Device Attributes— Identifier of support for user-specific attributes

1 (read)

00 (start-stop)

129 (response)


0

212

Device Attributes— Number of master-defined data set prototypes

1 (read)

00 (start-stop)

129 (response)


0

Device Attributes— 213 Number of outstationdefined data set prototypes

1 (read)

00 (start-stop)

129 (response)


0

214

Device Attributes— Number of master-defined data sets

1 (read)

00 (start-stop)

129 (response)


0

215

Device Attributes— Number of outstationdefined data sets

1 (read)

00 (start-stop)

129 (response)


216

Device Attributes— Max number of binary outputs per request

1 (read)

00 (start-stop)

129 (response)


217

Device Attributes— Local timing accuracy

1 (read)

00 (start-stop)

129 (response)


0

218

Device Attributes— Duration of timing accuracy

1 (read)

00 (start-stop)

129 (response)


0

219

Device Attributes— Support for analog output events

1 (read)

00 (start-stop)

129 (response)


Group Var num num

0

0

0

0

0






Description





220

Device Attributes— Max analog output index

1 (read)

00 (start-stop)

129 (response)


221

Device Attributes— Number of analog outputs

1 (read)

00 (start-stop)

129 (response)


222

Device Attributes— Support for binary output events

1 (read)

00 (start-stop)

129 (response)


223

Device Attributes— Max binary output index

1 (read)

00 (start-stop)

129 (response)


224

Device Attributes— Number of binary outputs

1 (read)

00 (start-stop)

129 (response)


225

Device Attributes— Support for frozen counter events

1 (read)

00 (start-stop)

129 (response)


226

Device Attributes— Support for frozen counters

1 (read)

00 (start-stop)

129 (response)


227

Device Attributes— Support for counter events

1 (read)

00 (start-stop)

129 (response)


228

Device Attributes— Max counter index

1 (read)

00 (start-stop)

129 (response)


229

Device Attributes— Number of counter points

1 (read)

00 (start-stop)

129 (response)


230

Device Attributes— Support for frozen analog inputs

1 (read)

00 (start-stop)

129 (response)


Group Var num num

0

0

0

0

0

0

0

0

0

0

0







Description





231

Device Attributes— Support for analog input events

1 (read)

00 (start-stop)

129 (response)


232

Device Attributes— Maximum analog input index

1 (read)

00 (start-stop)

129 (response)


233

Device Attributes— Number of analog input points

1 (read)

00 (start-stop)

129 (response)


234

Device Attributes— Support for double-bit binary input events

1 (read)

00 (start-stop)

129 (response)


235

Device Attributes— Maximum double-bit binary input index

1 (read)

00 (start-stop)

129 (response)


236

Device Attributes— Number of double-bit binary input points

1 (read)

00 (start-stop)

129 (response)


237

Device Attributes— Support for binary input events

1 (read)

00 (start-stop)

129 (response)


238

Device Attributes— Max binary input index

1 (read)

00 (start-stop)

129 (response)


239

Device Attributes— Number of binary input points

1 (read)

00 (start-stop)

129 (response)


1 (read)

00 (start-stop)

129 (response)


2 (write)

00 (start-stop)

1 (read)

00 (start-stop)

129 (response)


Group Var num num

0

0

0

0

0

0

0

0

0

0

0


240

241

Device Attributes— Max transmit fragment size

Device Attributes— Max receive fragment size






Description





242

Device Attributes— Device manufacturer’s software version

1 (read)

00 (start-stop)

129 (response)


243

Device Attributes— Device manufacturer’s hardware version

1 (read)

00 (start-stop)

129 (response)


1 (read)

00 (start-stop)

129 (response)


2 (write)

00 (start-stop)

1 (read)

00 (start-stop)

129 (response)


2 (write)

00 (start-stop)

1 (read)

00 (start-stop)

129 (response)


2 (write)

00 (start-stop)

248

Device Attributes— Device serial number

1 (read)

00 (start-stop)

129 (response)


249

Device Attributes— DNP3 subset and conformance

1 (read)

00 (start-stop)

129 (response)


250

Device Attributes— Device manufacturer’s product name and model

1 (read)

00 (start-stop)

129 (response)


252

Device Attributes— Device manufacturer’s name

1 (read)

00 (start-stop)

129 (response)


254

Device Attributes— Non-specific all attributes request

1 (read)

00 (start-stop) 06 (no range, or all)

Group Var num num

0

0

0

0

0

0

0

0

0

0


245

246

247

Device Attributes— User-assigned location name

Device Attributes— User assigned ID code/number

Device Attributes— User-assigned device name






Description




255

Device Attributes— List of attribute variations

1 (read)

00 (start-stop) 06 (no range, or all)

129 (response)

0

Binary Input— Any Variation



1


1 (read)


129 (response)

00, 01 (start-stop)

2


1 (read)


129 (response)

00, 01 (start-stop)

0

Binary Input Event— Any Variation

1 (read)


1


1 (read)



17, 28 (index)

2


1 (read)



17, 28 (index)

3


1 (read)



17, 28 (index)

0

Double-bit Binary Input— Any Variation



1

Double-bit Binary Input— Packed format

1 (read)


129 (response)

00, 01 (start-stop)

2

Double-bit Binary Input— With flags

1 (read)


129 (response)

00, 01 (start-stop)

Group Var num num

0

1

1

1

2

2

2

2

3

3

3

RESPONSE Master shall parse Outstation may issue Qualifier codes (hex) 00 (start-stop) 17 (index)










17, 28 (index)

1 (read)



17, 28 (index)

3

Double-bit Binary Input Event— With relative time

1 (read)



17, 28 (index)

0




10

2


1 (read)


129 (response)

00, 01 (start-stop)

11

0

Binary Output Event— Any Variation

1 (read)


1

Binary Output Event— Status without time

1 (read)



17, 28 (index)

11

2

Binary Output Event— Status with time

1 (read)



17, 28 (index)

12

0


22 (assign class)


129 (response)

echo of request

Group Var num num

4

4

4

4

10

11

12

Description



0

Double-bit Binary Input Event— Any Variation

1 (read)


1

Double-bit Binary Input Event— Without time

1 (read)

2

Double-bit Binary Input Event— With absolute time

1



17, 28 (index)










17, 28 (index)

1 (read)



17, 28 (index)

0


1 (read) 7 (freeze) 8 (freeze noack) 9 (freeze clear) 10 (frz. cl. noack) 22 (assign class)


1


1 (read)


129 (response)

00, 01 (start-stop)

20

2


1 (read)


129 (response)

00, 01 (start-stop)

20

5


1 (read)


129 (response)

00, 01 (start-stop)

6


1 (read)


129 (response)

00, 01 (start-stop)

Group Var num num



6 (dir. op, no ack)

17, 28 (index)

22 (assign class)


0

Binary Output Command Event— Any Variation

1 (read)


13

1

Binary Output Command Event— Command status without time

1 (read)

13

2

Binary Output Command Event— Command status with time

13

20

20

20

Description









129 (response)

00, 01 (start-stop)

1 (read)


129 (response)

00, 01 (start-stop)

Frozen Counter— 32-bit with flag and time

1 (read)


129 (response)

00, 01 (start-stop)

6

Frozen Counter— 16-bit with flag and time

1 (read)


129 (response)

00, 01 (start-stop)

9


1 (read)


129 (response)

00, 01 (start-stop)

10


1 (read)


129 (response)

00, 01 (start-stop)

0


1 (read)


1


1 (read)



17, 28 (index)

2


1 (read)



17, 28 (index)

0

Frozen Counter Event— Any Variation

1 (read)


Group Var num num

Description



0




1


1 (read)

21

2


21

5

21

21

21

21

21

22

22

22

23








Description





1


1 (read)



17, 28 (index)

2


1 (read)



17, 28 (index)

5

Frozen Counter Event— 32-bit with flag and time

1 (read)



17, 28 (index)

6

Frozen Counter Event— 16-bit with flag and time

1 (read)



17, 28 (index)

0




1


1 (read)


129 (response)

00, 01 (start-stop)

2


1 (read)


129 (response)

00, 01 (start-stop)

3


1 (read)


129 (response)

00, 01 (start-stop)

4


1 (read)


129 (response)

00, 01 (start-stop)

30

5

Analog Input— Single-prec flt-pt with flag

1 (read)


129 (response)

00, 01 (start-stop)

32

0


1 (read)


Group Var num num

23

23

23

23

30

30

30

30

30






Description





1


1 (read)



17, 28 (index)

2


1 (read)



17, 28 (index)

3

Analog Input Event— 32-bit with time

1 (read)



17, 28 (index)

4

Analog Input Event— 16-bit with time

1 (read)



17, 28 (index)

5

Analog Input Event— Single-prec flt-pt without time

1 (read)



17, 28 (index)

7

Analog Input Event— Single-prec flt-pt with time

1 (read)



17, 28 (index)

0

Analog Input Deadband— Any Variation

1 (read)


1 (read)


129 (response)

00, 01 (start-stop)

2 (write)

00, 01 (start-stop) 17, 28 (index)

1 (read)


129 (response)

00, 01 (start-stop)

2 (write)


Group Var num num

32

32

32

32

32

32

34

34

34


1

2

Analog Input Deadband— 16-bit

Analog Input Deadband— 32-bit





DNP3 OBJECT GROUP & VARIATION Group Var num num


Description

3


00, 01 (start-stop) 129(response) 06 (no range, or all)

1 (read) 34



Analog Input Deadband— Single-prec flt-pt 2 (write)




Qualifier codes (hex) 00, 01 (start-stop)

40

0


40

1


1 (read)


129 (response)

00, 01 (start-stop)

2


1 (read)


129 (response)

00, 01 (start-stop)

40

3

Analog Output Status— Single-prec flt-pt with flag

1 (read)


129 (response)

00, 01 (start-stop)

41

0

Analog Output— Any Variation

22 (assign class)



17, 28 (index)

129 (response)

echo of request

6 (dir. op, no ack)

17, 28 (index)


17, 28 (index)

129 (response)

echo of request

6 (dir. op, no ack)

17, 28 (index)

40

41

41

1

2








41

3

Description

Analog Output— Single-prec flt-pt







17, 28 (index)

129 (response)

echo of request

6 (dir. op, no ack)

17, 28 (index)

1 (read)


42

0

Analog Output Event— Any Variation

42

1

Analog Output Event— 32-bit without time

1 (read)



17, 28 (index)

2

Analog Output Event— 16-bit without time

1 (read)



17, 28 (index)

3

Analog Output Event— 32-bit with time

1 (read)



17, 28 (index)

42

4

Analog Output Event— 16-bit with time

1 (read)



17, 28 (index)

42

5

Analog Output Event— Single-prec flt-pt without time

1 (read)



17, 28 (index)

7

Analog Output Event— Single-prec flt-pt with time

1 (read)


129 (response) 130(unsol. resp)

17, 28 (index)

43

0

Analog Output Command Event— Any Variation

1 (read)


43

1

Analog Output Command Event— 32-bit without time

1 (read)



17, 28 (index)

42

42

42






Description





2

Analog Output Command Event— 16-bit without time

1 (read)



17, 28 (index)

3

Analog Output Command Event— 32-bit with time

1 (read)



17, 28 (index)

4

Analog Output Command Event— 16-bit with time

1 (read)



17, 28 (index)

5

Analog Output Command Event— Single-prec flt-pt without time

1 (read)



17, 28 (index)

7

Analog Output Command Event— Single-prec flt-pt with time

1 (read)



17, 28 (index)

1 (read)


129 (response)


2 (write)


2 (write)


Group Var num num

43

43

43

43

43

50


1


3

Time and Date— Absolute time at last recorded time

1




51

2




52

1


129 (response)


52

2

Time Delay— Fine

129 (response)


1


50

51

60








60

60

60

80

2

3

4

1

Description




Internal Indications— Packed format



1 (read)




1 (read)




1 (read)




1 (read)

00, 01 (start-stop)

2 (write)

00 (start-stop) index=7

No Object (function code only)

0 (confirm)


13 (cold restart)


23 (delay measurement)


24 (record current time)



129 (response)

00, 01 (start-stop)




14.7

Conform mance

This subclause s speccifies the functtions a masterr or an outstattion shall suppport in order tto conform to a defineed implementattion level. The su ubset definition ns deal primariily with the Ap pplication Layyer of the DNP3 protocol. It iis neverthelesss a requirement that in order o for a dev vice to conform m to an implem mentation level, it shall have implemented oon vices of the Datta Link Layer and Transport Functions (as defined in Claause 8 and Clauuse 9) sufficient it serv to supp port the implem mentation leveel. 14.7.1 1 Outstation n devices In ord der for an outsttation to impleement a particu ular Level “X”” of DNP3, thhe device shalll conform to thhe follow wing: ⎯ The outstatiion shall be able to parse all master m request s defined for L Level “X.” ⎯ The outstattion shall be co onfigurable to not transmit aanything otherr than Level “X X” responses to Level “X” requests. r ⎯ The vendo or shall prov vide an XML L Device Pro rofile that deescribes the device's DNP P3 implementaation. The Device D Profile for f an outstation includes the following secttions: 1) Device properties: p Thiss section identtifies the capabbilities of the D DNP3 technicaal features of thhe device, and d records the cu urrent value orr setting of eacch of the param meters that desccribes a speciffic instance of the device. 2) Mapping g to IEC 61850 0 object modelss: This optionaal section recorrds the mappinng of each DNP P3 configuratio on parameter or o point to an atttribute in the IIEC 61850 object models. 3) Capabilitties and curren nt settings for device d databasee: This sectionn identifies the capabilities annd current settiings for each DNP3 D data typee supported byy the device. 4) Implemeentation table: This section identifies whhich object grooups and variiations, functioon codes, and qualifiers q are im mplemented in n the device. 5) List of data d points: Th his section defines the data p oints availablee in the devicee for each DNP P3 data type, or o a description n of how this in nformation cann be obtained iff the database iis configurablee. More specific detailss are included in i DNP3 Speciification Suppllement 1. An ou utstation may accept a and resp pond to additio onal requests nnot defined in L Level “X” and still conform to that leevel. It may respond to such requests r with data not definedd in Level “X.”” Any additional a funcctions the outstation provides shall not preevent a masterr device from communicatinng with an a outstation on n the defined level. l For instaance, a DNP3- L1 outstation m TE may choose too accept WRIT requessts of File Iden ntifier Objects. However, it sh hall not requirre a master to ssend such a reqquest in order to operatte. 14.7.2 2 Master de evices In ord der for a masterr device to imp plement a partticular level “X X” of DNP3, thhe device shalll conform to thhe follow wing: ⎯ The master device shall bee able to parse all outstation rresponses definned for Level ““X.” 427 Copyright © 2012 IEEE. All rightts reserved.



⎯ The masterr device shalll be configuraable to limit the requests it sends to ooutstations with implementaation levels low wer than “X.” For instance, a Level 3 masster shall be coonfigurable so it does not seend any requests to either a Level L 1 outstattion or a Levell 2 outstation tthat it could not parse. This does not preveent the master from f sending L Level 3 requestts to a Level 3 outstation. ⎯ The vendo or shall prov vide an XML L Device Pro rofile that deescribes the device's DNP P3 implementaation. The Device D Profile for f a master inccludes the follo owing sections : 1) Device properties: p Thiss section identtifies the capabbilities of the D DNP3 technicaal features of thhe device, and d records the cu urrent value orr setting of eacch of the param meters that desccribes a speciffic instance of the device. 2) Mapping g to IEC 61850 0 object modelss: This optionaal section recorrds the mappinng of each DNP P3 configuratio on parameter or o point to an atttribute in the IIEC 61850 object models. 3) Implemeentation table: This section identifies whhich object grooups and variiations, functioon codes, and qualifiers q are im mplemented in n the device. More specific detailss are included in i DNP3 Speciification Suppllement 1.

14.8

XML rep presentation n

The orriginal version of the Device Profile docum ment only docum umented how thhe outstation’s capabilities annd curren nt settings sho ould be presen nted in human n-readable form m. There are m many benefitss to having thhis inform mation availablle in a form that t is machin ne readable ass well. These include a more accurate annd efficieent device setup p. This subclau use and the associated XML L Schema definne a mechanism m to describe aan outstattion using the XML. X 14.8.1 1 Background The XML X specificaation defines a language thaat can be usedd to transfer innformation eleectronically in a platforrm- and appliccation-indepen ndent fashion. XML X defines the syntax forr the language but not a valid vocabu ulary for a speecific applicatio on. The XML Schema S speciffication providees a mechanism m for describinng a vocaabulary to be used in a specifi fic application. A detaailed descriptio on of XML and d XML Schemas is beyond thhe scope of this document. A brief overview w, along with a simplee example, is presented to assist a readers uunfamiliar witth XML in unnderstanding thhe nder of this doccument, as welll as the associated schema. remain 14.8.1 1.1 XML As meentioned, the XML X is a speccification that defines d the synntax for a stanndardized markkup language. A marku up language iss a language that t allows thee distribution of data (usuaally readable ttext) along with embed dded meta-dataa (data that inclludes additionaal and/or qualiffying informatiion about the ooriginal data). An XM ML document is organized ass a set of elemeents. Each elem ment begins wiith a start tag aand ends with aan end taag. Start tags have the form m ‘’ n and ennd tags have the form ‘ >’. Elemeents can contaiin other elemen nts (i.e., nested d elements) orr values. An exxample of an X XML documennt would d be as follows:: th> 20 Ma arch 196 60 rth>


The first line of the document simply identifies the document as an XML document, version 1.0 and using the UTF-8 encoding. This line is fairly standard in all XML documents. The remainder of the document is what we are concerned with. The top-level element in this document is dateOfBirth. This element contains three sub-elements named day, month, and year. Each of these elements contains text that provides the value for this element. Elements can be nested as required; they can contain multiple lines of text, etc. As mentioned, XML provides the syntax for a standard markup language, but it does not define the vocabulary to be used. Hence, in the preceding example, the XML specification defines where the brackets are, what is included in the element’s content, etc., but the exact elements that can be used (dateOfBirth, day, month, year), and the valid values for these elements, are up to the user. Description of the vocabulary to be used in an XML document is typically handled by an XML Schema as discussed in the following subclauses. 14.8.1.2 XML schemas XML Schemas have emerged as the leading standard for defining XML vocabularies. An example of an XML Schema that can be used to describe the XML content in the preceding example is as follows:




This schema s definess two basic datta types, a dayyOfMonthType,, which consistts of integer values between 1 and 31 1 inclusive, and d a nameOfMo onthType, whicch consists of tthe names of alll the months. It then definess a type called c dateOfBirthType, whicch consists of three elementss day, month, and year. Finnally it defines a single top-level elem ment called dateeOfBirth. By usiing the XML Schema to vallidate the XML L content from m the precedingg example, a pprogram can use standaard library fun nctions to veriify syntax and d vocabulary ffor any docum ment. This guaarantees that aall required elements exist e and that all the values are valid. Thhis removes thhe burden of pperforming daata d XML Schem mas provide a very powerfull mechanism fo for validaation from the target applicattion. XML and exchan nging informattion between tw wo systems. 14.8.1 1.3 XSLT XSLT T defines a system that can be b used to tran nsform XML ddocuments intoo a different doocument (whicch may or o may not be XML) using a template. A user-defined u X XSLT templatee is used by ann XSL engine to converrt input XML documents to other o documen nts. Frequentlyy this is used too dynamically generate HTM ML docum ments from XM ML data for disp play on the Weeb. The DNP U Users Group prrovides an XSL LT template thhat can bee used to translate a DNP3 Deevice Profile XML X instance ffile to an HTM ML file. When using the XSL LT template, th here are two parameters that can be set to change the waay that the XM ML ment is presenteed: docum a))

can n be set to yess or no to man nage the displaay of any notees that may be included in thhe XML file. This T parameterr defaults to yes.

b)) is set to o manage the presentation p off section 2 of thhe Device Proffile. It can be sset to none if seection 2 is to be b omitted from m the presentattion. It can be sset to table to ppresent sectionn 2 in tabular form, f or it can n be set to treee to present seection 2 as a ttree structure. This parametter defaults to tree. t 14.8.1 1.4 XML sch hema specifications The XML X specificatiion can be foun nd at: ⎯ http://www.w3.org/TR/20 004/REC-xml-2 20040204/ Details on XML Sch hemas can be fo ound at: ⎯ http://www.w3.org/TR/xm mlschema-0 ⎯ http://www.w3.org/TR/xm mlschema-1 ⎯ http://www.w3.org/TR/xm mlschema-2 The XSLT X specificattion can be fou und at: ⎯ http://www.w3.org/TR/xsslt 14.8.2 2 Use cases s The DNP3 D Device Profile P Schem ma included in DNP3 Specifi fication Suppleement 1 uses X XML and XM ML Schem mas to define a vocabulary th hat can be used d to describe a DNP3 outstaation. There arre many ways in which h a document off this type coulld be used. Thiis subclause shhall try to descrribe a few com mmon ones.




14.8.2 2.1 Utility co ompares imp plementation ns A ven ndor can distrib bute an XML document thaat describes thee capabilities oof an outstatioon as well as iits defaullt configuration n. This documeent could be pu ublished on thee Web so potenntial customerss could review it and deetermine wheth her the device would meet th heir needs. In aaddition, a coppy of this file ccould be shippeed with each e device an nd used by the customer to configure c a maaster and/or coonfiguration toool to which thhe devicee shall be connected. 14.8.2 2.2 Utility pu ublishes pro oposed devic ce requireme ents A utiliity that is plann ning to install new n devices co ould generate aan XML docum ment that descrribes the desireed config guration for thee new device. This XML document could then be compared against ann XML file thhat describ bes a prospectiive device’s caapabilities to deetermine whethher that devicee can be configured to meet thhe utility’s needs. A sim mple applicatio on could be developed that takes the XM ML document distributed byy a vendor thhat describ bes a device’ss capabilities, and another XML X documennt from a utiliity that descriibes the utilitiees requirements, and veerifies whether the device can n satisfy the reqquirements. 14.8.2 2.3 Outstatio on publishes s current con nfiguration An ou utstation tool (w within the outsstation or a sep parate program m running on aanother compuuter) can publissh its currrent configuraation at any time by generaating a new X XML configurration file. Thiis file could bbe distrib buted using thee standard DNP P3 file transferr mechanism. M Masters can reaad this file andd use it to set uup their own o configurattion and/or dataabase to match h the remote deevice. 14.8.2 2.4 Master updates u outs station config guration A masster might read d the XML doccument provideed by a vendorr, or read it dirrectly from the device, and use this to o present a useer interface thaat shows the cu urrent configurration and suppported optionss for a particular devicee. The user mig ght then modiffy the configuraation and sendd the new confi figuration back to the device aas a mod dified XML filee. 14.8.3 3 DNP3 XML L Schema ov verview The DNP3 D XML Schema mirrors the t DNP3 Dev vice Profile do cument in term ms of which D DNP3 parameteers are specified, what options o are avaailable, etc. Hence, it is not nnecessary to deescribe each off the elements oof NP3 XML Sch hema in detail here. h Simply reefer to the desccription for thee correspondingg Device Profiile the DN item. This T subclausee shall, however, outline a few fe conventionns used when iimplementing the schema annd describ be how they sh hould be used when w creating an XML Devicce Profile for a particular devvice. 14.8.3 3.1 Checking for require ed parameterrs Using the DNP3 Dev vice Profile Scchema to descrribe actual venndor devices haas shown that iit is not possibble velop a schema that mandates the inclusion of o all of the XM ML elements. E Experience has shown that: to dev ⎯ Many devicces do not support all of the optional functtionality includded in the Devvice Profile. Foor example, siimple devices may not supp port network (TCP / UDP) communicatioons, and hencce, Section 1.3 of the Devicee Profile is nott relevant. Sim milarly, older deevices may not support secuure S 1.12 off the Device Prrofile is not rellevant. To cateer to these casees, authenticatiion, and thus Section the inclusio on of many eleements in the schema had too be made optiional by settinng their attribuute minOccurs to zero. ⎯ If the Devicce Profile is creeated by the veendor at the tim me of device m manufacture theen many settinggs in the Dev vice Profile arre undefined— —their definitioon being part of the configguration process performed by b the user at the t time of com mmissioning thhe device. Thiss again means tthat many of thhe schema elem ments had to be made optionaal. 431 Copyright © 2012 IEEE. All rightts reserved.



The DNP3 Device Profile Schema is therefore defined with virtually all elements optional, the completeness of the Device Profile XML files not being validated by the schema. 14.8.3.2 ReferenceDevice and AuxillaryInfo The top-level element of the DNP3 Device Profile Schema includes three sub-elements (Figure 14-1).

Figure 14-1—Top level of DNP3 Device Profile Schema The first element, called documentHeader, is used to describe the document itself, its title, author, revision history, etc. (Figure 14-2).

Figure 14-2—Example of the Schema’s first element The second element is referenceDevice. This element is used to describe the primary view of the device (Figure 14-3).




Figure 14-3—Example of Schema’s referenceDevice The third element, called auxiliaryInfo, is used to define alternative views of the reference device and is also of type dnp3DeviceOptionalType. The auxiliaryInfo element should only contain the elements that are different from the values defined in the referenceDevice element. This might be used, for example, to describe a device with multiple communication ports. Multiple auxiliaryInfo elements can be included to describe multiple ports. The elements of type dnp3DeviceOptionalType have an optional attribute description that can be used to describe why this element is being included in the Device Profile. This should be used with each auxiliaryInfo element to describe the device features being defined with the element. In order to speed up DNP3 file transfer over slow communication lines, unique filenames may be assigned to read predefined portions of the entire file or only configuration parameters that have changed. In a similar manner, the master may write a small file back to the outstation containing only a few parameters to be updated. There are custom user data sections throughout the DNP3 XML file, so application-specific data can also be stored in the same file. If DNP3 XML is supported through DNP3 File I/O, the standard file name dnpDP.xml shall be supported to read a complete Device Profile document. 14.8.3.3 Empty element versus enumeration A number of the parameters described in the DNP3 Device Profile Schema allow the user to pick from several options. Two mechanisms exist in the XML Schema specification for selecting between a finite set of choices, an enumeration and a choice group. The main difference is that enumerations support selecting between a set of simple types (i.e., a set of strings or a set of numbers) and a choice group supports the selection of one of a group of complex types (i.e., an element that can contain additional elements and/or data). Using a choice group with a set of empty elements is equivalent in functionality to an enumeration with the same options. An example of an enumeration and its representation in an XML document is as follows: yes




The same example using a choice group is as follows: While an enumeration looks a bit cleaner, using a choice group allows the user to select between a wider variety of options, including options that contain data. An example is as follows: This is an explanation In order to provide the option of selecting items that contain additional information the DNP3 Device Profile Schema routinely uses choice groups, even in some cases where an enumeration would suffice. 14.8.3.4 Per group versus per point parameters A number of parameters are defined in the Device Profile Object Group tables with the option of “Per Point” along with directions instructing the author to add a column to the point table for this object group if the “Per Point” option is chosen. The DNP3 Device Profile Schema includes optional elements in both the group table and the corresponding point list for these parameters. If the parameter is constant for all the points in a group, the corresponding XML document should only include this parameter in the group table for that data type. If the parameter varies by point, the corresponding XML document should only include this parameter in the point list for that data type. Although it is not recommended, if the element for this parameter does exist at both the group and point levels, the point specification shall override the group specification. 14.8.3.5 Representation of real-time DNP3 data Each data point defined in the DNP3 Device Profile Schema includes a “dnpData” element that contains sub-elements that represent the real-time data reported via the DNP3 protocol for that data point. The dnpData element is optional and shall typically not be included in DNP3 Device Profile XML files, but its definition is useful for a number of reasons. First, including these elements in the DNP3 Device Profile Schema allows real-time data to be referenced using XPath exactly the same way the rest of the information in the Device Profile is referenced. Applications can parse these XPath statements and replace them with the real-time data as necessary at runtime. Secondly, including these elements in the DNP3 Device Profile 434 Copyright © 2012 IEEE. All rights reserved.



Schem ma shall also allow a the schem ma to be used d to distribute real-time DNP P3 data valuess using XML in situations where thiss is desirable. 14.8.3 3.6 User exttensions It is frrequently desirrable to insert device- or ven nder-specific iinformation dirrectly into the device’s DNP P3 Device Profile. This could be used d, for example, to include the entire device cconfiguration iin a single XM ML ol. The followiing schema eleement defines a data type useed file that could be acccessed via the DNP3 protoco port the incorp poration of userr-specific data in a device’s D DNP3 Device P Profile. to supp xs:complexT Type name="UserDataT Type"> > /xs:complex xType> deviceConfi ig> XYZ Com mpany … mlns="http://www.example.com/X XYZ"> /deviceConf fig>


objectt models is hig ghly desirable. For example, this functionaality would bee required wheen configuring a DNP3/IEC 61850 gaateway, or if a control statio on wants to vieew the DNP3 ssubstation in tterms of a set oof known objects. well-k The DNP3 D XML Device D Profilee Schema inclludes elementts that describbe the mappinng between thhe corresponding DNP3 3 device’s poin nt map and IEC C 61850 objecct models. These elements, annd their use, aare bed in detail in n IEEE P1815.1™ [B9]. describ

14.9

Instructions for creating a Dev vice Profile document

DNP3 Specification Supplement 1 includes a DN NP3 Device Prrofile templatee (Word docum ment) which caan be useed to help creatte the XML Deevice Profile for fo a device. Beecause it is a reequirement thaat a vendor shaall provid de an XML Deevice Profile for f a DNP3 deevice, it is recoommended thaat the human-rreadable files bbe generaated from the device's d XML Device Profilee, instead of m modifying the W Word template.. If both a Worrd docum ment and an XM ML Device Pro ofile are provid ded for a devicce, the XML D evice Profile sshall be assumeed to be correct. c Note the t following special s considerations when creating c a Deviice Profile: ⎯ An implementation table shall s be added to Section 4 o f the Device P Profile to descriibe which objeect d variations, function f codees, and qualifi fiers for both requests andd responses aare groups and supported. Copy the imp plementation table for the highest subsset level suppported from thhe appropriate interoperabilitty Level Impleementation secction and placee it in Section 4 of the Devicce Profile. ⎯ Additional highlighted rows may be added to indicatee functionalityy supported beyyond that subsset d but instead the font should be chaanged to strikeethrough for anny level. Rowss may not be deleted, Object Gro oups not provided by an outtstation or nott processed byy a master (noote these Objeect Groups shall still be parseed). ⎯ If the Devicce Profile is beeing created fo or a specific M Master Device, the text in the implementatioon table colum mn headings “O Outstation shalll parse” and “O Outstation mayy issue” shouldd be deleted, annd the remainin ng text should be revised to state: s REQUEST

RESPONSE R

Master can issue

Master M parses

⎯ If the Dev vice Profile is i being creaated for a sppecific Outstattion Device, the text in thhe implementaation table colu umn headings “Master may issue” and “M Master shall pparse” should bbe deleted, and d the remaining g text should be revised to staate: REQUEST

RESPONSE R

Outstation parses p

Outstation O can issue i

⎯ For more in nformation on the differencees between subbset levels andd other Object Groups that aare not part of a subset level, see the Parsing g Code chart inn Clause 12. ⎯ Complete th he Revision Hiistory Table loccated at the beginning of the new Device Profile Speciaal consideration ns when generating using XM ML: ⎯ The best meethod for geneerating a DNP3 3 XML instancce file is to proogram the devicce configuratioon tool to creatte this file baseed on the curreent device settinngs.




⎯ The DNP Users Group Web site37 provides a list of commercially available DNP3 XML tools specifically designed to generate, modify, view, print, and translate to other file formats such as HTML. ⎯ The example DNP3 XML instance files available from the DNP Users Group Web site can be used as a template and modified with any standard text editor or a generic XML editor to create a DNP3 XML instance file for your device. ⎯ The DNP Users Group provides an XML package distributed as a zip file containing the following: 1) A schema file (.xsd) that all DNP3 XML instance files shall validate against 2) An XSLT file that can be used to translate a machine-readable DNP3 XML instance file into an HTML file that can be viewed with a web browser 3) A template XSLT file that can be customised by a vendor to translate those parts of the Device Profile to show userData entries 4) The DNP logo file, used by the XSLT NOTE—The first three files should be distributed with the DNP3 XML instance file for a device. A DNP3 XML instance file may not be compatible with different release versions of the DNP3 XML Schema and XSLT files.

Instead of generating a device-specific Word document, it is recommended that a human-readable file be generated from the XML Device Profile. If, however, the Word template is being used to generate a devicespecific Word document, the following considerations should be followed: ⎯ The general technique for producing a word processing-based Device Profile is to fill in the following document with the correct information and to save it to a new file that shall become the Device Profile for your device. ⎯ Bookmarks for the Vendor Name, Device Name, and Revision date on the cover page shall automatically update items in the tables of the appendix along with the footer when the cover page is edited.

37

http://www.dnp.org.




Anne ex A (norm mative) DNP P3 data object library— —object description ns A.1

Ob bject group p 0: device attributes a

A.1.1

De evice attributtes—secure authenticatiion version Group::

0

Variatiion:

209

Device Attrributes

Type:

Attrib

Secure auth hentication version n

Parsingg Codes:

Table 12-1

DNP3 Object O Librrary Group Name: Variation Name:

A.1.1.1

De escription

This attribute a provid des the secure authentication a version v supporrted by the outsstation. A.1.1.2

Co oding

A.1.1.2.1

Pictorial

octet o transmission n order

7

6

5

4

3

2

1

0

bit position

b7 b

b0

Attribute d data type cod de

b7 b

b0

Length Secure au uthentication version

A.1.1.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Secure aauthentication version field. UINTn: Seecure authentication version. Th his object reporrts the secure authentication a vversion supporrted by the outsstation.




A.1.2

De evice attributtes—numberr of security statistics pe er associatio on Group :

0

Variatiion:

210

Device Attrributes

Type:

Attrib

Number of security statistics per association

Parsingg Codes:

Table 12-1


A.1.2.1 De escription This attribute a provid des the numbeer of security statistics s per aassociation in tthe outstation available to thhe masterr. See 7.5.2.2. A.1.2.2

Co oding

A.1.2.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7 b

b0


b7 b

b0

Length Number o of security sta atistics per assocciation

A.1.2.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of security staatistics per assoociation field. UINTn: Nu umber of securrity statistics peer association. Th he number of security statisttics per associiation in the ooutstation avaiilable when thhis obj bject is reported d.




A.1.3

De evice attributtes—identific cation of sup pport for use er-specific atttributes Group :

0

Variatiion:

211

Device Attrributes

Type:

Attrib

Identificatio on of support for user-specific u attrib butes

Parsingg Codes:

Table 12-1


A.1.3.1 De escription This attribute a is ussed to identify y the support for private, vendor, or usser-specific seets of attributees (collecctively referencced as user-speecific attributess). This object o attribute consists of an n ASCII string that lists all thhe attribute setts supported byy the outstatioon. The lisst specifies 0, 1, 1 or more attriibute sets. Each element e in the list consists off a namespace– –index pair, whhere the namesppace identifiess the attribute sset and th he index specifiies at which grroup 0 index th he master can reead attributes ffrom that attribbute set. Namespaces are textt names that un niquely in the world identifyy one attribute set from anothher. Namespacees b registered with w the DNP Users U Group, wh hich is achieveed by completiing a form on thheir Web site.338 shall be The in ndex part of th he namespace– –index pair speecifies which ggroup 0 index sshall be used bby the master to accesss attributes asso ociated with th he respective atttribute set. Beforee attempting to o read user-speecific attributess, the master shhall read g0v2211 at index 0. Upon receivinng the ou utstation’s respo onse, the masteer parses the list. Using the innformation obttained after parrsing, the mastter can un nambiguously read r or write, as a appropriate, attributes assoociated with a sspecific attribuute set. A.1.3.2

Co oding

A.1.3.2.1

Pictorial

oc ctet transmission order

7

6

5

4

3

2

1

0

bit position

b7 7

b0

Attribute d data type co ode

b7 7

b0

Length String ide entifying userr-specific attribute ssets

A.1.3.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the atttribute data typ pe code, UINT T. (Refer to T Table 5-16.) F For this attribuute nu umber, this shalll be 1 (VSTR)). UINT8: Leength. Sp pecifies the num mber of octets in i the identifyiing string. 38

http:///www.dnp.org.




VSTRn: Identification of user-specific attribute sets. Consists of namespace–index number pairs and delimiters as follows: SET of 1 (Included for the first attribute set in the list) { VSTRx: Namespace. VSTR1: Comma delimiter used to separate the namespace from the index number fields. VSTRy: The group 0 index number used to access attributes for this attribute set stated as a decimal value in ASCII characters. } SET of m (Included for the second and subsequent attribute sets in the list) { VSTR1: Semicolon delimiter used to separate one attribute set from another. The first attribute set omits this field and all others include this field. VSTRx: Namespace. VSTR1: Comma delimiter used to separate the namespace from the index number fields. VSTRy: The group 0 index number used to access attributes for this attribute set stated as a decimal value in ASCII characters. } NOTE—If no attribute sets are supported, the data type code is set to 254, the length is set to 0, and there are no octets in the identification string.

A.1.3.3 Examples of the use of this attribute are: An outstation supporting a single user-specific attribute set ►►► Request Message C3 AC

01 FC

00 Grp

D3 Var

00 Qual

00 Range

00

00 Grp

D3 Var

17 Qual

01 Range

6F

72

70


81 FC

00 IIN1

00 IIN2

00 Index

01 Type

0A Length

◄◄◄ Continuation of Response Message 41 ←

42 43 20 43 Namespace of the attribute set

2C →,

31 index

In response to a read request for g0v211 with index 0, an outstation returns the information that attributes associated with the namespace “ABC Corp” are available using index number 1.




An outstation supporting two user-specific attribute sets ►►► Request Message C3 AC

01 FC

00 Grp

D3 Var

00 Qual

00 Range

00

00 Grp

D3 Var

17 Qual

01 Range

6F

72

70

59 5A 20 49 6E Namespace of the 2nd attribute set

63

2C →,


81 FC

00 IIN1

00 IIN2

00 Index

01 Type

14 Length

31 Index

3B ;


42 43 20 43 Namespace of the 1st attribute set

2C →,


32 Index

In response to a read request for g0v211 with index 0, an outstation returns the information that attributes associated with the namespace “ABC Corp” are available using index number 1 and those for namespace “XYZ Inc” are available using index number 2.




A.1.4

De evice attributtes—numberr of master-d defined data set prototyp pes Group:

0

Variation:

212

Device Attributes A

Type:

Attrib

Number of master-defined data set prototypees

Parsing Codes:

Table 12-1


A.1.4.1 De escription This attribute a provid des the number of data set pro ototypes in the outstation thatt were defined by the master. A.1.4.2

Co oding

A.1.4.2.1

Pictorial

octet o transmissio on order

7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Number o of master-deffined data set p prototypes

A.1.4.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of master-defi fined data set prototypes fieldd. UINTn: Nu umber of masteer-defined dataa set prototypess. Th he number of data d set prototy ypes that exist iin the outstatioon when this obbject is reporteed thaat were defined d by the masterr. A.1.4.2.3

No otes

When an outstation starts, it may have N outstaation-defined ddata set prototyypes with indeexes 0 to N – 1. c to o the number reported in object group 0, variation 2213. Master-ddefined data sset This corresponds prototy ypes begin theeir index numb bering with the number follow wing the higheest outstation-ddefined index; N for thee preceding exaample. Outstaations that acceept master-defiined data set prrototypes, but tthat store their definition in vvolatile memorry, may start up with zeero master-deffined data set prototypes. p Thhe value reporteed by this objeect shall changge he master writees data set prottotypes to the outstation. o after th




A.1.5

De evice attributtes—numberr of outstatio on-defined data set proto otypes Group:

0

Variation:

213

Device Attributes A

Type:

Attrib

Number of o outstation-defin ned data set prototy ypes

Parsing Codes:

Table 12-1

DNP3 Object O Library Group Name: Variation Name:

A.1.5.1 De escription This attribute a proviides the numb ber of data set prototypes iin the outstatiion that were defined by thhe outstattion. A.1.5.2

Co oding

A.1.5.2.1

Pictorial

oc ctet transmission n order

7

6

5

4

3

2

1

0

bit position

b7 b

b0


b7 b

b0

Length Number o of outstation--defined data set p prototypes

A.1.5.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of outstation-ddefined data seet prototypes fieeld. UINTn: Nu umber of outstaation-defined data d set prototyypes. Th he number of data d set prototy ypes in the outsstation that exiist when this obbject is reporteed thaat were defined d by the outstattion. A.1.5.2.3

No otes

When an outstation starts, it may have N outstaation-defined ddata set prototyypes with indeexes 0 to N – 1. This corresponds c to o the number reported r by th his object. Masster-defined daata set prototyypes begin theeir index numbering with the numbeer following th he highest outtstation-definedd index; N foor the precedinng ple. examp




A.1.6

De evice attributtes—numberr of master-d defined data sets Group:

0

Variation:

214

Device Attributes A

Type:

Attrib

Number of o master-defined data sets

Parsing Codes:

Table 12-1


A.1.6.1 De escription This attribute a provid des the number of data sets in the outstation that were defiined by the masster. A.1.6.2

Co oding

A.1.6.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Number o of master-deffined data sets

A.1.6.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of master-defi fined data sets ffield. UINTn: Nu umber of masteer-defined dataa sets. Th he number of data d sets in thee outstation whhen this objectt is reported thhat were defineed by y the master. A.1.6.2.3

No otes

n starts, it may y have N outsstation-definedd data sets wiith indexes 0 to N – 1. Thhis When an outstation n reporteed in object grroup 0, variatioon 215. Masterr-defined data sets begin theeir corresponds to the number he highest outtstation-definedd index; N foor the precedinng index numbering with the numbeer following th ple. examp Outstaations that acceept master-defiined data sets, but b that store ttheir definitionn in volatile meemory, may staart up witth zero masterr-defined data sets. The valu ue reported byy this object shhould change after the mastter writes data set descriiptors to the ou utstation.




A.1.7

De evice attributtes—numberr of outstatio on-defined data sets Group:

0

Variation:

215

Device Attributes A

Type:

Attrib

Number of outstation-defin ned data sets

Parsing Codes:

Table 12-1


A.1.7.1 De escription This attribute a provid des the number of data sets in the outstation that were defiined by the outtstation. A.1.7.2

Co oding

A.1.7.2.1

Pictorial

octet transmissio on order

7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Number o of outstation-d defined data sets

A.1.7.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of outstation-ddefined data seets field. UINTn: Nu umber of outstaation-defined data d sets. Th he number of data d sets in thee outstation whhen this objectt is reported thhat were defineed by y the outstation. A.1.7.2.3

No otes

n starts, it may y have N outsstation-definedd data sets wiith indexes 0 to N – 1. Thhis When an outstation n reporteed by this objeect. Master-deffined data setss begin their inndex numberinng corresponds to the number he number folllowing the high hest outstation--defined index ; N for the precceding examplle. with th




A.1.8 reque est

De evice attributtes—maximu um number o of binary outtput objects per Group:

0

Variation:

216

Device Attributes A

Type:

Attrib

Maximum m number of binarry output objects per p request

Parsing Codes:

Table 12-1


A.1.8.1 De escription This attribute a is the maximum num mber of binary y output objectts from object group 12 that the master maay includ de in control meessages. A.1.8.2

Co oding

A.1.8.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Number o of binary outp put objects

A.1.8.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of binary outpput objects fieldd. UINTn: Maximum numb ber of binary ou utput objects. Th he maximum nu umber of binarry output objeccts from objectt group 12 thatt the master maay incclude in contro ol messages.




A.1.9

De evice attributtes—local tim ming accura cy Group:

0

Variation:

217

Device Attributes A

Type:

Attrib

Local tim ming accuracy

Parsing Codes:

Table 12-1


A.1.9.1 De escription This attribute a is the rated r timing acccuracy of an outstation o stateed in microsecoonds. This valuue applies to thhe maxim mum error in th he detection an nd time stampiing of events w when the time for those evennts is determineed by thee outstation. It does not apply y to events thaat are retrievedd and passed onn from other ddevices when thhe event time is determined by those other o devices. A.1.9.2

Co oding

A.1.9.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Timing acccuracy microseco onds

A.1.9.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Timing aaccuracy microoseconds field. UINTn: Tim ming accuracy y microsecondss. Th his value is deffined as the maaximum differrence in time, sstated as a possitive number oof miicroseconds, beetween the tim me that would bbe given to an eevent by a hyppothetical devicce having a perfectt clock with infinitesimal i rresolution and no detection delays and thhe orst-case time that t the outstattion could givee. wo A.1.9.2.3

No otes

Do no ot confuse this attribute a with timing t resolutio on. Resolutionn is the smallest interval of tim me between daata sampliing or computtations or repo orted times. DNP3 D events aare reported w with a time reesolution of onne milliseecond. An ou utstation, for example, mig ght be able too detect the eexistence of an event everry 100 microseconds, m but b that does not n necessarily y mean that its timing accuraacy is 100 miccroseconds. Thhis hypoth hetical outstation’s timing accuracy could be b much worse , say, 20 000 m microseconds. When reporting thiss value, the caalculations should take into cconsideration the drift in thhe device’s loccal clock source, the perriod between tiime synchronizzations, sampliing resolution, and other factoors. 448 Copyright © 2012 IEEE. All rightts reserved.



If an outstation requires time synchronization from a master and asserts the Internal Indications bit IIN1.4 [NEED_TIME], the calculation should assume that the time reported by the master is perfect. The timing accuracy then depends on ⎯ The drift in the outstation’s local oscillator and the period between assertions of bit IIN1.4. ⎯ How well the outstation can determine the time delay when a delay measurement (function code 23 [DELAY_MEASURE]) is requested from the master. ⎯ Interrupt latency. ⎯ Data sampling periods. ⎯ Filter delays. ⎯ Other factors. If an outstation is synchronized from a local source, such as a GPS receiver, the time accuracy reported should include the error in that product and other possible error sources such as those listed in the previous paragraph. If an outstation contains multiple timing sources, only one is reportable using this object. It is suggested that vendors choose the source associated with the most critical measurements, those most likely to be used for forensic analysis should a major event occur. As an example, given a protective relay with independent time tagging sources for faults and analog measurements, the source associated with breaker tripping would be chosen.




A.1.10

De evice attributtes—duration of time acc curacy Group:

0

Variation:

218

Device Attributes A

Type:

Attrib

Duration of time accuracy

Parsing Codes:

Table 12-1

DNP3 Object O Library Group Name: Variation n Name:

A.1.10.1 De escription This attribute a is the number of secconds that the device maintaains its rated tiime accuracy ffollowing a tim me synchrronization from m the master. A.1.10.2

Co oding

A.1.10.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7 b

b0


b7 b

b0

Length Number o of seconds

A.1.10.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of seconds fieeld. UINTn: Nu umber of secon nds. Th he number of seeconds that thee device mainttains its rated tiime accuracy ffollowing a tim me syn nchronization from f the masteer. If time synchron nization is not required from m the master, tthis value shaall be zero. Thhis t tag eventts and devices that receive ttime from other inccludes devicess that do not time sou urces such as a GPS receiverr. If time in the deevice is depend dent on periodiic receipt of tiime from the m master, then thhis on-zero. This vaalue shall not eexceed 0xFFFF FFFFF. value shall be no




A.1.10.2.3

Notes

Rated accuracy is not defined by DNP3 as this is a vendor- and application-specific parameter. If an outstation contains multiple timing sources, only one is reportable using this object. It is suggested that vendors choose the source associated with the most critical measurements, those most likely to be used for forensic analysis should a major event occur. As an example, given a protective relay with independent time tagging sources for faults and analog measurements, the source associated with breaker tripping would be chosen.




A.1.11

De evice attributtes—supporrt for analog output events Group:

0

Variation:

219

Device Attributes A

Type:

Attrib

Support for f analog output events e

Parsing Codes:

Table 12-1


A.1.11.1 De escription This attribute a is Boolean that indicates whether th he device suppports analog ouutput events. A.1.11.2

Co oding

A.1.11.2.1

Pictorial

octet transmission n order

7

6

5

4

3

2

1

0

bit position

b7 b

b0

Attribute d data type code

b7 b

b0

Length Analog ou utput events

A.1.11.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Analog ooutput events ffield. INTn: Anaalog output events. Th his is a Boolean n having a valu ue of 1 if the devicce supports anaalog output eveents and 0 if the devicce does not sup pport analog ouutput events.




A.1.12 2

De evice attributtes—maximu um analog o utput index Group:

0

Variation:

220

Device Attributes A

Type:

Attrib

Maximum m analog output in ndex

Parsing Codes:

Table 12-1


A.1.12 2.1 De escription This attribute a is max ximum analog output o point in ndex controllabble from the maaster. A.1.12 2.2

Co oding

A.1.12 2.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Maximum analog outp put point index

A.1.12 2.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum analog outpput point index field. UINTn: Maximum analog g output point index. Th he presently configured max ximum analogg output pointt index controollable from thhe maaster. A.1.12 2.2.3

No otes

If therre are gaps in the point indeexes, the numb ber of points controllable by the master iin variation 2221 might not equal one more than the maximum poin nt index.




A.1.13

De evice attributtes—numberr of analog o outputs Group:

0

Variation:

221

Device Attributes A

Type:

Attrib

Number of o analog outputs

Parsing Codes:

Table 12-1


A.1.13.1 De escription This attribute a is num mber of analog output o points controllable c froom the master. A.1.13.2

Co oding

A.1.13.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Number o of analog outtput points

A.1.13.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of analog outpput points fieldd. UINTn: Nu umber of analo og output pointts. Th he presently co onfigured numb ber of analog output points that are controollable from thhe maaster. A.1.13.2.3

No otes

t point index xes, the numbeer of points conntrollable by thhe master mighht not equal onne If therre are gaps in the more than t the maxim mum point indeex in variation 220.




A.1.14 4

De evice attributtes—supporrt for binary o output eventts Group:

0

Variation:

222

Device Attributes A

Type:

Attrib

Support for f binary output events e

Parsing Codes:

Table 12-1


A.1.14 4.1 De escription This attribute a is Boolean that indicates whether th he device suppports binary outtput events. A.1.14 4.2

Co oding

A.1.14 4.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0


b7

b0

Length Binary outtput events

A.1.14 4.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Binary ooutput events fi field. INTn: Binaary output even nts. Th his is a Boolean n having a valu ue of 1 if the devicce supports bin nary output eveents and 0 if the devicce does not sup pport binary ouutput events.




A.1.15

De evice attributtes—maximu um binary ou utput index Group:

0

Variation:

223

Device Attributes A

Type:

Attrib

Maximum m binary output in ndex

Parsing Codes:

Table 12-1


A.1.15.1 De escription This attribute a is max ximum binary output o point ind dex controllablle from the maaster. A.1.15.2

Co oding

A.1.15.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0

Attribute d data type code

b7

b0

Length Maximum m binary outp put point index

A.1.15.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum binary outpuut point index field. UINTn: Maximum binary y output point index. i Th he presently configured max ximum binaryy output pointt index controollable from thhe maaster. A.1.15.2.3

No otes

m the master in variation 2224 If therre are gaps in the point indexes, the number of points coontrollable from might not equal one more than the maximum poin nt index.




A.1.16

De evice attributtes—numberr of binary o utputs Group:

0

Variation:

224

Device Attributes A

Type:

Attrib

Number of o binary outputs

Parsing Codes:

Table 12-1


A.1.16.1 De escription This attribute a is num mber of binary output o points controllable c froom the master. A.1.16.2

Co oding

A.1.16.2.1

Pictorial

A.1.16.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of binary outpput points fieldd. UINTn: Nu umber of binarry output pointss. Th he presently con nfigured numb ber of binary ouutput points coontrollable from m the master. A.1.16.2.3

No otes

If therre are gaps in the point indexes, the numb ber of points coontrollable froom the master might not equual one more m than the maximum m point index in variattion 223.




A.1.17

De evice attributtes—supporrt for frozen c counter even nts Group:

0

Variation:

225

Device Attributes A

Type:

Attrib

Support for f frozen counter events

Parsing Codes:

Table 12-1


A.1.17.1 De escription This attribute a is Boolean that indicates whether th he device suppports frozen couunter events. A.1.17.2

Co oding

A.1.17.2.1

Pictorial

A.1.17.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Frozen ccounter events field. INTn: Frozzen counter eveents. Th his is a Boolean n having a valu ue of 1 if the devicce supports fro ozen counter evvents and 0 if the devicce does not sup pport frozen coounter events.




A.1.18

De evice attributtes—supporrt for frozen c counters Group:

0

Variation:

226

Device Attributes A

Type:

Attrib

Support for f frozen counterss

Parsing Codes:

Table 12-1


A.1.18.1 De escription This attribute a is Boolean that indicates whether th he device suppports frozen couunters. A.1.18.2

Co oding

A.1.18.2.1

Pictorial

A.1.18.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Frozen ccounters field. INTn: Frozzen counters. Th his is a Boolean n having a valu ue of 1 if the devicce supports fro ozen counters aand 0 if the devicce does not sup pport frozen coounters.




A.1.19

De evice attributtes—supporrt for counterr events Group:

0

Variation:

227

Device Attributes A

Type:

Attrib

Support for f counter events

Parsing Codes:

Table 12-1


A.1.19.1 De escription This attribute a is Boolean that indicates whether th he device suppports counter evvents. A.1.19.2

Co oding

A.1.19.2.1

Pictorial

A.1.19.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Counterr events field. INTn: Cou unter events. Th his is a Boolean n having a valu ue of 1 if the devicce supports cou unter events annd 0 if the devicce does not sup pport counter eevents.




A.1.20

De evice attributtes—maximu um counter iindex Group:

0

Variation:

228

Device Attributes A

Type:

Attrib

Maximum m counter index

Parsing Codes:

Table 12-1


A.1.20.1 De escription This attribute a is max ximum counter point index reported by the ddevice. A.1.20.2

Co oding

A.1.20.2.1

Pictorial

A.1.20.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum counter poinnt index field. UINTn: Maximum counter point index. Th he presently con nfigured maxim mum counter ppoint index repported by the deevice. A.1.20.2.3

No otes

If therre are gaps in the t point index xes, the numbeer of points repported in variaation 229 mighht not equal onne more than t the maxim mum point indeex.




A.1.21

De evice attributtes—numberr of counter points Group:

0

Variation:

229

Device Attributes A

Type:

Attrib

Number of o counter points

Parsing Codes:

Table 12-1


A.1.21.1 De escription This attribute a is num mber of counterr points reporteed by the devic e. A.1.21.2

Co oding

A.1.21.2.1

Pictorial

A.1.21.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of counter poiints field. UINTn: Nu umber of countter points. Th he presently con nfigured numb ber of counter ppoints reportedd by the devicee. A.1.21.2.3

No otes

If therre are gaps in the point indeexes, the numb ber of points rreported mightt not equal onee more than thhe maxim mum point indeex reported in variation v 228.




A.1.22 2

De evice attributtes—supporrt for frozen a analog inputts Group:

0

Variation:

230

Device Attributes A

Type:

Attrib

Support for f frozen analog inputs i

Parsing Codes:

Table 12-1


A.1.22 2.1 De escription This attribute a is Boolean that indicates whether th he device suppports frozen anaalog inputs. A.1.22 2.2

Co oding

A.1.22 2.2.1

Pictorial

A.1.22 2.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Frozen aanalog inputs ffield. INTn: Frozzen analog inpu uts. Th his is a Boolean n having a valu ue of 1 if the devicce supports fro ozen analog inpputs and 0 if the devicce does not sup pport frozen annalog inputs.




A.1.23

De evice attributtes—supporrt for analog input events s Group:

0

Variation:

231

Device Attributes A

Type:

Attrib

Support for f analog input ev vents

Parsing Codes:

Table 12-1


A.1.23.1 De escription This attribute a is Boolean that indicates whether th he device suppports analog inpput events. A.1.23.2

Co oding

A.1.23.2.1

Pictorial

oc ctet transmission n order

7

6

5

4

3

2

1

0

bit position

b7 b

b0


b7 b

b0

Length Analog inp put events

A.1.23.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Analog iinput events fieeld. INTn: Anaalog input even nts. Th his is a Boolean n having a valu ue of 1 if the devicce supports anaalog input evennts and 0 if the devicce does not sup pport analog innput events.




A.1.24 4

De evice attributtes—maximu um analog in nput index Group:

0

Variation:

232

Device Attributes A

Type:

Attrib

Maximum m analog input ind dex

Parsing Codes:

Table 12-1


A.1.24 4.1 De escription This attribute a is max ximum analog input i point ind dex reported byy the device. A.1.24 4.2

Co oding

A.1.24 4.2.1

Pictorial

A.1.24 4.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum analog inpuut point index ffield. UINTn: Maximum analog g input point in ndex. Th he presently con nfigured maxim mum analog innput point indeex reported by tthe device. A.1.24 4.2.3

No otes





A.1.25

De evice attributtes—numberr of analog in nput points Group:

0

Variation:

233

Device Attributes A

Type:

Attrib

Number of o analog input po oints

Parsing Codes:

Table 12-1


A.1.25.1 De escription This attribute a is num mber of analog input i points rep ported by the ddevice. A.1.25.2

Co oding

A.1.25.2.1

Pictorial

A.1.25.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of analog inpuut points field. UINTn: Nu umber of analo og input points.. Th he presently con nfigured numb ber of analog innput points repported by the deevice. A.1.25.2.3

No otes





A.1.26

De evice attributtes—supporrt for double--bit binary in nput events Group:

0

Variation:

234

Device Attributes A

Type:

Attrib

Support for f double-bit binaary input events

Parsing Codes:

Table 12-1


A.1.26.1

De escription

This attribute a is Boolean that indicates whether th he device suppports double-bitt binary input eevents. A.1.26.2

Co oding

A.1.26.2.1

Pictorial

A.1.26.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Double--bit binary evennts field. INTn: Dou uble-bit binary input events. Th his is a Boolean n having a valu ue of 1 if the devicce supports dou uble-bit binaryy events and 0 if the devicce does not sup pport double-bbit binary inputt events.




A.1.27

De evice attributtes—maximu um double-b bit binary ind dex Group:

0

Variation:

235

Device Attributes A

Type:

Attrib

Maximum m double-bit binarry index

Parsing Codes:

Table 12-1


A.1.27.1

De escription

This attribute a is max ximum double-bit binary inpu ut point index rreported by thee device. A.1.27.2

Co oding

A.1.27.2.1

Pictorial

A.1.27.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum double-bit bbinary input pooint index field. UINTn: Maximum doublle-bit binary po oint index. Th he presently con nfigured maxim mum double-bbit binary inputt index reportedd by the devicee. A.1.27.2.3

No otes





A.1.28

De evice attributtes—numberr of double-b bit binary inp put points Group:

0

Variation:

236

Device Attributes A

Type:

Attrib

Number of o double-bit binarry input points

Parsing Codes:

Table 12-1


A.1.28.1 De escription This attribute a is num mber of double--bit binary inpu ut points reportted by the deviice. A.1.28.2

Co oding

A.1.28.2.1

Pictorial

A.1.28.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of double-bit bbinary input pooints field. UINTn: Nu umber of doublle-bit binary in nput points. Th he presently configured c num mber of doublle-bit binary input points rreported by thhe device. A.1.28.2.3

No otes





A.1.29

De evice attributtes—supporrt for binary iinput events Group:

0

Variation:

237

Device Attributes A

Type:

Attrib

Support for f binary input ev vents

Parsing Codes:

Table 12-1


A.1.29.1 De escription This attribute a is Boolean that indicates whether th he device suppports binary inpput events. A.1.29.2

Co oding

A.1.29.2.1

Pictorial

A.1.29.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, INT. (R Refer to Table 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Binary in input events fieeld. INTn: Binaary input eventts. Th his is a Boolean n having a valu ue of 1 if the devicce supports bin nary input evennts and 0 if the devicce does not sup pport binary innput events.




A.1.30

De evice attributtes—maximu um binary in nput index Group:

0

Variation:

238

Device Attributes A

Type:

Attrib

Maximum m binary input ind dex

Parsing Codes:

Table 12-1


A.1.30.1 De escription This attribute a is max ximum binary input i point indeex reported byy the device. A.1.30.2

Co oding

A.1.30.2.1

Pictorial

A.1.30.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum binary inputt point index fiield. UINTn: Maximum binary y input point in ndex. Th he presently con nfigured maxim mum binary innput point indexx reported by tthe device. A.1.30.2.3

No otes





A.1.31

De evice attributtes—numberr of binary in nput points Group:

0

Variation:

239

Device Attributes A

Type:

Attrib

Number of o binary input poiints

Parsing Codes:

Table 12-1


A.1.31.1 De escription This attribute a is num mber of binary input i points rep ported by the ddevice. A.1.31.2

Co oding

A.1.31.2.1

Pictorial

A.1.31.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Number of binary inpuut points field. UINTn: Nu umber of binarry input points. Th he presently con nfigured numb ber of binary innput points repoorted by the deevice. A.1.31.2.3

No otes





A.1.32 2

De evice attributtes—maximu um transmit fragment sizze Group:

0

Variation:

240

Device Attributes A

Type:

Attrib

Maximum m transmit fragment size

Parsing Codes:

Table 12-1


A.1.32 2.1 De escription This attribute a is max ximum number of octets the device d shall tran ansmit in an Appplication Layeer fragment. A.1.32 2.2

Co oding

A.1.32 2.2.1

Pictorial

A.1.32 2.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum transmit fraagment size fielld. UINTn: Maximum transm mit fragment siize. Th he maximum number n of occtets the devicce shall transm mit in an Appplication Layyer fraagment.




A.1.33

De evice attributtes—maximu um receive frragment size e Group:

0

Variation:

241

Device Attributes A

Type:

Attrib

Maximum m receive fragmen nt size

Parsing Codes:

Table 12-1


A.1.33.1 De escription This attribute a is maaximum numb ber of octets the t device shaall accept in a received Appplication Layyer fragmeent. A.1.33.2

Co oding

A.1.33.2.1

Pictorial

A.1.33.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, UINT. (Refer to Tablle 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the Maximuum receive fraggment size fieldd. UINTn: Maximum receiv ve fragment sizze. Th he maximum number n of octeets the device sshall accept inn a received Appplication Layyer fraagment.




A.1.34 4

De evice attributtes—device manufacture er’s software e version Group:

0

Variation:

242

Device Attributes A

Type:

Attrib

Device manufacturer’s m softtware version

Parsing Codes:

Table 12-1


A.1.34 4.1 De escription This attribute a is the version v code off the manufactu urer’s device ssoftware. The co ontents of this attribute is a free f form string g that is formaatted accordingg to the manufaacturer’s norm mal practicce. Two examples e are “5.3.006” and a “1.12:2003-11-25-Standaard.” A.1.34 4.2

Co oding

A.1.34 4.2.1

Pictorial

A.1.34 4.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the manufaccturer’s softwaare version strinng. VSTRn: Manufacturer’s M software s versio on string. Co ode assigned by y the manufactturer for the insstalled versionn of the device’s software.




A.1.35

De evice attributtes—device manufacture er’s hardwarre version Group:

0

Variation:

243

Device Attributes A

Type:

Attrib

Device manufacturer’s m hard dware version

Parsing Codes:

Table 12-1


A.1.35.1 De escription This attribute a is the version v code off the manufactu urer’s device hhardware. The co ontents of this attribute is a free f form string g that is formaatted accordingg to the manufaacturer’s norm mal practicce. Two examples e are “Rev D” an nd “2004-122.”” A.1.35.2

Co oding

A.1.35.2.1

Pictorial

A.1.35.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the manufaccturer’s hardw ware version strring. VSTRn: Manufacturer’s M hardware h versiion string. Co ode assigned by y the manufactturer for the insstalled versionn of the device’s hardware.




A.1.36

De evice attributtes—user-as ssigned locattion name Group:

0

Variation:

245

Device Attributes A

Type:

Attrib

User-assiigned location nam me

Parsing Codes:

Table 12-1


A.1.36.1 De escription This attribute a is a name or code giv ven to the locattion where the device is instaalled by the endd user. The co ontent of this attribute a is a freee form string that t is formatteed according too the user’s norrmal practice. Three examples are “1954 Broaad Street,” “Too ora Wind Farm m” and “Soho:P Piccadilly Circcus.” A.1.36.2

Co oding

A.1.36.2.1

Pictorial

Fo A.1.36.2.2 ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the user-asssigned device loocation name oor code string. VSTRn: User-assigned lo ocation name or o code string. Naame or code for location where the device iss installed. It iss assigned by eend user. A.1.36.2.3

No otes

It is reecommended th hat device man nufacturers pro ovide a configuurable means fo for the end userr to locally store a text location name or code. If a user u has a lo ocation naming g convention consisting off sub-fields (llike major annd minor), it is recom mmended that he/she h choosee a delimiting character (“:,,” “~,” “+,” eetc.) as a standard method to separaate the fields.




A.1.37

De evice attributtes—user-as ssigned ID co ode/number Group:

0

Variation:

246

Device Attributes A

Type:

Attrib

User-asssigned ID code/num mber

Parsing Codes:

Table 12-1

DNP3 Object Lib brary Group Name: Variation Name:

A.1.37.1 De escription This attribute a is a code or number given g to the deevice by the endd user. The co ontent of this attribute a is a freee form string that t is formatteed according too the user’s norrmal practice. Two examples e are “4075” and d “25-DS.” A.1.37.2

Co oding

A.1.37.2.1

Pictorial

A.1.37.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the user-asssigned device ccode or numberr string. VSTRn: User-assigned deevice code or number n string. Co ode or number of device assig gned by end usser. A.1.37.2.3

No otes

It is reecommended th hat device man nufacturers pro ovide a configuurable means fo for the end userr to locally store a text device code/nu umber.




A.1.38

De evice attributtes—user-as ssigned devi ce name Group:

0

Variation:

247

Device Attributes A

Type:

Attrib

User-assiigned device namee

Parsing Codes:

Table 12-1


A.1.38.1 De escription This attribute a is a name given to th he device by thee end user. The co ontent of this attribute a is a freee form string that t is formatteed according too the user’s norrmal practice. Two examples e are “Main Streeet Sub” and “500805RTU100 0.” A.1.38.2

Co oding

A.1.38.2.1

Pictorial

A.1.38.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the user-asssigned device nname string. VSTRn: User-assigned deevice name string. Naame of device assigned a by en nd user. A.1.38.2.3

No otes

It is reecommended th hat device man nufacturers pro ovide a configuurable means fo for the end userr to locally store a text device name.




A.1.39

De evice attributtes—device serial numbe er Group:

0

Variation:

248

Device Attributes A

Type:

Attrib

Device seerial number

Parsing Codes:

Table 12-1


A.1.39.1 De escription This attribute a is the serial s number assigned a by thee device manuffacturer. The co ontent of this attribute a is a frree form string g that is formattted accordingg to the manufaacturer’s norm mal practicce. Two examples e are “2003-07-0 04:1234” and “5 5Z4B-6xy9.” A.1.39.2

Co oding

A.1.39.2.1

Pictorial

A.1.39.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the manufaccturer’s serial number string.. VSTRn: Manufacturer’s M serial s number string. s Maanufacturer’s serial s number.




A.1.40

De evice attributtes—DNP3 subset s and c onformance e Group:

0

Variation:

249

Device Attributes A

Type:

Attrib

DNP3 su ubset and conformaance

Parsing Codes:

Table 12-1


A.1.40.1 De escription This attribute a has three t fields th hat identify th he DNP3 subsset level, a seeparator, and the DNP3 Teest Proced dure version fo or which the deevice was certiffied. A.1.40.2

Co oding

A.1.40.2.1

Pictorial

A.1.40.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the subset leevel, colon, andd test procedurre versions. VSTR1: Su ubset level. Th here are four su ubset level valu ues permitted: AS SCII “0” indicaates unknown, not determinedd, or none claim med. AS SCII “1” indicaates subset leveel 1. AS SCII “2” indicaates subset leveel 2. AS SCII “3” indicaates subset leveel 3. AS SCII “4” indicaates subset leveel 4. VSTR1: Co olon. An n ASCII colon n, “:” (binary value v 0x3A). T This separator iis mandatory aand shall appear in the attribute sttring.




VSTRn: Test procedure version. DNP3 Test Procedure version for which the device was certified. This is usually a calendar year number such as “2003.” If the device has not been tested, this field shall be omitted from the object. In the future, this field may contain more characters if conformance levels are coded differently. A.1.40.2.3

Notes

An example attribute has 6 characters and is coded as “1:2003”.




A.1.41

De evice attributtes—device manufacture er’s product name and m model Group:

0

Variation:

250

Device Attributes A

Type:

Attrib

Device manufacturer’s m prod duct name and mo odel

Parsing Codes:

Table 12-1


A.1.41.1 De escription This attribute a is the device d manufacturer’s producct name and m model. The co ontent of this attribute is a free f form strin ng that identifi es an industryy recognizable trade name annd modell. The string sh hould not includ de the manufaccturer’s name aas that appearss in attribute vaariation 252. Severaal examples aree “Callisto,” “D25 “ IED,” “F Form 5 Recloseer,” “SEL-351 Relay,” “NTU U-7500,” “PDS S Magna,” “IntelliCap,,” and “Multico omm.” A.1.41.2

Co oding

A.1.41.2.1

Pictorial

A.1.41.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the manufaccturer’s producct name and model string. VSTRn: Manufacturer’s M product p name and a model strinng. Maanufacture’s prroduct name an nd model.




A.1.42 2

De evice attributtes—device manufacture er’s name Group:

0

Variation:

252

Device Attributes A

Type:

Attrib

Device manufacturer’s m nam me

Parsing Codes:

Table 12-1


A.1.42 2.1 De escription This attribute a is the name of the device d manufaccturer. An exam mple is “123 S SCADA, Ltd.”” The content oof this attribute is a freee form string. A.1.42 2.2

Co oding

A.1.42 2.2.1

Pictorial

A.1.42 2.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the attrribute data typee code, VSTR. (Refer to Tab ble 5-16.) UINT8: Leength. Sp pecifies the num mber of octets in i the manufaccturer’s name sstring. VSTRn: Manufacturer’s M name n string. Maanufacture’s naame.




A.1.43

De evice attributtes—non-specific all attrributes reque est Group:

0

Variation:

254

Device Attributes A

Type:

Attrib

Non-speccific all attributes request r

Parsing Codes:

Table 12-1


A.1.43.1 De escription This attribute a is useed as a shorth hand to requesst an outstatioon to return alll of its attribuutes in a singgle respon nse. The master sends a singlle object headeer with this varriation in lieu oof including a ppossibly lengthhy list of object headerss in the requestt. A.1.43.2 Co oding This variation v does not n have objectts. A.1.43.2.1

No otes

This variation v may only o appear in a master request. It shall not bbe used in respponses from ouutstations. Requeests from a masster use group 0, 0 variation 254 qualifier codde ⎯ 0x00 where the start-sto op range field d indexes indiicate from whhich set or sets of outstatioon I 0 is the set s of attributes defined by thhe DNP Users Group. Other indexes speciffy attributes. Index privately deefined or vendo or-specific attriibute sets. ⎯ 0x06. Devices that implem ment attributes are a required to support this vaariation.




A.1.44 4

De evice attributtes—list of attribute a varia ations Grroup:

0

Vaariation:

255

Device Attributes A

Tyype:

Attrib

List of attribute a variations

Paarsing Coodes:

Table 12-1

DNP3 Object Libraary Group Nam me: Variation Name:

A.1.44 4.1 De escription This is i a special atttribute number that is used to retrieve a list of all of the device atttribute variatioon numbeers supported by the outstattion at a speciified index,39 aand the propeerties of those attributes. Thhis objectt has a variablee length that depends on the count of attribuute variations suupported by thhe outstation. A.1.44 4.2

Co oding

A.1.44 4.2.1

Pictorial

A.1.44 4.2.2 Fo ormal structu ure UINT8: Atttribute data typ pe code. Sp pecifies the atttribute data type code, U U8BS8LIST orr U8BS8EXL LIST. (Refer to Ta able 5-16.) UINT8: Leength. Sp pecifies the num mber of octetss in the follow wing list of varriation numbers and propertiees (ussed in conjuncttion with the preceding field to allow more than 255 octetts in the list). SET of n: Data D elements. { UINT8: Atttribute variatio on number. Th he number of an n attribute variiation that is suupported in thee device. BSTR8: Atttribute propertties. Bitt 0 indicates whether w the dev vice attribute iss writable by tthe master. If tthe bit is set, thhe maaster can chang ge the respective attribute byy sending a reqquest message having functioon code [WRITE]. 39

The different d sets of atttributes are retrieveed using the “index” field in the DN NP3 application heaader to denote the set number; indexx 0 is used for the attribute seet defined by the DNP D Users Group.




Bits 1 through 7 are reserved. } where n is the number of device attribute variations supported by the outstation. A.1.44.2.3

Notes

The list does not include variations 254 and 255. Devices that implement attributes are required to support this variation. This attribute variation is not writable.




A.2

Ob bject group p 1: binary inputs

A.2.1

Binary input— —packed form mat Group:

1

Variation:

1

Binary Input

Type:

Static

Packed format f

Parsing Codes:

Table 12-2

DNP3 Object O Libraary Group Name: Variation Name:

A.2.1.1 De escription Objectt group 1, varriation 1 is useed to report th he current valuue of a binary input point. S See 11.9.8 for a descrip ption of a Binaary Input Pointt Type. Variattion 1 objects contain c a singlee-bit binary inp put state withouut status flags. A.2.1.2 Co oding This object o is coded d as a single biit, with a possible value of 0 or 1, for eacch point index.. When multipple points are contained in a single resp ponse messagee, they are packked, as illustratted in the folloowing pictorial. A.2.1.2.1

Pictorial

f depicts the t bit-packing g sequence for a response conntaining bit indexes m throuugh n. As can bbe This figure seen, the t first bit is in the bit 0 po osition of the fiirst octet, the ssecond bit is inn the bit 1 possition of the firrst octet, etc. Any unuseed bits in the fiinal octet are reeturned as 0. A.2.1.2.2 Fo ormal structu ure BSTRn: Sttates n in i BSTRn represents the num mber of indexess reported in thhe bit string. Bitt 0 in the bit string corresponds to the loowest point inddex reported. Subsequent biits correspond to seq quentially increeasing point inndexes. Un nused bits in th he last octet aree padded with 00. Eaach bit has a vaalue of 0 or 1, representing r thhe state of the pphysical or logiical input. A.2.1.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 2, Bin nary Input withh Flags, shall bbe used for poiints that have aan abnorm mal condition that t can be reported with flag g bits.




A.2.2

Binary input— —with flags Group:

1

Variation:

2

Binary Input

Type:

Static

With flaags

Parsing Codes:

Table 12-2


A.2.2.1 De escription Objectt group 1, varriation 2 is useed to report th he current valuue of a binary input point. S See 11.9.8 for a descrip ption of a Binaary Input Pointt Type. Variattion 2 objects contain c a statuss octet that inclludes the state of the binary innput. A.2.2.2

Co oding

A.2.2.2.1

Pictorial

A.2.2.2.2 Fo ormal structu ure BSTR8: Flag Octet

A.2.2.2.3

Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

CHATTER_F FILTER

Bitt 6:

Reserved, alw ways 0

Bitt 7: log gical input.

STATE—Haas a value of 0 oor 1, representting the state off the physical oor

No otes

See 11 1.6 for flag bit descriptions.




A.3

Ob bject group p 2: binary input events s

A.3.1

Binary input ev vent—withou ut time Group:

2

Variation:

1

Binary Input Event

Type:

Event

Withoutt time

Parsing Codes:

Table 12-3


A.3.1.1 De escription Objectt group 2, varriation 1 is ussed to report events relatedd to a binary iinput point. S See 11.9.8 for a descrip ption of a Binaary Input Pointt type. Variattion 1 objects contain c an octet for reporting the state of thee input and stattus flags. A.3.1.2

Co oding

A.3.1.2.1

Pictorial

A.3.1.2.2 Fo ormal structu ure BSTR8: Flag Octet

A.3.1.2.3

Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

CHATTER_F FILTER

Bitt 6:




No otes





A.3.2

Binary input ev vent—with absolute a time e Group:

2

Variation:

2

Binary In nput Event

Type:

Event

With absolute time

Parsing Codes:

Table 12-3


A.3.2.1 De escription Objectt group 2, varriation 2 is ussed to report events relatedd to a binary iinput point. S See 11.9.8 for a descrip ption of a Binaary Input Pointt Type. Variattion 2 objects contain an octtet for reportin ng the state off the input and status flags, aand the absoluute time when w the event occurred. A.3.2.2

Co oding

A.3.2.2.1

Pictorial

ormal structu ure A.3.2.2.2 Fo BSTR8: Flag Octet Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

CHATTER_F FILTER

Bitt 6:




DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. A.3.2.2.3

No otes





A.3.3

Binary input ev vent—with relative time Group:

2

Variation:

3

Binary Input Event

Type:

Event

With rellative time

Parsing Codes:

Table 12-3


A.3.3.1 De escription Objectt group 2, varriation 3 is ussed to report events e related to a Binary Input point. S See 11.9.8 for a descrip ption of a Binaary Input Pointt Type. Variattion 3 objects contain c an octet for reporting the state of thee input and stattus flags, and tthe relative tim me when the event occu urred. A preced ding common tiime-of-occurreence (CTO) obj bject, group 51,, establishes thhe basis of o the relative time. t A.3.3.2

Co oding

A.3.3.2.1

Pictorial

ormal structu ure A.3.3.2.2 Fo BSTR8: Flag Octet Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

CHATTER_F FILTER

Bitt 6:




UINT16: Relative R time-of-occurrence. Tim me, in millisecconds, when th he event occurrred, with resppect to the preceding commoon tim me-of-occurren nce object. A.3.3.2.3

No otes

See 11 1.6 for flag bit descriptions. See th he CTO descrip ption, group 51, for more in nformation aboout common tim me-of-occurrennce and relativve times.




A.4

Ob bject group p 3: double-bit binary in nputs

A.4.1

Do ouble-bit binary input—p packed forma at Group:

3

Variation:

1

Double-b bit Binary Input

Type:

Static

Packed fo ormat

Parsing Codes:

Table 12-4


A.4.1.1 De escription Objectt group 3, varriation 1 is ussed to report the t current vallue of a double-bit binary iinput point. Seee 11.9.6 6 for a descriptiion of a Doublee-bit Binary In nput Point Typee. Variattion 1 objects contain c double--bit binary inpu ut states packeed without statuus flags. A.4.1.2 Co oding This object o is coded d as a two-bit,, unsigned inteeger with posssible values off 0 to 3, for eaach point indeex. When multiple poin nts are contain ned in a singlee response messsage, they aree packed, as illustrated in thhe wing pictorial. follow A.4.1.2.1

Pictorial

f depicts th he bit-packing g sequence for a response conntaining doublee-bit group inddexes m througgh This figure n. As can c be seen, th he first double-bit state is in th he bit 0 and 1 pposition of thee first octet, thee second doublebit staate is in the bit 2 and 3 positiion of the first octet, etc. Anyy unused doubble-bit groups iin the final octtet are retturned as 0. Fo A.4.1.2.2 ormal structu ure SET of n UINT2: U State. n represents r the number n of indeexes reported. Th he first index iss aligned on bitt 0 of the first ooctet. Un nused bits in th he last octet aree padded with 00. Eaach integer con ntains a state as defined forr a Double-bitt Binary Inputt Point Type in 11.9.6. These values repreesent states INTERMEDIA ATE, DETER RMINED_OFF F, ETERMINED_ _ON, and INDETERMINAT TE. DE A.4.1.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. Variation V 2, Do ouble-bit Binarry Input with fflags, shall be used for poinnts that haave an abnormal condition th hat can be reporrted with flag bbits.




A.4.2

Do ouble-bit binary input—w with flags Group:

3

Variation:

2

Double-b bit Binary Input

Type:

Static

With flag gs

Parsing Codes:

Table 12-4


A.4.2.1 De escription Objectt group 3, varriation 2 is ussed to report the t current staate of a doublle-bit binary iinput point. Seee 11.9.6 6 for a descriptiion of a Doublee-bit Binary In nput Point Typee. Variattion 2 objects contains c a statu us octet that inccludes the statee of the double-bit binary input. A.4.2.2

Co oding

A.4.2.2.1

Pictorial

A.4.2.2.2 Fo ormal structu ure BSTR6: Flags Bitt 0:

ONLINE E

Bitt 1:

RESTAR RT

Bitt 2:

COMM_L LOST

Bitt 3:

REMOTE E_FORCED

Bitt 4:

LOCAL__FORCED

Bitt 5:

CHATTE ER_FILTER

UINT2: Staate. Th his integer conttains the state of the double--bit binary inpput as defined ffor a Double-bbit Bin nary Input Po oint Type in 11.9.6. 1 These values repressent states INT TERMEDIATE E, DE ETERMINED_ _OFF, DETER RMINED_ON, and INDETER RMINATE. A.4.2.2.3

No otes





A.5

Ob bject group p 4: double-bit binary in nput events s

A.5.1

Do ouble-bit binary input eve ent—withoutt time Group:

4

Variation:

1

Double-b bit Binary Input Ev vent

Type:

Event

Without time t

Parsing Codes:

Table 12-5


A.5.1.1 De escription Objectt group 4, vaariation 1 is used u to report events relateed to a doublee-bit binary innput point. Seee 11.9.6 6 for a descriptiion of a Doublee-bit Binary In nput Point Typee. Variattion 1 objects contains c a statu us octet that inccludes the inpuut state. A.5.1.2

Co oding

A.5.1.2.1

Pictorial

A.5.1.2.2 Fo ormal structu ure BSTR6: Flags Bitt 0:

ONLINE E

Bitt 1:

RESTAR RT

Bitt 2:

COMM_L LOST

Bitt 3:

REMOTE E_FORCED

Bitt 4:

LOCAL__FORCED

Bitt 5:

CHATTE ER_FILTER

UINT2: Staate. Eaach integer con ntains a state as defined forr a Double-bitt Binary Inputt Point Type in 11.9.6. These values repreesent states INTERMEDIA ATE, DETER RMINED_OFF F, ETERMINED_ _ON, and INDETERMINAT TE. DE A.5.1.2.3

No otes





A.5.2

Do ouble-bit binary input eve ent—with ab bsolute time Group:

4

Variation:

2


Type:

Event

With absolute time

Parsing Codes:

Table 12-5


A.5.2.1 De escription Objectt group 4, vaariation 2 is used u to report events relateed to a doublee-bit binary innput point. Seee 11.9.6 6 for a descriptiion of a Doublee-bit Binary In nput Point Typee. Variattion 2 objects contain c a statuss octet for repo orting the statee of the input aand status flagss, and a time-oofoccurrrence. A.5.2.2

Co oding

A.5.2.2.1

Pictorial

A.5.2.2.2 ormal structu ure Fo BSTR6: Flags Bitt 0:

ONLINE E

Bitt 1:

RESTAR RT

Bitt 2:

COMM_L LOST

Bitt 3:

REMOTE E_FORCED

Bitt 4:

LOCAL__FORCED

Bitt 5:

CHATTE ER_FILTER

UINT2: Staate. Th his integer con ntains a state as defined forr a Double-bitt Binary Inputt Point Type in 11.9.6. These values repreesent states INTERMEDIA ATE, DETER RMINED_OFF F, ETERMINED_ _ON, and INDETERMINAT TE. DE DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. A.5.2.2.3

No otes

See 11 1.6 for flag bit descriptions. 496 Copyright © 2012 IEEE. All rightts reserved.



A.5.3

Do ouble-bit binary input eve ent—with rellative time Group:

4

Variation:

3


Type:

Event

With relaative time

Parsing Codes:

Table 12-5


A.5.3.1 De escription Objectt group 4, vaariation 3 is used u to report events relateed to a doublee-bit binary innput point. Seee 11.9.6 6 for a descriptiion of a Doublee-bit Binary In nput Point Typee. Variattion 3 objects contain c a status octet for repo orting the statee of the input aand status flaggs, and a relativve time-o of-occurrence. A preceding co ommon time-o of-occurrence ((CTO) object, ggroup 51, estabblishes the bassis of the relative time. A.5.3.2

oding Co

A.5.3.2.1

Pictorial

A.5.3.2.2 ormal structu ure Fo BSTR6: Flags Bitt 0:

ONLINE E

Bitt 1:

RESTAR RT

Bitt 2:

COMM_L LOST

Bitt 3:

REMOTE E_FORCED

Bitt 4:

LOCAL__FORCED

Bitt 5:

CHATTE ER_FILTER

UINT2: Staate. Th his integer con ntains a state as defined forr a Double-bitt Binary Inputt Point Type in 11.9.6. These values repreesent states INTERMEDIA ATE, DETER RMINED_OFF F, ETERMINED_ _ON, and INDETERMINAT TE. DE UINT16: Relative R time-of-occurrence. Tim me, in millisecconds, when th he event occurrred, relative too the precedingg common tim meof--occurrence ob bject. A.5.3.2.3

No otes

See 11 1.6 for flag bitt descriptions. See the CTO description, ggroup 51, for m more informattion on commoon time-o of-occurrence and a relative tim mes.




A.6

Ob bject group p 10: binary outputs

A.6.1

Binary output— —packed forrmat Group:

10

Variation:

1

Binary Output O

Type:

Static

Packed fo ormat

Parsing Codes:

Table 12-6


A.6.1.1 De escription Objectt group 10, varriation 1 is useed to control or o report the staate of one or m more binary ouutput points. Seee 11.9.4 4 for a descriptiion of the Binaary Output Poin nt Type. This object o is suitable for DNP3 devices d with eleectro-mechaniccal relays, pseuudo-controls, aand other output mechaanisms. Contro ol actions are initiated by seending a request message fr from the masteer with the Appplication Layer functio on code writee (2). This variation v shou uld only be uused to contrrol points thaat implement a compllementary latch h model. To obttain the outputt state of a binaary output poin nt, regardless oof which point type model is implemented at the respective index x, a request is sent from thee master with Application L Layer functionn code read (11). ver, the state returned r is onlly meaningful if the characteeristics of the point are suchh that the output Howev retainss a meaningfull state for a sig gnificant amou unt of time afteer a control coommand is issuued to the poinnt. The sttate is readable even if the binary b output point is contrrolled through some other m means, such as a manuaal operation, software autom mation comman nd, or the masster issuing a control comm mand with objeect g12v1. A.6.1.2 oding Co This object o is coded d as a single biit, with a possible value of 1 or 0, for eacch point index.. When multipple points are contained in a single message, they aree packed, as illuustrated in the following picttorial. A.6.1.2.1

Pictorial

This figure f depicts th he bit-packing sequence for a command coontaining bit inndexes m throuugh n. As can bbe seen, the t first bit is in the bit 0 po osition of the fiirst octet, the ssecond bit is inn the bit 1 possition of the firrst octet, etc. Any unuseed bits in the fiinal octet are seet to 0. A.6.1.2.2 Fo ormal structu ure BSTRn: Ou utput states n in i BSTRn represents the num mber of indexess appearing in tthe bit string. Bitt 0 in the bit sttring correspon nds to the lowest point index tto be commandded. Subsequent bitts correspond to sequentially increasing poiint indexes. Bitt 0 in the bit sttring is aligned d with bit 0 of th the first octet. 498 Copyright © 2012 IEEE. All rightts reserved.



Unused bits in the last octet are padded with 0. Each bit has a value of 1 or 0 where 1 indicates the output is active and 0 indicates the output is not active. When the output state is not meaningful, the bit shall be 0. A.6.1.2.3

Notes

The preferred method for issuing control commands to a binary output point is by including a g12v1 object with the select and operate function codes. The reason is that the status of the operation is returned in the command response, whereas the response to a write request message does not describe the success of the operation. A point index in object group 10 corresponds to the same physical or logical point as the identical index in object groups 11, 12, and 13.




A.6.2

Binary output— —output stattus with flag gs Group:

10

Variation:

2

Binary Output O

Type:

Static

Output sttatus with flags

Parsing Codes

Table 12-6


A.6.2.1 De escription Objectt group 10, varriation 2 is used d to report the status of a bin ary output poinnt. See 11.9.4 ffor a descriptioon of the Binary Outputt Point Type. Variattion 2 objects contains c a flag octet that inclu udes the activat ation state of thhe continuous ooutput signal. A.6.2.2

Co oding

A.6.2.2.1

Pictorial

octett transmission orrder

7 ST

6 0

5 0

4 LF

3 2 RF R CL

1 0 R OL RS

bit position

State and flag octet

A.6.2.2.2 Fo ormal structu ure BSTR8: Flag Octet Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:


Bitt 6:


Bitt 7: STATE—Vaalue is 1 or 0, where 1 indiccates that the output signal is acttive and 0 ind dicates that thee output signall is not active. When the ouutput state is not meeaningful, the STATE S flag sh hall be 0. A.6.2.2.3

No otes

See 11 1.6 for flag bit descriptions. A poin nt index in object group 10 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 11, 12, and 13.




A.7

Ob bject group p 11: binary output eve ents

A.7.1

Binary output event—statu us without tim me Group:

11

Variatioon:

1

Binary Output O Event

Type:

Evvent

Status without w time

Parsingg Codes:

Taable 12--7

DNP3 Object Lib brary Group Nam me: Variation Name:

A.7.1.1 De escription A Bin nary Output Ev vent object is an a instance off a report for aan outstation’s correspondingg Binary Output Static object (objectt group 10). See 11.9.4 for a description oof the Binary Output Point Type. A Binarry ut Event may bee generated forr a point only if i the outstationn returns an ouutput static objeect for that point Outpu in resp ponse to a statiic (Class 0) req quest. A chang ge event may bbe generated byy an outstationn when it deteccts someth hing of interesst has occurred d. Examples off this include a change in outtput point statee, or a change in outputt object flags. A binary outpu ut event objectt may also be ggenerated due tto other appliccation dependent reason ns. For biinary output points, p changees to the exceeption flags, aand changes oof the output state when th he underrlying point retains r a value for a signifficant amountt of time, are reported withh Binary Output Event objects. The binary b output point’s status (in ncluding flags)) at the time w when the event iis generated annd d is the status placed p into thee Binary Outpu ut Event object.. queued This object o shall nott be generated to simply repo ort that a comm mand was received. Object G Group 13 objeccts should d be used for th his purpose. Generration of Binarry Output Even nts is optionall for an outstaation, and mayy occur in one or more of thhe follow wing situations:: ⎯ Output point state changed d—Upon a con ntrol from a m master or upsttream device tthat results in a utput point, thee outstation maay generate an eevent object foor that point. Foor change to the status of an ou t same outpuut point on an ooutstation, a chhange event maay example, wheere multiple maasters control the be generated to t one or more master station ns to indicate thhat the output cchanged state. m a master may result in a chaange to the statuus ⎯ External effeccts—Mechanisms other than a control from of a point represented by an n output objectt. An event maay be generatedd to indicate too the master thhat the output poiint status has ch hanged. For ex xample, a locall automation seequence may ooverride the staate of a point set by b a previous control c from th he master. d—Where an outstation o geneerates Binary O Output Events ffor a particularr point, an event ⎯ Flags changed shall be generrated when any y of the flags for f the output ppoint change. N Note that the fflags in the flaggs octet relates to o the output po oint status and not n to the statuus value of anyy related input ppoint(s). Outstaations that impllement this objject: ⎯ Shall be able to t configure whether w output change c events are generated on output poinnts. ⎯ Should suppo ort Application Layer Functio on Code 22 (ASSSIGN_CLASS) fo for Object Grouup 10, Variatioon 0, if the outstaation device su upports Assign Class functionns on other objects. When events are con nfigured for a particular p outpu ut point, the ouutstation: ⎯ May generate an event when n something off interest happeens on the outpput point. ⎯ When flags arre supported fo or the point, sh hall generate aan event when any of the staatus flags for thhe output point change. c




⎯ Shall generate an event upon a change in the output point state, where the output point retains a meaningful state for a significant amount of time. A Binary Output Event shall be reported for transitions both to the active and to the not active output states. ⎯ Shall not generate an output change event solely for the purpose of indicating that a command has occurred on a point. An Object Group 13 object may be generated to indicate this. Object Group 11 objects are independent from Object Group 13 objects. Variation 1 objects contain a flag octet that indicates the status of the output point. For output points that retain a state, the state shall be indicated in the flag octet. Where a state is reported in a Binary Output Event, the state shall be that of the output point itself, not feedback resulting from the plant being driven, and any such change shall generate an event. A.7.1.2

Coding

A.7.1.2.1

Pictorial

A.7.1.2.2 Formal structure BSTR8: Flag Octet Bit 0:

ONLINE

Bit 1:

RESTART

Bit 2:

COMM_LOST

Bit 3:

REMOTE_FORCED

Bit 4:

LOCAL_FORCED

Bit 5:

Reserved, always 0

Bit 6:

Reserved, always 0

Bit 7: STATE—Value is 1 or 0, where 1 indicates that the output signal is active and 0 indicates that the output signal is not active. Where the output object does not have a meaningful output state, the STATE flag shall be 0. A.7.1.2.3

Notes

See 11.6 for flag bit descriptions. A point index in object group 11 corresponds to the same physical or logical point as the identical index in object groups 10, 12, and 13. This object group’s events are assigned to a specific event class using an assign class message with objects from object group 10 and the respective indexes.




A.7.2

Binary output event—statu us with time Group:

11

Variatioon:

2

Binary Output O Event

Type:

Evvent

Status with w time

Parsingg Codes:

Taable 12--7


A.7.2.1 De escription See object o group 11, 1 variation 1 for a description of Binnary Output E Events, event detection, annd implem mentation requ uirements. Variattion 2 objects contain a flaag octet that indicates the status of the output point and a time-oofoccurrrence. A.7.2.2

Co oding

A.7.2.2.1

Pictorial

A.7.2.2.2 ormal structu ure Fo BSTR8: Flag Octet Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:


Bitt 6:


Bitt 7: STATE—Vaalue is 1 or 0, where 1 indiccates that the output signal is acttive and 0 indiicates that the output signal is not active. Where the outtput object doees no ot have a meaniingful output sttate, the STAT TE flag shall bee 0. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred.




A.7.2.2.3

Notes

See 11.6 for flag bit descriptions. A point index in object group 11 corresponds to the same physical or logical point as the identical index in object groups 10, 12, and 13. This object group’s events are assigned to a specific event class using an assign class message with objects from object group 10 and the respective indexes.




A.8

Ob bject group p 12: binary output com mmands

A.8.1 CROB B

Binary output command— —control relay y output bloc ck—also kno own as Group:

12

Variation:

1

Binary Output O Command

Type:

Cmnd

Control relay r output block— —also known as CROB C

Parsing Codes:

Table 12-8


A.8.1.1 De escription Objectt group 12, vaariation 1 is used u to perform m digital contrrol operations at binary outp tput points. It is suitablle for DNP3 devices d with electro-mechanical relays, pseeudo-controls, and other outpput mechanism ms. Each g12v1 g object contains a block k of informatio on that applies to a single indeex. See 11 1.9.4 for a description of thee Binary Outpu ut Point Type. In summary, tthere are threee control modeels for wh hich this objectt is appropriatee. a))

Activation model—Has m a single virtual or physical ouutput. Its purpoose is to initiate an action (i.ee., “cause it to happen”).

b)) Complemen ntary latch mo odel—Has a sin ngle virtual orr physical outpput that remainns latched in aan active or no on-active state depending on which w commannd is received. c))

Complemen ntary two-outp put model—Haas two virtual or physical ooutputs, namedd close and triip. One or the other o output is set active mom mentarily depeending on whicch command is received.

Contro ol actions are initiated i by sending one or more m request m messages from m a master withh an appropriaate Appliccation Layer function f code, select (3), op perate (4), dirrect operate (55), or direct ooperate withou ut ackno owledgment (6)), along with a g12v1, object for each pointt index to be coontrolled. Thiss object shall not be useed with a write function code (2). A.8.1.2

Co oding

A.8.1.2.1

Pictorial

A.8.1.2.2 ormal structu ure Fo UINT4: Co ontrol code, Op peration Type field f [Op Typee]. 505 Copyright © 2012 IEEE. All rightts reserved.



This field is used in conjunction with the TCC field to specify a control operation. See operational functions (A.8.1.3.2) for additional details. The code names are: 0:

NUL

1:

PULSE_ON

2:

PULSE_OFF

3:

LATCH_ON

4:

LATCH_OFF

5 to 15: Undefined BSTR1: Control code, Queue field [QU]. This field is obsolete. The master shall always set this bit to 0. Outstations that receive a g12v1 object with this bit set shall return a status code NOT_SUPPORTED in the response. BSTR1: Control code, Clear field [CR]. Support for this field is optional. If the device supports commands with the clear bit set: ⎯ It shall support the case where the Op Type code is NUL, and may support the command for other Op Type values. ⎯ When the clear bit is set, the device shall remove pending control commands for that index and stop any control operation that is in progress for that index. The indexed point shall go to the state that it would have if the command were allowed to complete normally. If a non-NUL Op Type code is requested, the new command shall be initiated immediately after the cancellation actions complete. When the clear bit is set and the TCC - Op Type combination is not supported, the device shall return status code NOT_SUPPORTED in the response. UINT2: Control code, Trip-Close Code field [TCC]. This field is used in conjunction with the Op Type field to specify a control operation. See operational functions for additional details. The code names are 0:

NUL

1:

CLOSE

2:

TRIP

3:

RESERVED

UINT8: Count. This is the number of times the outstation shall execute the operation. Counts greater than 1 generate a series of pulses or repeated operations for the point. Both On-time and Offtime values are obeyed as illustrated in the figures under timing illustrations, subject to the comments regarding timing in interpreting the time fields. Implementation of a zero-count functionality is optional. A count value of 0 indicates that the output operation shall not be executed. Setting the count value to 0 is a useful technique for testing communications without affecting an output. When the outstation receives a 0 value, it shall: ⎯ Not change the output. ⎯ Ignore the On-time and Off-time values. ⎯ Return the same status code as if the execution had been attempted. 506 Copyright © 2012 IEEE. All rights reserved.



An outstation shall return status code NOT_SUPPORTED in the response when the count value is 0 in the request and the outstation does not implement the zero-count functionality. UINT32: On-time. This is the duration, expressed as the number of milliseconds, that the output drive remains active. See interpreting the time fields for more details. UINT32: Off-time. This is the duration, expressed as the number of milliseconds that the output drive remains non-active. See interpreting the time fields for more details. UINT7: Status code. This value shall be set to 0 in request messages. In response messages, this value represents the status of the selected or executed command. See Table 11-7 for descriptions of control-related status codes. BSTR1: Reserved [RES]. This bit is reserved. The master and outstation shall always set it to 0. A.8.1.3

Notes

A.8.1.3.1 Timing illustrations This subclause illustrates just two of the many timing possibilities that can appear in a g12v1 object.

PULSE ON with Count = 3

PULSE OFF with Count = 2 (Not interoperable) 507 Copyright © 2012 IEEE. All rights reserved.



A.8.1.3.2

Operational functions

A.8.1.3.2.1 Interoperable commands Only a few of the 64 possible TCC and Op Type field bit combinations are interoperable. Table A-1 indicates, for each point index, which commands are optional, preferred, not permitted, or not interoperable, depending on which point model is implemented. Table A-1—Interoperable control commands TCC field NUL

NUL

NUL

NUL

CLOSE

TRIP

Op Type field

Point model in outstation

NUL

PULSE_ON

LATCH_ON

LATCH_OFF

PULSE_ON

PULSE_ON

All other combinations

Support requirements

All

Optional

Activation

May support

Complementary latch

Not permitted

Complementary two-output

Not permitted

Activation

May support

Complementary latch

Preferred support


May support

Activation

May support

Complementary latch

Preferred support


May support

Activation

May support

Complementary latch

May support


Preferred support

Activation

May support

Complementary latch

May support


Preferred support

All

Not interoperable

Table A-2 indicates for a single point index, what action the outstation performs based on the contents of the interoperable control codes and the point model implemented. Table A-2—Actions performed by outstation for interoperable commands Row Control # code

TCC field

Op Type field

Clear field

1

0x00

NUL

NUL

0

2

0x20

NUL

NUL

1

3

0x01

NUL

PULSE_ON

0

Action

Does not initiate an action or change an in-progress or pending command. Values in On-time and Off-time fields are ignored. Cancel in-progress and pending commands. Values in Ontime and Off-time fields are ignored. For activation model, set output to active for the duration of the On-time. For both complementary models, return NOT_SUPPORTED status. 508




Row Control # code

TCC field

Op Type field

Clear field

4

0x21

NUL

PULSE_ON

1

5

0x03

NUL

LATCH_ON 0

6

0x23

NUL

LATCH_ON 1

7

0x04

NUL

LATCH_OFF 0

8

0x24

NUL

LATCH_OFF 1

9

0x41

CLOSE PULSE_ON

0

10

0x61

CLOSE PULSE_ON

1

11

0x81

TRIP

PULSE_ON

0

12

0xA1

TRIP

PULSE_ON

1

Action

For activation model, cancel in-progress and pending commands and then set output to active for the duration of the On-time. For both complementary models, return NOT_SUPPORTED status. For activation model, set output to active for the duration of the On-time. For complementary latch model, set the output to active. For complementary two-output model, set the close output to active for the duration of the On-time. Cancel in-progress and pending commands. Afterwards, initiate the action specified in row 5. For activation model, set output to active for the duration of the On-time. For complementary latch model, set the output to inactive. For complementary two-output model, set the trip output to active for the duration of the On-time. Cancel in-progress and pending commands. Afterwards, initiate the action specified in row 7. For activation model, set output to active for the duration of the On-time. For complementary latch model, set the output to active. For complementary two-output model, set the close output to active for the duration of the On-time. Cancel in-progress and pending commands. Afterwards, initiate the action specified in row 9. For activation model, set output to active for the duration of the On-time. For complementary latch model, set the output to inactive. For complementary two-output model, set the trip output to active for the duration of the On-time. Cancel in-progress and pending commands. Afterwards, initiate the action specified in row 11.

A.8.1.3.2.2 Additional requirements Vendors of outstation devices are responsible for assigning control codes that are appropriate to their device. For example, a manufacturer might assign CLOSE – PULSE_ON and TRIP – PULSE_ON to a breaker and NUL – LATCH_ON and NUL – LATCH_OFF to a pseudo point. Each index point shall implement only one of the control models. It is acceptable for vendors to provide configuration to select a model, but during operation, the point type shall remain fixed. Differing point indexes may support dissimilar point type models; that is, not all the indexes within a device need to have the same model. For each point index implementing the activation model, at least one of the TCC – Op Type field combinations marked as “May support” in Table A-1 shall be accepted for this point type. If more than one is accepted, then each shall perform the identical function. For each point index implementing one of the complementary models, at least one of the following command pairs shall be chosen: NUL – LATCH_ON ↔ NUL – LATCH_OFF or CLOSE – PULSE_ON ↔ TRIP – PULSE_ON 509 Copyright © 2012 IEEE. All rights reserved.



For each point index implementing one of the complementary models, if both command pairs are supported, then NUL – LATCH_ON and CLOSE – PULSE_ON shall perform the identical function and NUL – LATCH_OFF and TRIP – PULSE_ON shall perform the identical function Vendors are free to implement operations using the PULSE_OFF value in the Op Type field, but these may not be interoperable with all DNP3 masters, and alternate outstation vendors may not implement these operations. One use would be the generation of a pulse train that ends in the output remaining active. For example, if the output value was active prior to a PULSE_OFF command, then the output would go inactive for the time determined by the Off-time and then the output would change to active. It is acceptable to use two separate indexes, each implementing the activation model, to provide complementary functionality. For example, one index can drive the “trip” coil and another index can drive the “close” coil of a single circuit breaker. Outstation vendors may choose one of the following procedures when a command is received for a presently operating point: ⎯ Wait for completion of the previous command before beginning the new command. ⎯ Return an error status code to the master. ⎯ Terminate the presently executing command and initiate the new command. A.8.1.3.2.3 Interpreting the time fields The values in the On-time and Off-time fields are suggestions for time durations. A few common interpretations are as follows: ⎯ Always ignore. The outstation uses configured values in lieu of the time values in the object. This choice minimizes the amount of configuration in the master. ⎯ Use unless zero. The outstation uses the values supplied unless they are zero. A 0-time value indicates that the device shall substitute its pre-configured value. This choice maximizes output flexibility but allows masters to execute “unwise” commands (such as “pulse for 50 days”). ⎯ Use if reasonable. The outstation uses the values if they are within an acceptable or configured range. Otherwise, the outstation substitutes an appropriate value. This choice provides limited output flexibility but increases the safety of the operation. ⎯ A combination of the above. A.8.1.3.2.4 Master configuration A master device shall be configurable as to which control codes it shall issue on a per-index basis. The choices shall include all of the odd-numbered rows, beginning with row 3, in Table A-2. In addition, the master shall allow configuration of the On-time field. It may optionally provide configurable Off-time and Count fields. If these are not configurable, the Off-time should be 0 and the Count should be 1. A.8.1.3.2.5 Minimal outstation implementation At each binary output point index, the outstation shall choose a point type model and which of the TCC and Op Type field values it shall support. In addition, it shall support a Count value of 1 and an Off-time value of 0. A.8.1.3.2.6 Point index correlation A point index in object group 12 corresponds to the same physical or logical point as the identical index in object groups 10, 11 and 13. 510 Copyright © 2012 IEEE. All rights reserved.



A.8.2

Binary output command— —pattern conttrol block—a also known a as PCB Group:

12

Variation:

2


Type:

Cmnd

Pattern control c block—alsso known as PCB

Parsing Codes:

Table 12-8


A.8.2.1 De escription Objectt group 12, varriation 2 is used d to control mu ultiple binary ooutput points. IIt is suitable foor DNP3 devicees with electro-mechan e nical relays, psseudo-controls,, and other outtput mechanism ms. This variaation is intendeed for perrforming contrrol operations at a multiple poin nts simultaneoously where conntrol actions arre accomplisheed concurrrently. See 11 1.9.4 for a description of thee Binary Outpu ut Point Type. In summary, tthere are threee control modeels for wh hich this objectt is appropriatee. a))

Activation model—Has m a single virtual or physical ouutput. Its purpoose is to initiate an action (i.ee., “cause it to happen”).

b)) Complemen ntary latch mo odel—Has a sin ngle virtual orr physical outpput that remainns latched in aan active or no on-active state depending on which w commannd is received. c))

Complemen ntary two-outp put model—Haas two virtual or physical ooutputs, namedd close and triip. One or the other o output is set active mom mentarily depeending on whicch command is received.

Execu uting controls is initiated by sending s one or more request messages from m a master withh an appropriaate Appliccation Layer function f code, select (3), op perate (4), dirrect operate (55), or direct ooperate withou ut ackno owledgment (6), along with a single g12v2 object follow wed by one oor more Patternn Mask objectts, g12v3. This object may m not be used d with a write function f code, 2. A.8.2.2

Co oding

A.8.2.2.1

Pictorial

A.8.2.2.2 ormal structu ure Fo Pleasee see the formaal structure for object g12v1, which w is identiical.




A.8.2.2.3

Notes

Please see notes (A.8.1.3) for object g12v1, which are identical.




A.8.3

Binary output command— —pattern mas sk Group:

12

Variation:

3


Type:

Cmnd

Pattern mask m

Parsing Codes:

Table 12-8


A.8.3.1 De escription Objectt group 12, varriation 3 is used d to control mu ultiple binary ooutput points. This variation v is ussed in conjuncction with an object g12v2 to specify whhich specific ppoints are to bbe simulttaneously contrrolled. Please see s A.8.2. Variattion 3 objects contain c a singlee bit for each output o point inddex. A.8.3.2 Co oding This object o is coded as a bit striing where eacch bit correspoonds to a poinnt index. Indeexes are packeed sequen ntially. A.8.3.2.1

Pictorial

f depicts the t bit-packing g sequence forr an object conntaining bit inddexes m througgh n. As can bbe This figure seen, the t first bit is in the bit 0 po osition of the fiirst octet, the ssecond bit is inn the bit 1 possition of the firrst octet, etc. Any unuseed bits in the fiinal octet are seet to 0. A.8.3.2.2 Fo ormal structu ure BSTRn: In ncluded point in ndexes n in i BSTRn represents the num mber of indexess appearing in tthe bit string. Bitt 0 in the bit string s corresponds to the low west point indexx. Subsequent bits corresponnd to sequentially in ncreasing pointt indexes. Bitt 0 in the bit sttring is aligned d with bit 0 of th the first octet. Un nused bits in th he last octet aree padded with 00. Eaach bit has a vaalue of 1 or 0, where w 1 indicaates that the resspective point shall participaate in the concurren nt signal activ vation specifieed by the precceding Patternn Control Blocck bject, and 0 indicates that the point index shaall not particippate. obj A.8.3.2.3

No otes

A poin nt index in object group 12 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 10, 11, and 13.




A.9

Ob bject group p 13: binary output com mmand even nts

A.9.1

Binary output command ev vent—comm mand status w without time Group:

13

Variatioon:

1

Binary Output O Command Event

Type:

Evvent

Comman nd status without time t

Parsingg Codes:

Taable 12--9


A.9.1.1 De escription A Bin nary Output Co ommand Even nt object reportts that a comm mand has beenn attempted onn an outstationn’s corresponding binary y output point. Example usag ges of this objeect include: ⎯ Reporting to a master devicee that an outstaation has receivved a control fr from another m master ⎯ Reporting to a master devicee that a successsful or unsucceessful control w was attempted ⎯ Reporting to a master devicee that a controll request was m made by an inteernal applicatioon ⎯ Reporting to a master device that a contro ol was receivedd and processed at an outstation when issueed through a non n-originating deevice (e.g., Datta Concentratoor) A com mmand event may m be generaated by an outsstation when itt receives a coontrol commannd for an output point from any interrnal or externaal source. Exam mples of this iinclude a comm mand request rreceived thouggh C a comm mand request from f a differennt protocol, a ccontrol changee command from DNP3 containing a CROB, pplication. a locall automation ap Wheree the controlled d binary outputt point retains an output statee, a control reqquest to the outtput point wouuld includ de state inform mation. That reequested contro ol state is retuurned in this bbinary output ccommand evennt. This object o does no ot return state or status inforrmation for thhe output pointt itself or anyy feedback input associated with the control. c Outputt command eveent objects receeived by a masster are intendeed to be used fo for inform mational purposses, such as being logged. Generration of Binarry Output Com mmand Events is optional foor an outstationn. This object may be used in conjun nction with Bin nary Output Ch hange Event ob bjects. Outstaations that impllement this objject: ⎯ Shall be able to t configure whether w output command c evennts are generateed on output pooints. ⎯ Should support Application Layer Functio on Code 22 (ASSSIGN_CLASS) foor object groupp 12, Variationn 0 if the outstatio on device supp ports Assign Cllass functions oon other objectts. ⎯ May generatee events when n controls aree commandedd from internaal sources (e.gg., applicationn), external sourcces requesting controls c (e.g., protocol p controol request), or both. ⎯ Shall not gen nerate this event until a com mmand is fullyy processed. For example w when receiving a Select Before Operate contro ol request, an event e shall not be generated ffollowing recepption of a Seleect command unttil either the Seelect fails or thee Operate is prrocessed. ⎯ Shall not gen nerate this even nt as a result of o an output pooint state channge or a statuss change. Objeect group 11 objeects are used for this purpose. Object grooup 13 objectss are independdent from objeect group 11 objeects. ⎯ Should provid de the result off processing th he control requuest in the conntrol status fielld of this objecct. Where this staatus can be pro ovided, it shalll be in the sam me format as thhe control statuus field provideed in DNP3 objeect 12, variation n 1.




⎯ Should provide at least an indication of whether the processed control request was accepted (status = 0) or not accepted for unknown reasons (status = 127). Where possible, it is recommended that the outstation return known, relevant status codes. Where the processed control was received through a DNP3 request, for example, the status code returned in the output command event status code should be the same status code used in the response to the control request. ⎯ May choose to send output command events (1) only when the control actually succeeds (i.e., status code = 0), or (2) for any control command regardless of whether it succeeds or fails (i.e., status code >= 0) Variation 1 objects contain information regarding the commanded state of the output (where the point retains state information) and status information indicating the status that resulted when the outstation processed the requested control on the point. Information provided in this object relates to a control request, and not to the resultant state or status of the point controlled. A.9.1.2

Coding

A.9.1.2.1

Pictorial

A.9.1.2.2 Formal structure UINT7: Status Code. This value represents the status from processing the command that this event object is reporting. See Table 11-7 for descriptions of control-related status codes. BSTR1: Commanded State. The commanded flag has a value of 0 or 1, representing the control requested for the physical or logical output. 0 = Latch Off / Trip / NULL, 1 = Latch On / Close. Where the commanded state is unknown, the commanded state flag shall be 0. A.9.1.2.3

Notes

A point index in object group 13 corresponds to the same physical or logical point as the identical index in object groups 10, 11, and 12. This object group’s events are assigned to a specific event class using an assign class message with objects from object group 12 and the respective indexes.




A.9.2

Binary output command ev vent—comm mand status w with time Group:

13

Variatioon:

2

Binary Output O Command Event

Type:

Evvent

Comman nd status with timee

Parsingg Codes:

Taable 12--9


A.9.2.1

De escription

See ob bject g13v1 forr a description of Binary Outp put Command Events and evvent detection. Variattion 2 objects contain c a statu us octet that ind dicates the com mmanded statee from the conntrol request, thhe status code that resullted when the outstation o proccessed the requuested control, and a time-of--occurrence. Thhe of-occurrence represents r the time t at which the t control reqquest was proceessed. Informaation provided in time-o this ob bject relates to a control requeest, and not to the resultant sttate or status oof the point conntrolled. A.9.2.2

Co oding

A.9.2.2.1

Pictorial

A.9.2.2.2 ormal structu ure Fo UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Co ommanded Staate. Th he commanded d flag has a vaalue of 0 or 1 , representing the control reequested for thhe ph hysical or logical output. 0 = Latch L Off / Triip / NULL, 1 = Latch On / C Close. Where thhe commanded statee is unknown, the t commandeed state flag shaall be 0. DNP3TIME: Time-of-occcurrence. Tim me when the control was pro ocessed. A.9.2.2.3

No otes

A poin nt index in object group 13 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 10, 11, and 12. This object o group’s events e are assigned to a specific event classs using an assiign class messaage with objeccts from object o group 12 2 and the respeective indexes.




A.10

Ob bject group p 20: counte ers

A.10.1

Co ounter—32-b bit with flag Group:

20

Variation:

1

Counter

Type:

Static

32-bit with flag

Parsing Codes:

Table 12-10


A.10.1.1 De escription Objectt group 20, variation 1 is used u to reportt the current vvalue of a couunter point. S See 11.9.5 for a descrip ption of a Coun nter Point Type. Variattion 1 objects contain c a 32-bitt, unsigned inteeger count valuue. A.10.1.2

Co oding

A.10.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:

Reserved, alw ways 0.

UINT32: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +4 294 967 295. A.10.1.2.3

No otes

See 11 1.6 for flag bit descriptions. Master devices shall ignore the RO OLLOVER flag g. 517 Copyright © 2012 IEEE. All rightts reserved.



A.10.2 2

Co ounter—16-b bit with flag Group:

20

Variation:

2

Counter

Type:

Static

16-bit with flag

Parsing Codes:

Table 12-10


A.10.2 2.1 De escription Objectt group 20, variation 2 is used u to reportt the current vvalue of a couunter point. S See 11.9.5 for a descrip ption of a Coun nter Point Type. Variattion 2 objects contain c a 16-bitt, unsigned inteeger count valuue. A.10.2 2.2

Co oding

A.10.2 2.2.1

Pictorial

A.10.2 2.2.2 Fo ormal structu ure BSTR8: Flag Octet Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:


UINT16: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +65 5 535. A.10.2 2.2.3

No otes

See 11 1.6 for flag bit descriptions. Master devices shall ignore the RO OLLOVER flag g.




A.10.3

Co ounter—32-b bit with flag, delta

DNP3 Object O Library Group

Counter

Name: Variation

Group:

20

Variation:

3

Type:

Static

32-bit with flag, delta

Name:

A.10.3.1 De escription Objectt group 20, varriation 3 is used d to report the current value oof a delta counnter point. Variattion 3 objects contain c a 32-bitt, unsigned inteeger count valuue. A.10.3.2

Co oding

A.10.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes

Delta counters are obsolete. New w designs shoulld not implemeent or specify tthis variation. A description is presen nted here for reeference only. See 11 1.6 for flag bit descriptions.




A.10.4 4

Co ounter—16-b bit with flag, delta


Counter

Name: Variation

Group:

20

Variation:

4

Type:

Static


Name:

A.10.4 4.1 De escription Objectt group 20, varriation 4 is used d to report the current value oof a delta counnter point. Variattion 4 objects contain c a 16-bitt, unsigned inteeger count valuue. A.10.4 4.2

Co oding

A.10.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes

Delta counters are obsolete. New w designs shoulld not implemeent or specify tthis variation. A description is nted here for reeference only. presen See 11 1.6 for flag bit descriptions.




A.10.5

Co ounter—32-b bit without fla ag Group:

20

Variation:

5

Counter

Type:

Static

32-bit without flag

Parsing Codes:

Table 12-10



Co oding

A.10.5.2.1

Pictorial

A.10.5.2.2 ormal structu ure Fo UINT32: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +4 294 967 295. A.10.5.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 1, 32-b bit Counter with th Flags, shall bbe used for poiints that have aan abnorm mal condition that t can be reported with flag g bits.




A.10.6

Co ounter—16-b bit without fla ag Group:

20

Variation:

6

Counter

Type:

Static

16-bit without flag

Parsing Codes:

Table 12-10



Co oding

A.10.6.2.1

Pictorial

A.10.6.2.2 Fo ormal structu ure UINT16: Value. V Th his is the most recently r obtain ned or computeed value. Raange is 0 to +65 5 535. A.10.6.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 2, 16-b bit Counter with th Flags, shall bbe used for poiints that have aan abnorm mal condition that t can be reported with flag g bits.




A.10.7

Co ounter—32-b bit without fla ag, delta


Counter

Group:

20

Variation:

7

Type:

Static

32-bit without flag, delta

A.10.7.1 De escription Objectt group 20, varriation 7 is used d to report the current value oof a delta counnter point. Variattion 7 objects contain c a 32-bitt, unsigned inteeger count valuue. A.10.7.2

Co oding

A.10.7.2.1

Pictorial


No otes





A.10.8

Co ounter—16-b bit without fla ag, delta


Counter

Group:

20

Variation:

8

Type:

Static


A.10.8.1 De escription Objectt group 20, varriation 8 is used d to report the current value oof a delta Counnter point. Variattion 8 objects contain c a 16-bitt, unsigned inteeger count valuue. A.10.8.2

Co oding

A.10.8.2.1

Pictorial

A.10.8.2.2 Fo ormal structu ure UINT16: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +65 5 535. A.10.8.2.3

No otes





A.11

Ob bject group p 21: frozen counters

A.11.1

Frrozen counte er—32-bit witth flag Group:

21

Variation:

1

Frozen Counter C

Type:

Static

32-bit with flag

Parsing Codes:

Table 12-11


A.11.1.1 De escription Objectt group 21, varriation 1 is useed to report thee value of a coounter point caaptured at the iinstant when thhe count is frozen. See 11.9.5 for a deescription of a Counter C Point Type. Variattion 1 objects contain c a 32-bitt, unsigned inteeger count valuue. A.11.1.2

Co oding

A.11.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:



No otes




A.11.2 2

Frrozen counte er—16-bit witth flag Group:

21

Variation:

2

Frozen Counter C

Type:

Static

16-bit with flag

Parsing Codes:

Table 12-11


A.11.2 2.1 De escription Objectt group 21, varriation 2 is useed to report thee value of a coounter point caaptured at the iinstant when thhe count is frozen. See 11.9.5 for a deescription of a Counter C Point Type. Variattion 2 objects contain c a 16-bitt, unsigned inteeger count valuue. A.11.2 2.2

Co oding

A.11.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:



No otes





A.11.3

Frrozen counte er—32-bit witth flag, delta


Frozen Counter C

Name: Variation

Group:

21

Variation:

3

Type:

Static


Name:

A.11.3.1 De escription Objectt group 21, varriation 3 is useed to report the value of a dellta counter poinnt captured at tthe instant wheen the cou unt is frozen. Variattion 3 objects contain c a 32-bitt, unsigned inteeger count valuue. A.11.3.2

Co oding

A.11.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.11.4 4

Frrozen counte er—16-bit witth flag, delta


Frozen Counter C

Name: Variation

Group:

21

Variation:

4

Type:

Static


Name:

A.11.4 4.1 De escription Objectt group 21, varriation 4 is useed to report the value of a dellta counter poinnt captured at tthe instant wheen the cou unt is frozen. Variattion 4 objects contain c a 16-bitt, unsigned inteeger count valuue. A.11.4 4.2

Co oding

A.11.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.11.5

Frrozen counte er—32-bit witth flag and tiime Group:

21

Variation:

5

Frozen Counter C

Type:

Static

32-bit with flag and time

Parsing Codes:

Table 12-11



Co oding

A.11.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:


UINT32: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +4 294 967 295.




DNP3TIME: Time-of-occurrence. Time when the event occurred. A.11.5.2.3

Notes

See 11.6 for flag bit descriptions. Master devices shall ignore the ROLLOVER flag.




A.11.6

Frrozen counte er—16-bit witth flag and tiime Group:

21

Variation:

6

Frozen Counter C

Type:

Static


Parsing Codes:

Table 12-11



Co oding

A.11.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:


UINT16: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +65 5 535. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. 531 Copyright © 2012 IEEE. All rightts reserved.



A.11.6.2.3

Notes





A.11.7

Frrozen counte er—32-bit witth flag and tiime, delta


Frozen Counter C

Name: Variation

Group:

21

Variation:

7

Type:

Static

32-bit with flag and time, delta d

Name:


Co oding

A.11.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:







Notes

Delta counters are obsolete. New designs should not implement or specify this variation. A description is presented here for reference only. See 11.6 for flag bit descriptions.




A.11.8

Frrozen counte er—16-bit witth flag and tiime, delta


Frozen Counter C

Name: Variation

Group:

21

Variation:

8

Type:

Static


Name:


Co oding

A.11.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:





A.11.8.2.3

Notes





A.11.9

Frrozen counte er—32-bit witthout flag Group:

21

Variation:

9

Frozen Counter C

Type:

Static

32-bit without flag

Parsing Codes:

Table 12-11



Co oding

A.11.9.2.1

Pictorial

A.11.9.2.2 Fo ormal structu ure UINT32: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +4 294 967 295. A.11.9.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 1, 32-b bit Frozen Couunter with Flaggs, shall be useed for points thhat have an a abnormal co ondition that caan be reported with w flag bits.




A.11.10

Frrozen counte er—16-bit witthout flag Group:

21

Variation:

10

Frozen Counter C

Type:

Static

16-bit without flag

Parsing Codes:

Table 12-11


A.11.10.1 De escription Objectt group 21, varriation 10 is ussed to report th he value of a coounter point caaptured at the iinstant when thhe count is frozen. See 11.9.5 for a deescription of a Counter C Point Type. Variattion 10 objects contain a 16-b bit, unsigned in nteger count vaalue. A.11.10.2

Co oding

A.11.10.2.1

Pictorial


No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 2, 16-b bit Frozen Couunter with Flaggs, shall be useed for points thhat have an a abnormal co ondition that caan be reported with w flag bits.




A.11.11

Frrozen counte er—32-bit witthout flag, de elta


Frozen Counter C

Group:

21

Variation:

11

Type:

Static


A.11.11.1 De escription Objectt group 21, vaariation 11 is used u to report the value of a delta counterr point captureed at the instannt when the count is fro ozen. Variattion 11 objects contain a 32-b bit, unsigned in nteger count vaalue. A.11.11.2

Co oding

A.11.11.2.1

Pictorial


No otes





A.11.12

Frrozen counte er—16-bit witthout flag, de elta


Frozen Counter C

Group:

21

Variation:

12

Type:

Static


A.11.12.1 De escription Objectt group 21, vaariation 12 is used u to report the value of a delta counterr point captureed at the instannt when the count is fro ozen. Variattion 12 objects contain a 16-b bit, unsigned in nteger count vaalue. A.11.12.2

Co oding

A.11.12.2.1

Pictorial


No otes





A.12

Ob bject group p 22: counte er events

A.12.1

Co ounter eventt—32-bit with h flag Group:

22

Variation:

1

Counter Event E

Type:

Event

32-bit with flag

Parsing Codes:

Table 12-12


A.12.1.1 De escription Objectt group 22, varriation 1 is useed to report thee value of a coounter point aftter the count hhas changed. Seee 11.9.5 5 for a descriptiion of a Counteer Point Type. Variattion 1 objects contain c a 32-bitt, unsigned inteeger count valuue. A.12.1.2

Co oding

A.12.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:



No otes




A.12.2 2

Co ounter eventt—16-bit with h flag Group:

22

Variation:

2

Counter Event E

Type:

Event

16-bit with flag

Parsing Codes:

Table 12-12


A.12.2 2.1 De escription Objectt group 22, varriation 2 is useed to report thee value of a coounter point aftter the count hhas changed. Seee 11.9.5 5 for a descriptiion of a Counteer Point Type. Variattion 2 objects contain c a 16-bitt, unsigned inteeger count valuue. A.12.2 2.2

Co oding

A.12.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:



No otes





A.12.3

Co ounter eventt—32-bit with h flag, delta


Counter Event E

Name: Variation

Group:

22

Variation:

3

Type:

Event


Name:

A.12.3.1 De escription Objectt group 22, varriation 3 is used d to report the value of a deltta counter poinnt after the counnt has changedd. Variattion 3 objects contain c a 32-bitt, unsigned inteeger count valuue. A.12.3.2

Co oding

A.12.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.12.4 4

Co ounter eventt—16-bit with h flag, delta


Counter Event E

Name: Variation

Group:

22

Variation:

4

Type:

Event


Name:

A.12.4 4.1 De escription Objectt group 22, varriation 4 is used d to report the value of a deltta counter poinnt after the counnt has changedd. Variattion 4 objects contain c a 16-bitt, unsigned inteeger count valuue. A.12.4 4.2

Co oding

A.12.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.12.5

Co ounter eventt—32-bit with h flag and tim me Group:

22

Variation:

5

Counter Event E

Type:

Event


Parsing Codes:

Table 12-12



Co oding

A.12.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:







Notes





A.12.6

Co ounter eventt—16-bit with h flag and tim me Group:

22

Variation:

6

Counter Event E

Type:

Event


Parsing Codes:

Table 12-12



Co oding

A.12.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:





A.12.6.2.3

Notes





A.12.7

Co ounter eventt—32-bit with h flag and tim me, delta


Counter Event E

Name: Variation

Group:

22

Variation:

7

Type:

Event


Name:


Co oding

A.12.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:


UINT32: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +4 294 967 295. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. 549 Copyright © 2012 IEEE. All rightts reserved.



A.12.7.2.3

Notes





A.12.8

Co ounter eventt—16-bit with h flag and tim me, delta


Counter Event E

Name: Variation

Group:

22

Variation:

8

Type:

Event


Name:


Co oding

A.12.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:


UINT16: Count C value. Th his is the most recently r obtain ned or computeed value. Raange is 0 to +65 5 535. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred.




A.12.8.2.3

Notes





A.13

Ob bject group p 23: frozen counter ev vents

A.13.1

Frrozen counte er event—32--bit with flag Group:

23

Variation:

1

Frozen Counter C Event

Type:

Event

32-bit with flag

Parsing Codes:

Table 12-13


A.13.1.1 De escription Objectt group 23, vaariation 1 is ussed to report, as an event, th the value of a counter point captured at thhe instantt when the cou unt is frozen. Seee 11.9.5 for a description off a Counter Poiint Type. Variattion 1 objects contain c a 32-bitt, unsigned inteeger count valuue. A.13.1.2

Co oding

A.13.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:



No otes




A.13.2 2

Frrozen counte er event—16--bit with flag Group:

23

Variation:

2


Type:

Event

16-bit with flag

Parsing Codes:

Table 12-13


A.13.2 2.1 De escription Objectt group 23, vaariation 2 is ussed to report, as an event, th the value of a counter point captured at thhe instantt when the cou unt is frozen. Seee 11.9.5 for a description off a Counter Poiint Type. Variattion 2 objects contain c a 16-bitt, unsigned inteeger count valuue. A.13.2 2.2

Co oding

A.13.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.13.3

Frrozen counte er event—32--bit with flag , delta



Name: Variation

Group:

23

Variation:

3

Type:

Event


Name:

A.13.3.1 De escription Objectt group 23, varriation 3 is used d to report, as an a event, the vvalue of a deltaa counter point captured at thee instantt when the cou unt is frozen. Variattion 3 objects contain c a 32-bitt, unsigned inteeger count valuue. A.13.3.2

Co oding

A.13.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.13.4 4

Frrozen counte er event—16--bit with flag , delta



Name: Variation

Group:

23

Variation:

4

Type:

Event


Name:

A.13.4 4.1 De escription Objectt group 23, varriation 4 is useed to report, as an event, the vvalue of a deltaa counter poinnt captured at thhe instantt when the cou unt is frozen. Variattion 4 objects contain c a 16-bitt, unsigned inteeger count valuue. A.13.4 4.2

Co oding

A.13.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:



No otes





A.13.5

Frrozen counte er event—32--bit with flag and time Group:

23

Variation:

5


Type:

Event


Parsing Codes:

Table 12-13


A.13.5.1 De escription Objectt group 23, vaariation 5 is ussed to report, as an event, th the value of a counter point captured at thhe instantt when the cou unt is frozen. Seee 11.9.5 for a description off a Counter Poiint Type. Variattion 5 objects contain c a 32-bitt, unsigned inteeger count valuue. A.13.5.2

Co oding

A.13.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:







Notes





A.13.6

Frrozen counte er event—16--bit with flag and time Group:

23

Variation:

6


Type:

Event


Parsing Codes:

Table 12-13


A.13.6.1

De escription

Objectt group 23, vaariation 6 is ussed to report, as an event, th the value of a counter point captured at thhe instantt when the cou unt is frozen. Seee 11.9.5 for a description off a Counter Poiint Type. Variattion 6 objects contain c a 16-bitt, unsigned inteeger count valuue. A.13.6.2

Co oding

A.13.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:

DISCONTIN NUITY

Bitt 7:





A.13.6.2.3

Notes





A.13.7

Frrozen counte er event—32--bit with flag and time, de elta



Name: Variation

Group:

23

Variation:

7

Type:

Event


Name:

A.13.7.1 De escription Objectt group 23, varriation 7 is useed to report, as an event, the vvalue of a deltaa counter poinnt captured at thhe instantt when the cou unt is frozen. Variattion 7 objects contain c a 32-bitt, unsigned inteeger count valuue. A.13.7.2

Co oding

A.13.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:







Notes





A.13.8

Frrozen counte er event—16--bit with flag and time, de elta



Name: Variation

Group:

23

Variation:

8

Type:

Static


Name:

A.13.8.1 De escription Objectt group 23, varriation 8 is useed to report, as an event, the vvalue of a deltaa counter poinnt captured at thhe instantt when the cou unt is frozen. Variattion 8 objects contain c a 16-bitt, unsigned inteeger count valuue. A.13.8.2

Co oding

A.13.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

ROLLOVER R

Bitt 6:


Bitt 7:





A.13.8.2.3

Notes





A.14

Ob bject group p 30: analog g inputs

A.14.1

An nalog input— —32-bit with flag f Group:

30

Variation:

1

Analog In nput

Type:

Static

32-bit with flag

Parsing Codes:

Table 12-14


A.14.1.1 De escription Objectt group 30, vaariation 1 is used to report th he current valuue of an analogg input point. See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 1 objects contain c a flag octet o and a 32-b bit, signed inteeger value. A.14.1.2

Co oding

A.14.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –2 147 483 648 to +2 147 483 647. A.14.1.2.3

No otes





A.14.2 2

An nalog input— —16-bit with flag f Group:

30

Variation:

2

Analog In nput

Type:

Static

16-bit with flag

Parsing Codes:

Table 12-14


A.14.2 2.1 De escription Objectt group 30, vaariation 2 is used to report th he current valuue of an analogg input point. See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 2 objects contain c a flag octet o and a 16-b bit, signed inteeger value. A.14.2 2.2

Co oding

A.14.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –32 768 8 to +32 767. A.14.2 2.2.3

No otes





A.14.3

An nalog input— —32-bit witho out flag Group:

30

Variation:

3

Analog In nput

Type:

Static

32-bit without flag

Parsing Codes:

Table 12-14


A.14.3.1 De escription Objectt group 30, vaariation 3 is used to report th he current valuue of an analogg input point. See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 3 objects contain c a 32-bitt, signed integeer value. A.14.3.2

Co oding

A.14.3.2.1

Pictorial

A.14.3.2.2 Fo ormal structu ure INT32: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –2 147 483 648 to +2 147 483 647. A.14.3.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. Variation V 1, 32--bit Analog Inpput with Flagss, shall be usedd for points thhat have an a abnormal co ondition that caan be reported with w flag bits.




A.14.4 4

An nalog input— —16-bit witho out flag Group:

30

Variation:

4

Analog In nput

Type:

Static

16-bit without flag

Parsing Codes:

Table 12-14


A.14.4 4.1 De escription Objectt group 30, vaariation 4 is used to report th he current valuue of an analogg input point. See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 4 objects contain c a 16-bitt, signed integeer value. A.14.4 4.2

Co oding

A.14.4 4.2.1

Pictorial

A.14.4 4.2.2 Fo ormal structu ure INT16: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –32 768 8 to +32 767. A.14.4 4.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. Variation V 2, 16--bit Analog Inpput with Flagss, shall be usedd for points thhat have an a abnormal co ondition that caan be reported with w flag bits.




A.14.5

An nalog input— —single-prec cision, floatin ng-point with h flag Group:

30

Variation:

5

Analog In nput

Type:

Static

Single-prrecision, floating-p point with flag

Parsing Codes:

Table 12-14


A.14.5.1 De escription Objectt group 30, vaariation 5 is used to report th he current valuue of an analogg input point. See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 5 objects contain c a flag octet o and a sing gle-precision, ffloating-point vvalue. A.14.5.2

Co oding

A.14.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Vaalue Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038. A.14.5.2.3

No otes

See 11 1.3.5 for a desccription of floating-point form mat. See 11.6 fo for flag bit desccriptions.




A.14.6

An nalog input— —double-prec cision, floati ng-point with flag Group:

30

Variation:

6

Analog In nput

Type:

Static

Double-p precision, floating--point with flag

Parsing Codes:

Table 12-14


A.14.6.1 De escription Objectt group 30, varriation 6 is useed to report the current valuee of an Analogg Input point. See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 6 objects contain c a flag octet o and a dou uble-precision, floating-point value. A.14.6.2

Co oding

A.14.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:



No otes

See 11 1.3.5 for a desccription of floating-point form mat. See 11.6 fo for flag bit desccriptions. 570 Copyright © 2012 IEEE. All rightts reserved.



A.15

Ob bject group p 31: frozen analog inp puts

A.15.1

Frrozen analog g input—32-b bit with flag Group:

31

Variation:

1

Frozen Analog A Input

Type:

Static

32-bit with flag

Parsing Codes:

Table 12-15


A.15.1.1 De escription Objectt group 31, vaariation 1 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 1 objects contain c a flag octet o and a 32-b bit, signed inteeger value. A.15.1.2

Co oding

A.15.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –2 147 483 648 to +2 147 483 647. A.15.1.2.3

No otes





A.15.2 2

Frrozen analog g input—16-b bit with flag Group:

31

Variation:

2


Type:

Static

16-bit with flag

Parsing Codes:

Table 12-15


A.15.2 2.1 De escription Objectt group 31, vaariation 2 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 2 objects contain c a flag octet o and a 16-b bit, signed inteeger value. A.15.2 2.2

Co oding

A.15.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –32 768 8 to +32 767. A.15.2 2.2.3

No otes





A.15.3

Frrozen analog g input—32-b bit with time- of-freeze Group:

31

Variation:

3


Type:

Static

32-bit with w time-of-freeze

Parsing Codes:

Table 12-15


A.15.3.1 De escription Objectt group 31, vaariation 3 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 3 objects contain c a flag octet, o a 32-bit, signed integer value, and a tiime-of-freeze. A.15.3.2

Co oding

A.15.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –2 147 483 648 to +2 147 483 647.




DNP3TIME: Time-of-freeze. Time when the freeze occurred. A.15.3.2.3

Notes

See 11.6 for flag bit descriptions.




A.15.4 4

Frrozen analog g input—16-b bit with time- of-freeze Group:

31

Variation:

4


Type:

Static

16-bit with time-of-freeze

Parsing Codes:

Table 12-15


A.15.4 4.1 De escription Objectt group 31, vaariation 4 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 4 objects contain c a flag octet, o a 16-bit, signed integer value, and a tiime-of-freeze. A.15.4 4.2

Co oding

A.15.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –32 768 8 to +32 767. DNP3TIME: Time-of-occcurrence. Tim me when the frreeze occurred d. 575 Copyright © 2012 IEEE. All rightts reserved.



A.15.4.2.3

Notes





A.15.5

Frrozen analog g input—32-b bit without fla ag Group:

31

Variation:

5


Type:

Static

32-bit without w flag

Parsing Codes:

Table 12-15


A.15.5.1 De escription Objectt group 31, vaariation 5 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 5 objects contain c a 32-bitt, signed integeer value. A.15.5.2

Co oding

A.15.5.2.1

Pictorial

A.15.5.2.2 ormal structu ure Fo INT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –2 147 483 648 to +2 147 483 647. A.15.5.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 1, 32-b bit Frozen Anallog Input with Flags, shall bee used for poinnts that haave an abnormal condition th hat can be reporrted with flag bbits.




A.15.6

Frrozen analog g input—16-b bit without fla ag Group:

31

Variation:

6


Type:

Static

16-bit without flag

Parsing Codes:

Table 12-15


A.15.6.1 De escription Objectt group 31, vaariation 6 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 6 objects contain c a 16-bitt, signed integeer value. A.15.6.2

Co oding

A.15.6.2.1

Pictorial

A.15.6.2.2 Fo ormal structu ure INT16: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –32 768 8 to +32 767. A.15.6.2.3

No otes

This variation v does not n contain flaag-type inform mation. Data retturned in this vvariation is asssumed to be onnline with w no failure indications. i Vaariation 2, 16-b bit Frozen Anallog Input with Flags, shall bee used for poinnts that haave an abnormal condition th hat can be reporrted with flag bbits.




A.15.7

Frrozen analog g input—sing gle-precision n, floating-po oint with flag Group:

31

Variation:

7


Type:

Static


Parsing Codes:

Table 12-15


A.15.7.1 De escription Objectt group 31, vaariation 7 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 7 objects contain c a flag octet o and a sing gle-precision, ffloating-point vvalue. A.15.7.2

Co oding

A.15.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038. A.15.7.2.3

No otes





A.15.8

Frrozen analog g input—doub ble-precision n, floating-po oint with flag g Group:

31

Variation:

8


Type:

Static

Double-precision, floating g-point with flag

Parsing Codes:

Table 12-15


A.15.8.1 De escription Objectt group 31, vaariation 8 is ussed to report th he frozen valuee of an analogg input point. S See 11.9.1 forr a descrip ption of an An nalog Input Poin nt Type. Variattion 8 objects contain c a flag octet o and a dou uble-precision, floating-point value. A.15.8.2

Co oding

A.15.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:



No otes




A.16

Ob bject group p 32: analog g input even nts

A.16.1

An nalog input event—32-bit e t without tim me Group:

32

Variation:

1

Analog Input I Event

Type:

Event

32-bit without w time

Parsing Codes:

Table 12-16


A.16.1.1 De escription Objectt group 32, vaariation 1 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of an An nalog Input Poin nt Type. Variattion 1 objects contain c a flag octet o and a 32-b bit, signed inteeger value. A.16.1.2

Co oding

A.16.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –2 147 483 648 to +2 147 483 647. A.16.1.2.3

No otes





A.16.2 2

An nalog input event—16-bit e t without tim me Group:

32

Variation:

2

Analog Input I Event

Type:

Event


Parsing Codes:

Table 12-16


A.16.2 2.1 De escription Objectt group 32, vaariation 2 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of an An nalog Input Poin nt Type. Variattion 2 objects contain c a flag octet o and a 16-b bit, signed inteeger value. A.16.2 2.2

Co oding

A.16.2 2.2.1

Pictorial

A.16.2 2.2.2 Fo ormal structu ure BSTR8: Flaag Octet Bitt 0:

ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Vaalue Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –32 768 8 to +32 767. A.16.2 2.2.3

No otes





A.16.3

An nalog input event—32-bit e t with time Group:

32

Variation:

3

Analog In nput Event

Type:

Event

32-bit with time

Parsing Codes:

Table 12-16


A.16.3.1 De escription Objectt group 32, vaariation 3 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of an An nalog Input Poin nt Type. Variattion 3 objects contain c a flag octet, o a 32-bit, signed integer value, and a tiime-of-occurreence. A.16.3.2

Co oding

A.16.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –2 147 483 648 to +2 147 483 647.





Notes





A.16.4 4

An nalog input event—16-bit e t with time Group:

32

Variation:

4


Type:

Event

16-bit with time

Parsing Codes:

Table 12-16


A.16.4 4.1 De escription Objectt group 32, vaariation 4 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of an An nalog Input Poin nt Type. Variattion 4 objects contain c a flag octet, o a 16-bit, signed integer value, and a tiime-of-occurreence. A.16.4 4.2

Co oding

A.16.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Value Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is –32 768 8 to +32 767. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. 585 Copyright © 2012 IEEE. All rightts reserved.



A.16.4.2.3

Notes





A.16.5

An nalog input event—single e e-precision, floating-poin nt without tim me Group:

32

Variation:

5


Type:

Event

Single-prrecision, floating-p point without time

Parsing Codes:

Table 12-16


A.16.5.1 De escription Objectt group 32, vaariation 5 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of an An nalog Input Poin nt Type. Variattion 5 objects contain c a flag octet o and a sing gle-precision, ffloating-point vvalue. A.16.5.2

Co oding

A.16.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:



No otes





A.16.6

An nalog input event—doub e le-precision,, floating-point without time Group:

32

Variation:

6


Type:

Event

Double-p precision, floating--point without timee

Parsing Codes:

Table 12-16


A.16.6.1 De escription Objectt group 32, varriation 6 is useed to report chaange events rellated to an anaalog input poinnt. See 11.9.1 fo for a desccription of an Analog A Input Po oint Type. Variattion 6 objects contain c a flag octet o and a dou uble-precision, floating-point value. A.16.6.2

Co oding

A.16.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:



No otes




A.16.7

An nalog input event—single e e-precision, floating-poin nt with time Group:

32

Variation:

7


Type:

Event

Single-prrecision, floating-p point with time

Parsing Codes:

Table 12-16


A.16.7.1 De escription Objectt group 32, vaariation 7 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of a Analog Input Pointt Type. Variattion 7 objects contain c a flag octet, o a single-p precision, floatting-point valuue, and a time-oof-occurrence. A.16.7.2

Co oding

A.16.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Vaalue Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038.





Notes

See 11.3.5 for a description of floating-point format. See 11.6 for flag bit descriptions.




A.16.8

An nalog input event—doub e le-precision,, floating-point with time e Group:

32

Variation:

8


Type:

Event

Double-p precision, floating--point with time

Parsing Codes:

Table 12-16


A.16.8.1 De escription Objectt group 32, vaariation 8 is used to report events related to an analog input point. S See 11.9.1 for a descrip ption of an An nalog Input Poin nt Type. Variattion 8 objects contain c a flag octet, o a double--precision, floaating-point valuue, and a time--of-occurrence. A.16.8.2

Co oding

A.16.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:





FLT32: Value This is the most recently measured, obtained, or computed value. Range is approximately –1.7 × 10308 to +1.7 × 10308. DNP3TIME: Time-of-occurrence. Time when the event occurred. A.16.8.2.3

Notes





A.17

Ob bject group p 33: frozen analog inp put events

A.17.1

Frrozen analog g input event— —32-bit with hout time Group:

33

Variation:

1

Frozen Analog A Input Even nt

Type:

Event


Parsing Codes:

Table 12-17


A.17.1.1 De escription Objectt group 33, varriation 1 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 1 objects contain c a flag octet o and a 32-b bit, signed inteeger value. A.17.1.2

Co oding

A.17.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –2 147 483 648 to +2 147 483 647. A.17.1.2.3

No otes





A.17.2 2

Frrozen analog g input event— —16-bit with hout time Group:

33

Variation:

2

Frozen Analog A Input Eventt

Type:

Event

16-bit without time

Parsing Codes:

Table 12-17


A.17.2 2.1 De escription Objectt group 33, varriation 2 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 2 objects contain c a flag octet o and a 16-b bit, signed inteeger value. A.17.2 2.2

Co oding

A.17.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –32 768 8 to +32 767. A.17.2 2.2.3

No otes





A.17.3

Frrozen analog g input event— —32-bit with h time Group:

33

Variation:

3


Type:

Event

32-bit with time

Parsing Codes:

Table 12-17


A.17.3.1 De escription Objectt group 33, varriation 3 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 3 objects contain c a flag octet, o a 32-bit, signed integer value, and a tiime-of-freeze. A.17.3.2

Co oding

A.17.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –2 147 483 648 to +2 147 483 647.





Notes





A.17.4 4

Frrozen analog g input event— —16-bit with h time Group:

33

Variation:

4


Type:

Event

16-bit with time

Parsing Codes:

Table 12-17


A.17.4 4.1 De escription Objectt group 33, varriation 4 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 4 objects contain c a flag octet, o a 16-bit, signed integer value, and a tiime-of-freeze. A.17.4 4.2

Co oding

A.17.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is –32 768 8 to +32 767. DNP3TIME: Time-of-freeeze. Tim me when the frreeze occurred d. 597 Copyright © 2012 IEEE. All rightts reserved.



A.17.4.2.3

Notes





A.17.5 time

Frrozen analog g input event— —single-pre ecision, floatiing-point witthout Group:

33

Variation:

5


Type:

Event

Single-prrecision, floating-p point without time

Parsing Codes:

Table 12-17


A.17.5.1 De escription Objectt group 33, varriation 5 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 5 objects contain c a flag octet o and a sing gle-precision, ffloating-point vvalue. A.17.5.2

Co oding

A.17.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:



No otes





A.17.6 time

Frrozen analog g input event— —double-pre ecision, floatting-point without Group:

33

Variation:

6

Frozen Analog A Input Chang ge Event

Type:

Event

Double-p precision, floating--point without timee

Parsing Codes:

Table 12-17


A.17.6.1 De escription Objectt group 33, varriation 6 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 6 objects contain c a flag octet o and a dou uble-precision, floating-point value. A.17.6.2

Co oding

A.17.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT64: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is approxiimately –1.7 × 10308 to +1.7 × 10308.




A.17.6.2.3

Notes





A.17.7

Frrozen analog g input event— —single-pre ecision, floatiing-point witth time Group:

33

Variation:

7


Type:

Event

Single-prrecision, floating-p point with time

Parsing Codes:

Table 12-17


A.17.7.1 De escription Objectt group 33, varriation 7 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 7 objects contain c a flag octet, o a single-p precision, floatting-point valuue, and a time-oof-freeze. A.17.7.2

Co oding

A.17.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Fro ozen value Th his is the analog g input value at a the time wheen it was last frrozen. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038.





Notes





A.17.8

Frrozen analog g input event— —double-pre ecision, floatting-point with time Group:

33

Variation:

8


Type:

Event

Double-p precision, floating--point with time

Parsing Codes:

Table 12-17


A.17.8.1 De escription Objectt group 33, varriation 8 is useed to report fro ozen value chaange events rellated to an anaalog input poinnt. See 11 1.9.1 for a desccription of an Analog A Input Point Type. Variattion 8 objects contain c a flag octet, o a double--precision, floaating-point valuue, and a time--of-freeze. A.17.8.2

Co oding

A.17.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:





FLT32: Frozen value This is the analog input value at the time when it was last frozen. Range is approximately –1.7 × 10308 to +1.7 × 10308. DNP3TIME: Time-of-occurrence. Time when the freeze occurred. A.17.8.2.3

Notes





A.18

Ob bject group p 34: analog g input repo orting deadb bands

A.18.1

An nalog input reporting r dea adband—16--bit Group:

34

Variation:

1

Analog In nput Reporting Deeadband

Type:

Static

16-bit

Parsing Codes:

Table 12-18


A.18.1.1 De escription Objectt group 34, vaariation 1 is ussed to set and report the deaadband value of an analog iinput point. Seee 11.9.1 for a descriptiion of an Analo og Input Point Type. Variattion 1 objects contain c a 16-bitt, unsigned inteeger value. Analog input reporting deadbands are readable an nd writeable. A deadband of zero permits any ch hange in the an nalog input vaalue to generatte an event, and a deadband oof the fulll range of the variable v preven nts generation of an event. A.18.1.2

Co oding

A.18.1.2.1

Pictorial

A.18.1.2.2 Fo ormal structu ure UINT16: Deadband D valuee. Th his is the deadb band value exprressed as ⎯ Counts if thee fixed deadban nding method is employed. ⎯ Count-secon nds if the integrrating deadbannding method is employed. Raange is 0 to +65 5 535. A.18.1.2.3

No otes

Objectts of this type are not to be reeported in read d requests for C Class 0 data. T They may only be returned inn a respon nse to a read reequest that speccifically asks fo or object groupp 34. An ou utstation devicee should reporrt the value off 65 535 if the deadband vallue is greater tthan or equal to 65 535 5 when a read request r for thiss variation is reeceived. The reesponse to a reead request forr object group 34, variation 0 may include any variation of object grouup 34, in accordance wiith the device’ss capabilities an nd configuratioon.




A.18.2 2

An nalog input reporting r dea adband—32--bit Group:

34

Variation:

2


Type:

Static

32-bit

Parsing Codes:

Table 12-18


A.18.2 2.1 De escription Objectt group 34, vaariation 2 is ussed to set and report the deaadband value of an analog iinput point. Seee 11.9.1 for a descriptiion of an Analo og Input Point Type. Variattion 2 objects contain c a 32-bitt, unsigned inteeger value. Analog input reporting deadbands are readable an nd writeable. A deadband of zero permits any ch hange in the an nalog input vaalue to generatte an event, and a deadband oof the fulll range of the variable v preven nts generation of an event. A.18.2 2.2

Co oding

A.18.2 2.2.1

Pictorial

A.18.2 2.2.2 Fo ormal structu ure UINT32: Deadband D valuee. Th his is the deadb band value exprressed as ⎯ Counts if thee fixed deadban nding method is employed. ⎯ Count-secon nds if the integrrating deadbannding method is employed. Raange is 0 to +4 294 967 295. A.18.2 2.2.3

No otes

Objectts of this type are not to be reeported in read d requests for C Class 0 data. T They may only be returned inn a respon nse to a read reequest that speccifically asks fo or object groupp 34. An ou utstation devicee should report the value of 4 294 967 295 iif the deadbandd value is greatter than or equual to 4 29 94 967 295 wh hen a read request for this varriation is receivved. The reesponse to a reead request forr object group 34, variation 0 may include any variation of object grouup 34, in accordance wiith the device’ss capabilities an nd configuratioon.




A.18.3

An nalog input reporting r dea adband—sin ngle-precisio on, floating-p point Group:

34

Variation:

3


Type:

Static

Single-prrecision, floating-p point

Parsing Codes:

Table 12-18


A.18.3.1 De escription Objectt group 34, vaariation 3 is ussed to set and report the deaadband value of an analog iinput point. Seee 11.9.1 for a descriptiion of an Analo og Input Point Type. Variattion 3 objects contain c a positiive single-precision, floating--point value. Analog input reporting deadbands are readable an nd writeable. A deadband of zero permits any ch hange in the an nalog input vaalue to generatte an event, and a deadband oof the fulll range of the variable v preven nts generation of an event. A.18.3.2

Co oding

A.18.3.2.1

Pictorial

A.18.3.2.2 Fo ormal structu ure FLT32: Deeadband value Th his is the deadb band value exprressed as ⎯ Engineering units if the fix xed deadbandinng method is em mployed. ⎯ Engineering unit-seconds if i the integratinng deadbandingg method is em mployed. Raange is approximately 0 to +3.4 + × 1038. Noote that even tthough floatingg-point numbeers can n have negativ ve values, only positives are ppermitted in thiis variation. A.18.3.2.3

No otes

Objectts of this type are not to be reeported in read d requests for C Class 0 data. T They may only be returned inn a respon nse to a read reequest that speccifically asks fo or object groupp 34. A deadband value of positive infin nity prevents ev vent generatio n. A negative floating-point deadband valuue uivalent to a zero-value z deaadband, as any y absolute vallue change inn the input is larger than thhe is equ deadband. The reesponse to a reead request forr object group 34, variation 0 may include any variation of object grouup 34, in accordance wiith the device’ss capabilities an nd configuratioon.




Note that if the device is capable of reporting variation 3, floating-point, the device shall be configurable to only report data using variations 1 and 2 for masters that do not support floating-point. See 11.3.5 for a description of floating-point format.




A.19

Ob bject group p 40: analog g output sta atus

A.19.1

An nalog outputt status—32--bit with flag Group:

40

Variation:

1

Analog Output O Status

Type:

Static

32-bit with flag

Parsing Codes:

Table 12-19


A.19.1.1 De escription Objectt group 40, variation 1 is used u to reportt the status off an analog ouutput point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Variattion 1 objects contain c a flag octet o and a 32-b bit, signed inteeger value. A.19.1.2

Co oding

A.19.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Value Th his is the analog g value currenttly being outpuut. Raange is –2 147 483 648 to +2 147 483 647. A.19.1.2.3

No otes

See 11 1.6 for flag bit descriptions. A poin nt index in object group 40 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 41, 42, and 43. 610 Copyright © 2012 IEEE. All rightts reserved.



A.19.2 2

An nalog outputt status—16--bit with flag Group:

40

Variation:

2


Type:

Static

16-bit with flag

Parsing Codes:

Table 12-19


A.19.2 2.1 De escription Objectt group 40, variation 2 is used u to reportt the status off an analog ouutput point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Variattion 2 objects contain c a flag octet o and a 16-b bit, signed inteeger value. A.19.2 2.2

Co oding

A.19.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Value Th his is the analog g value currenttly being outpuut. Raange is –32 768 8 to +32 767. A.19.2 2.2.3

No otes

See 11 1.6 for flag bit descriptions. A poin nt index in object group 40 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 41, 42, and 43.




A.19.3

An nalog outputt status—single-precision n, floating-point with flag g Group:

40

Variation:

3


Type:

Static


Parsing Codes:

Table 12-19


A.19.3.1 De escription Objectt group 40, variation 3 is used u to reportt the status off an analog ouutput point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Variattion 3 objects contain c a flag octet o and a sing gle-precision, ffloating-point vvalue. A.19.3.2

Co oding

A.19.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Vaalue Th his is the analog g value currenttly being outpuut. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038. A.19.3.2.3

No otes

See 11 1.3.5 for a desccription of floating-point form mat. See 11.6 fo for flag bit desccriptions. A poin nt index in object group 40 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 41, 42, and 43.




A.19.4 4

An nalog outputt status—dou uble-precisio on, floating-p point with fla ag Group:

40

Variation:

4


Type:

Static

Double-p precision, floating--point with flag

Parsing Codes:

Table 12-19


A.19.4 4.1 De escription Objectt group 40, variation 4 is used u to reportt the status off an analog ouutput point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Variattion 4 objects contain c a flag octet o and a dou uble-precision, floating-point value. A.19.4 4.2

Co oding

A.19.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT64: Vaalue Th his is the analog g value currenttly being outpuut. Raange is approxiimately –1.7 × 10308 to +1.7 × 10308.




A.19.4.2.3

Notes

See 11.3.5 for a description of floating-point format. See 11.6 for flag bit descriptions. A point index in object group 40 corresponds to the same physical or logical point as the identical index in object groups 41, 42, and 43.




A.20

Ob bject group p 41: analog g outputs

A.20.1

An nalog outputt—32-bit Group:

41

Variation:

1

Analog Output O

Type:

Cmnd

32-bit

Parsing Codes:

Table 12-20


A.20.1.1 De escription Objectt group 41, vaariation 1 is ussed to set an analog a value innto an analog output point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Execu uting controls are initiated by sending one o or more request messaages from a m master with aan approp priate Applicattion Layer fun nction code, seelect (3), operaate (4), direct operate (5), oor direct operaate withou ut acknowledg gment (6), alon ng with a g41v1 object for eaach point. This object may noot be used withh a write function f code, 2. Variattion 1 objects contain c a 32-bitt, signed integeer value and a control status ooctet. A.20.1.2

Co oding

A.20.1.2.1

Pictorial

A.20.1.2.2 Fo ormal structu ure INT32: Req quested value Th his is the analo og value that iss requested; it may be scaledd and/or manippulated before a ph hysical or pseud do analog output is set. Raange is –2 147 483 648 to +2 147 483 647. UINT8: Co ontrol status. Th his value is alw ways 0 in a requ uest message. In response messsages, this valu ue represents tthe status of thhe requested coontrol operatioon. f descriptionss of control-rellated status coddes. Seee Table 11-7 for Raange is 0 to 255 5. A.20.1.2.3

No otes





A.20.2 2

An nalog outputt—16-bit Group:

41

Variation:

2

Analog Output O

Type:

Cmnd

16-bit

Parsing Codes:

Table 12-20


A.20.2 2.1 De escription Objectt group 41, vaariation 2 is ussed to set an analog a value innto an analog output point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Execu uting controls are initiated by sending one o or more request messaages from a m master with aan approp priate Applicattion Layer fun nction code, seelect (3), operaate (4), direct operate (5), oor direct operaate withou ut acknowledg gment (6), alon ng with a g41v2 2 object for eaach point. This object may noot be used withh a write function f code, 2. Variattion 2 objects contain c a 16-bitt, signed integeer value and a control status ooctet. A.20.2 2.2

Co oding

A.20.2 2.2.1

Pictorial

A.20.2 2.2.2 Fo ormal structu ure INT16: Req quested value Th his is the analo og value that iss requested; it may be scaledd and/or manippulated before a ph hysical or pseud do analog output is set. Raange is –32 768 8 to +32 767. UINT8: Co ontrol status. Th his value is alw ways 0 in a requ uest message. In response messsages, this valu ue represents tthe status of thhe requested coontrol operatioon. f descriptionss of control-rellated status coddes. Seee Table 11-7 for Raange is 0 to 255 5. A.20.2 2.2.3

No otes





A.20.3

An nalog outputt—single-pre ecision, floatting-point Group:

41

Variation:

3

Analog Output O

Type:

Cmnd

Single-prrecision, floating-p point

Parsing Codes:

Table 12-20


A.20.3.1 De escription Objectt group 41, vaariation 3 is ussed to set an analog a value innto an analog output point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Execu uting controls are initiated by sending one o or more request messaages from a m master with aan approp priate Applicattion Layer fun nction code, seelect (3), operaate (4), direct operate (5), oor direct operaate withou ut acknowledg gment (6), alon ng with a g41v3 3 object for eaach point. This object may noot be used withh a write function f code, 2. Variattion 3 objects contain c a singlee-precision, flo oating-point vaalue and a contrrol status octett. A.20.3.2

Co oding

A.20.3.2.1

Pictorial

A.20.3.2.2 Fo ormal structu ure FLT32: Reequested value Th his is the analo og value that iss requested; it may be scaledd and/or manippulated before a ph hysical or pseud do analog output is set. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038. UINT8: Co ontrol status. Th his value is alw ways 0 in a requ uest message. In response messsages, this valu ue represents tthe status of thhe requested coontrol operatioon. f descriptionss of control-rellated status coddes. Seee Table 11-7 for Raange is 0 to 255 5. A.20.3.2.3

No otes

See 11 1.3.5 for a desccription of the floating-point f format. f A poin nt index in object group 41 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 40, 42, and 43.




A.20.4 4

An nalog outputt—double-precision, floa ating-point Group:

41

Variation:

4

Analog Output O

Type:

Cmnd

Double-p precision, floating--point

Parsing Codes:

Table 12-20


A.20.4 4.1 De escription Objectt group 41, vaariation 4 is ussed to set an analog a value innto an analog output point. S See 11.9.2 for a descrip ption of an An nalog Output Po oint Type. Execu uting controls are initiated by sending one o or more request messaages from a m master with aan approp priate Applicattion Layer fun nction code, seelect (3), operaate (4), direct operate (5), oor direct operaate withou ut acknowledg gment (6), alon ng with a g41v4 4 object for eaach point. This object may noot be used withh a write function f code, 2. Variattion 4 objects contain c a doublle-precision, floating-point vaalue and a conttrol status octeet. A.20.4 4.2

Co oding

A.20.4 4.2.1

Pictorial

A.20.4 4.2.2 Fo ormal structu ure FLT64: Reequested value Th his is the analo og value that iss requested; it may be scaledd and/or manippulated before a ph hysical or pseud do analog output is set. Raange is approxiimately –1.7 × 10308 to +1.7 × 10308. UINT8: Co ontrol status. Th his value is alw ways 0 in a requ uest message. In response messsages, this valu ue represents tthe status of thhe requested coontrol operatioon. f descriptionss of control-rellated status coddes. Seee Table 11-7 for Raange is 0 to 255 5.




A.20.4.2.3

Notes

See 11.3.5 for a description of the floating-point format. A point index in object group 41 corresponds to the same physical or logical point as the identical index in object groups 40, 42, and 43.




A.21

Ob bject group p 42: analog g output eve ents

A.21.1

An nalog outputt event—32-b bit without tim me Group:

42

Variatioon:

1

Analog Output O Event

Type:

Evvent


Parsingg Codes:

Taable 12--21


A.21.1.1 De escription An An nalog Output Event E Object iss an instance of a report for aan outstation’s correspondingg Analog Output Status object (objectt group 40). Seee 11.9.2 for a description oof an Analog O Output Point Tyype. An Analoog ut Event may be b generated for fo a point only y if the outstaation returns ann output statuss object for thhat Outpu point in i response to a static (Classs 0) request. An n event may bbe generated byy an outstationn when it deteccts someth hing of interesst has occurred d. Examples off this include a change in outtput point value or a change in outputt object flags. An analog output o event object o may allso be generatted due to othher applicationndepend dent reasons. For an nalog output points, p changees to the exceeption flags, aand changes oof the output vvalue when thhe underllying point retaains a value, arre reported witth Analog Outpput Event objeects. The analoog output pointt’s value and status at th he time when the t event is gen nerated and quueued are the vvalue and statuss placed into thhe nt object. Analog Output Even This object o shall nott be generated to simply repo ort that a comm mand was received. Object G Group 43 objeccts should d be used for th his purpose. Generration of Analo og Output Eveents is optionaal for an outstaation and mayy occur in one or more of thhe follow wing situations:: ⎯ Output point value changed d—upon a con ntrol from a m master or upsttream device tthat results in a change to the value or status of an output point, the outsstation may geenerate an evennt object for thhat point. For exaample, where multiple m masterrs control the ssame output pooint on an outsstation, a changge event may be generated to one o or more maaster stations too indicate that tthe output channged value. ms other than a control from a master may result in a chaange to the valuue ⎯ External effeccts—mechanism of a point represented by an n output objectt. An event maay be generatedd to indicate too the master thhat the output po oint value has changed. For example, a loocal automatioon sequence m may override thhe value of a point set by a prev vious control from f the masterr. d—where an outstation generrates Analog O Output Events ffor a particularr point, an event ⎯ Flags changed shall be generrated when any y of the flags fo or the output ppoint change. N Note that the Fllags octet relatees to the output point p status and d not to the staatus value of anny related inpuut point(s). Outstaations that impllement this objject: ⎯ Shall be able to t configure whether w output change c events are generated on output poinnts. ⎯ Should suppo ort Application Layer Functio on Code 22 (ASSSIGN_CLASS) fo for Object Grouup 40, Variatioon 0 if the outstaation device sup pports Assign Class C functionss on other objeects. When events are con nfigured for a particular p outpu ut point, the ouutstation: ⎯ May generate an event when n something off interest happeens on the outpput point. ⎯ Shall generatee an event wheen an output po oint’s output vaalue changes siignificantly. ⎯ When flags arre supported fo or the point, sh hall generate aan event when any of the staatus flags for thhe output point change. c 620 Copyright © 2012 IEEE. All rightts reserved.



Variattion 1 objects contain a flag g octet that ind dicates the staatus of the outp tput point and a 32-bit signeed integer value. A.21.1.2

oding Co

A.21.1.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Value Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is –2 147 483 648 to +2 147 483 647. A.21.1.2.3

No otes





A.21.2 2

An nalog outputt event—16-b bit without tim me Group:

42

Variatioon:

2


Type:

Evvent


Parsingg Codes:

Taable 12--21


A.21.2 2.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 2 objects contain c a flag octet o and a 16-b bit signed integger value. A.21.2 2.2

Co oding

A.21.2 2.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Vaalue Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is –32 768 8 to +32 767. A.21.2 2.2.3

No otes





A.21.3

An nalog outputt event—32-b bit with time Group:

42

Variatioon:

3


Type:

Evvent

32-bit with w time

Parsingg Codes:

Taable 12--21


A.21.3.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 3 objects contain c a flag octet, o a 32-bit signed s integer vvalue, and a tim me-of-occurrennce. A.21.3.2

Co oding

A.21.3.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT32: Value Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is –2 147 483 648 to +2 147 483 647. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. 623 Copyright © 2012 IEEE. All rightts reserved.



A.21.3.2.3

Notes





A.21.4 4

An nalog outputt event—16-b bit with time Group:

42

Variatioon:

4


Type:

Evvent

16-bit with w time

Parsingg Codes:

Taable 12--21


A.21.4 4.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 4 objects contain c a flag octet, o a 16-bit signed s integer vvalue, and a tim me-of-occurrennce. A.21.4 4.2

Co oding

A.21.4 4.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


INT16: Value Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is –32 768 8 to +32 767. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred.




A.21.4.2.3

Notes





A.21.5

An nalog outputt event—sing gle-precision n, floating-po oint without ttime Group:

42

Variatioon:

5


Type:

Evvent

Single-p precision, floating--point without timee

Parsingg Codes:

Taable 12--21


A.21.5.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 5 objects contain c a flag octet o and a sing gle-precision flloating-point vvalue. A.21.5.2

Co oding

A.21.5.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Vaalue Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038. A.21.5.2.3

No otes

See 11 1.3.5 for a desccription of the floating-point f format. f A poin nt index in object group 42 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 40, 41, and 43. This object o group’s events e are assigned to a specific event classs using an assiign class messaage with objeccts from object o group 40 0 and the respeective indexes. 627 Copyright © 2012 IEEE. All rightts reserved.



A.21.6

An nalog outputt event—dou uble-precisio n, floating-p point without time Group:

42

Variatioon:

6


Type:

Evvent

Double-precision, floating g-point without tim me

Parsingg Codes:

Taable 12--21


A.21.6.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 6 objects contain c a flag octet o and a dou uble-precision ffloating-point vvalue. A.21.6.2

Co oding

A.21.6.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT64: Vaalue Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is approxiimately –1.7 × 10308 to +1.7 × 10308.




A.21.6.2.3

Notes

See 11.3.5 for a description of the floating-point format. A point index in object group 42 corresponds to the same physical or logical point as the identical index in object groups 40, 41, and 43. This object group’s events are assigned to a specific event class using an assign class message with objects from object group 40 and the respective indexes.




A.21.7

An nalog outputt event—single-precision,, floating-poiint with time e Group:

42

Variatioon:

7


Type:

Evvent

Single-p precision, floating--point with time

Parsingg Codes:

Taable 12--21


A.21.7.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 7 objects contain c a flag octet, o a single-p precision floatiing-point valuee, and a time-oof-occurrence. A.21.7.2

Co oding

A.21.7.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:


FLT32: Vaalue Th his is the most recently r measu ured, obtained, or computed ooutput value. Raange is approxiimately –3.4 × 1038 to +3.4 × 1038. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. 630 Copyright © 2012 IEEE. All rightts reserved.



A.21.7.2.3

Notes





A.21.8

An nalog outputt event—dou uble-precisio n, floating-p point with tim me Group:

42

Variatioon:

8


Type:

Evvent

Double-precision, floating g-point with time

Parsingg Codes:

Taable 12--21


A.21.8.1 De escription See ob bject group 42,, variation 1 forr a description of Analog Ouutput Events annd event detectiion. Variattion 8 objects contain c a flag octet, o a double--precision floatting-point valuue, and a time-oof-occurrence. A.21.8.2

Co oding

A.21.8.2.1

Pictorial


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:

OVER_RAN NGE

Bitt 6:

REFERENCE E_ERR

Bitt 7:





FLT64: Value This is the most recently measured, obtained, or computed output value. Range is approximately –1.7 × 10308 to +1.7 × 10308. DNP3TIME: Time-of-occurrence. Time when the event occurred. A.21.8.2.3

Notes





A.22

Ob bject group p 43: analog g output com mmand eve ents

A.22.1

An nalog outputt command event—32-bit e t without tim me Group:

43

Variatioon:

1

Analog Output O Command Event

Type:

Evvent


Parsingg Codes:

Taable 12--22


A.22.1.1 De escription An An nalog Output Command C Eveent object reports that a comm mand has beenn attempted onn an outstationn’s corresponding Analo og Output poin nt. Examples off usage of this object include: ⎯ Reporting to a master devicee that an outstaation has receivved a control fr from another m master ⎯ Reporting to a master devicee that a successsful or unsucceessful control w was attempted ⎯ Reporting to a master devicee that a controll request was m made from an innternal applicaation ⎯ Reporting to a master device that a contro ol was receivedd and processed at an outstation when issueed through a non n-originating deevice (e.g., Datta Concentratoor) A com mmand event may m be generaated by an outsstation when itt receives a coontrol commannd for an output point from an intern nal or external source. Examp ples of this incclude a commaand request received thoughh a ut Block, a com mmand requesst from a differrent protocol, or a control chhange commannd DNP3 Analog Outpu a executing ap pplication. from an Wheree the analog output o point co ontrolled retain ns an output vvalue, a controol request to tthe output point would d include valuee information. This requested d control valuee is returned inn this analog ooutput commannd event. This object does d not return value or statu us information for the output ut point itself, oor any feedbacck h the control. Output commaand event objeects received bby a master aree intended to bbe input associated with f information nal purposes, su uch as being lo ogged. used for Generration of Analo og Output Com mmand Events is optional foor an outstationn. This object may be used in conjun nction with An nalog Output Change Event objects. Outstaations that impllement this objject: ⎯ Shall be able to t configure whether w output command c evennts are generateed on output pooints. ⎯ Should support Application Layer Functio on Code 22 (ASSSIGN_CLASS) foor object groupp 41, Variationn 0 if the outstatio on device supp ports Assign Cllass functions oon other objectts. ⎯ May generatee events when n controls aree commandedd from internaal sources (e.gg., applicationn), external sourcces requesting controls c (e.g., protocol p controol request), or both. ⎯ Shall not gen nerate this event until a com mmand is fullyy processed. For example w when receiving a Select Before Operate contro ol request, an event e shall not be generated ffollowing recepption of a Seleect command unttil either the Seelect fails or thee Operate is prrocessed. ⎯ Shall not geneerate this even nt as a result off output point vvalue change oor status changge. Object grouup 42 objects aree used for this purpose. Objeect group 43 obbjects are indeependent from object group 442 objects. ⎯ Should provid de the result off processing th he control requuest in the conntrol status fielld of this objecct. Where this staatus can be pro ovided, it shalll be in the sam me format as thhe control statuus field provideed in DNP3 objeect 41, variation n 1.




⎯ Should proviide at least an n indication of o whether thhe processed ccontrol requesst was accepteed (status = 0) orr not accepted for unknown reasons r (statuss = 127). Wherre possible, it iis recommendeed that the outstaation return kn nown, relevantt status codes. Where the prrocessed contrrol was receiveed through a DN NP3 request, fo or example, thee status code rreturned in the output commaand event statuus code should be b the same thee status code ussed in the respoonse to the conntrol request. ⎯ May choose to send output command even nts (1) only whhen the controll actually succceeds (i.e., statuus code = 0), or (2) for any con ntrol command d regardless off whether it succceeds or fails (i.e., status codde >= 0). Variattion 1 objects contain value information regarding r the ccommanded vaalue of the ouutput (where thhe point retains value information) and status in nformation inddicating the sstatus that resuulted when thhe d the requested d control on th he point. Inforrmation providded in this objject relates to a outstattion processed contro ol request, and not to the resultant value or status s of the pooint controlled.. A.22.1.2

Co oding

A.22.1.2.1

Pictorial

A.22.1.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 INT32: Com mmanded Valu ue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is –2 147 483 648 to +2 2 147 483 647.. Where the coommanded vallue is unknow wn, thiis field shall co ontain 0. A.22.1.2.3

No otes





A.22.2 2

An nalog outputt command event—16-bit e t without tim me Group:

43

Variatioon:

2


Type:

Evvent


Parsingg Codes:

Taable 12--22


A.22.2 2.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Commandd Events and evvent detection.. Variattion 2 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, and th he commanded d value. Inform mation provided d in this objecct relates to a ccontrol requestt, and not to thhe resultaant state or stattus of the pointt controlled. A.22.2 2.2

Co oding

A.22.2 2.2.1

Pictorial

A.22.2 2.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 INT16: Co ommanded Vallue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is –32 768 to +32 767. Where the com mmanded valuue is unknownn, this field shaall con ntain 0. A.22.2 2.2.3

No otes





A.22.3

An nalog outputt command event—32-bit e t with time Group:

43

Variatioon:

3


Type:

Evvent

32-bit with w time

Parsingg Codes:

Taable 12--22


A.22.3.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Commandd Events and evvent detection.. Variattion 3 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, the co ommanded valu ue, and a time--of-occurrencee. The time-of--occurrence reppresents the tim me at which thhe contro ol request was processed. Infformation prov vided in this obbject relates too a control reqquest, and not to the ressultant state or status of the point controlled d. A.22.3.2

Co oding

A.22.3.2.1

Pictorial

A.22.3.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 INT32: Com mmanded Valu ue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is –2 147 483 648 to +2 2 147 483 647.. Where the coommanded vallue is unknow wn, thiis field shall co ontain 0. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred.




A.22.3.2.3

Notes





A.22.4 4

An nalog outputt command event—16-bit e t with time Group:

43

Variatioon:

4


Type:

Evvent

16-bit with w time

Parsingg Codes:

Taable 12--22


A.22.4 4.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Commandd Events and evvent detection.. Variattion 4 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, the co ommanded valu ue, and a time--of-occurrencee. The time-of--occurrence reppresents the tim me at which thhe contro ol request was processed. Infformation prov vided in this obbject relates too a control reqquest, and not to the ressultant state or status of the point controlled d. A.22.4 4.2

Co oding

A.22.4 4.2.1

Pictorial

A.22.4 4.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 INT16: Co ommanded Vallue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is –32 768 to +32 767. Where the com mmanded valuue is unknownn, this field shaall con ntain 0. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred.




A.22.4.2.3

Notes





A.22.5 witho out time

An nalog outputt command event—single e e-precision, floating-poin nt Group:

43

Variatioon:

5


Type:

Evvent

Single-p precision, floating--point without timee

Parsingg Codes:

Taable 12--22


A.22.5.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Commandd Events and evvent detection.. Variattion 5 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, and th he single-precission floating-p point command ded value. Infoormation proviided in this obbject relates to a contro ol request, and not to the resultant state or sttatus of the poiint controlled. A.22.5.2

Co oding

A.22.5.2.1

Pictorial

A.22.5.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 FLT32: Co ommanded Vallue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is approx ximately –3.4 × 1038 to +3..4 × 1038. Whhere the comm manded value is un nknown, this fieeld shall contaiin 0. A.22.5.2.3

No otes

See 11 1.3.5 for a desccription of the floating-point f format. f A poin nt index in object group 43 corresponds c to the same physsical or logical point as the iddentical index in objectt groups 40, 41, and 42. This object o group’s events e are assigned to a specific event classs using an assiign class messaage with objeccts from object o group 41 1 and the respeective indexes.




A.22.6 witho out time

An nalog outputt command event—doub e le-precision,, floating-point Group:

43

Variatioon:

6


Type:

Evvent

Double-precision, floating g-point without tim me

Parsingg Codes:

Taable 12--22


A.22.6.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Commandd Events and evvent detection.. Variattion 6 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, and th he double-preciision floating-p point commanded value. Info formation provvided in this obbject relates to a contro ol request and not n to the resultant state or staatus of the poinnt controlled. A.22.6.2

Co oding

A.22.6.2.1

Pictorial

A.22.6.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 FLT64: Co ommanded Vallue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is approx ximately –1.7 × 10308 to +1..7 × 10308. Whhere the comm manded value is un nknown, this fieeld shall contaiin 0.




A.22.6.2.3

Notes

See 11.3.5 for a description of the floating-point format. A point index in object group 43 corresponds to the same physical or logical point as the identical index in object groups 40, 41 and 42. This object group’s events are assigned to a specific event class using an assign class message with objects from object group 41 and the respective indexes.




A.22.7 time

An nalog outputt command event—single e e-precision, floating-poin nt with Group:

43

Variatioon:

7


Type:

Evvent

Single-p precision, floating--point with time

Parsingg Codes:

Taable 12--22


A.22.7.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Commandd Events and evvent detection.. Variattion 7 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, the sin ngle-precision floating-point commanded value, v and the time-of-occurrrence. The tim me-of-occurrencce represents the time at a which the co ontrol request was processedd. Information provided in thhis object relatees ontrol request and a not to the resultant r state or o status of thee point controllled. to a co A.22.7.2

Co oding

A.22.7.2.1

Pictorial

A.22.7.2.2 ormal structu ure Fo UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0 FLT32: Co ommanded Vallue. Th he Commanded d Value representing the coontrol requesteed for the phyysical or logiccal ou utput. Raange is approx ximately –3.4 × 1038 to +3..4 × 1038. Whhere the comm manded value is un nknown, this fieeld shall contaiin 0. DNP3TIME: Time-of-occcurrence. Tim me when the event occurred. 644 Copyright © 2012 IEEE. All rightts reserved.



A.22.7.2.3

Notes





A.22.8 time

An nalog outputt command event—doub e le-precision,, floating-point with Group:

43

Variatioon:

8


Type:

Evvent

Double-precision, floating g-point with time

Parsingg Codes:

Taable 12--22


A.22.8.1 De escription See ob bject group 43,, variation 1 forr a description of Analog Ouutput Change E Events and evennt detection. Variattion 8 objects contain c a status octet that ressulted when thee outstation prrocessed the reequested controol, the do ouble-precision n floating-pointt commanded value, v and the time-of-occurrrence. The tim me-of-occurrencce represents the time at a which the co ontrol request was processedd. Information provided in thhis object relatees ontrol request and a not to the resultant r state or o status of thee point controllled. to a co A.22.8.2

Co oding

A.22.8.2.1

Pictorial

A.22.8.2.2 Fo ormal structu ure UINT7: Staatus Code. Th his value repreesents the statu us from processsing the comm mand that thiss event object is rep porting. See Ta able 11-7 for descriptions d of control-relatedd status codes. BSTR1: Reeserved. Allways 0




FLT64: Commanded Value. The Commanded Value representing the control requested for the physical or logical output. Range is approximately –1.7 × 10308 to +1.7 × 10308. Where the commanded value is unknown, this field shall contain 0. DNP3TIME: Time-of-occurrence. Time when the event occurred. A.22.8.2.3

Notes





A.23

Ob bject group p 50: time an nd date

A.23.1

Tim me and date—absolute time t Group:

50

Variation:

1

Time and d Date

Type:

Info

Absolute time

Parsing Codes:

Table 12-23


A.23.1.1 De escription A Tim me and Date objject with time only is an info ormation type oobject that reprresents the absoolute time. This object o is used to o set or get the current time in n an outstationn. A.23.1.2

Co oding

A.23.1.2.1

Pictorial

ormal structu ure A.23.1.2.2 Fo DNP3TIME: Absolute tim me value. A.23.1.2.3

No otes

Read requests r and reesponses shall use u qualifier co ode 0x07 and a range field vaalue of 1 for thhis object. Wheen an outtstation receivees this request,, it implicitly indicates i that tthe master wannts the outstatiion to return thhe curren nt time. This object o can be in ncluded in a wrrite request. Write W requests shhall use qualifiier code 0x07 aand a range field value of 1 for this object. o When an a outstation reeceives this reequest, it impliicitly indicatess that the mastter wants to set the curreent time in the outstation. An ou utstation with access a to, and using, u an accurate local time ssource may chhoose not to sett its current tim me with th he time in the master m message. Even in this case, the outsttation shall repply as if it had set its local tim me from the t time in the message.




A.23.2 2

Tim me and date—absolute time t and inte erval Group:

50

Variation:

2

Time and d Date

Type:

Info

Absolute time and interval

Parsing Codes:

Table 12-23


A.23.2 2.1 De escription A Tim me and Date objject is an inforrmation object that representss the absolute ttime and a timee interval. This object o is an info ormation objecct that is used to t specify an innitial time andd the time betw ween subsequennt, regulaar actions or acctivities. Functiion code 11 an nd 12 freeze coommands use thhis object to sppecify when annd how often o counters or o other objectss should be fro ozen. A.23.2 2.2

Co oding

A.23.2 2.2.1

Pictorial

A.23.2 2.2.2 Fo ormal structu ure DNP3TIME: Absolute tim me value. Th his is when thee initial action n (freeze in thhe case of funcction code 11 and 12) shouuld commence. UINT32: In nterval time vaalue. Tim me, expressed in millisecond ds, between perriodic actions ((freezes in the case of functioon code 11 and 12) after the initiall occurrence.




A.23.3

Tim me and date—absolute time t at last re ecorded time e Group:

50

Variation:

3

Time and d Date

Type:

Info

Absolute time at last record ded time

Parsing Codes:

Table 12-23


A.23.3.1 De escription A Tim me and Date obj bject with time only is an info ormation type oobject that reprresents the abssolute time wheen the mo ost recently traansmitted Reco ord Current Tim me function codde (24) was sennt. This object o is used in n LAN applicaations to set thee current time iin an outstationn. A.23.3.2

Co oding

A.23.3.2.1

Pictorial

Fo ormal structu ure A.23.3.2.2 DNP3TIME: Absolute tim me value. A.23.3.2.3

No otes

This object o is includ ded in a write request. r The reequest shall usee qualifier codee 0x07 and a rrange field valuue of 1 fo or this object. When W an outstaation receives this request, itt implicitly inddicates that the master wants to set thee current time in i the outstation. The tiime value in th his object is th he absolute tim me when the laast bit of the llast octet in thhe most recenttly transm mitted Record Current C Time function f code (24) was sent When this object iss used, there is an implicitt assumption tthat the propaagation delay in the LAN is nificant. insign An ou utstation with access a to, and using, u an accurate local time ssource may chhoose not to sett its current tim me with th he time in the master m message. Even in this case, the outsttation shall repply as if it had set its local tim me from the t time in the message.




A.23.4 4

Tim me and date—indexed ab bsolute time e and long interval Group:

50

Variation:

4

Time and d Date

Type:

Info

Indexed absolute a time and long interval

Parsing Codes:

Table 12-23


A.23.4 4.1 De escription This object o variation n represents an n absolute timee and a time int nterval. It is useed to specify aan initial time oof an acttion and the tim me between su ubsequent, regu ular repetitionss of the actionns or activities. The interval is expresssed as a countt of a number of o time units. Iff the units are other than millliseconds, the iinterval is baseed on thee clock time of the outstation rather than on always being m measured relattive to the startt time. There may be multip ple instances of o this object variation v availaable at an outsttation, each wiith its own point y be either reaad or written. This object vaariation may bbe index. An instance of this object variation may ded in the response to a Read d of Class 0, but b if it is, thee device shall pprovide a methhod to disable it includ from being b included in the responsse to a Read off Class 0. Simillarly a master that reads or w writes this objeect variatiion shall provid de a method to o disable this beehavior. A.23.4 4.2

Co oding:

A.23.4 4.2.1

Pictorial

A.23.4 4.2.2 Fo ormal structu ure DNP3TIME: Start time. Th his is the time at which the action shall innitially occur. IIf this value iss zero, the Staart Tim me shall be intterpreted as thee time at whichh the outstationn processes the object. UINT32: In nterval count. Th his is the interv val between acctions after thee initial occurrrence. A zero vvalue means thhe acttion is not repeeated; see A.23 3.4.2.3. UINT8: Intterval units. Th his is the units of o the interval between actionns. <0> := = The outstatio on does not rrepeat the actioon, regardless of the Intervval Count. See A.23.4.2.3. A 651 Copyright © 2012 IEEE. All rightts reserved.



<1> := Milliseconds—In this case the interval is always counted relative to the Start Time and is constant regardless of the clock time set at the outstation. See A.23.4.2.3. <2> := Seconds—At the same millisecond within the second that is specified in the Start Time. <3> := Minutes—At the same second and millisecond within the minute that is specified in the Start Time. <4> := Hours—At the same minute, second and millisecond within the hour that is specified in the Start Time. <5> := Days—At the same time of day that is specified in the Start Time. <6> := Weeks—On the same day of the week at the same time of day that is specified in the Start Time. <7> := Months—On the same day of each month at the same time of day that is specified in the Start Time. If the Start Time falls on the 29th or greater day of the month, the outstation shall not perform the action in months that do not have such a day. <8> := Months on Same Day of Week from Start of Month—At the same time of day on the same day of the week after the beginning of the month as the day specified in the Start Time. For instance, if the Start Time specifies the second Tuesday of February and the Interval Count is 2, the next action shall occur on the second Tuesday of April. In the same example, if the Interval Count is set to 12, this is the same as specifying, “Every year on the second Tuesday in February”. If the specified day does not occur in a given month when an action was scheduled to occur, the outstation shall not perform the action that month but shall perform it at the next valid scheduled time. <9> := Months on Same Day of Week from End of Month—The outstation shall interpret this setting as in <8>, but the day of the week shall be measured from the end of the month, e.g.,“the second-last Tuesday in February”. <10> := Seasons—The definition of a season is specific to the outstation. <11..127> := Reserved for future use. <128..255> := Reserved for supplier-specific choices—These may not be interoperable. A.23.4.2.3

Notes

When writing to this object, the following rules apply: a)

If the Interval Units field code is a defined value and the Interval Count field is non-zero, the outstation shall perform the action periodically starting at the time specified in the Start Time and repeat it at the interval described by the Interval Unit code and Interval Count fields. In this case: 1) If the time written to the Start Time is in the past relative to the clock of the receiving outstation, the first action shall occur at the first calculated action time following the write. 2) If the time written to the Start Time is in the future relative to the clock of the receiving outstation, the first action shall occur at the time specified in the Start Time and then periodically thereafter as described in the Interval Unit code and Interval Count field. 652 Copyright © 2012 IEEE. All rights reserved.



b) If the Interval Units field code is <0>, or if the Interval Count field is zero, the outstation shall perform the action only once at the time specified in the Start Time. In this case, if the Start Time is in the past relative to the clock value of the receiving outstation, the outstation shall never perform the action. c)

If the Interval Units field code is a reserved value, the action of the outstation is undefined and may not be interoperable.

d) As described in the definition of the Interval Units field, if a value other than <0> or <1> is used for the Interval Units and a change occurs to the outstation’s clock (such as daylight savings time adjustment, summer time adjustment, or clock synchronization), the outstation shall continue to perform the action based on the clock time. This may cause the actual measured interval between two actions to be longer or shorter than that specified. If the unit <1> Milliseconds is used, however, the actual measured interval between actions shall be constant regardless of clock time. e)

If the outstation implements this object variation, it shall implement all the non-reserved values of Interval Units in order to ensure interoperability between devices.




A.24

Ob bject group p 51: time an nd date com mmon time--of-occurren nces

A.24.1 Tim me and date common tim me-of-occurrrence—abso olute time, synch hronized Group:

51

Variation:

1

Time and d Date Common Time-of-Occurrence

Type:

Info

Absolute time, synchronizeed

Parsing Codes:

Table 12-23


A.24.1.1 De escription A Tim me and Date Common C Timee-of-Occurrencce object is ann information type object thhat provides thhe absolu ute time as a reeference from which other objects o that folllow can use too compute theiir absolute tim me. The reelative time vaalue included with w a subsequent object is aadded to, or subbtracted from, the time in thhis objectt in order to callculate the abso olute time asso ociated with thee subsequent oobject. This object o may only appear in a response wheen the time inn the outstationn is believed tto be accurately synchrronized with a known time reference. r The synchronizatioon can be withh respect to the DNP3 masteer, anotheer DNP3 proceess in the outstaation, or a locaal source—the cchoice is systeem dependent. Use grroup 51, variattion 2 objects when the timee in the outstattion has neverr been set or w when the elapseed time since s the last time update from f the synch hronizing sourrce has exceedded a predetermined, devicespecifi fic limit. A.24.1.2

Co oding

A.24.1.2.1

Pictorial

ormal structu ure A.24.1.2.2 Fo DNP3TIME: Absolute tim me value. A.24.1.2.3

No otes

Time and a Date Comm mon Time-of-O Occurrence is often o abbreviatted to Time annd Date CTO. The primary reason for transmittin ng a Time and d Date Comm mon Time-of-O Occurrence object followed bby b wheen the times asssociated with the data objeccts data objects with rellative time offssets is to save bandwidth osely spaced. are clo An example of an ob bject that depen nds on a Time and Date Com mmon Time-off-Occurrence oobject is a binarry input change c event with w relative tim me, object grou up 2, variation 3.




The following shows how multiple Time and Date CTO objects may be included in a response when there are not enough bits in a data object to hold the relative time with respect to a single Time and Date CTO object. Each data object’s time is relative to the immediately preceding Time and Date CTO. In the figure, the time in DOi+1 is relative to T&D1: T&D0

DO0

DO1

•••

DOi

T&D1

DOi+1

DOi+2

•••




A.24.2 2 Tim me and date common tim me-of-occurrrence—absolute time, unsyn nchronized Group:

51

Variation:

2

Time and d Date Common Time-of-Occurrence

Type:

Info

Absolute time, unsynchron nized

Parsing Codes:

Table 12-23


A.24.2 2.1 De escription A Tim me and Date Common C Timee-of-Occurrencce object is ann information type object thhat provides thhe absolu ute time as a reeference from which other objects o that folllow can use too compute theiir absolute tim me. The reelative time vaalue included with w a subsequent object is aadded to, or subbtracted from, the time in thhis objectt in order to callculate the abso olute time asso ociated with thee subsequent oobject. This object o may only appear in a response r when n the time in thhe outstation hhas never been set or when thhe elapseed time since the last time update from the t synchronizzing source haas exceeded a predetermineed, devicee-specific limitt. Use grroup 51, variattion 1 objects in i a response when w the time in the outstatioon is believed to be accurately synchrronized with a known time reference. r The synchronizatioon can be withh respect to the DNP3 masteer, anotheer DNP3 proceess in the outstaation, or a locaal source—the cchoice is systeem dependent. A.24.2 2.2

Co oding

A.24.2 2.2.1

Pictorial

A.24.2 2.2.2 Fo ormal structu ure DNP3TIME: Absolute tim me value. A.24.2 2.2.3

No otes

Time and a Date Comm mon Time-of-O Occurrence is often o abbreviatted to Time annd Date CTO. The primary reason for transmittin ng a Time and d Date Comm mon Time-of-O Occurrence object followed bby b wheen the times asssociated with the data objeccts data objects with rellative time offssets is to save bandwidth osely spaced. are clo An example of an ob bject that depen nds on a Time and Date Com mmon Time-off-Occurrence oobject is a binarry input change c event with w relative tim me, object grou up 2, variation 3.




The following shows how multiple Time and Date CTO objects may be included in a response when there are not enough bits in a data object to hold the relative time with respect to a single Time and Date CTO object. Each data object’s time is relative to the immediately preceding Time and Date CTO. In the figure, the time in DOi+1 is relative to T&D1: T&D0

DO0

DO1

•••

DOi

T&D1

DOi+1

DOi+2

•••




A.25

Ob bject group p 52: time de elays

A.25.1

Tim me delay—c coarse Group:

52

Variation:

1

Time Dellay

Type:

Info

Coarse

Parsing Codes:

Table 12-23


A.25.1.1 De escription This object o is used to o convey the ellapsed time bettween two absoolute times witth a resolution of 1 second. A.25.1.2

Co oding

A.25.1.2.1

Pictorial

A.25.1.2.2 Fo ormal structu ure UINT16: Delay D seconds. Th his is the elapseed time with a 1-second resollution. Raange is 0 to +65 5 535 seconds. A.25.1.2.3

No otes

Use off the Fine Timee Delay object, group 52, varriation 2 is prefferred for delayy times of less than or equal to 65 secconds.




A.25.2 2

Tim me delay—fiine Group:

52

Variation:

2

Time Dellay

Type:

Info

Fine

Parsing Codes:

Table 12-23


A.25.2 2.1 De escription This object o is used d to convey the elapsed time between two absolutee times with a resolution oof 1 milliisecond. A.25.2 2.2

Co oding

A.25.2 2.2.1

Pictorial

A.25.2 2.2.2 Fo ormal structu ure UINT16: Delay D milliseco onds. Th his is the elapseed time with a 1-millisecond resolution. Raange is 0 to +65 5 535 milliseco onds. A.25.2 2.2.3

No otes

Use th he Coarse Timee Delay object,, group 52, variation 1 for dellay times of grreater than 65 sseconds.




A.26

Ob bject group p 60: class objects o

A.26.1

Class objects— —Class 0 data Group:

60

Variation:

1

Class Objjects

Type:

Info

Class 0 data d

Parsing Codes:

Table 12-24


A.26.1.1

De escription

A Claass 0 Data object is an objeect placeholderr that is transm mitted in a reaad request to specify that thhe outstattion return thee static data off all its points that have beenn assigned to one of the fouur classes (stattic Class 0, events Classs 1, 2, or 3). An ny points that are a not assigneed to one of thee four classes w will be excludeed t response, with w the result that the respo onse to the Claass 0 request m may contain a ssubset of all thhe from the outstattion’s static daata. The outstattion will includ de some or all oof the followinng objects in itss response: Ob bject Grroup

Descriiption

1

Bin nary Input

3

Double-bit Binary Input

10

Bin nary Output Stattus

20 2

Cou unter

21 2

Fro ozen Counter

30

An nalog Input

31

Fro ozen Analog Inpuut

40 4

An nalog Output Stattus

87

Datta Set

101 1

Bin nary-Coded Dec imal Integer

102 1

Un nsigned Integer— —8-bit

110 1

Octtet String

121 1

Seccurity Statistics

There are other restrrictions regardiing the inclusio on of frozen annd non-frozen counter and annalog input daata in the same responsee. See 11.9.1.5 for more detaiils. See 4.1.5.1 for more information on static data. See S 4.1.5.3for m more informatiion on classes. A.26.1.2 Co oding A Classs 0 Data objecct does not carrry any informaation in itself annd, therefore, ddoes not have aan object coding g. A.26.1.2.1

No otes

This object o may only y be used in rea ad requests. The asssociated qualiifier field in th he request shou uld always speccify all objectss (code 0x06) because there is no meeans to identify y specific objeccts without explicitly includinng their object groups in the m message.




A.26.2 2


60

Variation:

2

Class Objjects

Type:

Info

Class 1 data d

Parsing Codes:

Table 12-24


A.26.2 2.1

De escription

A Claass 1 Data object is an objeect placeholderr that is transm mitted in a reaad request to specify that thhe outstattion return som me or all objectts having a Claass 1 event attrribute. When aan outstation reeceives a requeest with th his object, it sh hall return Classs 1 event objeects from its evvent queue, or queues if it haas more than onne queue. The responsee will include none n (null respo onse), some, orr all of the following objects:: Ob bject Grroup

Descriiption

2

Bin nary Input Eventt

4

Double-bit Binary Input Event

11

Bin nary Output Eveent

13

Bin nary Output Com mmand Event

22 2

Cou unter Event

23 2

Fro ozen Counter Evvent

32

An nalog Input Evennt

33

Fro ozen Analog Inpuut Event

42 4

An nalog Output Eveent

43 4

An nalog Output Com mmand Event

70

Filee Transfer

88

Datta Set Event

111 1

Octtet String Event

113 1

Virrtual Terminal E Event

120 1

Au uthentication

122 1

Seccurity Statistics E Event

If the response contaains relative tim me event objeccts, it may alsoo include objecct 51 (Common Time Objectt). S 4.1.5.3for m more informatiion on classes. See 4.1.5.2 for more information on event data. See A.26.2 2.2 Co oding A Classs 1 Data objecct does not carrry any informaation in itself annd, therefore, ddoes not have aan object coding g. A.26.2 2.2.1

No otes

This object o may only y be used in rea ad requests. The asssociated qualiifier field in th he request may y specify all obbjects (code 0xx06), or it mayy specify a couunt of objeects (codes 0x0 07 or 0x08). See 5.1.5.1 regarding g event reportin ng order.




A.26.3


60

Variation:

3

Class Objjects

Type:

Info

Class 2 data d

Parsing Codes:

Table 12-24


A.26.3.1

De escription

A Claass 2 Data object is an objeect placeholderr that is transm mitted in a reaad request to specify that thhe outstattion return som me or all objectts having a Claass 2 event attrribute. When aan outstation reeceives a requeest with th his object, it sh hall return Class 2 event objeects from its evvent queue or queues if it haas more than onne queue. The responsee will include none n (null respo onse), some, orr all of the following objects:: Ob bject Grroup

Descriiption

2


4


11


13


22 2

Cou unter Event

23 2


32


33


42 4


43 4


70

Filee Transfer

88

Datta Set Event

111 1

Octtet String Event

113 1


120 1

Au uthentication

122 1


If the response contaains relative tim me event objeccts, it may alsoo include objecct 51 (Common Time Objectt). S 4.1.5.3for m more informatiion on classes. See 4.1.5.2 for more information on event data. See A.26.3.2 Co oding A Classs 2 Data objecct does not carrry any informaation in itself annd, therefore, ddoes not have aan object coding g. A.26.3.2.1

No otes





A.26.4 4


60

Variation:

4

Class Objjects

Type:

Info

Class 3 data d

Parsing Codes:

Table 12-24


A.26.4 4.1

De escription

A Claass 3 Data object is an objeect placeholderr that is transm mitted in a reaad request to specify that thhe outstattion return som me or all objectts having a Claass 3 event attrribute. When aan outstation reeceives a requeest with th his object, it sh hall return Class 3 event objeects from its evvent queue or queues if it haas more than onne queue. The responsee will include none n (null respo onse), some, orr all of the following objects:: Ob bject Grroup

Descriiption

2


4


11


13


22 2

Cou unter Event

23 2


32


33


42 4


43 4


70

Filee Transfer

88

Datta Set Event

111 1

Octtet String Event

113 1


120 1

Au uthentication

122 1


If the response contaains relative tim me event objeccts, it may alsoo include objecct 51 (Common Time Objectt). S 4.1.5.3for m more informatiion on classes. See 4.1.5.2 for more information on event data. See A.26.4 4.2 Co oding A Classs 3 Data objecct does not carrry any informaation in itself annd, therefore, ddoes not have aan object coding g. A.26.4 4.2.1

No otes





A.27

Ob bject group p 70: file-con ntrol

A.27.1

File-control—ffile identifier— —supersede ed


A.27.1.1

File-Conttrol

Group:

70

Variation:

1

Type:

Info

File identtifier - Superseded d

De escription

This File F Identifier object o (group 70, 7 variation 1)) has been supeerseded. Subcllause 5.3 discuusses appropriaate functio on codes and replacement obj bjects. Brief documentation n of this object appears below for referencce. Readers whho need to knoow more detaiils d consult the orriginal DNP3 documentation d . should A.27.1.2

Co oding

A.27.1.2.1

Pictorial







A.27.1.2.2 Formal structure UINT16: Name size. Number of octets in the File name string element. UINT8: File type code. 0:

8-bit binary

1:

8-bit ASCII

2:

7-bit ASCII

3:

EBCDIC

4:

BCD

5:

5-bit Baudot

6:

6-bit Baudot

UINT8: Attribute code. 0:

Regular or real permanent file.

1:

Temporary file

2:

Directory

3:

FIFO (first-in-first-out) File or pipe

UINT16: Start record. This is the first record associated with certain file function codes. UINT16: End record. This is the last record associated with certain file function codes. UINT32: File size. Total number of octets in the file. DNP3TIME: Time of creation. Time when the file was created or last modified. BSTR16: Permission. Bit 0:

World Execute

Bit 1:

World Write

Bit 2:

World Read

Bit 3:

Group Execute

Bit 4:

Group Write

Bit 5:

Group Read

Bit 6:

Owner Execute

Bit 7:

Owner Write

Bit 8:

Owner Read

Bits 9–15:

Reserved, always 0

UINT32: File ID. Unique identifier for the file.




UINT32: Owner ID. Unique identifier for the file owner. UINT32: Group ID. Unique identifier for the file owner’s group. UINT8: File function code. 0:

Append

1:

Delete

2:

Insert

3:

Write

4:

Erase

5:

Information

6:

Change working directory

7:

Present working directory

8:

Execute

9:

Read

10–254:

Not used.

255:

Response

UINT8: Status code. 0:

Successful

1:

Does not exist

2:

Out of space

3:

Permission denied

4:

Busy

OSTRn: File name string. Name of file where the n in OSTRn is the number of octets specified by the name size element. UINT16: First, second … and last record size. This is the number of octets in the respective data record that immediately follows. OSTRm: First, second … and last record data octets. These are the contents of the record where the m in OSTRm is the number of octets specified by the respective record size element. A.27.1.2.3

Notes

New DNP3 implementations should avoid using this object.




A.27.2 2

File-control—a authenticatio on Group:

70

Variation:

2

File-Conttrol

Type:

Info

Authenticcation

Parsing Codes:

Table 12-25


A.27.2 2.1 De escription An Au uthentication object o is used for a master to o request an aauthorization kkey from an ouutstation for usse with su ubsequent file--control transactions. A.27.2 2.2

Co oding

A.27.2 2.2.1

Pictorial

A.27.2 2.2.2 Fo ormal structu ure UINT16: User U name strin ng offset. Th his is the offsett (number of octets) o from thee beginning off the object to tthe first octet oof thee user name strring in the objeect. UINT16: User U name strin ng size. In a master request, this is the number of octtets in the userr name string aappearing in thhe bject. obj 668 Copyright © 2012 IEEE. All rightts reserved.



Outstations always set this value to 0 in responses to indicate there is no user name string appearing in the returned object. UINT16: Password string offset. This is the offset (number of octets) from the beginning of the object to the first octet of the password string in the object. UINT16: Password string size. In a master request, this is the number of octets in the password string appearing in the object. Outstations always set this value to 0 in responses to indicate there is no password string appearing in the returned object. UINT32: Authentication key. This value shall be 0 in a master request message. Outstation responses return a 32-bit number for use with future file-control transactions. A non-zero value indicates specific permissions have been granted, whereas a 0 value indicates world or guest permissions. OSTRn: User name string. Masters include a non-null-terminated user name string in request messages that indicates the name of the user requesting an authentication key. The n in OSTRn indicates the number of octets in the user name string. For security reasons, outstations do not return a user name—this element contains zero octets in responses. OSTRm: Password string. Masters include a non-null-terminated password string in request messages that indicates the user’s password. The m in OSTRm indicates the number of octets in the password string. For security reasons, outstations do not return a password—this element contains zero octets in responses. A.27.2.2.3

Notes

The authentication key returned is valid for only a single transaction unless otherwise stated in other DNP3 documentation.




A.27.3

File-control—ffile command d Group:

70

Variation:

3

File-Conttrol

Type:

Info

File comm mand

Parsing Codes:

Table 12-25


A.27.3.1 De escription A Filee Command obj bject is used wiith Application n Layer functioon codes 25 andd 27 to initiate open and deleete operattions. A.27.3.2

Co oding

A.27.3.2.1

Pictorial




A.27.3.2.2 Fo ormal structu ure UINT16: File F name string g offset. Th his is the offsett (number of octets) o from thee beginning off the object to tthe first octet oof thee file name striing at the end of o the object. UINT16: File F name string g size. In a master requ uest, this is the number of occtets in the filee name string aappearing in thhe bject. obj Ou utstations alwaays set this valu ue to 0 in respoonses to indicaate there is no uuser name strinng app pearing in the returned object. DNP3TIME: Time of creeation. Tim me when the fiile was created d or last modifiied. 671 Copyright © 2012 IEEE. All rightts reserved.



This field should contain a time value when opening a file for writing (see operational mode below). For other operations and when the time of creation is unknown, this field should contain a 0. BSTR16: Permissions. Bit 0:

World Execute

Bit 1:

World Write

Bit 2:

World Read

Bit 3:

Group Execute

Bit 4:

Group Write

Bit 5:

Group Read

Bit 6:

Owner Execute

Bit 7:

Owner Write

Bit 8:

Owner Read

Bits 9–15:

Reserved, always 0

Permission is determined by the logical ORing of the bits. The relevant action is permitted if the bit is set and inhibited if the bit is clear. (0x1FF indicates no restrictions.) This field should contain a non-zero value when opening a file for writing (see operational mode below). For other operations, this field should contain a 0. UINT32: Authentication key. Masters enter the value returned from an authentication transaction immediately preceding the request that contains this object. A non-zero value indicates specific permissions have been granted, whereas a 0 value indicates world or guest permissions. Enter 0 if the outstation does not support authentication. UINT32: File size. Total number of octets in the file. This field should contain a non-zero value when opening a file for writing or appending (see operational mode below). This provides a means for the outstation to know how much buffer or storage space it may need to allocate for the entire file after the writing is completed. For other operations, this field should contain a 0. A file size of 0xFFFFFFFF indicates that the actual file size is unknown. Outstation devices are not required to accept unknown file sizes and may reject the request. UINT16: Operational mode. This field applies to file open requests and specifies how the outstation should prepare itself for subsequent file control operations. The following table indicates allowable codes for this field. Code

Mode name

0 1

NULL READ

2

WRITE

Description

This code is used for non-open command requests. Specifies that an existing file is to be opened for reading. Specifies that the file is to be opened for writing. If the file already exists, this specifies that the existing file should be over-written and its length shall be truncated to 0 before writing the data octets. 672 Copyright © 2012 IEEE. All rights reserved.



Code

Mode name

3

APPEND

all others

Reserved

Description

Specifies a file shall be opened for writing and that octets are to be appended to the end of that file. If the file does not already exist, it shall be created. Minimum implementations are not obligated to support this mode. These codes are reserved for future use.

UINT16: Maximum block size. This item is used for file open commands. It is used to negotiate the number of file octets transferred in subsequent read or write request messages to an amount that is satisfactory for both the master and the outstation. If the file is opened for reading, this value sets a maximum limit on the number of file data octets that the master shall accept in a single response. The outstation may send no more than this number of octets from the file in each g70v5 object. Outstations may send fewer octets in the response. If the file is opened for writing, this value sets the maximum limit on the number of octets from the file that the master shall send in each g70v5 object. The master may be required to transport fewer octets than this value in subsequent write requests if the outstation’s response indicates a lower number in its maximum block size field—see File Command Status object, g70v4. UINT16: Request ID. This is a master-dependent parameter that the outstation is required to return in the request ID field of its corresponding response. It permits the master to associate a response with a particular request. Typically, the master obtains this value from a single running counter that it maintains for all file-control requests to all outstations. The count is incremented with each new request. This approach is not a DNP3 requirement, and masters are free to choose any scheme, including no scheme, of their choosing. Outstations do not interpret or deduce any meaning from the value in this field. OSTRn: File name string. Masters include a non-null-terminated, file name string in request messages that indicates the name of the file to which the action specified by the Application Layer function code applies. The n in OSTRn indicates the number of octets in the file name string. A.27.3.2.3

Notes

The authentication key is valid for only a single transaction unless otherwise stated in other DNP3 documentation.




A.27.4 4

File-control—ffile command d status Grroup:

70

Vaariation:

4

File-Conttrol

Tyype:

Info/Event

File comm mand status

Paarsing Coodes:

Table 12-25

DNP3 Ob bject Libraary Group Name: Variation Name:

A.27.4 4.1 De escription A Filee Command Staatus object is used u in file-con ntrol responsess and requests, depending onn the Applicatioon Layer function code in the request. A.27.4 4.1.1 Re esponses This object o appears in i all responses to open, closse, delete, and aabort operationns, Applicationn Layer functioon codes 25, 26, 27, and d 30. It is also used for respo onses to get filee information commands, Appplication Layyer on code 28, when w the outstaation needs to report an erroor condition. W When the outsttation sends thhis functio objectt as an event, itt shall request Application A Laayer confirmatiion. A.27.4 4.1.2 Re equests This object o appears in requests associated with closing a file or aborting ann operation, Appplication Layyer functio on codes 26 an nd 30. A.27.4 4.2

Co oding

A.27.4 4.2.1

Pictorial




A.27.4.2.2 Formal structure UINT32: File handle. This parameter provides a unique numeric identifier for an opened file. Its value is assigned by the outstation based on the outstation’s own file management algorithm. The file handle is valid only as long as the file remains opened. The handle is transmitted in future transaction requests from the master that opened the file to identify the same file. An outstation should never specify the same file handle value for more than one master at a time. When this object is included in the response to a request for opening a file, the file handle shall be memorized by the master for future file-control transactions only if the status code indicates success; it has no meaning if the operation is unsuccessful. When this object is used to responses to non-open requests, the file handle specifies which file the outstation acted, or attempted to act, upon. When this object is used for file-control requests, such as close and abort, the file handle specifies which file the outstation should act upon. UINT32: File size. This field only applies to responses returned from an outstation when a master requests to open a file for reading. See File Command object, group 70, variation 3. In this case, the value is the total number of octets in the file. For all other transactions involving a File Command Status object, the file size is set to 0. UINT16: Maximum block size. This item is returned in responses to file open commands. For all other transactions involving a File Command Status object, the file size is set to 0. It is used to negotiate the number of file octets transferred in subsequent read or write messages to an amount that is satisfactory for both the master and the outstation. If the file is to be opened for reading, this value specifies the maximum number of file octets that the outstation shall include in a single response. Outstations may send fewer file octets in the subsequent read response messages. This value shall be less than or equal to the maximum block size value that the master specified in the File Command object, group 70, variation 3, requesting to open the file. If the file is to be opened for writing, this value sets the maximum limit on the number of octets from the file that the outstation can accept in a single write request. The master may send fewer file octets in the subsequent write request messages. When this value is less than the maximum block size value that the master specified in the File Command object, group 70, variation 3, requesting to open the file, then the master shall limit the number of file octets it transmits to this lower value. UINT16: Request ID. When this object is included in a request message, the outstation is required to return in the same value in the request ID field of its corresponding response. It permits the master to associate a response with a particular request. When this object is returned in a response message, this value shall match the request ID value found in the file-control object associated with the request. Outstations do not interpret or deduce any meaning from the value in this field. Additional information is provided in the description of the request ID field in the File Command object, group 70, variation 3.




UINT8: Status code. The status code indicates whether the request was successful, or if not, it gives an appropriate error code to explain what went wrong. See Table 11-8 for descriptions of file-related status codes. Of those, only codes 0 through 9 and 255 apply to a File Command Status object. OSTRn: Optional text. This field provides a means for an outstation to include optional text explanations that supplement a terse status code when an error is detected. DNP3 outstations are encouraged to fill in this field, but they are not required to do so. DNP3 masters shall accept responses with characters in this field; however, they are not obligated to do anything with this information.




A.27.5

File-control—ffile transportt Grroup:

70

Vaariation:

5

File-Conttrol

Tyype:

Info/Event

File transsport

Paarsing Coodes:

Table 12-25


A.27.5.1 De escription A Filee Transport objject is used to transmit octetts from a file bbetween a masster and an outtstation in either directiion. Re A.27.5.1.1 equests A Filee Transport ob bject is used in i file-control requests to reead or write a block of datta from the fille, Appliccation Layer fu unction codes 1 and 2. When n this object ap appears in suchh a request, it iis considered aan Inform mation type ob bject. When th he outstation sends this objeect as an eventt, it shall requuest Applicatioon Layer confirmation. A.27.5.1.2 Re esponses This object o is used in i responses to o requests to reead a block of data from a fille, Applicationn Layer functioon code 1, only if the read operatio on is successfu ul. If the outsttation respondds immediatelyy, this object is dered an Inforrmation type object; o however, if the outsstation returnss the file octeets in a delayeed consid respon nse, the object is considered to t be an Event type object. A.27.5.2

Co oding

A.27.5.2.1

Pictorial

A.27.5.2.2 Fo ormal structu ure UINT32: File F handle. In a request, thiss parameter is the file handlle returned froom the outstation during a fiile pen transaction,, and it specifiees which file thhe outstation shhall act upon. op In a response, thiis parameter in ndicates to whicch file the respponse pertains. 677 Copyright © 2012 IEEE. All rightts reserved.



UINT31: Block number. This field specifies the block number associated with the group of data octets from the file. The block numbers are initialized to zero when a file is opened and incremented by one count after each subsequent transfer of file octets. The first block transferred has a block number of 0. BSTR1: Last. This bit is set in the last block of the file transfer and cleared in all other blocks. OSTRn: File data octets. These are the file’s octets. The most number of octets in any message is dependent on the maximum block size negotiated during the open transaction. A.27.5.2.3

Notes

Blocks do not need to be the same size for each block transferred and can vary from message-to-message. Therefore, no assumptions should be made pertaining to an offset within the file being a fixed multiple of the block number. FileOffset = N * BlockNumber; <- This is wrong! Both the outstation and the master should update the file offset after every each read or write transfer.




A.27.6

File-control—ffile transportt status Grroup:

70

Vaariation:

6

File-Conttrol

Tyype:

Info/Event

File transsport status

Paarsing Coodes:

Table 12-25


A.27.6.1 De escription A Filee Transport object is used to report r the statu us of a file transsport operationn. An ou utstation returns this object in n a response to a read requestt, Application Layer functionn code 1, only if the reaad operation was w not successful. An ou utstation alwayss returns this object a responsse to a write reequest, Applicaation Layer funnction code 2. When the outstation n responds imm mediately, this object is consiidered an Inforrmation type oobject; howeveer, o returrns the object in i a delayed response, the objject is considerred to be an Evvent type objecct. if the outstation When the outstation sends this objeect as an eventt, it shall requesst Application Layer confirm mation. A.27.6.2

Co oding

A.27.6.2.1

Pictorial

A.27.6.2.2 ormal structu ure Fo UINT32: File F handle. Th his parameter in ndicates to whiich file the respponse pertains. UINT31: Block B number. Th his field speciffies the block number n associiated with the group of data octets from thhe filee. BSTR1: Laast. Th his bit is set in the t last block of o the file transsfer and clearedd in all other bblocks. 679 Copyright © 2012 IEEE. All rightts reserved.



UINT8: Status code. The status code indicates whether the request was successful, or if not, it gives an appropriate error code to explain what went wrong. See Table 11-8 for descriptions of file-related status codes. Of those, only codes 0, 6, 8, 16 through 20, and 255 apply to a File Transport Status object. OSTRn: Optional text. This field provides a means for an outstation to include optional text explanations that supplement a terse status code when an error is detected. DNP3 outstations are encouraged to fill in this field, but they are not required to do so. DNP3 masters shall accept responses with characters in this field, however; they are not obligated to do anything with this information.




A.27.7

File-control—ffile descripto or Grroup:

70

Vaariation:

7

File-Conttrol

Tyype:

Info/Event

File descrriptor

Paarsing Coodes:

Table 12-25


A.27.7.1

De escription

A.27.7.1.1 Re equests A Filee Descriptor ob bject is used in n file-control reequests with A Application Layyer function coode 28 to obtaain inform mation about th he file named in the object. When W this objject appears inn a request, it iis considered aan Inform mation type objject. A.27.7.1.2 Re esponses This object o is used in n responses to requests for fille information,, Application L Layer function code 28, only if the op peration to gett the file inforrmation is succcessful. Whenn the outstatioon responds im mmediately, thhis objectt is considered d an Informatio on type object (see the rightt-hand columnn of the headinng at top of thhis page);; however, if th he outstation returns the info ormation in a ddelayed responnse, the object is considered to be an Event type ob bject. When th he outstation sends s this objeect as an evennt, it shall requuest Applicatioon Layer confirmation.




A.27.7.2

Co oding

A.27.7.2.1

Pictorial

A.27.7.2.2 ormal structu ure Fo UINT16: File F name string g offset. Th his is the offsett (number of octets) o from thee beginning off the object to tthe first octet oof thee file name striing at the end of o the object. UINT16: File F name string g size. Th his is the number of octets in the file name sstring appearinng in the objectt. UINT16: File F type. Th his value is set to 0 in requestts. In a response, thiis field specifiees the type of ffile per the following chart. Type

0 1 all others

Descrip ption

File is a directory. File is a simple file th hat is suitable ffor sequential ffile transfer. These codes c are reserrved for future use. 682 Copyright © 2012 IEEE. All rightts reserved.



UINT32: File size. This value is set to 0 in requests. In responses: For file type 0 files, directories, this is the number of entries in the subdirectory, excluding any links to itself or its parent directory. For file type 1 files, this is the total number of octets in the file. A file size of 0xFFFFFFFF indicates that the actual file size is unknown. DNP3TIME: Time of creation. This value is set to 0 in requests. In a response this is the time when the file was created or last modified. BSTR16: Permissions. This value is set to 0 in requests. In responses: Bit 0:

World Execute

Bit 1:

World Write

Bit 2:

World Read

Bit 3:

Group Execute

Bit 4:

Group Write

Bit 5:

Group Read

Bit 6:

Owner Execute

Bit 7:

Owner Write

Bit 8:

Owner Read

Bits 9–15:

Reserved, always 0

Permission is determined by the logical ORing of the bits. The relevant action is permitted if the bit is set and inhibited if the bit is clear. (0x1FF indicates no restrictions.) UINT16: Request ID. When this object is included in a request message, the outstation is required to return the same value in the request ID field of its corresponding response. This permits the master to associate a response with a particular request. When this object is returned in a response message, this value shall match the request ID value found in the File Descriptor object associated with the request. Outstations do not interpret or deduce any meaning from the value in this field. Additional information is provided in the description of the request ID field in the File Command object, group 70, variation 3. OSTRn: File name string. Masters include a non-null-terminated, file name string in request messages that indicates the name of the file about which information is desired. The n in OSTRn indicates the number of octets in the file name string. Outstations include a non-null-terminated, file name string in response messages to indicate the name of the file about which the information applies.




A.27.8

File-control—ffile specifica ation string Group:

70

Variation:

8

File-Conttrol

Type:

Info

File speciification string

Parsing Codes:

Table 12-25


A.27.8.1 De escription This object o is used to o identify a speecific file using g its name and possibly the coomplete path to the file. This is i a variable length object whose w size dep pends on the number of chharacters requiired to uniquely identiffy the file. This object o may onlly be used witth qualifier 0x5B because diifferent files m may use a diffeerent number oof characcters depending g on their locaation, the vend dor’s file system m, and which vendor suppliees the device. If there is i an index num mber associated with a file, it is not referennced in the object headers thaat specify objeect group 70, variation 8. 8 A.27.8.2

Co oding

A.27.8.2.1

Pictorial

o size in the fille specification n string is the nnumber of charracters in the sttring. This valuue The value of would also appear in the prefix p appearin ng before the obbject. A.27.8.2.2 Fo ormal structu ure OSTRn: Fiile specification n string. Fille specification n strings do not n use a nulll-terminator. A All characterss have non-zerro values. Th he left-most character c is trransmitted firrst. For exam mple, if the ffile name were “C Config.bin,” thee “C” characterr would appearr in the octet 0 position. A.27.8.2.3

No otes

DNP3 does not specify whether files named in th his object use shhort file namess, such as My yConfig.bin or fullly qualified filee names that in nclude a path to o the file, such as \RTU\ConfigurattionFiles\Analo og.cfg. 684 Copyright © 2012 IEEE. All rightts reserved.



It is the responsibility of devices using this object to support a length and naming style that is required to uniquely identify the intended file. It is recommended to keep the names as short as possible.




A.28

Ob bject group p 80: interna al indication ns

A.28.1

Intternal indica ations—packe ed format Group:

80

Variation:

1

Internal Indications I

Type:

Static

Packed fo ormat

Parsing Codes:

Table 12-26


A.28.1.1 De escription Objectt group 80, vaariation 1 is ussed to report an nd in some caases set a devicce’s DNP3 Intternal Indicatioon states. Internal indiccations are desscribed in detaail in Clause 4 through Clauuse 6 of this sttandard. Sixteeen s are reported in every y response froom an outstattion. The internal indicationns internaal indication states reported or set by thiis object group p and variation are the same. Point indexes i are useed to specify th he specific inteernal indicationn bit(s) accordiing to the following table. Index

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Bit

IIN N1.0 IIN N1.1 IIN N1.2 IIN N1.3 IIN N1.4 IIN N1.5 IIN N1.6 IIN N1.7 IIN N2.0 IIN N2.1 IIN N2.2 IIN N2.3 IIN N2.4 IIN N2.5 IIN N2.6 IIN N2.7

Name

BROADCAST B CLASS_1_EVE C ENTS CLASS_2_EVE C ENTS CLASS_3_EVE C ENTS NEED_TIME N LOCAL_CONT L TROL DEVICE_TRO D OUBLE DEVICE_REST D TART NO_FUNC_CO N ODE_SUPPOR RT OBJECT_UNK O KNOWN PARAMETER_ P _ERROR EVENT_BUFF E FER_OVERFL LOW ALREADY_EX A XECUTING CONFIG_COR C RRUPT RESERVED_1 R RESERVED_2 R 2

A device may includ de a private set of internal ind dication states bbeyond index 115. A.28.1.2 Co oding This object o is coded d as a bit strin ng. When multtiple indexes aare contained in a single meessage, they aare packed d, as illustrated d in the followiing pictorial. A.28.1.2.1

Pictorial




This figure depicts the bit-packing sequence for a message containing bit indexes 0 through 15. As can be seen, the first bit is in the bit 0 position of the first octet, the second bit is in the bit 1 position of the first octet, etc. Any unused bits in the final octet are returned as 0. A.28.1.2.2 Formal structure BSTRn: Internal Indication States. n in BSTRn represents the number of indexes reported in the bit string. Bit 0 in the bit string corresponds to the lowest point index. Subsequent bits correspond to sequentially increasing point indexes. Bit 0 in the bit string is aligned with bit 0 of the first octet. Unused bits in the last octet are padded with 0. Each bit has a value of 0 or 1, representing the internal indication state.




A.29

Ob bject group p 81: device e storage

A.29.1

De evice storage e—buffer fill status Group:

81

Variation:

1

Device Storage

Type:

Info

Buffer filll status

Parsing Codes:

Table 12-26


A.29.1.1 De escription A Dev vice Storage—B Buffer Fill Status object conv veys what perccentage of interrnal buffer spaace is filled. A.29.1.2

Co oding

A.29.1.2.1

Pictorial

ormal structu ure A.29.1.2.2 Fo UINT7: Filll percentage. Peercentage of alllocated space th hat is currentlyy filled. Range is 0 to 100. BSTR1: Ov verflow state. 0:

Normal.

1:

Overflowed.

UINT8: Grroup. Th he group num mber along wiith the variatiion field speccify which buuffer’s status is ind dicated. UINT8: Vaariation. Th he variation number n along with the grooup field speccify which buuffer’s status is ind dicated. A.29.1.2.3

No otes

for new DNP3 This object o is NOT recommended r 3 implementatiions. Originallyy, this object w was conceived to indicaate how much of o the memory y allocated for queues, bufferrs, and other sttorage facilitiess were currenttly occupiied. However, the application of this objecct is heavily deependent on thhe software arcchitecture of thhe outstattion. Each ven ndor is free to implement i DN NP3 in a manneer that is best ffor his or her organization, annd becausse of this, it is not possible to o provide unifo ormity for massters. Masters w would need to provide custom softwaare for each ven ndor and possiibly each produ uct produced bby the same venndor.




A.30

Ob bject group p 82: Device e Profiles

A.30.1

De evice Profile— —functions and indexes s Group:

82

Variation:

1

Device Profile

Type:

Info

Functions and indexes

Parsing Codes:

Table 12-26


A.30.1.1 De escription This Device D Profile object providees a means for an outstation tto tell the mastter which funcctions it supporrts and what indexes forr each object group. A masster does not request r this objject; instead an n outstation haas the option oof sending it w when the requeest from the t master is no ot recognizablee, un-parsable, or objects refeerenced in the request are nott supported. Thhe Internal Indications octet indicatess the problem in i parsing, andd this object prrovides information so that thhe ors) can determ mine how to adj djust future requuests. masterr (or its operato Upon receipt of thiis object, the master m (or its operators) caan change the polling schem me, poll requeest nality of the ouutstation, or re-configure the ddatabase. messaage(s), limit or expand the asssumed function A Dev vice Profile ob bject has two sections. s The first f specifies w which Applicaation Layer funnction codes aare supporrted by the outtstation. The seecond section specifies whatt range of indexxes is valid for specific objeect groupss.




A.30.1.2

Co oding

A.30.1.2.1

Pictorial

ormal structu ure A.30.1.2.2 Fo BSTR64: Function F codes 0 to 63 supporrted. Eaach bit correspo onds to an App plication Layerr function codee by position. F For example, bbit 1 (second ( bit) aligns with funcction code 1, R READ. Set bitss indicate suppported functionns. Fu unction codes higher h than 63 are a reported byy appending a similar BSTR664 to this objecct; thee bits correspon nd to function codes 64 throuugh 127. UINT16: Count C of object headers that follow. f Th his value speciffies the numberr of object heaaders that follow w. Object Hea aders: N sets of o object headeers, where N is the count speccified previoussly. Eaach object head der consists off the standard D DNP3 group, variation, quallifier, and rangge octets.




Valid qualifier codes are as follows: ⎯ 07 and 08. The range field contains the count of the indexes supported by the outstation—points are assumed to have contiguous index numbers beginning at 0. ⎯ 00 and 01. The range field contains the start and stop indexes. Each object header may use any one of the valid qualifier codes—the headers do not need to use the same qualifiers.




A.31

Ob bject group p 83: data se ets

A.31.1

Da ata set—priv vate registrattion object Group:

83

Variation:

1

Data Set

Type:

Any

Private reegistration object

Parsing Codes:

Table 12-26


A.31.1.1 De escription A Priv vate Registratiion Object (PR RO) object con ntains a uniquuely defined ggrouping of daata. The speciffic group of data is privaate but known to the master and a outstation communicatinng the PRO object. Examp ple uses for PR RO objects are as follows: ⎯ Snapshot of values v associateed with a poweer transformer,, including volltages, currentss, power factorrs, oil temperaturre, ambient tem mperature, and tap setting. ⎯ Harmonic currrents in phasess A, B, and C of o an electrical feeder. ⎯ Periodically recorded r upstreeam pressure, downstream ppressure, tempperature, and oorifice size for a gas pipe. ⎯ Tuning param meters associateed with a Propo ortional-Integraal-Derivative ((PID) loop. A speccific PRO objeect may be repo orted as static or o event data oor as informatioon depending oon the system in which h it is employed d. The applicattion may also determine d wheether the PRO m may be includded with Class 1, 2, or 3 events or with h Class 0 staticc data or wheth her the object sshall be polledd for separatelyy from class daata and whether the objeect may be inclluded in an unssolicited transm mission. Each PRO P object is matched one-tto-one with a Private P Registrration Object D Descriptor (g883v2) object thhat describ bes the structure and format of o the data con ntained within tthe PRO. A.31.1.2

Co oding

A.31.1.2.1

Pictorial




A.31.1.2.2 Formal structure VSTR4: Vendor Code This is a four-octet vendor name field. Vendors should select a unique acronym for their company. UINT16: Object identifier. A number that uniquely identifies the data set. This field is also known as a Private Registration Number or PRN. It is a private number that allows devices to distinguish one data set from another. UINT16: Length. The total number of octets in all of the data objects that follow this field. Data objects: The data objects are specified in the corresponding Private Registration Object Descriptor having the same vendor and Object identifier (PRN). A.31.1.2.3

Notes

The objects in a data set may have indexes for the respective point type they are associated with; however, this is not necessary. There is no means using the data object specifiers in the Private Registration Object Descriptor to correlate an object in a PRO with an index. Applications may optionally choose to include a single time object in the data set to specify the time at which all the other objects were recorded.




A.31.2 2

Da ata set—priv vate registrattion object de escriptor Group:

83

Variation:

2

Data Set

Type:

Info

Private reegistration object descriptor d

Parsing Codes:

Table 12-26


A.31.2 2.1 De escription A Priv vate Registration Object Desscriptor (PROD D) object descrribes the struccture and format of a uniquely defineed grouping of data that is prrivate to the ou utstation. See oobject g83v1 fo for more inform mation about thhe data seets associated with w Private Reegistration Objjects. Each PROD P object is matched one-to-one with a Private Registtration Object ((g83v1) objectt. This object o may be used u for determ mination of how w to parse a Priivate Registrattion Object. A.31.2 2.2

Co oding

A.31.2 2.2.1

Pictorial




A.31.2.2.2 Formal structure VSTR4: Vendor Code This is a four-octet vendor name field. Vendors should select a unique acronym for their company. UINT16: Object identifier. A number that uniquely identifies the data set. This field is also known as a Private Registration Number or PRN. It is private number that allows devices to distinguish one data set from another. UINT16: Count of data object specifiers. The number (N) of data object specifier sets that follow this field. N sets of data object specifiers: Each specifier corresponds to a data set, or group of data having the same point type. A.31.2.2.3 Format of data object specifier UINT16: Object quantity. The number of objects having the object group and variation specified by the following two octets. UINT8: Object group. The object group for objects in this set. UINT8: Object variation. The object variation for objects in this set. A.31.2.2.4

Notes

The objects in a data set may have indexes for the respective point type they are associated with; however, this is not necessary. There is no means using the data object specifiers to correlate an object in a PRO with an index.




A.32

Ob bject group p 85: data se et prototype es

A.32.1

Da ata set prototype—with UUID U Group:

85

Variation:

1

Data Set Prototype

Type:

Info

With UU UID

Parsing Codes:

Table 12-27


A.32.1.1 De escription This object o is used to t transport a list l of descriptor elements thhat define a grooup or subset oof elements thhat exist in i a data set. References R to prototypes p may y appear in a ddata set descripptor as a shorthhand method fo for indicaating that the data d set shall contain c a subseet of elementss described by the lists of deescriptors in thhe prototy ypes. A dataa set descriptorr consists of a sequence s of deescriptor elemeents that includde a length, a deescriptor code,, a data ty ype code, a maaximum data length, and posssibly an ancillar ary value. A.32.1.2

Co oding

A.32.1.2.1

Pictorial

ormal structu ure A.32.1.2.2 Fo SET of n: Descriptor D elem ments (refer to Table 5-6) { UINT8: Leength. Sp pecifies the totaal number of occtets in the desscriptor code, ddata type codee, maximum data len ngth, and ancilllary value field ds. If there is nno ancillary vallue field, the leength is 3. 696 Copyright © 2012 IEEE. All rightts reserved.



UINT8: Descriptor code. Specifies what type of descriptor element this is. UINT8: Data type code. Specifies the type of data in the value field of the corresponding data set element. If there is not a corresponding element in the data set, such as descriptor elements having descriptor codes of ID, UUID, NSPC, and NAME, this field should specify data type code NONE. UINT8: Maximum data length. Specifies the maximum number of octets the value field may contain for the corresponding element in the data set. For example, if the data code were UINT, and the maximum data length were set to 4, then the value shall be represented by a 1-, 2-, 3-, or 4-octet (8-, 16-, 24- or 32-bit) unsigned integer. If the data code were VSTR, and the maximum data length were set to 32, the string length in the data set’s element shall not exceed 32 characters. If there is not a corresponding element in the data set, such as descriptor elements having descriptor codes of ID, UUID, NSPC, and NAME, this field should specify 0. Variant: Ancillary value. (Variant implies dependency on the descriptor element’s data descriptor code and length fields.) Ancillary value that depends on the descriptor code. } A.32.1.2.3

Notes

The first descriptor element shall be an ID element. It contains an identifier for the prototype. This identifier is not related to the identifiers in data sets or data set descriptors. It is used to access individual prototypes using classic DNP3 index numbers. The second descriptor element in a data set prototype shall be a UUID element. It is the UUID associated with the prototype. If any member of an existing prototype, except the ID element, should need to change in any respect, the new prototype shall have a new UUID, including changes to names, namespaces, types, maximum lengths, and so forth. If prototype namespace and name are used, they shall appear in the third and fourth descriptor elements; the third element shall be a NSPC element, and the fourth shall be a NAME. These refer to the namespace and name of the prototype, not to the individual or specific data set with which it is associated. Both NSPC and NAME shall appear or both should not. It is not permissible to have a NSPC without a NAME or a NAME without a NSPC. Each data set descriptor shall fit within a single Application Layer fragment.




A.33

Ob bject group p 86: data se et descripto ors

A.33.1

Da ata set descrriptor—data set contents s Group:

86

Variation:

1

Data Set Descriptor

Type:

Info

Data set contents c

Parsing Codes:

Table 12-27


A.33.1.1 De escription This object o describess the sequence of elements in n a data set andd the data typess of the values in the data set.. A dataa set descriptorr consists of a sequence s of deescriptor elemeents that includde a length, a deescriptor code,, a data ty ype code, a maaximum data length, and posssibly an ancillar ary value. A.33.1.2

Co oding

A.33.1.2.1

Pictorial

ormal structu ure A.33.1.2.2 Fo SET of n: Descriptor D elem ments (refer to Table 5-6) { UINT8: Leength. Sp pecifies the totaal number of occtets in the desscriptor code, ddata type codee, maximum data len ngth, and ancilllary value field ds. If there is nno ancillary vallue field, the leength is 3. UINT8: Deescriptor code. Sp pecifies what ty ype of descripto or element thiss is. 698 Copyright © 2012 IEEE. All rightts reserved.



UINT8: Data type code. Specifies the type of data in the value field of the corresponding data set element. If there is not a corresponding element in the data set, such as descriptor elements having descriptor codes of ID, NAME, and PTYP, this field should specify data type code NONE. UINT8: Maximum data length. Specifies the maximum number of octets the value field may contain for the corresponding element in the data set. For example, if the data code were UINT, and the maximum data length were set to 4, then the value shall be represented by a 1-, 2-, 3-, or 4-octet (8-, 16-, 24-, or 32-bit) unsigned integer. If the data code were VSTR, and the maximum data length were set to 32, the string length in the data set’s element shall not exceed 32 characters. If there is not a corresponding element in the data set, such as descriptor elements having descriptor codes of ID, NAME, and PTYP, this field should specify 0. Variant: Ancillary value. (Variant implies dependency on the descriptor element’s data descriptor code and length fields.) Ancillary value that depends on the descriptor code. } A.33.1.2.3

Notes

Each data set descriptor shall fit within a single Application Layer fragment. For each outstation–master pair of devices, event and static data sets that relate to the same collection40 of data are based on the same data set descriptor and have the same identifier as appears in the data set descriptor.

40

The term “collection” is used in this document as a noun to represent a group or set of data. It was chosen to avoid confusion with other terms that have a specific meaning in DNP3.




A.33.2 2

Da ata set descrriptor—chara acteristics Group:

86

Variation:

2

Data Set Descriptor

Type:

Info

Characterristics

Parsing Codes:

Table 12-27


A.33.2 2.1 De escription This object o conveys the transmissio on attributes off a data set. Thhe attributes inddicate: ⎯ Whether the data d set is readaable and/or wriitable. ⎯ Whether staticc and/or event variations exisst. ⎯ Which devicee, master or outtstation, defineed the data set. A.33.2 2.2

Co oding

A.33.2 2.2.1

Pictorial

octe et transmission order

b7

7 0

6 0

5 0

4 DF

3 2 1 0 EV ST WR RD b0

biit position

C Characteristics

A.33.2 2.2.2 Fo ormal structu ure BSTR4: Ch haracteristics

A.33.2 2.2.3

Bitt 0:

RD—set if daata set is readaable.

Bitt 1:

WR—set if data d set is writaable.

Bitt 2:

ST—set if ou utstation maintaains a static daata set.

Bitt 3:

EV—set if ou utstation generrates a data set event.

Bitt 4:

DF—set if deefined by masteer, and clearedd if defined by outstation.

No otes

The in ndex number associated a with h this object co orresponds to tthe identifier iin a data set deescriptor, objeect group 86, variation 1. 1 This object o may not be returned in response to a read request thhat specifies obbject group 86,, variation 0; thhe requesst should speciffy variation 2.




A.33.3

Da ata set descrriptor—pointt index attrib butes Group:

86

Variation:

3

Data Set Descriptor

Type:

Info

Point ind dex attributes

Parsing Codes:

Table 12-27


A.33.3.1 De escription This object o conveys the point index xes correspond ding to the dataa elements in a data set. A.33.3.2

Co oding

A.33.3.2.1

Pictorial

Fo ormal structu ure A.33.3.2.2 UINT8: Leength. Sp pecifies the num mber of octets in i the data set identifier fieldd. UINTn: Daata set identifieer. Th his is a numbeer that uniqueely identifies tthe point indeex set. This nnumber providees correspondence to t a data set deescriptor and thhe resultant datta sets. SET of n: Point P index eleements. { UINT8: Leength. Sp pecifies the num mber of octets in i the point typpe and point inndex fields.




UINT8: Point type. Specifies the point type with which the index is associated. Point type values are the group number used to convey static data. UINTn: Point index. An index number relative to the point indexes used to convey data values for the specified point type in traditional DNP3 read or write requests. } A.33.3.2.3

Notes

Data set point index attribute objects are transmitted in their entirety. It is not permitted to send portions of the object; the entire object shall fit within a single Application Layer fragment. The order of the point index elements shall match the order appearing in the data set descriptor having the same identifier as that found in the data set identifier field. If a value in the data set is not correlated to a specific point in the classic database, group number 0 is used. This object may not be returned in response to a read request that specifies object group 86, variation 0; the request should specify variation 3.




A.34

Ob bject group p 87: data se ets

A.34.1

Da ata set—pres sent value Group:

87

Variation:

1

Data Set

Type:

Static

Present value v

Parsing Codes:

Table 12-27


A.34.1.1 De escription This object o conveys the present or most recently obtained valuees in a data set.. A.34.1.2

Co oding

A.34.1.2.1

Pictorial

A.34.1.2.2 Fo ormal structu ure UINT8: Leength. Sp pecifies the num mber of octets in i the data set identifier fieldd. UINTn: Daata set identifieer. Th his is a num mber that uniquely identifiies the data set. This nuumber providees correspondence to t a data set deescriptor. 703 Copyright © 2012 IEEE. All rightts reserved.



UINT8: Length. Specifies the number of octets in the evaluation time field. This value is always 6. DNP3TIME: Evaluation time. The evaluation time is the time when a snapshot of all the element values were obtained or computed and buffered for transmission. This time is not adjusted if a repeated response is sent. SET of n: Data elements. { UINT8: Length. Specifies the number of octets in the value field shall not exceed the limit specified in the maximum data length field of the corresponding descriptor element. Variant: Value. (Variant implies dependency on the data type and the element’s length field.) Data element’s value. } A.34.1.2.3

Notes

The first four values—length, data set identifier, length, and evaluation time—are mandatory even though there is not a corresponding descriptor element in the corresponding data set descriptor. All of the element values that follow, in the set of n, are transmitted in the same order as they appear in the corresponding data set descriptor object. Data sets are transmitted in their entirety. It is not permitted to send portions of a data set. Data sets shall fit within a single Application Layer fragment. The evaluation time is an absolute time and has no interrelationship to other DNP3 times that appear in other objects in the same response message. The format of the data that appears in each of the value fields is specified by the data type code in the corresponding data set descriptor element. The data type only specifies the format, integer, floating-point, visible string, etc. The number of octets in the value is specified by the length field and may not exceed the limit specified in the maximum data length field of the corresponding descriptor element.




A.35

Ob bject group p 88: data se et events

A.35.1

Da ata set eventt—snapshot Group:

88

Variation:

1

Data Set Event

Type:

Event

Snapshott

Parsing Codes:

Table 12-27


A.35.1.1 De escription This object o conveys a data set even nt. A.35.1.2

Co oding

A.35.1.2.1

Pictorial

A.35.1.2.2 Fo ormal structu ure UINT8: Leength. Sp pecifies the num mber of octets in i the data set identifier fieldd. UINTn: Daata set identifieer. Th his is a num mber that uniquely identifiies the data set. This nuumber providees correspondence to t a data set deescriptor. 705 Copyright © 2012 IEEE. All rightts reserved.



UINT8: Length. Specifies the number of octets in the time-of-event field. This value is always 6. DNP3TIME: Time-of-event. Time when the event occurred. SET of n: Data elements. { UINT8: Length. Specifies the number of octets in the value field; this shall not exceed the limit specified in the maximum data length field of the corresponding descriptor element. Variant: Value. (Variant implies dependency on the data type and the element’s length field.) Data element’s value. } A.35.1.2.3

Notes

The first four values—length, data set identifier, length, and time of event—are mandatory even though there is not a corresponding descriptor element in the corresponding data set descriptor. All of the element values that follow, in the set of n, are transmitted in the same order as they appear in the corresponding data set descriptor object. Data sets are transmitted in their entirety. It is not permitted to send portions of a data set. Data sets should fit within a single Application Layer fragment. The time-of-event is an absolute time and has no interrelationship to other DNP3 times that appear in other objects in the same response message. For example, consider a response that contains a common-time-ofoccurrence object, group 51, some binary input events objects, and a data set event object. The data set event object should still include the time element, and that time is not affected or influenced by the previous common-time-of-occurrence object. The format of the data that appears in each of the value fields is specified by the data type code in the corresponding data set descriptor element. The data type only specifies the format, integer, floating-point, visible string, etc. The number of octets in the value is specified by the length field and may not exceed the limit specified in the maximum data length field of the corresponding descriptor element.




A.36

Ob bject group p 90: applica ations

A.36.1

Ap pplication—identifier Group:

90

Variation:

1

Applicatiion

Type:

Info

Identifierr

Parsing Codes:

Table 12-28


A.36.1.1 De escription An Ap pplication Iden ntifier object iss used to repreesent an appliccation or operrating system pprocess within a devicee. It is used d in conjuncction with ap pplication-relaated function codes (INT TIALIZE_APPL L, STAR RT_APPL, and STOP_APPL)) to control app plications. A.36.1.2

Co oding

A.36.1.2.1 Pictorial Not ap pplicable. See formal f structurre. A.36.1.2.2 Fo ormal structu ure The fo ormat of this ob bject is privately defined by the t device wheere the applicattion resides. A.36.1.2.3

No otes

Objectt qualifier cod de 0x5B shall be used with this object iff a specific appplication is reeferenced in thhe messaage.




A.37

Ob bject group p 91: status of requeste ed operatio ons

A.37.1

Sttatus of requested operattion—active configuratio on Group:

91

Variation:

1

Status of Requested Operattion

Type:

Info

Activate configuration c

Parsing Codes:

Table 12-28


A.37.1.1 De escription This object providees a sequencee of status elements e that indicate the fitness or suuitability of thhe ate configurattion (Applicatiion Layer funnction code 31) request or thhe corresponding objeccts in an activa guration data reeferenced by ob bjects in the request. config This status results frrom the checkiing performed prior to the ouutstation’s actuually attempting to activate thhe config guration. A.37.1.2

Co oding

A.37.1.2.1

Pictorial

A.37.1.2.2 ormal structu ure Fo UINT32: Time T delay. Th he number of milliseconds m du uring which thee outstation exxpects to be buusy and shall nnot resspond to requests. Th his value may be b 0 if an errorr is detected annd the outstatioon shall not atttempt to activaate thee configuration n. It may also be 0 if the outtstation shall nnot restart and can accept neew req quests immediaately. 708 Copyright © 2012 IEEE. All rightts reserved.



UINT8: Number of status elements. Specifies the total number of status elements in this object. There shall be one status element for each object in the request, and the ordering of the status elements shall correspond to the order in which objects appear in the request. SET of n: Status elements. { UINT8: Length. Specifies the total number of octets in the status code and ancillary text fields. If there is no ancillary text field, the length is 1. UINT8: Status code. Set to 0 if the outstation does not detect any errors in the corresponding request object or in the configuration data referenced by the corresponding request object. Set to 1 if the outstation detects an error in the request object. One example is that the outstation is unable to locate a file referenced by a file specification string, g70v8. Another example is that the outstation does not have a name referenced by an octet string, g110, object. Set to 2 if the outstation detects an error in the configuration data referenced by the corresponding request data. Set to 3 for any other error. Set to 4 if not checked. VSTRn: Ancillary text. Any text that elaborates on the status code. This text may be logged at the master station to assist in diagnosing problems. Examples for status code 1 are “File not found” or “Unknown name.” Examples for status code 2 are “Scale factor exceeds limits.” } A.37.1.2.3

Notes

If the request contains multiple objects, and an error is detected in any one of them, it is permissible to stop the error checking immediately without checking the remaining objects. The status code for the unchecked objects should be reported as 4.




A.38

Ob bject group p 100: floatin ng-point

A.38.1

Flo oating-point— —none—gen neral descrip ption commo on to all varia ations


Floating-Point

Group:

100

Variation:

All

Type:

Static

None—G General Description n Common to All Variations

A.38.1.1 De escription Floatin ng-point objects are obsolete. New applicattions should usse the Analog IInput types, groups 30 througgh 33.




A.39

Ob bject group p 101: binary y-coded de ecimal integ gers

A.39.1

Binary-coded decimal integer—small Group:

101

Variation:

1

Binary-C Coded Decimal Inteeger

Type:

Static

Small

Parsing Codes:

Table 12-29


A.39.1.1 De escription This object o is used d to convey 4-digit, 4 binary--coded decimaal values for which other objects are not approp priate. See 11.9 9.3 for a descriiption of a BCD D Point Type. A.39.1.2

Co oding

A.39.1.2.1

Pictorial

A.39.1.2.2 Fo ormal structu ure BCD4: BCD D value.




A.39.2 2

Binary-coded decimal integer—medium m Group:

101

Variation:

2


Type:

Static

Medium

Parsing Codes:

Table 12-29


A.39.2 2.1 De escription This object o is used d to convey 8-digit, 8 binary--coded decimaal values for which other objects are not approp priate. See 11.9 9.3 for a descriiption of a BCD D Point Type. A.39.2 2.2

Co oding

A.39.2 2.2.1

Pictorial

A.39.2 2.2.2 Fo ormal structu ure BCD8: BCD D value.




A.39.3

Binary-coded decimal integer—large Group:

101

Variation:

3


Type:

Static

Large

Parsing Codes:

Table 12-29


A.39.3.1 De escription This object o is used d to convey 16-digit, binary y-coded decim mal values for which other objects are not approp priate. See 11.9 9.3 for a descriiption of a BCD D Point Type. A.39.3.2

Co oding

A.39.3.2.1

Pictorial

A.39.3.2.2 Fo ormal structu ure BCD16: BC CD value.




A.40

Ob bject group p 102: unsig gned intege rs

A.40.1

Un nsigned integ ger—8-bit Group:

102

Variation:

1

Unsigned d Integer

Type:

Static

8-bit

Parsing Codes:

Table 12-29


A.40.1.1 De escription This object o is used to o convey singlee-octet values for which otheer objects are nnot appropriate. This object o can be used u for readin ng and writing g memory locaations within a device usingg virtual address qualifi fier codes. A.40.1.2

Co oding

A.40.1.2.1

Pictorial

A.40.1.2.2 Fo ormal structu ure UINT8: Occtet value.




A.41

Ob bject group p 110: octet strings

A.41.1

Oc ctet string—n none—generral descriptio on common to all variations Group:

110

Variation:

All

Octet Striing

Type:

Static


Parsing Codes:

Table 12-30


A.41.1.1 De escription This description d app plies to all Octeet String, grou up 110, variatioons. See 11.9.77 for a descripption of an Octtet String Point Type. Octet strings may bee used to repressent any block of 8-bit quantiities. The variation v used with w an Octet String is the length of the string. A respponse may conntain a variatioon smalleer than requesteed if the availaable string leng gth is shorter thhan what was reequested. A.41.1.2

Co oding

A.41.1.2.1

Pictorial

The fo ollowing figuree illustrates an Octet String off n octets (variiation n).

A.41.1.2.2 Fo ormal structu ure OSTRn: Value. V Th his is the most recently r measu ured, obtained, or computed vvalue. Raange is 0 to 255 5 within each octet. o Th he octet string length, denoted as the n in O OSTRn, is the same as the vaariation numbeer, and may not exceeed 255. A.41.1.2.3

No otes

olls. Octet String objects are not includeed in Class 0 po Readin ng and writing g of 8-bit memo ory locations can be implemeented using thiss object togethher with absoluute addresssing qualifierss. Only read, r write, and d response fun nction codes are permitted.




A.42

Ob bject group p 111: octet string even nts

A.42.1 variattions

Oc ctet string ev vent—none— —general des scription com mmon to all Group:

111

Variation:

All

Octet Striing Event

Type:

Event


Parsing Codes:

Table 12-30


A.42.1.1 De escription This description d app plies to all Octeet String Event, group 111, vvariations. Seee 11.9.7 for a ddescription of aan Octet String Point Ty ype. The variation v used with an octet string is the length l of the string. A respponse may conntain a variatioon smalleer than requesteed if the availaable string leng gth is shorter thhan what was reequested. A.42.1.2

Co oding

A.42.1.2.1

Pictorial

The fo ollowing figuree illustrates an Octet String Event E of n octetts (variation n).

A.42.1.2.2 Fo ormal structu ure OSTRn: Value. V Th his is the most recently r measu ured, obtained,, or computed vvalue of the Occtet String at thhe tim me when the ev vent was generaated. Raange is 0 to 255 5 within each octet. o Th he octet string length, l denoted d as the n in O OSTRn, is samee as the variatiion number, annd maay not exceed 255. 2 A.42.1.2.3

No otes

Only reead, response, and a unsolicited response r functio on codes are perm mitted.




A.43

Ob bject group p 112: virtua al terminal o output bloc cks

A.43.1 all va ariations

Virtual termina al output block—none—g general desc cription common to Group:

112

Variation:

All

Virtual Terminal T Output Bllock

Type:

Static


Parsing Codes:

Table 12-30


A.43.1.1 De escription This description d app plies to all Viirtual Terminaal Output Blocck, group 112, variations. S See 11.9.9 for a descrip ption of a Virtu ual Terminal Point P Type. The vaariation used with w a Virtual Terminal T Outpu ut Block is the length of the sstring. A.43.1.2

Co oding

A.43.1.2.1

Pictorial

The fo ollowing figuree illustrates a Virtual V Terminaal Output Blocck object of n ooctets (variationn n).

A.43.1.2.2 Fo ormal structu ure OSTRn: Teerminal data. Eaach octet can haave a value thaat ranges from 0 to 255. Excllusive use of A ASCII characteers is not n required. Th he octet string length, denoted as the n in O OSTRn, is the same as the vaariation numbeer, and may not exceeed 255. Th he content of th he data in the object o is speciffic to the particcular terminal protocol. DNP P3 maasters and outsstations do nott need to know w any of the deetails of the terrminal protocool; DN NP3 does not assign a any sign nificance to anyy of the data occtets in this objject. A.43.1.2.3

No otes

Objectts of this type are a not to be reeturned in a Claass 0 poll. The Device D Profile document d shalll list the point index i number( s) assigned to vvirtual terminaals.




A.44

Ob bject group p 113: virtua al terminal e event data

A.44.1 variattions

Virtual termina al event data a—none—gen neral descrip ption commo on to all Group:

113

Variation:

All

Virtual Terminal T Event Datta

Type:

Event


Parsing Codes:

Table 12-30


A.44.1.1 De escription This description d applies to Virtu ual Terminal Event E Data, ggroup 113, all variations. See 11.9.9 for a descrip ption of a Virtu ual Terminal Point P Type. The vaariation used with w a Virtual Terminal T Eventt Data is the lenngth of the striing. A.44.1.2

Co oding

A.44.1.2.1

Pictorial

The fo ollowing figuree illustrates a Virtual V Terminaal Event Data oobject of n octeets (variation nn).

A.44.1.2.2 Fo ormal structu ure OSTRn: Teerminal data. Eaach octet can haave a value thaat ranges from 0 to 255. Excllusive use of A ASCII characteers is not n required. Th he octet string length, denoted as the n in O OSTRn, is the same as the vaariation numbeer, and may not exceeed 255. Th he content of th he data in the object o is speciffic to the particcular terminal protocol. DNP P3 maasters and outsstations do nott need to know w any of the deetails of the terrminal protocool; DN NP3 does not assign a any sign nificance to anyy of the data occtets in this objject. A.44.1.2.3

No otes

The Device D Profile document d shou uld list the poin nt index numbeer(s) assigned tto virtual termiinals. This object o may be assigned a to Claass 1, 2, or 3.




A.45

Ob bject group p 120: authe entication

A.45.1

Au uthentication n—challenge e Group:

120

Variation:

1

Authenticcation

Type:

Info

Challenge

Parsing Codes:

Table 12-31


A.45.1.1

De escription

This object o is used for fo DNP3 securre authenticatio on as describedd in Clause 7. T This object maay be included in either a request or a response. Wh hen this objecct appears alonne in the requeest or responsee its appearancce utstation) transsmit an Authenntication Replyy object with thhe requires that the otheer station (either master or ou nd on the DNP P3 fragment thhe other station most recenttly MAC Value calculaated based on this object an mitted. transm If the outstation traansmits this ob bject at the en nd of a responnse with the C CON bit set, tthe outstation is m transmitt the applicatio on Confirm usinng Aggressivee Mode authenttication (g120vv3 requessting that the master and g1 120v9). A.45.1.2

Co oding

A.45.1.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0

Challenge e Sequence Number b31 b b0 b15 b

User Num mber

b7 b

b0

MAC Algo orithm

b7 b

b0

Reason fo for Challenge e

Challenge e Data




A.45.1.2.2 Formal structure UINT32: Challenge Sequence Number (CSQ). Devices shall use this value to match Replies with challenges, according to the rules described in Clause 7. UINT16: User Number (USR). The responder shall use this value to identify which set of Session Keys is to be used in this challenge-response sequence. <0> := Unknown. The challenge-response sequence is being initiated by an outstation. Therefore the appropriate USR is not yet known. The master will supply the appropriate USR in the Authentication Reply. <1> := Default. The challenge-response sequence is being initiated by a master on behalf of more than one user, and the set of Session Keys used will therefore be the default set of keys for this master-outstation pair. Refer to Clause 7 for more information. <2…65 535> := Chosen by the master station to be associated with a particular user and corresponding set of Session Keys. UINT8: MAC algorithm (MAL). Using this value, the Challenger shall specify the algorithm that the Responder shall use to calculate the MAC Value, and shall also specify the resulting length of the MAC Value. Refer to 7.6.1.1 and 7.6.2.1 and the references cited there for details of how to calculate these algorithms. <0> := not used. <1> := HMAC SHA-1 truncated to 4 octets (serial). No longer recommended. Used only in IEEE Std 1815-2010. <2> := HMAC SHA-1 truncated to 10 octets (networked). <3> := HMAC SHA-256 truncated to 8 octets (serial). <4> := HMAC SHA-256 truncated to 16 octets (networked). <5> := HMAC SHA-1 truncated to 8 octets (serial). <6> := AES-GMAC (output is 12 octets). <7..127> := reserved for future use. <128..255> := reserved for vendor-specific choices. Not guaranteed to be interoperable. IMPORTANT: Refer to 7.6.1.4.3 regarding the dependency between the use of truncated MAC algorithms and the need for frequent Session Key changes. In any case, the longest practical MAC should be used; the shorter options are only provided to address performance issues on bandwidth-limited systems. UINT8: Reason for Challenge. This value explains the Challenger’s reason for making the challenge. The Responder shall use this value to determine what extra data to include when calculating the MAC Value. <0> := not used. <1> := CRITICAL. Challenging a critical function. The Responder shall include the entire previous ASDU transmitted by the Responder when calculating the MAC Value, as well as any further protocol-specific information. <2..255> := reserved for future use. 720 Copyright © 2012 IEEE. All rights reserved.



UINTn: Pseudo-Random Challenge Data. Devices shall include pseudo-random data in the Challenge message to ensure that the contents of the Challenge message are not predictable. The pseudo-random data shall be generated using the algorithm 3.1 specified in FIPS 186-2. The minimum length of the Challenge Data shall be 4 octets. A.45.1.2.3

Notes

In the DNP3 implementation of IEC/TS 62351-5 authentication, the length of the Challenge Data is not specified within the object, but in the Object Prefix. The Authentication Challenge object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Challenge Data is therefore the size specified in the Object Prefix, minus 8 octets.




A.45.2 2

Au uthentication n—reply Group:

120

Variation:

2

Authenticcation

Type:

Info

Reply

Parsing Codes:

Table 12-31


A.45.2 2.1 De escription This object o is used for fo DNP3 securre authenticatio on as describedd in Clause 7. T This object maay be included in either a request or a response. Thiss shall be the only object to aappear in the reequest or respoonse. It is a reply A Challenge objject (g120v1). to an Authentication A.45.2 2.2

Co oding

A.45.2 2.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0


User Num mber

MAC Valu ue

A.45.2 2.2.2 Fo ormal structu ure UINT32: Challenge C Sequ uence Number (CSQ). ( Th he value transm mitted in this ob bject shall be tthe same valuee transmitted byy the Challenger in the Authenticaation Challengee object. UINT16: User U Number (U USR). Th he sender shalll use this valu ue to identify which set of Session Keys the Challenger sho ould use to autthenticate this Reply. R If the seender is the ouutstation, this vvalue shall be thhe sam me as the US SR value tran nsmitted by thhe master in the previous Authenticatioon Ch hallenge messaage. If the send der is the masster, it shall seet the USR vallue according to wh hich user is being b authentiicated. Refer to the discusssion in Clauuse 7 for more infformation. UINTn: MA AC Value.




The sender shall calculate the MAC Value according to the MAC algorithm specified by the Challenger, as described in Clause 7. The sender shall include in the MAC Value calculation the data listed in Table A-3, in the order listed. Table A-3—Data included in the MAC Value calculation Data Challenge message Addressing information

Challenged ASDU

Padding Data

Description The entire DNP3 Application Layer fragment containing the Authentication Challenge object. Although IEC/TS 62351-5 specifies a protocol may include addressing information from lower layers, DNP3 authentication does not include any such addresses. The entire DNP3 Application Layer fragment being challenged, including the Application Layer header. Any padding data required.

Included Always. Never.

If the Reason For Challenging is <1>, challenging a critical function. As required by the MAC algorithm.

Outstations sending this object shall use the current Monitoring Direction Session Key to calculate the MAC Value. Masters sending this object shall use the current Control Direction Session Key to calculate the MAC Value. A.45.2.2.3

Notes

In the DNP3 implementation of IEC/TS 62351-5 authentication, the length of the MAC Value is not specified within the object but in the Object Prefix. The Authentication Reply object should always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the MAC Value is therefore the size specified in the Object Prefix, minus 6 octets.




A.45.3

Au uthentication n—Aggressiv ve Mode req uest Group:

120

Variation:

3

Authenticcation

Type:

Info

Aggressiv ve Mode Request

Parsing Codes:

Table 12-31


A.45.3.1 De escription This object o is used fo or DNP3 securre authenticatio on as describedd in Clause 7. T This object maay be included aas the firrst object in eiither a DNP3 request r or a DNP3 D responsee. It attempts tto authenticate the fragment it appearrs in. Aggreessive Mode mu ust be precedeed by a Challen nge and a Reply ly. A device shhall not transmiit an Aggressivve Mode Request until the device hass received at leeast one Challeenge message from the Challlenger. Refer to ocedures in Claause 7 for more details. the pro The in nitial Challeng ge is necessary y because the sender s of this object uses the data from thhe most recenttly received Challenge message to calculate the Challenge S equence Num mber and the HMAC in thhe Aggreessive Mode Reequest. As sho own in the following figure, the t device shalll include an A Authentication H HMAC object (g120v9) as thhe last ob bject in the sam me fragment as the Authenticaation Aggressivve Mode Requuest object. Application Header

Object Headerr g120v3 Authentication n Aggressive Mode Requestt

Object g12 20v3 Authentication Aggressiv ve Mode Request

A.45.3.2

Co oding

A.45.3.2.1

Pictorial

Objecct headers and oobjects to be autheenticated, e.g.,g112v1 Control Relay y Output Block

Object Headder g120v9 Authenticatiion HMAC

Object gg120v9 Authenttication HMAC


7

6

5

4

3

2

1

0

bit position

b0


User Num mber

A.45.3.2.2 Fo ormal structu ure UINT32: Challenge C Sequ uence Number (CSQ). Th he Challenge Sequence Num mber (CSQ) sshall be the C CSQ from thee most recenttly recceived Challen nge message, plus p the numbeer of Aggressivve Mode Requeests (g120v3) oor Au uthentication Reply R objects (g g120v2) that thhe sender of thhis object has trransmitted sincce recceiving that Ch hallenge messaage. 724 Copyright © 2012 IEEE. All rightts reserved.



UINT16: User Number. The sender of this object shall use this value to identify which set of Session Keys is to be used to authenticate this Aggressive Mode Request. <0> := Unknown. Not used for this object. <1> := Default. One of two cases is occurring: ⎯ This object is being sent by a master on behalf of more than one user. ⎯ This object is being sent by an outstation and there is no corresponding user. In either case, the set of Session Keys used will be the default set used for this master–outstation pair. Refer to Clause 7 for more information. <2…65 535> := Chosen by the master station to be associated with a particular user and corresponding set of Session Keys. A.45.3.2.3

Notes

The DNP3 device shall transmit this object using the qualifier 0x07 (single-octet count of objects) with a count of 1.




A.45.4 4

Au uthentication n—session key k status re quest Group:

120

Variation:

4

Authenticcation

Type:

Info

Session Key K Status Requesst

Parsing Codes:

Table 12-31


A.45.4 4.1 De escription This object o is used for fo DNP3 securre authenticatio on as describedd in Clause 7. T This object maay be included in a DNP P3 request sentt by the masterr only. This mu ust be the only object to appeear in the requeest. The functioon code to t be used in th his request is an n Authenticatio on Request (0xx20). It is intennded to elicit a DNP3 response with function fu code Authentication A Response (0x8 83) containing a Session Keyy Status object. A.45.4 4.2

Co oding

A.45.4 4.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0 b15

User Num mber

A.45.4 4.2.2 Fo ormal structu ure UINT16: User U Number. Th he master shall use this value to identify whhich set of Sesssion Keys it is qquerying. <0 0> := Unknown n. Not used forr this object. <1> := Default. The T default sett of Session Keeys used by thhe master on beehalf of multipple users, or used when thee outstation innitiates the sequuence of messages that resullts hentication. Reefer to Clause 7 for a descripption of when thhis value shouuld in an auth be used. 2…65 535> := Chosen by thee master stationn to be associaated with a parrticular user annd <2 nding set of Seession Keys. correspon A.45.4 4.2.3

No otes

The master m shall usee the qualifier 0x07 0 (one octett count of obje cts) in the objeect header for tthis object.




A.45.5

Au uthentication n—session key k status Group:

120

Variation:

5

Authenticcation

Type:

Info

Session Key K Status

Parsing Codes:

Table 12-31


A.45.5.1 De escription This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 response only y. This must bee the only objecct to appear in the response. It is transmitteed in response to Session Keys aas known by thhe a Sesssion Key Status Request objeect and represeents the currennt state of the S outstattion. If the outstation consideers the Session Keys to be vaalid, this objectt is authenticateed with a MAC C. A.45.5.2

Co oding

A.45.5.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0

Key Change Sequence e Number b31 b0 b15

User Num mber

b7

b0

Key Wrap p Algorithm

b7

b0

Key Statuss

b7

b0

MAC Algo orithm

b0 b15

Challenge e Data Length

Challenge e Data

MAC Valu ue




A.45.5.2.2 Formal structure UINT32: Key Change Sequence Number (KSQ). Each outstation shall maintain a Key Change sequence number, which it shall use to match Key Status messages with subsequent Key Change messages. This value shall be initialized to zero on start-up of the outstation (unless the MAC algorithm is AESGMAC; see Clause 7). The outstation shall increment the KSQ each time it receives a Session Key Change or Session Key Status Request. (The first KSQ transmitted shall therefore always be 1) If the value reaches 4 294 967 295, the next KSQ the outstation transmits shall be zero. The master shall not process the KSQ except to include it in subsequent Key Change messages. UINT16: User Number. The outstation shall use this value to identify the set of Session Keys for which it is reporting the current status. This value shall match the value supplied in the previous Session Key Status Request, as described in the definition of that object. UINT8: Key wrap algorithm. Using this value, the outstation shall indicate to the master the algorithm it will use to decrypt the data in subsequent Session Key Change objects. Each device shall support at least the minimum subset of algorithms listed in Clause 7. <0> := not used. <1> := AES-128 Key Wrap Algorithm, as described in 7.6.1.2. <2> := AES-256 Key Wrap Algorithm, as described in 7.6.2.2. <3..127> := reserved for future use. <128..255> := reserved for vendor-specific choices. Not guaranteed to be interoperable. UINT8: Key status. This value describes the status of the two Session Keys as known by the outstation. <0> := not used. <1> := OK. There have been no communications failures or restarts since the last time the outstation received an authentic Key Change message. The Session Keys are valid. <2> := NOT_INIT. The outstation has not received an authentic Key Change message since it last started up, or has not received such a message within the Session Key Change Interval or Session Key Change Count configured at the outstation. The Session Keys are not valid. <3> := COMM_FAIL. The outstation has detected a communications failure in either the control or monitoring direction. The Session Keys are not valid. <4> := AUTH_FAIL. The outstation has received a non-authentic Challenge or Aggressive Mode Request. The Session Keys are not valid. NOTE—This shall also be the response if the USR number supplied is invalid.

<5..255> := reserved for future use. UINT8: MAC algorithm (MAL). Using this value, the outstation shall specify the algorithm that the master shall use to calculate the MAC Value, and shall also specify the resulting length of the MAC Value. Refer to 7.6.1.1 and 7.6.2.1 and the references cited there for details of how to calculate these algorithms. 728 Copyright © 2012 IEEE. All rights reserved.



<0> := No MAC Value in this message. <1> := HMAC SHA-1 truncated to 4 octets (serial). <2> := HMAC SHA-1 truncated to 10 octets (networked). <3> := HMAC SHA-256 truncated to 8 octets (serial). <4> := HMAC SHA-256 truncated to 16 octets (networked). <5> := HMAC SHA-1 truncated to 8 octets (serial). <6> := AES-GMAC (output is 12 octets). <7..127> := reserved for future use. <128..255> := reserved for vendor-specific choices. Not guaranteed to be interoperable. IMPORTANT: Refer to 7.6.1.4.3 regarding the dependency between the use of truncated MAC algorithms and the need for frequent Session Key changes. UINT16: Challenge Data Length. This value defines the length of the Challenge Data that follows. UINTn: Pseudo-random Challenge Data. The outstation shall include this pseudo-random data in the Key Status message to verify that the contents of the Key Status message are not predictable. The pseudo-random data shall be generated using the algorithm specified in FIPS 186-2. UINTn: MAC Value. The outstation shall calculate the MAC Value according to the MAC algorithm MAL, as described in Clause 7. The outstation shall include in the MAC Value calculation the data listed in Table A-4, in the order listed. It shall use the Monitoring Direction Session Key from the Session Key Change object most recently received from the master. Note that this MAC is calculated regardless of whether the Session Keys are currently considered valid. If they are not valid, the outstation shall use the last Monitoring Direction Session Key that was considered valid. If there were no previous Session Keys, the MAL shall be <0> and there shall be no MAC Value included in this object. Table A-4—Data included in the MAC Value calculation Data Challenge message

Padding Data

A.45.5.2.3

Description The entire DNP3 Application Layer fragment containing the Session Key Change object most recently received by the outstation. Any padding data required.

Included Always.

As required by the MAC algorithm.

Notes

The Authentication Challenge object should always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Challenge Data may therefore be either calculated from the qualifier and the length of the HMAC or read from the corresponding field of the object.




A.45.6

Au uthentication n—session key k change Group:

120

Variation:

6

Authenticcation

Type:

Info

Session Key K Change

Parsing Codes:

Table 12-31


A.45.6.1

De escription

This object o is used for DNP3 seccure authentication as descrribed in Clausse 7. The master performs aan Authentication Requ uest (0x20) of this t object to su upply the outsttation with thee Session Key tthat will be useed V in all subsequent s au uthentication opperations. Thiis must be thee only object to to calcculate MAC Values appearr in the requestt. The Seession Keys arre encrypted ussing a separate Update Key. A.45.6.2

Co oding

A.45.6.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0

Key Chan nge Sequencce Number b31 b0 b15

User Num mber

Encrypted d Key Wrap D Data

A.45.6.2.2 Fo ormal structu ure UINT24: Key K Change Sequence Numbeer (KSQ). Th his value shalll match the KSQ K transmitteed in the Sesssion Key Stattus object moost reccently received d by the masterr, as described in the definitioon of that objecct. UINT16: User U Number (U USR). Th he master shalll use this valuee to specify whhich set of Sesssion Keys is too be changed. It shaall match the USR in the Session S Key S Status object m most recently received by thhe maaster, as describ bed in the defin nition of that oobject.




UINTn: Wrapped key data. This value shall be the result of passing the Session Keys and the most recent Key Status message through the Key Wrap Algorithm defined in the Key Status message. The master shall pass the data through the Key Wrap Algorithm in the order described in Table A-5. Table A-5—Data included in the key wrap (in order) Data Key Length

Description The size of one of the Session Keys. Both keys are the same length. This value is two octets long. The key used to authenticate data from the master. The key used to authenticate data from the outstation. All data in the Session Key Status object most recently received from the outstation, KSQ first, not including any HMAC. As required by the key wrap algorithm.

Control Direction Session Key Monitoring Direction Session Key Key Status message

Padding data

Included Always

Always Always Always

As required.

The Session Keys shall be treated as arrays of octets and transmitted with the lowest index octet first. For example, Appendix A of the AES specification provides the example of a 128-bit cipher key shown in Table A-6. The octet with index 0, having value 2b, shall be transmitted first. Table A-6—Example of key order Value

2b

7e

15

16

28

ae

d2

a6

ab

f7

15

88

09

cf

4f

3c

index

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Note that the output from the key wrap algorithm may be longer than the input. For instance, the AES Key Wrap Algorithm produces output that is exactly 8 octets longer than its input. Table A-7 shows a typical example of the Wrapped Key Data using this algorithm. Table A-7—Example of wrapped key data Data

Description

Size (in octets)

Key Length

So the outstation will know what follows

2


Using the minimum size 128-bit keys

16


16

Session Key Status object

Using the minimum size of Challenge Data, i.e.,4 octets

15

Padding data

Required to make the input data a multiple of 8 octets.

7

Additional output

For the AES key wrap algorithm

8

TOTAL

64




A.45.6.2.3

Notes

In the DNP3 implementation of IEC/TS 62351-5 authentication, the length of the Wrapped Key Data is not specified within the object, but in the Object Prefix. The Authentication Key Change object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Wrapped Key Data is therefore the size specified in the Object Prefix, minus 6 octets. The outstation should respond to this request with a Session Key Status Object (g120v5).




A.45.7

Au uthentication n—error Grroup:

120

Vaariation:

7

Authenticcation

Tyype:

Event/Info

Error

Paarsing Coodes:

Table 12-31


A.45.7.1

De escription

This object o is used in n DNP3 securee authenticatio on as describedd in Clause 7. T This object is uused by a devicce (eitherr master or outstation) to indiicate an error with w a previouss authenticationn operation. This object o may be assigned a to a Class C and transm mitted as an evvent object alonng with other ddata. Outstationns shall not n allow this object o to be asssigned to no class, c or to stattic Class 0. If ssent by a mastter, this object is consid dered of type In nfo rather than Event. It is reecommended that t an instancce of each Autthentication Errror event object be createdd on each DNP P3 association to an outtstation. Doing g so permits thee outstation to report securityy problems onn one associatioon to massters on other associations. a Note N that the User Number m must be unique within a DNP33 association, aas describ bed in 7.7.4. Only O the most recent Authen ntication Errorr event object shall be buffered; older event objectts shall be discaarded to avoid denial of serviice attacks. A.45.7.2

Co oding

A.45.7.2.1

Pictorial

octet transmission order

7

6

5

4

3

2

1

0

bit position

b0

b31 b0 b15 b0 b15 b7

b0

Challenge Se equence Numb ber OR Sequence Key Change S Number User Numberr Association ID D Error Code

b0

Time of Errorr

b47

Error Text




A.45.7.2.2 Formal structure UINT32: Sequence Number. This value shall be the Challenge Sequence Number or Key Change Sequence Number, of the operation that the Error message is replying to. UINT16: User Number (USR). This value shall be the User Number of the operation that the Error message is replying to, identifying the set of Session Keys and Update Key in use. Note that the User Number may also be zero when the correct User Number is unknown. Refer to Clause 7. UINT16: Association ID. This value shall uniquely identify the association between the master and outstation on which the error occurred. The definition of a DNP3 association may be found in Annex C. Because of the variety of configurations of implementations, the Association ID may correspond to different combinations of DNP3 addresses, IP addresses, and port numbers or identifiers on the master and outstation. However, whatever mapping is used, the combination of User Number and Association ID shall be unique within the device. UINT8: Error code. This value shall specify the reason the error message is being transmitted. <0> := not used. <1> := Authentication failed. The authentication information supplied by the other device was incorrect, or the data it was authenticating was corrupted in transit. <2> := Unexpected response. The other device transmitted a message that did not follow the procedures as described in Clause 7. NO LONGER SUPPORTED. Used only in IEEE Std 1815-2010. <3> := No response. The other device either did not respond to the Challenge message or did not follow an Aggressive Mode request with data for authentication. NO LONGER SUPPORTED. Used only in IEEE Std 1815-2010. <4> := Aggressive Mode not supported. The device sending this Error Code does not permit the use of Aggressive Mode on this link. <5> := MAC algorithm not supported. The device sending this Error Code does not permit the use of the specified MAC algorithm on this link. Mandatory MAC algorithms are specified in the 7.6.1.1. <6> := Key Wrap algorithm not supported. The device sending this Error Code does not permit the use of the specified Key Wrap algorithm on this link. Mandatory Key Wrap algorithms are specified in 7.6.1.2. <7> := Authorization failed. The authentication information supplied by the other device was correct, but the authenticated user is not permitted to perform the requested operation. <8> := Update Key Change Method not permitted. The outstation does not permit the specified key change method on this link. Mandatory Update Key Change Methods are specified in 7.6.1.4.9. <9> := Invalid Signature. The digital signature supplied in a User Status Change or Signed Update Key Change object was invalid. <10> := Invalid Certification Data. The Certification Data supplied in a User Status Change object was invalid. <11> := Unknown User. The master attempted to change the Update Key of a user without first supplying a valid User Status Change. 734 Copyright © 2012 IEEE. All rights reserved.



<12> := Max Session Key Status Requests Exceeded. The master on a different association has requested Session Key Status too often and it is possible a denial of service attack is underway. <13…127> := reserved for future standardization. <128..255> := private range for definition by each vendor. A device using this range shall use a different Error Code for each possible error reason, and shall supply an Error Text to explain each Error Code. DNP3TIME: Time of error. Time when the event occurred expressed in standard DNP3 time. UNCDn: Error text. This value shall be a string of text suitable for display on a user interface or in a security log encoded in unicode UTF-8 as described in IETF RFC 3629 (note that all characters encoded in 7-bit ASCII comply with UTF-8). The Error Text shall explain the Error Code. It is recommended that the Error Text also include a unique description of the user represented by the User Number. For standardized Error Codes, the Error Text is optional and the length of the text may be zero. For private range Error Codes, the Error Text shall be mandatory. A.45.7.2.3

Notes

In the DNP3 implementation of IEC/TS 62351-5 authentication, the length of the Error Text is not specified within the object, but in the Object Prefix. The Authentication Error object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Error Text is therefore the size specified in the Object Prefix, minus 15 octets. The Error Text is optional.




A.45.8

Au uthentication n—user certiificate Group:

120

Variation:

8

Authenticcation

Type:

Info

User Certtificate

Parsing Codes:

Table 12-31


A.45.8.1 De escription This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 request only, using the Secu ure Authenticaation (0x20) fun unction code. T This must be thhe only object to appearr in the requestt. This object o is transm mitted by the master m station to identify wheen a user of thee outstation haas been added oor deleted d, when the usser’s role has changed, c or wh hen the date haas changed on which the user’s access to thhe outstattion will expiree. The daata provided in n this object is certified by an n external authhority that is noot the master sttation itself. Thhe authorrity provides th he certificate to the master, and the mastter provides thhe certificate tto the outstatioon withou ut modification n. The key used d to sign the ceertificate shall bbe the private kkey of the authhority. This object o variation n is an alternatiive form of an Authenticationn User Status C Change (g120vv10) object. It is an exttension of a standard s X.509 9v3 certificate that carries tthe equivalent information tto that found in g120v v10. The masteer may transmiit this object variation insteadd of g120v10. This object iss only used with outstattions that supp port asymmetricc Update Key Change C Methoods. A.45.8.2

Co oding

A.45.8.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b7

b0

ge Method Key Chang

b7

b0

Certificate e Type

IEC 62351 1-8 Certificatte

A.45.8.2.2 Fo ormal structu ure UINT8: Keey Change Metthod. Th he master shalll use this valu ue to identify tthe method thhat will be used to change thhe Up pdate Keys associated with th he user. Th he possible valu ues of Key Change Method aare described inn 7.6.1.4.9. Nuumbers less thaan 64 4 represent the use of symmeetric keys and algorithms, w while numbers 64 through 1227 rep present the usee of mostly asy ymmetric (pubblic) keys and algorithms. Thhis object is nnot useed with symmeetric Key Chan nge Methods. <0 0..63> := Symm metric, not used d with this objeect. 736 Copyright © 2012 IEEE. All rightts reserved.



<64> := Obsolete. Do not use. <65> := Obsolete. Do not use. <66> := Obsolete. Do not use. <67> := Asymmetric RSA-1024 / DSA SHA-1 / HMAC-SHA-1. <68> := Asymmetric RSA-2048 / DSA SHA-256 / HMAC-SHA-256. <69> := Asymmetric RSA-3072 / DSA SHA-256 / HMAC-SHA-256. <70> := Asymmetric RSA-2048 / DSA SHA-256 / AES-GMAC. <71> := Asymmetric RSA-3072 / DSA SHA-256 / AES-GMAC. <72..127> := Reserved for future symmetric methods. <128..255> := Reserved for vendor-specific choices. Not guaranteed to be interoperable. The algorithms identified here are described in more detail in 7.6. UINT8: Certificate Type. The master shall use this value to specify whether the IEC/TS 62351-8 Certificate is an ID Certificate, which contains the user’s public key, or an Attribute Certificate, which does not. <0> := not used. <1> := ID Certificate. <2> := Attribute Certificate. <3..255 > := Reserved. UINTn: IEC/TS 62351-8 Certificate. This data is an extension to a standard X.509v3 cryptographic certificate. The definition of an X.509v3 certificate is found in IETF RFC 5280. The format of this extension intended for use in the power industry is defined in IEC/TS 62351-8. Parts of those specifications as they existed at the time of writing are reproduced here in order to explain the application to DNP3. However, if there is a disagreement between the text here and those specifications, those specifications are definitive. IETF RFC 5280 defines an X.509 ID Certificate in ASN.1 notation as follows: Certificate ::= SEQUENCE { tbsCertificate signatureAlgorithm signatureValue } TBSCertificate ::= SEQUENCE { version serialNumber signature issuer validity subject subjectPublicKeyInfo issuerUniqueID

subjectUniqueID

TBSCertificate, AlgorithmIdentifier, BIT STRING

[0] Version must be v3, CertificateSerialNumber, AlgorithmIdentifier, Name, Validity, Name, SubjectPublicKeyInfo, [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3




extensions

[3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3

}

IETF RFC 5755 also provides the following definition of an Attribute Certificate, which is used to change the role or other characteristics of a user without supplying the user’s public key again. AttributeCertificate ::= SEQUENCE { Acinfo AttributeCertificateInfo, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } AttributeCertificateInfo ::= SEQUENCE { Version AttCertVersion -- version is v2, Holder Holder, Issuer AttCertIssuer, Signature AlgorithmIdentifier, serialNumber CertificateSerialNumber, attrCertValidityPeriod AttCertValidityPeriod, attributes SEQUENCE OF Attribute, issuerUniqueID UniqueIdentifier OPTIONAL, extensions Extensions OPTIONAL } Attribute ::= SEQUENCE { Type Values

AttributeType, SET OF AttributeValue -- at least one value is required

} AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY DEFINED BY AttributeType

At a minimum, a DNP3 device implementing this object shall support the following values in the signatureAlgorithm and tbsCertificate.signature of an ID Certificate, or the signatureAlgorithm and acInfo.signature fields of an Attribute Certificate (the two fields are always the same) ⎯ id-dsa-with-sha1. To be used when the Key Change Method is <67>. ⎯ id-dsa-with-sha256. To be used when the Key Change Method is <68> through <71>. If a DNP3 device implementing this object is also to be compliant with IEC/TS 62351-8, it must also support the following algorithms: ⎯ sha-1WithRSAEncryption, key length 1024. To be used when the Key Change Method is <67>. ⎯ sha256WithRSAEncryption. To be used when the Key Change Method is <68> through <71>, with the corresponding RSA key length. This object shall contain the IEC/TS 62351-8 extension to the X.509 certificate format, defined as follows: id-IEC62351 OBJECT_IDENTIFIER ::= { 1 2 840 10070 } id-IECuserRoles OBJECT_IDENTIFIER ::= id-IEC62351 { 8 1 } IECUserRoles ::= SEQUENCE OF UserRoleInfo




UserRoleInfo ::= SEQUENCE { -- contains the role information blob -- IEC62351 specific parameter userRole SEQUENCE SIZE (1..MAX) OF RoleID aor UTF8String (SIZE(1..64)), revision INTEGER (0..255), roleDefinition UTF8String (0..23) OPTIONAL, -- optional fields to be used within IEEE 1815 and IEC60870-5 operation Operation OPTIONAL, statusChangeSequenceNumber INTEGER (0..4 294 967 295) OPTIONAL, } RoleId ::= INTEGER (-32 768..32 767) Operation ::= ENUMERATED { Add (1), Delete (2), Change (3) }

The RoleID numbers shall be the numbers defined in the User Status Change (g120v10) object for User Role. These have been chosen to correspond with the roles defined in IEC/TS 62351-8. Note that this certificate format permits a particular user to be assigned multiple roles simultaneously, while the User Status Change object only permits a single role at a time. The aor or Area of Responsibility field shall be used by the outstation to verify that this certificate applies to the outstation receiving the certificate. Area of Responsibility shall be a pre-configured characteristic of any outstation that uses this object. Defining possible values of this text string is the responsibility of the authority, but it may for instance indicate a geographical area or a portion of the organization. An outstation may belong to more than one Area of Responsibility. The outstation shall not accept any role changes for a user unless the aor field contains one of the Areas of Responsibility the outstation is configured to belong to. The revision number shall always increase. The roleDefinition is a string that is used to describe where the RoleID numbers have been defined. To comply with this standard, use the value “IEC62351-8” because the DNP3 RoleID numbers have been made to align with IEC/TS 62351-8. The other DNP3 Secure Authentication operating parameters discussed in this standard shall be included in the certificate as listed in Table A-8.




Table A-8—DNP3 Secure Authentication parameters in IEC/TS 62351-8 certificates DNP3 parameter

Source in IEC/TS 62351-8 ID certificate

Source in IEC/TS 62351-8 attribute certificate

User Name

Certificate.tbsCertificate.subject

AttributeCertificate.Acinfo.holder

User Public Key

Certificate.tbsCertificate. subjectPublicKeyInfo

Not included. Defined in the ID Certificate. An ID Certificate must be supplied by the authority before an Attribute Certificate can be used.

User Role Expiry Interval

Certificate.tbsCertificate.validity

AttributeCertificate.Acinfo. attrCertValidityPeriod

Subtract the notBefore time from the notAfter time to calculate the interval. If the outstation has secure time synchronization when it receives the certificate, it shall use the notBefore and notAfter times as provided. Otherwise, it shall use the calculated interval relative to the time it received the certificate. The outstations shall re-evaluate the expiry of the certificate whenever secure time synchronization is achieved. User Role

Certificate.tbsCertificate.extensions. IECUserRoles.userRole

As described for the ID certificate, but using the notBeforeTime and notAfterTime fields.

AttributeCertificate.Acinfo.extensions. IECUserRoles.userRole

Note that there may be several instances of IECUserRoles, so multiple roles may be assigned to the user through one certificate. Operation

Certificate.tbsCertificate.extensions. IECUserRoles.operation Required in DNP3.

AttributeCertificate.Acinfo.extensions. IECUserRoles.operation Required in DNP3. Operation shall only be either (2) Delete or (3) Changes in an attribute certificate.

Status Change Sequence Number

Certificate.tbsCertificate.extensions. IECUserRoles. statusChangeSequenceNumber

AttributeCertificate.Acinfo.extensions. IECUserRoles. statusChangeSequenceNumber

Optional if the authority can guarantee Certificate.tbsCertificate.serialNumber will always increase for this user.

Optional if the authority can guarantee AttributeCertificate.Acinfo.serialNum ber will always increase for this user.

A.45.8.3 Notes The Authentication User Certificate object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, as specified in the Object Prefix. The length of the IEC/TS 62351-5 Certificate is therefore the length of the object minus one octet for the Key Change Method.




A.45.9

Au uthentication n—message authenticatiion code (MA AC) Group:

120

Variation:

9

Authenticcation

Type:

Info

Message Authentication Co ode (MAC)

Parsing Codes:

Table 12-31


A.45.9.1 De escription This object o is used fo or DNP3 securre authenticatio on as describedd in Clause 7. T This object maay be included aas the lasst object in eitther a DNP3 request r or a DNP3 D responsee. It attempts to authenticate the fragment it appearrs in. Aggreessive Mode sh hall be preced ded by a Challlenge. A deviice shall not ttransmit an Agggressive Modde Requeest until it has received at leeast one Challenge message.. Refer to the procedures inn 7.5.3 for more detailss. The in nitial Challeng ge is necessary y because the sender of thiis object uses data from the most recenttly received Challenge message m to calcculate the MAC C Value. As sho own in the folllowing figure, the device sh hall include ann Authentication Aggressivee Mode Requeest objectt (g120v3) as th he first object in i the same fraagment as the A Authentication MAC object. Application n Header

Object g120v3 Authentiication Aggressiive Mode Reequest

Object Head der g120v3 Authentication Aggressive Mode Requeest

A.45.9.2

Co oding

A.45.9.2.1

Pictorial

Objecct headers and obbjects to be autheenticated, e.g.,g1 2v1 Control Relay y Output Block

Object Headder g120v9 Authenticatiion MAC

Object g120v9 Authentiication MAC


7

6

5

4

3

2

1

0

bit position

MAC Valu ue

A.45.9.2.2 Fo ormal structu ure UINTn: MA AC Value. In Aggressive Mode, M the MAC Value shall bee calculated in the same mannner as in norm mal ode, but shall be b calculated based b on the saame ASDU as tthe Aggressivee Mode Requesst, mo ratther than the prrevious ASDU U. Table A-9 deescribes this diifference.




Table A-9—Data included in the HMAC Value calculation in Aggressive Mode Data

Description

Included

Challenge message

The entire Application Layer fragment containing the most recently received Authentication Challenge Object, including the CSQ at the time of that challenge.

Always.

Addressing information

Although IEC/TS 62351-5 specifies a protocol that may include addressing information from lower layers, DNP3 authentication does not include any such addresses.

Never.

Authenticated Data

The entire Application Layer fragment that this object is included in, including the Application Layer header, all objects preceding this one, and the object header and object prefix for this object.

Always.

Padding Data

Any padding data required.

As required by the MAC algorithm.

The length of the MAC Value shall be determined by the MAC algorithm (MAL) of the most recent Challenge received by the sender of the object, as described in the definition of the Authentication Challenge object. Outstations sending this object shall use the current Monitoring Direction Session Key to calculate the MAC Value. Masters sending this object shall use the current Control Direction Session Key to calculate the MAC Value. A.45.9.3

Notes

In the DNP3 implementation of IEC/TS 62351-5 authentication, the length of the MAC Value is not specified within the object but in the Object Prefix. The Authentication Aggressive Mode Request object should be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the MAC Value is therefore the size specified in the Object Prefix.




A.45.10

Au uthentication n—user statu us change Group:

120

Variation:

10

Authenticcation

Type:

Info

User Stattus Change

Parsing Codes:

Table 12-31


A.45.10.1 De escription This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 request only, using the Secu ure Authenticaation (0x20) fun unction code. T This must be thhe only object to appearr in the requestt. This object o is transm mitted by the master m station to identify wheen a user of thee outstation haas been added oor deleted d, when the user’s role has ch hanged, or wheen the date on w which the userr’s access to thhe outstation wiill expiree has changed. The daata provided in n this object is certified by an n external authhority that is noot the master sttation itself. Thhe authorrity provides th he certification n data to the master, m and the master providdes the certificaation data to thhe outstattion without modification. m Prior to t using this object, o the cho oice to use eith her public keyys or symmetriic keys for rem motely changinng Updatte Keys shall be b pre-configurred at both master and outstaation. This chooice will determ mine the contennt of the Certification Data, D as illustraated in Table A-10. A Table e A-10—Crea ation of certiification data a Metho od of changing Update U Keys User Status Informatio on Included when producing p the Ceertification Data (iin order)

Operattion performed by b the authoriity on the above Status Inform mation to producee the Certificcation Data

Public Keys Operation Status Change Sequence Numbber User Role piry Interval User Role Exp User Name Leength User Public Keey Length User Name K User’s Public Key Digital Signatu ure

Symm metric Keys Operattion Status Change Sequennce Number User R Role User R Role Expiry Interrval User N Name Length User N Name

Messaage Authenticatioon Code (note: not a Key Wrapp algorithm—no key is transmitted in thhis case)




A.45.10.2

Coding

A.45.10.2.1

Pictorial




A.45.10.2.2 Formal structure UINT8: Key Change Method. The master shall use this value to identify the method that will be used to change the Update Keys associated with the user. In this object, the Key Change Method specifies the operation the authority performed on the User Status Information to produce the Certification Data, and thus certify the user status change. The possible values of Key Change Method are described in 7.6.1.4.9. Numbers less than 64 represent the use of symmetric keys and algorithms, while numbers 64 through 127 represent the use of mostly asymmetric (public) keys and algorithms. <0> := not used. <1> := Obsolete. Do not use. <2> := Obsolete. Do not use. <3> := Symmetric AES-128 / SHA-1-HMAC. <4> := Symmetric AES-256 / SHA-256-HMAC. <5> := Symmetric AES-256 / AES-GMAC. <6..63> := Reserved for future symmetric methods. <64> := Obsolete. Do not use. <65> := Obsolete. Do not use. <66> := Obsolete. Do not use. <67> := Asymmetric RS-1024 / DSA SHA-1 / SHA-1-HMAC. <68> := Asymmetric RSA-2048 / DSA SHA-256 / SHA-256-HMAC. <69> := Asymmetric RSA-3072 / DSA SHA-256 / SHA-256-HMAC. <70> := Asymmetric RSA-2048 / DSA SHA-256 / AES-GMAC. <71> := Asymmetric RSA-3072 / DSA SHA-256 / AES-GMAC. <72..127> := Reserved for future symmetric methods. <128..255> := Reserved for vendor-specific choices. Not guaranteed to be interoperable. The algorithms identified here are described in more detail in 7.6.1. UINT8: Operation. The master shall use this value to specify how the user’s status is to be changed: <0> := not used. <1> := ADD. This is a new user not previously known to the outstation. The outstation shall record the User Status Information. <2> := DELETE. The outstation shall invalidate the existing Update Key associated with the User Name. <3> := CHANGE. The outstation shall update the User Status Information associated with the User Name. <4..255> := reserved for future use. UINT32: Status Change Sequence Number (SCS). The authority shall use this value to prevent replays of the User Status Change message. The authority shall set this value to 0 initially and increment it for each User Status Change. If the value is 4 294 967 295, the next value shall be 0. 745 Copyright © 2012 IEEE. All rights reserved.



UINT16: User Role. The master shall use this value to identify the role the user is subsequently permitted to perform. No user is permitted to change the role of another user; only the authority may do so. Table 7-12 describes the permitted standard roles and the corresponding permissions. The interpretation of these permissions is a local issue. Outstations may be configured to disallow any of the standard roles defined here. UINT16: User Role Expiry Interval. The master shall use this value to indicate when the role of this user will expire, causing the outstation to invalidate the Update Key associated with this User Name. This value shall indicate the number of days after receiving the User Status Change object that the outstation shall consider the user role to be expired. This value is not effective until after the user’s Update Key has been changed following the User Status Change. Note that time synchronization is considered a mandatory Critical Function requiring authentication in DNP3. UINT16: User Name Length. The master shall use this value to specify the length of the User Name that follows. UINT16: User Public Key Length. The master shall use this value to specify the length (in octets) of the Public Key associated with this user. — If the Key Change Method is less than 64, this value is zero. If the Key Change Method is between 64 and 127 inclusive, this value is the length of the User Public Key included in this object and signed by the authority. — Any other values of Key Change Method are defined by external agreement and are not guaranteed to be interoperable. UINT16: Certification Data Length. The master shall use this value to specify the total length of the Certification Data that follows. UINTn: User Name. The master shall use this value to specify which user’s status is to be changed. The name shall be unique within the organization managed by the authority, with one exception: The null-terminated UTF-8 string “Common” shall be used to identify the common Update Key used between the master and the outstation. The format of the User Name is otherwise outside the scope of this standard. UINTn: User Public Key. The master shall use this value to specify the Public Key associated with the user. Because it is a Public Key, it is not encrypted. If symmetric keys are being used to change Update Keys (i.e.,Key Change Method is <64), there is no Public Key and this value is therefore not included in the object. This value shall be an octet-by-octet copy of the SubjectPublicKeyInfo field from an X.509 certificate (IETF RFC 5280). UINTn: Certification Data. The authority shall use this value to certify that the other fields of this object are correct. The authority shall create the Certification Data as described in Table A-10 using the specified Key Change Method and pass it to the master for verbatim transmission to the outstation in this field of this object.




A.45.10.3 Notes The Authentication User Status Change object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Certification Data may therefore be either calculated from the qualifier and the length of the other fields or read from the corresponding field of the object.




A.45.11

Au uthentication n—update ke ey change re equest Group:

120

Variation:

11

Authenticcation

Type:

Info

Update Key K Change Requeest

Parsing Codes:

Table 12-31


A.45.11.1

De escription

This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 request only, using the Auth hentication Req quest (0x20) fuunction code. T This must be thhe only object to appearr in the requestt. The master m transmits this object to begin the process of chhanging the U Update Key asssociated with a particu ular user at th he outstation. The T master speecifies the nam me of the userr whose Updaate Key is to bbe changed. The master also includ des pseudo-ran ndom Challennge Data to bbe used by thhe outstation to nticate itself. authen The ou utstation shall send an Update Key Change Reply object iin response to tthis object. A.45.11.2

Co oding

A.45.11.2.1

Pictorial


7

6

5

4

3

2

1

0

b7

bit position

b0 b0

b15 b b0 b15 b

Key Chan nge Method User Nam me Length Master Challenge Da ata Length

User Nam me

Master Challenge Da ata




A.45.11.2.2 Formal structure UINT8: Key Change Method. The master shall use this value to specify the method and algorithms (symmetric or asymmetric) that will be used to change the Update Key. The possible values of this field are described in the User Status Change object (g120v10). The master shall use numbers smaller than 64 to specify symmetric algorithms and keys and numbers 64 to 127 specify asymmetric algorithms and keys. UINT16: User Name Length. The master shall use this value to specify the length of the User Name that follows. UINT16: Master Challenge Data Length. The master shall use this value to specify the length of the Challenge Data that follows. The minimum length shall be as specified in Clause 7. UINTn: User Name. The master shall use this value to specify which user’s key is to be changed. The name shall be unique within the organization managed by the authority, with one exception: The null-terminated UTF-8 string “Common” shall be used to identify the common Update Key used between the master and the outstation. The format of the User Name is otherwise outside the scope of this standard. UINTn: Pseudo-random Challenge Data from Master. The master shall include this pseudo-random data in the Update Key Change Request if the Key Change Method is symmetric (less than 64). The pseudo-random data shall be generated using the algorithm 3.1 specified in the FIPS 186-2. A.45.11.2.3 Notes The Authentication Challenge object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix.



IEEE Sttd 1815-2012 IEEE Standard d for Electric Pow wer Systems Com mmunications—D Distributed Netwo ork Protocol (DN NP3)

A.45.12

Au uthentication n—update ke ey change re eply Group:

120

Variation:

12

Authenticcation

Type:

Info

Update Key K Change Reply

Parsing Codes:

Table 12-31


A.45.12.1

De escription

This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 response only y, using the Au uthentication Reesponse (0x83)) function codee. This object o is transm mitted in respo onse to an Upd date Key Channge Request obbject. The outstation uses thhis objectt to assign a sequence numbeer to the Updatte Key change sequence, assiign a User Num mber to the user in queestion, and supp ply the master with pseudo-raandom Challennge Data. A.45.12.2

Co oding

A.45.12.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0

Key Chan nge Sequencce Number b31 b0 b15 b0 b15

User Num mber Outstation n Challenge Data Length

Outstation n Challenge Data

A.45.12.2.2 Fo ormal structu ure UINT32: Key K Change Sequence Numbeer (KSQ). Th his is the Key y Change Sequ uence numberr defined in thhe Session Keey Status objeect (g1 120v5). The outstation o shalll use this valuue to identify messages thatt are part of thhe sam me key changee sequence. In addition to inccrementing thiis value wheneever it receivess a Seession Key Change or Sessio on Key Statuss request, the ooutstation shalll increment thhe KS SQ each time itt receives an Update U Key Ch ange Request oobject. Th he master shalll not process the KSQ exceept to include it in subsequeent Update Keey Ch hange objects. 750 Copyright © 2012 IEEE. All rightts reserved.



UINT16: User Number. This value is the integer value the outstation has chosen to represent the User Name specified in the Update Key Change Request object. The User Number need only be unique within the current DNP3 association between the master and the outstation. UINT16: Challenge Data Length. This value defines the length of the Challenge Data that follows, in octets. The minimum length shall be as specified in 7.6.1.4.9. UINTn: Pseudo-random Challenge Data from Outstation. The outstation shall provide this pseudo-random data to ensure mutual authentication can take place between it and the master. The pseudo-random data shall be generated using the algorithm 3.1 specified in FIPS 186-2. A.45.12.2.3 Notes This object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Challenge Data may therefore be either calculated from the qualifier or read from the corresponding field of the object.




A.45.13

Au uthentication n—update ke ey change Group:

120

Variation:

13

Authenticcation

Type:

Info

Update Key K Change

Parsing Codes:

Table 12-31


A.45.13.1

De escription

This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 request only. The master m uses this object to supp ply the encrypteed new Updatee Key for the uuser. This object o shall bee followed in the t same DNP P3 request by one of the foollowing objeccts based on thhe Updatte Key Change Method speciffied by the masster in the Upddate Key Changge Request: ⎯ If the Updaate Key Chang ge Method is symmetric, ann Update Keyy Change Conffirmation objeect (g120v15) follows. f ⎯ If the Upd date Key Chan nge Method iss asymmetric, an Update K Key Change S Signature objeect (g120v14) follows. f A.45.13.2

Co oding

A.45.13.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

b0

Key Chan nge Sequencce Number b31 b0 b15 b0 b15

User Num mber Encrypted d Update Keyy Length

Encrypted d Update Keyy Data




A.45.13.2.2 Formal structure UINT32: Key Change Sequence Number (KSQ). This value is the Key Change Sequence number supplied by the outstation in the Update Key Change Reply object (g120v12). UINT16: User Number. This value is the integer value the outstation has supplied in the Update Key Change Reply object (g120v12) to represent the user whose Update Key is being changed. UINT16: Encrypted Update Key Length. This value defines the length of the encrypted Update Key that follows. UINTn: Encrypted Update Key Data. This value contains the new Update Key for the user, plus the name of the user and the Outstation Challenge Data from the outstation, in the order shown in Table A-11. Table A-11—Encrypted Update Key data Data

Description

From object…

User Name

The organizationally unique name of the user associated with the new Update Key


Update Key

The new Update Key for the user

Outstation Challenge Data

Pseudo-random data selected by the outstation


Padding Data

Any padding data required

n/a

The Update Key Data shall be encrypted using the algorithm specified in the Key Change Method of the Update Key Change Request. The Update Key Data shall be encrypted using one of the following keys: — If the Key Change Method is symmetric, the Update Key Data shall be encrypted using the symmetric key shared between the central authority and the outstation. The master shall pass this Encrypted Update Key Data from the central authority to the outstation in this object without modification. — If the Key Change Method is asymmetric, the Update Key Data shall be encrypted using the outstation’s public key. A.45.13.2.3 Notes This object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix.




A.45.14

Au uthentication n—update ke ey change si gnature Group:

120

Variation:

14

Authenticcation

Type:

Info

Update Key K Change Signatture

Parsing Codes:

Table 12-31


A.45.14.1

De escription

This object o is used for f DNP3 secu ure authenticattion as describbed in Clause 77. This object is included inn a DNP3 request only,, following an n Update Key Change objecct (g120v13). This object aauthenticates thhe date Key for a particular p user. changiing of the Upd This object o shall be transmitted by y the master on nly when the m master specifiedd a Key Changge Method in iits most recent r Update Key K Change Request R that specifies the use of asymmetricc (public) keyss and algorithm ms (i.e.,th he value of Key y Change Meth hod was betweeen 64 and 127)). A.45.14.2

Co oding

A.45.14.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

Digital Sig gnature

A.45.14.2.2 Fo ormal structu ure UINTn: Diigital Signaturee. Th his value is thee digital signatu ure of the mastter on behalf oof the user, callculated over thhe data found in Ta able A-12 in the order show wn, using the aalgorithm speciified in the Keey hange Method of the Update Key K Change R Request. Ch Th he master shall calculate the signature usingg the Private K Key of the userr, correspondinng to the Public Key y the master su upplied in the U User Status Chaange (g120v100) object.




Table A-12—Data included in the digital signature Data

Description

Source

Outstation Name

The organizationally-unique name of the outstation.

Pre-configured

Master Challenge Data

Pseudo-random data selected by the master


Outstation Challenge Data

Pseudo-random data selected by the outstation


Key Change Sequence Number (KSQ)

Sequence number that stays the same for this set of key change messages


User Number (USR)

Short number assigned by the outstation to represent this user


Encrypted Update Key Data

The encrypted Update Key and accompanying data, including the name of the user associated with the Update Key

Update Key Change

Padding Data


n/a

A.45.14.2.3

Notes

This object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix.



IEEE Sttd 1815-2012 IEEE Standard for Electric Pow wer Systems Com mmunications—D Distributed Netwo ork Protocol (DNP3)

A.45.15

Au uthentication n—update ke ey change co onfirmation Group:

120

Variation:

15

Authenticcation

Type:

Info

Update Key K Change Confirrmation

Parsing Codes:

Table 12-31


A.45.15.1

De escription

This object o is used for fo DNP3 securre authenticatio on as describedd in Clause 7. T This object maay be included in either a DNP3 request or a DNP3 3 response. It authenticates the master andd the outstatioon to each other hentication cod de (MAC) and the new Updatte Key that is ssupplied by thee master. using a message auth Exchaanging this objeect ensures that both master and a outstation aagree on the foollowing inform mation: ⎯ The new Up pdate Key. ⎯ The name of o the user or ou utstation who is i receiving thee object. ⎯ The pseudo o-random Challlenge Data pro ovided by both master and ouutstation to avoiid replay. ⎯ The sequen nce number iden ntifying this Update U Key Chaange. ⎯ The User Number N that willl be associated d with this Upddate Key in all subsequent auuthentications. A.45.15.2

Co oding

A.45.15.2.1

Pictorial


7

6

5

4

3

2

1

0

bit position

Message A Authenticatio on Code

A.45.15.2.2 Fo ormal structu ure UINTn: Meessage Authentication Code (MAC). ( Ta able A-13 desccribes the auth hentication dataa to be used inn the calculatiion, in the ordder sho own. Although h similar data is transmittedd in both direcctions, it is im mportant that thhe name of the sen nder and the order o of the psseudo-random data in the caalculation difffer pending on thee direction. This prevents an attacker from replaying the ddata sent by onne dep device to imperso onate the otherr device. Th he key used to calculate the MAC M is the new w Update Keyy supplied by tthe master in thhe Up pdate Key Change object. Th he algorithm annd length of thee MAC shall bbe determined bby thee Key Change Method field of the Update Key Change Request that innitiated this keey change sequencee.




Table A-13—Data included in the MAC calculation Data Receiver’s User Name

Description Long organizationally unique name for the user or outstation whose is receiving this object.

From object… If a master is receiving this object, this name comes from the Update Key Change Request. If an outstation is receiving this object, the outstation name was pre-configured.

Sender’s Challenge Data

If a master is sending this object, this is the Master Challenge Data.

Update Key Change Request.

If an outstation is sending this object, this is the Outstation Challenge Data.

Update Key Change Reply.

If a master is receiving this object, this is the Master Challenge Data.

Update Key Change Request.

If an outstation is receiving this object, this is the Outstation Challenge Data.


Key Change Sequence Number (KSQ)

Sequence number that stays the same for this set of key change messages.


User Number

Short number assigned by the outstation to represent this user.


Padding Data


n/a

Receiver’s Challenge Data

A.45.15.2.3

Notes

This object shall always be used with a Qualifier of 0x5B, indicating that the object is of variable length up to 65 535 octets, specified in the Object Prefix. The length of the Encrypted Authentication Data is therefore the size specified in the Object Prefix.




A.46

Ob bject group p 121: securrity statistic cs

A.46.1

Se ecurity statis stic—32-bit with w flag Group:

121

Variation:

1

Security Statistic

Type:

Static

32-bit with flag

Parsing Codes:

Table 12-31


A.46.1.1

De escription

This object o is used to report the current value of a security statistic. See 111.9.10 for a description off a Securiity Statistic Point Type. See 7.5.2.2 7 for detaails of the poinnt indexes perm mitted for this oobject and wheen the staatistics are incrremented. Variattion 1 objects contain c a 32-bitt, unsigned inteeger count valuue. A.46.1.2

Co oding

A.46.1.2.1

Pictorial


7 0

6 DC C

5 0

4 LF

3 2 RF CL

1 0 R OL RS

bit position

Flag octett b0

b15

Associatio on ID

b0

Count Value b31


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:


Bitt 6:

DISCONTIN NUITY

Bitt 7:





UINT16: Association ID. This value shall uniquely identify the association between the master and the outstation on which the statistic is measured. The definition of a DNP3 association may be found in Annex C. Because of the variety of configurations of implementations, the Association ID may correspond to different combinations of DNP3 addresses, IP addresses, and port numbers or identifiers on the master and outstation. The Association ID shall be unique within the device. A value of 0 for Association ID means the statistic was measured on the same association on which this object is reported. UINT32: Count value. This is the most recently obtained or computed value. Range is 0 to +4 294 967 295. A.46.1.2.3 Notes See 11.6 for flag bit descriptions.




A.47

Ob bject group p 122: securrity statistic c events

A.47.1

Se ecurity statis stic event—32-bit with fla ag Group:

122

Variation:

1

Security Statistic Event

Type:

Event

32-bit with flag

Parsing Codes:

Table 12-31


A.47.1.1

De escription

This object o is used to t report the vaalue of a securrity statistic aft fter the count hhas changed. S See 11.9.10 forr a descrip ption of a Secu urity Statistic Point P Type. Seee 7.5.2.2 for ddetails of the point indexes permitted for thhis objectt and when the statistics are in ncremented. Outstaations shall nott allow this object to be assign ned to no classs, or to static C Class 0. Variattion 1 objects contain c a 32-bitt, unsigned inteeger count valuue. A.47.1.2

Co oding

A.47.1.2.1

Pictorial


7 0

6 DC C

5 0

4 LF

3 2 RF CL

1 0 RS OL

bit position

Flag octett b0

b15 b

Associatio on ID

b0

Count Va alue b31 b


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST

Bitt 3:

REMOTE_FO ORCED

Bitt 4:

LOCAL_FOR RCED

Bitt 5:





Bit 6:

DISCONTINUITY

Bit 7:

Reserved, always 0

UINT16: Association ID. This value shall uniquely identify the association between the master and the outstation on which the statistic is measured. The definition of a DNP3 association may be found in Annex C. Because of the variety of configurations of implementations, the Association ID may correspond to different combinations of DNP3 addresses, IP addresses, and port numbers or identifiers on the master and outstation. The Association ID shall be unique within the device. A value of 0 for Association ID means the statistic was measured on the same association on which this object is reported. UINT32: Count value. This is the most recently obtained or computed value. Range is 0 to +4 294 967 295. A.47.1.2.3

Notes





A.47.2 2

Se ecurity statis stic event—32-bit with fla ag and time Group:

122

Variation:

2

Security Statistic Event

Type:

Event


Parsing Codes:

Table 12-31


A.47.2 2.1

De escription

This object o is used to t report the vaalue of a securrity statistic aft fter the count hhas changed. S See 11.9.10 forr a descrip ption of a Secu urity Statistic Point P Type. Seee 7.5.2.2 for ddetails of the point indexes permitted for thhis objectt and when the statistics are in ncremented. Outstaations shall nott allow this object to be assign ned to no classs, or to static C Class 0. Variattion 2 objects contain c a 32-bitt, unsigned inteeger count valuue and a timesttamp. A.47.2 2.2

Co oding

A.47.2 2.2.1

Pictorial


7 0

6 DC C

5 0

4 LF

3 2 1 0 RF CL RS R OL

bit position

Flag octett b0

b15

Associatio on ID

b0

Count Vallue b31 b0

Time-of-occcurrence

b47


ONLINE

Bitt 1:

RESTART

Bitt 2:

COMM_LOS ST 762 Copyright © 2012 IEEE. All rightts reserved.



Bit 3:

REMOTE_FORCED

Bit 4:

LOCAL_FORCED

Bit 5:

Reserved, always 0

Bit 6:

DISCONTINUITY

Bit 7:

Reserved, always 0

UINT16: Association ID. This value shall uniquely identify the association between the master and the outstation on which the statistic is measured. The definition of a DNP3 association may be found in Annex C. Because of the variety of configurations of implementations, the Association ID may correspond to different combinations of DNP3 addresses, IP addresses, and port numbers or identifiers on the master and outstation. The Association ID shall be unique within the device. A value of 0 for Association ID means the statistic was measured on the same association on which this object is reported. UINT32: Count value. This is the most recently obtained or computed value. Range is 0 to +4 294 967 295. DNP3TIME: Time-of-occurrence. Time when the event occurred expressed in standard DNP3 time. A.47.2.2.3

Notes





Annex B (informative) DNP3 quick reference
















Annex C (informative) Associations C.1

Introduction

DNP3 over Internet Protocol follows the same logical connection structure as DNP3 over serial ports. The simplest case is a device (either master or outstation) with only one available logical connection to another device. In this case, it is clear that messages arriving on the connection are from the “other” device. The situation becomes more complicated when a device allows simultaneous communication with more than one other device. For clarity, this annex shall only discuss the issue of solicited messaging and configurations without dual end points.

C.2

Association definition

An association is a representation of a logical connection between a master and an outstation. An association maintains state information associated with the logical connection. This state information includes: ⎯ Master Identifier (e.g., a communication port number if serial or an IP address if networked) ⎯ 16-bit master DNP3 address ⎯ Outstation Identifier ⎯ 16-bit outstation DNP3 address ⎯ Data Link Layer state information ⎯ Transport Function state information ⎯ Application Layer state information ⎯ User Layer state information (e.g., timeout status on a control select) and for DNP3/UDP or DNP3/TCP associations also includes: ⎯ Remote UDP or TCP port number ⎯ Remote IP address ⎯ Local UDP or TCP port number ⎯ Type of port (either UDP or TCP) DNP3 over serial connections requires a (constant) physical link between devices. In this case, the combination of the physical link and 16-bit DNP3 address uniquely defines the association. In fact, for a point-to-point RS-232 link, the association is completely defined by just the physical link. In the IP network case, a single physical link can “carry” an unlimited number of associations. Each outstation needs to be capable of determining the association identity solely by observing the data “on the wire.” It is important to note that associations remain intact longer than a single message exchange between a master and an outstation.

C.3

Association issues

Creation of an association using serial ports is a simple matter. From the master perspective, if it wishes to communicate with an outstation, it simply inspects its local pre-configured tables to determine whether it already has established an association with the target device. If not (and if the master has sufficient 769 Copyright © 2012 IEEE. All rights reserved.



resources), it allocates resources for the outstation and begins communication using the communication port and outstation DNP3 address from the table. The association with the outstation is never terminated (because the wire between the devices continues to exist). From the outstation perspective, it simply inspects its local tables to determine whether it has ever communicated with this master address. If so, it uses that existing state information. If not, it creates an association that initially sends the RESTART IIN. This association is never destroyed. DNP3 transportation over IP-based networks adds additional complications. Whereas there is a fairly limited number of devices that can directly connect via serial ports (e.g., 1 per serial port for RS-232 and about 32 per serial port for RS-485), there are an unlimited number of devices that may logically connect using the Internet Protocol suite. When using DNP3 over IP, the combination of physical link and DNP3 address is no longer sufficient to uniquely identify the association. In addition, the number of associations that may be maintained by an outstation using DNP3 over IP is limited only by the resources within the outstation and not by the physical connection hardware.

C.4

UDP associations

UDP is a stateless protocol. This means that, at the UDP level, each end of the link has no concept of prior communication. This does not match the DNP3 requirement that each end maintain association state information. Therefore, the master shall maintain information in addition to what is required for UDP communication. When a master wishes to communicate with an outstation using UDP, it performs the same internal table scan/association creation as for a serial connection. It then constructs an outgoing datagram addressed to the outstation using the IP address, UDP port number, and the identified outstation DNP3 address from its internal table. Incoming datagrams (UDP messages received from the network) are matched to an association using the outstation’s IP address and the outstation’s UDP port number. When an outstation receives a request from the master, it shall also match this to an association. Unlike the master case, pre-configured tables need not be present in the outstation; in which case, the outstation shall build the table “on-the-fly.” If the outstation determines that this is an existing (active) association, it passes the message to that association’s DNP3 protocol layers, which may generate a response. The DNP3 protocol layers use information from the association, in the same way as they would for a serial connection, for example, checking whether the message has the correct application sequence number. The response generated shall also include association-specific information such as whether the RESTART IIN should be set. If the outstation determines that this is a new (permitted) association, it creates the association and sets the application state to indicate that the RESTART IIN should be sent in responses until it is cleared. The matching of a UDP message with an association may include the DNP3 destination address, the source IP address, or the source UDP port number. An interesting question is what to do if the incoming UDP datagram is from an IP address with an inactive (timed-out) UDP association. Two choices exist in this case: Ignore the fact that the association was already known and re-create it, or attempt to re-establish communications using the association. The latter is recommended since loss of an association may mean discarding of “good” events. UDP transactions can resume if the network connection is lost and then regained. It should be treated the same as if a serial port plug was removed and then re-inserted.

C.5

TCP associations

TCP is a state-oriented protocol. This means that, at the TCP level, each end of the link participates in a connection setup before DNP3 communications can commence. When a master wishes to communicate with an outstation using TCP, it performs the same internal table scan/association creation as for a serial connection. It then requests a connection to the outstation and forms the TCP stream, which is used for communication. Requests are sent to the outstation using the stream, and responses from the outstation are received on the stream.




When an outstation receives a request from the master, it shall match this to an association. Unlike the master case, pre-configured tables need not be present in the outstation; in which case, the outstation builds the table on “on-the-fly.” Outstations using DNP3 over TCP receive two types of TCP messages: requests for connection and stream data. Upon a receipt of a TCP request for connection, the outstation performs the same determination of association existence as is done in UDP. The matching of a TCP connection request with an association may include checking the DNP3 destination address, the TCP port number, or the source IP address. If the outstation finds an existing association, it may check the old connection and, if it is no longer in use, reattach to the existing association. It is recommended that the outstation attempt to re-attach to a matching association, when possible, to avoid discarding of “good” events. TCP messages with stream data are simply routed to the appropriate DNP3 protocol layers for the logical association, corresponding to the received stream (which may generate responses on that stream). Responses generated by an outstation also include association-specific information such as whether the RESTART IIN should be set. If the outstation determines that this is a new (permitted) association, it creates the association and sets the application state to indicate that the RESTART IIN should be sent in responses until it is cleared. Once connected, each end of the DNP3/TCP link expects periodic messages from the other end. Both devices shall retain an association while messages are received with sufficient regularity (determined by the poll interval or keep-alive timer). If the association was not retained, then, for example, the DNP3 protocol Application Layer would always be forced to accept every sequence number and there would be NO protection against duplicated messages. After a TCP association times out, the outstation may release the association’s resources. A possible implementation may mark a timed-out association as available for use by a new association. In this case, a timeout simply permits release of state information.




Annex D (normative) UTF-8 related copyright When referring to UTF-8 in the XML Schema, IETF RFC 3629 has been used.41 IETF RFC 3629 contains the following copyright notice that applies to examples and quotations appearing in this document that were extracted from IETF RFC 3629. Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

41 IETF publications are available from the Internet Engineering Task Force, IETF Secretariat, c/o Association Management Solutions, LLC (AMS), 48377 Fremont Boulevard, Suite 117, Fremont, CA 94538 (http://www.ietf.org).




Annex E (informative) Sample CRC calculations The following are ‘C’ language coding examples that illustrate how to compute the DNP3 CRC. /************************************************************************** This function illustrates how to compute the CRC and append it to a data block for transmission. **************************************************************************/ short idx; unsigned char dataBlock[18]; short blockSize; unsigned short crc;

// // // //

Index Array to hold transmitted block Size of data block, not including CRC octets 16-bit check code (crc accumulator)

// ... // Insert code here to load contents of dataBlock and compute blockSize; // ... // Compute check code crc = 0; // Initialize for (idx = 0; idx < blockSize; idx++) computeCRC(dataBlock[idx],&crc); crc = ~crc; // Invert // Append CRC to end of block dataBlock[idx++] = (unsigned char)crc; dataBlock[idx] = (unsigned char)(crc >> 8); // ...

/************************************************************************** This function illustrates how to compute the CRC and check it for a received data block. **************************************************************************/ short idx; unsigned char dataBlock[18]; short blockSize; unsigned short crc;

// // // //

Index Array to hold received data block Size of data block, not including CRC octets 16-bit check code (crc accumulator)

// ... // Insert code here to receive contents of dataBlock and blockSize; // ... // Compute check code for data in received block crc = 0; // Initialize for (idx = 0; idx < blockSize; idx++) computeCRC(dataBlock[idx],&crc); crc = ~crc; // Invert // Check CRC at end of block 773 Copyright © 2012 IEEE. All rights reserved.



if (dataBlock[idx++] == (unsigned char)crc && dataBlock[idx] == (unsigned char)(crc >> 8)) { // Block received without error // // // } else { //

... Insert code here to process good block ...

Error discovered

// ... // Insert error processing code here // ... } // ... [Table Lookup Method]

/************************************************************************ This function updates the contents of *crcAccum using a table lookup method. ************************************************************************/ void computeCRC ( unsigned char dataOctet, // Data octet unsigned short *crcAccum // Pointer to 16-bit crc accumulator ) { static unsigned short crcLookUpTable[256] { 0x0000, 0x365E, 0x6CBC, 0x5AE2, 0xD978, 0xFF89, 0xC9D7, 0x9335, 0xA56B, 0x26F1, 0xB26B, 0x8435, 0xDED7, 0xE889, 0x6B13, 0x4DE2, 0x7BBC, 0x215E, 0x1700, 0x949A, 0x29AF, 0x1FF1, 0x4513, 0x734D, 0xF0D7, 0xD626, 0xE078, 0xBA9A, 0x8CC4, 0x0F5E, 0x9BC4, 0xAD9A, 0xF778, 0xC126, 0x42BC, 0x644D, 0x5213, 0x08F1, 0x3EAF, 0xBD35, 0x535E, 0x6500, 0x3FE2, 0x09BC, 0x8A26, 0xACD7, 0x9A89, 0xC06B, 0xF635, 0x75AF, 0xE135, 0xD76B, 0x8D89, 0xBBD7, 0x384D, 0x1EBC, 0x28E2, 0x7200, 0x445E, 0xC7C4, 0x7AF1, 0x4CAF, 0x164D, 0x2013, 0xA389, 0x8578, 0xB326, 0xE9C4, 0xDF9A, 0x5C00, 0xC89A, 0xFEC4, 0xA426, 0x9278, 0x11E2, 0x3713, 0x014D, 0x5BAF, 0x6DF1, 0xEE6B, 0xA6BC, 0x90E2, 0xCA00, 0xFC5E, 0x7FC4, 0x5935, 0x6F6B, 0x3589, 0x03D7, 0x804D, 0x14D7, 0x2289, 0x786B, 0x4E35, 0xCDAF, 0xEB5E, 0xDD00, 0x87E2, 0xB1BC, 0x3226,

= // Look up table values 0xEF26, 0x10AF, 0x5D4D, 0xA2C4, 0xC689, 0x3900, 0x74E2, 0x8B6B, 0xBC78, 0x43F1, 0x0E13, 0xF19A, 0x95D7, 0x6A5E, 0x27BC, 0xD835, 0x499A, 0xB613, 0xFBF1, 0x0478,

0xB5C4, 0x4A4D, 0x07AF, 0xF826, 0x9C6B, 0x63E2, 0x2E00, 0xD189, 0xE69A, 0x1913, 0x54F1, 0xAB78, 0xCF35, 0x30BC, 0x7D5E, 0x82D7, 0x1378, 0xECF1, 0xA113, 0x5E9A,

0x839A, 0x7C13, 0x31F1, 0xCE78, 0xAA35, 0x55BC, 0x185E, 0xE7D7, 0xD0C4, 0x2F4D, 0x62AF, 0x9D26, 0xF96B, 0x06E2, 0x4B00, 0xB489, 0x2526, 0xDAAF, 0x974D, 0x68C4,




0x8F13, 0x709A, 0x3D78, 0xC2F1, 0xF5E2, 0x0A6B, 0x4789, 0xB800, 0xDC4D, 0x23C4, 0x6E26, 0x91AF, };

0xB94D, 0x46C4, 0x0B26, 0xF4AF, 0xC3BC, 0x3C35, 0x71D7, 0x8E5E, 0xEA13, 0x159A, 0x5878, 0xA7F1,

0xE3AF, 0x1C26, 0x51C4, 0xAE4D, 0x995E, 0x66D7, 0x2B35, 0xD4BC, 0xB0F1, 0x4F78, 0x029A, 0xFD13,

0xD5F1, 0x2A78, 0x679A, 0x9813, 0xAF00, 0x5089, 0x1D6B, 0xE2E2, 0x86AF, 0x7926, 0x34C4, 0xCB4D,

0x566B, 0xA9E2, 0xE400, 0x1B89, 0x2C9A, 0xD313, 0x9EF1, 0x6178, 0x0535, 0xFABC, 0xB75E, 0x48D7,

0x6035, 0x9FBC, 0xD25E, 0x2DD7, 0x1AC4, 0xE54D, 0xA8AF, 0x5726, 0x336B, 0xCCE2, 0x8100, 0x7E89,

0x3AD7, 0xC55E, 0x88BC, 0x7735, 0x4026, 0xBFAF, 0xF24D, 0x0DC4, 0x6989, 0x9600, 0xDBE2, 0x246B,

0x0C89, 0xF300, 0xBEE2, 0x416B, 0x7678, 0x89F1, 0xC413, 0x3B9A, 0x5FD7, 0xA05E, 0xEDBC, 0x1235

*crcAccum = (*crcAccum >> 8) ^ crcLookUpTable[(*crcAccum ^ dataOctet) & 0xFF]; } /* end computeCRC() */ [Bit-shifting Method] /************************************************************************ This function updates the contents of *crcAccum using right shifts for each bit. ************************************************************************/ void computeCRC ( unsigned char dataOctet, // Data octet unsigned short *crcAccum // Pointer to 16-bit crc accumulator ) { unsigned char idx; // Index unsigned short temp; // Temporary variable #define REVPOLY 0xA6BC

// Reverse polynomial for right shifts

// Perform right shifts and update crc accumulator for (idx = 0; idx < 8; idx++) { temp = (*crcAccum ^ dataOctet) & 1; *crcAccum >>= 1; dataOctet >>= 1; if (temp) *crcAccum ^= REVPOLY; } } /* end computeCRC() */




Annex F (informative) Managing Secure Authentication updates F.1

Introduction

DNP3 Secure Authentication has been updated from the version contained in IEEE 1815-2010. The version included in Clause 7 of IEEE 1815-2010 is identified as SAv2 (Secure Authentication v2), and the version included in Clause 7 of IEEE 1815-2012 is identified as SAv5 (Secure Authentication v5); the two versions are not compatible. An outstation reports the version number using Object Group 0 Variation 209. This annex highlights considerations when dealing with DNP3 Secure Authentication updates, in order to minimize interoperability issues. It applies to devices implementing DNP3 Secure Authentication for the first time as well as for devices updating their Secure Authentication version. The nature of the SCADA (utility) industries, in which DNP3 is deployed, typically has the following characteristics. Once deployed and commissioned by a user, an outstation device can remain in the same state as its initial installation for periods of many years. During this long deployment lifetime, an outstation may have its firmware or capabilities upgraded several times; however, this is not assured. Many systems are not upgraded. Due to the remote nature of many installations, regular patching of firmware or software is not always practical. The introduction of Secure Authentication to DNP3 will not likely change this reality in many situations. In comparison with moderate-to-high numbers of widely distributed outstations, the low number of more centralized master stations in a given system should, in theory, be simpler to upgrade on a regular basis. For various reasons, this is not always the case. The reputation of DNP3 that has been built in the utility SCADA industry globally has been, in no small part, due to the proven interoperability of products supporting DNP3, including devices of different ages and produced by different manufacturers. The release of an updated DNP3 Secure Authentication does not invalidate the deployment of existing or planned new devices supporting earlier versions of the specification. When a new version of IEEE Std 1815 or DNP3 Secure Authentication is announced, there is a natural delay between the time of the official release of the specification and the availability of devices that can be purchased with the new functionality, including upgrades for previously installed devices. In the case of DNP3 Secure Authentication, it would be normal to expect that a device supporting earlier versions of Secure Authentication (or a device that does not support DNP3 Secure Authentication at all), once installed, will remain in the field with the installed functionality for a long period of time. The DNP Users Group publishes test procedures for validating the operation of DNP3. Executing these test procedures against a device is one of the steps required in the claim that a device is conformant with the DNP3 specification. Test Procedures for Secure Authentication will be released together with, or as soon as practical after, the release of DNP3 Secure Authentication revisions. The DNP3 Device Profiles provided by manufacturers for their devices contain detailed information from which users can determine master station to outstation device interoperability. The version of DNP3 Secure Authentication supported by a device is now included in these DNP3 Device Profiles.




F.2

Se ecure Authe entication version v upd dates

As DN NP3 Secure Au uthentication reevisions are relleased, the DN NP Users Groupp will state thee interoperability relatio onships between DNP3 Seccure Authentiication versionns. In particuular this will highlight nonninterop perability issuees between adjacent DNP3 Seecure Authentiication versionns. Due to o the nature of critical infraastructure securrity as it relatees to communnication devicee protocols, it is envisaaged that it wiill be necessarry for the DN NP Users Grouup to occasionnally revise the DNP3 Secuure Authentication speciification. Thesse revisions wiill then be releeased as a new w version of thhe DNP3 Secuure Authentication speciification. Wheree possible, th he DNP Userss Group will provide upddates to the D DNP3 Secure Authenticatioon specifi fication such that t a new veersion will be backward com mpatible withh the previous version that it superssedes. In this case, users caan expect there would be nno interoperabbility issues bbetween devicees implem menting backw ward compatiblle versions. An ny new functionnality that is added to the new w version of thhe specifi fication will not be available on o devices thatt implement ann older (but com mpatible) versiion. At tim mes, it may bee necessary to change or enh hance the DNP P3 Secure Autthentication sppecification in a manneer that would lead l to non-intteroperable beh havior betweenn devices impllementing adjaacent versions oof DNP3 Secure Autheentication. In th his case, the reevision could bbe considered to define a neew specification, ot simply be a revision r to the existing speciffication. and no

F.3

Re ecommenda ations

F.3.1

Fo or outstations

It is highly recom mmended that outstations be b deployed w with the latesst version off DNP3 Secuure p by the t DNP Useers Group. Hoowever, in ordder to be inteeroperable, neew Authentication as published ystem may be required r to im mplement a speecific version oof DNP3 Secuure outstattions being deployed in a sy Authentication, as su upported by thee master station n. If the masterr station suppoorts multiple veersions of DNP P3 on, the outstatio on should impllement the highhest of those vversions. Securee Authenticatio When support for a new version of o DNP3 Secu ure Authenticattion is being aadded to an ouutstation alreaddy pport for all previous nonn-interoperable DNP3 Secuure supporrting DNP3 Secure Autheentication, sup Authentication versiions should bee retained if possible, p with configuration to select betw ween the DNP P3 on versions. Securee Authenticatio The DNP D Users Grroup recommen nds to manufaacturers that thhey should prrovide timely uupdates to theeir devicees based on thee latest DNP3 Secure S Authenttication specifiication publishhed by the DNP P Users Group.. F.3.2

Fo or master sta ations

Similaarly, it is high hly recommend ded that masteer stations be deployed withh the latest veersion of DNP P3 Securee Authenticatio on as publisheed by the DNP P Users Group up. It may be advantageous for new mastter station n deployments to implement several version ns of DNP3 Seecure Authentication in orderr to operate with outstattions already deployed in the t field. In particular, p wheere there are sseveral conseccutive backwarrd compaatible versions published by the DNP Userrs Group, the m master station should at leasst implement thhe highesst of those verssion numbers. When support for a new n version off DNP3 Securee Authenticatioon is being addded to a masterr station alreaddy pport for all previous nonn-interoperable DNP3 Secuure supporrting DNP3 Secure Autheentication, sup Authentication versions should be b retained, with w configuraation to selectt between thee DNP3 Secuure Authentication versions.




Master stations thatt support morre than one version v of DN NP3 Secure A Authentication should providde guration selectiion for the DN NP3 Secure Au uthentication vversion for eacch association between mastter config and ou utstation. The DNP D Users Grroup recommen nds to manufaacturers that thhey should prrovide timely uupdates to theeir devicees based on thee latest DNP3 Secure S Authenttication specifiication publishhed by the DNP P Users Group.. F.3.3

Fo or DNP3 systtem users

Users requiring DN NP3 Secure Au uthentication should s specifyy the provisionn of devices tthat support thhe mber in use in the t system as well as the moost recent verssion as publishhed by the DN NP highesst version num Users Group. The DNP3 D Device Profile supplieed by device m manufacturers will list the ssupported DNP P3 on versions. Securee Authenticatio The security of DN NP3 communiccation will be increased by configuring a system to usse later versionns mbers) of the DNP3 D Secure Authentication A specification. W When configuuring the system m, (higheer version num the maaster station co onfiguration fo or the outstatio on and the outtstation configuuration shouldd use the higheest comm mon DNP3 Secu ure Authenticattion version su upported by botth devices. It is recommended that t users dev velop an upgraade policy to m move their sysstems toward tthe latest DNP P3 on specification n. Securee Authenticatio F.3.4

Co ommercial co onsideration ns

Manuffacturers, supp pliers, and sy ystem users of o DNP3 capaable equipmennt need to bee aware of thhe comm mercial realitiess associated with w the introdu uction of revissed specificatiions. Devices deployed in thhe field may m be a mixtu ure of versions. Interoperatio on with deployyed systems m may require devvices to suppoort more than t one versio on of DNP3 Seecure Authenticcation, as descrribed above. There may be comm mercial advanttage for manufacturers in offfering devicess that support multiple DNP P3 on versions, in line with thesee recommendattions. Securee Authenticatio




Annex G (informative) Bibliography Bibliographical references are resources that provide additional or helpful material but do not need to be understood or used to implement this standard. Reference to these resources is made for informational use only. [B1] EIA-RS-232-F, Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange.42 [B2] EIA-RS-485-A, Electrical Characteristics of Generators and Receivers for Use in Balanced Multipoint Systems. [B3] IEC 60870-5-1:1990, Telecontrol equipment and systems. Part 5: Transmission protocols—Section One: Transmission frame formats.43 [B4] IEC 60870-5-101:2003, Telecontrol equipment and systems—Part 5-101: Transmission protocols— Companion standard for basic telecontrol tasks. [B5] IEC 60870-5-2:1992, Telecontrol equipment and systems - Part 5: Transmission protocols—Section 2: Link transmission procedures. [B6] IEC/TS 62351-1, Power systems management and associated information exchange—Data and communications security. Part 1: Communication network and system security—Introduction to security issues. [B7] IEEE Std C37.1™-2007, IEEE Standard for SCADA and Automation Systems.44 [B8] IEEE Std 1686™-2007, IEEE Standard for Substation Intelligent Electronic Devices (IEDs) Cyber Security Capabilities. [B9] IEEE P1815.1™/D4.00 (June 2012), IEEE Draft Standard for Exchanging Information Between Networks Implementing IEC 61850 and IEEE Std 1815 (Distributed Network Protocol—DNP3).45 [B10] ISO 8601, Data elements and interchange formats—Information interchange—Representation of dates and times.46 [B11] Mansfield, N., Practical TCP/IP: Designing, Using, and Troubleshooting TCP/IP Networks on Linux and Windows. London: Addison-Wesley/Pearson Education Ltd., 2003. (A hands-on tutorial with a wide scope of networking information.) [B12] Stevens, W. R., TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA: Addison-Wesley, 1994. (A complete introduction to the Internet Protocols.)

42

EIA publications are available from Global Engineering Documents (http://global.ihs.com/). IEC publications are available from the International Electrotechnical Commission (http://www.iec.ch/). IEC publications are also available in the United States from the American National Standards Institute (http://www.ansi.org/). 44 IEEE publications are available from The Institute of Electrical and Electronics Engineers (http://standards.ieee.org/). 45 Numbers preceded by P are IEEE authorized standards projects that were not approved by the IEEE-SA Standards Board at the time this publication went to press. For information about obtaining a draft, contact the IEEE. 46 ISO publications are available from the ISO Central Secretariat (http://www.iso.org/). ISO publications are also available in the United States from the American National Standards Institute (http://www.ansi.org/). 43



IEEE DPN3

Recommend Documents