DNP 3.

0 Interface

Version 3.1.0.x
OSIsoft, LLC
777 Davis St., Suite 250
San Leandro, CA 94577 USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web: http://www.osisoft.com

OSIsoft Australia • Perth, Australia

OSIsoft Europe GmbH • Frankfurt, Germany
OSIsoft Asia Pte Ltd. • Singapore
OSIsoft Canada ULC • Montreal & Calgary, Canada
OSIsoft, LLC Representative Office • Shanghai, People’s Republic of China
OSIsoft Japan KK • Tokyo, Japan
OSIsoft Mexico S. De R.L. De C.V. • Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil

DNP 3.0 Interface

Copyright: © 2002-2011 OSIsoft, LLC. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical,
photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.

OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, PI Asset Framework(PI-AF), IT
Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Data Services, PI Manual Logger, PI
ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of
OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners.

U.S. GOVERNMENT RIGHTS

Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as
provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC.
Published: 12/2011
Table of Contents
Terminology.................................................................................................................. vii

Chapter 1. Introduction.................................................................................................1
Reference Manuals............................................................................................ 3
Supported Features........................................................................................... 3
Diagram of Hardware Connection......................................................................8

Chapter 2. Principles of Operation...............................................................................9

Connectivity....................................................................................................... 9
Data Handling.................................................................................................... 9
I/O Thread Pool.....................................................................................10
Worker Thread Pool...............................................................................10
Static Data....................................................................................................... 10
Event Type Data............................................................................................... 12
Unsolicited Data............................................................................................... 13
Status Data...................................................................................................... 14
Questionable Data........................................................................................... 14
Binary Input Data...................................................................................14
Binary Output Data................................................................................15
Analog Input/Output Data......................................................................15
Octet String Data..............................................................................................15
Time and Date.................................................................................................. 16
Heartbeat Tags................................................................................................. 16
Interface................................................................................................. 16
RTU....................................................................................................... 16
RTU Status Information....................................................................................16
Reset Link Counter Tag....................................................................................17
DNP3 Internal Indication (IIN) Tags..................................................................17
Outputs............................................................................................................ 19
Analog Output Block..............................................................................19
Counters.......................................................................................................... 19
Freezing/Clearing Counters...................................................................19
DNP and other Debugging messages..............................................................20
Tag Level Debugging for Received Values.......................................................21
UniInt Phase 2 Failover....................................................................................22
Cold Configuration.................................................................................22
Hot Configuration...................................................................................22

Chapter 3. Upgrading to Version 3.0.1.0 or Later......................................................25

PI Point Configuration......................................................................................25
Heartbeat Tags......................................................................................25
DNP3 Internal Indication (IIN) Tags (Object 80).....................................26
DNP 3.0 Interface iii
 Counter Freeze Request Tags (Object 20)............................................26
Digital State Sets.............................................................................................. 27

Chapter 4. Installation Checklist.................................................................................29

Data Collection Steps.......................................................................................29
Interface Diagnostics........................................................................................30
Advanced Interface Features...........................................................................31

Chapter 5. Interface Installation..................................................................................33

Naming Conventions and Requirements..........................................................33
Interface Directories.........................................................................................34
PIHOME Directory Tree.........................................................................34
Interface Installation Directory...............................................................34
Interface Installation Procedure.......................................................................34
Installing Interface as a Windows Service........................................................34
Installing Interface Service with PI Interface Configuration Utility....................35
Service Configuration............................................................................35
Installing Interface Service Manually.....................................................37

Chapter 6. Digital States..............................................................................................39

Chapter 7. PointSource...............................................................................................41

Chapter 8. PI Point Configuration...............................................................................43

Point Attributes.................................................................................................43
Tag......................................................................................................... 43
PointSource...........................................................................................44
PointType...............................................................................................44
Location1...............................................................................................44
Location2...............................................................................................44
Location3...............................................................................................47
Location4...............................................................................................48
Location5...............................................................................................48
InstrumentTag........................................................................................49
Userint1.................................................................................................51
Userint2.................................................................................................52
ExDesc.................................................................................................. 52
Scan...................................................................................................... 53
Convers.................................................................................................53
Span...................................................................................................... 53
Squareroot.............................................................................................53
Userreal1...............................................................................................53
Userreal2...............................................................................................54
Zero....................................................................................................... 54
Shutdown...............................................................................................54
Scaling............................................................................................................. 54
Output Points................................................................................................... 56
Trigger Method 1 (Recommended)........................................................57
Trigger Method 2....................................................................................57

Chapter 9. Startup Command File..............................................................................59

Configuring the Interface with PI ICU...............................................................59

DNP 3.0 Interface iv

 DNP3 Interface page.............................................................................61
Command-line Parameters..............................................................................72
Sample PIDNP3.bat File..................................................................................81

Chapter 10. Device Configuration (XML) File..........................................................83

XML Overview........................................................................................83
PIDNP3 XML Nodes, Elements, and Attributes......................................84

Chapter 11. UniInt Failover Configuration...............................................................91

Introduction...................................................................................................... 91
Quick Overview......................................................................................92
Synchronization through a Shared File (Phase 2)............................................93
Configuring Synchronization through a Shared File (Phase 2)........................94
Configuring UniInt Failover through a Shared File (Phase 2)...........................97
Start-Up Parameters..............................................................................97
Failover Control Points..........................................................................99
PI Tags.................................................................................................100
Detailed Explanation of Synchronization through a Shared File (Phase 2)....104
Steady State Operation........................................................................105
Failover Configuration Using PI ICU..............................................................107
Create the Interface Instance with PI ICU......................................................107
Configuring the UniInt Failover Startup Parameters with PI ICU....................108
Creating the Failover State Digital State Set..................................................108
Using the PI ICU Utility to create Digital State Set...............................109
Using the PI SMT 3 Utility to create Digital State Set...........................109
Creating the UniInt Failover Control and Failover State Tags (Phase 2)........112

Chapter 12. Interface Node Clock...........................................................................113

Chapter 13. Security................................................................................................115

Chapter 14. Starting / Stopping the Interface........................................................117

Starting Interface as a Service.......................................................................117
Stopping Interface Running as a Service.......................................................117

Chapter 15. Buffering..............................................................................................119

Which Buffering Application to Use................................................................119
How Buffering Works.....................................................................................120
Buffering and PI Server Security....................................................................120
Enabling Buffering on an Interface Node with the ICU...................................121
Choose Buffer Type.............................................................................121
Buffering Settings.................................................................................122
Buffered Servers..................................................................................124
Installing Buffering as a Service...........................................................127

Chapter 16. Interface Diagnostics Configuration..................................................131

Scan Class Performance Points....................................................................131
Performance Counters Points........................................................................134
Performance Counters.........................................................................135
Performance Counters for both (_Total) and (Scan Class x)................135

DNP 3.0 Interface v

Table of Contents

Performance Counters for (_Total) only...............................................137

Performance Counters for (Scan Class x) only....................................139
Interface Health Monitoring Points.................................................................141
I/O Rate Point................................................................................................ 146
Interface Status Point.....................................................................................148

Appendix A. Error and Informational Messages...................................................151

Message Logs................................................................................................ 151
Messages....................................................................................................... 152
Informational........................................................................................ 152
System Errors and PI Errors..........................................................................153
UniInt Failover Specific Error Messages........................................................153
Informational........................................................................................ 153
Errors (Phase 1 & 2)............................................................................154
Errors (Phase 2)..................................................................................155

Appendix B. PI SDK Options..................................................................................157

Appendix C. Sample PI Tag Configurations..........................................................159

Heartbeat Tags............................................................................................... 159
Interface (non-UniInt health tag)..........................................................159
RTU..................................................................................................... 159
Reset Link Counter Tag..................................................................................159
DNP3 Internal Indication (IIN) Tags................................................................159
Value Tags...................................................................................................... 161
If scaling is required:............................................................................161
Status Tags.................................................................................................... 162
Counter Freeze Tags (Object 20)...................................................................163
Counter Freeze Tag (Output)...............................................................163
Counter Freeze Tag (Input)..................................................................163
Analog Control Block (Object 41)...................................................................164
Time and Date (Object 50).............................................................................165
Octet String (Object 110/111).........................................................................165

Appendix D. Device Profile Document...................................................................167

Appendix E. Tips for Non-Conformant DNP3 Devices..........................................173

RTU Not Responding to Reset Link Request.................................................173

Appendix F. Technical Support and Resources....................................................175

Before You Call or Write for Help.........................................................175
Help Desk and Telephone Support......................................................175
Search Support....................................................................................176
Email-based Technical Support...........................................................176
Online Technical Support.....................................................................176
Remote Access....................................................................................177
On-site Service....................................................................................177
Knowledge Center...............................................................................177
Upgrades.............................................................................................177
OSIsoft Virtual Campus (vCampus).....................................................177

vi
 Appendix G. Revision History................................................................................179

DNP 3.0 Interface vii

Terminology
To understand this interface manual, you should be familiar with the terminology used in this
document.

Buffering
Buffering refers to an Interface Node’s ability to store temporarily the data that interfaces
collect and to forward these data to the appropriate PI Servers.

N-Way Buffering
If you have PI Servers that are part of a PI Collective, PIBufss supports n-way buffering.
N-way buffering refers to the ability of a buffering application to send the same data to each
of the PI Servers in a PI Collective. (Bufserv also supports n-way buffering to multiple PI
Servers however it does not guarantee identical archive records since point compressions
attibutes could be different between PI Servers. With this in mind, OSIsoft recommends that
you run PIBufss instead.)

ICU
ICU refers to the PI Interface Configuration Utility. The ICU is the primary application that
you use to configure PI interface programs. You must install the ICU on the same computer
on which an interface runs. A single copy of the ICU manages all of the interfaces on a
particular computer.
You can configure an interface by editing a startup command file. However, OSIsoft
discourages this approach. Instead, OSIsoft strongly recommends that you use the ICU for
interface management tasks.

ICU Control
An ICU Control is a plug-in to the ICU. Whereas the ICU handles functionality common to
all interfaces, an ICU Control implements interface-specific behavior. Most PI interfaces have
an associated ICU Control.

Interface Node
An Interface Node is a computer on which
 the PI API and/or PI SDK are installed, and
 PI Server programs are not installed.

PI API
The PI API is a library of functions that allow applications to communicate and exchange
data with the PI Server. All PI interfaces use the PI API.

PI Collective
A PI Collective is two or more replicated PI Servers that collect data concurrently. Collectives
are part of the High Availability environment. When the primary PI Server in a collective

DNP 3.0 Interface ix

 becomes unavailable, a secondary collective member node seamlessly continues to collect
and provide data access to your PI clients.

PIHOME
PIHOME refers to the directory that is the common location for PI 32-bit client applications.
A typical PIHOME on a 32-bit operating system is C:\Program Files\PIPC.
A typical PIHOME on a 64-bit operating system is C:\Program Files (x86)\PIPC.
PI 32-bit interfaces reside in a subdirectory of the Interfaces directory under PIHOME.
For example, files for the 32-bit Modbus Ethernet Interface are in
[PIHOME]\PIPC\Interfaces\ModbusE.
This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64
directory path. For example, ICU files in [PIHOME]\ICU.

PIHOME64
PIHOME64 is found only on a 64-bit operating system and refers to the directory that is the
common location for PI 64-bit client applications.
A typical PIHOME64 is C:\Program Files\PIPC.
PI 64-bit interfaces reside in a subdirectory of the Interfaces directory under PIHOME64.
For example, files for a 64-bit Modbus Ethernet Interface would be found in
C:\Program Files\PIPC\Interfaces\ModbusE.
This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64
directory path. For example, ICU files in [PIHOME]\ICU.

PI Message Log
The PI message Log is the file to which OSIsoft interfaces based on UniInt 4.5.0.x and later
writes informational, debug and error message. When a PI interface runs, it writes to the
local PI message log. This message file can only be viewed using the PIGetMsg utility. See
the UniInt Interface Message Logging.docx file for more information on how to access these
messages.

PI SDK
The PI SDK is a library of functions that allow applications to communicate and exchange
data with the PI Server. Some PI interfaces, in addition to using the PI API, require the use of
the PI SDK.

PI Server Node
A PI Server Node is a computer on which PI Server programs are installed. The PI Server
runs on the PI Server Node.

PI SMT
PI SMT refers to PI System Management Tools. PI SMT is the program that you use for
configuring PI Servers. A single copy of PI SMT manages multiple PI Servers. PI SMT runs
on either a PI Server Node or a PI Interface Node.

DNP 3.0 Interface x

 Pipc.log
The pipc.log file is the file to which OSIsoft applications write informational and error
messages. When a PI interface runs, it writes to the pipc.log file. The ICU allows easy
access to the pipc.log.

Point
The PI point is the basic building block for controlling data flow to and from the PI Server.
For a given timestamp, a PI point holds a single value.
A PI point does not necessarily correspond to a “point” on the foreign device. For example, a
single “point” on the foreign device can consist of a set point, a process value, an alarm limit,
and a discrete value. These four pieces of information require four separate PI points.

Service
A Service is a Windows program that runs without user interaction. A Service continues to
run after you have logged off from Windows. It has the ability to start up when the computer
itself starts up.
The ICU allows you to configure a PI interface to run as a Service.

Tag (Input Tag and Output Tag)

The tag attribute of a PI point is the name of the PI point. There is a one-to-one
correspondence between the name of a point and the point itself. Because of this relationship,
PI System documentation uses the terms “tag” and “point” interchangeably.
Interfaces read values from a device and write these values to an Input Tag. Interfaces use an
Output Tag to write a value to the device.

DNP 3.0 Interface xi

Chapter 1. Introduction

This document describes the use of the DNP 3.0 interface to the PI system, from here on
referred to as the PI DNP3 interface or DNP3 interface. The DNP3 interface supports the
DNP 3.0 Level 1 Master protocol for Polled Static and Polled Report-by-Exception data.
Additionally, the interface provides a subset of the DNP 3.0 Level 2 and Level 3 Master
protocol for requesting specific data from a DNP3 compliant device. The interface is also
capable of handling unsolicited messages from DNP 3.0 slave devices. Therefore, the sending
of unsolicited messages may be enabled in the slave devices. For a complete description of
this protocol, refer to the DNP Basic Four Documentation Set and the DNP V3.00 Subset
Definition, both of which are available from the DNP User’s Group at dnp.org.
DNP is designed for use in Supervisory Control and Data Access (SCADA) environments.
Beginning with version 3.0.1.0, the PI DNP3 interface is now capable of simultaneously
connecting to several hundred field devices that communicate using DNP 3.0. See the
Connectivity section of this manual for more details on connecting with RTU field devices.
The devices may be connected via TCP/IP, RS-232, or RS-485 directly. The interface is
designed to run as a service under the Windows NT or later operating systems.
The PI DNP3 interface functions solely as a master station and sends only the minimum
messages required for data retrieval. As a master station, the interface will not respond to any
data requests from other DNP master stations.
The DNP3 interface retrieves data by polling DNP 3.0 compliant devices using user-defined
scan classes or intervals or by receiving unsolicited data from the DNP3 compliant device.
The interface is capable of requesting data using the polled static and/or polled report by
exception methods. Polled static data, referred to as static data in this manual, includes DNP3
Class 0 data as well as object and variation specific data. Polled report by exception data
includes DNP3 Class 1, Class 2, and Class 3 data. This manual refers to polled report-by-
exception data as event data. Scanning for event data is the recommended method in order to
keep network traffic to a minimum. Moreover, requests for event data are a DNP3 Level 1
function and must be supported by all slave devices. A request for DNP3 Class 0 static data is
also required to be supported by all slaves. However, a static data request for a specific object
and variation is defined as a DNP3 Level 2 or Level 3 function and may or may not be
supported by the DNP3 slave device. Refer to the Device Profile Document section for
details describing DNP3 functionality supported by this interface.
The interface supports outputs to the Analog Output Block (Object 41). This interface
provides a means of freezing or freezing/clearing DNP3 Binary Counters (Object 20). The
user can freeze a counter by using two different methods. The first method uses an output PI
Point to send a request to freeze the counter by specifying the output value as being a DNP3
function request that will be sent to the DNP3 compliant device. The second method uses a
defined input PI Point associated with a specified scanclass that monitors the return value of
the freeze request sent to the device. PI Points require special attention when being defined

DNP 3.0 Interface 1

 for either method described above. Refer to the PI Point Configuration section of this manual
for details relating to configuring points of this object type.

Note: If you are upgrading from a previous version of the interface to 3.0.1.0, refer to
the Upgrading to Version 3.0.1.0 section of this manual before upgrading.

The recommended requirements for this interface are as follows:

 Windows XP/2003 Server or later to take advantage of the non-blocking socket
connection calls made to the RTU over TCP connection mediums.
 Processor and RAM as recommended by Microsoft for the operating system in
use.
 I/O medium specific ports. For example, to utilize RS-232 communication, an RS
232 port is required. For TCP/IP, a Network card is required. For RS 485, a RS
232 to RS 485 converter is required.
The minimum requirements for this interface are as follows:
 Windows XP.
 Processor and RAM as recommended by Microsoft for the operating system in
use.
 I/O medium specific ports. For example, to utilize RS-232 communication, an RS
232 port is required. For TCP/IP, a Network card is required. For RS 485, a RS
232 to RS 485 converter is required.

Note: These are only minimum requirements. Large configurations require a faster
computer and more RAM.

Note: The value of [PIHOME] variable for the 32-bit interface will depend on whether the
interface is being installed on a 32-bit operating system (C:\Program Files\PIPC) or
a 64-bit operating system (C:\Program Files (x86)\PIPC).
The value of [PIHOME64] variable for a 64-bit interface will be C:\Program Files\PIPC on
the 64-bit Operating system.
In this documentation [PIHOME] will be used to represent the value for either [PIHOME]
or [PIHOME64]. The value of [PIHOME] is the directory which is the common location for
PI client applications.

Note: Throughout this manual there are references to where messages are written
by the interface which is the PIPC.log. This interface has been built against UniInt
version (4.5.0.59 and later), which now writes all its messages to the local PI
Message log.

Please note that any place in this manual where it references PIPC.log should now
refer to the local PI message log. Please see the document UniInt Interface
Message Logging.docx in the %PIHOME%\Interfaces\UniInt directory for more
details on how to access these messages.

DNP 3.0 Interface 2

 Reference Manuals
OSIsoft
 PI Server manuals
 PI API Installation manual
 UniInt Interface User Manual

DNP
 DNP3 Specification. Data Link Layer
 DNP3 Specification, Application Layer
 DNP3 Specification, Transport Function
 DNP3 Specification, Object Library

Supported Features

Feature Support
Part Number PI-IN-OS-DNP3-NTI
* Platforms 32-bit Interface 64-bit Interface
Windows XP
32-bit OS Yes No
64-bit OS Yes (Emulation Mode) No
Windows 2003 Server
32-bit OS Yes No
64-bit OS Yes (Emulation Mode) No
Windows Vista
32-bit OS Yes No
64-bit OS Yes (Emulation Mode) No
Windows 2008
32-bit OS Yes No
Windows 2008 R2
64-bit OS Yes (Emulation Mode) No
Windows 7
32-bit OS Yes No
64-bit OS Yes (Emulation Mode) No
Auto Creates PI Points No
Point Builder Utility No
ICU Control Yes
PI Point Types int16, int32, float16, float32, digital, string
Sub-second Timestamps Yes
Sub-second Scan Classes Yes

DNP 3.0 Interface 3

Introduction

Feature Support
Automatically Incorporates PI Point Yes
Attribute Changes
Exception Reporting Yes
Outputs from PI Yes
Inputs to PI: Scan-based / Unsolicited / Scan-based / Unsolicited
Event Tags
Supports Questionable Bit Yes
Supports Multi-character PointSource Yes
Maximum Point Count None
* Uses PI SDK No
PINet String Support No
* Source of Timestamps PI Server or RTU
History Recovery No
UniInt-based Yes
* Disconnected Startup Yes
* SetDeviceStatus Yes
* Failover UniInt Failover (Phase 2); Hot and Cold
* Vendor Software Required on PI No
Interface Node / PINet Node
Vendor Software Required on Foreign No
Device
Vendor Hardware Required No
Additional PI Software Included with No
Interface
Device Point Types See Note.
Serial-Based Interface See Note

* See paragraphs below for further explanation.

Platforms
The Interface is designed to run on the above mentioned Microsoft Windows operating
systems and their associated service packs.
Please contact OSIsoft Technical Support for more information.

Uses PI SDK
The PI SDK and the PI API are bundled together and must be installed on each PI Interface
node. This Interface does not specifically make PI SDK calls.

Source of Timestamps
Scan-based data objects that do not contain a timestamp will always use the current PI Server
time.
There are several different methods for determining the timestamp of event data. Event type
data received from a RTU comes with a RTU 1 supplied timestamp. The XML file that
specifies RTU configuration includes two timing configuration nodes,
<TimeSource>type</TimeSource> and <TimeSync>freq:type</TimeSync>, to
detail how event data will be timestamped. The TimeSource node is used to identify the
4
 source of the timestamp for event data. There are three valid values that can be used in the
type parameter of this node; RTU, Adjusted, and PI. The TimeSync node determines if
the RTU time is synchronized with the PI Server time and whether the RTU time is
configured as local or UTC2 .
1 Remote Terminal Unit: Device used to control/monitor/record sensor results especially in
SCADA applications.
2 Coordinated Universal Time – (UTC, World Time) The standard time common to every
place in the world. UTC is derived from International Atomic Time (TAI) by the addition of a
whole number of “leap seconds.”
All values sent to the PI server will be timestamped with a UTC time. The freq parameter of
this node specifies how often the time on the RTU will be synchronized with the time from
the PI Server. If freq is defined to be zero, then the time on the RTU will never be
synchronized. If freq is greater than zero, then the RTU time will be synchronized when the
interface starts and every freq hours thereafter. The type parameter of the TimeSync node
informs the interface of whether the RTU is configured in local or in UTC time. The two
valid values for the type parameter are UTC and Local. Knowing if the RTU is configured
for UTC or Local serves two purposes. First, configuration informs the interface about what
time format must be sent to the RTU during time synchronizations. Second, it allows the
interface to correctly adjust the timestamp of event data received from the RTU.
The following table shows how the interface determines the adjustment of timestamps
received from event data generated by the RTU.
TimeSource TimeSync (type) Meaning
(type)
Data will be time-stamped with the
PI UTC or Local PI Server time at the instance the event
was received.
Data will be time-stamped with the raw
RTU UTC
RTU time with no adjustment.
Data will be time-stamped with the RTU
RTU* Local time offset by the difference between UTC
and Local Time.
Data will be time-stamped with the RTU
Adjusted UTC time offset by the difference between the
RTU time and the PI Server time.
Data will be time-stamped with the RTU
time offset by the difference between the
Adjusted* Local
RTU time and the PI Server time plus the
difference between UTC and Local Time.
* The calculation assumes the RTU and PI Server are in the same time zone and
have the same difference between Local Time and UTC.

UniInt-based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an
OSIsoft-developed template used by developers and is integrated into many interfaces,
including this interface. The purpose of UniInt is to keep a consistent feature set and behavior
across as many of OSIsoft’s interfaces as possible. It also allows for the very rapid
development of new interfaces. In any UniInt-based interface, the interface uses some of the
UniInt-supplied configuration parameters and some interface-specific parameters. UniInt is
constantly being upgraded with new options and features.

DNP 3.0 Interface 5

Introduction

The UniInt Interface User Manual is a supplement to this manual.

Disconnected Start-Up
The PI DNP 3.0 interface is built with a version of UniInt that supports disconnected start-up.
Disconnected start-up is the ability to start the interface without a connection to the PI server.
This functionality is enabled by adding /cachemode to the list of start-up parameters or by
enabling disconnected startup using the ICU. Refer to the UniInt Interface User Manual for
more details on UniInt Disconnect startup.

SetDeviceStatus
The DNP3 Interface supports health tags. The Device Status health tag has its point attribute
Exdesc set to [UI_DEVSTAT] and is used to represent the status of the source device. The
following events can be written into this tag:
 Good – the interface is communicating with all RTUs assigned to this interface.
 1 | Starting | UI x.x.x.x – the interface is starting.
 3 | n devices(s) in error | message – The number of RTUs operational. Moreover,
the RTU(s) in error are logged to the file listed by the message.
 4 | Intf Shutdown – the interface is shutting down.
Please refer to the UniInt Interface User Manual.doc file for more information on how to
configure health points.

Failover
UniInt Failover Support
UniInt Phase 2 Failover provides support for cold, warm, or hot failover configurations.
The Phase 2 hot failover results in a no data loss solution for bi-directional data transfer
between the PI Server and the Data Source given a single point of failure in the system
architecture similar to Phase 1. However, in warm and cold failover configurations, you
can expect a small period of data loss during a single point of failure transition. This
failover solution requires that two copies of the interface be installed on different
interface nodes collecting data simultaneously from a single data source. Phase 2
Failover requires each interface have access to a shared data file. Failover operation is
automatic and operates with no user interaction. Each interface participating in failover
has the ability to monitor and determine liveliness and failover status. To assist in
administering system operations, the ability to manually trigger failover to a desired
interface is also supported by the failover scheme.
The failover scheme is described in detail in the UniInt Interface User Manual, which is a
supplement to this manual. Details for configuring this Interface to use failover are
described in the UniInt Failover Configuration section of this manual.
This interface support UniInt Phase 2 Failover support for hot and cold failover.

Device Point Types

The DNP 3.0 specification provides for multiple types of data points. All these types are
explained in the DNP V3:00 Data Object Library document. The DNP Data Object Library
defines data types in terms of object type and variation. The object type is the basic or generic
type of data and the variation is the specific layout of that data. See sections PI Point
Configuration, and Location5, for a list of all supported DNP object types.
6
 Serial-Based Interface
Server class machines often have inferior serial ports. Server class machines are not required
for most interfaces and should not be used, especially not when serial port connections are
required.
This interface can run either with a serial connection, a connection using TCP/IP or both.
Server class machines often have inferior serial ports. Server class machines are not required
for most interfaces and should not be used, especially not when serial port connections are
required.

DNP 3.0 Interface 7

Introduction

Diagram of Hardware Connection

8
Chapter 2. Principles of Operation

The PI DNP3 interface is designed to operate as a DNP 3.0 compliant master device. The
interface acting as a master device is capable of communicating with one or more DNP 3.0
compliant slave devices (RTUs).
The DNP3 interface can make requests polled data as well as receive unsolicited data from a
DNP 3.0 compliant RTU. The DNP3 protocol defines static and event type data as being
retrieved by actively polling the RTU at periodic scan intervals. Whereas, unsolicited data
means the RTU will send messages to the interface on a non-solicited or event driven basis.
The interface is designed to make use of a configuration file to set up the internal operation of
the interface. The configuration file is written in XML format and is described in the Device
Configuration (XML) File section of this document.
The following sections describe the connectivity and types of data available with the use of
this interface. Details on how to configure PI tags for this interface can be found in the PI
Point Configuration section, as well as in the Sample PI Tag Configuration section, of this
manual.

Note: Users of the PI DNP3 interface prior to version 2.0.0.0 must update the
interface XML configuration file as specified in this manual.

Connectivity
The interface connects to RTU field devices via TCP/IP, RS-232, or RS-485 directly.
Moreover, the interface is capable of simultaneously connecting to several hundred field
devices that communicate using DNP 3. Exact numbers vary depending on scan frequency
and point count. OSIsoft has conducted field tests connecting nearly 400 devices and
scanning the devices once a minute for 40 values without issue.
The PI DNP3 interface uses a multi-threaded Window I/O Completion Port model for
communicating with DNP3 devices. This means that the interface does not wait for a
response from a request to a given RTU before sending a request to another RTU. The result
is a much more efficient interface that can communicate with many RTUs without affecting
performance of the main interface loop, which processes data from all connected RTUs and
updates the PI server.

DNP 3.0 Interface 9

 Data Handling
Data received from a connected RTU is processed via interface thread pools. The interface
makes use of an I/O thread pool and may optionally use a Worker thread pool in conjunction
with the I/O thread pool to process DNP3 packets. Details of each thread pool are described
below.

I/O Thread Pool

With the I/O completion port model, the interface uses a thread pool to manage I/O with the
connected RTU. By default, the thread pool size is two times the number of logical processors
on the interface node. For example, a two- processor computer will create 4 threads to
process I/O and a four-processor computer will create 8 threads. In general, the default thread
pool size should be sufficient for an interface with several connected RTUs. However, an
interface with several hundred RTUs may require a higher thread pool size. Therefore, a
/IOPool startup parameter has been included to allow the user to use the PI ICU to define a
specific thread pool size for the interface. Refer to the Startup Command File section of this
manual for additional details about how to configure this parameter. In a field test with nearly
500 connected RTUs, a thread pool size of 5 was more than sufficient to process 40 data
points from each of the connected field devices at a scan rate of once a minute.
The I/O thread pool is always used to retrieve data from the communication medium. The
same thread pool, by default, is used to parse and process the DNP3 message packet. The
processed packets are then passed to the main interface thread so the values can be sent to PI.
Alternatively, the user can specify the I/O thread pool to pass only the received message
packet or fragment to a Worker thread pool where parsing and processing of the DNP3 packet
takes place.

Worker Thread Pool

The default operation of the interface requires the use of a Worker thread pool consisting of a
single thread. However, there may be some interface configurations that might allow the
interface to perform better when a larger worker thread pool is used. For example, an
interface may be connected to dozens of RTUs that each have several thousand DNP3 objects
that are returned to the interface. Depending on the scan frequency, the processing period of
the received DNP3 packets from event or integrity scans can produce very large DNP3
messages when all the packets are reassembled to form a complete response. Using the
worker pool to do the reassembling and processing of the DNP3 message keeps the I/O thread
pool free to perform operations on the remaining connected RTUs; keeping the data flow to
PI constant. There is no set configuration as when to configure the worker thread pool for a
larger size and modifying the worker pool size should only be considered if the number of
RTUs assigned to the interface is greater than one or if interface does not appear to be
keeping up with requests.
To modify the Worker thread pool, use the PI ICU to set the /WorkerPool startup parameter
to the desired number of worker pool threads. Refer to the Startup Command File section of
this manual for additional details about how to configure this parameter.

DNP 3.0 Interface 10

 Static Data
In terms of DNP 3.0, static data is the current value of a data point at the time of the DNP
request. Therefore, the value received from a RTU for a static point during a scan is the
current value and will be time stamped with the current time of the PI server.
The static value of a data point can be retrieved by polling the RTU for Class 0 data or by
using a request for a specific object type, index number, and variation. The interface makes
the request for Class 0 data during what is referred to as an Integrity Scan. The Integrity Scan
causes the RTU to respond to the interface with a list of all of its events and the current value
of all of its points. The interface performs this type of scan at start-up or recovery from a
communications failure as well as a user defined frequency for each RTU.
Retrieving the static value of data points by polling for a specific object type, index number,
and variation will be made if there are PI tags configured for the PI DNP3 interface that are
not configured to be included in a scan class designated for event data. This type of data is
also referred to as non-Class 0 static data. Please refer to the description of the /event
parameter for a definition of an event scan class.
The PI DNP3 interface is capable of forming DNP 3.0 compliant request messages for non-
Class 0 static data by analyzing the configuration of a PI tag’s attributes. Each DNP request
for static data consists of the DNP Slave address (RTU address), the object type, the start and
stop index of the point(s) requested, and the object variation. Each scan class contains at least
one DNP request for a specific DNP address. For example, if there are six tags configured
with the PI tag attributes listed in the following table:
Tag Loc2 Loc3 Loc4 Loc5 InstrumentTag
(DNP (DNP (Scanclass) (Object Type) (Variation)
Index) Address)
AnlgPnt0 0 45 1 30 0
AnlgPnt4 4 45 1 30 0
CntrPnt0 0 45 1 20
CntrPnt7 7 45 1 20 0
CntrPnt23 23 45 1 20
BnryPnt4 4 45 1 1 0

During scans for this scan class, three DNP requests would be sent. The first one would be to
Slave address 45, Object Type 30 (Analog Input), Variation 0, Start Index 0, and Stop Index
4. The DNP Slave would respond with the current value of the Analog Input points 0 through
4 (5 points). The second request would be to Slave address 45, Object Type 20 (Counter),
Variation 0, Start Index 0 and Stop index 23. The DNP Slave would respond with the current
value of the Counter points 0 through 23 (24 points). The third request would be to Slave
address 45, Object Type 1 (Binary Input), Variation 0, Start Index 4 and Stop index 4. The
DNP Slave would respond with the current value of the Binary Input point 4 (1 point).
This information will help the user configure PI tags for efficient use of the network. If only
two analog inputs are required, index 2 and index 4750, and if they were both members of the
same scan class, a single request would be made to the RTU with a start index of 2 and a stop
index of 4750. The RTU would respond to this request with 4749 points worth of data. Not
only would all of the data have to be transmitted across the network, but the interface would
have to parse all of the data in order to retrieve only two values. A much more efficient use of
the network and the interface host machine’s resources could be used if the two points are
configured to use two different scan classes. If it is necessary to scan the two points at the
same scan rate, then two scan classes can be created with off-sets. It is highly recommended
DNP 3.0 Interface 11
Principles of Operation

to group requests to the same DNP device address that have PI points defined with identical
object types by their DNP index numbers, keeping index numbers as close together as
possible in the same scan-class.
Some of the example tags above have an empty string for the InstrumentTag value. An
empty InstrumentTag will lead the DNP3 interface to include a variation value of zero in
the request for data. A variation of zero returns the default variation supported on the RTU.
The variation can be included in the InstrumentTag and if a variation is found in the
InstrumentTag, then it will be included in the request to the DNP slave device. The DNP
slave device is not required to respond with the exact variation requested. Refer to the PI
Point Configuration section of this document for more detail about the use of the
InstrumentTag attribute.

Note: Polled values received from the DNP device that have associated PI points will
have the value either sent to the PI or discarded. A value is discarded if the value is
received for a scanclass that the tag does not belong. All integrity scans, event
scans, and unsolicited messages received from the DNP device will be sent to the
corresponding PI point regardless of the point assigned scanclass.

Event Type Data

