Supported features for PI Interface for DNP3

The following table describes features that this interface supports. Some features are described in more detail after the table.

* See paragraphs below for further explanation.

** For more information, see the "OMF Health Messaging" topic in the PI Universal Interface (UniInt) User Guide.

• Read-only Interface available

  A read-only version of this interface is available. Read-only versions cannot update the data source (that is, control system). If outputs to the data source are not needed, use the read-only version of the interface.

  Note: A read-only interface provides the best defense against accidental or malicious changes to the control system.

• Uses PI SDK

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

• Source of Time stamps

  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 an RTU comes with an RTU1 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 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 (type)	TimeSync (type)	Meaning
  PI	UTC or Local	Data will be time-stamped with the PI Server time at the instance the event was received.
  RTU	UTC	Data will be time-stamped with the raw RTU time with no adjustment.
  RTU*	Local	Data will be time-stamped with the RTU time offset by the difference between UTC and Local Time.
  Adjusted	UTC	Data will be time-stamped with the RTU time offset by the difference between the RTU time and the PI Server time.
  Adjusted	Local	Data will be time-stamped with the RTU time offset by the difference between the 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.

• 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 Data Archive. This functionality is enabled by adding /cachemode to the list of start-up parameters or by enabling disconnected startup using the ICU.

• SetDeviceStatus

  The device status health point produces messages based on the interface device status. Messages that are interface-specific are documented in the interface user guide.

  The following table lists standard status strings:

  Message	Description
  0 | Good	The interface is working properly, and reading/writing data.
  10 | Connected / No Data	The interface is connected to the device, but not receiving data.
  50	The interface is attempting to force failover. This message does not include a string. This message maps to 95 | Device(s) in error.
  90 | Starting	The interface is starting, but not connected to the device.
  95 | Device(s) in error	There is a communication error with the device.
  99 | Intf Shutdown	The interface is shutting down.

• 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 Data Archive 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 PI Universal Interface (UniInt) User Guide, which is a supplement to this manual.

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

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