Professional Documents
Culture Documents
DNPMaster Us PDF
DNPMaster Us PDF
Technical Facts
Filename DNPMaster.DLL
Plataform Win32
User Layer
Application Layer
Physical Layer
Communication Media
The figure above shows the EPA structure and how it fits into the entire communication system.
The User Layer can be defined as the place the user will handle data, after all communications. In a SCADA
system it is represented by the user application. It makes use of the Application Layer to send/receive complete
messages to/from a outstation.
The Application Layer is responsible to specify in details the requests from the User Layer, and back to it when
the message comes from the Data Link Layer. In simple words, it joins the messages from User Layer, referred as
a fragment, into a multiple fragment message with complete information to be processed and sent to an
outstation by Data Link Layer.
The Data Link Layer is used to pass messages between primary (originating) stations and secondary (receiving)
© 2014 Enter your company name DRIVER DNP v4.0.21
stations. It also packs data and checks it against transmission errors, and controls the needs of each media, as
RS232, RS485, modems, fibre transceivers, etc.
DNP protocol can be configured to Exchange data using polling (Constant communication), or through an
Integrity-Change schema (more efficient). The data change messages are also known as RBE (Report by
Exception) and can happen spontaneously (unsolicited) or non-spontaneously through explicit request from
Master side.
Function Codes
The function code identifies the purpose of the message. There are two groups of function codes; one for
requests and the other for responses. There are several types of request functions, as shown below. The
response functions are used only internally by the driver to control the messages and are not open for the user.
Object Headers
Objects
The intelligent devices that use the DNP Application Layer are capable of monitor, control and/or produce a great
amount of data. These data are processed and stored as information objects, and are standardized in such a way
to produce an unique way to describe and represent them.
There are four data objects categories:
Static Objects: Reflect the actual value of a field or internal variable.
Event Objects: These objects are generated as a result of a change in a value or any other stimulant. They are
historical objects, i.e., reflect the data value at some moment in the past.
Frozen Static Objects: Reflect the “frozen” value of a field or internal variable. Data are frozen as a result of a data
freeze request.
Frozen Event Objects: These are the objects obtained by the change of a frozen data or any other stimulant. They
are historical objects, i.e., reflect the data value at some moment in the past.
Each category is represented with a different object, shown below:
Object Description
Digital Inputs The binary input grouping contains all objects that represent binary (status or Boolean)
input information. The objects 1 - 9 are reserved for these objects.
Digital Outputs The binary output grouping contains all objects that represent binary output or relay control
information. The objects 10 - 19 are reserved for these objects.
Counters The counter grouping contains all objects that represent counters. The objects 20 - 29 are
reserved for these objects.
Analog Inputs The analog input grouping contains all objects that represent analog input information. The
objects 30 - 39 are reserved for these objects.
Analog Outputs The analog output grouping contains all objects that represent analog output information.
The objects 40 - 49 are reserved for these objects.
Time The time grouping contains all objects that represent time in absolute or relative form in any
resolution. The objects 50 - 59 are reserved for these objects.
Classes The class grouping contains all objects that represent data classes or data priority. The
objects 60 - 69 are reserved for these objects.
Files The files’ grouping contains all objects that represent files or a file system. The objects 70 -
79 are reserved for these objects.
Devices The devices grouping contains all objects that represent device (rather than point)
information. The objects 80 - 89 are reserved for these objects.
Applications The applications’ grouping contains all objects that represent software applications or
operating system processes. The objects 90 - 99 are reserved for these objects.
Alternate Numeric The alternate numeric grouping contains all objects that represent alternate or custom
numeric representations. The objects 100 - 109 are reserved for these objects.
Variation
Variations represent changes or object sub-types. As an example, a digital input can be represented by a single bit
(0 or 1), by a status byte or contain or not the time information (timestamp). In this way, the combination of object
and variation describe completely an information. Examples:
Qualifier
Range
Indicates the object amount, initial and final indexes or identifiers for the objects.
Classes
Objects declared in a system or device that implements DNP protocol in a Slave mode can be grouped into classes.
The protocol defines 4 standard classes, like below:
Class 0: It means ALL objects. This is, the master side (this driver for example) at startup can request class 0, and at
the answer the slave side will send the current value of all declared objects.
Class 1 to 3: These are entities that store temporarily event lists(changes) at the objects. Each object needs to be
configured at the slave side to generate events upon data changes, and generally there is a standard between DNP
users to reserve class 1 for digital events, class 2 for analog events and class 3 for counter events.
Elipse DNP Driver implements the Master behavior of DNP protocol, according to Level 2 specification and some
of the Level 3. We recommend the usage of the configurations below:
- Enable Class 0 Upon Startup and at Regular Intervals (see next Page): In this way all tags will have a value at
application startup;
- Use of Unsolicited Messages OR Event Scans at Regular Intervals: Data updates (as changes happen) can be sent
spontaneously by the slave side OR through automatic event requests (Classes 1,2 and 3) by the driver.
- Tag configuration using Event Objects instead of Static Objects: Tags configured as static objects generate
polling communication (Constant message Exchange), thus generating unecessary network traffic. On the other
hand, tags configured as events don´t make communication and are updated automatically as integrity or data
change messages arrive.
Driver Configuration
Configuration - P Parameters
Extra Configurations
DNP
App Timeout (ms): This is the maximum amount of time the App Layer will wait for a complete response of the
request by DataLink layer. If a communication is in course, this time is extended automatically until the finish of
reception. Standard Value: depends on communication speed.
App Read Retries: Number of communication retries done at application layer in case of transaction failure at
read operations. Standard Value: 0.
App Write Retries: Number of communication retries done at application layer in case of transaction failure at
write operations. Standard Value: 0.
Master Address: This is address of the Master station (PC). It must be different from any slave.
Control Relay On-Time: When Sending Control Relay Commands using PLC tags, this field specifies the normal
on-time for Pulse On/Off or Latch On/Off commands.
Control Relay Off-Time: When Sending Control Relay Commands using PLC tags, this field specifies the normal
off-time for Pulse On/Off or Latch On/Off commands.
Default Slave Address: If you use N1=0 in any tag (N1 is the slave DNP address), the 0 will be replaced by the
Default Slave Address defined in this field.
Delay Between Messages: Delay time applied between each message sent by the driver, in miliseconds.
Error Count for Inactive State: Indicates how many consecutive erros the driver will consider to put the device
into INACTIVE state. The driver will retry communication with the device at next Class message or Polling, or only
at the interval informed at the property Demotion Time, is this option is being used.
Other
Counter DeadBand (units): DeadBand amount to check in counters to check if new events are received.
Analog DeadBand (units): DeadBand amount to check in analog points to check if new events are received.
Select/Operate Message Timeout: This is the timeout used to block other driver messages expect operate, right
Private Objects
The private objects are declarations that can be generated by each manufacturer, and reflect data structures
composed by basic DNP data types.
The window above represents two lists: The right one has the objects, composed of an index, a fanufacturer code
(4 characters) , an object id number and the total object bytes. The list can be edited through Add, Update and
Del buttons.
Clicking over each object line, you can insert the DNP objects that will take part of each PRO (Private Registration
Objects). Should be informed the object code, variation and amount. The order is also important, and you can
chage it through arrow, Add, Update e Del buttons.
If you use the time objects (code 50), it will be used as PRO TimeStamp.
The option “Return All PRO Instances as one indexed block tag” makes all PRO’s to be sent to the same block tag,
since they have the same DNP address. In this case, the block needs one more element, since the first element
will contain the PRO index, and then the other elements, as declared.
Tag N Parameters
Function Codes
Supported Objects
Supported Qualifiers
Obj 12, Obj 41 (SELECT,OPERATE, etc.) Us er Defi ned 0, 1, 7, 8, 17, 18, 27, 28, 47, 58
Block B Parameters
Block usage for reading events is NOT permitted as all block elements share a single timestamp, what can´t be
accepted due to the uniqueness of each event with it´s own timestamp. So if you want to use blocks, they will work
only with pollings (B2 parameter = 0 READ FROM CACHE). The exception is the SINGLE BLOCK EVENT, as in this case
the timestamp of each event will be reported in a single fixed block element.
Taking as example a device with DNP Address=3, here we have some examples of N1, N2, N3 and N4 parameters at
format “N1.N2.N3.N4”:
Digital Input 100, Object 1 Variation 2: 3.1.102.100 (configured as static object)
Digital Input 100, Object 2 Variation 2: 3.1.202.100 (configured as event)
At example above, both tags reference the same variable (digital input 100). However, the first tag keeps asking
continuously its value (polling) while the second only receives notifications when the point changes de value.
Beyond that, at the event form the timestamp of the change originated at the device is kept and reported at the tag
timestamp property, while in static mode (as there is no timestamp) the timestamp is the computer local time.
General Comments
General comments and driver specific functions.
The Integrity Command performs a READ request of all data configured at the salve side, for all objects (Class 0) or
for specific objects.
Due to the particularity of DNP protocol to send at integrity the current variable values (therefore as static objects
and not as events), it´s necessary for the driver to process the information in order to unify the static values with
the event values, in a way that the application will need a single tag for the point.
If the application uses tags as events (as recommended) – during initialization, upon receiving an integrity (class 0)
with the static value of a point, a “provisory” event will be generated with tag “Quality” property equal to 216
Event Collection
A correct Driver Event reception is fundamental for the event tags to receive their values. The driver will only
discover that there are events for one of the event classes (1,2 or 3) is the system uses at least one of the options
below:
The option “Scan for Events Every X ms” at driver configuration is enabled. This will instruct the driver
to request the classes at fixed intervals, receiving the events.
The device sends events spontaneously using unsolicited messages.
The application has at least one tag configured for a static object read. (Ex: digital input/output,
analog input/output, etc..)
Commands
When using relay commands (Object 12, Variation 1) a sequence of information fields is sent, as defined below:
Bit 7 6 5 4 3 2 1 0
Trip/Close: This field determines which control relay to activate in a system where a trip and close relay pair is used
to energize and de-energize the field points. The possible values are (in binary): 00 = NUL; 01 = Close; 10 = Trip. The
NUL value in this field can be used to activate the field point select relay only without activating the trip or close
relays. In a system without field point select relays, the NUL value would not perform any control operation. In a
system without trip/close relays, this field should always be NUL to indicate a normal digital control operation
where the exact control point is inherently known. This field does not support having both the trip and close
attributes simultaneously, as this is an illegal operation for the system.
Clear: If the control operation has the Clear attribute set, all control operations are removed from the queue
including the presently running control and this control operation is performed.
Queue: If the control code is NUL then no control operation is queued, and the queue is cleared of all controls
including the presently running control if the Clear attribute is set.
When the control function is executed and completed, it is removed from the queue. If the control block for that
operation had the Queue attribute set, the control operation is re-queued (to the back of the queue) for that point.
Code: The control block can be used with devices which support control queuing on a point per point basis or
devices which have other control mechanisms. In the former, any control command should be queued for the
particular point in question. In the latter, each control is performed until completion before the next control is
accepted for that point.
Byte 1: Count
The Count field determines how many times the control is executed. If the count is 0, do not execute the control.
When the count reaches 0, the control is complete.
Bytes 2 to 5: On Time
The on-time field specifies the amount of time the digital output is to be turned on (may not apply to all control
types).
The Status Field can be obtained at Elipse E3 through the parameter WStatus of WriteEx method (See example
below).
To send this command, you can use single tags (PLC or IOTags) and/or block tags. To use a PLC tag, you have to set a
number from 0 to 255 (corresponding to Control Code byte) as the tag value. The remaining bytes will be obtained
from the Extra dialog definitions.
For the block tag you have to use a script calling the Write() function. To perform this, the block should have four
elements, with individual write properties disabled. The elements are:
Element 0 = Control Code
Element 1 = Count
Element 2 = Relay OnTime
Element 3 = Relay OffTime
This feature can be used if different command settings have to be used for each point, not using the default
OnTime and OffTime settings.
If the option “Use Single Block Read for All Events” is set, you can use a block to receive all events. The block has the
following configuration:
N1 = DNP Address
N2 = 50
N3,N4 = not used
Size: Until 7 elements, as below:
Element 0: Object Code
Quality Information
For the objects with status indications (most of them), this driver performs a mapping to OPC standard used in
Elipse E3, as explained here:
Bit 7 6 5 4 3 2 1 0
Meaning XX XX CF LF RF CL RS OL
Bit 7 6 5 4 3 2 1 0
Meaning 0 RE OR LF RF CL RS OL
Bit 7 6 5 4 3 2 1 0
Obs: Remembering that according to OPC standard, if quality is greater or equal to 192 it is considered GOOD.
History Revision
Branch PR Branch MG
Av. Sete de Setembro, 4698/1705 Rua Antônio de Albuquerque, 156
80240-000 Curitiba - PR 7° andar Sala 705
Phone: (41) 3342-0120 30112-010 Belo Horizonte - MG
Fax: (41) 3342-0120 Phone: (31) 2511-2121
E-mail: elipse-pr@elipse.com.br E-mail: elipse-mg@elipse.com.br
Branch RJ USA
Av. Praia de Botafogo, 300/525 2501 Blue Ridge Road, Suite 250
22250-044 Rio de Janeiro - RJ Raleigh - NC - 27607 USA
Phone: (21) 2158-1015 Phone: +1 (252) 995-6885
Fax: (21) 2158-1099 Fax: +1 (252) 995-5686
E-mail: elipse-rj@elipse.com.br E-mail: info@elipse-software.com
Taiwan
9F., No.12, Beiping 2nd St., Sanmin Dist.
807 Kaohsiung City - Taiwan
Phone: +886 (7) 323-8468
Fax: +886 (7) 323-9656
E-mail: evan@elipse.com.br
www.elipse.com.br
kb.elipse.com.br
elipse@elipse.com.br