The PI DNP3 interface considers an event to contain three attributes; information to identify
the point, a value, and the time the value changed. DNP events belong to one of four different
classes of data, 0, 1, 2, and 3. Events belonging to class 1 generally have a higher priority
than events in class 2, 3, or 0 and class 0 usually refers to the static value of the data points.
The DNP V3:00 Data Object Library (page 10-1) states “Class 0 data is potentially any
information object not assigned to class 1, 2, or 3. That is, class 0 data is non-priority data.”
An information object refers to an object that contains information to identify the point, the
new value, and the time (an event).
Scanning for event type data provides a much more efficient use of the network than scanning
for the static values. For example, an analog input type may change every 10 seconds. In
order for the interface to retrieve all of these changes, it would be necessary to scan for the
static value of the point at a rate higher than 10 seconds. However, this still does not ensure
all of the changes will be captured. It is much more efficient and the resolution of the data is
ensured if the interface is configured to scan for event data. A scan for event data can be made
once a minute or more and all of the changes will be sent to the PI server. The changes may
be filtered out through compression or exception reporting, but that is completely
configurable on a per-point basis. On the other end, if there is a tag that does not change
value very often, a request for the static value of the point every ten seconds is unnecessary in
order to get 10-second fidelity. Once again a scan for event data every minute will retrieve the
data and send to the archive the exact time the value changed without having to send a
request every 10 seconds.
The interface does not define event type points, rather it defines event type scan classes with
the /event=scanclass parameter in the start-up command file. The scanclass defines a
scan class that corresponds to a /f= flag from the start-up file and Location4 of the PI
tags. Every point in this scan class will be treated as an event type point. The DNP3 interface
will send two types of requests to a RTU regarding event type points.
The first type of request is an integrity scan. An integrity scan is a request for Class 1, 2, 3,
and 0 data (in that order). The RTU will respond to this type of scan will all of its events first

12
 and then a list of all of its points with their current value. The result of the integrity scan will
be to update all of the PI tags to their current DNP value. The integrity scan will be performed
at start-up, recovery from a communications failure, and at a rate that is configured by the
<IntegrityScan> node defined in the RTU XML configuration file.
The second type of request the interface will send is an event scan request. The event scan
will be sent at the rate specified by the scan class. An event scan is a request for all Class 1, 2,
and 3 data from the RTU. The RTU will respond to an event scan with a list of the events that
have taken place since the last event or integrity scan. Some RTUs define events in different
manners. A change in an analog input tag from 1000 to 1010 may constitute a class 1 event in
one implementation and not in another. To account for variations in RTU configurations and
to prevent data loss, the DNP3 interface requests all Class 1, 2, and 3 data from all the RTUs
assigned to an event class. Take care when assigning the /event parameter to a scan class.
The scan rate assigned to the /event parameter must not be so long as to let the RTU’s
buffer fill with data. Refer to the documentation for the specific RTU to determine what
constitutes an event, and how long it will take before the RTU buffer becomes full.

Note: Event scans will only be made at one scan rate per RTU. If a RTU is
configured with points in two scan classes and both scan classes are configured to
be an event class, the interface will send a request for event data at the smallest of
the two scan class frequencies. All the RTU events will be returned as a result of an
event scan. It does not make sense to ask for events at a rate of 10 seconds and
also at a rate of 1 minute.

Unsolicited Data
Similar to the Event Type Data described above, unsolicited data also contains three
attributes; information to identify the point, a value, and the time the value changed. The
unsolicited data belongs to one of three different classes of data; class 1, 2, or 3. Events
belonging to class 1 generally have a higher priority than events in class 2, or 3.
Configuring the interface to receive unsolicited data from an RTU eliminates the need to poll
for events at a regular basis. Moreover, unsolicited data will be sent to the interface as the
RTU deems necessary.
The interface can be configured to request and receive unsolicited data by modifying the xml
configuration file for the interface. See the Device Configuration (XML) File section for
details about configuring the xml file.

Note: Consider increasing the ReadTimeout attribute of the Device Configuration

(XML) File when the interface is configured to received unsolicited data. An
increased ReadTimeout may be necessary when the RTU sends unsolicted events
at a rate which is faster than data that is scanned due to the priority of servicing
unsolicited data before solicited data is serviced. Failure to increase the
ReadTimeout could result in Data Link or Application Layer retries or the interface or
exceedign the ReadTimeout; which would inform the interface to reset the link of the
RTU.

DNP 3.0 Interface 13

Principles of Operation

Note: The enabling of an RTU to send unsolicited data that is configured to share
the same IOGroup as defined in the xml configuration file is not recommended due
to possible data collisions.

Note: Take care to ensure “IO Timeout” is not erroneously writing to PI tags when
the interface is configured to receive only unsolicited data from an RTU. Make sure
the /IOTimeout startup command line parameter is set to zero or a value greater
than the expected interval between unsolicited data. Failure to do so may result in
“IO Timeout” being written to PI tags because no unsolicited data has been received
from the RTU in the maximum period set by the parameter. If the RTU infrequently
sends unsolicited data, then the interface should be configured to request and
integrity poll on a regular basis and the /IOTimeout parameter should be set to a
value greater than the integrity poll interval to ensure that the interface can detect a
communication error if the integrity scan fails to return valid results.

Status Data
For every point of DNP data, there may be an associated status flag. If a RTU supports status
flags for a particular point of data, then status data can be stored in PI via the interface. The
bits of the flag specify different conditions for different object types. The status flag
encompasses bits 4 – 7 and each bit of the flag specifies different conditions for different
object types. The value of the status bits are either 0 or 1, where a 1 means the flag is set.
Refer to the DNP V3:00 Data Object Library manual to determine which flag is appropriate
for an object type. To configure a PI tag to monitor the status of a DNP point, configure the
tag the same as the value tag and set Location5 of the point to the negative of the DNP
object type. The DNP3 interface will write an integer value to the status tag. This integer
value will be the decimal value of the bit pattern received from the DNP device and its value
will range from 0 to 128. To easily determine the status of an object from its decimal value,
OSIsoft has included .csv files that can be used to create digital state sets with the interface
installation package. If the status tags are configured as a “digital” type PI tags, the
digitalset attribute can be used to point to the appropriate digital state set. This converts
the value of the status bit to a human readable string.

Questionable Data
If the RTU responds to static or event data with an object variation that includes the object’s
status, the interface can determine if the value received from the RTU is of questionable
validity. If the data received is questionable, then the questionable bit will be set for the value
of the object sent to the PI tag. Data is considered questionable if the status for an object type
indicates one or more of the following conditions.

Binary Input Data

 Off-line – The state of the digital point may not be correct.

 Restart – Indicates that the field device has been restarted.

14
  Communications Lost – The device reporting this object has lost communication
with the originating device.
 Chatter Filter – Indicates that the binary input point has been filtered in order to
remove unneeded transitions in the state of the point.

Binary Output Data

 Restart – Indicates that the field device has been restarted.

 Communications Lost – The device reporting this object has lost communication
with the originating device.

Analog Input/Output Data

 Off-line – The state of the digital point may not be correct

 Restart – Indicates that the field device has been restarted
 Communications Lost – The device reporting this object has lost communication
with the originating device.
 Over Range – Indicates that the digitized signal or calculation has exceeded the
positive or negative range of the value. The actual value of the tag will be the
maximum value for the size of the data if the value is positive or the minimum
value for the data if the value is negative.
 Reference Check – Indicates that the reference signal used to digitize the analog
input is not stable and the resulting digitized value may not be correct.

Octet String Data

The interface is capable of requesting Octet String Static and Event data as described below.
 Object 110, Variation 1-255, Octet String Static. The variation used with an Octet
String is the length of the string. A response may contain a variation smaller
than requested if the available string length is shorter than what was requested.
Octet String objects are not included in class 0 polls.
 Object 111, Variation 1-255, Octet String Event. The variation used with an Octet
String is the length of the string. A response may contain a variation smaller
than requested if the available string length is shorter than what was requested.
It is recommended to use a variation of 255 when creating PI tags to read an Octet String in
order to read the maximum size of an Octet String. If the size of the Octet String received
from the RTU is less than 255, the length of the Octet String stored in PI will reflect the
smaller size.
PI tags for Octet Strings may be defined as PI string or blob types. PI blob types will always
contains the entire Octet String received from the RTU. PI string types will contain the entire
Octet String received from the RTU as long as the Octet String does not contain a null(0x00)
character. If the Octet String contains one or more null(0x00) characters, the PI string will
truncate the Octet String at the first null character found in the Octet String.
Example:
DNP 3.0 Interface 15
Principles of Operation

Recived Octet String = {0x01,0x02,0x03,0x04,0x00,0x06,0x07,0x00,0x09}. Length = 9

Value in PI blob = {0x01,0x02,0x03,0x04,0x00,0x06,0x07,0x00,0x09}. Length = 9
Value PI string = {0x01,0x02,0x03,0x04}. Length = 4

Time and Date

The interface provides a means to retrieve the time and date from a connected RTU. The time
and date object can be used as a heartbeat tag to determine liveliness of the interface and its
connected RTU(s). The user can define a time and date tag by setting the Location5
attribute equal to the DNP3 object number 50. This tag can provide either a string
representation of the RTU time (given in UTC) or the tag can be defined to provide an integer
value representing the number of seconds elapsed since midnight January 1, 1970. Refer to
the PI Point Configuration and Startup Command File sections of this manual for additional
details relating to interface setup and operation. Only one tag for the time and date per RTU
can be defined.

Heartbeat Tags
The interface has the capability to monitor the heartbeat (liveliness) of the interface and its
connected RTU(s). Refer to the PI Point Configuration and Sample PI Tag Configurations
sections of this manual for additional details relating to heartbeat tag configuration and
operation. Only one tag to monitor the interface heartbeat can be defined. Likewise, only one
tag per RTU can be defined to monitor the RTU heartbeat.

Interface

The interface heartbeat tag, if defined, is updated once a second and cycles from a value of 1
to 60 during normal operation. If the interface is gracefully shutdown, the value of the
interface heartbeat tag is set to the Intf Shut digital state.

Note: If the interface heartbeat is flat-lined for an extended period of time, the
interface may need to be restarted.

RTU

The RTU heartbeat tag, if defined, is updated once a second and cycles from a value of 1 to
60 during normal operation. If the interface is gracefully shutdown, the value of the RTU
heartbeat tag is set to 0.
If the RTU is deemed to be in a state that requires its link to be reset, the associated heartbeat
tag is set to the Unit Down digital state. For a TCP connection, the interface puts the RTU in
a needs link reset state when the there is no valid socket connection established to the RTU.
For a serial connection, the needs reset link state is determined if the serial port is in a fault
state or if the RTU does not respond to requests from the interface in the allotted amount of
time specified for the RTU.

16
 RTU Status Information
The interface monitors the connection status of all assigned RTUs. Once every 10 seconds the
interface checks all assigned RTUs to see if any RTU requires its link to be reset. If an RTU is
found in need of resetting, the address of the RTU is logged to a .csv file for analysis. The
device status log is very useful to determine which field device(s) are in trouble. If the
interface utilizes the Device Status health point as described in the UniInt Interface User
Manual, the interface will send the device status tag a message containing the count of RTUs
in error and also include the path to the interface device status log file in the message.
The naming convention for the device status log file is exename_devstat_id.csv, where
exename is the name of the interface executable file and id is the interface identification.
For example, an executable file named pidnp3 with an id of 200 has a device status log file of
pidnp3_devstat_200.csv. The device status log is placed in the /devstat subdirectory
of the interface executable directory. The maximum size of the device status log is
approximately 100KB and then the file will be cleared for new data. By default, the device
status log will be created. If no device status log is desired, use the /NoDevStatLog startup
command parameter to disable logging.

Reset Link Counter Tag

Each RTU must have its link reset before the interface can request data from the RTU.
Moreover, if the connection to the RTU is lost, the link to the RTU must be reset upon
reestablishment of a connection to the RTU. Additionally, an RTU connected via serial will
require a reset if the RTU fails to respond to interface requests.
To help determine how often a RTU is being reset, the interface includes a reset counter tag
that will store the value of reset link requests sent to the interface. For example, when using a
cellular architecture to communicate with a field RTU, this tag can help identify an RTU that
is having communications issues and even help determine the time of day communication
issues with a particular device is more apparent.
The tag is updated by default once a minute and the value contains the number of reset
request sent to the interface during that last one minute period and then the value is reset to
zero. The update period for the tag is configurable from a minimum of once a minute to a
maximum of once an hour. Refer the PI Point Configuration section of this manual for
additional configuration details for this tag.

DNP3 Internal Indication (IIN) Tags

The interface provides a means of monitoring the Internal Indications of a DNP3 Compliant
RTU. The user can define PI tags to monitor each of the internal indicators of the RTU. See
the PI Point Configuration section of this manual for details about configuring such tags. The
table below shows the available indicators that can be monitored by the interface.

DNP 3.0 Interface 17

Principles of Operation

Internal Indication (IIN)

ALL Stations
All stations message received.
Set when a request is received with the destination address of the all stations address
(0xFFFF hexadecimal).
Cleared after next response (even if response to global request is required).
Used to let the master station know that a Broadcasted message was received by this station.
Class 1 data available
Set when data that has been configured as Class 1 data is ready to be sent to the master.
Master station should request this class data from the Outstation when this bit is set in a
response.
Class 2 data available
Set when data that has been configured as Class 2 data is ready to be sent to the master
Master station should request this class data from the Outstation when this bit is set in a
response
Class 3 data available
Set when data that has been configured as Class 3 data is ready to be sent to the master
Master station should request this class data from the Outstation when this bit is set in a
response
Need Time
Time-synchronization required from the master. The master synchronizes the time by writing
the Time and Date object to the Outstation.
Cleared when the time is set by the master. This bit is also cleared when the master explicitly
writes a 0 into this bit of the Internal Indication object of the Outstation.
Local
Set when some or all of the Outstation’s digital output points are in the Local state. That is, the
Outstation’s control outputs are NOT accessible through the DNP protocol.
Clear when the Outstation is in the Remote state. That is, the Outstation’s control outputs are
accessible through the DNP protocol.
Device Trouble
Set when an abnormal condition exists at the Outstation. The device profile for a given device
states the conditions that affect this bit.
This should only be used when the state cannot be described by a combination of one or
more of the other IIN bits.
Device Restart
Set when the user application at the Outstation restarts.
Cleared when the master explicitly writes a 0 into this bit of the Internal Indications object in
the Outstation.
Bad Function
Function code not implemented
Unknown Object
Requested object(s) unknown. The Outstation does not have the specified objects or there are
no objects assigned to the requested class.
This indication should be used for debugging purposes and usually indicates a mismatch in
device profiles or configuration problems.
Out of Range
Parameters in the qualifier range or data fields are not valid or out of range. This is a catch-all
for application request formatting errors.
This indication should be used for debugging purposes and usually indicates configuration
problems.

18
 Internal Indication (IIN)
Buffer Overflow
Event buffer(s), or other application buffers have overflowed. For example, COS/SOE buffers
have overflowed.
The master should attempt to recover as much data as possible and indicate to the user that
there may be lost data. The appropriate error recovery procedures should be initiated by the
user.
Already Executing
Request understood but requested operation is already executing.
Bad Configuration
Set to indicate that the current configuration in the Outstation is corrupt and that the master
application layer should inform the user of this exception. The master may download another
configuration to the Outstation.
Note that sometimes a corrupt configuration will disable an Outstation, making it impossible to
communicate this condition to a master station.

Outputs

Analog Output Block

The interface supports outputs to the Analog Output Block (Object 41). The output values
from PI are used to set the Block values for these DNP3 types. These PI Points require
special attention when being defined and utilize the userint2 attribute to specify the requested
DNP3 function. Refer to the PI Point Configuration section of this manual for details relating
to configuring points of these types.

Counters

Freezing/Clearing Counters

This version of the interface provides a means of freezing or freezing/clearing DNP3 Binary
Counters (Object 20). The user can use either an output point to freeze counters on demand or
an input point to freeze counters as determined by the rate defined by a scan class. When
using an output point, the output value of the point specifies they type of freeze request sent
to the DNP3 compliant device. Freezing and/or clearing counters using a specified scan rate
can be accomplished using input PI points. The input point monitors the return status of the
freeze request sent to the device. These PI Points require special attention when being defined
and use the Location2 and userint1 to specify the object index to freeze. Refer to the PI
Point Configuration section of this manual for details relating to configuring points of this
type. The following table shows the meaning of an output value as it relates to a specific
freeze request.
Output Value Meaning
0 This function code, Immediate Freeze, is used to copy the
specified data objects to a freeze buffer. Upon reception of the
message, the Outstation should copy the current values of the
specified data objects to their appropriate freeze buffers. The
objects which were frozen can be requested (in another
request) by asking for frozen objects.

DNP 3.0 Interface 19

Principles of Operation

Output Value Meaning

1 This function code, Immediate Freeze No Ack., works
identically to the previous function code (Immediate Freeze)
except that no Outstation response is needed. Typically, this
function code is used to perform a global freeze on all
Outstations belonging to the master. In this case, the SEND-
NO REPLY services of the Data Link Layer may have to be
used in certain environments.
2 This function code, Freeze and Clear, is used to copy the
specified data to a freeze buffer like the immediate freeze
function code but then the Outstation clears to 0 the specified
data objects. Typically, this function code is used to freeze
counters or accumulators and then reset them to 0.
3 This function code, Freeze and Clear No Ack., works
identically to the previous function code (Freeze and Clear)
except that no Outstation response is needed. Typically, this
function code is used to perform a global freeze and clear on
all Outstations belonging to the master.

DNP and other Debugging messages

The PI DNP3 interface can send the incoming and outgoing DNP messages to the console
window (if running interactively) and/or to a log file. The DNP messages are written to a log
file that is separate from the PIPC.log file. This log file is referred to as the RTU log file
and the name of the log will be PIDNP3_ps_id_n.log where ps is pointsource of the
interface instance, id is the interface identification, and n is the DNP address of the RTU.
The output of these messages is controlled by the /dnpdbg=level parameter in the start-up
command file. The level is a 16-bit integer value that is expressed as a series of four
hexadecimal numbers. Each bit of the debug flag turns on and off debugging in a different
section of the interface. For example, the least significant bit (the far right bit) is the bit that
turns on and off writing the raw messages to the RTU log file. So, to turn on the logging of
these messages, the /dnpdbg parameter must be set to /dnpdbg=0x0001. The next bit to the
left controls the writing of Data Link Layer descriptions of the message to the RTU log file.
So, to turn on the logging of the Data Link Layer descriptions, the /dnpdbg parameter must
be set to /dnpdbg=0x0002. Each of the four hexadecimal digits represents 4 bits. From left
to right, the 1st bit’s value is 8, the 2nd bit’s value is 4, the 3rd bit’s value is 2 and the least
significant bit’s value is 1. To turn on multiple flags, add the value of the flags. For example,
to turn on both the logging of the raw messages and the Data Link Layer explanations, the
parameter must be set to /dnpdbg=0x0003. The 0x preceding the numbers in the above
example denote the number is expressed as a hexadecimal number. The parameter can also be
represented as a decimal number. The hexadecimal number 0x77 is equal to 119 in decimal.
Therefore, the two parameters /dnpdbg=0x0077 and /dnpdbg=119 are equivalent.
Although the two are equivalent and they will both work, OSIsoft recommends using the
hexadecimal version because it is easier for humans to determine which bits are set to 1. The
following table provides a list of debug bit values and what they control. For each bit, setting
the bit to 1 will turn on that section of debugging messages and setting the bit to 0 will turn
them off.

Note: The debug messages are intended only for debugging. There is no
mechanism for removing old RTU log files. If the debug messages are left on, the log
files will become large and unmanageable in a short period of time.

20
 Bit Position Hex Value Decimal What the bit turns on and off
(right to left) Value
1 0x0001 1 Raw messages written to RTU log file
2 0x0002 2 Description of Data Link Layer written to the RTU log
File
3 0x0004 4 Description of Transport Layer written to the RTU log
File
4 0x0008 8 Description of Application Layer written to the RTU
log File
5 0x0010 16 Raw messages written to the console window
6 0x0020 32 Description of Data Link Layer written to the console
window
7 0x0040 64 Description of Transport Layer written to the console
window
8 0x0080 128 Description of Application Layer written to the
console window
9 0x0100 256 Start Up Procedures
10 0x0200 512 Load PI Tag Procedures
11 0x0400 1024 Data Sent to PI (not including Heartbeat Tags)
12 0x0800 2048 Scanning for Current Values
13 0x1000 4096 Communications Medium
14 0x2000 8192 Scaled Value

Tag Level Debugging for Received Values

The PI DNP3 interface can log the received DNP values for a specific tag to the console
window (if running interactively) and/or to a log file. To do this, set the location3 to the
negative DNP address of the device to log the value received from the RTU to the message
log. Set the DNP address back to the positive DNP address to disable logging.
Example: for a RTU with address 4, set location3=-4 to log the value received from the
RTU to the message.

Note: Polled values received from the DNP device that have associated PI points will
have the value either sent to the PI or discarded. A value is discarded if the value is
received for a scanclass that the tag does not belong. All integrity scans, event
scans, and unsolicited messages received from the DNP device will be sent to the
corresponding PI point regardless of the point assigned scanclass.

Below is an example of the two types of messages written to the message log.

18-Nov-11 09:55:13
PIDNP3 1> INFO> (Point ID = 50335)> TMW_D4_AI_0
RTU Name: Capacitor #4, Address: 4
Value to PI API: 200.033, Time: 18-Nov-11 14:55:13.3830, istat: 0, Tag Scanclass: 1, Value Scanclass: 1

18-Nov-11 09:55:13
PIDNP3 1> INFO> (Point ID = 38956)> TMW_D4_AI_1
RTU Name: Capacitor #4, Address: 4
Discarding Value: 198.274, Time: 18-Nov-11 14:55:13.3830, istat: 0, Tag Scanclass: Unsolicited, Value Scanclass: 1

DNP 3.0 Interface 21

Principles of Operation

UniInt Phase 2 Failover

Cold Configuration

In the cold failover configuration, each interface in the failover configuration will use an
identical Device Configuration (XML) File that contains information on how to connect to
the DNP3 Slave RTU.
Below is an example of a typical UniInt Cold Failover Configuration.

Hot Configuration

In the hot failover configuration, there must be two redundant RTUs available. Each RTU
must have the same DNP3 Slave address, but communicate on different ports. Each interface
in the failover configuration will use a Device Configuration (XML) File that contains
information on how to connect to the DNP3 Slave RTU assigned to that particular interface
instance.
Each RTU must contain redundant/identical data. Moreover, each RTU responds to requests
from its corresponding PI DNP3 interface master. This allows for both interface instances in

22
 the configuration to collect identical data and in turn allows for the RTU to clear its event
buffers after servicing requests from its master.
Below is an example of a typical UniInt Hot Failover Configuration.

DNP 3.0 Interface 23

Chapter 3. Upgrading to Version 3.0.1.0 or Later

PI Point Configuration
When upgrading from a version of the PI DNP3 Interface prior to 3.0.1.0, the following
changes to the point configuration must take place in order to ensure proper operation. These
changes are required to accommodate future changes in the DNP3 Specification. See the PI
Point Configuration and Sample PI Tag Configurations sections of this document for details
concerning all point attribute information.

Heartbeat Tags

Add the value HEARTBEAT to the InstrumentTag as shown in the following heartbeat
tags.
Version 2.2.0.10 and earlier: InstrumentTag is blank
Version 3.0.1.0 and later: InstrumentTag = HEARTBEAT

Interface Heartbeat (non-UniInt health tag)

Tag: Interface_Heartbeat
Location1 = ID
Location2 = 0
Location3 = 0
Location4 = N/A
Location5 = 0
InstrumentTag = HEARTBEAT

RTU
Tag: RTU_Heartbeat
Location1 = ID
Location2 = 0
Location3 = DNP Slave Address
Location4 = N/A
Location5 = 0
InstrumentTag = HEARTBEAT

DNP 3.0 Interface 25

 DNP3 Internal Indication (IIN) Tags (Object 80)

Change the value of the Location5 attribute to a value of 80.

Version 2.2.0.10 and earlier: Location5 = 0
Version 3.0.1.0 and later: Location5 = 80
Tag: IIN_Name (see table in PI Point Configuration, in section Location2)
Location1 = ID
Location2 = Indicator_Name See DNP3 Internal Indications (IIN) section.
Location3 = DNP Slave Address
Location4 = 0
Location5 = 80

Counter Freeze Request Tags (Object 20)

Change the Location5 equal 120 to Location5 equal 20.

Version 2.2.0.10 and earlier: Location5 = 120
Version 3.0.1.0 and later: Location5 = 20
Add the value FREEZE to the InstrumentTag as shown in the following freeze request
tags.
Version 2.2.0.10 and earlier: InstrumentTag is blank
Version 3.0.1.0 and later: InstrumentTag = FREEZE

Counter Freeze Tag (Output)

When defining an output tag to be used in freezing and/or clearing all counters, the following
attributes must be defined.
Tag: Freeze_All_Tags
Location1 = ID
Location2 = Don’t Care
Location3 = DNP Slave Address
Location4 = 0
Location5 = 20
InstrumentTag = FREEZE
UserInt1 = -1 See Sample PI Tag Configurations section.
PointType = int32 or digital
SourceTag = Tag that the output value comes from. See Freezing/Clearing Counters
section for required value.

DNP 3.0 Interface 26

 Counter Freeze Tag (Input)
