Posts Tagged ‘IED’

DNP3_NG – Part 2

Thursday, October 24th, 2013

DNP3_NGIn the previous blog entry, we looked at what is the DNP3_NG driver. Now let us take a closer look at what is new.

With the DNP3_NG driver, it is now possible to automatically create variables in the zenon Editor. One option is to import the XML Device profile that specifies the capabilities of the outstation. The driver allows you to create variables for the items specified in the points list of the device profile. Alternatively, you can carry out an online browse of the outstation. In this case, the driver in the editor will connect to the outstation, perform an integrity poll, and enable you to select which points returned in the integrity poll should be created as variables.

Where the DNP332 driver only supported configuration of a polling interval for the integrity poll and all three event classes together, the DNP3_NG driver allows you to specify both an interval for common event class polls as well as polling intervals for each individual event class.

The DNP3_NG driver now also provides configuration options for unsolicited responses for each event class. When unsolicited responses are supported, you could turn off cyclic polling for event classes and e.g. only perform event polls on demand, triggered from the runtime.

Using the driver object “class scan” you can explicitly trigger an integrity poll or an event poll for the event class specified. Also, you can trigger a read for points that are not included in the integrity poll or any event class. Such a read is also executed after each integrity poll. Device Attributes, for example, are not included in an integrity poll and need to be read explicitly. Using a variable from the type “class scan” it is also possible to trigger a “cold restart” of the outstation.

Variables now also allow individual configuration of the variation. When the Outstation does not return the DNP object in an event class poll in the desired variation, e.g. the object contains no timestamp, you can change the variation at the variable, and set the option “permanently read variable”. After every integrity poll, or after an explicit trigger, the driver will request the DNP objects in the specific variation.

While it was necessary for the DNP332 driver to select the “SBO” flag at the variable, to specify that a Select Before Operate should be executed via Command Input instead of a Direct Operate, with the DNP3_NG driver, this flag needs to stay disabled. Instead, at every variable of the type Binary Output and each Analog Output, a property “Command Mode” defines if a Direct Operate or a Select Before Operate (Automatic SBO) is executed.

When using Command Input it is now also possible to use a Boolean variable instead of an unsigned short integer, and use the Qualifier Of Command to specify whether a Latch On / Off, Pulse On / Off or a Trip / Close will be used.
The DNP3_NG driver also supports Secure Authentication. Currently, Secure Authentication v2 is supported using pre-shared keys.

To get a detailed overview of which functionality is supported by the DNP3_NG driver, the DNP3 XML device profile is installed with an installation of the zenon Editor in the directory: “%CD_PROGRAMDATA7100%communicationprofiles\Dnp3\Driver”. The driver manual (login required) also provides a source for further detailed information.

DNP3_NG – Part 1

Thursday, October 17th, 2013

DNP3_NG“NG” is a common abbreviation for “No Good”. You may therefore find it uncomforting, that especially for newly introduced drivers, the driver name ends with “NG”. There is no need to worry though. Actually quite the opposite of “No Good” is the case here. “NG” as we use it, stands for “Next Generation”. Basically, as demands for support of additional features for a PLC driver grow, there is a turning point where it makes more sense to develop a completely new driver than to continue adding functionality to an existing driver. The new driver will become the “Next Generation” driver for the specific protocol or PLC.

What is the DNP3_NG driver?

The DNP3_NG driver is a new zenon driver for the DNP3 resp. IEEE 1815 protocol. Like the DNP332 driver it allows communication to DNP3 Outstations, sometimes also called DNP3 slaves. The DNP3_NG driver is the successor to the zenon DNP332 driver.

Where do I get the DNP3_NG driver?

The DNP3_NG driver is officially available with zenon 7.10. In fact, when you add a new DNP3 driver to your project in zenon 7.10, only the DNP3_NG driver is available in the list.

Can I still use the old DNP332 driver in zenon 7.10?

Yes, the DNP332 driver is still installed with zenon 7.10 and will continue to be available in future versions. Existing projects with the DNP332 driver that are converted to zenon version 7.10, will still contain and use the DNP332 driver. You will be able to open the driver configuration in the editor and the DNP332 driver will still be used in the runtime. If you want to create the legacy DNP332 driver for an existing or new project in zenon version 7.10, this is also still possible. The procedure how to add the legacy DNP332 driver to the driver selection list is described in the version 7.10 DNP332 driver documentation.

Can I switch from the DNP332 driver to the DNP3_NG driver in zenon 7.10?

Yes, you can make the switch from the DNP332 driver to the DNP3_NG driver for existing projects. Although everything should go smoothly, it makes sense to start off by making a project backup. You will need to make note of the communication parameters in the DNP332 driver configuration. Then in the context menu of the DNP332 driver you can call up the option to exchange the driver to the new DNP3_NG driver. After this process is complete, you will need to reopen the driver configuration of the DNP3_NG driver and input the correct communication parameters which you previously made note of. The output window of the zenon editor will inform you of any possible errors that may occur during the exchange process. For example, with the old DNP332 driver it was possible to select data types for certain driver object types that were not compliant with the DNP3 protocol standard. If such data types are used in the DNP332 driver, a warning message will appear, and the driver exchange is cancelled. To continue, the data type for these variables needs to be changed prior to exchanging the driver again. The manual for the DNP3_NG driver contains further information on how to switch the DNP332 driver to the DNP3_NG driver.

Next time we will look at some of the new features of the DNP3_NG driver and draw up a more detailed comparison between the legacy DNP332 driver and the new DNP3_NG driver.