Introduction to PI Interface for DNP3

This document describes the use of the PI Interface for DNP 3.0, 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 XP 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 DNP3 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 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 Upgrading to version 3.0.1.0 or later section of this manual before upgrading.

The recommended requirements for this interface are as follows:

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

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

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

The value of the [PIHOME] variable for the 32-bit interface depends 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 the [PIHOME64] variable for a 64-bit interface is C:\Program Files\PIPC on the 64-bit operating system. In this documentation [PIHOME] represents the value of either [PIHOME] or [PIHOME64]. The value of [PIHOME] is the directory which is the common location for PI client applications.

This interface was built using a UniInt version (4.5.0.59 and later) which writes all its messages to the local PI Message log. Any references to PIPC.log are erroneous and actually 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.

OSIsoft is revising product documentation and other literature to reflect the evolution of the PI Server from a single server to a multi-server architecture. Specifically, the original historian core of the PI Server is now referred to as the Data Archive. Originally, the PI Server was a single server that contained the Data Archive and other subsystems. To add features and improve scalability, the PI Server has evolved from a single server to multiple servers. While the Data Archive remains a core server of the PI Server product, the product name PI Server now refers to much more than the Data Archive. OSIsoft documentation, including this user manual, is changing to use PI Server in this broader sense and Data Archive to refer to the historian core.