When defining an input tag to be used in freezing and/or clearing all counters, the following
attributes must be defined
Tag: Freeze_All_Tags
Location1 = ID
Location2 = Don’t Care
Location3 = DNP Slave Address
Location4 = Scanclass (cannot be an event scanclass. Zero if unsolicited.
Location5 = 20
InstrumentTag = FREEZE
UserInt1 = -1 See Sample PI Tag Configurations section.
UserInt2 = type of freeze being requested. See Sample PI Tag Configurations section.
DigitalSet = DNP_FreezeCodes
PointType = Digital

Digital State Sets

For users who are upgrading from a version of the PI DNP3 Interface prior to 3.0.1.0, note
that the following changes were made to the digital state sets included with the interface
installation kit. Previous versions of the interface included .txt files to be used with the
piconfig utility to create the digital state sets on the PI server. Version 3.0.1.0 has removed
the .txt files used with the piconfig utility and replaced them with .csv files that can be
imported by PI SMT to create DNP3-specific digital state sets. See the DNP3 Specific Digital
State Sets section for details concerning digital state set information.
The included files are:
 DigitalSet_DNP_AnalogStatus.csv

 DigitalSet_DNP_BinaryStatus.csv

 DigitalSet_DNP_CounterStatus.csv

 DigitalSet_DNP_DoubleBit.csv

 DigitalSet_DNP_FreezeCodes.csv
Current users should note that the old piconfig files contained separate state sets for
Analog Input and Analog Output status as well as separate state sets for Binary Input and
Binary Output status. These state sets have now been combined into a single Analog status
file and single Binary status file respectively. Moreover, the OutputStatus.txt
piconfig file has been removed to allow users to use the AnalogStatus or BinaryStatus set
as appropriate. There is no requirement for current interface users to modify the digital state
set being currently used by PI points.

DNP 3.0 Interface 27

Upgrading to Version 3.0.1.0 or Later

If a current user wants to convert digital PI tags from the old to new digital state set, the
following changes must be made.
Old piconfig .txt file New PI SMT .csv file Change in states
AnalogInputStatus.txt DigitalSet_DNP_AnalogStatus.csv None
AnalogOutputStatus.txt DigitalSet_DNP_AnalogStatus.csv Additional states
available in new
.csv file. The state
value indices
available in the .txt
file are the same in
the new .csv file.
BinaryInputStatus.txt DigitalSet_DNP_BinaryStatus.csv No change.
CounterStatus.txt DigitalSet_DNP_CounterStatus.csv No change.
FreezeFunctionCodes.txt DigitalSet_DNP_FreezeCodes.csv No change.
OutputStatus.txt (for DigitalSet_DNP_AnalogStatus.csv Additional states
Analog objects) available in new
.csv file. The state
value indices
available in the .txt
file are the same in
the new .csv file.
OutputStatus.txt (for DigitalSet_DNP_BinaryStatus.csv This state set
Binary objects) corresponds with
the DNP3 protocol
for Binary objects.
Note: the interface
does not support
binary outputs at
this time.
N/A DigitalSet_DNP_DoubleBit.csv This is a new set.

28
Chapter 4. Installation Checklist

If you are familiar with running PI data collection interface programs, this checklist helps you
get the Interface running. If you are not familiar with PI interfaces, return to this section after
reading the rest of the manual in detail.
This checklist summarizes the steps for installing this Interface. You need not perform a given
task if you have already done so as part of the installation of another interface. For example,
you only have to configure one instance of Buffering for every Interface Node regardless of
how many interfaces run on that node.
The Data Collection Steps below are required. Interface Diagnostics and Advanced Interface
Features are optional.

Data Collection Steps

1. Confirm that you can use PI SMT to configure the PI Server. You need not run PI
SMT on the same computer on which you run this Interface.
2. If you are running the Interface on an Interface Node, edit the PI Server’s Trust Table
to allow the Interface to write data.
3. Run the installation kit for the PI Interface Configuration Utility (ICU) on the
interface node if the ICU will be used to configure the interface. This kit runs the PI
SDK installation kit, which installs both the PI API and the PI SDK.
4. Run the installation kit for this Interface. This kit also runs the PI SDK installation kit
which installs both the PI API and the PI SDK if necessary.
5. If you are running the Interface on an Interface Node, check the computer’s time
zone properties. An improper time zone configuration can cause the PI Server to
reject the data that this Interface writes.
6. Run the ICU and configure a new instance of this Interface. Essential startup
parameters for this Interface are:
Point Source (/PS=x)
Interface ID (/ID=#)
PI Server (/Host=host:port)
Scan Class(/F=##:##:##,offset)
XML Configuration File (/xml=<UNC Path>)

Note: Users of the PI DNP3 interface prior to version 2.0.0.0 must modify the
interface XML configuration file to the format indicated in the Device Configuration
(XML) File section of this manual.

DNP 3.0 Interface 29

 7. Use the Connection Tool to confirm connection between the Interface Node and the
device.
8. If you will use digital points, define the appropriate digital state sets as describe in
this manual in the section DNP3 Specific Digital State Sets.
9. Build input tags and, if desired, output tags for this Interface. Important point
attributes and their purposes are:
Location1 specifies the Interface instance ID.
Location2 is the DNP list index number of the point.
Location3 is the DNP address of the device.
Location4 specifies the scan class.
Location5 is the DNP Object type.
InstrumentTag is the specific variation of the DNP Object type (default is 0)
10. Start the Interface interactively and confirm its successful connection to the PI Server
without buffering.
11. Confirm that the Interface collects data successfully.
12. Stop the Interface and configure a buffering application (either Bufserv or PIBufss).
When configuring buffering use the ICU menu item Tools  Buffering… 
Buffering Settings to make a change to the default value (32678) for the Primary and
Secondary Memory Buffer Size (Bytes) to 2000000. This will optimize the
throughput for buffering and is recommended by OSIsoft.
13. Start the buffering application and the Interface. Confirm that the Interface works
together with the buffering application by either physically removing the connection
between the Interface Node and the PI Server Node or by stopping the PI Server.
14. Configure the Interface to run as a Service. Confirm that the Interface runs properly
as a Service.
15. Restart the Interface Node and confirm that the Interface and the buffering
application restart.

Interface Diagnostics
16. Configure Scan Class Performance points.
17. Install the PI Performance Monitor Interface (Full Version only) on the Interface
Node.
18. Configure Performance Counter points.
19. Configure UniInt Health Monitoring points
20. Configure the I/O Rate point.
21. Install and configure the Interface Status Utility on the PI Server Node.
22. Configure the Interface Status point.

DNP 3.0 Interface 30

 Advanced Interface Features
1. Configure the interface for Disconnected Startup. Refer to section Disconnected
Startup in this manual and the UniInt Interface User Manual for more details on
UniInt Disconnect startup.

DNP 3.0 Interface 31

Chapter 5. Interface Installation

OSIsoft recommends that interfaces be installed on PI Interface Nodes instead of directly on

the PI Server node. A PI Interface Node is any node other than the PI Server node where the
PI Application Programming Interface (PI API) is installed (see the PI API manual). With this
approach, the PI Server need not compete with interfaces for the machine’s resources. The
primary function of the PI Server is to archive data and to service clients that request data.
After the interface has been installed and tested, Buffering should be enabled on the PI
Interface Node. Buffering refers to either PI API Buffer Server (Bufserv) or the PI Buffer
Subsystem (PIBufss). For more information about Buffering see the Buffering section of this
manual.
In most cases, interfaces on PI Interface Nodes should be installed as automatic services.
Services keep running after the user logs off. Automatic services automatically restart when
the computer is restarted, which is useful in the event of a power failure.
The guidelines are different if an interface is installed on the PI Server node. In this case, the
typical procedure is to install the PI Server as an automatic service and install the interface as
an automatic service that depends on the PI Update Manager and PI Network Manager
services. This typical scenario assumes that Buffering is not enabled on the PI Server node.
Bufserv can be enabled on the PI Server node so that interfaces on the PI Server node do not
need to be started and stopped in conjunction with PI, but it is not standard practice to enable
buffering on the PI Server node. The PI Buffer Subsystem can also be installed on the PI
Server. See the UniInt Interface User Manual for special procedural information.

Naming Conventions and Requirements

In the installation procedure below, it is assumed that the name of the interface executable is
PIDNP3.exe and that the startup command file is called PIDNP3.bat.

When Configuring the Interface Manually

It is customary for the user to rename the executable and the startup command file when
multiple copies of the interface are run. For example, PIDNP31.exe and PIDNP31.bat
would typically be used for interface number 1, PIDNP32.exe and PIDNP32.bat for
interface number 2, and so on. When an interface is run as a service, the executable and the
command file must have the same root name because the service looks for its command-line
parameters in a file that has the same root name.

DNP 3.0 Interface 33

 Interface Directories

PIHOME Directory Tree

The [PIHOME] directory tree is defined by the PIHOME entry in the pipc.ini configuration
file. This pipc.ini file is an ASCII text file, which is located in the %windir% directory.
For 32-bit operating systems, a typical pipc.ini file contains the following lines:
[PIPC]
PIHOME=C:\Program Files\PIPC
The above lines define the root of the PIHOME directory on the C: drive. The PIHOME
directory does not need to be on the C: drive. OSIsoft recommends using the paths shown
above as the root PIHOME directory name.

Interface Installation Directory

The interface install kit will automatically install the interface to:
PIHOME\Interfaces\PIDNP3\
PIHOME is defined in the pipc.ini file.

Interface Installation Procedure

The PI DNP3 Interface setup program uses the services of the Microsoft Windows Installer.
Windows Installer is a standard part of Windows 2000 and later operating systems. To install,
run the appropriate installation kit.
DNP3_#.#.#.#_.exe

Installing Interface as a Windows Service

The PI DNP3 Interface service can be created, preferably, with the
PI Interface Configuration Utility, or can be created manually.

DNP 3.0 Interface 34

 Installing Interface Service with PI Interface Configuration Utility
The PI Interface Configuration Utility provides a user interface for creating, editing, and
deleting the interface service:

Service Configuration

Service name
The Service name box shows the name of the current interface service. This service name is
obtained from the interface executable.

ID
This is the service id used to distinguish multiple instances of the same interface using the
same executable.

Display name
The Display Name text box shows the current Display Name of the interface service. If there
is currently no service for the selected interface, the default Display Name is the service name
with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the
prefix “PI-” be appended to the beginning of the interface to indicate that the service is part of
the OSIsoft suite of products.

DNP 3.0 Interface 35

Interface Installation

Log on as
The Log on as text box shows the current “Log on as” Windows User Account of the
interface service. If the service is configured to use the Local System account, the Log on as
text box will show “LocalSystem.” Users may specify a different Windows User account for
the service to use.

Password
If a Windows User account is entered in the Log on as text box, then a password must be
provided in the Password text box, unless the account requires no password.

Confirm password
If a password is entered in the Password text box, then it must be confirmed in the Confirm
Password text box.

Dependencies
The Installed services list is a list of the services currently installed on this machine. Services
upon which this interface is dependent should be moved into the Dependencies list using the

button. For example, if API Buffering is running, then “bufserv” should be selected
from the list at the right and added to the list on the left. To remove a service from the list of

dependencies, use the button, and the service name will be removed from the
Dependencies list.
When the interface is started (as a service), the services listed in the dependency list will be
verified as running (or an attempt will be made to start them). If the dependent service(s)
cannot be started for any reason, then the interface service will not run.

Note: Please see the PI Log and Windows Event Logger for messages that may
indicate the cause for any service not running as expected.

- Add Button
To add a dependency from the list of Installed services, select the dependency name, and
click the Add button.

- Remove Button
To remove a selected dependency, highlight the service name in the Dependencies list, and
click the Remove button.
The full name of the service selected in the Installed services list is displayed below the
Installed services list box.

Startup Type
The Startup Type indicates whether the interface service will start automatically or needs to
be started manually on reboot.

36
  If the Auto option is selected, the service will be installed to start automatically
when the machine reboots.
 If the Manual option is selected, the interface service will not start on reboot, but
will require someone to manually start the service.
 If the Disabled option is selected, the service will not start at all.
Generally, interface services are set to start automatically.

Create
The Create button adds the displayed service with the specified Dependencies and with the
specified Startup Type.

Remove
The Remove button removes the displayed service. If the service is not currently installed, or
if the service is currently running, this button will be grayed out.

Start or Stop Service

The toolbar contains a Start button and a Stop button . If this interface service is not
currently installed, these buttons will remain grayed out until the service is added. If this
interface service is running, the Stop button is available. If this service is not running, the
Start button is available.
The status of the Interface service is indicated in the lower portion of the PI ICU dialog.

Status of Status of the

the ICU Interface Service
Service installed or
uninstalled

Installing Interface Service Manually

Help for installing the interface as a service is available at any time with the command:
PIDNP3.exe –help
Open a Windows command prompt window and change to the directory where the
PIDNP31.exe executable is located. Then, consult the following table to determine the
appropriate service installation command.
Windows Service Installation Commands on a PI Interface Node or a PI Server Node with
Bufserv implemented
Manual service PIDNP3.exe –install –depend “tcpip bufserv”
Automatic service PIDNP3.exe –install –auto –depend “tcpip bufserv”
*Automatic service with PIDNP3.exe –serviceid X –install –auto –depend “tcpip bufserv”
service id

DNP 3.0 Interface 37

Interface Installation

Windows Service Installation Commands on a PI Interface Node or a PI Server Node

without Bufserv implemented
Manual service PIDNP3.exe –install –depend tcpip
Automatic service PIDNP3.exe –install –auto –depend tcpip
*Automatic service with PIDNP3.exe –serviceid X –install –auto –depend tcpip
service id

*When specifying service id, the user must include an id number. It is suggested that this
number correspond to the interface id (/id) parameter found in the interface .bat file.
Check the Microsoft Windows Services control panel to verify that the service was added
successfully. The services control panel can be used at any time to change the interface from
an automatic service to a manual service or vice versa.

38
Chapter 6. Digital States

For more information regarding Digital States, refer to the PI Server documentation.

Digital State Sets

PI digital states are discrete values represented by strings. These strings are organized in PI as
digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n
to represent different values of discrete data. For more information about PI digital tags and
editing digital state sets, see the PI Server manuals.
An interface point that contains discrete data can be stored in PI as a digital point. A
digital point associates discrete data with a digital state set, as specified by the user.

DNP3 Specific Digital State Sets

The DNP3 specification allows for different RTU status conditions to be reported with tags.
These status parameters are reported as a 7, 6, or 5 bit integers with each bit representing a
different state. Instead of having a PI tag for each status bit, the PI DNP3 interface has just
one tag to keep track of the status. This status tag can be an integer or even a float tag, but a
status of “36” does not tell the user as much about the state of the tag, but “36” translated to
OffLine_CommLost_OverRange is more meaningful. For this reason, five .csv files are
included with the PI DNP3 interface.
 DigitalSet_DNP_AnalogStatus.csv

 DigitalSet_DNP_BinaryStatus.csv

 DigitalSet_DNP_CounterStatus.csv

 DigitalSet_DNP_DoubleBit.csv

 DigitalSet_DNP_FreezeCodes.csv
To create the digital sets, import the .csv files using the PI SMT. After the sets are created,
create or edit the digital status tags and set their digitalset attribute to the name of the
correct digital state set.

System Digital State Set

Similar to digital state sets is the system digital state set. This set is used for all points,
regardless of type, to indicate the state of a point at a particular time. For example, if the
interface receives bad data from the data source, it writes the system digital state Bad Input
to PI instead of a value. The system digital state set has many unused states that can be used
by the interface and other PI clients. Digital States 193-320 are reserved for OSIsoft
applications.

DNP 3.0 Interface 39

Chapter 7. PointSource

The PointSource is a unique, single or multi-character string that is used to identify the PI
point as a point that belongs to a particular interface. For example, the string Boiler1 may be
used to identify points that belong to the MyInt Interface. To implement this, the PointSource
attribute would be set to Boiler1 for every PI point that is configured for the MyInt
Interface. Then, if /ps=Boiler1 is used on the startup command-line of the MyInt Interface,
the Interface will search the PI Point Database upon startup for every PI point that is
configured with a PointSource of Boiler1. Before an interface loads a point, the interface
usually performs further checks by examining additional PI point attributes to determine
whether a particular point is valid for the interface. For additional information, see the /ps
parameter. If the PI API version being used is prior to 1.6.x or the PI Server version is prior to
3.4.370.x, the PointSource is limited to a single character unless the SDK is being used.

Case-sensitivity for PointSource Attribute

The PointSource character that is supplied with the /ps command-line parameter is not case
sensitive. That is, /ps=P and /ps=p are equivalent.

Reserved Point Sources

Several subsystems and applications that ship with PI are associated with default PointSource
characters. The Totalizer Subsystem uses the PointSource character T, the Alarm Subsystem
uses G and @, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem
uses C. Do not use these PointSource characters or change the default point source characters
for these applications. Also, if a PointSource character is not explicitly defined when creating
a PI point; the point is assigned a default PointSource character of Lab (PI 3). Therefore, it
would be confusing to use Lab as the PointSource character for an interface.

Note: Do not use a point source character that is already associated with another
interface program. However it is acceptable to use the same point source for multiple
instances of an interface.

DNP 3.0 Interface 41

Chapter 8. PI Point Configuration

The PI point is the basic building block for controlling data flow to and from the PI Server. A
single point is configured for each measurement value that needs to be archived.

Point Attributes
Use the point attributes below to define the PI point configuration for the Interface, including
specifically what data to transfer.

Tag

The Tag attribute (or tagname) is the name for a point. There is a one-to-one correspondence
between the name of a point and the point itself. Because of this relationship, PI
documentation uses the terms “tag” and “point” interchangeably.
Follow these rules for naming PI points:
 The name must be unique on the PI Server.
 The first character must be alphanumeric, the underscore (_), or the percent sign
(%).
 Control characters such as linefeeds or tabs are illegal.
 The following characters also are illegal: * ’ ? ; { } [ ] | \ ` ‘ “

Length
Depending on the version of the PI API and the PI Server, this Interface supports tags whose
length is at most 255 or 1023 characters. The following table indicates the maximum length
of this attribute for all the different combinations of PI API and PI Server versions.
PI API PI Server Maximum Length
1.6.0.2 or higher 3.4.370.x or higher 1023
1.6.0.2 or higher Below 3.4.370.x 255
Below 1.6.0.2 3.4.370.x or higher 255
Below 1.6.0.2 Below 3.4.370.x 255

If the PI Server version is earlier than 3.4.370.x or the PI API version is earlier than 1.6.0.2,
and you want to use a maximum tag length of 1023, you need to enable the PI SDK. See
Appendix_B for information.

DNP 3.0 Interface 43

 PointSource

The PointSource attribute contains a unique, single or multi-character string that is used to
identify the PI point as a point that belongs to a particular interface. For additional
information, see the /ps command-line parameter and the “PointSource” section.

PointType

Typically, device point types do not need to correspond to PI point types. For example,
integer values from a device can be sent to floating point or digital PI tags. Similarly, a
floating-point value from the device can be sent to integer or digital PI tags, although the
values will be truncated.
Float16, float32, float 64, int16, int32, and digital point types are supported. For more
information on the individual PointTypes, see PI Server manuals.

Location1

Location1 indicates to which copy of the Interface the point belongs. The value of this
attribute must match the /id command-line parameter.

Location2

DNP3 Objects
Location2 is the DNP list index (or point) number of the point. When used in freezing
counters (Location5=20), this value determines the starting index of one or more counters
to be frozen. Below is an excerpt from the DNP3 Data Object Library Documentation.
The following rules apply to the interpretation of the object point number (DNP Application
Layer range field) in conjunction with objects and variations.
Rule 1:
Point I of object x, variation y represents the same physical point as point I, object x,
variation z, where y and z are variations of object x.
For example: A device has 16 running counters (object 20) numbered 0 to 15. Point 5 can be
asked for in four different ways:
Obj 20, var 1, range 5 returns the running value of counter 5 in 32-bit format.
Obj 20, var 2, range 5 reports the same information, only in 16-bit format.
Obj 20, var 3, range 5 returns the number of counts accumulated in counter 5 since the last
time it was reported, again in 32-bit format.
Obj 20, var 4, range 5 reports the same information, only in 16-bit format.

DNP 3.0 Interface 44

 Rule 2:
Point I of object x can be reported in one of many variations (i.e. it can be a 16-bit or 32-bit
counter). When reported as an event, point I can be returned in either one of the variations
for that object. The exact variation to return is an application specific decision; however an
application should report only ONE event object in any one variation for each event. When
responding to a request for Class data or variation 0 of object x, there should be only one
variation of the object returned.
Rule 3:
Point I within different objects of the same grouping are not necessarily unique, however,
within each of the binary input, binary output, analog input, analog output and counter
groupings the following rules apply.
Point I in the static object is the same physical point as point I in the event object.
Point I in the frozen object is the same physical point as point I in the frozen event object.
For example: For binary inputs, point I in obj 1 var 1 and 2 is the same point as point I in
obj 2 var 1, 2 and 3 (static and event correlation). For counters, point I in obj 20 var 1, 2, 3,
and 4 is the same point as point I in obj 22 var 1, 2, 3, 4, 5, 6, 7, and 8 (static and event
correlation). In addition, point I in obj 21 var 1, 2, 3, 4, 5, 6, 7, and 8 is the same point as
point I in obj 23 var 1, 2, 3, 4, 5, 6, 7, and 8 (frozen and frozen static correlation).

NOTE: Point I in obj 20 and point I in obj 21 are NOT necessarily the same point.
There is no direct correlation between frozen and non-frozen objects.

For the above reason, object type 1 and 2, 20 and 22, 21 and 23, 30 and 32, 31 and 33, 110
and 111, will be considered the same, so that if a PI tag is configured for an object type 30,
index 1, and an object type 32, index 1 event is received, that value will be written to the tag.

Reset Link Counter Tag

Location2 must be set to 0.

Counter Freeze Request Tag

Refer to UserInt1 and Counter Freeze Tags (Object 20) sections of this manual.

DNP3 Internal Indications (IIN)

Location2 is the value of the Internal Indication (IIN) this tag monitors. The table below
shows the relationship between the Location2 value and the IIN it represents. For IIN PI
tags, Location5=80 must be defined.
Location2 Internal Indication (IIN)
1 ALL Stations
All stations message received.
Set when a request is received with the destination address of the all
stations address (ffff hexadecimal).
Cleared after next response (even if response to global request is
required).
Used to let the master station know that a Broadcasted message was
received by this station.

DNP 3.0 Interface 45

PI Point Configuration

Location2 Internal Indication (IIN)

2 Class 1 data available
Set when data that has been configured as Class 1 data is ready to be
sent to the master.
Master station should request this class data from the Outstation when
this bit is set in a response.
3 Class 2 data available
Set when data that has been configured as Class 2 data is ready to be
sent to the master
Master station should request this class data from the Outstation when
this bit is set in a response
4 Class 3 data available
Set when data that has been configured as Class 3 data is ready to be
sent to the master
Master station should request this class data from the Outstation when
this bit is set in a response
5 Need Time
Time-synchronization required from the master. The master synchronizes
the time by writing the Time and Date object to the Outstation.
Cleared when the time is set by the master. This bit is also cleared when
the master explicitly writes a 0 into this bit of the Internal Indication object
of the Outstation.
6 Local
Set when some or all of the Outstation’s digital output points are in the
Local state. That is, the Outstation’s control outputs are NOT accessible
through the DNP protocol.
Clear when the Outstation is in the Remote state. That is, the Outstation’s
control outputs are accessible through the DNP protocol.
7 Device Trouble
Set when an abnormal condition exists at the Outstation. The device
profile for a given device states the conditions that affect this bit.
This should only be used when the state can not be described by a
combination of one or more of the other IIN bits.
8 Device Restart
Set when the user application at the Outstation restarts.
Cleared when the master explicitly writes a 0 into this bit of the Internal
Indications object in the Outstation.
9 Bad Function
Function code not implemented
10 Unknown Object
Requested object(s) unknown. The Outstation does not have the
specified objects or there are no objects assigned to the requested class.
This indication should be used for debugging purposes and usually
indicates a mismatch in device profiles or configuration problems.
11 Out of Range
Parameters in the qualifier range or data fields are not valid or out of
range. This is a catch-all for application request formatting errors.
This indication should be used for debugging purposes and usually
indicates configuration problems.

46
 Location2 Internal Indication (IIN)
12 Buffer Overflow
Event buffer(s), or other application buffers have overflowed. For
example, COS/SOE buffers have overflowed.
The master should attempt to recover as much data as possible and
indicate to the user that their may be lost data. The appropriate error
recovery procedures should be initiated by the user.
13 Already Executing
Request understood but requested operation is already executing.
14 Bad Configuration
Set to indicate that the current configuration in the Outstation is corrupt
and that the master application layer should inform the user of this
exception. The master may download another configuration to the
Outstation.
Note that sometimes a corrupt configuration will disable an Outstation,
making it impossible to communicate this condition to a master station.

Location3

DNP3 Object Tags

Location3 is the DNP address of the device. Every DNP device is assigned an address. The
address of the DNP device must be positive in value. This Location3 value must match a
device address from the Device Configuration XML file.

Note: Set location3 to the negative DNP address of the device to log the value
received from the RTU to the message log. Set the DNP address back to the positive
DNP address to remove logging.

Example: For a RTU with address 4, set location3=-4 to log the value received
from the RTU to the message log.

Polled values received from the DNP device that have associated PI points will have
the value either sent to the PI or discarded. A value is discarded if the value is
received for a scanclass that the tag does not belong. All integrity scans, event
scans, and unsolicited messages received from the DNP device will be sent to the
corresponding PI point regardless of the point assigned scanclass.

Heartbeat Tags
Location3 is set to the DNP address of the device.
Location3 is set to 0 for the interface heartbeat tag (non-UniInt health tag).

Reset Link Counter Tag

Location3 is set to the DNP address of the device.

Counter Freeze Request Tag

Location3 is set to the DNP address of the device.

DNP 3.0 Interface 47

PI Point Configuration

Note: Location5 must be set to equal to 0 for all heartbeat tags.

Location4

Scan-based Inputs
For interfaces that support scan-based collection of data, Location4 defines the scan class
for the PI point. The scan class determines the frequency at which input points are scanned
for new values. For more information, see the description of the /f parameter in the Startup
Command File section.

Note: When defining input points used for freezing counters at a specified interval,
the points must not be assigned to an event scan class.

Trigger-based Inputs, Unsolicited Inputs, and Output Points

Location4 should be set to zero for these points.

Reset Link Counter Tag

Location4 is sets the update interval for the tag. The default update interval is 1 minute.
Range: 1 – 60 minutes

Counter Freeze Request Tag

Location4 should be set to zero for output tags.
Location4 should be set to the scanclass for input tags. The scanclass must not be an event
scanclass as defined by the /event startup parameter.

Location5

Value Tags
Location5 is the DNP Object type. See table below.

Status Tags
Location5 is the NEGATIVE of the DNP Object type.

Heartbeat Tags
Location5 is set to 0.
For interface heartbeat tag (non-UniInt health tag), also set Location3 equal to zero and set
the InstrumentTag equal to HEARTBEAT.

Reset Link Counter Tag

Location5 is set to 0.
Also set the InstrumentTag equal to RESETLINK.
48
 Counter Freeze Request Tag
Location5 is set to 20.
Also set the InstrumentTag equal to FREEZE.

DNP3 Internal Indication (IIN) Tags

Location5 is set to 80. Location2 must also be set to identify the indication to monitor.

Object Types
The following table lists the DNP Object Types along with their associated Location5
value.
Object Location5 Generic Type
01, 02* Binary Input and Events
03, 04* Double-bit Input
10 Binary Output Status
20***, 22* Binary Counters & Events
21, 23* Frozen Counters & Events
30, 32* Analog Input & Events
31, 33* Frozen Analog Input & Events
40 Analog Output Status
41** Analog Output Block (output)
50 Time and Date
80 Internal Indications
110****,111* Octet String & Events
* These types are considered to be equal. For example, a counter event (object 22) for
point number 3 will be saved to a Counter (Location5 = 20) PI tag with point
number 3 (Location2 = 3).
** This generic type is associated with DNP output objects. This type also needs
specific InstrumentTag and Userint2 values.
*** This generic type is associated with DNP object 20 when requesting to freeze
counter values. This type also needs specific Location2 and Userint1 values. If the
point is used as an input point, then Userint2 will also be needed.
**** This type is associated with DNP Octet String and requires the use of the
InstrumentTag attribute.

InstrumentTag

Length
Depending on the version of the PI API and the PI Server, this Interface supports an
InstrumentTag attribute whose length is at most 32 or 1023 characters. The following table
indicates the maximum length of this attribute for all the different combinations of PI API and
PI Server versions.
PI API PI Server Maximum Length
1.6.0.2 or higher 3.4.370.x or higher 1023
1.6.0.2 or higher Below 3.4.370.x 32

DNP 3.0 Interface 49

PI Point Configuration

Below 1.6.0.2 3.4.370.x or higher 32

Below 1.6.0.2 Below 3.4.370.x 32

If the PI Server version is earlier than 3.4.370.x or the PI API version is earlier than 1.6.0.2,
and you want to use a maximum InstrumentTag length of 1023, you need to enable the PI
SDK. See Appendix B for information.

Value/Status Tags
The InstrumentTag is used to specify the variation of the DNP Object type. The variation
describes the type of data being requested. For example, the user may be requesting 32 bit or
16 bit, with or without a parameter. A blank InstrumentTag informs the interface to include
a variation type of 0 in the request for data. A variation value of 0 is a request for the default
variation the remote device supports. If a variation is found in the InstrumentTag and if the
tag is not an event type tag belonging to an event scan class, it will be included in the request
to the DNP slave device. The DNP slave device is not required to respond with the exact
variation requested. However, if a specific variation is required, a variation that contains a
parameter for example, then it can be requested.
The following is an excerpt from the DNP V3.00 Application Layer Protocol Description
(page 3-18).
The object field is two octets in length. The first octet specifies the general type of data (e.g.
analog inputs) and the second octet specifies the variation of the data type (e.g. 16-bit analog
inputs or 32-bit analog inputs). In the request direction, if the object variation is specified as
0, this indicates all object variations belonging to the same group (i.e. all or any analog
inputs types). In the response direction however, variation 0 cannot be used to specify the
objects. The specific variation has to be specified.
Consider the example where the request message specifies counter objects in the first octet
and the variation is 0. Given that the Outstation supports only 16 bit counters, it will respond
with an object header with the variation field set to indicate that the counter objects are 16
bit counters.
With the same request message directed to another station, the returned object header may
indicate a 32-bit count field in the counter objects it returns. By requesting data with the
variation set to 0, it is not necessary for the master to know what variations the Outstation
supports. The master must however be able to interpret the object headers and have some
knowledge of the structure of each variation.

Heartbeat Tags
Set the InstrumentTag = HEARTBEAT.

Reset Link Counter Tag

Set the InstrumentTag = RESETLINK.

Counter Freeze Request Tag

When the freezing of the object 20 counters is required, set the InstrumentTag = FREEZE.

Octet String Tag

This value must be set to a value of 1—255. It is recommended to use a variation of 255
when creating PI tags to read an Octet String in order to read the maximum size of an Octet

50
 String. If the size of the Octet String received from the RTU is less than 255, the length of the
Octet String stored in PI will reflect the smaller size

Userint1

Counter Freeze Request Tag

The Userint1 attribute is used in requests to freeze or freeze/clear Binary Counters (Object
20). The freezing of this object is specified by setting the Location5 attribute to a value 20.
The value of the Location2 attribute must be set to the starting index of the Counter(s) that
is to be frozen. The value of the Userint1 attribute is used to set the stopping index of the
Counter(s) that are to be frozen. If all Counters are to be frozen, then the Userint1 value
must be set to a value of -1. If the point is being used as an input point, then Userint2 must
also be defined. If the freeze request comes from an output PI Point, refer to the Counters
Freezing/Clearing Counters section for the DNP3 function code associated with the output
value of this PI Point. The following table demonstrates how the value of Userint1 is
interpreted.

DNP 3.0 Interface 51

PI Point Configuration

Userint1 Meaning
Value
-1 Freeze or Freeze/Clear all counters. The output value of the tag
specifies what action will be taken
n The value of n represents the stopping index of the Binary
Counter to be Frozen or Frozen/Cleared. Where n is a valid
Binary Counter index. When n is specified, a Location2 starting
index must also be supplied.

Userint2

Analog Control Block (Object 41) Tag

The Userint2 attribute is necessary when writing output values to the Analog Control Block
(Object 41). The use of these objects is specified by setting the Location5 attribute to a
value 41. The following table lists the value that the Userint2 attribute must be set to when
requesting a specific DNP3 function.
Function Userint2 Value
Select and Operate 0
Direct Operate 1
Direct Operate, No Ack 2

Counter Freeze Request Tag

The Userint2 attribute is also necessary when using input defined PI points to request
freezing of Binary Counters (Object 20). The freezing of this object is specified by setting the
Location5 attribute to a value 20. The value of the Location2 attribute must be set to the
starting index of the Counter(s) to be frozen. The value of the Userint1 attribute is used to
set the stopping index of the Counter(s) that are to be frozen. The following table lists the
value that the Userint2 attribute must be set to when using an input point to freeze binary
counters.
Function Userint2 Value
Immediate Freeze 0
Immediate Freeze, No Ack 1
Freeze and Clear 2
Freeze and Clear, No Ack 3

ExDesc

Length
Depending on the version of the PI API and the PI Server, this Interface supports an ExDesc
attribute whose length is at most 80 or 1023 characters. The following table indicates the
maximum length of this attribute for all the different combinations of PI API and PI Server
versions.

52
 PI API PI Server Maximum Length
1.6.0.2 or higher 3.4.370.x or higher 1023
1.6.0.2 or higher Below 3.4.370.x 80
Below 1.6.0.2 3.4.370.x or higher 80
Below 1.6.0.2 Below 3.4.370.x 80

If the PI Server version is earlier than 3.4.370.x or the PI API version is earlier than 1.6.0.2,
and you want to use a maximum ExDesc length of 1023, you need to enable the PI SDK. See
Appendix B for information.

Performance Points
For UniInt-based interfaces, the extended descriptor is checked for the string
“PERFORMANCE_POINT”. If this character string is found, UniInt treats this point as a
performance point. See the section called Scan Class Performance Points.

Scan

By default, the Scan attribute has a value of 1, which means that scanning is turned on for the
point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the
Interface starts, a message is written to the pipc.log and the tag is not loaded by the
Interface. There is one exception to the previous statement.
If any PI point is removed from the Interface while the Interface is running (including setting
the scan attribute to 0), SCAN OFF will be written to the PI point regardless of the value of
the Scan attribute. Two examples of actions that would remove a PI point from an interface
are to change the point source or set the scan attribute to 0. If an interface specific attribute is
changed that causes the tag to be rejected by the Interface, SCAN OFF will be written to the
PI point.

Convers

Convers may be used in the scaling of a raw value. See the Scaling section below for a
detailed explanation of how to use this attribute.

Span

Span may be used in the scaling of a raw value. See the Scaling section below for a detailed
explanation of how to use this attribute.

Squareroot

Squareroot is used to determine which scaling formula, if any, will be applied to the raw
DNP value before the value is sent to PI. The default is zero. See the Scaling section below
for a detailed explanation of how to use this attribute.

Userreal1

Userreal1 may be used as the instrument minimum in the scaling of a raw value. See the
Scaling section below for a detailed explanation of how to use this attribute.
DNP 3.0 Interface 53
PI Point Configuration

Userreal2

Userreal2 may be used as the instrument range in the scaling of a raw value. See the
Scaling section below for a detailed explanation of how to use this attribute.

Zero

Zero may be used in the scaling of a raw value. See the Scaling section below for a detailed
explanation of how to use this attribute.

Shutdown

The Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown
subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The
timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the
Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that
the timestamp for the SHUTDOWN events will be accurate to within 15 minutes in the event of
a power failure. For additional information on shutdown events, refer to PI Server manuals.

Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are
independent of the SHUTDOWN events that are written by the Interface when
the /stopstat=Shutdown command-line parameter is specified.

SHUTDOWN events can be disabled from being written to PI when PI is restarted by setting the
Shutdown attribute to 0 for each point. Alternatively, the default behavior of the PI Shutdown
Subsystem can be changed to write SHUTDOWN events only for PI points that have their
Shutdown attribute set to 0. To change the default behavior, edit the
\PI\dat\Shutdown.dat file, as described in the PI Server manuals.

Bufserv and PIBufss

It is undesirable to write shutdown events when buffering is being used. Bufserv and PIBufss
are utility programs that provide the capability to store and forward events to a PI Server,
allowing continuous data collection when the Server is down for maintenance, upgrades,
backups, and unexpected failures. That is, when PI is shutdown, Bufserv or PIBufss will
continue to collect data for the Interface, making it undesirable to write SHUTDOWN events to
the PI points for this Interface. Disabling Shutdown is recommended when sending data to a
Highly Available PI Server Collective. Refer to the Bufserv or PIBufss manuals for additional
information.

Scaling
All data coming from a DNP 3.0 compliant device is one of four types; binary, 8 bit status, 16
bit integer, or 32 bit integer. The PI DNP3 interface supports scaling the 16 bit and 32 bit
integer types. The scaling for these types adheres to one of the following formulas depending
on the value of the PI tag squareroot attribute. The following definitions describe the
different variables of the formula:
 value is the 16 or 32 bit value received from the RTU

54
  def_range is the default range and is equal to 65,536 (216) for 16-bit values and
4,294,967,296 (232) for 32-bit integer/short float values. Long float (64-bit real)
values received from the RTU will be treated the same as 32-bit values due to
limitations of the operating system.
 def_min is the default minimum and it is equal to is –32,768 (-215) for 16-bit
values and –2,147,483,648 (-231) for 32-bit integer/short float values. Long float
(64-bit real) values received from the RTU are treated the same as 32-bit values
due to limitations of the operating system.
 instr_min is the instrument zero and is found in the PI point UserReal1 attribute
 instr_range is the instrument range and is equal to the PI point UserReal2
attribute
 pispan is equal to the PI point attribute span
 pizero is equal to the PI point attribute zero

squareroot Formula applied

0 value written to PI
1 value (value is assumed to be unsigned integer)
2
2 value
3 value written to PI (value is treated as an unsigned integer)
 value - def_min 
4   pispan   pizero
 def_range 
 value 
5   pispan   pizero
 def_range 
 value - instr_min 
6   pispan   pizero
 instr_rang e 
 value 
7   pispan   pizero
 instr_range 
8 value  convers

Note: The default behavior of the PI DNP3 interface is to treat

all integer values received from a DNP device as signed
integers. If this is not the desired behavior, the squareroot
attribute must be set to the appropriate value.

Examples of squareroot data handling:

Example 1.A DNP 3.0 compliant device is used to read and transmit the temperature of a
beaker of water. The water temperature range is between 0o C and 100o C. The range of
values from the device is between -10000 and +10000, where -10000 correspond to 0o C and
10000 corresponds to 100o C. To properly convert the value from the PLC to a temperature in
o C, use the following settings:

DNP 3.0 Interface 55

PI Point Configuration

instr_min = -10000 instr_range = 20000

pizero = 0 pispan = 100
squareroot = 6
Example 2. A DNP 3.0 compliant device is used to measure the volume of liquid in a tank.
The results of the measurement are transmitted as a 16-bit signed integer with the minimum
(0x8000 hex or –32768) being equal to zero gallons and the maximum (0x7FFF hex or
32767) being equal to 250 gallons. To properly convert the value to the number of gallons,
use the following settings:
pizero = 0 pispan = 250
squareroot = 4
Example 3. The 16-bit analog inputs received from a device should be treated as unsigned
integers so that the range of values is from 0 to 65,536 instead of –32,768 to 32,767. To
properly store values larger than 32767 use the following setting:
squareroot = 3
If any of the above settings result in dividing a number by 0, the formula will be ignored and
an error message will be written to the pipc.log file once. The raw values will then be stored
in PI.

Output Points
Output points control the flow of data from the PI Server to any destination that is external to
the PI Server, such as a PLC or a third-party database. For example, to write a value to a
register in a PLC, use an output point. Each interface has its own rules for determining
whether a given point is an input point or an output point. There is no de facto PI point
attribute that distinguishes a point as an input point or an output point.
Outputs are triggered for UniInt-based interfaces. That is, outputs are not scheduled to occur
on a periodic basis. There are two mechanisms for triggering an output.
As of UniInt 3.3.4, event conditions can be placed on triggered outputs. The conditions are
specified using the same event condition keywords in the extended descriptor as described
below. The only difference is that the trigger tag is specified with the SourceTag attribute
instead of with the “event” or “trig” keywords. For output points, event conditions are
specified in the extended descriptor as follows:
event_condition
The keywords in the following table can be used to specify trigger conditions.
Event Description
Condition
Anychange Trigger on any change as long as the value of the current event is different than
the value of the previous event. System digital states also trigger events. For
example, an event will be triggered on a value change from 0 to “Bad Input,” and
an event will be triggered on a value change from “Bad Input” to 0.
Increment Trigger on any increase in value. System digital states do not trigger events.
For example, an event will be triggered on a value change from 0 to 1, but an
event will not be triggered on a value change from “Pt Created” to 0. Likewise,
an event will not be triggered on a value change from 0 to “Bad Input.”
Decrement Trigger on any decrease in value. System digital states do not trigger events.
For example, an event will be triggered on a value change from 1 to 0, but an
event will not be triggered on a value change from “Pt Created” to 0. Likewise,
an event will not be triggered on a value change from 0 to “Bad Input.”

56
 Event Description
Condition
Nonzero Trigger on any non-zero value. Events are not triggered when a system digital
state is written to the trigger tag. For example, an event is triggered on a value
change from “Pt Created” to 1, but an event is not triggered on a value change
from 1 to “Bad Input.”

Trigger Method 1 (Recommended)

For trigger method 1, a separate trigger point must be configured. The output point must have
the same point source as the interface. The trigger point can be associated with any point
source, including the point source of the interface. Also, the point type of the trigger point
does not need to be the same as the point type of the output point.
The output point is associated with the trigger point by setting the SourceTag attribute of the
output point equal to the tag name of the trigger point. An output is triggered when a new
value is sent to the Snapshot of the trigger point. The new value does not need to be different
than the previous value that was sent to the Snapshot to trigger an output, but the timestamp
of the new value must be more recent than the previous value. If no error is indicated, then
the value that was sent to the trigger point is also written to the output point. If the output is
unsuccessful, then an appropriate digital state that is indicative of the failure is usually
written to the output point. If an error is not indicated, the output still may not have
succeeded because the interface may not be able to tell with certainty that an output has
failed.

Trigger Method 2

For trigger method 2, a separate trigger point is not configured. To trigger an output, write a
new value to the Snapshot of the output point itself. The new value does not need to be
different than the previous value to trigger an output, but the timestamp of the new value
must be more recent than the previous value.
Trigger method 2 may be easier to configure than trigger method 1, but trigger method 2 has
a significant disadvantage. If the output is unsuccessful, there is no tag to receive a digital
state that is indicative of the failure, which is very important for troubleshooting.

DNP 3.0 Interface 57

Chapter 9. Startup Command File

Command-line parameters can begin with a / or with a -. For example, the /ps=M and
-ps=M command-line parameters are equivalent.
For Windows, command file names have a .bat extension. The Windows continuation
character (^) allows for the use of multiple lines for the startup command. The maximum
length of each line is 1024 characters (1 kilobyte). The number of parameters is unlimited,
and the maximum length of each parameter is 1024 characters.
The PI Interface Configuration Utility (PI ICU) provides a tool for configuring the Interface
startup command file.

Configuring the Interface with PI ICU

Note: PI ICU requires PI 3.3 or greater.

The PI Interface Configuration Utility provides a graphical user interface for configuring PI
interfaces. If the Interface is configured by the PI ICU, the batch file of the Interface
(PIDNP3.bat) will be maintained by the PI ICU and all configuration changes will be kept
in that file and the module database. The procedure below describes the necessary steps for
using PI ICU to configure the PI DNP3 Interface.
From the PI ICU menu, select Interface, then NewWindows Interface Instance from EXE...,
and then Browse to the PIDNP3.exe executable file. Then, enter values for Host PI System,
Point Source and Interface ID#. A window such as the following results:

DNP 3.0 Interface 59

 “Interface name as displayed in the ICU (optional)” will have PI- pre-pended to this name
and it will be the display name in the services menu.
Click on Add.
The following display should appear:

Note that in this example the Host PI System is mkellylaptop. To configure the interface to
communicate with a remote PI Server, select ‘Interface => Connections…’ item from PI ICU
menu and select the default server. If the remote node is not present in the list of servers, it
can be added.
Once the interface is added to PI ICU, near the top of the main PI ICU screen, the Interface
Type should be DNP3. If not, use the drop-down box to change the Interface Type to be
DNP3.”
Click on Apply to enable the PI ICU to manage this copy of the PI DNP3 Interface.

DNP 3.0 Interface 60

 The next step is to make selections in the interface-specific tab (i.e. “ DNP3”) that allow the
user to enter values for the startup parameters that are particular to the PIDNP3 Interface.

DNP 3.0 Interface 61

Startup Command File

Since the PI DNP3 Interface is a UniInt-based interface, in some cases the user will need to
make appropriate selections in the UniInt page. This page allows the user to access UniInt
features through the PI ICU and to make changes to the behavior of the interface.
To set up the interface as a Windows Service, use the Service page. This page allows
configuration of the interface to run as a service as well as to starting and stopping of the
interface. The interface can also be run interactively from the PI ICU. To do that go to menu,
select the Interface item and then Start Interactive.
For more detailed information on how to use the above-mentioned and other PI ICU pages
and selections, please refer to the PI Interface Configuration Utility User Manual. The next
section describes the selections that are available from the DNP3 page. Once selections have
been made on the PI ICU GUI, press the Apply button in order for PI ICU to make these
changes to the interface’s startup file.

DNP3 Interface page

Since the startup file of the PI DNP3 Interface is maintained automatically by the PI ICU, use
the PI DNP3 page to configure the startup parameters and do not make changes in the file
manually. The following is the description of interface configuration parameters used in the
PI ICU Control and corresponding manual parameters.
The PI DNP3 ICU Control for PI ICU has 3 sections/tabs. A yellow text box indicates that an
invalid value has been entered, or that a required value has not been entered.

XML Tab
When selecting the XML tab for the first time after adding the interface to the ICU you must
use the browse button to select either an existing XML configuration file or enter a new
filename in the browse dialog which will then be created for you. This textbox is not editable
and can only be populated by using the browse button.

62
 Device Configuration File Path:
This text box is used to specify the path of the XML configuration file to be used by the
interface. If there are spaces in the path, then the path and file name must be enclosed in
double quotation marks in the batch file not in the GUI.
Example: /xml=”C:\Program Files\pipc\interfaces\pidnp3\PIDNP3.xml”
Use the browse button to choose an existing XML Configuration file or enter a file name in
the dialog box presented after clicking the browse button. To create a new empty XML
Configuration file point to the location where you wish to store the file. By default the
location will be the same location as the executable. In the figure below a new file is being
created by the entry MyNewXMLFile.xml in the File name box. You could have chosen one
of the other files listed as well by selecting it and clicking it. Click Open to create the new
file or open an existing one.

DNP 3.0 Interface 63

Startup Command File

The next figure shows what will be presented if a new file is entered instead of picking an
existing file. If an existing file is chosen then the box on the left will show under Session any
IO Groups or RTUs already configured in that .XML file.

64
 Device Configuration File Settings:
See the section Device Configuration (XML) File for a description of these different items.
Note that the Address box is in yellow. This indicates that a required field is missing or
invalid. You need to fill this in. After you assign a value to the Address box then click on the
icon , which will add an IOGroup. The following will appear in the box on the left.

Click the IO Group1 that will allow you to configure this IO Group as either TCP of Serial.
Choose which type you want to configure.

Next if you chose TCP you will get a section similar to the following where you can enter
either a TCP/IP address or a NodeName.

DNP 3.0 Interface 65

Startup Command File

If you chose Serial you will get a section similar to the following where you can enter the
Baud rate, COM Port, Parity, Data Bits and Stop Bits.

After filling in either the TCP or Serial parameters the next step is to create a RTU Device by
clicking on the second button above the box on the left.
This will add a RTU1 to the box on the left.

Click on the RTU1 to get the next dialog box to configure.

Make the appropriate choices. For more information see the section called Device
Configuration (XML) File.
If you want to add another RTU to the same group click on the particular IO Group# and
click the second button , which is Add RTU.

If you want to add another IOGroup click on the Session and click the first button , which
is the Add Group button.

To delete any RTU or IO Group select it and click the third button .

Additional Parameters
This text box is to be used for any additional parameters not currently supported by the ICU
Control. Any parameters entered in this field must be separated by a space and a / or -. If a

66
 parameter’s argument contains any embedded spaces then the argument must be enclosed in
double quotes.

Optional Parameters Tab

I/O Timeout:
The /IOTimeOut parameter specifies the length of time, in minutes, allowed to elapse
without a good communications session with a RTU before the system digital state “IO
TimeOut” will be written to all tags belonging to the RTU. A value of 0 or the absence of the
parameter in the start-up file means “IO TimeOut” will never be written to the PI tags. A
communications session is defined as receiving a good response to a request. The span is in
minutes and care must be taken when assigning this value. The default check for an I/O
timeout will be performed once a minute. The setting of the span must go hand in hand with
the setting of the Integrity Scan frequency and the scan class frequency. If the I/O timeout
span is less or roughly equal to the shortest scan class frequency and the Integrity Scan
frequency, “IO TimeOut” may be written to the tags shortly before every scan. Therefore, the
span must be at least 1.5 times longer than the shortest scan class frequency or the Integrity
Scan frequency whichever is shorter. (/IOTimeOut=# Default:0).

Retry Interval (seconds):

The /Retry parameter specifies the interval in seconds that the interface will make
subsequent attempts to connect to a specific RTU device. (/Retry=# Default:30).
DNP 3.0 Interface 67
Startup Command File

Number of Threads for IO Pool:

The /IOPool parameter specifies the number of threads to be used for the IO completion
port pool. If this parameter is not defined, the default of 2 x Number of logical processors is
used. This parameter was implemented in version 3.0.1.0 of the interface. It appears only
when the interface version 3.0.1.0 or later is installed. (/IOPool=# Default:2x Number of
processors).

Number of Threads for Worker Pool:

The /WorkerPool parameter specifies the number of threads to be used for the worker pool.
If this parameter is not defined, no worker pool is created. This parameter was implemented
in version 3.0.1.0 of the interface. It appears only when the interface version 3.0.1.0 or later is
installed. (/WorkerPool=# Default:1).

Number of msec for IOCP to sleep:

The /IOSleep parameter specifies the number of milliseconds to allow the IOCP threads to
sleep between executions. By default, the IOCP routine does not sleep between executions.
This parameter should not be altered unless the interface process appears to be utilizing a
high percentage of the cpu. In this case, set the /IOSleep parameter to one and restart the
interface. This parameter was implemented in version 3.0.1.0 of the interface. It appears only
when the interface version 3.0.1.0 or later is installed. (/IOSleep=# Default:0, range 0-100).

Do not log RTU’s with no connection

The /NoDevStatLog parameter when defined instructs the interface not to log the list of
RTU’s that have no connection to the interface in the device status log. However, the number
of RTU(s) in error are still listed in the Device Status tag. By default, the RTU(s) that are in
error are logged to the device status log for the interface. The maximum size of the log file is
100KB and once reached, the file will then be cleared for new data. This parameter was
implemented in version 3.0.1.0 of the interface. It appears only when the interface version
3.0.1.0 or later is installed. (/NoDevStatLog).

Do not log startup parameters for RTU’s

The /NoLogRTUParams parameter when defined instructs the interface not to log startup
parameters for RTU’s assigned to the interface. This is useful to prevent the pipc.log file
from becoming difficult to read when many RTU’s are defined for a given instance of the
interface. By default, the startup parameters for each RTU are listed in the pipc.log file.
This parameter was implemented in version 3.0.1.0 of the interface. It appears only when the
interface version 3.0.1.0 or later is installed. ( /NoLogRTUParams).

Prevent UniInt Failover when device statuses are equal

This parameter is only applicable when UniInt Interface Failover is being used.
The /StatusKeepState parameter when defined will prevent the backup copy of the interface
from assuming the primary state at an interval specified by the location5 attribute of the
ActiveID tag when the value of both failover copies of the interface have equal device status
values and neither interface is able to collect data while in the primary state. The interface
does this by writing a value of 30 to the device status.
The UniInt device status health tag accepts values in the range of 0-100; whereby a value of 0
represents a good status value. Any value less than 50 will prevent the backup copy of the
interface instance from assuming control if the device status values of the failover instances
68
 are equal in error value. A value of 50 -70 will allow the backup copy of the interface to
assume control, at an interval specified by the location5 attribute of the ActiveID tag, if the
device status values of the failover instances are equal

RTU Log Size in Kilobytes (KB):

The /RTULogSize parameter specifies the maximum size of the RTU log file before the file
is cleared for new data. The size specified is in Kilo-Bytes (KB). If the interface debug level
as defined by the /dnpdbg does not specify logging to the RTU log file (level=0x0001), then
the log file is not created by the interface. This parameter was implemented in version 3.0.1.0
of the interface. It appears only when the interface version 3.0.1.0 or later is installed.
(/RTULogSize=# Default:100).

Device Status Update Interval (sec):

This parameter specifies the interface device status update interval in seconds.
The user should consider the /retry rate as well as the time it takes to establish connections
with configured devices in determining the /StatusInterval value. The user should use an
interval that will allow enough time to establish connection with enough devices to allow
the /StatusPercentUp value to be reached.

Minimum % for Good Device Status:

This parameter specifies the minimum percent of connected devices for reporting a good
device status.
All configurations:
The interface will write a value of good to the UniInt device status health tag if the percent of
connected devices is equal to or greater than the /StatusPercentUp value.
If the /StatusPercentUp=0, the interface will always report a status of good.
UniInt failover:
The interface will report a status value of 50 if the percent of connected devices is less than
the /StatusPercentUp value. If the /StatusKeepState parameter is defined, the interface will
report a status value of 30 if the percent of connected devices is less than the
/StatusPercentUp value.
The /StatusPercentUp=0 is useful during a UniInt failover configuration if the user wants
the other interface to assume the role as primary only if the heartbeat of this copy of the
interface fails to update (i.e. this copy is shutdown, crashes, or enters a locked state).

Seconds before Device Status Set:

Where # specifies the time in seconds before the interface will set the device status upon
initial startup or upon assuming the role as primary if running in a UniInt failover
configuration.

DNP 3.0 Interface 69

Startup Command File

Event Classes Tab

Event Classes
The /event parameter specifies a scan class as an event class. All the points assigned to this
scan class will be treated as event type tags. The ScanClass defines a scan class that
corresponds to a /f= flag from the start-up file and the Location4 of the PI tags.
Example: If this is found in the start-up file.
/f=10 /f=120 /f=00:10:00 /event=2 /event=3
The interface will make a request for event data every 2 minutes and every 10 minutes. All PI
tags with Location4 equal to 2 or 3 will be considered event type tags and no requests for
static data will be made for these tags except for the integrity scans. ( /Event=#).

70
 Debug Tab

Debug Options:
These checkboxes specify the level of debugging messages to be written to the log files and
to the console window if running interactively. The level is a 16-bit number that can be
expressed as a hexadecimal number if preceded with a 0x. Each bit of the debug parameter
turns on and off debugging in a different section of the interface. The following list shows
example debug parameters and the section of code affected by that bit. For each bit, setting
the bit to 1 will turn on that section’s debugging messages and setting the bit to 0 will turn
them off. To combine different flags, add the value of the flags together. For example, to send
the raw DNP messages to both the RTU log file and to the console, and to log the Data Link,
Transport, and Application Layer message explanations to the log file, set the parameter to
/dnpdbg=0x001F. This turns on bits 1 through 5 starting from the right. For a more detailed
explanation, refer to the DNP and other Debugging messages section. You can also turn on all
debugging by checking the Maximum Debug check box.
Examples
/dnpdbg=0x0001 Raw DNP messages written to the RTU log file
/dnpdbg=0x0002 Data Link Layer Descriptions to Log File
/dnpdbg=0x0004 Transport Layer Descriptions to Log File
/dnpdbg=0x0008 Application Layer Descriptions to Log File
/dnpdbg=0x0010 Raw DNP messages written to the Console
/dnpdbg=0x0020 Data Link Layer Descriptions to Console
/dnpdbg=0x0040 Transport Layer Descriptions to Console
/dnpdbg=0x0080 Application Layer Descriptions to Console
/dnpdbg=0x0100 Start-UP procedures

DNP 3.0 Interface 71

Startup Command File

/dnpdbg=0x0200 Load PI Tag Procedures

/dnpdbg=0x0400 Data Sent to PI (not including Heartbeat tags)
/dnpdbg=0x0800 Scanning for Current Values
/dnpdbg=0x1000 Communications Medium
/dnpdbg=0x2000 Value Scaling

72
 Command-line Parameters

Parameter Description
/CacheMode Required for disconnected startup operation. If defined, the
Required /CacheMode startup parameter indicates that the interface
Default: Not Defined will be configured to utilize the disconnected startup feature.

/CachePath=path Used to specify a directory in which to create the point caching

Optional files. The directory specified must already exist on the target
machine. By default, the files are created in the same location
Default: Not Defined
as the interface executable.
If the path contains any spaces, enclose the path in quotes.
Examples:
/CachePath=D:\PIPC\Interfaces\CacheFiles
/CachePath=D:/PIPC/Interfaces/CacheFiles
/CachePath=D:/PIPC/Interfaces/CacheFiles/

Examples with space in path name:

/CachePath=”D:\Program Files\PIPC\MyFiles”
/CachePath=”D:/Program Files/PIPC/MyFiles”
/CachePath=”D:/Program
Files/PIPC/MyFiles/”
/CacheSynch=# NOTE: Care must be taken when modifying this parameter. This
Optional value must be less than the smallest scan class period defined
with the /f parameter. If the value of the /CacheSynch
Default: 250 ms
parameter is greater than the scan class value, input scans will
be missed while the point cache file is being synchronized.
The optional /CacheSynch=# startup parameter specifies
the time slice period in milliseconds (ms) allocated by UniInt for
synchronizing the interface point cache file with the PI Server.
By default, the interface will synchronize the point cache if
running in the disconnected startup mode. UniInt allocates a
maximum of # ms each pass through the control loop
synchronizing the interface point cache until the file is
completely synchronized.
Synchronization of the point cache file can be disabled by
setting the value /CacheSynch=0. The minimum
synchronization period when cache synchronization is enabled
is 50ms Whereas, the maximum synchronization period is
3000ms (3s). Period values of 1 to 49 will be changed by the
interface to the minimum of 50ms and values greater than 3000
will be set to the maximum interval value of 3000ms.
Default: 250 ms
Range: {0, 50 – 3000} time in milliseconds
Example: /CacheSynch=50 (use a 50ms interval)
/CacheSynch=3000 (use a 3s interval)
/CacheSynch=0 (do not synchronize the cache)

DNP 3.0 Interface 73

Startup Command File

Parameter Description
/dnpdbg=level Specifies the level of debugging messages to be written to the
Optional log files and to the console window if running interactively. The
level is a 16-bit number that can be expressed as a
hexadecimal number if preceded with a 0x. Each bit of the
debug parameter turns on and off debugging in a different
section of the interface. The following list shows example debug
parameters and the section of code affected by that bit. For
each bit, setting the bit to 1 will turn on that section’s debugging
messages and setting the bit to 0 will turn them off. To combine
different parameters, add the value of the parameters together.
For example, to send the raw DNP messages to both the RTU
log file and to the console, and to log the Data Link, Transport,
and Application Layer message explanations to the log file, set
the parameter to /dnpdbg=0x001F. Basically, this turns on
bits 1 through 5 starting from the right. For a more detailed
explanation, See the DNP and other Debugging messages
section.
Examples
/dnpdbg=0x0001 Raw DNP messages written to the RTU
log file
/dnpdbg=0x0002 Data Link Layer Descriptions to Log File
/dnpdbg=0x0004 Transport Layer Descriptions to Log File
/dnpdbg=0x0008 Application Layer Descriptions to Log File
/dnpdbg=0x0010 Raw DNP messages written to the
Console
/dnpdbg=0x0020 Data Link Layer Descriptions to Console
/dnpdbg=0x0040 Transport Layer Descriptions to Console
/dnpdbg=0x0080 Application Layer Descriptions to Console
/dnpdbg=0x0100 Start-UP procedures
/dnpdbg=0x0200 Load PI Tag Procedures
/dnpdbg=0x0400 Data Sent to PI (not including Heartbeat
Tags)
/dnpdbg=0x0800 Scanning for Current Values
/dnpdbg=0x1000 Communication Medium
/dnpdbg=0x2000 Value Scaling
/ec=# The first instance of the /ec parameter on the command-line is
Optional used to specify a counter number, #, for an I/O Rate point. If the
# is not specified, then the default event counter is 1. Also, if the
/ec parameter is not specified at all, there is still a default
event counter of 1 associated with the interface. If there is an
I/O Rate point that is associated with an event counter of 1,
each copy of the interface that is running without
/ec=#explicitly defined will write to the same I/O Rate point.
This means either explicitly defining an event counter other than
1 for each copy of the interface or not associating any I/O Rate
points with event counter 1. Configuration of I/O Rate points is
discussed in the section called I/O Rate Point.
For interfaces that run on Windows nodes, subsequent
instances of the /ec parameter may be used by specific
interfaces to keep track of various input or output operations.
Subsequent instances of the /ec parameter can be of the form
/ec*, where * is any ASCII character sequence. For example,
/ecinput=10, /ecoutput=11, and /ec=12 are
legitimate choices for the second, third, and fourth event
counter strings.

74
 Parameter Description
/event=ScanClass Specifies a scan class as an event class which polls the RTU
Optional for all DNP3 class 1,2, and 3 events. All of the points assigned
to this scan class will be treated as event type tags. The
ScanClass defines a scan class that corresponds to a /f=
flag from the start-up file and the Location4 of the PI
tags.
Example: If this is found in the start-up file.
/f=10 /f=120 /f=00:10:00 /event=2
The interface will make a request for event data (class 1,2,3
data) every 2 minutes. All PI tags with Location4 equal to 2
will be considered event type tags and no requests for static
data will be made for these tags except during the integrity scan
if configured.
/f=SS.## The /f parameter defines the time period between scans in
or terms of hours (HH), minutes (MM), seconds (SS) and sub-
/f=SS.##,SS.## seconds (##). The scans can be scheduled to occur at discrete
moments in time with an optional time offset specified in terms
or
of hours (hh), minutes (mm), seconds (ss) and sub-seconds
/f=HH:MM:SS.## (##). If HH and MM are omitted, then the time period that is
or specified is assumed to be in seconds.
/f=HH:MM:SS.##, Each instance of the /f parameter on the command-line
hh:mm:ss.## defines a scan class for the interface. There is no limit to the
number of scan classes that can be defined. The first
Required for reading scan- occurrence of the /f parameter on the command-line defines
based inputs the first scan class of the interface; the second occurrence
defines the second scan class, and so on. PI Points are
associated with a particular scan class via the Location4 PI
Point attribute. For example, all PI Points that have Location4
set to 1 will receive input values at the frequency defined by the
first scan class. Similarly, all points that have Location4 set to 2
will receive input values at the frequency specified by the
second scan class, and so on.
Two scan classes are defined in the following example:
/f=00:01:00,00:00:05 /f=00:00:07
or, equivalently:
/f=60,5 /f=7
The first scan class has a scanning frequency of 1 minute with
an offset of 5 seconds, and the second scan class has a
scanning frequency of 7 seconds. When an offset is specified,
the scans occur at discrete moments in time according to the
formula:
scan times = (reference time) + n(frequency) + offset
where n is an integer and the reference time is midnight on the
day that the interface was started. In the above example,
frequency is 60 seconds and offset is 5 seconds for the first
scan class. This means that if the interface was started at
05:06:06, the first scan would be at 05:07:05, the second scan
would be at 05:08:05, and so on. Since no offset is specified for
the second scan class, the absolute scan times are undefined.
The definition of a scan class does not guarantee that the
associated points will be scanned at the given frequency. If the
interface is under a large load, then some scans may occur late
or be skipped entirely. See the section “Performance
Summaries” in the UniInt Interface User Manual.doc for more
information on skipped or missed scans.
Sub-second Scan Classes
Sub-second scan classes can be defined on the command-line,

DNP 3.0 Interface 75

Startup Command File

Parameter Description
such as
/f=0.5 /f=00:00:00.1
where the scanning frequency associated with the first scan
class is 0.5 seconds and the scanning frequency associated
with the second scan class is 0.1 of a second.
Similarly, sub-second scan classes with sub-second offsets can
be defined, such as
/f=0.5,0.2 /f=1,0
Wall Clock Scheduling
Scan classes that strictly adhere to wall clock scheduling are
now possible. This feature is available for interfaces that run on
Windows and/or UNIX. Previously, wall clock scheduling was
possible, but not across daylight saving time. For example,
/f=24:00:00,08:00:00 corresponds to 1 scan a day
starting at 8 AM. However, after a Daylight Saving Time change,
the scan would occur either at 7 AM or 9 AM, depending upon
the direction of the time shift. To schedule a scan once a day at
8 AM (even across daylight saving time), use
/f=24:00:00,00:08:00,L. The ,L at the end of the
scan class tells UniInt to use the new wall clock scheduling
algorithm.
/host=host:port The /host parameter is used to specify the PI Home node.
Required Host is the IP address of the PI Sever node or the domain
name of the PI Server node. Port is the port number for
TCP/IP communication. The port is always 5450. It is
recommended to explicitly define the host and port on the
command-line with the /host parameter. Nevertheless, if
either the host or port is not specified, the interface will attempt
to use defaults.

Examples:

The interface is running on a PI Interface Node, the domain

name of the PI home node is Marvin, and the IP address of
Marvin is 206.79.198.30. Valid /host parameters would be:
/host=marvin
/host=marvin:5450
/host=206.79.198.30
/host=206.79.198.30:5450
/id=x The /id parameter is used to specify the interface identifier.
Required The interface identifier is a string that is no longer than 9
characters in length. UniInt concatenates this string to the
header that is used to identify error messages as belonging to a
particular interface. See the Appendix A Error and Informational
Messages for more information.
UniInt always uses the /id parameter in the fashion described
above. This interface also uses the /id parameter to identify a
particular interface copy number that corresponds to an integer
value that is assigned to one of the Location code point
attributes, most frequently Location1. For this interface, use only
numeric characters in the identifier. For example,
/id=1

76
 Parameter Description
/IOPool=# Where # is the number of threads to be used for the IO
Optional completion port pool. If this parameter is not defined, the default
is used.
Default = 2 x Number of logical processors
Minimum = 1
Maximum = 1024
/IOSleep=# Where # is the number of milliseconds to allow the IOCP
Optional threads to sleep between executions. By default, the IOCP
routine does not sleep between executions. This parameter
should not be altered unless the interface process appears to
be utilizing a high percentage of the cpu. In this case, set the
/IOSleep parameter to one and restart the interface.
Default = 0
Minimum = 0
Maximum = 100
/IOTimeOut=# Specifies the length of time, in minutes, allowed to elapse
Optional without a good communication session with a RTU before the
system digital state “IO TimeOut” will be written to all tags
belonging to the RTU. A value of 0 or the absence of the
parameter in the start-up file means “IO TimeOut” will never be
written to the PI tags. A communications session is defined as
receiving a good response to a request or receiving an
unsolicited message from the RTU. The value # is in minutes
and care must be taken when assigning this value. By default,
the default check for an I/O timeout is not performed. If the I/O
timeout value is less or roughly equal to the shortest scan class
frequency and the Integrity Scan frequency, “IO TimeOut” may
be written to the tags shortly before every scan. Therefore, the
value of # must be at least 1.5 times longer than the shortest
scan class frequency or the Integrity Scan frequency whichever
is shorter.
Note: If the interface is configured to receive unsolicited
responses from the RTU, “IO TimeOut” may be written to tags if
values on the RTU do not change frequently enough to send an
unsolicited message to the interface. Therefore, consideration
must be taken whether or not to perform integrity scans at
periodic intervals when assigning a value to this parameter.
Default = 0
Minimum = 0 (Timeout not written)
Maximum = 1440 (1 day in minutes)
/NoDevStatLog When this parameter is defined, the interface does not log the
Optional list of RTUs that have no connection to the interface in the
device status log. However, the number of RTUs in error will still
be listed in the Device Status tag. By default, the RTU(s) that
are in error are logged to a device status log file for the
interface. The maximum size of the log file is 100KB and once
reached the file will then be cleared for new data.
/NoLogRTUParams When this parameter is defined, the interface does not log the
Optional startup parameters for RTUs assigned to the interface. This is
useful to prevent the pipc.log file from becoming difficult to
read when many RTUs are defined for a given instance of the
interface. By default, the startup parameters for each RTU are
listed in the pipc.log file.

DNP 3.0 Interface 77

Startup Command File

Parameter Description
/PISDK=# The /pisdk parameter can be used to enable or disable the
Optional PI SDK in some situations. Use /pisdk=1 to enable the PI
Default = 0 SDK. Use /pisdk=0 to disable the PI SDK. If a particular
interface requires the PI SDK, then the PI SDK will always be
enabled and the /pisdk parameter will be ignored.
If the interface is running on an interface node with the PI API
version 1.6.x or greater and the version of the PI Server is
3.4.370.x or greater, the interface will ignore the /pisdk
parameter and the SDK will not be used to retrieve point
attributes.
/ps=x The /ps parameter specifies the point source for the interface.
Required X is not case sensitive and can be any <single/multiple>
character string. For example, /ps=P and /ps=p are
equivalent. The length of X is limited to 100 characters by
UniInt. X can contain any character except ‘*’ and ‘?’.
The point source that is assigned with the /ps parameter
corresponds to the PointSource attribute of individual PI Points.
The interface will attempt to load only those PI points with the
appropriate point source.
If the PI API version being used is prior to 1.6.x or the PI Server
version is prior to 3.4.370.x, the PointSource is limited to a
single character unless the SDK is being used.
/retry=# Specifies the interval (in seconds) that the interface will make
Optional subsequent attempts to connect to a specific RTU device.
Default: Example:
/retry=30 /retry=20 Retry every 20 seconds
/RTULogSize=# Where # specifies the maximum size of the RTU log file before
Optional the file is cleared for new data. Size in Kilo-Bytes (KB). If the
interface debug level as defined by the /dnpdbg does not
specify logging to the RTU log file (level=0x0001), then the log
file is not created by the interface.
Default = 100 (100KB)
Minimum = 10 (10KB)
Maximum = 10000 (10MB)
/sio The /sio parameter stands for “suppress initial outputs.” The
Optional parameter applies only for interfaces that support outputs. If the
/sio parameter is not specified, the interface will behave in
the following manner.
When the interface is started, the interface determines the
current Snapshot value of each output tag. Next, the interface
writes this value to each output tag. In addition, whenever an
individual output tag is edited while the interface is running, the
interface will write the current Snapshot value to the edited
output tag.
This behavior is suppressed if the /sio parameter is specified
on the command-line. That is, outputs will not be written when
the interface starts or when an output tag is edited. In other
words, when the /sio parameter is specified, outputs will only
be written when they are explicitly triggered.

78
 Parameter Description
/StatusInterval=# Where # specifies interface device status update interval in
Optional seconds.

The user should consider the /retry rate as well as the time
it takes to establish connections with configured devices in
determining the /StatusInterval value. The user should
use an interval that will allow enough time to establish
connection with enough devices to allow the
/StatusPercentUp value to be reached.

Note: When the interface is configured to use UniInt

failover, the setting of the /StatusInterval to an
interval that does not allow enough time to attempt a
reconnection to a device in error could result in the
interface setting the device status to an error
condition prematurely and result in the backup copy
of the interface assuming control.

Default = 1 (1 second)
Minimum = 1 (1 second)
Maximum = 3600 (1 hour)
/StatusKeepState This parameter is only applicable when UniInt Interface Failover
Optional is being used.

The /StatusKeepState parameter when defined will

prevent the backup copy of the interface from assuming the
primary state at an interval specified by the location5 attribute of
the ActiveID tag when the value of both failover copies of the
interface have equal device status values and neither interface
is able to collect data while in the primary state. The interface
does this by writing a value of 30 to the device status.

The UniInt device status health tag accepts values in the range
of 0-100; whereby a value of 0 represents a good status value.
Any value less than 50 will prevent the backup copy of the
interface instance from assuming control if the device status
values of the failover instances are equal in error value. A value
of 50 -70 will allow the backup copy of the interface to assume
control, at an interval specified by the location5 attribute of the
ActiveID tag, if the device status values of the failover instances
are equal

Default = not defined

DNP 3.0 Interface 79

Startup Command File

Parameter Description
/StatusPercentUp=# Where # specifies the minimum percent of connected devices
Optional for reporting a good device status.

All configurations:
The interface will write a value of good to the UniInt device
status health tag if the percent of connected devices is equal to
or greater than the /StatusPercentUp value.

If the /StatusPercentUp=0, the interface will always

report a status of good.

UniInt failover:
The interface will report a status value of 50 if the percent of
connected devices is less than the /StatusPercentUp
value. If the /StatusKeepState parameter is defined, the
interface will report a status value of 30 if the percent of
connected devices is less than the /StatusPercentUp
value.

The /StatusPercentUp=0 is useful during a UniInt failover

configuration if the user wants the other interface to assume the
role as primary only if the heartbeat of this copy of the interface
fails to update (i.e. this copy is shutdown, crashes, or enters a
locked state).

Default = 100 (100%)

Minimum = 0 (0%)
Maximum = 100 (100%)
/StatusUpdateDelay=# Where # specifies the time in seconds before the interface will
Optional set the device status upon initial startup or upon assuming the
role as primary if running in a UniInt failover configuration.

Default = 0 (no delay)

Minimum = 0
Maximum = 600 (10 minutes)
/stopstat=digstate If /stopstat=digstate is present on the command line,
or then the digital state, digstate, will be written to each PI
/stopstat Point when the interface is stopped. For a PI 3 Server,
digstate must be in the system digital state table. . UniInt
will use the first occurrence of digstate found in the table.
/stopstat only is
If the /stopstat parameter is present on the startup
equivalent to
command line, then the digital state “Intf Shut” will be
/stopstat=”Intf
written to each PI Point when the interface is stopped.
Shut”
If neither /stopstat nor /stopstat=digstate is
specified on the command line, then no digital states will be
Optional written when the interface is shut down.
Default = no digital state Examples:
written at shutdown.
/stopstat=shutdown
/stopstat=”Intf Shut”
The entire digstate value should be enclosed within double
quotes when there is a space in digstate.

80
 Parameter Description
/WorkerPool=# Where # is the number of threads to be used for the worker
Optional pool. If this parameter is not defined, no worker pool is created.
Default = 1
Minimum = 0
Maximum = 1024
/xml=<UNCPath> Specifies the name and path of the XML configuration file to be
Required used by the interface. If there are spaces in the name or path,
then the name and path must be enclosed in quotation marks.
Example:
/xml=C:\pipc\interfaces\pidnp3\PIDNP3.xml
Example:
/xml=”C:\Program
Files\interfaces\pidnp3\PIDNP3.xml”

Sample PIDNP3.bat File

The following is an example file:
REM ==================================================================
REM PIDNP3.bat
REM
REM Sample startup file for the PI DNP3 Interface
REM
REM ==================================================================
REM
REM OSIsoft strongly recommends using PI ICU to modify startup files.
REM
REM Sample command line
REM
PIDNP3.exe /host=XXXXXX:5450 /ps=P /id=1 ^
/xml=C:\PIPC\Interfaces\PIDNP3\PIDNP3.xml ^
/f=5 /f=10 /f=00:10:00
REM
REM End of PIDNP3.bat File

DNP 3.0 Interface 81

Chapter 10. Device Configuration (XML) File

The interface uses a configuration file to set up the internal operation of the interface. The
configuration file is written in XML format. The XML file can be created and/or edited using
a text editor such as Notepad or a third party XML editor. The PI DNP3 ICU Control can
create the XML file for the user if it does not already exist.

Note: Users of the PI DNP3 interface prior to version 2.0.0.0 must modify the
interface XML configuration file to the format indicated in this section of this manual.
The XML file is only read once during start up. If changes need to be made to the
file, the interface will need to be stopped and restarted in order for the changes to be
recognized.

XML Overview

XML follows a similar pattern to HTML. The structure used by both languages is described
as being tree-like. This is because the structure branches in many different directions, where
each branch may contain other branches. Angle brackets, <>, are used to specify the
beginning and end of a node. The beginning of a node looks like <node> and the end as
</node>. There must be a beginning and end to every node. The first node of an XML
document is referred to as the root node. Nodes that are contained between the opening and
closing of a node are called child nodes. The parameters surrounded by square brackets [ ] are
optional:
<node [attributename=”value”]>
<child [attributename=”value”]>
</child>
</node>

Each node has a name associated with it. In the example above, the name of the root node
would be node and the name of the child element would be child.
Nodes can also have attributes. The format for an attribute has the following layout.
AttributeName=”AttributeValue”.

The attribute value is always enclosed in quotations and is treated internally as a string but
can be converted to any other data type. An attribute looks like the following.
<node Attribute=”2”></node>

The value of this Attribute is 2. A node can also have elements. Elements appear the same
as nodes, except that they have loose text between the opening and closing of the node. The
value of the element is treated internally as a string but can be converted to any other data
type. Unlike an attribute value, an element value is not enclosed in quotations.

DNP 3.0 Interface 83

 An example of an element is shown below.
<node Attribute=”2”>
<child ID=”1”>
<Element>myText</Element>
<child ID=”2”>
<Element>3</Element>
</child>
</child>
</node>

In the example above, the element of the first child is the string myText. Note that child nodes
can contain other child nodes, thus, forming the tree structure. The second child nodes
element has 3 as its text value.
The short form of a node that has no child nodes or elements appears in the following form.
<Name Attributes… />

This format does not require a closing node. It only requires the opening node as long as it
ends with a forward slash.

PIDNP3 XML Nodes, Elements, and Attributes

There are three major nodes that must be included in the PI DNP3 XML configuration file.
The nodes are the Root, IOGroup, and RTU nodes.

Root Node
The root node must be named PIDNP.Session.
Root Node Attribute Description
Address This specifies the PI DNP3 interface 16-bit DNP3 master address. This
Required will be the Master Address on the network. The user must choose an
address that is unique on the DNP network.
Some RTUs will need to be configured to specifically respond to this
address.
DLRetries This is the number of times to retry when waiting on an ACK to a Data-
Optional Link message request.
If connecting to multiple RTUs, set this value to zero to improve interface
performance.
Valid range {0 – 15}
Default: 3
ALRetries This is the number of times to retry when waiting on an ACK to an
Optional Application layer message request.
If connecting to multiple RTUs, set this value to zero or one to improve
interface performance.
Valid range {0 – 15}
Default: 3
Example: <PIDNP.Session Address=”1” DLRetries=”3” ALRetries=”3”

Note: To improve interface performance, it is recommended to set the XML file

DLRetries and ALRetries equal to zero when connecting to multiple RTUs.

DNP 3.0 Interface 84

 IOGroup Nodes
Child nodes of the root node are IOGroup nodes. The IOGroup nodes are used to specify the
properties of a physical device such as a communication port, or TCP port. The IOGroup node
has one attribute, Type. The type must be either Serial or TCP. The child nodes will depend
on the type. A serial communications port will have different child nodes from a TCP port.
The IOGroup is also used to group RTUs together that communicate through the same serial
port. Each Serial IOGroup node will have one or more RTUInfo child nodes. Each of the
RTUInfo nodes will represent a RTU that the PI DNP3 interface will communicate with
through the physical port described by the IOGroup child nodes. For TCP Input/Output, there
must only be one RTUInfo child node per IOGroup. There are at least 64000 TCP ports
available on a machine that supports TCP/IP. It takes overhead both on the server side and on
the client side to release and reacquire a TCP socket. For this reason, they should not share
the connection and each RTU that communicates via TCP should be assigned to its own
IOGroup thereby acquiring its own port on the interface machine. However, different TCP/IP
IOGroup Nodes can have the same IP Address as long as they have different assigned Port
numbers.
IOGroup Child Nodes Description
for Type=”Serial”
Example: <IOGroup Type=”Serial”>
Port The numeric value of the serial COM port to use. For example if using
Required COM1 set this value to 1.
Valid range: {1 – Max Port}
Example: <Port>1</Port>
Baud The speed at which to communicate.
Optional The default value is 9600.
Valid range: {See serial specification}
Default: <Baud>9600</Baud>
Parity The error checking parity to use. This can be 2 for even, 1 for odd, and 0
Optional for none.
Valid range: {0,1,2}
Default: <Baud>0</Baud>
DataBits The number of data bits.
Optional The default value is 8.
Valid range: {See serial specification}
Default: <DataBits>8</DataBits>
StopBits The number of stop bits following a message. This can be 1 for one, 2
Optional for two, or 3 for one and a half stop bits.
Valid range: {1,2,3}
Default: <StopBits>1</StopBits>

DNP 3.0 Interface 85

Device Configuration (XML) File

IOGroup Child Nodes Description

for Type=”TCP”
Example: <IOGroup Type=”TCP”>
IP The Host name or IP address of the RTU.
Required if TCP Valid range: {Any valid address or name}
Example: <IP>192.164.55.128</IP>
Port The TCP/IP port to use for communication.
Optional Valid range: {0 – Max Port Number}
Default: <Port>20000</Port>

RTUInfo Nodes
The RTUInfo node is a child of the IOGroup node. This node describes the information
specific for a single RTU. The IOGroup node can have one or more RTUInfo nodes.
RTUInfo Child Nodes Description
Address The DNP address of the device.
Required Valid range: {0 – Max Integer}
Example: <Address>100</Address>
ClearRestart If set to a value of 1, the interface will attempt to clear the RTU
Optional Restart Internal Indication (IIN) bit if it is set.
Valid range: {0,1} 0 means do not clear restart IIN bit
1 means clear restart IIN bit
Default: <ClearRestart>0</ClearRestart>
Example: <ClearRestart>1</ClearRestart>
CloseOnDataError TCP connection only. If set to a value of 1, the interface will close and
Optional reestablish a new TCP connection to the RTU when the maximum
retyr attempts for data failed to retrieve data from the RTU.
Valid range: {0,1} 0 means do not close TCP connection on error
1 means close TCP connection on error.
Default: <CloseOnDataError>0</CloseOnDataError>
Example: <CloseOnDataError>1</CloseOnDataError>
IntegrityReconnect Specifies if the interface must perform an integrity scan on the RTU
Optional on reconnection with the RTU after a communications failure. For this
attribute to be effective, the “IntegrityScan” attribute must be set to a
value greater than zero.
Meanings:
0 – No integrity scan on reconnect
1 – Perform an integrity scan on reconnect
Valid range: {0,1}
Default:
<IntegrityReconnect>0</IntegrityReconnect>
Example:
<IntegrityReconnect>1</IntegrityReconnect>

86
 RTUInfo Child Nodes Description
IntegrityScan Specifies in minutes how often an integrity scan is performed. An
Optional integrity scan will only be performed if this attribute is set to
something other than zero. If the value is greater than zero, then an
integrity scan will be performed at start-up and then at the frequency
configured with this attribute.
Valid range: {0 – Max Integer}
Default: <IntegrityScan>10</ IntegrityScan>
Example: <IntegrityScan>0</ IntegrityScan>
NoResetLinkReply If set to a value of 1, the interface will not wait for the RTU to reply to
Optional a Reset Link request sent by the interface.
NOTE: This attribute should only be used for RTUs that may not be
DNP3 compliant. Typically, a RTU must reply to a received Reset
Link request. See Appendix D for additional details on using this
attribute.
Valid range: {0,1} 0 means wait for a reply
1 means do not wait for a reply
Default: <NoResetLinkReply>0</NoResetLinkReply>
Example: <NoResetLinkReply>1</NoResetLinkReply>
NoResetLinkOnCrcError If set to a value of 1, the interface will not attempt to call Reset Link
Optional on an RTU with a CRC error in the RTU response.
Valid range: {0,1} 0 means call Reset Link
1 means do not call Reset Link
Default: < NoResetLinkOnCrcError>0</
NoResetLinkOnCrcError>
Example: < NoResetLinkOnCrcError>1</
NoResetLinkOnCrcError>
ReadTimeout In milliseconds, the amount of time to wait for an entire message to
Optional be sent across the network. Depending on the type of network, this
value may need to be increased to avoid a timeout.
Valid range: {250 – 60000}
Default: <ReadTimeout>2000</ReadTimeout>
Example: <ReadTimeout>5000</ReadTimeout>
RequestQualifier Specifies the DNP3 qualifier that the interface will use when sending
Optional requests for static data. The default value is “1”. There are some field
RTUs that only support the “No Range Field” qualifier. In this case,
the RTU must use a request qualifier “6” value.
If the request qualifier is set to a value of 0,1, or 2, the interface will
use the smallest possible qualifier code as based on the largest index
number of the requested object. If the request qualifier is set to “6”,
the interface will always use this qualifier value for RTU requests.
Meanings:
0 – One Octet Start and Stop Indices
1 – Two Octet Start and Stop Indices
2 – Four Octet Start and Stop Indices
6 – No Range Field (all of a given type)
The default value is 1, two octet start and stop indices.
Valid range: {0,1,2,6}
Default: <RequestQualifier>1</RequestQualifier>
Example: <RequestQualifier>6</RequestQualifier>

DNP 3.0 Interface 87

Device Configuration (XML) File

RTUInfo Child Nodes Description

RtuName The name assigned to this RTU. This attribute is only used for
Optional message logging. If the attribute is not defined, the default name of
“DNP3_Device” will be used. It is not necessary to enclose the name
in quotes
Default: <RtuName>DNP3_Device</RtuName>
Example: <RtuName>ION8400_Stubby</RtuName>
TimeSource The TimeSource node is used to identify the source of the
Optional timestamp for event data. There are three valid values that can be
used in the type parameter of this node; RTU, Adjusted, and PI.
Valid range: {RTU, Adjusted, PI }
Default: <TimeSource>RTU</TimeSource>
Example: <TimeSource>PI</TimeSource>
TimeSync The TimeSync node determines if the RTU time is synchronized
Optional with the PI Server time, whether the RTU time is configured as local
Format: or UTC1, and if the interface should automatically synchronize the
freq:type:autotime RTU if the “NEED TIME” bit is set in the Internal Indications (IIN) of
the RTU.
All values sent to the PI server will be time-stamped with a UTC time.
The freq parameter of this node specifies how often the time on the
RTU will be synchronized with the time from the PI Server. If freq is
defined to be zero, then the time on the RTU will never be
synchronized. If freq is greater than zero, then the RTU time will be
synchronized when the interface starts and every freq hours
thereafter. The type parameter of the TimeSync node informs the
interface of whether the RTU is configured in local or in UTC time.
The two valid values for the type parameter are UTC and Local.
Knowing if the RTU is configured for UTC or Local serves two
purposes. First, configuration informs the interface about what time
format must be sent to the RTU during time synchronizations.
Secondly, it allows the interface to correctly adjust the timestamp of
event data received from the RTU.
If the autotime parameter is set to ‘1’, then the interface will attempt to
time synchronize the RTU if the “NEED TIME” bit is set in the Internal
Indications (IIN) of the RTU regardless of when the last
synchronization occurred.
Freq valid range: {0-65535}
Type valid range: {UTC, LOCAL}
Autotime valid range: {0,1}
Default: <TimeSync>0:UTC:0</TimeSync>
Means: no timesynching, rtu is UTC, autotime disabled
Example: <TimeSync>0:Local:1</TimeSync>
Means: no timesynching, rtu is Local, autotime enabled
Example: <TimeSync>1:Local:1</TimeSync>
Means: timesynching, rtu is Local, autotime enabled
Backward Compatibility. The DNP3 interface version 1.4.x TimeSync
supports the previous version’s way of only entering a number for the
hours. If the parameter appears in the XML file as
<TimeSync>12</TimeSync>, then the time synchronize
frequency is every 12 hours and the RTU time is assumed to be UTC.

88
 RTUInfo Child Nodes Description
Unsolicited The Unsolicited node sets the interface configuration for
Optional unsolicited messages from the RTU.
Meanings:
0 – Do not enable unsolicited messages from RTU
1 – Enable unsolicited messages from RTU
Valid range {0,1}
Default: < Unsolicited>0</Unsolicited>
Example: < Unsolicited>0</Unsolicited>
Example: < Unsolicited>1</Unsolicited>
1 Coordinated Universal Time – (UTC, World Time) The standard time common to every place in
the world. UTC is derived from International Atomic Time (TAI) by the addition of a whole number
of “leap seconds.”

Sample PIDNP3.xml File

<PIDNP.Session Address=”1” DLRetries=”3” ALRetries=”3”>
<IOGroup Type=Serial>
<Port>1</Port>
<Baud>19200</Baud>
<Parity>0</Parity>
<DataBits>8</DataBits>
<StopBits>1</StopBits>
<RTUInfo>
<Address>123</Address>
<IntegrityScan>1</IntegrityScan>
<IntegrityReconnect>0</IntegrityReconnect>
<ReadTimeout>5000</ReadTimeout>
<TimeSync>7:UTC:1</TimeSync>
<RequestQualifier>1</RequestQualifier>
</RTUInfo>
<RTUInfo>
<Address>238</Address>
<IntegrityScan>1</IntegrityScan>
<TimeSync>11:Local</TimeSync>
<RequestQualifier>6</RequestQualifier>
</RTUInfo>
</IOGroup>
<IOGroup Type=”TCP”>
<IP>savtest03</IP>
<Port>20000</Port>
<RTUInfo>
<Address>3</Address>
<IntegrityScan>20</IntegrityScan>
<IntegrityReconnect>1</IntegrityReconnect>
<TimeSync>0:Local:1</TimeSync>
<TimeSource>PI</TimeSource>
<RequestQualifier>1</RequestQualifier>
</RTUInfo>
</IOGroup>
<IOGroup Type=TCP>
<IP>192.168.45.68</IP>
<Port>20000</Port>
<RTUInfo>
<Address>4</Address>
<IntegrityScan>1</IntegrityScan>
<TimeSync>12:UTC</TimeSync>
<TimeSource>RTU</TimeSource>
<RequestQualifier>6</RequestQualifier>
</RTUInfo>
</IOGroup>
DNP 3.0 Interface 89
Device Configuration (XML) File

</PIDNP.Session>

90
Chapter 11. UniInt Failover Configuration

Introduction
To minimize data loss during a single point of failure within a system, UniInt provides two
failover schemas: (1) synchronization through the data source and (2) synchronization
through a shared file. Synchronization through the data source is Phase 1, and
synchronization through a shared file is Phase 2.
Phase 1 UniInt Failover uses the data source itself to synchronize failover operations and
provides a hot failover, no data loss solution when a single point of failure occurs. For this
option, the data source must be able to communicate with and provide data for two interfaces
simultaneously. Additionally, the failover configuration requires the interface to support
outputs.
Phase 2 UniInt Failover uses a shared file to synchronize failover operations and provides for
hot, warm, or cold failover. The Phase 2 hot failover configuration provides a no data loss
solution for a single point of failure similar to Phase 1. However, in warm and cold failover
configurations, you can expect a small period of data loss during a single point of failure
transition.

Note: This interface supports only Phase 2 failover.

You can also configure the UniInt interface level failover to send data to a High Availability
(HA) PI Server collective. The collective provides redundant PI Servers to allow for the
uninterrupted collection and presentation of PI time series data. In an HA configuration,
PI Servers can be taken down for maintenance or repair. The HA PI Server collective is
described in the PI Server Reference Guide.
When configured for UniInt failover, the interface routes all PI data through a state machine.
The state machine determines whether to queue data or send it directly to PI depending on the
current state of the interface. When the interface is in the active state, data sent through the
interface gets routed directly to PI. In the backup state, data from the interface gets queued
for a short period. Queued data in the backup interface ensures a no-data loss failover under
normal circumstances for Phase 1 and for the hot failover configuration of Phase 2. The same
algorithm of queuing events while in backup is used for output data.

DNP 3.0 Interface 91

 Quick Overview
The Quick Overview below may be used to configure this Interface for failover. The failover
configuration requires the two copies of the interface participating in failover be installed on
different nodes. Users should verify non-failover interface operation as discussed in the
Installation Checklist section of this manual prior to configuring the interface for failover
operations. If you are not familiar with UniInt failover configuration, return to this section
after reading the rest of the UniInt Failover Configuration section in detail. If a failure occurs
at any step below, correct the error and start again at the beginning of step 6 Test in the table
below. For the discussion below, the first copy of the interface configured and tested will be
considered the primary interface and the second copy of the interface configured will be the
backup interface.

Configuration
 One Data Source
 Two Interfaces

Prerequisites
 Interface 1 is the Primary interface for collection of PI data from the data source.
 Interface 2 is the Backup interface for collection of PI data from the data source.
 You must setup a shared file if using Phase 2 failover..
 Phase 2: The shared file must store data for five failover tags:
(1) Active ID.
(2) Heartbeat 1.
(3) Heartbeat 2.
(4) Device Status 1.
(5) Device Status 2.
 Each interface must be configured with two required failover command line
parameters: (1) its FailoverID number ( /UFO_ID); (2) the FailoverID number of its
Backup interface (/UFO_OtherID). You must also specify the name of the PI Server
host for exceptions and PI tag updates.
 All other configuration parameters for the two interfaces must be identical.

DNP 3.0 Interface 92

 Synchronization through a Shared File (Phase 2)

Figure 1: Synchronization through a Shared File (Phase 2) Failover Architecture

The Phase 2 failover architecture is shown in Figure 2 which depicts a typical network setup
including the path to the synchronization file located on a File Server (FileSvr). Other
configurations may be supported and this figure is used only as an example for the following
discussion.
For a more detailed explanation of this synchronization method, see Detailed Explanation of
Synchronization through a Shared File (Phase 2)

DNP 3.0 Interface 93

UniInt Failover Configuration

Configuring Synchronization through a Shared File (Phase 2)

Step Description
1. Verify non-failover interface operation as described in the Installation Checklist section of
this manual
2. Configure the Shared File
Choose a location for the shared file. The file can reside on one of the interface nodes or
on a separate node from the Interfaces; however OSIsoft strongly recommends that you
put the file on a Windows Server platform that has the “File Server” role configured. .
Setup a file share and make sure to assign the permissions so that both Primary and
Backup interfaces have read/write access to the file.
3. Configure the interface parameters
Use the Failover section of the Interface Configuration Utility (ICU) to enable failover and
create two parameters for each interface: (1) a Failover ID number for the interface; and
(2) the Failover ID number for its backup interface.
The Failover ID for each interface must be unique and each interface must know the
Failover ID of its backup interface.
If the interface can perform using either Phase 1 or Phase 2 pick the Phase 2 radio button
in the ICU.
Select the synchronization File Path and File to use for Failover.
Select the type of failover required (Cold, Warm, Hot). The choice depends on what types
of failover the interface supports.
Ensure that the user name assigned in the “Log on as:” parameter in the Service section
of the ICU is a user that has read/write access to the folder where the shared file will
reside.
All other command line parameters for the primary and secondary interfaces must be
identical.
If you use a PI Collective, you must point the primary and secondary interfaces to different
members of the collective by setting the SDK Member under the PI Host Information
section of the ICU.
[Option] Set the update rate for the heartbeat point if you need a value other than the
default of 5000 milliseconds.
4. Configure the PI tags
Configure five PI tags for the interface: the Active ID, Heartbeat 1, Heartbeat2, Device
Status 1 and Device Status 2. You can also configure two state tags for monitoring the
status of the interfaces.
Do not confuse the failover Device status tags with the UniInt Health Device Status tags.
The information in the two tags is similar, but the failover device status tags are integer
values and the health device status tags are string values.
Tag ExDesc digitalset UniInt does not
examine the
ActiveID [UFO2_ACTIVEID] remaining attributes,
IF1_Heartbeat but the pointsource
(IF-Node1) [UFO2_HEARTBEAT:#] and location1 must
IF2_Heartbeat match
(IF-Node2) [UFO2_HEARTBEAT:#]
IF1_DeviceStatus
(IF-Node1) [UFO2_DEVICESTAT:#]
IF2_DeviceStatus
(IF-Node2) [UFO2_DEVICESTAT:#]
IF1_State [UFO2_STATE:#] IF_State
(IF-Node1)

94
 Step Description
Tag ExDesc digitalset UniInt does not
examine the
IF2_State
remaining attributes,
(IF-Node2) [UFO2_STATE:#] IF_State
but the pointsource
5. Test the configuration.
After configuring the shared file and the interface and PI tags, the interface should be
ready to run.
See Troubleshooting UniInt Failover for help resolving Failover issues.
1. Start the primary interface interactively without buffering.
2. Verify a successful interface start by reviewing the pipc.log file. The log
file will contain messages that indicate the failover state of the interface. A
successful start with only a single interface copy running will be indicated by
an informational message stating “UniInt failover: Interface in
the “Primary” state and actively sending data to PI.
Backup interface not available.” If the interface has failed to start,
an error message will appear in the log file. For details relating to
informational and error messages, refer to the Messages section below.
3. Verify data on the PI Server using available PI tools.
 The Active ID control tag on the PI Server must be set to the value of
the running copy of the interface as defined by the /UFO_ID startup
command-line parameter.
 The Heartbeat control tag on the PI Server must be changing values at
a rate specified by the /UFO_Interval startup command-line
parameter.
4. Stop the primary interface.
5. Start the backup interface interactively without buffering. Notice that this copy
will become the primary because the other copy is stopped.
6. Repeat steps 2, 3, and 4.
7. Stop the backup interface.
8. Start buffering.
9. Start the primary interface interactively.
10. Once the primary interface has successfully started and is collecting data,
start the backup interface interactively.
11. Verify that both copies of the interface are running in a failover configuration.
 Review the pipc.log file for the copy of the interface that was started
first. The log file will contain messages that indicate the failover state of
the interface. The state of this interface must have changed as
indicated with an informational message stating “UniInt failover:
Interface in the “Primary” state and actively sending
data to PI. Backup interface available.” If the interface
has not changed to this state, browse the log file for error messages.
For details relating to informational and error messages, refer to the
Messages section below.
 Review the pipc.log file for the copy of the interface that was started
last. The log file will contain messages that indicate the failover state of
the interface. A successful start of the interface will be indicated by an
informational message stating “UniInt failover: Interface in
the “Backup” state.” If the interface has failed to start, an error
message will appear in the log file. For details relating to informational
and error messages, refer to the Messages section below.

DNP 3.0 Interface 95

UniInt Failover Configuration

Step Description
12. Verify data on the PI Server using available PI tools.
 The Active ID control tag on the PI Server must be set to the value of
the running copy of the interface that was started first as defined by the
/UFO_ID startup command-line parameter.
 The Heartbeat control tags for both copies of the interface on the PI
Server must be changing values at a rate specified by the
/UFO_Interval startup command-line parameter or the scan class
which the points have been built against.
13. Test Failover by stopping the primary interface.
14. Verify the backup interface has assumed the role of primary by searching the
pipc.log file for a message indicating the backup interface has changed to
the “UniInt failover: Interface in the “Primary” state and
actively sending data to PI. Backup interface not
available.” The backup interface is now considered primary and the
previous primary interface is now backup.
15. Verify no loss of data in PI. There may be an overlap of data due to the
queuing of data. However, there must be no data loss.
16. Start the backup interface. Once the primary interface detects a backup
interface, the primary interface will now change state indicating “UniInt
failover: Interface in the “Primary” state and actively
sending data to PI. Backup interface available.” In the
pipc.log file.
17. Verify the backup interface starts and assumes the role of backup. A
successful start of the backup interface will be indicated by an informational
message stating “UniInt failover: Interface in “Backup
state.” Since this is the initial state of the interface, the informational
message will be near the beginning of the start sequence of the pipc.log
file.
18. Test failover with different failure scenarios (e.g. loss of PI connection for a
single interface copy). UniInt failover guarantees no data loss with a single
point of failure. Verify no data loss by checking the data in PI and on the data
source.
19. Stop both copies of the interface, start buffering, start each interface as a
service.
20. Verify data as stated above.
21. To designate a specific interface as primary. Set the Active ID point on the
Data Source Server of the desired primary interface as defined by the
/UFO_ID startup command-line parameter.

96
 Configuring UniInt Failover through a Shared File (Phase 2)

Start-Up Parameters

Note: The /stopstat parameter is disabled If the interface is running in a UniInt

failover configuration. Therefore, the digital state, digstate, will not be written to
each PI Point when the interface is stopped. This prevents the digital state being
written to PI Points while a redundant system is also writing data to the same PI
Points. The /stopstat parameter is disabled even if there is only one interface
active in the failover configuration.

The following table lists the start-up parameters used by UniInt Failover Phase 2. All of the
parameters are required except the /UFO_Interval startup parameter. See the table below
for further explanation.
Parameter Required/ Description Value/Default
Optional
/UFO_ID=# Required Failover ID for IF-Node1 Any positive, non-
This value must be different from zero integer / 1
the failover ID of IF-Node2.
Required Failover ID for IF-Node2 Any positive, non-
This value must be different from zero integer / 2
the failover ID of IF-Node1.
/UFO_OtherID=# Required Other Failover ID for IF-Node1 Same value as
The value must be equal to the Failover ID for
Failover ID configured for the IF-Node2 / 2
interface on IF-Node2.
Required Other Failover ID for IF-Node2 Same value as
The value must be equal to the Failover ID for
Failover ID configured for the IF-Node1 / 1
interface on IF-Node1.
/UFO_Sync= Required for The Failover File Synchronization Any valid pathname /
path/[filename] Phase 2 Filepath and Optional Filename any valid filename
synchronization specify the path to the shared file The default filename
used for failover synchronization is generated as
and an optional filename used to executablename_
specify a user defined filename in pointsource_
lieu of the default filename.
interfaceID.dat
The path to the shared file
directory can be a fully qualified
machine name and directory, a
mapped drive letter, or a local path
if the shared file is on one of the
interface nodes. The path must be
terminated by a slash ( / ) or
backslash ( \ ) character. If no
terminating slash is found, in the
/UFO_Sync parameter, the
interface interprets the final
character string as an optional
filename.
The optional filename can be any
valid filename. If the file does not

DNP 3.0 Interface 97

UniInt Failover Configuration

Parameter Required/ Description Value/Default

Optional
exist, the first interface to start
attempts to create the file.
Note: If using the optional
filename, do not supply a
terminating slash or backslash
character.
If there are any spaces in the path
or filename, the entire path and
filename must be enclosed in
quotes.
Note: If you use the backslash
and path separators and enclose
the path in double quotes, the final
backslash must be a double
backslash (\\). Otherwise the
closing double quote becomes
part of the parameter instead of a
parameter separator.
Each node in the failover
configuration must specify the
same path and filename and must
have read, write, and file creation
rights to the shared directory
specified by the path parameter.
The service that the interface runs
against must specify a valid logon
user account under the “Log On”
tab for the service properties.
/UFO_Type=type Required The Failover Type indicates which COLD|WARM|HOT /
type of failover configuration the COLD
interface will run. The valid types
for failover are HOT, WARM, and
COLD configurations.
If an interface does not supported
the requested type of failover, the
interface will shutdown and log an
error to the pipc.log file stating
the requested failover type is not
supported.
/UFO_Interval=# Optional Failover Update Interval 50 - 20000 / 1000
Specifies the heartbeat Update
Interval in milliseconds and must
be the same on both interface
computers.
This is the rate at which UniInt
updates the Failover Heartbeat
tags as well as how often UniInt
checks on the status of the other
copy of the interface.

98
 Parameter Required/ Description Value/Default
Optional
/Host=server Required Host PI Server for Exceptions and For IF-Node1
PI tag updates PrimaryPI / None
The value of the /Host startup For IF-Node2
parameter depends on the SecondaryPI / None
PI Server configuration. If the
PI Server is not part of a collective,
the value of /Host must be
identical on both interface
computers.
If the redundant interfaces are
being configured to send data to a
PI Server collective, the value of
the /Host parameters on the
different interface nodes should
equal to different members of the
collective.
This parameter ensures that
outputs continue to be sent to the
Data Source if one of the
PI Servers becomes unavailable
for any reason.

Failover Control Points

The following table describes the points that are required to manage failover. In Phase 2
Failover, these points are located in a data file shared by the Primary and Backup interfaces.
OSIsoft recommends that you locate the shared file on a dedicated server that has no other
role in data collection. This avoids potential resource contention and processing degradation
if your system monitors a large number of data points at a high frequency.
Point Description Value / Default
ActiveID Monitored by the interfaces to determine which From 0 to the highest
interface is currently sending data to PI. Interface Failover ID
ActiveID must be initialized so that when the number / None)
interfaces read it for the first time, it is not an Updated by the
error. redundant Interfaces
ActiveID can also be used to force failover. For Can be changed
example, if the current Primary is IF-Node 1 and manually to initiate a
ActiveID is 1, you can manually change manual failover
ActiveID to 2. This causes the interface at IF-
Node2 to transition to the primary role and the
interface at IF-Node1 to transition to the backup
role.
Heartbeat 1 Updated periodically by the interface on Values range between
IF-Node1. The interface on IF-Node2 monitors 0 and 31 / None
this value to determine if the interface on Updated by the
IF-Node1 has become unresponsive. Interface on IF-Node1
Heartbeat 2 Updated periodically by the interface on IF- Values range between
Node2. The interface on IF-Node1 monitors this 0 and 31 / None
value to determine if the interface on IF-Node2 Updated by the
has become unresponsive. Interface on IF-Node2

DNP 3.0 Interface 99

UniInt Failover Configuration

PI Tags

The following tables list the required UniInt Failover Control PI tags, the values they will
receive, and descriptions.

Active_ID Tag Configuration

Attributes ActiveID
Tag <Intf>_ActiveID
Compmax 0
ExDesc [UFO2_ActiveID]
Location1 Match # in /id=#
Location5 Optional, Time in min to wait for backup
to collect data before failing over.
Point Source Match x in /ps=x
Point Type Int32
Shutdown 0
Step 1

Heartbeat and Device Status Tag Configuration

Attribute Heartbeat 1 Heartbeat 2 DeviceStatus 1 DeviceStatus 2
Tag <HB1> <HB2> <DS1> <DS2>
[UFO2_Heartbeat:#] [UFO2_Heartbeat:#] [UFO2_DeviceStat:#] [UFO2_DeviceStat:#]
ExDesc Match # in Match # in Match # in Match # in
/UFO_ID=# /UFO_OtherID=# /UFO_ID=# /UFO_OtherID=#
Location1 Match # in /id=# Match # in /id=# Match # in /id=# Match # in /id=#
Location5 Optional, Time in Optional, Time in Optional, Time in Optional, Time in
min to wait for min to wait for min to wait for min to wait for
backup to collect backup to collect backup to collect backup to collect
data before failing data before failing data before failing data before failing
over. over. over. over.
Point
Match x in /ps=x Match x in /ps=x Match x in /ps=x Match x in /ps=x
Source
Point Type int32 int32 int32 int32
Shutdown 0 0 0 0
Step 1 1 1 1

100
 Interface State Tag Configuration
Attribute Primary Backup
Tag <Tagname1> <Tagname2>
Compmax 0 0
DigitalSet UFO_State UFO_State
ExDesc [UFO2_State:#] [UFO2_State:#]
(Match /UFO_ID=# on primary node) (Match /UFO_ID=# on backup node)
Location1 Match # in /id=# Same as for Primary node
PointSource Match x in /ps=x Same as for Primary node
PointType digital digital
Shutdown 0 0
Step 1 1

The following table describes the extended descriptor for the above PI tags in more detail.
PI Tag ExDesc Required / Description Value
Optional
[UFO2_ACTIVEID] Required Active ID tag 0 - highest
The ExDesc must start with the Interface Failover
case sensitive string: ID
[UFO2_ACTIVEID]. Updated by the
The pointsource must match the redundant
interfaces’ point source. Interfaces
Location1 must match the ID for the
interfaces.
Location5 is the COLD failover retry
interval in minutes. This can be
used to specify how long before an
interface retries to connect to the
device in a COLD failover
configuration. (See the description
of COLD failover retry interval for a
detailed explanation.)
[UFO2_HEARTBEAT:#] Required Heartbeat 1 Tag 0 - 31 / None
(IF-Node1) The ExDesc must start with the Updated by the
case sensitive string: Interface on
[UFO2_HEARTBEAT:#] IF-Node1
The number following the colon (:)
must be the Failover ID for the
interface running on IF-Node1.
The pointsource must match the
interfaces’ point source.
Location1 must match the ID for the
interfaces.

DNP 3.0 Interface 101

UniInt Failover Configuration

PI Tag ExDesc Required / Description Value

Optional
[UFO2_HEARTBEAT:#] Required Heartbeat 2 Tag 0 - 31 / None
(IF-Node2) The ExDesc must start with the Updated by the
case sensitive string: Interface on
[UFO2_HEARTBEAT:#] IF-Node2
The number following the colon (:)
must be the Failover ID for the
interface running on IF-Node2.
The pointsource must match the
interfaces’ point source.
Location1 must match the id for the
interfaces.
[UFO2_DEVICESTAT :#] Required Device Status 1 Tag 0 - 99 / None
(IF-Node1) The ExDesc must start with the Updated by the
case sensitive string: Interface on
[UFO2_HEARTBEAT:#] IF-Node1
The value following the colon (:)
must be the Failover ID for the
interface running on IF-Node1
The pointsource must match the
interfaces’ point source.
Location1 must match the id for the
interfaces.
A lower value is a better status and
the interface with the lower status
will attempt to become the primary
interface.
The failover 1 device status tag is
very similar to the UniInt Health
Device Status tag except the data
written to this tag are integer
values. A value of 0 is good and a
value of 99 is OFF. Any value
between these two extremes may
result in a failover. The interface
client code updates these values
when the health device status tag is
updated.
[UFO2_DEVICESTAT :#] Required Device Status 2 Tag 0 - 99 / None
(IF-Node2) The ExDesc must start with the Updated by the
case sensitive string: Interface on
[UFO2_HEARTBEAT:#] IF-Node2
The number following the colon (:)
must be the Failover ID for the
interface running on IF-Node2
The pointsource must match the
interfaces’ point source.
Location1 must match the ID for the
interfaces.
A lower value is a better status and
the interface with the lower status
will attempt to become the primary
interface.
[UFO2_STATE:#] Optional State 1 Tag 0 - 5 / None
(IF-Node1) The ExDesc must start with the Normally updated
case sensitive string: by the Interface
[UFO2_STATE:#] currently in the

102
 PI Tag ExDesc Required / Description Value
Optional
The number following the colon (:) primary role.
must be the Failover ID for the
interface running on IF-Node1
The failover state tag is
recommended.
The failover state tags are digital
tags assigned to a digital state set
with the following values.
0 = Off: The interface has been shut
down.
1 = Backup No Data Source: The
interface is running but cannot
communicate with the data source.
2 = Backup No PI Connection: The
interface is running and connected
to the data source but has lost its
communication to the PI Server.
3 = Backup: The interface is
running and collecting data
normally and is ready to take over
as primary if the primary interface
shuts down or experiences
problems.
4 = Transition: The interface stays
in this state for only a short period
of time. The transition period
prevents thrashing when more than
one interface attempts to assume
the role of primary interface.
5 = Primary: The interface is
running, collecting data and
sending the data to PI.
[UFO2_STATE:#] Optional State 2 Tag Normally updated
(IF-Node2) The ExDesc must start with the by the Interface
case sensitive string: currently in the
[UFO2_STATE:#] Primary state.
The number following the colon (:) Values range
must be the Failover ID for the between 0 and 5.
interface running on IF-Node2 See description of
The failover state tag is State 1 tag.
recommended.

DNP 3.0 Interface 103

UniInt Failover Configuration

Detailed Explanation of Synchronization through a Shared File

(Phase 2)
In a shared file failover configuration, there is no direct failover control information passed
between the data source and the interface. This failover scheme uses five PI tags to control
failover operation, and all failover communication between primary and backup interfaces
passes through a shared data file.
Once the interface is configured and running, the ability to read or write to the PI tags is not
required for the proper operation of failover. This solution does not require a connection to
the PI Server after initial startup because the control point data are set and monitored in the
shared file. However, the PI tag values are sent to the PI Server so that you can monitor them
with standard OSIsoft client tools.
You can force manual failover by changing the ActiveID on the data source to the backup
failover ID.

The figure above shows a typical network setup in the normal or steady state. The solid
magenta lines show the data path from the interface nodes to the shared file used for failover
synchronization. The shared file can be located anywhere in the network as long as both
interface nodes can read, write, and create the necessary file on the shared file machine.
OSIsoft strongly recommends that you put the file on a dedicated file server that has no other
role in the collection of data.
The major difference between synchronizing the interfaces through the data source (Phase 1)
and synchronizing the interfaces through the shared file (Phase 2) is where the control data is
located. When synchronizing through the data source, the control data is acquired directly
from the data source. We assume that if the primary interface cannot read the failover control
104
 points, then it cannot read any other data. There is no need for a backup communications path
between the control data and the interface.
When synchronizing through a shared file, however, we cannot assume that loss of control
information from the shared file implies that the primary interface is down. We must account
for the possible loss of the path to the shared file itself and provide an alternate control path
to determine the status of the primary interface. For this reason, if the shared file is
unreachable for any reason, the interfaces use the PI Server as an alternate path to pass
control data.
When the backup interface does not receive updates from the shared file, it cannot tell
definitively why the primary is not updating the file, whether the path to the shared file is
down, whether the path to the data source is down, or whether the interface itself is having
problems. To resolve this uncertainty, the backup interface uses the path to the PI Server to
determine the status of the primary interface. If the primary interface is still communicating
with the PI Server, than failover to the backup is not required. However, if the primary
interface is not posting data to the PI Server, then the backup must initiate failover operations.
The primary interface also monitors the connection with the shared file to maintain the
integrity of the failover configuration. If the primary interface can read and write to the
shared file with no errors but the backup control information is not changing, then the backup
is experiencing some error condition. To determine exactly where the problem exists, the
primary interface uses the path to PI to establish the status of the backup interface. For
example, if the backup interface controls indicate that it has been shutdown, it may have been
restarted and is now experiencing errors reading and writing to the shared file. Both primary
and backup interfaces must always check their status through PI to determine if one or the
other is not updating the shared file and why.

Steady State Operation

Steady state operation is considered the normal operating condition. In this state, the primary
interface is actively collecting data and sending its data to PI. The primary interface is also
updating its heartbeat value; monitoring the heartbeat value for the backup interface,
checking the active ID value, and checking the device status for the backup interface every
failover update interval on the shared file. Likewise, the backup interface is updating its
heartbeat value; monitoring the heartbeat value for the primary interface, checking the active
ID value, and checking the device status for the primary interface every failover update
interval on the shared file. As long as the heartbeat value for the primary interface indicates
that it is operating properly, the ActiveID has not changed, and the device status on the
primary interface is good, the backup interface will continue in this mode of operation.
An interface configured for hot failover will have the backup interface actively collecting and
queuing data but not sending that data to PI. An interface for warm failover in the backup role
is not actively collecting data from the data source even though it may be configured with PI
tags and may even have a good connection to the data source. An interface configured for
cold failover in the backup role is not connected to the data source and upon initial startup
will not have configured PI tags.
The interaction between the interface and the shared file is fundamental to failover. The
discussion that follows only refers to the data written to the shared file. However, every value
written to the shared file is echoed to the tags on the PI Server. Updating of the tags on the
PI Server is assumed to take place unless communication with the PI Server is interrupted.
The updates to the PI Server will be buffered by bufserv or BufSS in this case.

DNP 3.0 Interface 105

UniInt Failover Configuration

In a hot failover configuration, each interface participating in the failover solution will queue
three failover intervals worth of data to prevent any data loss. When a failover occurs, there
may be a period of overlapping data for up to 3 intervals. The exact amount of overlap is
determined by the timing and the cause of the failover and may be different every time. Using
the default update interval of 5 seconds will result in overlapping data between 0 and 15
seconds. The no data loss claim for hot failover is based on a single point of failure. If both
interfaces have trouble collecting data for the same period of time, data will be lost during
that time.
As mentioned above, each interface has its own heartbeat value. In normal operation, the
Heartbeat value on the shared file is incremented by UniInt from 1 - 15 and then wraps
around to a value of 1 again. UniInt increments the heartbeat value on the shared file every
failover update interval. The default failover update interval is 5 seconds. UniInt also reads
the heartbeat value for the other interface copy participating in failover every failover update
interval. If the connection to the PI Server is lost, the value of the heartbeat will be
incremented from 17 - 31 and then wrap around to a value of 17 again. Once the connection
to the PI Server is restored, the heartbeat values will revert back to the 1 - 15 range. During a
normal shutdown process, the heartbeat value will be set to zero.
During steady state, the ActiveID will equal the value of the failover ID of the primary
interface. This value is set by UniInt when the interface enters the primary state and is not
updated again by the primary interface until it shuts down gracefully. During shutdown, the
primary interface will set the ActiveID to zero before shutting down. The backup interface
has the ability to assume control as primary even if the current primary is not experiencing
problems. This can be accomplished by setting the ActiveID tag on the PI Server to the
ActiveID of the desired interface copy.
As previously mentioned, in a hot failover configuration the backup interface actively collects
data but does not send its data to PI. To eliminate any data loss during a failover, the backup
interface queues data in memory for three failover update intervals. The data in the queue is
continuously updated to contain the most recent data. Data older than three update intervals is
discarded if the primary interface is in a good status as determined by the backup. If the
backup interface transitions to the primary, it will have data in its queue to send to PI. This
queued data is sent to PI using the same function calls that would have been used had the
interface been in a primary state when the function call was received from UniInt. If UniInt
receives data without a timestamp, the primary copy uses the current PI time to timestamp
data sent to PI. Likewise, the backup copy timestamps data it receives without a timestamp
with the current PI time before queuing its data. This preserves the accuracy of the
timestamps.

106
 Failover Configuration Using PI ICU
The use of the PI ICU is the recommended and safest method for configuring the Interface for
UniInt failover. With the exception of the notes described in this section, the Interface shall
be configured with the PI ICU as described in the “Configuring the Interface with the PI
ICU” section of this manual.

Note: With the exception of the /UFO_ID and /UFO_OtherID startup command-
line parameters, the UniInt failover scheme requires that both copies of the interface
have identical startup command files. This requirement causes the PI ICU to
produce a message when creating the second copy of the interface stating that the
“PS/ID combo already in use by the interface” as shown in Figure 2 below. Ignore
this message and click the Add button.

Create the Interface Instance with PI ICU

If the interface does not already exist in the ICU it must first be created. The procedure for
doing this is the same as for non-failover interfaces. When configuring the second instance
for UniInt Failover the Point Source and Interface ID will be in yellow and a message will be
displayed saying this is already in use. This should be ignored.

Figure 2: PI ICU configuration screen shows that the “PS/ID combo is already in use by
the interface.” The user must ignore the yellow boxes, which indicate errors, and click the
Add button to configure the interface for failover.

DNP 3.0 Interface 107

UniInt Failover Configuration

Configuring the UniInt Failover Startup Parameters with PI ICU

There are three interface startup parameters that control UniInt failover: /UFO_ID,
/UFO_OtherID, and /UFO_Interval. The UFO stands for UniInt Failover. The /UFO_ID
and /UFO_OtherID parameters are required for the interface to operate in a failover
configuration, but the /UFO_Interval is optional. Each of these parameters is described in
detail in Configuring UniInt Failover through a Shared File (Phase 2)section and Start-Up
Parameters

Figure 3: The figure above illustrates the PI ICU failover configuration screen showing
the UniInt failover startup parameters (Phase 2). This copy of the interface defines its
Failover ID as 2 (/UFO_ID=2) and the other interfaces Failover ID as 1
(/UFO_OtherID=1). The other failover interface copy must define its Failover ID as 1
(/UFO_ID=1) and the other interface Failover ID as 2 ( /UFO_OtherID=2) in its ICU
failover configuration screen. It also defines the location and name of the
synchronization file as well as the type of failover as COLD.

Creating the Failover State Digital State Set

The UFO_State digital state set is used in conjunction with the failover state digital tag. If
the UFO_State digital state set has not been created yet, it can be using either the Failover
page of the ICU (1.4.1.0 or greater) or the Digital States plug-in in the SMT 3 Utility (3.0.0.7
or greater).

108
 Using the PI ICU Utility to create Digital State Set

To use the UniInt Failover page to create the UFO_State digital state set right click on any of
the failover tags in the tag list and then select the “Create UFO_State Digital Set on Server
XXXXXX…”, where XXXXXX is the PI Server where the points will be or are create on.

This choice will be grayed out if the UFO_State digital state set is already created on the
XXXXXX PI Server.

Using the PI SMT 3 Utility to create Digital State Set

Optionally the “Export UFO_State Digital Set (.csv) can be selected to create a comma
separated file to be imported via the System Manangement Tools (SMT3) (version 3.0.0.7 or
higher) or use the UniInt_Failover_DigitalSet_UFO_State.csv file included in the
installation kit.
The procedure below outlines the steps necessary to create a digital set on a PI Sever using
the “Import from File” function found in the SMT3 application. The procedure assumes the
user has a basic understanding of the SMT3 application.
2. Open the SMT3 application.
3. Select the appropriate PI Server from the PI Servers window. If the desired server is
not listed, add it using the PI Connection Manager. A view of the SMT application is
shown in Figure 4 below.
4. From the System Management Plug-Ins window, select Points then Digital States. A
list of available digital state sets will be displayed in the main window for the
selected PI Server. Refer to Figure 4 below.
5. In the main window, right click on the desired server and select the “Import from
File” option. Refer to Figure 4 below.

DNP 3.0 Interface 109

UniInt Failover Configuration

Figure 4: PI SMT application configured to import a digital state set file. The PI Servers
window shows the “localhost” PI Server selected along with the System Management
Plug-Ins window showing the Digital States Plug-In as being selected. The digital state
set file can now be imported by selecting the Import from File option for the localhost.
6. Navigate to and select the UniInt_Failover_DigitalSet_UFO_State.csv file
for import using the Browse icon on the display. Select the desired Overwrite
Options. Click on the OK button. Refer to Figure 5 below.

Figure 5: PI SMT application Import Digital Set(s) window. This view shows the
UniInt_Failover_DigitalSet_UFO_State.csv file as being selected for import.
Select the desired Overwrite Options by choosing the appropriate radio button.

110
 7. Navigate to and select the UniInt_Failover_DigitalSet_UFO_State.csv file
for import using the Browse icon on the display. Select the desired Overwrite
Options. Click on the OK button. Refer to Figure 5 above.
8. The UFO_State digital set is created as shown in Figure 6 below.

Figure 6: The PI SMT application showing the UFO_State digital set created on the
“localhost” PI Server.

DNP 3.0 Interface 111

UniInt Failover Configuration

Creating the UniInt Failover Control and Failover State Tags (Phase 2)
The ICU can be used to create the UniInt Failover Control and State Tags.
To use the ICU Failover page to create these tags simply right click any of the failover tags in
the tag list and select the “Create all points (UFO Phase 2)” menu item.
If this menu choice is grayed out it is because the UFO_State digital state set has not been
created on the Server yet. There is a menu choice “Create UFO_State Digital Set on Server
xxxxxxx…” which can be used to create that digital state set. Once this has been done then
the “Create all points (UFO Phase2) should be available.

Once the failover control and failover state tags have been created the Failover page of the
ICU should look similar to the illustration below.

112
Chapter 12. Interface Node Clock

Make sure that the time and time zone settings on the computer are correct. To confirm, run
the Date/Time applet located in the Windows Control Panel. If the locale where the Interface
Node resides observes Daylight Saving Time, check the “Automatically adjust clock for
daylight saving changes” box. For example,

In addition, make sure that the TZ environment variable is not defined. All of the currently
defined environment variables can be viewed by opening a Command Prompt window and
typing set. That is,
C:> set
Confirm that TZ is not in the resulting list. If it is, run the System applet of the Control
Panel, click the “Environment Variables” button under the Advanced Tab, and remove TZ
from the list of environment variables.

DNP 3.0 Interface 113

Chapter 13. Security

The PI Firewall Database and the PI Proxy Database must be configured so that the interface
is allowed to write data to the PI Server. See “Modifying the Firewall Database” and
“Modifying the Proxy Database” in the PI Server manuals.
Note that the Trust Database, which is maintained by the Base Subsystem, replaces the Proxy
Database used prior to PI version 3.3. The Trust Database maintains all the functionality of
the proxy mechanism while being more secure.
See “Trust Login Security” in the chapter “Managing Security” of the PI Server System
Management Guide.
If the interface cannot write data to the PI Server because it has insufficient privileges, a
-10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2
Serve, it writes a -999 error. See the section Appendix A: Error and Informational Messages
for additional information on error messaging.

PI Server v3.3 and Higher

Security configuration using piconfig

For PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust
table:
C:\PI\adm> piconfig
@table pitrust
@mode create
@istr Trust,IPAddr,NetMask,PIUser
a_trust_name,192.168.100.11,255.255.255.255,piadmin
@quit
For the above,
Trust: An arbitrary name for the trust table entry; in the above example,
a_trust_name
IPAddr: the IP Address of the computer running the Interface; in the above example,
192.168.100.11
NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddr
PIUser: the PI user the Interface to be entrusted as; piadmin is usually an appropriate user

DNP 3.0 Interface 115

 Security Configuring using Trust Editor
The Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI
Trust table.
See the PI System Management chapter in the PI Server manual for more details on security
configuration.

PI Server v3.2
For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:
C:\PI\adm> piconfig
@table pi_gen,piproxy
@mode create
@istr host,proxyaccount
piapimachine,piadmin
@quit
In place of piapimachine, put the name of the PI Interface node as it is seen by PI Server.

DNP 3.0 Interface 116

Chapter 14. Starting / Stopping the Interface

This section describes starting and stopping the Interface once it has been installed as a
service. See the UniInt Interface User Manual to run the Interface interactively.

Starting Interface as a Service

If the Interface was installed as service, it can be started from PI ICU, the Services control
panel or with the command:
PIDNP3.exe –start

To start the interface service with PI ICU, use the button on the PI ICU toolbar.
A message will inform the user of the status of the interface service. Even if the message
indicates that the service has started successfully, double check through the Services control
panel applet. Services may terminate immediately after startup for a variety of reasons, and
one typical reason is that the service is not able to find the command-line parameters in the
associated .bat file. Verify that the root name of the .bat file and the .exe file are the
same, and that the .bat file and the .exe file are in the same directory. Further
troubleshooting of services might require consulting the pipc.log file, Windows Event
Viewer, or other sources of log messages. See the section Appendix A: Error and
Informational Messages for additional information.

Stopping Interface Running as a Service

If the Interface was installed as service, it can be stopped at any time from PI ICU, the
Services control panel or with the command:
PIDNP3.exe –stop
The service can be removed by:
PIDNP3.exe –remove

To stop the interface service with PI ICU, use the button on the PI ICU toolbar.

DNP 3.0 Interface 117

Chapter 15. Buffering

Buffering refers to an Interface Node’s ability to temporarily store the data that interfaces
collect and to forward these data to the appropriate PI Servers. OSIsoft strongly recommends
that you enable buffering on your Interface Nodes. Otherwise, if the Interface Node stops
communicating with the PI Server, you lose the data that your interfaces collect.
The PI SDK installation kit installs two buffering applications: the PI Buffer Subsystem
(PIBufss) and the PI API Buffer Server (Bufserv). PIBufss and Bufserv are mutually
exclusive; that is, on a particular computer, you can run only one of them at any given time.
If you have PI Servers that are part of a PI Collective, PIBufss supports n-way buffering. N-
way buffering refers to the ability of a buffering application to send the same data to each of
the PI Servers in a PI Collective. (Bufserv also supports n-way buffering, but OSIsoft
recommends that you run PIBufss instead.)

Which Buffering Application to Use

You should use PIBufss whenever possible because it offers better throughput than Bufserv.
In addition, if the interfaces on an Interface Node are sending data to a PI Collective, PIBufss
guarantees identical data in the archive records of all the PI Servers that are part of that
collective.
You can use PIBufss only under the following conditions:
 the PI Server version is at least 3.4.375.x; and
 all of the interfaces running on the Interface Node send data to the same PI
Server or to the same PI Collective.
If any of the following scenarios apply, you must use Bufserv:
 the PI Server version is earlier than 3.4.375.x; or
 the Interface node runs multiple interfaces, and these interfaces send data to
multiple PI Servers that are not part of a single PI Collective.
If an Interface Node runs multiple interfaces, and these interfaces send data to two or more PI
Collectives, then neither PIBufss nor Bufserv is appropriate. The reason is that PIBufss and
Bufserv can buffer data only to a single collective. If you need to buffer to more than one PI
Collective, you need to use two or more Interface Nodes to run your interfaces.
It is technically possible to run Bufserv on the PI Server Node. However, OSIsoft does not
recommend this configuration.

DNP 3.0 Interface 119

 How Buffering Works
A complete technical description of PIBufss and Bufserv is beyond the scope of this
document. However, the following paragraphs provide some insights on how buffering
works.
When an Interface Node has Buffering enabled, the buffering application (PIBufss or
Bufserv) connects to the PI Server. It also creates shared memory storage.
When an interface program makes a PI API function call that writes data to the PI Server (for
example, pisn_sendexceptionqx()), the PI API checks whether buffering is enabled. If it
is, these data writing functions do not send the interface data to the PI Server. Instead, they
write the data to the shared memory storage that the buffering application created.
The buffering application (either Bufserv or PIBufss) in turn
 reads the data in shared memory, and
 if a connection to the PI Server exists, sends the data to the PI Server; or
 if there is no connection to the PI Server, continues to store the data in shared
memory (if shared memory storage is available) or writes the data to disk (if
shared memory storage is full).
When the buffering application re-establishes connection to the PI Server, it writes to the PI
Server the interface data contained in both shared memory storage and disk.
(Before sending data to the PI Server, PIBufss performs further tasks such data validation and
data compression, but the description of these tasks is beyond the scope of this document.)
When PIBufss writes interface data to disk, it writes to multiple files. The names of these
buffering files are PIBUFQ_*.DAT.
When Bufserv writes interface data to disk, it writes to a single file. The name of its buffering
file is APIBUF.DAT.
As a previous paragraph indicates, PIBufss and Bufserv create shared memory storage at
startup. These memory buffers must be large enough to accommodate the data that an
interface collects during a single scan. Otherwise, the interface may fail to write all its
collected data to the memory buffers, resulting in data loss. The buffering configuration
section of this chapter provides guidelines for sizing these memory buffers.
When buffering is enabled, it affects the entire Interface Node. That is, you do not have a
scenario whereby the buffering application buffers data for one interface running on an
Interface Node but not for another interface running on the same Interface Node.

Buffering and PI Server Security

After you enable buffering, it is the buffering application—and not the interface program—
that writes data to the PI Server. If the PI Server’s trust table contains a trust entry that allows
all applications on an Interface Node to write data, then the buffering application is able write
data to the PI Server.
However, if the PI Server contains an interface-specific PI Trust entry that allows a particular
interface program to write data, you must have a PI Trust entry specific to buffering. The
following are the appropriate entries for the Application Name field of a PI Trust entry:

DNP 3.0 Interface 120

 Buffering Application Application Name field for PI Trust
PI Buffer Subsystem PIBufss.exe
PI API Buffer Server APIBE (if the PI API is using 4 character process
names)
APIBUF (if the PI API is using 8 character process
names)

To use a process name greater than 4 characters in length for a trust application name, use the
LONGAPPNAME=1 in the PIClient.ini file.

Enabling Buffering on an Interface Node with the ICU

The ICU allows you to select either PIBufss or Bufserv as the buffering application for your
Interface Node. Run the ICU and select Tools > Buffering.

Choose Buffer Type

To select PIBufss as the buffering application, choose Enable buffering with PI Buffer
Subsystem.
To select Bufserv as the buffering application, choose Enable buffering with API Buffer
Server.
If a warning message such as the following appears, click Yes.

DNP 3.0 Interface 121

Buffering

Buffering Settings

There are a number of settings that affect the operation of PIBufss and Bufserv. The
Buffering Settings section allows you to set these parameters. If you do not enter values for
these parameters, PIBufss and Bufserv use default values.

PIBufss
For PIBufss, the paragraphs below describe the settings that may require user intervention.
Please contact OSIsoft Technical Support for assistance in further optimizing these and all
remaining settings.

Primary and Secondary Memory Buffer Size (Bytes)

This is a key parameter for buffering performance. The sum of these two memory buffer sizes
must be large enough to accommodate the data that an interface collects during a single scan.
A typical event with a Float32 point type requires about 25 bytes. If an interface writes data
to 5,000 points, it can potentially send 125,000 bytes (25 * 5000) of data in one scan. As a
result, the size of each memory buffer should be 62,500 bytes.
The default value of these memory buffers is 32,768 bytes. OSIsoft recommends that these
two memory buffer sizes should be increased to the maximum of 2000000 for the best
buffering performance.

Send rate (milliseconds)

Send rate is the time in milliseconds that PIBufss waits between sending up to the Maximum
transfer objects (described below) to the PI Server. The default value is 100. The valid range
is 0 to 2,000,000.

122
 Maximum transfer objects
Maximum transfer objects is the maximum number of events that PIBufss sends between
each Send rate pause. The default value is 500. The valid range is 1 to 2,000,000.

Event Queue File Size (Mbytes)

This is the size of the event queue files. PIBufss stores the buffered data to these files. The
default value is 32. The range is 8 to 131072 (8 to 128 Gbytes). Please see the section
entitled, “Queue File Sizing” in the PIBufss.chm file for details on how to appropriately size
the event queue files.

Event Queue Path

This is the location of the event queue file. The default value is [PIHOME]\DAT.
For optimal performance and reliability, OSIsoft recommends that you place the PIBufss
event queue files on a different drive/controller from the system drive and the drive with the
Windows paging file. (By default, these two drives are the same.)

Bufserv
For Bufserv, the paragraphs below describe the settings that may require user intervention.
Please contact OSIsoft Technical Support for assistance in further optimizing these and all
remaining settings.

Maximum buffer file size (KB)

This is the maximum size of the buffer file ( [PIHOME]\DAT\APIBUF.DAT). When Bufserv
cannot communicate with the PI Server, it writes and appends data to this file. When the
buffer file reaches this maximum size, Bufserv discards data.
The default value is 2,000,000 KB, which is about 2 GB. The range is from 1 to 2,000,000.

DNP 3.0 Interface 123

Buffering

Primary and Secondary Memory Buffer Size (Bytes)

This is a key parameter for buffering performance. The sum of these two memory buffer sizes
must be large enough to accommodate the data that an interface collects during a single scan.
A typical event with a Float32 point type requires about 25 bytes. If an interface writes data
to 5,000 points, it can potentially send 125,000 bytes (25 * 5000) of data in one scan. As a
result, the size of each memory buffer should be 62,500 bytes.
The default value of these memory buffers is 32,768 bytes. OSIsoft recommends that these
two memory buffer sizes should be increased to the maximum of 2000000 for the best
buffering performance.

Send rate (milliseconds)

Send rate is the time in milliseconds that Bufserv waits between sending up to the Maximum
transfer objects (described below) to the PI Server. The default value is 100. The valid range
is 0 to 2,000,000.

Maximum transfer objects

Max transfer objects is the maximum number of events that Bufserv sends between each
Send rate pause. The default value is 500. The valid range is 1 to 2,000,000.

Buffered Servers

The Buffered Servers section allows you to define the PI Servers or PI Collective that the
buffering application writes data.

PIBufss
PIBufss buffers data only to a single PI Server or a PI Collective. Select the PI Server or the
PI Collective from the Buffering to collective/server drop down list box.
The following screen shows that PIBufss is configured to write data to a standalone PI Server
named starlight. Notice that the Replicate data to all collective member nodes check box
is disabled because this PI Server is not part of a collective. (PIBufss automatically detects
whether a PI Server is part of a collective.)

124
 The following screen shows that PIBufss is configured to write data to a PI Collective named
admiral. By default, PIBufss replicates data to all collective members. That is, it provides n-
way buffering.
You can override this option by not checking the Replicate data to all collective member
nodes check box. Then, uncheck (or check) the PI Server collective members as desired.

DNP 3.0 Interface 125

Buffering

Bufserv
Bufserv buffers data to a standalone PI Server, or to multiple standalone PI Servers. (If you
want to buffer to multiple PI Servers that are part of a PI Collective, you should use PIBufss.)
If the PI Server to which you want Bufserv to buffer data is not in the Server list, enter its
name in the Add a server box and click the Add Server button. This PI Server name must be
identical to the API Hostname entry:

The following screen shows that Bufserv is configured to write to a standalone PI Server
named etamp390. You use this configuration when all the interfaces on the Interface Node
write data to etamp390.

The following screen shows that Bufserv is configured to write to two standalone PI Servers,
one named etamp390 and the other one named starlight. You use this configuration when
some of the interfaces on the Interface Node write data to etamp390 and some write to
starlight.

126
 Installing Buffering as a Service

Both the PIBufss and Bufserv applications run as a Service.

PI Buffer Subsystem Service

Use the PI Buffer Subsystem Service page to configure PIBufss as a Service. This page also
allows you to start and stop the PIBufss service.
PIBufss does not require the logon rights of the local administrator account. It is sufficient to
use the LocalSystem account instead. Although the screen below shows asterisks for the
LocalSystem password, this account does not have a password.

DNP 3.0 Interface 127

Buffering

API Buffer Server Service

Use the API Buffer Server Service page to configure Bufserv as a Service. This page also
allows you to start and stop the Bufserv Service
Bufserv version 1.6 and later does not require the logon rights of the local administrator
account. It is sufficient to use the LocalSystem account instead. Although the screen below
shows asterisks for the LocalSystem password, this account does not have a password.

128
DNP 3.0 Interface 129
Chapter 16. Interface Diagnostics Configuration

The Interface Point Configuration chapter provides information on building PI points for
collecting data from the device. This chapter describes the configuration of points related to
interface diagnostics.

Note: The procedure for configuring interface diagnostics is not specific to this
Interface. Thus, for simplicity, the instructions and screenshots that follow refer to an
interface named ModbusE.

Some of the points that follow refer to a “performance summary interval”. This interval is 8
hours by default. You can change this parameter via the Scan performance summary box in
the UniInt – Debug parameter category pane:

Scan Class Performance Points

A Scan Class Performance Point measures the amount of time (in seconds) that this Interface
takes to complete a scan. The Interface writes this scan completion time to millisecond
resolution. Scan completion times close to 0 indicate that the Interface is performing
optimally. Conversely, long scan completion times indicate an increased risk of missed or
skipped scans. To prevent missed or skipped scans, you should distribute the data collection
points among several scan classes.

DNP 3.0 Interface 131

 You configure one Scan Class Performance Point for each Scan Class in this Interface. From
the ICU, select this Interface from the Interface drop-down list and click UniInt-Performance
Points in the parameter category pane:

Right click the row for a particular Scan Class # to bring up the context menu:

You need not restart the Interface for it to write values to the Scan Class Performance Points.
To see the current values (snapshots) of the Scan Class Performance Points, right click and
select Refresh Snapshots.

Create / Create ALL

To create a Performance Point, right-click the line belonging to the tag to be created, and
select Create. Click Create All to create all the Scan Class Performance Points.

Delete
To delete a Performance Point, right-click the line belonging to the tag to be deleted, and
select Delete.

DNP 3.0 Interface 132

 Correct / Correct All
If the “Status” of a point is marked “Incorrect”, the point configuration can be automatically
corrected by ICU by right-clicking on the line belonging to the tag to be corrected, and
selecting Correct. The Performance Points are created with the following PI attribute values.
If ICU detects that a Performance Point is not defined with the following, it will be marked
Incorrect: To correct all points click the Correct All menu item.
The Performance Points are created with the following PI attribute values:
Attribute Details
Tag Tag name that appears in the list box
Point Source Point Source for tags for this interface, as specified on the first tab
Compressing Off
Excmax 0
Descriptor Interface name + “ Scan Class # Performance Point”

Rename
Right-click the line belonging to the tag and select “Rename” to rename the Performance
Point.

Column descriptions

Status
The Status column in the Performance Points table indicates whether the Performance Point
exists for the scan class in column 2.
Created – Indicates that the Performance Point does exist
Not Created – Indicates that the Performance Point does not exist
Deleted – Indicates that a Performance Point existed, but was just deleted by the user

Scan Class #
The Scan Class column indicates which scan class the Performance Point in the Tagname
column belongs to. There will be one scan class in the Scan Class column for each scan class
listed in the Scan Classes combo box on the UniInt Parameters tab.

Tagname
The Tagname column holds the Performance Point tag name.

PS
This is the point source used for these performance points and the interface.

Location1
This is the value used by the interface for the /ID=# point attribute.

DNP 3.0 Interface 133

Interface Diagnostics Configuration

Exdesc
This is the used to tell the interface that these are performance points and the value is used to
corresponds to the /ID=# command line parameter if multiple copies of the same interface
are running on the Interface node.

Snapshot
The Snapshot column holds the snapshot value of each Performance Point that exists in PI.
The Snapshot column is updated when the Performance Points/Counters tab is clicked, and
when the interface is first loaded. You may have to scroll to the right to see the snapshots.

Performance Counters Points

When running as a Service or interactively, this Interface exposes performance data via
Windows Performance Counters. Such data include items like:
 the amount of time that the Interface has been running;
 the number of points the Interface has added to its point list;
 the number of tags that are currently updating among others
There are two types or instances of Performance Counters that can be collected and stored in
PI Points. The first is (_Total) which is a total for the Performance Counter since the
interface instance was started. The other is for individual Scan Classes (Scan Class x) where
x is a particular scan class defined for the interface instance that is being monitored.
OSIsoft’s PI Performance Monitor Interface is capable of reading these performance values
and writing them to PI points. Please see the Performance Monitor Interface for more
information.
If there is no PI Performance Monitor Interface registered with the ICU in the Module
Database for the PI Server the interface is sending its data to, you cannot use the ICU to
create any Interface instance’s Performance Counters Points:

134
 After installing the PI Performance Monitor Interface as a service, select this Interface
instance from the Interface drop-down list, then click Performance Counters in the parameter
categories pane, and right click on the row containing the Performance Counters Point you
wish to create. This will bring up the context menu:

Click Create to create the Performance Counters Point for that particular row. Click Create
All to create all the Performance Counters Points listed which have a status of Not Created.
To see the current values (snapshots) of the created Performance Counters Points, right click
on any row and select Refresh Snapshots.

Note: The PI Performance Monitor Interface – and not this Interface – is responsible
for updating the values for the Performance Counters Points in PI. So, make sure
that the PI Performance Monitor Interface is running correctly.

Performance Counters

In the following lists of Performance Counters the naming convention used will be:
“PerformanceCounterName” (.PerformanceCountersPoint Suffix)
The tagname created by the ICU for each Performance Counter point is based on the setting
found under the Tools  Options  Naming Conventions  Performance Counter Points.
The default for this is “sy.perf.[machine].[if service] followed by the Performance Counter
Point suffix.

Performance Counters for both (_Total) and (Scan Class x)

“Point Count” (.point_count)

A .point_count Performance Counters Point is available for each Scan Class of this Interface
as well as a Total for the interface instance.
DNP 3.0 Interface 135
Interface Diagnostics Configuration

The .point_count Performance Counters Point indicates the number of PI Points per Scan
Class or the total number for the interface instance. This point is similar to the Health Point
[UI_SCPOINTCOUNT] for scan classes and [UI_POINTCOUNT] for totals.
The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for
example, “sy.perf.etamp390.E1(Scan Class 1).point_count” refers to Scan Class
1, “(Scan Class 2)” refers to Scan Class 2, and so on. The tag containing “(_Total)” refers to
the sum of all Scan Classes.

“Scheduled Scans: % Missed” (.sched_scans_%missed)

A .sched_scans_%missed Performance Counters Point is available for each Scan Class of this
Interface as well as a Total for the interface instance.
The .sched_scans_%missed Performance Counters Point indicates the percentage of scans the
Interface missed per Scan Class or the total number missed for all scan classes since startup.
A missed scan occurs if the Interface performs the scan one second later than scheduled.
The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for
example, “sy.perf.etamp390.E1(Scan Class 1).sched_scans_%missed” refers
to Scan Class 1, “(Scan Class 2)” refers to Scan Class 2, and so on. The tag containing
“(_Total)” refers to the sum of all Scan Classes.

“Scheduled Scans: % Skipped” (.sched_scans_%skipped)

A .sched_scans_%skipped Performance Counters Point is available for each Scan Class of
this Interface as well as a Total for the interface instance.
The .sched_scans_%skipped Performance Counters Point indicates the percentage of scans
the Interface skipped per Scan Class or the total number skipped for all scan classes since
startup. A skipped scan is a scan that occurs at least one scan period after its scheduled time.
This point is similar to the [UI_SCSKIPPED] Health Point.
The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for
example, “sy.perf.etamp390.E1(Scan Class 1).sched_scans_%skipped” refers
to Scan Class 1, “(Scan Class 2)” refers to Scan Class 2, and so on. The tag containing
“(_Total)” refers to the sum of all Scan Classes.

“Scheduled Scans: Scan count this interval” (.sched_scans_this_interval)

A .sched_scans_this_interval Performance Counters Point is available for each Scan Class of
this Interface as well as a Total for the interface instance.
The .sched_scans_this_interval Performance Counters Point indicates the number of scans
that the Interface performed per performance summary interval for the scan class or the total
number of scans performed for all scan classes during the summary interval. This point is
similar to the [UI_SCSCANCOUNT] Health Point.
The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for
example, “sy.perf.etamp390.E1(Scan Class 1).sched_scans_this_interval”
refers to Scan Class 1, “(Scan Class 2)” refers to Scan Class 2, and so on. The tag containing
“(_Total)” refers to the sum of all Scan Classes.

136
 Performance Counters for (_Total) only

“Device Actual Connections” (.Device_Actual_Connections)

The .Device_Actual_Connections Performance Counters Point stores the actual number of
foreign devices currently connected and working properly out of the expected number of
foreign device connections to the interface. This value will always be less than or equal to the
Expected Connections.

“Device Expected Connections” (.Device_Expected_Connections)

The .Device_Expected_Connections Performance Counters Point stores the total number of
foreign device connections for the interface. This is the expected number of foreign device
connections configured that should be working properly at runtime. If the interface can only
communicate with 1 foreign device then the value of this counter will always be one. If the
interface can support multiple foreign device connections then this is the total number of
expected working connections configured for this Interface.

“Device Status” (.Device_Status)

The .Device_Status Performance Counters Point stores communication information about the
interface and the connection to the foreign device(s). The value of this counter is based on the
expected connections, actual connections and value of the /PercentUp command line
option. If the device status is good then the value is ‘0’. If the device status is bad then the
value is ‘1’. If the interface only supports connecting to 1 foreign device then the
/PercentUp command line value does not change the results of the calculation. If for
example the Interface can connect to 10 devices and 5 are currently working then the value of
the /PercentUp command line parameter is applied to determine the Device Status. If the
value of the /PercentUp command line parameter is set to 50 and at least 5 devices are
working then the DeviceStatus will remain good (i.e. have a value of zero).

“Failover Status” (.Failover_Status)

The .Failover_Status Performance Counters Point stores the failover state of the interface
when configured for UniInt interface level failover. The value of the counter will be ‘0’ when
the interface is running as the ‘Primary’ interface in the failover configuration. If the interface
is running in backup mode then the value of the counter will be ‘1’.

“Interface up-time (seconds)” (.up_time)

The .up_time Performance Counters Point indicates the amount of time (in seconds) that this
Interface has been running. At startup the value of the counter is zero. The value will continue
to increment until it reaches the maximum value for an unsigned integer. Once it reaches this
value then it will start back over at zero.

“IO Rate (events/second)” (.io_rates)

The .io_rates Performance Counters Point indicates the rate (in event per second) at which
this Interface writes data to its input tags. (As of UniInt 4.5.0.x and later this performance
counters point will no longer be available.)

DNP 3.0 Interface 137

Interface Diagnostics Configuration

“Log file message count” (.log_file_msg_count)

The .log_file_msg_count Performance Counters Point indicates the number of messages that
the Interface has written to the log file. This point is similar to the [UI_MSGCOUNT]
Health Point.

“PI Status” (PI_Status)

The .PI_Status Performance Counters Point stores communication information about the
interface and the connection to the PI Server. If the interface is properly communicating with
the PI server then the value of the counter is ‘0’. If the communication to the PI Server goes
down for any reason then the value of the counter will be ‘1’. Once the interface is properly
communicating with the PI server again then the value will change back to ‘0’.

“Points added to the interface” (.pts_added_to_interface)

The .pts_added_to_interface Performance Counter Point indicates the number of points the
Interface has added to its point list. This does not include the number of points configured at
startup. This is the number of points added to the interface after the interface has finished a
successful startup.

“Points edited in the interface”(.pts_edited_in_interface)

The .pts_edited_in_interface Performance Counters Point indicates the number of point edits
the Interface has detected. The Interface detects edits for those points whose PointSource
attribute matches the Point Source parameter and whose Location1 attribute matches the
Interface ID parameter of the Interface.

“Points Good” (.Points_Good)

The .Points_Good Performance Counters Point is the number of points that have sent a good
current value to PI. A good value is defined as any value that is not a system digital state
value. A point can either be Good, In Error or Stale. The total of Points Good, Points In Error
and Points State will equal the Point Count. There is one exception to this rule. At startup of
an interface, the Stale timeout must elapse before the point will be added to the Stale Counter.
Therefore the interface must be up and running for at least 10 minutes for all tags to belong to
a particular Counter.

“Points In Error” (.Points_In_Error)

The .Points_In_Error Performance Counters Point indicates the number of points that have
sent a current value to PI that is a system digital state value. Once a point is in the In Error
count it will remain in the In Error count until the point receives a new, good value. Points in
Error do not transition to the Stale Counter. Only good points become stale.

“Points removed from the interface” (.pts_removed_from_interface)

The .pts_removed_from_interface Performance Counters Point indicates the number of points
that have been removed from the Interface configuration. A point can be removed from the
interface when one of the tag properties for the interface is updated and the point is no longer
a part of the interface configuration. For example, changing the point source, location 1, or
scan property can cause the tag to no longer be a part of the interface configuration.

138
 “Points Stale 10(min)” (.Points_Stale_10min)
The .Points_Stale_10min Performance Counters Point indicates the number of good points
that have not received a new value in the last 10 min. If a point is Good, then it will remain in
the good list until the Stale timeout elapses. At this time if the point has not received a new
value within the Stale Period then the point will move from the Good count to the Stale
count. Only points that are Good can become Stale. If the point is in the In Error count then it
will remain in the In Error count until the error clears. As stated above, the total count of
Points Good, Points In Error and Points Stale will match the Point Count for the Interface.

“Points Stale 30(min)” (.Points_Stale_30min)

The .Points_Stale_30min Performance Counters Point indicates the number of points that
have not received a new value in the last 30 min. For a point to be in the Stale 30 minute
count it must also be a part of the Stale 10 minute count.

“Points Stale 60(min)” (.Points_Stale_60min)

The .Points_Stale_30min Performance Counters Point indicates the number of points that
have not received a new value in the last 60 min. For a point to be in the Stale 60 minute
count it must also be a part of the Stale 10 minute and 30 minute count.

“Points Stale 240(min)” (.Points_Stale_240min)

The .Points_Stale_240min Performance Counters Point indicates the number of points that
have not received a new value in the last 240 min. For a point to be in the Stale 240 minute
count it must also be a part of the Stale 10 minute, 30 minute and 60 minute count.

Performance Counters for (Scan Class x) only

“Device Scan Time (milliseconds)” (.Device_Scan_Time)

A .Device_Scan_Time Performance Counter Point is available for each Scan Class of this
Interface.
The .Device_Scan_Time Performance Counters Point indicates the number of milliseconds
the Interface takes to read the data from the foreign device and package the data to send to PI.
This counter does not include the amount of time to send the data to PI. This point is similar
to the [UI_SCINDEVSCANTIME] Health Point.
The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for
example, “sy.perf.etamp390.E1 (Scan Class 1).device_scan _time” refers to
Scan Class 1, “(Scan Class 2) refers to Scan Class 2, and so on.

“Scan Time (milliseconds)” (.scan_time)

A .scan_time Performance Counter Point is available for each Scan Class of this Interface.
The .scan_time Performance Counter Point indicates the number of milliseconds the Interface
takes to both read the data from the device and send the data to PI. This point is similar to the
[UI_SCINSCANTIME] Health Point.

DNP 3.0 Interface 139

Interface Diagnostics Configuration

The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for
example, “sy.perf.etamp390.E1(Scan Class 1).scan_time” refers to Scan Class 1,
“(Scan Class 2)” refers to Scan Class 2, and so on.

140
 Interface Health Monitoring Points
Interface Health Monitoring Points provide information about the health of this Interface. To
use the ICU to configure these points, select this Interface from the Interface drop-down list
and click Health Points from the parameter category pane:

Right click the row for a particular Health Point to display the context menu:

Click Create to create the Health Point for that particular row. Click Create All to create all
the Health Points.
To see the current values (snapshots) of the Health Points, right click and select Refresh
Snapshots.
DNP 3.0 Interface 141
Interface Diagnostics Configuration

For some of the Health Points described subsequently, the Interface updates their values at
each performance summary interval (typically, 8 hours).

[UI_HEARTBEAT]
The [UI_HEARTBEAT] Health Point indicates whether the Interface is currently running.
The value of this point is an integer that increments continuously from 1 to 15. After reaching
15, the value resets to 1.
The fastest scan class frequency determines the frequency at which the Interface updates this
point:
Fastest Scan Frequency Update frequency
Less than 1 second 1 second
Between 1 and 60 Scan frequency
seconds, inclusive
More than 60 seconds 60 seconds

If the value of the [UI_HEARTBEAT] Health Point is not changing, then this Interface is in
an unresponsive state.

[UI_DEVSTAT]
The DNP3 Interface supports health tags. The Device Status health tag has its point attribute
Exdesc set to [UI_DEVSTAT] and is used to represent the status of the source device. The
following events can be written into this tag:
 Good – the interface is communicating with all RTUs assigned to this interface.
 1 | Starting | UI x.x.x.x – the interface is starting.
 3 | n devices(s) in error | message – The number of RTUs operational. Moreover,
the RTU(s) in error are logged to the file listed by the message.
 4 | Intf Shutdown
Please refer to the UniInt Interface User Manual.doc file for more information on how to
configure health points.

[UI_SCINFO]
The [UI_SCINFO] Health Point provides scan class information. The value of this point is a
string that indicates
 the number of scan classes;
 the update frequency of the [UI_HEARTBEAT] Health Point; and
 the scan class frequencies
An example value for the [UI_SCINFO] Health Point is:
3 | 5 | 5 | 60 | 120
The Interface updates the value of this point at startup and at each performance summary
interval.

142
 [UI_IORATE]
The [UI_IORATE] Health Point indicates the sum of
1. the number of scan-based input values the Interface collects before it performs
exception reporting; and
2. the number of event-based input values the Interface collects before it performs
exception reporting; and
3. the number of values that the Interface writes to output tags that have a SourceTag.
The Interface updates this point at the same frequency as the [UI_HEARTBEAT] point. The
value of this [UI_IORATE] Health Point may be zero. A stale timestamp for this point
indicates that this Interface has stopped collecting data.

[UI_MSGCOUNT]
The [UI_MSGCOUNT] Health Point tracks the number of messages that the Interface has
written to the pipc.log file since start-up. In general, a large number for this point indicates
that the Interface is encountering problems. You should investigate the cause of these
problems by looking in pipc.log.
The Interface updates the value of this point every 60 seconds. While the Interface is running,
the value of this point never decreases.

[UI_POINTCOUNT]
The [UI_POINTCOUNT] Health Point counts number of PI tags loaded by the interface. This
count includes all input, output and triggered input tags. This count does NOT include any
Interface Health tags or performance points.
The interface updates the value of this point at startup, on change and at shutdown.

[UI_OUTPUTRATE]
After performing an output to the device, this Interface writes the output value to the output
tag if the tag has a SourceTag. The [UI_OUTPUTRATE] Health Point tracks the number of
these values. If there are no output tags for this Interface, it writes the System Digital State No
Result to this Health Point.
The Interface updates this point at the same frequency as the [UI_HEARTBEAT] point’s.
The Interface resets the value of this point to zero at each performance summary interval.

[UI_OUTPUTBVRATE]
The [UI_OUTPUTBVRATE] Health Point tracks the number of System Digital State values
that the Interface writes to output tags that have a SourceTag. If there are no output tags for
this Interface, it writes the System Digital State No Result to this Health Point.
The Interface updates this point at the same frequency as the [UI_HEARTBEAT] point’s.
The Interface resets the value of this point to zero at each performance summary interval.

DNP 3.0 Interface 143

Interface Diagnostics Configuration

[UI_TRIGGERRATE]
The [UI_TRIGGERRATE] Health Point tracks the number of values that the Interface writes
to event-based input tags. If there are no event-based input tags for this Interface, it writes the
System Digital State No Result to this Health Point.
The Interface updates this point at the same frequency as the [UI_HEARTBEAT] point’s.
The Interface resets the value of this point to zero at each performance summary interval.

[UI_TRIGGERBVRATE]
The [UI_TRIGGERRATE] Health Point tracks the number of System Digital State values
that the Interface writes to event-based input tags. If there are no event-based input tags for
this Interface, it writes the System Digital State No Result to this Health Point.
The Interface updates this point at the same frequency as the [UI_HEARTBEAT] point’s.
The Interface resets the value of this point to zero at each performance summary interval.

[UI_SCIORATE]
You can create a [UI_SCIORATE] Health Point for each Scan Class in this Interface. The
ICU uses a tag naming convention such that the suffix “.sc1” (for example,
sy.st.etamp390.E1.Scan Class IO Rate.sc1) refers to Scan Class 1, “.sc2” refers to
Scan Class 2, and so on.
A particular Scan Class’s [UI_SCIORATE] point indicates the number of values that the
Interface has collected. If the current value of this point is between zero and the
corresponding [UI_SCPOINTCOUNT] point, inclusive, then the Interface executed the scan
successfully. If a [UI_SCIORATE] point stops updating, then this condition indicates that an
error has occurred and the tags for the scan class are no longer receiving new data.
The Interface updates the value of a [UI_SCIORATE] point after the completion of the
associated scan.
Although the ICU allows you to create the point with the suffix “.sc0”, this point is not
applicable to this Interface.

[UI_SCBVRATE]
You can create a [UI_SCBVRATE] Health Point for each Scan Class in this Interface. The
ICU uses a tag naming convention such that the suffix “.sc1” (for example,
sy.st.etamp390.E1.Scan Class Bad Value Rate.sc1) refers to Scan Class 1,
“.sc2” refers to Scan Class 2, and so on.
A particular Scan Class’s [UI_SCBVRATE] point indicates the number System Digital State
values that the Interface has collected.
The Interface updates the value of a [UI_SCBVRATE] point after the completion of the
associated scan.
Although the ICU allows you to create the point with the suffix “.sc0”, this point is not
applicable to this Interface.

[UI_SCSCANCOUNT]
You can create a [UI_SCSCANCOUNT] Health Point for each Scan Class in this Interface.
The ICU uses a tag naming convention such that the suffix “.sc1” (for example,
144
 sy.st.etamp390.E1.Scan Class Scan Count.sc1) refers to Scan Class 1, “.sc2”
refers to Scan Class 2, and so on.
A particular Scan Class’s [UI_ SCSCANCOUNT] point tracks the number of scans that the
Interface has performed.
The Interface updates the value of this point at the completion of the associated scan. The
Interface resets the value to zero at each performance summary interval.
Although there is no “Scan Class 0”, the ICU allows you to create the point with the suffix
“.sc0”. This point indicates the total number of scans the Interface has performed for all of its
Scan Classes.

[UI_SCSKIPPED]
You can create a [UI_SCSKIPPED] Health Point for each Scan Class in this Interface. The
ICU uses a tag naming convention such that the suffix “.sc1” (for example,
sy.st.etamp390.E1.Scan Class Scans Skipped.sc1) refers to Scan Class 1, “.sc2”
refers to Scan Class 2, and so on.
A particular Scan Class’s [UI_SCSKIPPED] point tracks the number of scans that the
Interface was not able to perform before the scan time elapsed and before the Interface
performed the next scheduled scan.
The Interface updates the value of this point each time it skips a scan. The value represents
the total number of skipped scans since the previous performance summary interval. The
Interface resets the value of this point to zero at each performance summary interval.
Although there is no “Scan Class 0”, the ICU allows you to create the point with the suffix
“.sc0”. This point monitors the total skipped scans for all of the Interface’s Scan Classes.

[UI_SCPOINTCOUNT]
You can create a [UI_SCPOINTCOUNT] Health Point for each Scan Class in this Interface.
The ICU uses a tag naming convention such that the suffix “.sc1” (for example,
sy.st.etamp390.E1.Scan Class Point Count.sc1) refers to Scan Class 1, “.sc2”
refers to Scan Class 2, and so on.
This Health Point monitors the number of tags in a Scan Class.
The Interface updates a [UI_SCPOINTCOUNT] Health Point when it performs the associated
scan.
Although the ICU allows you to create the point with the suffix “.sc0”, this point is not
applicable to this Interface.

[UI_SCINSCANTIME]
You can create a [UI_SCINSCANTIME] Health Point for each Scan Class in this Interface.
The ICU uses a tag naming convention such that the suffix “.sc1” (for example,
sy.st.etamp390.E1.Scan Class Scan Time.sc1) refers to Scan Class 1, “.sc2”
refers to Scan Class 2, and so on.
A particular Scan Class’s [UI_ SCINSCANTIME] point represents the amount of time (in
milliseconds) the Interface takes to read data from the device, fill in the values for the tags,
and send the values to the PI Server.
The Interface updates the value of this point at the completion of the associated scan.
DNP 3.0 Interface 145
Interface Diagnostics Configuration

[UI_SCINDEVSCANTIME]
You can create a [UI_SCINDEVSCANTIME] Health Point for each Scan Class in this
Interface. The ICU uses a tag naming convention such that the suffix “.sc1” (for example,
sy.st.etamp390.E1.Scan Class Device Scan Time.sc1) refers to Scan Class 1,
“.sc2” refers to Scan Class 2, and so on.
A particular Scan Class’s [UI_ SCINDEVSCANTIME] point represents the amount of time
(in milliseconds) the Interface takes to read data from the device and fill in the values for the
tags.
The value of a [UI_ SCINDEVSCANTIME] point is a fraction of the corresponding
[UI_SCINSCANTIME] point value. You can use these numbers to determine the percentage
of time the Interface spends communicating with the device compared with the percentage of
time communicating with the PI Server.
If the [UI_SCSKIPPED] value is increasing, the [UI_SCINDEVSCANTIME] points along
with the [UI_SCINSCANTIME] points can help identify where the delay is occurring:
whether the reason is communication with the device, communication with the PI Server, or
elsewhere.
The Interface updates the value of this point at the completion of the associated scan.

I/O Rate Point

An I/O Rate point measures the rate at which the Interface writes data to its input tags. The
value of an I/O Rate point represents a 10-minute average of the total number of values per
minute that the Interface sends to the PI Server.
When the Interface starts, it writes 0 to the I/O Rate point. After running for ten minutes, the
Interface writes the I/O Rate value. The Interface continues to write a value every 10 minutes.
When the Interface stops, it writes 0.
The ICU allows you to create one I/O Rate point for each copy of this Interface. Select this
Interface from the Interface drop-down list, click IO Rate in the parameter category pane, and
check Enable IORates for this Interface.

146
 As the preceding picture shows, the ICU suggests an Event Counter number and a Tagname
for the I/O Rate Point. Click the Save button to save the settings and create the I/O Rate point.
Click the Apply button to apply the changes to this copy of the Interface.
You need to restart the Interface in order for it to write a value to the newly created I/O Rate
point. Restart the Interface by clicking the Restart button:

(The reason you need to restart the Interface is that the PointSource attribute of an I/O Rate
point is Lab.)
To confirm that the Interface recognizes the I/O Rate Point, look in the pipc.log for a
message such as:
PI-ModBus 1> IORATE: tag sy.io.etamp390.ModbusE1 configured.
To see the I/O Rate point’s current value (snapshot), click the Refresh snapshot button:

Enable IORates for this Interface

The Enable IORates for this interface check box enables or disables I/O Rates for the current
interface. To disable I/O Rates for the selected interface, uncheck this box. To enable I/O
Rates for the selected interface, check this box.

Event Counter
The Event Counter correlates a tag specified in the iorates.dat file with this copy of the
interface. The command-line equivalent is /ec=x, where x is the same number that is
assigned to a tag name in the iorates.dat file.

Tagname
The tag name listed under the Tagname column is the name of the I/O Rate tag.

Tag Status
The Tag Status column indicates whether the I/O Rate tag exists in PI. The possible states are:
 Created – This status indicates that the tag exist in PI
 Not Created – This status indicates that the tag does not yet exist in PI
 Deleted – This status indicates that the tag has just been deleted

DNP 3.0 Interface 147

Interface Diagnostics Configuration

 Unknown – This status indicates that the PI ICU is not able to access the PI
Server

In File
The In File column indicates whether the I/O Rate tag listed in the tag name and the event
counter is in the IORates.dat file. The possible states are:
 Yes – This status indicates that the tag name and event counter are in the
IORates.dat file
 No – This status indicates that the tag name and event counter are not in the
IORates.dat file

Snapshot
The Snapshot column holds the snapshot value of the I/O Rate tag, if the I/O Rate tag exists
in PI. The Snapshot column is updated when the IORates/Status Tags tab is clicked, and when
the Interface is first loaded.

Right Mouse Button Menu Options

Create
Create the suggested I/O Rate tag with the tag name indicated in the Tagname column.

Delete
Delete the I/O Rate tag listed in the Tagname column.

Rename
Allow the user to specify a new name for the I/O Rate tag listed in the Tagname column.

Add to File
Add the tag to the IORates.dat file with the event counter listed in the Event Counter Column.

Search
Allow the user to search the PI Server for a previously defined I/O Rate tag.

Interface Status Point

The PI Interface Status Utility (ISU) alerts you when an interface is not currently writing data
to the PI Server. This situation commonly occurs if
 the monitored interface is running on an Interface Node, but the Interface Node
cannot communicate with the PI Server; or
 the monitored interface is not running, but it failed to write at shutdown a System
state such as Intf Shut.
The ISU works by periodically looking at the timestamp of a Watchdog Tag. The Watchdog
Tag is a tag whose value a monitored interface (such as this Interface) frequently updates. The
Watchdog Tag has its excdev, excmin, and excmax point attributes set to 0. So, a non-

148
 changing timestamp for the Watchdog Tag indicates that the monitored interface is not
writing data.
Please see the Interface Status Interface for complete information on using the ISU. PI
Interface Status runs only on a PI Server Node.
If you have used the ICU to configure the PI Interface Status Utility on the PI Server Node,
the ICU allows you to create the appropriate ISU point. Select this Interface from the
Interface drop-down list and click Interface Status in the parameter category pane. Right
click on the ISU tag definition window to bring up the context menu:

Click Create to create the ISU tag.

Use the Tag Search button to select a Watchdog Tag. (Recall that the Watchdog Tag is one of
the points for which this Interface collects data.)
Select a Scan frequency from the drop-down list box. This Scan frequency is the interval at
which the ISU monitors the Watchdog Tag. For optimal performance, choose a Scan
frequency that is less frequent than the majority of the scan rates for this Interface’s points.
For example, if this Interface scans most of its points every 30 seconds, choose a Scan
frequency of 60 seconds. If this Interface scans most of its points every second, choose a
Scan frequency of 10 seconds.
If the Tag Status indicates that the ISU tag is Incorrect, right click to enable the context
menu and select Correct.

Note: The PI Interface Status Utility – and not this Interface – is responsible for
updating the ISU tag. So, make sure that the PI Interface Status Utility is running
correctly.

DNP 3.0 Interface 149

 Appendix A. Error and Informational Messages

A string NameID is pre-pended to error messages written to the message log. Name is a non-
configurable identifier that is no longer than 9 characters. ID is a configurable identifier that
is no longer than 9 characters and is specified using the /id parameter on the startup
command-line.

Message Logs
The location of the message log depends upon the platform on which the Interface is running.
See the UniInt Interface User Manual for more information.
Messages are written to PIHOME\dat\pipc.log at the following times.
 When the Interface starts many informational messages are written to the log.
These include the version of the interface, the version of UniInt, the
command-line parameters used, and the number of points.
 As the Interface loads points, messages are sent to the log if there are any
problems with the configuration of the points.
 If the UniInt /dbUniInt parameter is found in the command-line, then various
informational messages are written to the log file.

DNP 3.0 Interface 151

 Messages

Informational

Message 07-Dec-07 16:57:34

PIDNP3 1> Starting PI DNP3 Interface Version 3.0.1.0
Build Date: 07-Dec-2007 16:55:27
Meaning This message informs the user that the interface is starting and lists the version number
of the interface.

Message 07-Dec-07 16:57:34

PIDNP3 1> INFO> The interface is configured using the
following startup parameters:
Interface instance (/Id): 1
Interface debug level (/DNPDbg): 0x00000001
Write I/O Timeout (/IOTimeOut): No
XML Configuration file (/XML):
D:\PI\interfaces\DNP3\pidnp3.xml
Connection retry rate (/Retry): 10 seconds
Thread pool size (/IOPool): 5
DNP3 Event class (/Event): Scanclass 1
Log RTU configuration (/NoLogRTUParams): Yes
Maximum log file size (/RTULogSize): 100KB
Device status log (/NoDevStatLog): Yes,
d:\PI\interfaces\DNP3\devstat\ pidnp3_devstat_1.csv
Meaning This message informs the user of the parameters being used for interface startup.

Message 07-Dec-07 16:57:34

PIDNP3 1> INFO> There are 2 RTU(s) assigned to the
interface.
Capacitor #123456789(4), Capacitor #987654321(5)
Meaning This message informs the user of the RTU Name (DNP3 Address) assigned to the
interface.

Message 07-Dec-07 16:57:34

PIDNP3 1> Parameters for RTU Name: Capacitor #23495246, Address: 4
RTU Master Address: 3
Communication will be via 192.168.45.30:20000
Event type data timestamped with UnAdjusted RTU time.
RTU time will be synchronized with PI every 24 hours.
RTU time is Local Standard Time (LST).
Integrity Scans every 2 minute(s).
Integrity scans immediately after a communications failure.
Attempt to clear the IIN “Restart” bit if set.
Meaning This message informs the user of the parameters defined in the xml configuration file
that are being used for the RTU.

DNP 3.0 Interface 152

 Message 07-Dec-07 16:57:35
PIDNP3 1> RTU Name: Capacitor #23495246, Address: 4
RTU reset on communication medium >
192.168.45.30:20000.
There are 37 PI-Point(s) assigned to this RTU.
Meaning This message informs the user that the interface is connected to the RTU and displays
the number of tags configured for the RTU.

System Errors and PI Errors

System errors are associated with positive error numbers. Errors related to PI are associated
with negative error numbers.

Error Descriptions on Windows

Descriptions of system and PI errors can be obtained with the pidiag utility:
\PI\adm\pidiag – e error_number

UniInt Failover Specific Error Messages

Informational

Message 16-May-06 10:38:00

DNP3 1> UniInt failover: Interface in the “Backup” state.
Meaning Upon system startup, the initial transition is made to this state. While in this state the
interface monitors the status of the other interface participating in failover. When
configured for Hot failover, data received from the data source is queued and not sent
to the PI Server while in this state. The amount of data queued while in this state is
determined by the failover update interval. In any case, there will be typically no more
than two update intervals of data in the queue at any given time. Some transition chains
may cause the queue to hold up to five failover update intervals worth of data.

Message 16-May-06 10:38:05

DNP3 1> UniInt failover: Interface in the “Primary” state
and actively sending data to PI. Backup interface not
available.
Meaning While in this state, the interface is in its primary role and sends data to the PI Server as
it is received. This message also states that there is not a backup interface participating
in failover.

Message 16-May-06 16:37:21

DNP3 1> UniInt failover: Interface in the “Primary” state
and actively sending data to PI. Backup interface
available.
Meaning While in this state, the interface sends data to the PI Server as it is received. This
message also states that the other copy of the interface appears to be ready to take
over the role of primary.

DNP 3.0 Interface 153

Error and Informational Messages

Errors (Phase 1 & 2)

Message 16-May-06 17:29:06

DNP3 1> One of the required Failover Synchronization
points was not loaded.
Error = 0: The Active ID synchronization point was not
loaded.
The input PI tag was not loaded
Cause The Active ID tag is not configured properly.
Resolution Check validity of point attributes. For example, make sure Location1 attribute is valid
for the interface. All failover tags must have the same PointSource and
Location1 attributes. Modify point attributes as necessary and restart the interface.

Message 16-May-06 17:38:06

DNP3 1> One of the required Failover Synchronization
points was not loaded.
Error = 0: The Heartbeat point for this copy of the
interface was not loaded.
The input PI tag was not loaded
Cause The Heartbeat tag is not configured properly.
Resolution Check validity of point attributes. For example, make sure Location1 attribute is valid
for the interface. All failover tags must have the same PointSource and Location1
attributes. Modify point attributes as necessary and restart the interface.

Message 17-May-06 09:06:03

DNP3 > The Uniint FailOver ID (/UFO_ID) must be a positive
integer.
Cause The UFO_ID parameter has not been assigned a positive integer value.
Resolution Change and verify the parameter to a positive integer and restart the interface.

Message 17-May-06 09:06:03

DNP3 1> The Failover ID parameter (/UFO_ID) was found but
the ID for the redundant copy was not found
Cause The /UFO_OtherID parameter is not defined or has not been assigned a positive
integer value.
Resolution Change and verify the /UFO_OtherID parameter to a positive integer and restart
the interface.

154
 Errors (Phase 2)

Unable to open synchronization file

Message 27-Jun-08 17:27:17
PI Eight Track 1 1> Error 5: Unable to create file
‘\\georgiaking\GeorgiaKingStorage\UnIntFailover\\PIEightT
rack_eight_1.dat’
Verify that interface has read/write/create access on
file server machine.
Initializing UniInt library failed
Stopping Interface
Cause This message will be seen when the interface is unable to create a new failover
synchronization file at startup. The creation of the file only takes place the first time
either copy of the interface is started and the file does not exist. The error number
most commonly seen is error number 5. Error number 5 is an “access denied” error
and is likely the result of a permissions problem.
Resolution Ensure the account the interface is running under has read and write permissions for
the folder. The “log on as” property of the Windows service may need to be set to an
account that has permissions for the folder.

Error Opening Synchronization File

Message Sun Jun 29 17:18:51 2008
PI Eight Track 1 2> WARNING> Failover Warning: Error = 64
Unable to open Failover Control File
‘\\georgiaking\GeorgiaKingStorage\Eight\PIEightTrack_eigh
t_1.dat’
The interface will not be able to change state if PI is
not available
Cause This message will be seen when the interface is unable to open the failover
synchronization file. The interface failover will continue to operate correctly as long as
communication to the PI Server is not interrupted. If communication to PI is interrupted
while one or both interfaces cannot access the synchronization file, the interfaces will
remain in the state they were in at the time of the second failure, so the primary
interface will remain primary and the backup interface will remain backup.
Resolution Ensure the account the interface is running under has read and write permissions for
the folder and file. The “log on as” property of the Windows service may need to be set
to an account that has permissions for the folder and file.

DNP 3.0 Interface 155

 Appendix B. PI SDK Options

To access the PI SDK settings for this Interface, select this Interface from the Interface drop-
down list and click UniInt – PI SDK in the parameter category pane.

Disable PI SDK
Select Disable PI SDK to tell the Interface not to use the PI SDK. If you want to run the
Interface in Disconnected Startup mode, you must choose this option.
The command line equivalent for this option is /pisdk=0.

Use the Interface’s default setting

This selection has no effect on whether the Interface uses the PI SDK. However, you must not
choose this option if you want to run the Interface in Disconnected Startup mode.

Enable PI SDK
Select Enable PI SDK to tell the Interface to use the PI SDK. Choose this option if the PI
Server version is earlier than 3.4.370.x or the PI API is earlier than 1.6.0.2, and you want to
use extended lengths for the Tag, Descriptor, ExDesc, InstrumentTag, or
PointSource point attributes. The maximum lengths for these attributes are:

Attribute Enable the Interface to use PI Server earlier than 3.4.370.x or PI

the PI SDK API earlier than 1.6.0.2, without the
use of the PI SDK
Tag 1023 255
Descriptor 1023 26
ExDesc 1023 80
InstrumentTag 1023 32
PointSource 1023 1

However, if you want to run the Interface in Disconnected Startup mode, you must not
choose this option.
The command line equivalent for this option is /pisdk=1.

DNP 3.0 Interface 157

DNP 3.0 Interface 158
 Appendix C. Sample PI Tag Configurations

Heartbeat Tags

Interface (non-UniInt health tag)

Tag: Interface_Heartbeat
Location1 = ID
Location2 = 0
Location3 = 0
Location4 = N/A
Location5 = 0
InstrumentTag = HEARTBEAT

RTU
Tag: RTU_Heartbeat
Location1 = ID
Location2 = 0
Location3 = DNP Slave Address
Location4 = N/A
Location5 = 0
InstrumentTag = HEARTBEAT

Reset Link Counter Tag

Tag: RTU_ResetLinkCounter
Location1 = ID
Location2 = 0
Location3 = DNP Slave Address
Location4 = n (Where n is update interval in minutes. Range: 1 – 60)
Location5 = 0
InstrumentTag = RESETLINK

DNP3 Internal Indication (IIN) Tags

Tag: IIN_Name (see table in PI Point Configuration, Location2)
Location1 = ID
Location2 = Indicator_Name (value 1-14, table in DNP3 Internal Indications (IIN))
Location3 = DNP Slave Address
Location4 = 0
Location5 = 80

DNP 3.0 Interface 159

 Location2 Internal Indication (IIN)
1 ALL Stations
All stations message received.
Set when a request is received with the destination address of the all
stations address (ffff hexadecimal).
Cleared after next response (even if response to global request is
required).
Used to let the master station know that a Broadcasted message was
received by this station.
2 Class 1 data available
Set when data that has been configured as Class 1 data is ready to be
sent to the master.
Master station should request this class data from the Outstation when
this bit is set in a response.
3 Class 2 data available
Set when data that has been configured as Class 2 data is ready to be
sent to the master
Master station should request this class data from the Outstation when
this bit is set in a response
4 Class 3 data available
Set when data that has been configured as Class 3 data is ready to be
sent to the master
Master station should request this class data from the Outstation when
this bit is set in a response
5 Need Time
Time-synchronization required from the master. The master
synchronizes the time by writing the Time and Date object to the
Outstation.
Cleared when the time is set by the master. This bit is also cleared
when the master explicitly writes a 0 into this bit of the Internal
Indication object of the Outstation.
6 Local
Set when some or all of the Outstation’s digital output points are in the
Local state. That is, the Outstation’s control outputs are NOT accessible
through the DNP protocol.
Clear when the Outstation is in the Remote state. That is, the
Outstation’s control outputs are accessible through the DNP protocol.
7 Device Trouble
Set when an abnormal condition exists at the Outstation. The device
profile for a given device states the conditions that affect this bit.
This should only be used when the state cannot be described by a
combination of one or more of the other IIN bits.
8 Device Restart
Set when the user application at the Outstation restarts.
Cleared when the master explicitly writes a 0 into this bit of the Internal
Indications object in the Outstation.
9 Bad Function
Function code not implemented
10 Unknown Object
Requested object(s) unknown. The Outstation does not have the
specified objects or there are no objects assigned to the requested
class.
This indication should be used for debugging purposes and usually
indicates a mismatch in device profiles or configuration problems.

DNP 3.0 Interface 160

 Location2 Internal Indication (IIN)
11 Out of Range
Parameters in the qualifier range or data fields are not valid or out of
range. This is a catch-all for application request formatting errors.
This indication should be used for debugging purposes and usually
indicates configuration problems.
12 Buffer Overflow
Event buffer(s), or other application buffers have overflowed. For
example, COS/SOE buffers have overflowed.
The master should attempt to recover as much data as possible and
indicate to the user that their may be lost data. The appropriate error
recovery procedures should be initiated by the user.
13 Already Executing
Request understood but requested operation is already executing.
14 Bad Configuration
Set to indicate that the current configuration in the Outstation is corrupt
and that the master application layer should inform the user of this
exception. The master may download another configuration to the
Outstation.
Note that sometimes a corrupt configuration will disable an Outstation,
making it impossible to communicate this condition to a master station.
15 Reserved
16 Reserved

Value Tags
Tag: Value_Object_Index
Location1 = ID
Location2 = DNP Object Index
Location3 = DNP Slave Address
Location4 = Scanclass is solicited. Zero if unsolicited.
Location5 = DNP Object Type
InstrumentTag = DNP Object Variation

If scaling is required:

Convers = See explanation below for details.

Span = See explanation below for details.
Squareroot = See explanation below for details.
UserReal1 = See explanation below for details.
UserReal2 = See explanation below for details.
Zero = See explanation below for details.

All data coming from a DNP 3.0 compliant device is one of four types; binary, 8 bit status, 16
bit integer, or 32 bit integer. The PI DNP3 interface supports scaling the 16 bit and 32 bit
integer types. The scaling for these types adheres to one of the following formulas depending
on the value of the PI tag squareroot attribute. The following definitions describe the
different variables of the formula;
 value is the 16 or 32 bit value received from the RTU

DNP 3.0 Interface 161

Sample PI Tag Configurations

 def_range is the default range and is equal to 65,536 (216) for 16-bit values and
4,294,967,296 (232) for 32-bit integer/short float values. Long float (64-bit real)
values received from the RTU will be treated the same as 32-bit values due to
limitations of the operating system.
 def_min is the default minimum and it is equal to is –32,768 (-215) for 16-bit
values and –2,147,483,648 (-231) for 32-bit integer/short float values. Long float
(64-bit real) values received from the RTU will be treated the same as 32-bit
values due to limitations of the operating system.
 instr_min is the instrument zero and is found in the PI point UserReal1 attribute
 instr_range is the instrument range and is equal to the PI point UserReal2
attribute
 pispan is equal to the PI point attribute span
 pizero is equal to the PI point attribute zero
squareroot Formula applied
0 value written to PI
1 value (value is assumed to be unsigned integer)
2
2 value
3 value written to PI (value is treated as an unsigned integer)
 value - def_min 
4   pispan   pizero
 def_range 
 value 
5   pispan   pizero
 def_range 
 value - instr_min 
6   pispan   pizero
 instr_rang e 
 value 
7   pispan   pizero
 instr_range 
8 value  convers

Status Tags
Tag: Status_Object_Index
Location1 = ID
Location2 = DNP Object Index
Location3 = DNP Slave Address
Location4 = Scanclass is solicited. Zero if unsolicited.
Location5 = -DNP Object Type (negative of DNP Object Type)
InstrumentTag = DNP Object Variation
DigitalSet = See included digital state sets
PointType = Digital

162
 Counter Freeze Tags (Object 20)

Counter Freeze Tag (Output)

When defining an output tag to be used in freezing and/or clearing all counters, the following
attributes must be defined.
Tag: Freeze_All_Tags
Location1 = ID
Location2 = Don’t Care
Location3 = DNP Slave Address
Location4 = 0
Location5 = 20
InstrumentTag = FREEZE
UserInt1 = -1 (See table below)
PointType = int32 or digital
SourceTag = Tag that the output value comes from. See Freezing/Clearing Counters section
of Principles of Operation for required value.
When defining an output tag to be used in freezing and/or clearing a range of counters, the
following attributes must be defined.
Tag: Freeze_Range_Of_Tags
Location1 = ID
Location2 = Starting index of counter object to be frozen
Location3 = DNP Slave Address
Location4 = 0
Location5 = 20
InstrumentTag = FREEZE
UserInt1 = Stopping index of counter object to be frozen. (See table below)
PointType = int32 or digital
SourceTag = Tag that the output value comes from. See Freezing/Clearing Counters section
of Principles of Operation for required value.

Counter Freeze Tag (Input)

The return value stored in PI is the value of the type of freeze request performed on the
object. See the definition of the UserInt2 point attribute.
When defining an input tag to be used in freezing and/or clearing all counters, the following
attributes must be defined.
Tag: Freeze_All_Tags
Location1 = ID
Location2 = Don’t Care
Location3 = DNP Slave Address
Location4 = Scanclass (cannot be an event scanclass.)
Location5 = 20
InstrumentTag = FREEZE
UserInt1 = -1 (See table below)
UserInt2 = type of freeze being requested. (See table below)
DigitalSet = DNP_FreezeCodes
PointType = Digital

DNP 3.0 Interface 163

Sample PI Tag Configurations

When defining an input point to be used in freezing and/or clearing a range of counters. The
following attributes must be defined.
Tag: Freeze_Range_Of_Tags
Location1 = ID
Location2 = Starting index of counter object to be frozen
Location3 = DNP Slave Address
Location4 = Scanclass (cannot be an event scanclass).
Location5 = 20
InstrumentTag = FREEZE
UserInt1 = Stopping index of counter object to be frozen. (See table below)
UserInt2 = type of freeze being requested. (See table below)
DigitalSet = DNP_FreezeCodes
PointType = Digital

Userint1 Value Meaning

-1 Freeze or Freeze/Clear all counters. The output value of the tag
specifies what action will be taken
n The value of n represents the stopping index of the Binary
Counter to be Frozen or Frozen/Cleared. Where n is a valid
Binary Counter index. When n is specified, a Location2 starting
index must also be supplied.

Userint2 Value Function

0 Immediate Freeze
1 Immediate Freeze, No Ack
2 Freeze and Clear
3 Freeze and Clear, No Ack

Analog Control Block (Object 41)

Output Tag
Tag: ACB_Object_Index
Location1 = ID
Location2 = DNP Object Index
Location3 = DNP Slave Address
Location4 = 0
Location5 = 41
InstrumentTag = DNP Object Variation (valid range 1-4)
UserInt2 = DNP Function. (See table below)
PointType = int32, float32, or float64
SourceTag = Tag that the output value comes from. This is the value written
to the object.
Userint2 Value Function
0 Select and Operate
1 Direct Operate
2 Direct Operate, No Ack

164
 Time and Date (Object 50)
Tag: RTU_Time_Date
Location1 = ID
Location2 = 0
Location3 = DNP Slave Address
Location4 = Scanclass
Location5 = 50
InstrumentTag = 1
PointType = string, int32, or float64

Octet String (Object 110/111)

Tag: RTU_Octet_String
Location1 = ID
Location2 = DNP Object Index
Location3 = DNP Slave Address
Location4 = Scanclass is solicited. Zero if unsolicited.
Location5 = 110
InstrumentTag = 1—255 (Required)
PointType = blob or string

It is recommended to use a variation of 255 when creating PI tags to read an Octet String in
order to read the maximum size of an Octet String. If the size of the Octet String received
from the RTU is less than 255, the length of the Octet String stored in PI will reflect the
smaller size

DNP 3.0 Interface 165

 Appendix D. Device Profile Document

DNP V3.00
DEVICE PROFILE DOCUMENT
This document must be accompanied by a table having the following headings:
Object Group Request Function Code Response Function Codes
Object Variation Request Qualifiers Response Qualifiers
Object Name (optional)
Vendor Name: OSIsoft, Inc.
Device Name: PI DNP3 Interface to the PI system (Version 2.x.x.x)
Highest DNP Level Supported: Device Function:
For Requests: N/A  Master  Slave
For Responses: Level 1
Notable objects, functions, and/or qualifiers supported in addition to the Highest DNP Levels Supported (the
complete list is described in the attached table):
The PI DNP3 interface supports the DNP 3.0 Level 1 Master protocol for Polled Static and Polled Report-by-
Exception data. Additionally, the interface provides a subset of the DNP 3.0 Level 2 and Level 3 Master protocol
for requesting specific object type, index number, and variation to retrieve static data. The PI DNP3 interface is
capable of producing Analog outputs and counter Freeze functioning. The PI DNP3 interface is not capable of
handling unsolicited messages from DNP 3.0 slave devices. The sending of unsolicited messages must be
disabled in the slave devices.

Maximum Data Link Frame Size (octets): Maximum Application Fragment Size (octets):
Transmitted _______ Transmitted (if >2048, must be configurable)
Received ___292_ (must be 292) Received Unlimited (must be >= 249)
Maximum Data Link Re-tries: Maximum Application Layer Re-tries:
 None  None
 Fixed at _______________________  Configurable, range 0 to 15
 Configurable, range 0 to 15 (Fixed is not permitted)
Requires Data Link Layer Confirmation:
 Never
 Always
 Sometimes Requests to RESET Link.
 Configurable If ‘Configurable’, how? ______________________________________________
Requires Application Layer Confirmation:
 Never
 Always (not recommended)
 When reporting Event Data (Slave devices only)
 When sending multi-fragment responses (Slave devices only)
 Sometimes If ‘Sometimes’, when? ______________________________________________
 Configurable If ‘Configurable’, how? ______________________________________________

DNP 3.0 Interface 167

 Timeouts while waiting for:
Data Link Confirm  None  Fixed at _________  Variable  Configurable
Complete Appl. Fragment  None  Fixed at _________  Variable  Configurable
Application Confirm  None  Fixed at _________  Variable  Configurable
Complete Appl. Response  None  Fixed at _________  Variable  Configurable
Others __________________________________________________________________________
Note: Timeout parameters are configured bythe ReadTimeout parameter defined in the XML device
configuration file.
Sends/Executes Control Operations:
WRITE Binary Outputs  Never  Always  Sometimes  Configurable
SELECT/OPERATE  Never  Always  Sometimes  Configurable
DIRECT OPERATE  Never  Always  Sometimes  Configurable
DIRECT OPERATE – NO ACK  Never  Always  Sometimes  Configurable
Count > 1  Never  Always  Sometimes  Configurable
Pulse On  Never  Always  Sometimes  Configurable
Pulse Off  Never  Always  Sometimes  Configurable
Latch On  Never  Always  Sometimes  Configurable
Latch Off  Never  Always  Sometimes  Configurable
Queue  Never  Always  Sometimes  Configurable
Clear Queue  Never  Always  Sometimes  Configurable
Note: Configurable parameters are described in the PI Point Configuration and Appendix B: Sample PI Tag
Configurations.

FILL OUT THE FOLLOWING ITEM FOR MASTER DEVICES ONLY:

Expects Binary Input Change Events:
 Either time-tagged or non-time-tagged for a single event
 Both time-tagged and non-time-tagged for a single event
 Configurable (attach explanation)
FILL OUT THE FOLLOWING ITEMS FOR SLAVE DEVICES ONLY:
Reports Binary Input Change Events when no Reports time-tagged Binary Input Change Events when
specific variation requested: no specific variation requested:
 Never  Never
 Only time-tagged  Binary Input Change With Time
 Only non-time-tagged  Binary Input Change With Relative Time
 Configurable to send both, one or the other  Configurable (attach explanation)
(attach explanation)
Sends Unsolicited Responses: Sends Static Data in Unsolicited Responses:
 Never  Never
 Configurable (attach explanation)  When Device Restarts
 Only certain objects  When Status Flags Change
 Sometimes (attach explanation) No other options are permitted.
 ENABLE/DISABLE UNSOLICITED
Function codes supported

DNP 3.0 Interface 168

 Default Counter Object/Variation: Counters Roll Over at:
 No Counters Reported  No Counters Reported
 Configurable (attach explanation)  Configurable (attach explanation)
 Default Object ______________  16 Bits
Default Variation ______________  32 Bits
 Point-by-point list attached  Other Value _____________
 Point-by-point list attached
Sends Multi-Fragment Responses:  Yes  No

DNP Object & Variation Request Response

Obj Var Description Func Qual Func Qual
Codes Codes Codes Codes
(dec) (hex) (dec) (hex)
1 0 Binary Input – All Variations 1 (Read) 00, 01, 06
1 1 Binary Input 1 (Read) 00, 01, 06 129 00, 01
1 2 Binary Input with Flag 1 (Read) 00, 01, 06 129 00, 01
2 0 Binary Input Change – All Variations 1 (Read) 06
2 1 Binary Input Change w/out Time 1 (Read) 06 129 17, 18
2 2 Binary Input Change with Time 1 (Read) 06 129 17, 18
2 3 Binary Input Change 1 (Read) 06 129 17, 18
3 0 Double-bit Input – All Variations 1 (Read) 00, 01, 06
3 1 Double-bit Input 1 (Read) 00, 01, 06 129 00, 01
3 2 Double-bit Input with Flag 1 (Read) 00, 01, 06 129 00, 01
4 0 Double-bit Input Change – All Variations 1 (Read) 06
4 1 Double-bit Input Change w/out Time 1 (Read) 06 129 17, 18
4 2 Double-bit Input Change with Time 1 (Read) 06 129 17, 18
4 3 Double-bit Input Change 1 (Read) 06 129 17, 18
10 0 Binary Output – All Variations 1 (Read) 00, 01, 06
10 1 Binary Output 1 (Read) 00, 01, 06 129 00, 01
10 2 Binary Output 1 (Read) 00, 01, 06 129 00, 01
20 0 Binary Acc – All Variations 7 (Immed 00, 01, 06
Freeze)
8 (Immed.
Fr. Noack)
9 (Fr. Clr)
10 (Fr. Clr
Noack)
20 0 Binary Acc – All Variations 1 (Read) 00, 01, 06
20 1 32-bit Binary Acc 1 (Read) 00, 01, 06 129 00, 01
20 2 16-bit Binary Acc 1 (Read) 00, 01, 06 129 00, 01
20 3 32-bit Delta Acc 1 (Read) 00, 01, 06 129 00, 01
20 4 16-bit Delta Acc 1 (Read) 00, 01, 06 129 00, 01
20 5 32-bit Binary Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
20 6 16-bit Binary Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
20 7 32-bit Binary Delta Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01

DNP 3.0 Interface 169

Device Profile Document

DNP Object & Variation Request Response

Obj Var Description Func Qual Func Qual
Codes Codes Codes Codes
(dec) (hex) (dec) (hex)
20 8 16-bit Binary Delta Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
21 0 Frozen Acc – All Variations 1 (Read) 00, 01, 06
21 1 32-bit Frozen Acc 1 (Read) 00, 01, 06 129 00, 01
21 2 16-bit Frozen Acc 1 (Read) 00, 01, 06 129 00, 01
21 3 32-bit Frozen Delta Acc 1 (Read) 00, 01, 06 129 00, 01
21 4 16-bit Frozen Delta Acc 1 (Read) 00, 01, 06 129 00, 01
21 5 32-bit Frozen Acc with Time of Freeze 1 (Read) 00, 01, 06 129 00, 01
21 6 16-bit Frozen Acc with Time of Freeze 1 (Read) 00, 01, 06 129 00, 01
21 7 32-bit Frozen Delta Acc with Time of 1 (Read) 00, 01, 06 129 00, 01
Freeze
21 8 16-bit Frozen Delta Acc with Time of 1 (Read) 00, 01, 06 129 00, 01
Freeze
21 9 32-bit Frozen Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
21 10 16-bit Frozen Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
21 11 32-bit Frozen Delta Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
21 12 16-bit Frozen Delta Acc w/out Flag 1 (Read) 00, 01, 06 129 00, 01
22 0 Acc Change Event – All Variations 1 (Read) 06
22 1 32-bit Acc Change Event w/out Time 1 (Read) 06 129 17, 28
22 2 16-bit Acc Change Event w/out Time 1 (Read) 06 129 17, 28
22 3 32-bit Delta Acc Change Event w/out Time 1 (Read) 06 129 17, 28
22 4 16-bit Delta Acc Change Event w/out Time 1 (Read) 06 129 17, 28
22 5 32-bit Acc Change Event with Time 1 (Read) 06 129 17, 28
22 6 16-bit Acc Change Event with Time 1 (Read) 06 129 17, 28
22 7 32-bit Delta Acc Change Event with Time 1 (Read) 06 129 17, 28
22 8 16-bit Delta Acc Change Event with Time 1 (Read) 06 129 17, 28
23 0 Frozen Acc Events – All Variations 1 (Read) 06
23 1 32-bit Frozen Acc Event w/out Time 1 (Read) 06 129 17, 28
23 2 16-bit Frozen Acc Event w/out Time 1 (Read) 06 129 17, 28
23 3 32-bit Frozen Delta Acc Event w/out Time 1 (Read) 06 129 17, 28
23 4 16-bit Frozen Delta Acc Event w/out Time 1 (Read) 06 129 17, 28
23 5 32-bit Frozen Acc Event with Time 1 (Read) 06 129 17, 28
23 6 16-bit Frozen Acc Event with Time 1 (Read) 06 129 17, 28
23 7 32-bit Frozen Delta Acc Event with Time 1 (Read) 06 129 17, 28
23 8 16-bit Frozen Delta Acc Event with Time 1 (Read) 06 129 17, 28
30 0 Analog Input – All Variations 1 (Read) 00, 01, 06
30 1 32-bit Analog Input 1 (Read) 00, 01, 06 129 00, 01
30 2 16-bit Analog Input 1 (Read) 00, 01, 06 129 00, 01
30 3 32-bit Analog Input w/out Flag 1 (Read) 00, 01, 06 129 00, 01
30 4 16-bit Analog Input w/out Flag 1 (Read) 00, 01, 06 129 00, 01
30 5 Short Floating Analog Input 1 (Read) 00, 01, 06 129 00, 01
30 6 Long Floating Analog Input 1 (Read) 00, 01, 06 129 00, 01
31 0 Frozen Analog Input – All Variations 1 (Read) 00, 01, 06

170
DNP Object & Variation Request Response
Obj Var Description Func Qual Func Qual
Codes Codes Codes Codes
(dec) (hex) (dec) (hex)
31 1 32-bit Frozen Analog Input 1 (Read) 00, 01, 06 129 00, 01
31 2 16-bit Frozen Analog Input 1 (Read) 00, 01, 06 129 00, 01
31 3 32-bit Frozen Analog Input w/ Time of 1 (Read) 00, 01, 06 129 00, 01
Freeze
31 4 16-bit Frozen Analog Input w/ Time of 1 (Read) 00, 01, 06 129 00, 01
Freeze
31 5 32-bit Frozen Analog Input w/out Flag 1 (Read) 00, 01, 06 129 00, 01
31 6 16-bit Frozen Analog Input w/out Flag 1 (Read) 00, 01, 06 129 00, 01
31 7 Short Floating Frozen Analog Input 1 (Read) 00, 01, 06 129 00, 01
31 8 Long Floating Frozen Analog Input 1 (Read) 00, 01, 06 129 00, 01
32 0 Analog Change Event – All Variations 1 (Read) 06
32 1 32-bit Analog Change Event w/out Time 1 (Read) 06 129 17, 28
32 2 16-bit Analog Change Event w/out Time 1 (Read) 06 129 17, 28
32 3 32-bit Analog Change Event with Time 1 (Read) 06 129 17, 28
32 4 16-bit Analog Change Event with Time 1 (Read) 06 129 17, 28
32 5 Single Precision Analog Change Event 1 (Read) 06 129 17, 28
32 6 Double Precision Analog Change Event 1 (Read) 06 129 17, 28
32 7 Single Precision Analog Change Event 1 (Read) 06 129 17, 28
with Time
32 8 Double Precision Analog Change Event 1 (Read) 06 129 17, 28
with Time
33 0 Frozen Analog Event – All Variations 1 (Read) 06
33 1 32-bit Frozen Analog Event w/out Time 1 (Read) 00, 01, 06 129 17, 28
33 2 16-bit Frozen Analog Event w/out Time 1 (Read) 00, 01, 06 129 17, 28
33 3 32-bit Frozen Analog Event with Time 1 (Read) 00, 01, 06 129 17, 28
33 4 16-bit Frozen Analog Event with Time 1 (Read) 00, 01, 06 129 17, 28
33 5 Short Floating Frozen Analog Event 1 (Read) 00, 01, 06 129 17, 28
33 6 Long Floating Frozen Analog Event 1 (Read) 00, 01, 06 129 17, 28
33 7 Single Precision Frozen Analog Change 1 (Read) 06 129 17, 28
Event with Time
33 8 Double Precision Frozen Analog Change 1 (Read) 06 129 17, 28
Event with Time
40 0 Analog Output Status – All Variations 1 (Read) 00, 01, 06
40 1 32-bit Analog Output Status 1 (Read) 00, 01, 06 129 00, 01
40 2 16-bit Analog Output Status 1 (Read) 00, 01, 06 129 00, 01
40 3 Short Floating Analog Output 1 (Read) 00, 01, 06 129 00, 01
40 4 Long Floating Analog Output 1 (Read) 00, 01, 06 129 00, 01
41 1 32-bit Analog Output Status 3 (Select) 17, 28 129 Echo of
4 (Operate) request
5 (Dir Op)
6 (DirOp,
NoAck

DNP 3.0 Interface 171

Device Profile Document

DNP Object & Variation Request Response

Obj Var Description Func Qual Func Qual
Codes Codes Codes Codes
(dec) (hex) (dec) (hex)
41 2 16-bit Analog Output Status 3 (Select) 17, 28 129 Echo of
4 (Operate) request
5 (Dir Op)
6 (DirOp,
NoAck
41 3 Short Floating Analog Output 3 (Select) 17, 28 129 Echo of
4 (Operate) request
5 (Dir Op)
6 (DirOp,
NoAck
41 4 Long Floating Analog Output 3 (Select) 17, 28 129 Echo of
4 (Operate) request
5 (Dir Op)
6 (DirOp,
NoAck
50 0 Time and Data – All Variations
50 1 Time and Date 1 (Read) 07, 129 07
2 (Write) quantity=1
51 0 Time and Data CTO – All Variations
51 1 Time and Date CTO 129 07
51 2 Unsynchronized Time and Date CTO 129 07
52 0 Time Delay – All Variations
52 1 Time Delay Coarse 129 07
52 2 Time Delay Fine 129 07
60 1 Class 0 Data 1 (Read) 06
60 2 Class 1 Data 1 (Read) 06
60 3 Class 2 Data 1 (Read) 06
60 4 Class 3 Data 1 (Read) 06
80 1 Internal Indications 2 (Write) 00, index=7
110 1- Octet String Static 1 (Read) 00, 01, 06 129 00, 01
255
111 1- Octet String Event 1 (Read) 06 129 00, 01
255

172
 Tips for Non-Conformant DNP3
Appendix E.
Devices

RTU Not Responding to Reset Link Request

The RTU does not seem to be responding to interface requests as indicated by the following
pipc.log message:
02-Mar-06 14:34:35
PIDNP3 1> INFORMATIONAL MESSAGE> RTU Name: DNP3 Device, RTU Address: 100
RTU Connect and Reset failed.
User level reset device failed.
Data Link Layer confirm acknowledgement failed.
Data link receive next message failed.
Expected message not received from RTU within timeout period.
Sent message:
05, 64, 05, c0, 64, 00, 0a, 00, 7a, 97,

Received message:
05, 64, 05, 00, 03, 00, 64, 00, 3e, 0e,

Windows System Error: 0

02-Mar-06 14:34:35
PIDNP3 1> INFORMATIONAL MESSAGE> RTU Name: DNP3 Device, RTU Address: 100
Attempting to connect and reset RTU once every 5 seconds.

Check the following.

1. Verify interface node can ping RTU device.
2. Run the interface with debug level of /dnpdbg=0x0011.
3. Check the RTU log file for the following message,
3/2 20:52:58.204 - 05, 64, 05, c0, 64, 00, 0a, 00, 7a, 97,
3/2 20:53:4.580 - 05, 64, 05, c0, 64, 00, 0a, 00, 7a, 97,
3/2 20:53:10.283 - 05, 64, 05, c0, 64, 00, 0a, 00, 7a, 97,
3/2 20:53:15.939 - 05, 64, 05, c0, 64, 00, 0a, 00, 7a, 97,
3/2 20:53:26.549 - 05, 64, 05, c0, 64, 00, 0a, 00, 7a, 97,

4. In the xml file for the interface, add the attribute NoResetLinkReply to the RTU
node as shown. See the Device Configuration (XML) File section for more details.
<PIDNP.Session Address=“10“ DLRetries=“3“ ALRetries=“3“>
<IOGroup Type=“TCP“>
<Port>20000</Port>
<IP>211.224.48.186</IP>
<RTUInfo>
<Address>100</Address>
<IntegrityScan>1</IntegrityScan>
<TimeSync>0:UTC</TimeSync>
<TimeSource>RTU</TimeSource>

DNP 3.0 Interface 173

 <ReadTimeout>5000</ReadTimeout>
<NoResetLinkReply>1</NoResetLinkReply>
</RTUInfo>
</IOGroup>
</PIDNP.Session>

5. Restart the interface.

If interface Resets the RTU, then the RTU is not configured to respond to Data Link layer
Reset Link request.

DNP 3.0 Interface 174

 Appendix F. Technical Support and Resources

You can read complete information about technical support options, and access all of the
following resources at the OSIsoft Technical Support Web site:
http://techsupport.osisoft.com (http://techsupport.osisoft.com)

Before You Call or Write for Help

When you contact OSIsoft Technical Support, please provide:

 Product name, version, and/or build numbers
 Computer platform (CPU type, operating system, and version number)
 The time that the difficulty started
 The log file(s) at that time

Help Desk and Telephone Support

You can contact OSIsoft Technical Support 24 hours a day. Use the numbers in the table
below to find the most appropriate number for your area. Dialing any of these numbers will
route your call into our global support queue to be answered by engineers stationed around
the world.
Office Location Access Number Local Language Options
San Leandro, CA, USA 1 510 297 5828 English
Philadelphia, PA, USA 1 215 606 0705 English
Johnson City, TN, USA 1 423 610 3800 English
Montreal, QC, Canada 1 514 493 0663 English, French
Sao Paulo, Brazil 55 11 3053 5040 English, Portuguese
Frankfurt, Germany 49 6047 989 333 English, German
Manama, Bahrain 973 1758 4429 English, Arabic
Singapore 65 6391 1811 English, Mandarin
86 021 2327 8686 Mandarin
Perth, WA, Australia 61 8 9282 9220 English

DNP 3.0 Interface 175

 Support may be provided in languages other than English in certain centers (listed above)
based on availability of attendants. If you select a local language option, we will make best
efforts to connect you with an available Technical Support Engineer (TSE) with that language
skill. If no local language TSE is available to assist you, you will be routed to the first
available attendant.
If all available TSEs are busy assisting other customers when you call, you will be prompted
to remain on the line to wait for the next available TSE or else leave a voicemail message. If
you choose to leave a message, you will not lose your place in the queue. Your voicemail
will be treated as a regular phone call and will be directed to the first TSE who becomes
available.
If you are calling about an ongoing case, be sure to reference your case number when you call
so we can connect you to the engineer currently assigned to your case. If that engineer is not
available, another engineer will attempt to assist you.

Search Support

From the OSIsoft Technical Support Web site, click Search Support.
Quickly and easily search the OSIsoft Technical Support Web site’s Support Solutions,
Documentation, and Support Bulletins using the advanced MS SharePoint search engine.

Email-based Technical Support

[email protected]
When contacting OSIsoft Technical Support by email, it is helpful to send the following
information:
 Description of issue: Short description of issue, symptoms, informational or error
messages, history of issue
 Log files: See the product documentation for information on obtaining logs
pertinent to the situation.

Online Technical Support

From the OSIsoft Technical Support Web site, click Contact us > My Support > My Calls.
Using OSIsoft’s Online Technical Support, you can:
 Enter a new call directly into OSIsoft’s database (monitored 24 hours a day)
 View or edit existing OSIsoft calls that you entered
 View any of the calls entered by your organization or site, if enabled
 See your licensed software and dates of your Service Reliance Program
agreements

DNP 3.0 Interface 176

 Remote Access

From the OSIsoft Technical Support Web site, click Contact Us > Remote Support Options.
OSIsoft Support Engineers may remotely access your server in order to provide hands-on
troubleshooting and assistance. See the Remote Access page for details on the various
methods you can use.

On-site Service

From the OSIsoft Technical Support Web site, click Contact Us > On-site Field Service Visit.
OSIsoft provides on-site service for a fee. Visit our On-site Field Service Visit page for more
information.

Knowledge Center

From the OSIsoft Technical Support Web site, click Knowledge Center.
The Knowledge Center provides a searchable library of documentation and technical data, as
well as a special collection of resources for system managers. For these options, click
Knowledge Center on the Technical Support Web site.
 The Search feature allows you to search Support Solutions, Bulletins, Support
Pages, Known Issues, Enhancements, and Documentation (including user
manuals, release notes, and white papers).
 System Manager Resources include tools and instructions that help you manage:
Archive sizing, backup scripts, daily health checks, daylight savings time
configuration, PI Server security, PI System sizing and configuration, PI trusts
for Interface Nodes, and more.

Upgrades

From the OSIsoft Technical Support Web site, click Contact Us > Obtaining Upgrades.
You are eligible to download or order any available version of a product for which you have
an active Service Reliance Program (SRP), formerly known as Tech Support Agreement
(TSA). To verify or change your SRP status, contact your Sales Representative or Technical
Support (http://techsupport.osisoft.com/) for assistance.

OSIsoft Virtual Campus (vCampus)

The OSIsoft Virtual Campus (vCampus) Web site offers a community-oriented program that
focuses on PI System development and integration. The Web site’s annual online
subscriptions provide customers with software downloads, resources that include a personal
development PI System, online library, technical webinars, online training, and community-
oriented features such as blogs and discussion forums.
OSIsoft vCampus is intended to facilitate and encourage communication around PI
programming and integration between OSIsoft partners, customers and employees. See the

DNP 3.0 Interface 177

Technical Support and Resources

OSIsoft vCampus Web site, http://vCampus.osisoft.com (http://vCampus.osisoft.com) or

contact the OSIsoft vCampus team at [email protected] for more information.

178
 Appendix G. Revision History

Date Author Comments

26-Feb-02 JAC Initial writing. Used Skeleton Version 1.11
21-Mar-02 CG Fixed headers and footers; TOC; formatting
12-Apr-02 JAC Initial Release version 1.0
22-May-02 JAC Updated to version 1.1
16-Nov-04 Driddell Version 2.0.5.0
8-Dec-04 M Kelly Made changes to screenshots and fixed several
section. Fixed headers and footers; TOC.
21-Mar-05 M Kelly Fixed formatting, headers and footers, TOC, page
references.
10-May-05 Driddell Add details related to freezing counters.
15-Jun-05 M Kelly Added section on Configuring the Interface with PI
ICU. Fixed TOC.
13-Jul-05 M Kelly Updated the screen shot for the ICU section, fixed
sample batch file and XML file to match one
installed by release, updated digital state section to
match files provided by release. Made Final.
03-Aug-05 Driddell Updated to version 2.0.5.1. Cover change only.
21-Sep-05 Driddell Updated to version 2.0.5.3. Added Heartbeat tag
information to Principles of Operation and PI Point
Configuration sections.
13-Oct-05 Driddell Version 2.0.5.4. Added attribute “RequestQualifier”
and “IntegrityReconnect” to xml file.
23-Nov-05 Driddell Version 2.0.5.18. Added /retry command line
parameter. Added “RtuName” attribute to xml file
for message logging. Added debug level for
communications medium to startup command file.
19-Dec-05 Driddell Version 2.1.3.0. Modify appendices, added
sections on questionable data, internal indications,
added example PI tag configurations, added
section on using a multi-character point source.
02-Mar-06 Driddell Version 2.1.3.1. Add attributes “ClearRestart”,
“NoResetLinkReply”, and “autotime” to the
“TimeSynch” attribute. Add Appendix D.
18-Apr-06 Driddell Version 2.1.3.3. Built against UniInt 4.1.5
19-Apr-06 Driddell Updated to skeleton 2.4
20-May-06 Driddell Version 2.2.0.0
07-Dec-07 Driddell Version 3.0.1.0. Add Data Handling section, Add
/IOPool, /IOSleep, /WorkerPool, /NoDevStatLog,
/NoLogRTUParams, and /RTULogSize startup

DNP 3.0 Interface 179

Date Author Comments
command parameters. Add RTU status logging and
UniInt Device status information. Add Reset Link
Counter Tag. Add support for Double-bit Input
object. Remove “Delay”, “ConnectTimeout”, and
“WriteTimeout” attributes from xml file. Modify
“Request Qualifier” attribute in xml file. Modify
Interface and RTU Heartbeat tags.
20-Feb-2008 Mkelly Version 3.0.1.0 Rev A; Updated ICU Control
section. Fixed headers and footers. Updated TOC.
Added new items to the support features table.
Fixed installation checklist.
7-Apr-2008 Janelle Version 3.0.1.0 Revision B: updated headers; minor
formatting changes.
10-Apr-2008 Driddell Version 3.0.1.0 Revision C: added information
about digital states in the section Upgrading to
Version 3.0.1.0.
10-Dec-2010 Sbranscomb Version 3.0.1.0 Revision D; Converted to Interface
Skeleton Manual Version 3.0.30.
03-Jan-2011 MKelly Version 3.0.1.0 Revision E; Added changed for
Interface Manual Skelton 3.0.31.
10-Jan-2011 Driddell Version 3.0.3.x; Added new startup command file
parameters. Added uniint phase 2 failover.
09-Feb-2011 MKelly Version 3.0.3.x, Revision A; Updated all the ICU
Control screenshots and descriptions adding the
four new command line parameters. This ICU
Control was rearranged also. Fixed several other
formatting problems.
04-Mar-2011 Driddell Version 3.0.3.x. Added “CloseOnDataError”
element to the xml configuration file.
13-Jul-2011 Driddell Version 3.1.0.x. Added Uniint Phase 2 Hot Failover.
Added Object 110/111 Octet String Static and
Event.

DNP 3.0 Interface 180