Addressing Point Type Object Groups
What is DNP?
DNP is an acronym for Distributed Network Protocol, a non-proprietary protocol primarily used for the transmission of data in electric and water companies using SCADA applications. Standards for this protocol come from the International Electrotechnical Commission (IEC), which is the same organization responsible for the IEC61850 protocol that Ignition also supports.
Outstations
DNP3 protocol either passes measured data from or control commands to the plant floor mechanisms by using multiple interconnected outstations. Outstations are considered processes at their core, but will typically be referred to as devices or systems that exist in a plant floor’s network. In order to establish a network of outstations, you need to acknowledge two major components:
- Master: A device in charge of administering control commands and receiving data from other devices.
- Outstation: A device responsible for transferring measured data to its master or control commands from its master.
Inside every outstation resides a database that stores various point data using indices as well as categorizing them into different types. Points are where static, measured values of a monitored plant floor process reside along with other attributes such as name, scale factor, event value, etc. A point’s type provides a way to distinguish different points that may contain similar characteristics. Example point types are:
- Binary Inputs
- Binary Outputs
- Analog Inputs
- Analog Outputs
- Counters
Outstations will update specific types and indices of various points based on changes being monitored on the plant floor. Master outstations will then update their databases with point data coming from outstations they are directly connected to using one of two ways:
- The master will pass specific function codes to an outstation requesting one or more points in its database be updated with any new point data.
- An outstation will pass unsolicited data to the master, regardless of any initial request.
Protocol Specifications
Importation concepts for the protocol involve event-based data acquisition and link-layer framing of data being passed between devices.
Event-Based Data Acquisition
DNP3 uses a method of data acquisition across outstations known as event-based reporting. If you refer to the outstation’s database of points, each and every point is organized by point type and index. Each point’s attributes stay up to date with the most recent values through triggered events in the device. Instead of following the more traditional (and probably more familiar) method of using a tag subscription to periodically poll for specific values available in a device, DNP3 event-based reporting will pass only data due to changes that occurred from a point’s source. The DNP3 processes that rely on events for data are known as Class Polling and Unsolicited messaging.
Class Polling
A point within an outstation’s database will contain one of three class event types in the form of a unique attribute. This attribute is expected to be defined by the DNP3 device programmer before any requests are made. These class attributes give points some level of priority classification in order of 1 (highest priority) to 3 (lowest priority). Prioritization of points may be needed in situations where data from high-priority marked events need to be processed sooner and/or more often than others.
Between the master and outstation, when it comes the time to activate event-based data acquisition between the two, the master is expected to define individual poll rates for the three classes, or at the very least a rate from one class (the rest can be 0) depending on what is configured for your points. The master is also expected to be able to handle multiple events through the use of a temporary buffer each time its class poll receives a new event since polling in this protocol expects a bundle of one or more events that occurred across different points.
Integrity Polling
When a master and outstation have established a connection for the first time, either device has restarted, or a long amount of time has passed and a monitor check is due, an integrity poll is performed. This is because integrity polls will request the synchronization of the entire master database with the outstation, which includes all class 1-3 event data and any static data that is also configured with class attributes. A fourth class type of class 0 exists which is considered the lowest in priority during this poll. This is because class 0 attributes are only applied to objects that return static data and not events. Due to the potentially large volume of data that will be sent to the master with this method, it’s best to use class polling when possible.
Unsolicited Messaging
Unsolicited messaging is another feature that expects the master to handle the buffering of events. Instead of waiting for the master to send a class poll request, outstations will send over an event to the master immediately after a change occurs, hence the name “unsolicited”. Instead of defining class polls, masters can be configured to accept these unsolicited messages from an outstation.
The Data-Link Layer
The connection between master and outstation requires a unique communication layer known as the Data-Link layer. In terms of the OSI networking model, we can define this structure as a lower-level application layer detail. During the scenario of an application request passed between master and outstation, the request itself requires unique addressing information and exception handlers to be attached before being transmitted through the physical layer of a given network. Both the master and outstation are expected to be configured with their own local source addresses as well as whitelisting addresses of request destinations for its established data-link layer.
Once outstation address information is appended to the request, we can expect the frame of the message to be sent as shown in the following diagram:
Data Specifications
Points were mentioned in the above section in terms of where they could be visualized on the hardware, but specific values within a request sent by the master to the Data-Link layer help outstations fetch specific points within their database when needed.
Addressing Point Type Object Groups
Earlier it was mentioned that point types are categorized within the database due to differences in their attributes. This means, every point in an outstation’s database is an addressed object of attributes using three unique integers in a fixed order:
- Group
- Variation
- Index
Group
Group is the first integer of the address that indicates which set of point types to search. There are many different groups of point types. Refer to the user manual for a list of common groups.
Variation
In every point that we wish to select from a group comes a range of options for how the returned data will be encoded. This is represented by the variation integer.
Index
Each point type group is an array within an outstation’s database, which will require a set of indices to organize each point. It is zero-based indexed.
See the user manual for a short table of group and variation options.
Ignition DNP3 Drivers
Currently two DNP3 drivers are available to take the role of a master that passes requests to outstations:
- DNP3 v2
- DNP3 Legacy
The biggest difference between the two devices would be their methods of acquiring data for the OPC-UA server.
As a master, the DNP3 v2 driver will have the ability to accept event-based messages using the process described above, either through class polls or unsolicited messaging. The legacy driver, however, does not have the same ability. Instead, the legacy DNP3 driver only offers the ability to manually subscribe to specific point value attributes using the traditional OPC tag subscription process. This manual subscription to specific points forces the master to bypass any event-based data packaging and instead request an explicit read of static values directly from the source point address. This limitation of the DNP3 Legacy driver has resulted in the introduction of the DNP3 v2 driver.
Sequence of Events
Sequence of Events are the chronological order of event data, and can be preserved using both event-based polling and unsolicited messaging. It’s recommended to use a dedicated tag group with the following non-default settings for OPC UA Queue Size and OPC UA Sampling Interval.
OPC UA Queue Size
This should be increased to the maximum anticipated number of queued events for the configured polling durations or anticipated communication outages. The amount of memory available to the Ignition server is likely to far exceed that of any outstation, and many of them will have small fixed size buffers to hold sets of event data waiting to be requested by the next class poll. The exact size will depend on the outstation implementation and must be derived from available technical documentation.
This is required for both drivers.
OPC UA Sampling Interval
This should be set to 0. In OPC UA, a Sampling Interval of 0 means the server may use event-based reporting for a Monitored Item, rather than sample-based. This must be enabled to allow multiple events that occur closer together in time than a non-zero sampling interval allows to be reported to the client while maintaining OPC UA compliant behavior in the server.
This is not required when using the legacy DNP3 driver, which does not behave in a compliant manner.
Keep in mind that the Sequence of Events configuration described here is Ignition’s way of configuring the Event buffer described in the above section, Class Polling. Once event data is received inside of the OPC-UA server, it is up to individual tag subscriptions with these set tag group properties to establish this event buffer. Without it, all reported events by DNP3 may not make their way to the OPC Client.
Aliased Points
Aliased Points is a Legacy DNP3 feature that allows users to define more meaningful naming conventions for OPC-browsable points. It requires the knowledge of group, variation, and index values to fetch the correct point addresses.
You may have noticed that compared to the Legacy driver, the new DNP3 v2 driver no longer provides a configuration for Aliased Points. This difference also relates to the DNP3 v2 driver’s ability to handle event-based messaging. Aliased point configuration ensures an additional layer of tag subscriptions that forces explicit reads to DNP3 points, which again bypasses any event-based data packaging. In the scenario that users wish to continue using this feature for existing tags after acquiring the DNP3 v2 driver, they must continue using the Legacy DNP3 driver. Despite this, please be informed that the legacy driver will no longer receive support going forward. All future DNP3 updates will be given to the later driver.
Data Link Addressing
The data-link layer section mentioned that additional master and outstation addresses are needed to be defined on both devices for a connection to be established. On the device connection page for both the v2 and Legacy drivers, you will notice Source and Destination address fields that are required on top of the typical host IP and port fields. Since the Ignition driver acts as the master, we can define the source address to any integer we want, so long as it’s not already taken by any other existing DNP3 device connection. The destination address however is expected to be defined in the outstation beforehand using DNP3 programming software.
Request Configurations
Another set of common configuration fields between both drivers will be the Integrity Poll rate fields and Unsolicited Messaging checkboxes. Both concepts were described above as being a way to primarily acquire event-based data to be sent back to a master. However, since the Legacy driver is limited to acquiring only static values from explicit read requests, setting these configurations do not necessarily work the same way since event-based reports were not previously considered at the time.
Command Modes
The last set of common configuration fields between drivers is the ability to switch between two different command modes, Select-Before-Operate and Direct-Operate. Originally this was an IEC process where control objects in IEC devices are programmed to accept commands from clients by specifying one of these “Operate” modes. To keep things simple, some objects are required to acknowledge that they have been “Selected” before being given a command, while others can be given commands immediately.
The DNP3 v2 driver will contain these Command Mode fields for two different sets of point types: binary and analogs. The DNP3 Legacy driver contains a single checkbox labeled Direct Operate Enabled to apply to all point types.
DNP3 Scripting Functions
Since both driver versions have their own primary methods of acquiring data for Ignition, two sets of scripting functions exist:
- Legacy DNP3 drivers use system.dnp3
- DNP3 v2 drivers use system.dnp
Functions from both drivers are expected to carry out the same requests such as operate and freeze commands. The operate function relates to what was mentioned above in the section Command Modes. As for the term freeze, it can be understood as taking a snapshot of a particular point to save in a new location within the same outstation.
Comments
0 comments
Article is closed for comments.