QN-901 Q-NET RTU PROTOCOL SERVERS · 2019. 1. 30. · The original LAN-based Qnet product operates with a proprietary protocol to allow bi-directional data exchange and control between

QN-901

Q-NET RTU PROTOCOL SERVERS

TDMS-Plus Master Station Software December 2018

TDMS-Plus Master Station QN-901

Software Q-NET RTU Protocol Servers

Q-NET RTU Protocol Servers

Copyright © 2016 by QEI QN-901 Q-NET RTU PROTOCOL SERVERS ALL RIGHTS RESERVED

NOTICE

The information in this document has been carefully checked and is believed to be accurate. However, no responsibility is assumed or implied for inaccuracies. Furthermore, QEI reserves the right to make changes to any products herein described to improve reliability, function or design. QEI does not assume liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights nor the rights of others.

This manual and all data contained constitutes proprietary information of QEI and shall not be reproduced, copied or disclosed to others, or used as the basis for manufacture without written consent of QEI.

.

45 Fadem Road Springfield, NJ 07081 Phone: (973) 379-7400 Fax: (973) 379-2138 Web Site: www.qeiinc.com

http://www.qeiinc.com/



Copyright © 2016 QEI Contents i

Revisions

RRevision Description Date

A Release to Production October 1994

B Formatting Update F February 2003

C Title Change to TDMS-Plus F December 2004

D D Added DNP Server Ff February 2008

E Added Genisys Server March 2012

F Formatting Update August 2013

G DNP SCL Update October 2013

H Implement DNP V2 Secure Authentication

September 2014

I Formatting Update April 2016

J Updates QEI Address December 2018



Copyright © 2016 QEI Contents i

Contents 1 INTRODUCTION ........................................................................1

2 L&N CONITEL 2020 SERVER ...................................................2 2.1 L&N DATASETS .................................................................. 2 2.2 DATA POLLS ....................................................................... 2

2.2.1 Scan ..................................................................... 2 2.2.2 Freeze and Freeze/Reset ..................................... 3

2.3 CONTROLS ......................................................................... 4 2.3.1 Relay Control ........................................................ 4 2.3.2 Raise/Lower Control ............................................. 5 2.3.3 Setpoints ............................................................... 6

2.4 AUTODIAGNOSTICS .......................................................... 6 2.4.1 Start Request ........................................................ 6 2.4.2 Report Request ..................................................... 6

2.5 LOGGING ............................................................................ 6

3 LANDIS & GYR 9000s SERVER ...............................................8 3.1 LANDIS & GYR 9000s DATASETS ...................................... 8 3.2 ANALOG REPORTING ........................................................ 8

3.2.1 Analog Change Report (FC = 0) ............................ 8 3.2.2 Analog Force Report (FC = 1) ............................... 8

3.3 STATUS REPORTING ........................................................ 8 3.3.1 Indication Change Report (FC = 5) ....................... 8 3.3.2 Indication Force Report (FC = 6) ........................... 9

3.4 ACCUMULATOR REPORTING ........................................... 9 3.4.1 Accumulator Freeze (FC = 10) .............................. 9 3.4.2 Accumulator Read (FC = 11) ................................ 9

3.5 CONTROLS ......................................................................... 9 3.5.1 SBO Control Select (FC = 12) ............................... 9 3.5.2 SBO Control Operate (FC = 13) .......................... 10

3.6 REPEAT LAST MESSAGE (FC = 27) ................................ 11 3.7 EXCEPTION BYTE ............................................................ 11

4 GOULD MODBUS PLC SERVER ............................................ 12 4.1 MODBUS DATASETS ....................................................... 12 4.2 OPERATION ..................................................................... 12

4.2.1 Read Output/Coil Status (FN = 1) ....................... 12 4.2.2 Read Input Status (FN = 2) ................................. 12 4.2.3 Read Output/Holding Register (FN = 3) .............. 13 4.2.4 Read Input Register (FN = 4) .............................. 13 4.2.5 Force Single Coil (FN = 5) ................................... 13 4.2.6 Preset Single/Holding Register (FN = 6) ............. 13

4.3 LOGGING .......................................................................... 13

5 GTAC SERVER........................................................................ 15



Copyright © 2016 QEI Contents ii

5.1 GTAC DATASETS ............................................................. 16 5.2 ANALOG/ACCUMULATOR DATA FORMAT ..................... 17 5.3 BUFFERING OF STATUS CHANGES ............................... 17 5.4 CONTROL OPERATIONS ................................................. 17

5.4.1 Control Point Select (CSEL) ................................ 17 5.4.2 Control Point Trip/Close ...................................... 17 5.4.3 Set Point Control ................................................. 18

6 VALMET CIU SERVER ............................................................ 19 6.1 VCIU DATASETS .............................................................. 19 6.2 TEXT MESSAGES ............................................................ 20 6.3 FUNCTIONS ...................................................................... 21

6.3.1 Function 1 – Read 30-Second Data .................... 21 6.3.2 Function 2 – Read 2-Minute Data ....................... 21 6.3.3 Function 3 – Read 4-Minute Data ....................... 22 6.3.4 Function 4 – Read Hourly Data ........................... 22 6.3.5 Function 5 – Read Non-Periodic Data (Text Messages) 22 6.3.6 Function 6 – Send 60-Second Data .................... 23 6.3.7 Function 7 – Send Hourly Data ........................... 23 6.3.8 Function 8 – Send Monthly Data ......................... 23 6.3.9 Function 9 – Send Percent Load Shed ................ 23 6.3.10 Function 10 – Send Scram Command (Arm) ....... 24 6.3.11 Function 11 – Execute Scram Request ............... 24 6.3.12 Function 12 – Send Non-Periodic Data (Text Messages) 25 6.3.13 Function 13 – Acknowledge Non-Periodic Data .. 25 6.3.14 Function 14 – Read 2-Minute Data (ASCII) ......... 25 6.3.15 Function 15 – Read 2-minute Data (ASCII) ......... 25 6.3.16 Function 16 – Send 10 values ............................. 25

6.4 STATUS WORD ................................................................ 26

7 DNP SERVER .......................................................................... 27 7.1 DNP DATASETS ............................................................... 27 7.2 OPERATION ..................................................................... 28 7.3 SCANMON LOGGING ....................................................... 29 7.4 DNP SECURITY CONFIGURATION ................................. 30

7.4.1 INTRODUCTION ................................................ 30 7.4.2 SECURITY CONFIGURATION ........................... 30

8 GENISYS SERVER .................................................................. 33 8.1 GENISYS DATASETS ....................................................... 33 8.2 OPERATION ..................................................................... 34 8.3 SCANMON LOGGING ....................................................... 34 8.4 GENISYS COMMUNICATION PROTOCOL ...................... 35

8.4.1 General Message Format ................................... 35

9 Appendix A – DNP Device Profile Document ....................... 37



Copyright © 2016 QEI INTRODUCTION 1

1 INTRODUCTION The original LAN-based Qnet product operates with a proprietary protocol to allow bi-directional data exchange and control between multiple TDMS-Plus SCADA master stations. Because the data exchange is based on task-to-task communication under DECnet, the package operates over any medium supported by DECnet.

This document describes an extension to the Qnet package to support data exchange on serial data links using RTU protocols. The purpose of this is to make the TDMS-Plus master station appear to other (non-TDMS-Plus) systems as if it were a number of RTUs.

The software extension consists of a family of link server programs, one for each link protocol. Descriptions of the servers implemented for the various RTU protocols are contained in this document.

Each link is served by a separate copy of the server of the appropriate protocol. The function of the server is to:

Reply to poll requests (by mapping the RTU number in the request to a dataset number and formatting the current values of master station points specified in the dataset). If the RTU number does not map to a valid dataset, the server either does not reply or replies with an error indication, depending on the protocol.

Service control requests. For a protocol with a two-step control procedure, the server issues checkback replies to both the select and the execute requests. It then initiates a TDMS-Plus control operation for the appropriate control point specified in the dataset.

This causes other software in the master station to forward a control message sequence to the communication line and RTU specified by the control point’s control address (as defined via the Station editor). The RTUs on this communication line may be operating with a totally different protocol, which may or may not involve its own two-step control procedure.

The RTU servers described in this document use the same Dataset Definitions and Dataset Mapping editors as the LAN-based Qnet. These are described in the following document:

QN-900 Qnet User’s Guide The Dataset Definitions editor (HSLIST) allows the user to specify what data in the master station database is to be sent in reply to RTU-type polls from other systems. The meaning of some of the parameters in the datasets is protocol dependent, and is described in later chapters of this document. The Dataset Mapping editor (QLINK) allows the user to define a number of links to other systems. For each link, the user defines the protocol, the communication port and the mapping of RTU numbers to datasets.



Copyright © 2016 QEI L&N CONITEL 2020 SERVER 2

2 L&N CONITEL 2020 SERVER The QNET server name for the L & N Conitel 2020 protocol is CONI.

A full implementation of this server would have to handle the following types of requests from another master station:

Data poll (SCAN, FREEZE, FREEZE/RESET)

Control (TRIP, CLOSE, EXECUTE, RAISE/LOWER, SETPOINT A/B)

Autodiagnostics (START/REPORT).

The TDMS-Plus implementation supports all of these functions except RAISE/LOWER and SETPOINT A/B. For these requests, the server does not send a reply.

In this document, the names X, Y and Z are used to refer to different fields in the Conitel 2020 RTU message. These names are also used to refer to parameter fields on the Dataset editor. To avoid confusion, use of the names X, Y and Z in this appendix will be in full context. For example, “X section in the message” is used to refer to the RTU message, and “parameter X” is used to refer to the dataset.

2.1 L&N DATASETS

For the L&N Conitel 2020 protocol, the XYZ parameters in the dataset definitions have the following meaning:

X = polling group number (0-15)

Y = length of time period (for raise/lower controls only) – Not Used

Z = status type (for status points section of dataset)

1 = status with MCD (momentary change detect)

0 = status without MCD

= Control type (*for control points section of dataset)

0 = relay control

1 = raise/lower control (Not Used)

2 = setpoint A (Not Used)

3 = setpoint B (Not Used)

2.2 DATA POLLS

2.2.1 Scan

On a “scan” request, the server sends the required data point values in the following order:

Status with MCD (momentary change detect)

Status without MCD

Accumulators

Analogs




The procedure is as follows:

First, the server finds the dataset for the specified RTU and proceeds to the status section of the dataset.

If the RTU number does not map to a valid dataset, the server does not reply to the scan request.

If the required dataset is found, the server scans the status points in the dataset looking only for those whose group number (Xparameter) matches the group number given in the scan request, and whose Z parameter is 1 (= status with MCD). These points are formatted into however many message blocks are required and added to the transmit buffer. Unused bits in the last half-block are set to zero.

The server then scans the status points again, this time picking up only those points with a matching group number and with a Z parameter of 0 (= status without MCD). These are also formatted and added to the transmit buffer. Again, any unused bits in the last half-block are set to zero.

The server then scans the accumulator section of the dataset, collecting and formatting values for all those whose group number (X parameter) matches the group number given in the scan request.

Then it transmits the data reply.

For each analog and accumulator set, the server transmits an unscaled 12-bit value. That is, the engineering value in the database is converted back to a raw form by subtracting the offset and dividing by the scale factor.

NOTE: If the result does not fit into the 12-bit field allowed in the message, then the server

clamps the value at +2047 if positive or –2047 if negative.

For status points without MCD, one bit is sent for each point.

For status points with MCD, the server sends two bits for each point:

The LSB represents the current status in the database

The MSB is a momentary change-detect bit. When set, it means to the other master that a TRIP-CLOSE sequence has occurred for this point since the last scan.

To support MCD processing by the server, the scan task increments the status point’s spare condition code on every change. Every time the server transmits the point’s value, it memorizes the value of the spare condition code. The server sets the MCD bit if the spare condition code changed since the last transmission.

The server does not actually modify the spare condition code, it just memorizes it. This means that any number of servers can transmit this point with change detect bits.

2.2.2 Freeze and Freeze/Reset

These requests are processed in the same way as the “scan” request. The server does not perform any accumulator freeze function. This is done by the scan tasks. The server simply replies with data for the specified group.

An RTU number of zero in the “freeze” or “freeze/reset” request is a broadcast to all RTUs. In this case, the server does not reply.




2.3 CONTROLS

2.3.1 Relay Control

This section describes how the server processes relay control requests.

The relay to be operated is specified in the control request by means of :

The RTU number, given in the ADDRESS field of the 12-bit X section of the message

The group number (0-15), given in the GROUP field of the 12-bit X section of the message

Number within the group, given in the 12-bit Y section of the message

The Y section of the message defines the relative relay number by means of a bit mask with only one bit set. Thus a value of:

1 means relay #1

2 means relay #2

4 means relay #3

8 means relay #4

etc.

On receipt of a “select” (OPEN or CLOSE) request, the server:

Finds the dataset for the specified RTU and proceeds to the controls section of the dataset.

Scans the points in the dataset, looking only at those status points whose group number (Xparameter) matches the group number given in the select requests, and those Z parameter is 0.

NOTE: Relay controls are identified by Z parameter values of 0.

Picks the Nth such point, where N is the relay number given in the select message.

If an Nth point is found, then the server sends a select checkback reply, makes a record of the select in its select buffer, and starts a 5-second timer.

If there is no Nth point in the specified group, the server does not issue a checkback.

If no execute request is received within 5 seconds, or if the next message is not an execute, then the select buffer is cleared.

On receipt of an “execute” request, the server:

Checks for a match of the RTU/group/relay# against the contents of the select buffer.

If there is a match, the server sends an execute checkback reply.

If the point identified during the processing of the select request is controllable, the server issues a standard OPEN or CLOSE control message for this point to the TDMS-Plus control program.

If the point is not controllable (has no control address), then the server simply updates its value in the database, unless the point is manually set. See notes below.

If there is no match, the server does not send a checkback reply, and does not issue any control or perform any database update. If the select buffer is not empty, it is now cleared.




NOTES:

1. Control requests for points that are telemetered to TDMS-Plus but have no TDMS-Plus control addresses are meaningless and are therefore denied (the server does not respond).

2. If the point is a pure pseudo point (that is, it has no telemetry and no control address), then the server simply sets point to the state specified in the control request. This makes it easy for operators at other master stations to set flags in the TDMS-Plus master station in a manner similar to performing control operations. Applications include controlling processes implementing in TDMS-Plus via command sequencing. If a pure pseudo point is manually set, however, the control request cannot be honored and is therefore denied (the server does

not respond).

2.3.2 Raise/Lower Control

The raise/lower request is not implemented. The purpose of the following discussion is to ensure that the dataset and server design allow for a future implementation.

The raise/lower request is a single message specifying:

The RTU number (given in the X section of the message)

Group number (given in the X section of the message)

Up to three raise/lower operations defined in three 4-bit fields in the Y section of the message. The MSB of each of these 4-bit fields defines the direction (1=RAISE, 0=LOWER). The remaining three bits define the control duration as a count of fixed time periods (0-7). A count of 0 is treated as no control. The length of the time period is specified in parameter Y of the control definition in the dataset, and can be different for each of the three raise/lower controls in the group.

No check back is required for this request.

On receipt of a raise/lower request, the server:


Scans the points in the dataset, looking for the first three points whose group number (X parameter) matches the group number given in the raise/lower request, and those Z parameter value is 1.

NOTE: Raise/lower controls are identified by Z parameter values of 1.

For each of any such points found, the server:

- Calculates the control duration by multiplying the duration count (given in the raise/lower message) by the length of one time period (given by the Y parameter in the dataset). If the result is zero, then this raise/lower control is skipped and the server proceeds to the next one.

- Looks up the point’s definition record and obtains the associated control interval point (which must be an analog point).

- Sets the control interval point’s value to the control duration calculated above (overriding and removing any manual set status, if necessary).

- Initiates a standard control operation for the point (OPEN if LOWER, CLOSE if RAISE)

The first point found gets the raise/lower command from the most significant 4 bits of the Y section of the message. The second point (if found) gets the middle 4 bits. The third point (if found) gets the command from the least significant bits.




If there are not points found at all, nothing happens.

2.3.3 Setpoints

The setpoint requests are not implemented. The purpose of the following discussion is to ensure that the dataset and server design allow for a future implementation.

Assuming that the setpoint request contains a 12-bit value, the server would process the request by performing the following steps:

Find a point in the control section of the dataset that has a matching group number (X parameter) and the correct Z parameter:

Z = 2 if setpoint A request

Z = 3 if setpoint B request

This point must be an analog point.

Convert the 12-bit value to an engineering value by applying the point’s scale factor and offset.

If the point is a setpoint, issue a setpoint command using the engineering value computed above (the scan task will unscale the point’s engineering value back to the original 12-bit value before sending it to the destination RTU).

If the point is not a setpoint, than just update its value in the database to equal the engineering value computed above (unless the point is manually set).

2.4 AUTODIAGNOSTICS

2.4.1 Start Request

Any “start” request is acknowledged by simply returning the same message.

2.4.2 Report Request

In response to a “report” request, the server transmits a “no problems” response. This consists of all bits clear in:

the 4 most significant bits in the GROUP field of the X section of the response, and

the 12 least significant bits in the Y section of the response

2.5 LOGGING

The purpose of the logging function is to help in trouble-shooting. The server logs requests received and replies sent, both in HEX and in English, in a format illustrated below:

13:46:42.7 CONISV01 received [%NORMAL”,4] HEX: 0C 21 DE F4 RTU: 2. group:4. Request: “Scan”




CONISV01 sent [“%NORMAL”,4] HEX: 0C 21 DE F4 0C 21 DE F4 0C 21 DE F4 0C 21 DE F4 RTU:2, Group: 4. Response: “Scan” Dataset: 30. Status 002: 0 Status 005: 1 Analog 004: 123. Analog 013: 1104.

13:46:44.4 CONISV01 received [“%NORMAL”,4] HEX: OC 31 AE 14 RTU: 3, Group: 12. Request: “Scan” etc.

The point numbers in the example are point numbers within the dataset.

The logging is enabled by entering commands as follows:

SCANMON CONISV01 x y

Where “x” is the RTU number (0 = all RTUs) and “y” is a command code:

1 = enable logging in English only

2 = enable logging of errors only (in English and HEX)

3 = enable logging in English and HEX

0 = disable logging



Copyright © 2016 QEI LANDIS & GYR 9000s SERVER 8

3 LANDIS & GYR 9000s SERVER The Qnet server name for the Landis & Gyr 9000s protocol is LGYR.

In this implementation, the server responds only to those requests described below. Use of the optional exception byte is limited to that described in 3.7.

3.1 LANDIS & GYR 9000s DATASETS

For the Landis & Gyr 9000S protocol, the XYZ parameters in the dataset definitions have the following meaning:

X = exception deadband (see 3.2.1) - For analog points, in raw counts

Y = control interval timer (see 3.5.1)

Z = not used

3.2 ANALOG REPORTING

3.2.1 Analog Change Report (FC = 0)

The server sends any analog that has changed by at least its deadband. Each point can be assigned its own deadband via the X field (range 0-255) on the dataset editor. The server uses a minimum deadband of 2 to prevent all analogs from being reported on all scans.

For each analog point in the dataset, the server maintains a copy of the last value transmitted plus a copy of the deadband converted to engineering units (i.e. the value of X multiplied by the point’s scale factor). These deadbands are evaluated by the server at start-up. On an exception request, the server compares the point’s current value with its last transmitted value. If the difference is greater than the deadband, the server includes the point in the exception report and updates its last transmitted value.

The value that is transmitted is an unscaled value. The point’s current engineering value is converted to raw form by subtracting the offset and dividing by the scale factor. If the value does not fit into the 12-bit field, it is clamped at + or – 2047.

3.2.2 Analog Force Report (FC = 1)

The server returns all the analog points in the dataset within the requested start/stop addresses. An address in this case is a relative point number within the dataset. Zero values are returned for gaps in the dataset (i.e. for positions where the point entry is blank).

As in the case of a change report, the server updates the last transmitted value for any point it reports.

3.3 STATUS REPORTING

3.3.1 Indication Change Report (FC = 5)

Status points are transmitted in groups of eight. If any point within a group has changed, then all the points in that group are transmitted, along with the appropriate change bits. Zero values are returned for gaps in the dataset (i.e. for positions where the point entry is blank)

For each status point in the dataset, the server maintains the last value transmitted.




For each status point, the change bit is set if at least two transitions have occurred on the point since it was last reported. This makes it possible, for example, for the master to generate OPEN-CLOSE-OPEN transitions in its database for cases where the point is OPEN and the RTU sends another OPEN with the change bit is set. Similarly, if the point was OPEN and the RTU sends CLOSE with the change bit set, the master would generate the sequence OPEN-CLOSE-OPEN-CLOSE.

To support this, the scan task increments the status point’s spare condition code on every change. Every time the server transmits the point’s value, it memorizes both the transmitted value and the value of the spare condition code. Since the scan task increments the spare condition code on every status change, the server knows exactly how many transitions (up to 7) occurred since it last transmitted the point. The server sets the change bit if the spare condition code changed by at least two since the last transmission.

The server does not actually modify the spare condition code, it just memorizes it. This means that any number of servers can transmit this point with change detect bits.

3.3.2 Indication Force Report (FC = 6)

The server returns all the status points in the dataset within the requested start/stop addresses, along with the corresponding change bits. Zero values are returned for gaps in the dataset (i.e. for positions where the point entry is blank).

3.4 ACCUMULATOR REPORTING

3.4.1 Accumulator Freeze (FC = 10)

The server does not actually perform any accumulator freeze function. This is done by the scan tasks.

If the freeze request is directed to a specific RTU, then the server returns an acknowledgment. If it is a broadcast request (to RTU zero), then no response is given.

3.4.2 Accumulator Read (FC = 11)

The server returns the point number of the first defined accumulator in the dataset followed by the values of all the accumulator points up to the last non-blank entry in the dataset. Zero values are returned for gaps in the dataset (i.e. for positions where the accumulator point entry is blank).

The server converts the accumulator values to raw counts by dividing by the scale factor. If the raw value does not fit into the 16-bit field in the message, the server sends 65535.

3.5 CONTROLS

3.5.1 SBO Control Select (FC = 12)

The “select” request contains the point number, the trip/close command and a timer multiplier byte. In a real RTU, the timer is strap selectable. In the server, the timer is specified on a per point basis via the point’s Y parameter in the dataset.




TDMS-Plus control points that are to use this feature must be defined with analog points as the control interval. On a control operation, the server multiplies the point’s Y parameter by the multiplier given in the message and writes this into the point’s associated control interval point. The value of the Y parameter must take the TDMS RTU’s strap selected timer into account.

On Receipt of a “select” request, the server:


Picks the Nth control point, where N is the control point number given in the select message.

If an Nth point is found, then the server sends a select checkback reply, makes a record of the select in its select buffer, and starts a 5 second timer.

If there is no Nth point in the specified group, the server returns an error message (error code 3).

If no execute request is received within 5 seconds, or if the next message is not an execute, then the select buffer is cleared.

3.5.2 SBO Control Operate (FC = 13)

On receipt of the “operate” request, the server:

Checks for a match of the RTU/group/relay# against the contents of the select buffer.

If there is a match, and the point is controllable, the server then checks the control interval. If the timer multiplier given in the select request is non-zero, but the point has no control interval point, the request cannot be honored.

If there is a match, and there is no control interval error, the server sends an execute checkback reply. Then,

If the point identified during the processing of the select request is controllable, the server sets the point’s control interval and issues a standard OPEN or CLOSE control message for this point to the TDMS-Plus control program.

The desired control interval is set by multiplying the point’s Y parameter by the timer multiplier given in the select request and loading the result into the point’s control interval point.

If the point is not controllable (has no control address), then the server simply updates its value in the database, unless the point is manually set. See notes below.

If there is no match, or if the timer multiplier is non-zero but there is no control interval point, the server sends an error reply (error code 3), and does not issue any control or perform any database update. If the select buffer is not empty, it is now cleared.

NOTES:

Control requests for points that are telemetered to TDMS-Plus but have no TDMS-Plus control addresses are meaningless and are therefore denied (the server responds with an error).

If the point is a pure pseudo point (that is, it has no telemetry and no control address), then the server simply sets point to the state specified in the control request. This makes it easy




for operators at other master stations to set flags in the TDMS-Plus master station in a manner similar to performing control operations. Applications include controlling processes implemented in TDMS-Plus via command sequencing.

If a pure pseudo point is manually set, however, the control request cannot be honored and is

therefore denied (the server does not respond).

3.6 REPEAT LAST MESSAGE (FC = 27)

On receipt of this message, the server simply resents the last message transmitted.

3.7 EXCEPTION BYTE

The optional exception byte is used only with error code 3 (“bad message from master”) to indicate that a request has been denied. This can occur in the following cases:

The master sends a continuation request that is not expected (i.e. in the previous response, the server did not indicate that a continuation is required).

An Analog Change Report request has a short header with the continuation bit set, or it has a normal header with the continuation bit clear.

An Analog or Indicator Force Report request does not contain a valid pair of start/stop point addresses (e.g. the start address is greater than the stop address, or the start address is greater than the last point defined in the dataset).

The control information in a SBO Control Operate request does not match that of the preceding SBO Control Select request.

For a SBO Control Select request:

Control of this dataset is not allowed by this master (as specified on the QLINK editor).

There is no corresponding TDMS-Plus control point (i.e. the corresponding entry in the control section of the dataset is empty).

A timer multiplier is specified in the request but the corresponding TDMS-Plus control point does not have an associated control interval point defined.

The specified control point is not actually controllable but it is telemetered.

The specified control point is a pure pseudo point (i.e. neither controllable nor telemetered) but is manually set.



Copyright © 2016 QEI GOULD MODBUS PLC SERVER 12

4 GOULD MODBUS PLC SERVER The QNET server name for the Modbus protocol is MODB.

The Modbus server conforms to the RTU communication mode of the Modbus protocol as defined in the Gould Electronics document Gould Modbus Protocol Reference Guide (Gould Reference number PI-MBUS-300 Rev B).

4.1 MODBUS DATASETS

For the Modbus protocol, the XYZ parameters in the dataset definitions have the following meaning:

X = 0 – Not used

Y = 0 – Not used

Z = Enabled/disabled buffering of status changes (status points only) = Analog data format (analog points only)

For status points, the “Z” code determines whether the server sends all buffered status changes or just the current status:

0 = Send current status

1 = Send all changes

When returning analog data to the “other system” in response to read input and holding register requests, the server uses the “Z” value in the dataset to determine how to convert the engineering value to a 16-bit register value. These “Z” codes are individually assignable to each point in the dataset, and have the following meanings:

0 = Convert engineering value to 16-bit unsigned value, using point’s own scale factor and offset.

1 = Convert engineering value to 16-bit signed value, using point’s own scale factor and offset.

2 = Convert engineering value to 4-digit BCD, no scaling.

4.2 OPERATION

The Modbus server responds to the following requests:

4.2.1 Read Output/Coil Status (FN = 1)

The server returns the status of the points specified in the “control” section of the dataset. This section of the dataset normally contains status points with control, but may also contain pseudo points.

4.2.2 Read Input Status (FN = 2)

The server returns the status of points specified in the “status” section of the dataset. This section of the dataset contains status points.




4.2.3 Read Output/Holding Register (FN = 3)

The server returns the values of points specified in the “accumulator” section of the dataset. This section of the dataset contains analog points.

4.2.4 Read Input Register (FN = 4)

The server returns the values of the points specified in the “analog” section of the dataset. This section of the dataset contains analog points.

4.2.5 Force Single Coil (FN = 5)

If the corresponding point in the “control” section of the dataset is controllable, the server issues a control command to the point. If the point is tagged, the control request is rejected (i.e. the server sends an exception response indication “failure in associated device”).

If the point is a pseudo point (is neither telemetered nor controllable), then the server just updates the point’s value in the database. If it is an alarm point, then an alarm would be raised. This feature allows the “other system” to raise an alarm on the TDMS-Plus system or to control the operation of a TDMS-Plus process written in Command Sequencing. Note that if the point is manually set, the request is rejected.

If the specified control is not defined in the dataset, or if the point is not controllable but is telemetered, then the request is rejected.

4.2.6 Preset Single/Holding Register (FN = 6)

The server stores the value into the corresponding point in the “accumulator” section of the dataset. The 16-bit register value is converted to engineering units using that point’s defined scale factor and offset. Full alarm processing for limit violations apply. Another way to control a Command Sequencing process.

If the corresponding point in the “accumulator” section of the dataset is a setpoint, the server issues a setpoint command. If the point is tagged, the preset request is rejected.

If the point is a pseudo point (is neither telemetered nor a setpoint), then the server just updates the point’s value in the database. Full alarm processing for limit violations apply. Another way to control a Command Sequencing process.

4.3 LOGGING

The purpose to the logging function is to help in trouble-shooting. The server logs requests received and replies sent, both in HEX and in English, in a format illustrated below:

13:48:00.2 MODBSV49 Received: [“%NORMAL”,8] “0C 03 00 00 00 0B 38 D0” RTU: 12 “Read input status” Start: 0 Length: 11 13:48:00.2 MODBSV49 MODBSV49 Sent: [“NORMAL”,7] RTU: 12 ”Read input status” Except: 0 Byte count: 2 0C 02 02 EE 05 19 DA




13:48:00.7 MODBSV49 Received: [“%NORMAL”,8] “0D 01 00 00 00 01 FD 06” RTU: 13 “Read coil” Start: 0 Length: 1 13:48:00:7 MODBSV49 MODBSV49 Sent: [“NORMAL”,6] RTU: 13 “Read coil” Except: 0 Byte Count: 1 0D 01 01 01 93 18

13:48:01.7 MODBSV49 Received: [“%NORMAL”,8] “0B 03 00 06 00 04 A4 A2” RTU: 11 “Read holding register” Start: 6 Length: 4 13:48:01.7 MODBSV49 MODBSV49 Sent: [“NORMAL”,13] RTU: 11 “Read holding register” Except: 0 Byte count: 8 0B 03 08 40 A8 00 00 00 06 00 06 F9 F6 13:48:03.4 MODBSV49 Received: [“%NORMAL”,8] “0A 04 00 7A 00 1E 50 A0” RTU: 10 “Read input register” Start: 122 Length: 30 13:48:03.4 MODBSV49 MODBSV49 Sent: [“NORMAL”,65] RTU: 10 “Read input register” Except: 0 Byte count: 60 0A 04 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8A 86 etc.

The point numbers in the example are point numbers within the dataset.

The logging is enabled by entering the commands as follows:

SCANMON MODBSV01 x y

Where “x” is the RTU number (0 = all RTUs) and “y” is a command code:

1 = enable logging in HEX only 2 = enable logging in English only] 3 = enable logging in HEX and English 0 = disable logging



Copyright © 2016 QEI GTAC SERVER 15

5 GTAC SERVER The GTAC protocol server emulates a Honeywell HS 7024 RTU. The protocol name that should be entered in the QLINK editor for this server is GTAC.

The GTAC server supports the following requests from another master station:

Alarm Scan (ASCN)

Request for digital status information if an unreported change has occurred.

Station Check (SCHK)

Request for all digital status information whether previously reported or not.

Continuous Data Point Scan (CSCN)

Request for all data from the Analog section of a dataset.

Full Data Point Scan (FSCN)

Request for all data from the Analog and Accumulator sections (in this order) of a dataset

Acknowledge (ACKN)

The other master station acknowledges reception of the response to the previous request.

Control Point Select (CSEL)

Request to select the specified output control point or setpoint, or update point (i.e. a point from the Control section of a dataset)

The server returns a checkback message for confirmation that the correct point was selected.

Trip or Open the Selected Digital Output Control Point (TRIP)

Request to perform the open control for the selected point.

Close the Selected Digital Output Control Point (CLOSE)

Request to perform the Close control for the selected point.

Set Point (STPT)

Request to perform a setpoint control.

Specifies the new analog value to be applied to the setpoint output selected by a CSEL request.




Reset All Points (RAPT)

Request to de-select any control points selected by the previous CSEL request

No reply is needed.

The GTAC server does NOT support the following functions (for these requests, the server does not send a reply):

Select Continuous Data Point Scan (SCNC)

Request for data from selected continuous data points.

Selected Non-Continuous Data Point Scan (SCNS)

Request for data from selected non-continuous data points.

Selected Indication Point Status Scan (SCNI)

Request for status point information from selected indication points.

Store Counter Data (STRE)

Request to transfer all current accumulator values to the holding register for subsequent transmission to the higher-level master station.

Reset Counters (RSET)

Request to reset all counter values to zero.

5.1 GTAC DATASETS

The Status section of a GTAC dataset contains status points.

The Analog section of a GTAC dataset contains the Continuous Data points (both analogs and accumulators). A continuous data analog point is identified in the dataset by setting the “Z” field to 0 on HSLIST. A continuous data accumulator point is identified by setting the “Z” field to 1. In the present implementation of the GTAC server, accumulators are not supported.

The Accumulator section of a GTAC dataset contains the Non-Continuous Data points (both analogs and accumulators). The non-continuous analog points and non-continuous accumulator points are identified via their “Z” codes as described above for the Continuous Data points. As above, however, the present implementation of the GTAC server does not support accumulators.

The Control section of a GTAC dataset contains three types of controls:

(a) Digital control points for TRIP/CLOSE operations

- These points are identified by a “Z” code of 0.

(b) Analog output points for setpoint operations.





(c) Update points


- These are non-control points that are updated from the higher-level master station via control requests. This is how the other master station sends data back to TDMS-Plus.

- The other master station normally updates the update points once a minute. If the GTAC server does not receive an update for any of the update points within a minute, then it marks all the update points in that dataset “telemetry failed”.

5.2 ANALOG/ACCUMULATOR DATA FORMAT

The present implementation of the GTAC server provides only the 2’s complement binary format for both analog and accumulator points.

5.3 BUFFERING OF STATUS CHANGES

The GTAC server buffers up to 7 status changes for each status point. If, for example, a point changes state three times between polls from the other master station, the GTAC server will send a status change in response to each of the next three polls.

5.4 CONTROL OPERATIONS

5.4.1 Control Point Select (CSEL)

A control Point Select (CSEL) request is issued by the other master station to select a control point.

In response to this request, the GTAC server verifies that the specified point exists in the dataset, and if it does exist, it sends a check back reply to the requester.

Any subsequent CSEL request cancels the previous one. If no operate (TRIP/CLOSE or SETPOINT) request is received within 20 seconds after a CSEL request, the GTAC server cancels the selection.

5.4.2 Control Point Trip/Close

A Trip/Close Selected Digital Output (TRIP, CLOSE) request is issued by the other master station to perform the Open/Close control for a point selected by a previous CSEL request.

The GTAC server responds by first verifying that:

A successful CSEL request had been issued (and not cancelled yet).

The point specified in the Trip/Close request is the same as the one selected.

The selected point is either controllable or a pure pseudo point (i.e. if it is not controllable, then it is not telemetered either)




If there is not error, the server then proceeds as follows:

If the point is a pure pseudo point and is not manually set, the server writes the new value into the database. Normal alarm processing applies.

If the point is controllable, and is neither manually set nor tagged, the server executes the requested control operation.

Regardless of the outcome, the previously selected point becomes de-selected.

Updating of pure pseudo points by the other master station via control operations is useful for allowing the other master station to start and control TDMS-Plus processes (e.g. command sequence programs) or to provide inputs for calculations.

5.4.3 Set Point Control

A Setpoint (STPT) request is issued by the other master station to perform a setpoint control for a point previously selected via a CSEL request.

The GTAC server responds by first verifying that:

A successful CSEL request had been issued (and not cancelled yet).

The selected point is either controllable (i.e. a setpoint) or a pseudo point (i.e. not telemetered)

If there is no error, the server acts as follows:

If the point is a pseudo point and is not manually set, the server writes the new value into database. Normal alarm processing (for limit violations) applies.

If the point is a setpoint and is not tagged, the server executes the requested control operation.

Regardless of the outcome, the previously selected point becomes de-selected.



Copyright © 2016 QEI VALMET CIU SERVER 19

6 VALMET CIU SERVER The VCIU Qnet server implements a Valmet CIU message protocol used in the links between a generation & transmission master station and its various electric member co-operatives (EMCs). The protocol name that should be entered in the QLINK Editor for this server is VCIU.

The VCIU server runs on the EMCs and used only one dataset. The dataset assignment is made via a virtual RTU on the QLINK editor. The RTU number of this virtual RTU should be chosen to match the EMC station address.

In this implementation, the server responds to most of the defined function codes, including the ones related to the transmission of text messages. The functions supported are indicated by an X in the [ ] column of the table below:

Function Code Description

[ ] 1 Read 30-second data

[X] 2 Read 2-minute data

[ ] 3 Read 4-minute data

[X] 4 Read hourly data

[X] 5 Read non-periodic data (test messages)

[X] 6 Send 60-second data

[X] 7 Send hourly data

[X] 8 Send monthly data

[X] 9 Send percent load shed

[X] 10 Send scram command (arm)

[X] 11 Execute scram request

[X] 12 Send non-periodic data (text messages)

[X] 13 Acknowledge non-periodic data

[X] 14 Read 2-minute data (ASCII)

[X] 15 Read 2-minute data (BCD)

[ ] 16 Send 10 values

6.1 VCIU DATASETS

For each function code, the VCIU server maps input/output values to pre-allocated point numbers in its assigned dataset. Only the ANALOG and STATUS sections of the dataset are used.

The first and third points in the ANALOG section of the dataset have special purposes:

Point #0 defines the current load management mode. The server uses this to set the “S” flag in the 16-bit status word. See section 6.4.

Point #1 is not used.

Point #2 defines the number of the command sequence to automatically activate when a scram command is received from the other system. A value of zero corresponds to local mode. See paragraph 6.3.11.




The input/output points in the ANALOG section of the dataset start at point #10.

The second and third points in the STATUS section of the dataset also have special purposes:

Point #0 is not used.

Point #1 specifies the alarm point that the server sets on receipt of a load reduction command while load reduction is in local mode. See section 6.3.9.

Point #2 specifies the alarm point that the server sets on receipt of a scram command while scram is in local mode. See section 6.3.11.

There are presently no input/output points in the STATUS section of the dataset.

For the VCIU server, the meaning of the XYZ parameters for the input/output points are given below:

X = Quality code required flag.

0 = No quality code to be sent. 1 = Quality code to be sent.

Y = Number of digits (if Z corresponds to BCD or ASCII)

Z = Transmitted format

0 = DEC floating point 1 = IEEE floating point (not implemented) 2 = 16-bit signed integer 3 = 16-bit unsigned integer 4 = 32-bit integer 5 = BCD 6 = ASCII 7 = 8-bit signed integer 8 = 8-bit unsigned integer

The server transmits a quality code byte whenever the X parameter specifies that it is required. There are two bits in the quality code byte:

ME – Manually entered. - Set if the TDMS-Plus point is manually set (M). BAD – Bad data. - Set if the TDMS-Plus point is telemetry failed (F) or over range (V).

6.2 TEXT MESSAGES

The operator at the EMC can sent a multi-line message to the other system by using the Message item from the Applications menu of the Session Manager. Where supported by the link software, the operator can direct the message to any of the following destinations on the other system.

A specific Operator Workstation

A specific event printer

Alarm

When the operator selects the Message item, a Qnet message dialog box is displayed containing the following data entry areas:

Destination

This is the name of the system (client) to which the message is to be sent.




Facility

This is a set of pushbuttons that are used to select the type of facility, on the system named above, to which the message is to be sent:

- WORKSTATION To send a message to an operator workstation.

- LOGGER To send a message by printing on an event logger.

- ALARM To send a message by raising an alarm.

In the case of LOGGER, there is a data entry field that accepts the desired logger number. In the case of ALARM, there is a data entry field that accepts the desired alarm priority.

Message

This is the text of the message to be sent. This field contains five lines of 80 characters each.

When the operator clicks on the Send pushbutton in the Qnet Message dialog box, the message program looks up the destination system name in QLINK to obtain the name of the server-handling link to that system. The program then sends the request, containing the contents of the message box, to the appropriate server, who forwards the request to the other system.

In the case of the Valmet CIU message protocol, only the text of the message is passed on to the other system. The protocol does not contain a detailed specification of the destination.

6.3 FUNCTIONS

For each function that involves reading or writing a point, the server accesses the point from the pre-allocation position in the dataset and packs or unpacks the value according to the specification contained in the point’s XYZ parameters. This means that for each data field in each type of message, the corresponding database point must be specified at the correct location in the dataset, with the correct XYZ parameters. The required dataset locations and XYZ parameters are summarized below.

6.3.1 Function 1 – Read 30-Second Data

This function is not implemented. If this request is received, the server will not reply.

If implemented in the future, the server would return values of 64 status points specified in the STATUS section of the dataset, starting at point #10.

6.3.2 Function 2 – Read 2-Minute Data

The data values returned to the other master station consist of the following points in the ANALOG section of the dataset:

Dataset Format Point # X:Y:Z Description 10 1:0:0 kw demand 11 1:0:0 kvar demand 12 1:0:4 percentage of load reduction




6.3.3 Function 3 – Read 4-Minute Data


For purposes of future implementation, space in the ANALOG section of the dataset has been reserved to specify point values to be sent, as follows:

Dataset Format Point # X:Y:Z Description 13 1:0:0 weather analog value 1 14 1:0:0 weather analog value 2 15 1:0:0 weather analog value 3

6.3.4 Function 4 – Read Hourly Data

The three data values returned to the other master station are selected from the following points in the ANALOG section of the dataset:

Dataset Format Point # X:Y:Z Description

63 1:0:0 kw demand, system-wide 64 1:0:0 kvar demand, system-wide 65 1:0:0 hourly power factor, system-wide

66 1:0:0 kw demand, substation #1

67 1:0:0 kvar demand, substation #1 68 1:0:0 hourly power factor, substation #1

69 1:0:0 kw demand, substation #2 70 1:0:0 kvar demand, substation #2 71 1:0:0 hourly power factor, substation #2 . . . . . .

183 1:0:0 kw demand, Substation #40 184 1:0:0 kvar demand, substation #40 185 1:0:0 hourly power factor, substation #40

The three values returned depend on the substation specified in the request. Substation #0 corresponds to system-wide.

6.3.5 Function 5 – Read Non-Periodic Data (Text Messages)

When the VCIU server receives a message request from the operator, it stores the message in an output message buffer. It then informs the other system that there is a message by setting the “general information message pending” bit in the status word. The other system will then ask for the message, one line at a time, using function 5.




On the last line, the server sets the msb of the line number, whereupon the other system acknowledges the message via function 13 (see 6.3.13).

6.3.6 Function 6 – Send 60-Second Data

The data values return to the other master station consist of the following points in the ANALOG section of the dataset:


16 1:10:6 Oglethorpe kw demand (ascii) 17 1:10:6 Georgia territorial kw demand (ascii) 18 1:0:0 Oglethorpe kw demand (float)

19 1:0:0 Georgia territorial kw demand (float)

6.3.7 Function 7 – Send Hourly Data

The data values received from the other master station are stored in the following points of the ANALOG section of dataset:


20 0:2:5 Current day 21 0:2:5 Current month 22 0:2:5 Current year

23 0:2:5 Current hour 24 0:2:5 Current minute

25 0:2:5 Current second 26 0:2:5 Current 100th of a second Any points that are manually set will not be updated.

6.3.8 Function 8 – Send Monthly Data



27 0:0:8 Month of peak hourly demand 28 0:0:8 Day of peak hourly demand 29 0:0:8 Hour of peak hourly demand

30 1:0:0 System kw demand at peak 31 1:0:0 Member kw demand at peak

Any points that are manually set will not be updated.

6.3.9 Function 9 – Send Percent Load Shed


Dataset Format




Point # X:Y:Z Description

32 0:4:5 percent load shed (BCD) Any points that are manually set will not be updated.

The data value returned to the other master station consists of the following point of the ANALOG section of dataset:


33 0:0:3 percent KW The server then checks the current load management mode defined by point #0 in the ANALOG section of the dataset. If there is no point, or if the point’s value is other than 3 or 4, then load reduction is considered to be in Local mode. In this case, the server notifies the operator by setting the alarm point specified as point #1 in the STATUS section of the dataset to “1”. Later, when the operator acknowledges the alarm, the server will reset the alarm point to “0” and acknowledge the other master station by setting the LAK bit.

If the load management mode is 3 or 4 (Remote mode), then the server automatically acknowledges the other master station by setting the LAK bit in the reply to the very next request.

6.3.10 Function 10 – Send Scram Command (Arm)

On receipt of this function, the server sets a flag to indicate that the scram function is armed. The scram command is actually completed via function 11.

If the next function is not 11, or there are no further requests at all for 15 seconds, the scram is disarmed.

6.3.11 Function 11 – Execute Scram Request

On receipt of this function, the server obtains the number of a command sequence from the value of point #2 in the ANALOG section of the dataset. If there is no point, or if the point’s value is zero, then scram is considered to be in Local mode. In this case, the server notifies the operator by setting the alarm point specified is as point #2 in the STATUS second of the dataset to “1”. Later, when the operator acknowledges the alarm, the server will reset the alarm point to “0” and acknowledge the other master station by setting the SAK bit.

If the command sequence number is a positive integer, then that command sequence is triggered, and the server automatically acknowledges the other master station by setting the SAK bit in the reply to the very next request.

The command sequence would typically be programmed to set the scram points of all (or just some subset) of the load management control sets.

By manually setting the value of point #2 in the ANALOG section of the dataset, the EMC operator can switch between different scram command sequence programs, or set scram to manual mode by entering a value of zero.




6.3.12 Function 12 – Send Non-Periodic Data (Text Messages)

On receipt of this function, the server stores the received line of text into an input message buffer.

When the last line is received (msb of line number is set), the server outputs the buffered text by raising a series of priority 3 alarms. First, it outputs an alarm identified the source of the message:

mm/dd hh:mm:ss MESSAGE FROM xxxxxx

Where “xxxxxx” is the name of the other system (client). Then, it outputs as many alarms as required to contain the message, each alarm containing 60 characters of text.

To confirm reception of the message, the server sets the “G I Message Ack” bit in the returned status word after the last line is received.

6.3.13 Function 13 – Acknowledge Non-Periodic Data

When the server receives this function, it clears the output message buffer and stops sending the “general information message pending” bit in the status word.

6.3.14 Function 14 – Read 2-Minute Data (ASCII)



34 0:6:6 2-minute kw demand (ascii) 35 0:6:6 2-minute kvar demand (ascii)

6.3.15 Function 15 – Read 2-minute Data (ASCII)



36 0:2:5 kw demand (BCD) 37 0:2:5 kvar demand (BCD

38 0:2:5 percent load reduction (BCD)

6.3.16 Function 16 – Send 10 values





6.4 STATUS WORD

The 16-bit status word returned by the server on every request (except function 16) is formatted as follows:

Name Description

CF SCADA system configuration - Server always return 0 LMS Load Module system configuration - Server always returns 10 E CIU/EMC communications error - Server always returns 0 S EMC System local mode flag (load management mode) - Based on value of point #0 in the analog section of the dataset - Server returns 0 (for remote) if point #0 has a value of 3 or 4:

otherwise returns 1 (for local)

GIM General information pending - Set in every response while operator message is pending (see

6.3.5), cleared when message is acknowledged (see 6.3.13)

L Local/remote CIU status bit - Server always returns 0 LAK Load Management Ack - See section 6.3.9 SAK Scram Ack - See Section 6.3.11 GAK G I Message Ack

- Set in next response after last line of message is received (see 6.3.12), then cleared in next response after that.

PFD CIU message printer buffer - Server always returns 0 IVD Invalid data bit - Server always returns 0 P Power up bit from CIU, EMC - Set in first response after server startup COS Change of state bit - Server always returns 0 RE Relay error - Server always returns 0



Copyright © 2016 QEI DNP SERVER 27

7 DNP SERVER

The QNET server name for the DNP protocol is DNPS. The DNP Device Profile Document (Appendix A) describes the level of implementation in detail.

7.1 DNP DATASETS

For the DNP protocol, the ABCD and XYZ parameters in the dataset definitions have the following meaning: A: Not used.

B: Not used.

C: Not used. D: Binary Input Mode (Status section only)

0: Single Bit - Status point will be represented as a Single-Bit Binary Input (Object 1)

1: Double Bit - Status point will be represented as a Double-Bit Binary Input (Object

3)

The QEI to DNP mapping for Double-Bit status points is as follows:

QEI DNP DNP Encoding

0 OFF 01

1 ON 10

2 INTERMEDIATE 00

3 INDETERMINATE 11

X: Control Checkback Mode (Control section only)

0: End-To-End Control Checkback - The DNP server will wait for a checkback

response from the controlled remote device before returning a checkback response to the DNP client.

1: Local Control Checkback – The DNP server will immediately return checkback

success to the DNP client upon receipt of a control. (This mode is typically only of use when the controlled remote device can only be reached via dialup modem – waiting for the dialup link to be established introduces a long delay which may cause the DNP client to timeout)

Y: DNP Object Variation

0: Default Variation – Point is represented as the default object variation (see table

below) n: User-defined Variation – Point is represented as variation n Default object variations are listed below:

Obj Def. Var Description

1 2 Binary Input With Status

2 2 Binary Input Change With Time

3 2 Double-Bit Input With Flag

4 2 Double-Bit Input Change Event With Absolute Time




10 2 Binary Output With Status

11 2 Binary Output Change With Time

20 1 32-Bit Binary Counter

22 1 32-Bit Counter Change Event Without Time

30 1 32-Bit Analog Input

32 1 32-Bit Analog Change Event Without Time

40 2 16-Bit Analog Output Status

42 2 16-Bit Analog Output Change Event Without Time Example: The default Analog Input (Object 30) variation is 1 (32-Bit Analog Input). To force the point to be represented as variation 5 (Short Floating Point Analog Input), enter a “5” in the point’s Y-field.

Z: Analog Scaling Mode (Analog and Control sections)

0: Engineering – The engineering value of the analog point is returned in the DNP object.

1: Raw – The raw value of the analog point is returned in the DNP object. (The

engineering value is converted back to raw by subtracting the offset and then dividing by the scale factor.)

7.2 OPERATION

Unsolicited Responses

Unsolicited Responses will only be sent once a valid Enable Unsolicited Responses message has been received (with the exception of a single empty Unsolicited Response, which is sent on server startup). The default DNP address to which Unsolicited Responses will be sent is 1024. The Client Name field on the Client Mapping Editor (QLINK) can be used to specify a different destination address for Unsolicited Responses.

Controls and Setpoints

Controls and setpoints will only be accepted if the Virtual RTU’s C-flag is set on the Client Mapping Editor (QLINK). (The M-flag is not used at all by the DNP Server.)

Both Controls and Setpoints should be listed in the Control section of the Virtual RTU editor. The Select-Before-Operate (SBO) Arm Timer is hard-coded to 5 seconds i.e. a valid operate request must be received within a 5 second window after the receipt of a valid select request – if not, the operate request will be rejected.

The mapping from DNP to QEI controls is explained below.

If the Control Relay Output Block request specifies a Trip or Close, the following mapping is always used, regardless of the specified operation:

DNP Trip => QEI 0-Control DNP Close => QEI 1-Control If a Trip or Close is not specified in the Control Relay Output Block request, the following mapping is used:

DNP Pulse OFF or Latch OFF => QEI 0-Control




DNP Pulse ON or Latch ON => QEI 1-Control

Event Classes

Event Objects class assignments are as follows:

Binary Object Events: Class 1 Analog Object Events: Class 2 Counter Object Events: Class 3 TCP/IP Communications

The DNP QNET Server uses the existing Scan Task IP Redirector for TCP/IP communications. To configure a QNET DNP Server for TCP/IP communications, add an entry to the IP Network Interface Mapping Table Editor (IPNMAP), specifying the IP address and DNP address of the DNP Master e.g.

COMMLINE RTU ADDRESS IP ADDRESS TRANSPORT PROTOCOL

60 1024 192.168.20.144 TCP DNP

Then specify the IPNnn device in the Communication Port field of the Client Mapping Editor (QLINK), where nn is the commline number specified in the IPNMAP entry e.g.

COMMUNICATION PORT> IPN60

Time and Date Objects

Even though the DNP QNET Server will accept a write to the Time and Date object (Object 50), the OpenVMS system time will not actually be updated. Short Floating Point Support

The DNP QNET Server supports reads and writes for short floating point object variations, which means that analog engineering values can be transported without loss of precision. Health Bits (flag byte)

Online (Bit 0) is always set to 1 If the point is manually set, the REMOTE_FORCED (bit 3) and the LOCAL_FORCED (bit 4) are both set to 1. Otherwise it is a 0. If the point has telemetry failure, the COMM_LOST bit (bit 2) is set to 1. Otherwise it is a 0. UTC vs. local time

To use UTC time, set CRITICAL RESPONSE TIME on the QLINK record to 1. To use local time, set CRITICAL RESPONSE TIME on the QLINK record to 0.

7.3 SCANMON LOGGING

Scanmon logging is enabled or disabled using the following command:

SCANMON DNPSMXnn x y

where nn is the QLINK record number, x is the Virtual RTU number (0 = all Virtual RTUs) and y is the command code: 0 = disable logging 3 = enable logging




7.4 DNP SECURITY CONFIGURATION

7.4.1 INTRODUCTION This section describes the requirements for setting up DNP in a V2 secure environment. The user can customize the optional settings for DNP V2 Secure Authentication. These settings include the Update key, Expected Key change interval, Expected Key change count, and Maximum security error count.

The configurable parameters are described below:

Update Key The outstation uses the Update Key to decrypt new Session Keys. The Update Key must match on both the master and outstation. The Update Key is 16 bytes. Both the Session Keys and the Update Key are symmetric keys.

Expected Key Change Interval

Expected Key Change Count The outstation shall maintain a timer and a count between successive Key Change messages in the same manner as the master. The outstation shall invalidate the current set of Session Keys if they have not been changed within the configured interval. This rule will cause the Session Keys to become invalid whenever either the master or outstation times out, whichever happens sooner. To avoid excessive message exchanges it is recommended that the outstation interval and count be configured for twice the interval and count configured at the master.

Maximum Security Error Count To help protect against denial-of-service attacks, a device shall stop transmitting Error messages after it has counted a number of errors that exceeds a preset Maximum Security Error Count. The maximum error count shall be configurable up to a maximum of 10 errors or down to 0. The default shall be 2.

7.4.2 SECURITY CONFIGURATION A configuration utility can be used to customize the security configuration for a given DNP server. The utility is available by running the DNP security configuration utility:

$ DNPCONFIG

The utility requires the user to enter the SCADA administrator password to continue:

Enter Administrator Password >>>

Enter the SCADA administrator password to continue to the main menu.

DNP Security Configuration

1) DNP Scantask (Client) 2) DNP QNET (Server) 3) Exit Select Option: 2

Choose menu option 2 to configure a DNP server. The utility will prompt for the server number:

Enter QNET Server #:

Enter the DNP server # to continue.

An example for DNP server #0 is shown below:

Enter QNET Server #: 0

DNPSSV00 Server Configuration

1) View Configuration 2) Create Default Configuration 3) Modify Configuration 4) Return to Main Menu




Select Option:

After entering the DNP server #, the main server configuration menu is displayed:

DNPSSVxx Server Configuration

1) View Configuration 2) Create Default Configuration 3) Modify Configuration 4) Return to Main Menu Select Option:

The user can View the current configuration, Create a default configuration, or Modify the configuration. The options are described below:

1. View Configuration Use this option to view the current configuration stored in the security file. If no configuration exists, the utility will display an error message.

Select Option: 1 Update Key: 26 66 A2 39 2A 5A 77 6F 8C 58 16 C3 43 BD 31 6E Key Change Interval: 900000 Max Key Change Count: 1000 Max Error Count: 2 Press any key to continue...

2. Create Default Configuration

Use this option to create a configuration with the default parameters. If an existing configuration exists, the utility will prompt the user whether to overwrite the configuration.

Select Option: 2 !!! Configuration File Will Be Overwritten !!! Do you wish to continue (Y/N)? Y Default Configuration Created Successfully!! Press any key to continue... The default parameters are set as follows: Update Key: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA Key Change Interval: 900000 Max Key Change Count: 1000 Max Error Count: 2

3. Modify Configuration

Use this option to modify an existing configuration. If no configuration exists, the utility will display an error message.

DNPSSVxx Server Configuration Modification

1) Generate Random Update Key 2) Enter New Update Key 3) Change Expected Key Change Interval 4) Change Expected Key Change Count 5) Change Max Error Count 6) View Configuration 7) Save Changes 8) Return to Previous Menu Select Option:




The user can generate a new Update Key (random), enter a new Update Key, modify the Expected Key Change Interval, modify the Expected Key Change Count, modify the Maximum Security Error Count, View the Configuration, Save Changes, or Return to the Previous Menu.

The option to generate a Random Update Key will create a random 16 byte hexadecimal key and display it:

Select Option: 1 New Update Key Generated: 2F 78 BB EA FE 84 61 26 CE 9A A3 37 CD 2C 6B DA Press any key to continue...

The option to enter a new Update Key requires the user to enter an Update Key as 16 hexadecimal entries separated by commas:

Select Option: 2 Enter New Key Update Key (16 Hex Bytes Separated by Commas) : 26,66,A2,39,2A,5A,77,6F,8C,58,16,C3,43,BD,31,6E New Update Key Accepted: 26 66 A2 39 2A 5A 77 6F 8C 58 16 C3 43 BD 31 6E Press any key to continue...

If the new Update Key is invalid, the utility will display an error and the Update Key will not be accepted:

Select Option: 2 Enter New Key Update Key (16 Hex Bytes Separated by Commas) : abc,def,ghi,jkl *** Invalid Entry -- Must be 16 Hex Bytes Separated by Commas *** Press any key to continue...

Please Note that modifying the Security Configuration will require a restart of DNP QNET Server

for the changes to take effect.



Copyright © 2016 QEI GENISYS SERVER 33

8 GENISYS SERVER

The QNET server name for the GENISYS protocol is GENI. The GENISYS server is designed to operate as a GENISYS slave device. The slave address(es) for this server should be entered in the QLINK editor under the RTU column. The VRTU column will be the HSLIST record number for the corresponding slave address. The GENISYS server supports the following GENISYS opcodes (sent from the GENISYS master):

Opcode Definition

GEN_COMMON_CONTROL (0XF9)

This command will be sent to deliver the same data to all slave devices on the communication channel at the same time.

GEN_ACK_POLL (0xFA)

This command will be sent to the slave to acknowledge receipt of indication points and to request any new data.

GEN_POLL (0xFB)

A normal poll command, sent by the master to request any changes in status input values.

GEN_CONTROL_DATA (0xFC)

This opcode is used to update the state of Digital Output points in the GENISYS slave device. This opcode is sent whenever a control point value is changed in the master. This opcode will result in a status point update in the TDMS master.

GEN_RECALL (0xFD)

This opcode is the equivalent of an "All-data-poll". It is sent by the master when communications are established, and at periodic intervals thereafter, to insure that the master’s database is current.

GEN_CONTROL_EXECUTE (0XFE)

This command will be sent to cause execution of previously delivered control data.

The GENISYS server responds with the following GENISYS opcodes (sent to the GENISYS master):

Opcode Definition

GEN_RACK (0xF1)

A general-purpose acknowledgement, sent when no indication changes are un-reported.

GEN_RIND (0xF2)

Used to deliver new or all data to the master in response to an ACK, POLL, CONTROL_DATA, RECALL, or CONTROL_EXECUTE messages.

GEN_ESC (0xF0)

This value is used to encode any data value in a message that has a value of 0xF0-0xFF. This is done in order that data is not confused with opcodes. Any value in the above range is sent as 0xF0, followed by the least-significant nibble of the data. The expansion is done after CRC calculation, and the re-compression is done before the CRC calculation. The ESC sequence will be sent by either the master or slave device whenever it is required.

The GENISYS server always operates in secure mode which requires a two CRC-16 checksum in front of the termination character (0xF6) (on all messages except the GEN_RACK). The status data sent to the GENISYS master is packed eight indications per data byte. For changed data, all eight bits are sent when any status point value changes. Any unused bits are sent as 0. The control data received from the GENISYS master is unpacked eight indications per data byte. All eight status points are written when a control byte is received. Any unused bits are ignored.

8.1 GENISYS DATASETS For the GENISYS protocol, only the STATUS and CONTROL sections of the HSTLIST editor are used. The protocol does not support ANALOG or ACCUMULATOR points.




The ABCD and XYZ parameters in the dataset definitions are not used for either the STATUS or CONTROL sections. The user should only enter the desired TDMS point name in the HSLIST editor.

8.2 OPERATION

Controls

Controls are implemented in the GENISYS server as writes to TDMS status points.

The status point to accept the control (for the point write) should be entered into the HSLIST editor for the appropriate point slot.

TCP/IP Communications

The GENISYS QNET Server can use the existing Scan Task IP Redirector for TCP/IP communications. To configure a QNET GENISYS Server for TCP/IP communications, add an entry to the IP Network Interface Mapping Table Editor (IPNMAP), specifying the IP address and device number of the GENISYS Server e.g.

DEV # RTU ADDRESS IP ADDRESS TRANSPORT PROTOCOL

60 0 192.168.20.144 TCP 3001

Then specify the IPNnn device in the Communication Port field of the Client Mapping Editor (QLINK), where nn is the device number specified in the IPNMAP entry e.g.

COMMUNICATION PORT> IPN60

8.3 SCANMON LOGGING

Scanmon logging is enabled or disabled using the following command:

SCANMON GENIMXnn x y

where nn is the QLINK record number, x is the Virtual RTU number (0 = all Virtual RTUs) and y is the command code: 0 = disable logging 1 = enable logging 3 = enable logging with Hex

An example is given below:

10:03:34.4 GENISV00 Received: ["%NORMAL",5] HEX: <-51 C1 02 FD <-XX XX XX F6 Slave=2. F/C=13 (Recall) GENISV00 Sent: ["NORMAL",9] HEX: <-FE 00 02 F2 <-76 8D 0E 01 <-XX XX XX F6 Slave=2. F/C=2 (Indication) Status 001: 0 Status 002: 1 Status 003: 1




Status 004: 1 Status 005: 1 Status 006: 1 Status 007: 1 Status 008: 1 Status 009: 0 Status 010: 1 Status 011: 1 Status 012: 1 Status 013: 0 Status 014: 0 Status 015: 0 Status 016: 0 10:03:34.7 GENISV00 Received: ["%NORMAL",11] HEX: <-00 00 02 FC <-01 E0 00 01 <-XX F6 2D A5 Slave=2. F/C=12 (Control Data) GENISV00 Sent: ["NORMAL",3] HEX: <-XX F6 02 F1 Slave=2. F/C=1 (Acknowledge) 10:03:34.9 GENISV00 Received: ["%NORMAL",14] HEX: <-00 00 02 FB <-01 E0 00 01 <-9A F6 2D A5 <-XX XX F6 32 Slave=2. F/C=11 (Poll) GENISV00 Sent: ["NORMAL",3] HEX: <-XX F6 02 F1 Slave=2. F/C=1 (Acknowledge) 10:53:53.5 GENISV00 Received: ["%NORMAL",5] HEX: <-F1 C2 02 FB <-XX XX XX F6 Slave=2. F/C=11 (Poll) GENISV00 Sent: ["NORMAL",7] HEX: <-FC 00 02 F2 <-XX F6 39 93 Slave=2. F/C=2 (Indication) Status 001: 0 Status 002: 0 Status 003: 1 Status 004: 1 Status 005: 1 Status 006: 1 Status 007: 1 Status 008: 1

8.4 GENISYS COMMUNICATION PROTOCOL

8.4.1 General Message Format

The GENISYS protocol is a binary, byte oriented, serial, polling protocol in which all messages are framed by unique header/control and terminator bytes. It is normally transmitted and received by asynchronous serial communication controllers configured to process 8 bit characters with one start bit and one stop bit.




A typical GENISYS message is composed of a header/control character, a station address, data bytes (optional), two checksum bytes, and a terminator byte as shown in figure 5-1. Note that in the following paragraphs character (byte) values preceded by "$" are hexadecimal values.

8.4.1.1 Control Character

There are 13 possible header/control characters (bytes) in the GENISYS protocol ($F1 - $FE). Character $F0 is reserved for use as an "escape" character, $F6 is reserved for use as a message terminator, and $FF is not used. The basic GENISYS protocol defines 9 of the 23 available headers. Headers $F1 - $F3 are assigned to slave to master message while headers $F9 - $FE are assigned to master to slave messages. It is possible for characters to appear in the data field which have bit patterns identical to the header/control and terminator characters. In order to preserve the uniqueness of the control and terminator characters, data bytes having values between $F0 $FF are sent as 2 byte sequences. The first byte in the sequence is always $F0 and the second byte in the sequence is (<byte value> - $F0). Whenever the character $F0 is received, it is always arithmetically added to the character which immediately follows to form the original data byte.

8.4.1.2 Station Address

In master to slave messages the station address is the address of the slave to which the message is sent. In slave to master messages the station address is the address of the slave sending the message. As there is only one master on any GENISYS protocol communication channel, and all messages are sent either to or from the master, the master requires no address. Valid station addresses are $01 to $$FF (1 to 255). The common mode message, transmitted from master to slave, may use $00 as a broadcast address.

8.4.1.3 Data Bytes

All data bytes are sent as a two byte pair. The first byte of the pair is a byte address while the second byte is the actual data. Theoretically, the range of valid data byte addresses is $00 to $DF (0 to 223 decimal). GENISYS 2000, however, normally only accepts byte addresses between $00 and $1F (and 31 decimal). Serial data bits 1 - 8 are packaged in the first byte, 9 - 16 in the second, etc. The lowest numbered bit in a data byte is the least significant bit.

8.4.1.4 Security Checksum

All GENISYS messages except the slave to master acknowledge message and the master to slave non-secure poll message include a two-byte CRC-16 checksum. The standard CRC-16 generator polynomial X(16) + X(15) + X(2) + 1 is used. This checksum is calculated before any escape characters are inserted and includes all characters in the message except the message terminator.

Copyright © 2016 QEI Appendix A – DNP Device Profile Document 37

TDMS-Plus Master Station Software

QN-901 Q-NET RTU Protocol Servers

9 Appendix A – DNP Device Profile Document

DNP3 Device Profile Based on DNP XML Schema version 2.08.00

Document Name: TDMSPlusSlaveDNPDeviceProfile

Document Description: TDMS-Plus DNP QNET Server Device Profile

Revision History

Date Time Version Reason for change Edited by

2014-09-03 3 TDMS-Plus DNP QNET Server Device Profile QEI

REFERENCE DEVICE:

1 Device Properties This document is intended to be used for several purposes, including:

- Identifying the capabilities of a DNP3 device (Master Station or Outstation)




- Recording the settings of a specific instance of a device (parameter settings for a specific instance of the device in the user's total DNP3 estate)

- Matching user requirements to product capabilities when procuring a DNP3 device

The document is therefore structured to show, for each technical feature, the capabilities of the device (or capabilities required by the device when procuring).

It is also structured to show the current value (or setting) of each of the parameters that describe a specific instance of the device. This "current value" may also show a

functional limitation of the device. For example when implementing secure authentication it is not required that all DNP3 devices accept aggressive mode requests during

critical exchanges (see Device Profile 1.12.4), in which case a vendor would mark this current value as "No - does not accept aggressive mode requests".

Additionally, the current value may sometimes be used to show a value that a device can achieve because of hardware or software dependencies. An example of this is in

section 1.6.8 of the Device Profile (Maximum error in the time that the Master issues freeze requests) where the value may well depend upon tolerances of hardware

components and interactions between software tasks. When the Device Profile current value is used in this way the corresponding entry in the capabilities column is

grayed-out. Users should note that if an entry in the capabilities column of the Device Profile is grayed-out then there may be information in the current value column that

is pertinent to the device's capabilities.

Unless otherwise noted, multiple boxes in the second column below are selected for each parameter to indicate all capabilities supported or required. Parameters without

checkboxes in the second column do not have capabilities and are included so that the current value may be shown in the third column.

The items listed in the capabilities column below may be configurable to any of the options selected, or set to a fixed value when the device was designed. Item 1.1.10

contains a list of abbreviations for the possible ways in which the configurable parameters may be set. Since some parameters may not be accessible by each of these

methods supported, an abbreviation for the configuration method supported by each parameter is shown in the fourth column of the tables below.

If this document is used to show the current values, the third column should be filled in even if a fixed parameter is selected in the capabilities section ("NA" may be

entered for parameters that are Not Applicable).

If the document is used to show the current values of parameters, then column 3 applies to a single connection between a master and an outstation.

1.1 DEVICE IDENTIFICATION Capabilities Current Value

If

configurable

list methods

1.1.1 Device Function:

Masters send DNP requests, while Outstations send DNP

responses. If a single physical device can perform both

functions a separate Device Profile Document must be

provided for each function.

Master

Outstation

Master

Outstation

Proprietary

File via Other

Mechanism

----------------

1.1.2 Vendor Name: QEI




The name of the organization producing the device.

Note: The current value of this outstation parameter is

available remotely using protocol object Group 0

Variation 252.

1.1.3 Device Name:

The model and name of the device, sufficient to

distinguish it from any other device from the same

organization.



Variation 250.

TDMS-Plus DNP QNET

Server

1.1.4 Device manufacturer's hardware version string:



Variation 243.

N/A

1.1.5 Device manufacturer's software version string:



Variation 242.

7.4

1.1.6 Device Profile Document Version Number:

Version of the Device Profile Document is indicated by a

whole number incremented with each new release. This

should match the latest version shown in the Revision

History at the beginning of this document.

1

1.1.7 DNP Levels Supported for:

Indicate each DNP3 Level to which the device conforms

fully. For Masters, requests and responses can be

indicated independently.

Outstations Only

Requests and Responses

None

Level 1

Level 2

Level 3

Level 4

Level 2

Proprietary

File via Other

Mechanism

----------------

1.1.8 Supported Function Blocks: Self Address Support

Proprietary File

via Other




Data Sets

File Transfer

Virtual Terminal

Mapping to IEC 61850 Object Models defined in a DNP3

XML file

Function code 31, activate configuration

Secure Authentication (if checked then see 1.12)

Mechanism

----------------

1.1.9 Notable Additions:

A brief description intended to quickly identify (for the reader)

the most obvious features the device supports in addition to the

Highest DNP Level Supported. The complete list of features is

described in the Implementation Table.

Proprietary File

via Other

Mechanism

----------------

1.1.10 Methods to set Configurable Parameters: XML - Loaded via DNP3 File Transfer

XML - Loaded via other transport mechanism

Terminal - ASCII Terminal Command Line

Software - Vendor software named

Proprietary file loaded via DNP3 File Transfer

Proprietary file loaded via other transport mechanism

Direct - Keypad on device front panel

Factory - Specified when device is ordered

Protocol - Set via DNP3 (e.g. assign class)

Other - explain:

1.1.11 DNP3 XML files available On-line:

XML configuration file names that can be read or written

through DNP3 File Transfer to a device.

A device's currently running configuration is returned by DNP3

on-line XML file read from the device.

DNP3 on-line XML file write to a device will update the device's

configuration when the Activate Configuration (function code

31) is received.

Rd Wr Filename Description of Contents

dnpDP.xml Complete Device Profile

dnpDPCap.xml Device Profile Capabilities

dnpDPCfg.xml Device Profile config values

Rd Wr Filename

dnpDP.xml

dnpDPCap.xml

dnpDPCfg.xml

Proprietary File

via Other

Mechanism

----------------




1.1.12 External DNP3 XML files available Off-line:

XML configuration file names that can be read or written from

an external system, typically from a system that maintains the

outstation configuration.

External off-line XML file read permits an XML definition of a

new configuration to be supplied from off-line configuration

tools.

External off-line XML file write permits an XML definition of a

new configuration to be supplied to off-line configuration tools.

Rd Wr Filename Description of Contents

dnpDP.xml Complete Device Profile

dnpDPCap.xml Device Profile Capabilities

dnpDPCfg.xml Device Profile config values

Rd Wr Filename

dnpDP.xml

dnpDPCap.xml

dnpDPCfg.xml

Proprietary File

via Other

Mechanism

----------------

1.1.13 Connections Supported: Serial (complete section 1.2)

IP Networking (complete section 1.3)

Other, explain

Serial

IP Networking

Proprietary File

via Other

Mechanism

----------------

1.2 SERIAL CONNECTIONS Capabilities Current Value

If

configurable

list methods

1.2.1 Port Name:

Name used to reference the communications port defined

in this section.

Any

1.2.2 Serial Connection Parameters: Asynchronous - 8 Data Bits, 1 Start Bit, 1 Stop Bit,

No Parity

Other, explain

Note: Implemented in Target Layer

Asynchronous Proprietary File

via Other

Mechanism

----------------

1.2.3 Baud Rate: Fixed at

Configurable, range 1 to 115200

Configurable, selectable from

Configurable, other, describe

Note: Implemented in Target Layer

9600 Proprietary File

via Other

Mechanism

----------------

1.2.4 Hardware Flow Control (Handshaking):

Describe hardware signaling requirements of the None

None RS-232 / V.24 / V.28

Options:

Proprietary File

via Other




interface.

Where a transmitter or receiver is inhibited until a given

control signal is asserted, it is considered to require that

signal prior to sending or receiving characters.

Where a signal is asserted prior to transmitting, that

signal will be maintained active until after the end of

transmission.

Where a signal is asserted to enable reception, any data

sent to the device when the signal is not active could be

discarded.

RS-232 / V.24 / V.28 Options: Asserts:

RTS Before Tx

DTR Before Tx

RTS Before Rx

DTR Before Rx

Always RTS

Always DTR

Requires Before Tx:

CTS Asserted Deasserted

DCD Asserted Deasserted

DSR Asserted Deasserted

RI Asserted Deasserted

Requires Rx Inactive before Tx

Requires Before Rx:

CTS Asserted Deasserted

DCD Asserted Deasserted

DSR Asserted Deasserted

RI Asserted Deasserted

Always Ignores:

CTS

DCD

DSR

RI

Other, explain

RS-422 / V.11 Options:

Other,

RS-422 / V.11 Options:

RS-485Options: Other,

Mechanism

----------------




Requires Indication before Rx

Asserts Control before Tx

Other, explain

RS-485 Options:

Requires Rx inactive before Tx

Other, explain

Other, explain Sofware

1.2.5 Interval to Request Link Status:

Indicates how often to send Data Link Layer status

requests on a serial connection. This parameter is

separate from the TCP Keep-alive timer.

Not Supported

Fixed at seconds

Configurable, range 0 to 2147483647seconds

Configurable, selectable from seconds


0 seconds Proprietary File

via Other

Mechanism

----------------

1.2.6 Supports DNP3 Collision Avoidance:

Indicates whether an Outstation uses a collision

avoidance algorithm.

Collision avoidance may be implemented by a back-off

timer with two parameters that define the back-off time

range or by some other vendor-specific mechanism.

The recommended back-off time is specified as being a

fixed minimum delay plus a random delay, where the

random delay has a maximum value specified. This defines

a range of delay times that are randomly distributed

between the minimum value and the minimum plus the

maximum of the random value.

If a back-off timer is implemented with only a fixed or only

a random value, select the Back-off time method and set

the parameter that is not supported to “Fixed at 0 ms”.

No

Yes, using Back-off time = (Min + Random) method

Other, explain

No Proprietary File

via Other

Mechanism

----------------




1.2.7 Receiver Inter-character Timeout:

When serial interfaces with asynchronous character

framing are used, this parameter indicates if the receiver

makes a check for gaps between characters. (i.e.

extensions of the stop bit time of one character prior to the

start bit of the following character within a message). If

the receiver performs this check and the timeout is

exceeded then the receiver discards the current data link

frame. A receiver that does not discard data link frames

on the basis of inter-character gaps is considered not to

perform this check.

Where no asynchronous serial interface is fitted this

parameter is not applicable. In this case none of the

options shall be selected.

Not Checked

No gap permitted

Fixed at bit times

Fixed at ms

Configurable, range to bit times

Configurable, range to ms

Configurable, selectable from bit times

Configurable, selectable from ms


Variable, explain

Not Checked Proprietary File

via Other

Mechanism

----------------

1.2.8 Inter-character gaps in transmission:

When serial interfaces with asynchronous character

framing are used, this parameter indicates whether extra

delay is ever introduced between characters in the

message, and if so, the maximum width of the gap.

Where no asynchronous serial interface is fitted this

parameter is not applicable. In this case none of the

options shall be selected.

None (always transmits with no inter-character gap)

Maximumbit times

Maximumms

None Proprietary File

via Other

Mechanism

----------------

1.3 IP NETWORKING Capabilities Current Value

If

configurable

list methods

1.3.1 Port Name:

Name used to reference the communications port defined

in this section.

Any

1.3.2 Type of End Point: TCP Initiating (Master Only)

TCP Listening (Outstation Only)

TCP Dual (required for Masters)

UDP Datagram (required)

TCP Listening

Proprietary File

via Other

Mechanism

----------------

1.3.3 IP Address of this Device: *.*.*.* Proprietary File




via Other

Mechanism

----------------

1.3.4 Subnet Mask: *.*.*.* Proprietary File

via Other

Mechanism

----------------

1.3.5 Gateway IP Address: *.*.*.* Proprietary File

via Other

Mechanism

----------------

1.3.6 Accepts TCP Connections or UDP Datagrams

from: Allows all (show as *.*.*.* in 1.3.7)

Limits based on IP address

Limits based on list of IP addresses

Limits based on a wildcard IP address

Limits based on list of wildcard IP addresses

Other, explain

Allows all

Proprietary File

via Other

Mechanism

----------------

1.3.7 IP Address(es) from which TCP Connections or

UDP Datagrams are accepted:

*.*.*.*

Proprietary File

via Other

Mechanism

----------------

1.3.8 TCP Listen Port Number:

If Outstation or dual end point Master, port number on

which to listen for incoming TCP connect requests.

Required to be configureable for Masters and

recommended to be configurable for Outstations.

Not Applicable (Master w/o dual end point)

Fixed at 20,000





via Other

Mechanism

----------------




1.3.9 TCP Listen Port Number of remote device:

If Master or dual end point Outstation, port number on

remote device with which to initiate connection. Required

to be configurable for Masters and recommended to be

configurable for Outstations.

Not Applicable (Outstation w/o dual end point)

Fixed at 20,000





via Other

Mechanism

----------------

1.3.10 TCP Keep-alive timer:

The time period for the keep-alive timer on active TCP

connections.

Fixed at ms

Configurable, range 0 to 32767ms



0 ms Proprietary File

via Other

Mechanism

----------------

1.3.11 Local UDP port:

Local UDP port for sending and/or receiving UDP

datagrams. Masters may let system choose an available

port. Outstations must use one that is known by the

Master.

Fixed at 20,000




Let system choose (Master only)


via Other

Mechanism

----------------

1.3.12 Destination UDP port for DNP3 Requests

(Masters Only): Fixed at 20,000





via Other

Mechanism

----------------

1.3.13 Destination UDP port for initial unsolicited null

responses (UDP only Outstations):

The destination UDP port for sending initial unsolicited

Null response.

None

Fixed at 20,000





via Other

Mechanism

----------------

1.3.14 Destination UDP port for responses (UDP only None





Outstations):

The destination UDP port for sending all responses other

than the initial unsolicited Null response.

Fixed at 20,000




Use source port number

via Other

Mechanism

----------------

1.3.15 Multiple outstation connections (Masters only):

Indicates whether multiple outstation connections are

supported.

Supports multiple outstations (Masters only) Proprietary File

via Other

Mechanism

----------------

1.3.16 Multiple master connections (Outstations only):

Indicates whether multiple master connections are

supported and the method that can be used to establish

connections.

Supports multiple masters (Outstations only)

If supported, the following methods may be used:

Method 1 (based on IP address) - required

Method 2 (based on IP port number) - recommended

Method 3 (browsing for static data) - optional

IP address

IP port number

Proprietary File

via Other

Mechanism

----------------

1.3.17 Time synchronization support: DNP3 LAN procedure (function code 24)

DNP3 Write Time (not recommended over LAN)

Other, explain

Not Supported

Write Time Proprietary File

via Other

Mechanism

----------------

1.4 LINK LAYER Capabilities Current Value

If

configurable

list methods

1.4.1 Data Link Address:

Indicates if the link address is configurable over the entire

valid range of 0 to 65,519. Data link addresses 0xFFF0

through 0xFFFF are reserved for broadcast or other

special purposes.

Fixed at 1024

Configurable, range to




via Other

Mechanism

----------------




1.4.2 DNP3 Source Address Validation:

Indicates whether the Outstation will filter out requests

not from a specific source address.

Never

Always, one address allowed (shown in 1.4.3)

Always, any one of multiple addresses allowed

(each selectable as shown in 1.4.3)

Sometimes, explain

Always - multiple addresses Proprietary File

via Other

Mechanism

----------------

1.4.3 DNP3 Source Address(es) expected when

Validation is Enabled:

Selects the allowed source address(es)

Configurable to any 16 bit DNP Data Link Address

value




Any Data Link Address Proprietary File

via Other

Mechanism

----------------

1.4.4 Self Address Support using address 0xFFFC:

If an Outstation receives a message with a destination

address of 0xFFFC it shall respond normally with its own

source address. It must be possible to diasble this feature

if supported.

Yes (only allowed if configurable)

No

No Proprietary File

via Other

Mechanism

----------------

1.4.5 Sends Confirmed User Data Frames:

A list of conditions under which the device transmits

confirmed link layer services (TEST_LINK_STATES,

RESET_LINK_STATES, CONFIRMED_USER_DATA).

Never

Always

Sometimes, explain

Never Proprietary File

via Other

Mechanism

----------------

1.4.6 Data Link Layer Confirmation Timeout:

This timeout applies to any secondary data link message

that requires a confirm or response (link reset, link status,

user data, etc).

None

Fixed at ms




Variable, explain

2000ms Proprietary File

via Other

Mechanism

----------------

1.4.7 Maximum Data Link Retries:

The number of times the device will retransmit a frame

that requests Link Layer confirmation.

None

Fixed at

3 Proprietary File

via Other

Mechanism







----------------

1.4.8 Maximum number of octets Transmitted in a Data

Link Frame:

This number includes the CRCs. With a length field of 255,

the maximum size would be 292.

Fixed at





via Other

Mechanism

----------------

1.4.9 Maximum number of octets that can be Received

in a Data Link Frame:

This number includes the CRCs. With a field length of 255,

the maximum size would be 292. The device must be able

to receive 292 octets to be compliant.

Fixed at





via Other

Mechanism

----------------

1.5 APPLICATION LAYER Capabilities Current Value

If

configurable

list methods

1.5.1 Maximum number of octets Transmitted in an

Application Layer Fragment other than File Transfer:

This size does not include any transport or frame octets.

- Masters must provide a setting less than or equal to 249

to be compliant.

- Outstations must provide a setting less than or equal to

2048 to be compliant.



Variation 240.

Fixed at





via Other

Mechanism

----------------

1.5.2 Maximum number of octets Transmitted in an

Application Layer Fragment containing File Transfer: Fixed at





via Other

Mechanism

----------------




1.5.3 Maximum number of octets that can be received in

an Application Layer Fragment:

This size does not include any transport or frame octets.

- Masters must provide a setting greater than or equal to

2048 to be compliant.

- Outstations must provide a setting greater than or equal

to 249 to be compliant.



Variation 241.

Fixed at





via Other

Mechanism

----------------

1.5.4 Timeout waiting for Complete Application Layer

Fragment:

Timeout if all frames of a message fragment are not

received in the specified time. Measured from time first

frame of a fragment is received until the last frame is

received.

None

Fixed at ms




Variable, explain


via Other

Mechanism

----------------

1.5.5 Maximum number of objects allowed in a single

control request for CROB (Group 12):



Variation 216.

Fixed at (enter 0 if controls are not supported for

CROB)




Variable, explain

10 Proprietary File

via Other

Mechanism

----------------


control request for Analog Outputs (Group 41): Fixed at (enter 0 if controls are not supported for

Analog Outputs)




Variable, explain

10 Proprietary File

via Other

Mechanism

----------------





control request for Data Sets (Groups 85, 86, 87): Fixed at (enter 0 if controls are not supported for Data

Sets)




Variable, explain

8 Proprietary File

via Other

Mechanism

----------------

1.5.8 Supports mixed object groups (AOBs, CROBs and

Data Sets) in the same control request: Not applicable - controls are not supported

Yes

No

Yes Proprietary File

via Other

Mechanism

----------------

1.5.9. User Data:

A user data entry

1.6 FILL OUT THE FOLLOWING ITEMS FOR MASTERS

ONLY Capabilities Current Value

If

configurable

list methods

1.6.1 Timeout waiting for Complete Application Layer

Responses (ms):

Timeout on Master if all fragments of a response message

are not received in the specified time.

None

Fixed at ms




Variable, explain


via Other

Mechanism

----------------

1.6.2 Maximum Application Layer Retries for Request

Messages:

The number of times a Master will retransmit an

application layer request message if a response is not

received. This parameter must never cause a Master to

retransmit time sync messages.

None

Fixed at




Variable, explain


via Other

Mechanism

----------------




1.6.3 Incremental Timeout waiting for First or Next

Fragment of an Application Layer Response: None

Fixed at ms




Variable, explain


via Other

Mechanism

----------------

1.6.4 Issuing controls to off-line devices:

Indicates if the Master issues control requests to devices

that are thought to be off-line (i.e. the Master has not seen

responses to previous Master requests).

Not applicable - controls are not supported

Yes

No

N/A Proprietary File

via Other

Mechanism

----------------

1.6.5 Issuing controls to off-scan devices:

Indicates if the Master issues control requests to devices

that are currently off-scan (i.e. the Master has been

configured not to issue poll requests to the device).

Not applicable - controls are not supported

Yes

No

N/A Proprietary File

via Other

Mechanism

----------------

1.6.6 Maximum Application Layer Retries for Control

Select Messages (same sequence number):

Indicates the number of times a Master will retransmit an

application layer control select request message if a

response is not received - using the same message

sequence number.

None (required)

Fixed at




Variable, explain


via Other

Mechanism

----------------

1.6.7 Maximum Application Layer Retries for Control

Select Messages (new sequence number):

Indicates the number of times a Master will retransmit an

application layer control select request message if a

response is not received - using a new message sequence

number.

None (required)

Fixed at




Variable, explain


via Other

Mechanism

----------------




1.6.8 Maximum error in the time that the Master issues

freeze requests:

If the Master is scheduled to issue freeze requests at a

specific time, what is the maximum error in the time that

the Master may actually issue a request?

ms

Proprietary File

via Other

Mechanism

----------------

1.6.9 Maximum error in the time that the Master

schedules repetitive freeze requests:

If the Master is scheduled to issue freeze requests at a

regular interval, what is the maximum error in the time

interval that the Master may actually issue a request? (i.e.

how early / late could the request actually be issued)?

ms

Proprietary File

via Other

Mechanism

----------------

1.6.10 Scheduled actions that may affect the accuracy of

freeze requests:

Indicates if the Master's accuracy of issuing freeze

requests may be affected by other scheduled operations

such as poll requests or control requests.

Freeze time may be affected by Poll requests

Freeze time may be affected by Control requests

Proprietary File

via Other

Mechanism

----------------

1.6.11 Master's algorithm for scheduling request

operations:

Describe the Master's algorithm for determination of

which activity is performed when more than one is due at

the same moment. Discuss precedence and priorities for

activities such as time synchronization, poll requests,

control requests and freeze requests.

1.7 FILL OUT THE FOLLOWING ITEMS FOR

OUTSTATIONS ONLY Capabilities Current Value

If

configurable

list methods

1.7.1 Timeout waiting for Application Confirm of

solicited response message: None

Fixed at ms




Variable, explain

10000ms Proprietary File

via Other

Mechanism

----------------




1.7.2 How often is time synchronization required from

the master:

Details of when the master needs to perform a time

synchronization to ensure that the outstation clock does

not drift outside of an acceptable tolerance. If the option

to relate this to IIN1.4 is used then details of when IIN1.4

is asserted are in section 1.10.2.

Never needs time

Within seconds after IIN1.4 is set

Periodically, fixed at seconds

Periodically, between and seconds


via Other

Mechanism

----------------

1.7.3 Device Trouble Bit IIN1.6:

If IIN1.6 device trouble bit is set under certain conditions,

explain the possible causes.

Never used

Reason for setting

Never used Proprietary File

via Other

Mechanism

----------------

1.7.4 File Handle Timeout:

If there is no activity referencing a file handle for a

configurable length of time, the outstation must do an

automatic close on the file. The timeout value must be

configurable up to 1 hour. When this condition occurs the

outstation will send a File Transport Status Object (obj

grp 70 var 6) using a status code value of handle expired

(0x02).

Not applicable, files not supported

Fixed at ms




Variable, explain

Not applicable Proprietary File

via Other

Mechanism

----------------

1.7.5 Event Buffer Overflow Behavior: Discard the oldest event

Discard the newest event

Other, explainper Object Group

Other, per Object Group

Proprietary File

via Other

Mechanism

----------------

1.7.6 Event Buffer Organization:

Explain how event buffers are arranged (per Object

Group, per Class, single buffer etc) and provide their

sizes.

per Object Group per Object Group Proprietary File

via Other

Mechanism

----------------

1.7.7 Sends Multi-Fragment Responses:

Indicates whether an Outstation sends multi-fragment

responses (Masters do not send multi-fragment requests).

Yes

No


via Other

Mechanism

----------------




1.7.8 Last Fragment Confirmation:

Indicates whether the Outstation requests confirmation of

the last fragment of a multi-fragment response.

Always

Sometimes, explainOnly when it contains events

Never

Sometimes Proprietary File

via Other

Mechanism

----------------

1.7.9 DNP Command Settings preserved through a

device restart:

If any of these settings are written through the DNP

protocol and they are not preserved through a restart of

the Outstation, the Master will have to write them again

after it receives a response in which the Restart IIN bit is

set.

Assign Class

Analog Deadbands

Data Set Prototypes

Data Set Descriptors

Function Code 31 Activate Configuration

Proprietary File

via Other

Mechanism

----------------

1.8 OUTSTATION UNSOLICITED RESPONSE SUPPORT Capabilities Current Value

If

configurable

list methods

1.8.1 Supports Unsolicited Reporting:

When the unsolicited response mode is configured "off",

the device is to behave exactly like an equivalent device

that has no support for unsolicited responses. If set to

"on", the Outstation will send a null Unsolicited Response

after it restarts, then wait for an Enable Unsolicited

Response command from the master before sending

additional Unsolicited Responses containing event data.

Not Supported

Configurable, selectable from On and Off

On Proprietary File

via Other

Mechanism

----------------

1.8.2 Master Data Link Address:

The destination address of the master device where the

unsolicited responses will be sent.

Fixed at 1024





via Other

Mechanism

----------------

1.8.3 Unsolicited Response Confirmation Timeout:

This is the amount of time that the outstation will wait for

an Application Layer confirmation back from the master

indicating that the master received the unsolicited

response message. As a minimum, the range of

configurable values must include times from one second to

one minute. This parameter may be the same one that is

Fixed at ms





via Other

Mechanism

----------------




used for normal, solicited, application confirmation

timeouts, or it may be a separate parameter. Variable, explain

1.8.4 Number of Unsolicited Retries:

This is the number of retries that an outstation transmits in

each unsolicited response series if it does not receive

confirmation back from the master. The configured value

includes identical and regenerated retry messages. One of

the choices must provide for an indefinite (and potentially

infinite) number of transmissions.

None

Fixed at




Always infinite, never gives up

3 Proprietary File

via Other

Mechanism

----------------

1.8.5. User Data:

A user data entry

1.9 OUTSTATION UNSOLICITED RESPONSE TRIGGER

CONDITIONS Capabilities Current Value

If

configurable

list methods

1.9.1 Number of class 1 events: Class 1 not used to trigger Unsolicited Responses

Fixed at




5 Proprietary File

via Other

Mechanism

----------------


Fixed at




5 Proprietary File

via Other

Mechanism

----------------


Fixed at


5 Proprietary File

via Other

Mechanism

----------------






1.9.4 Total number of events from any class: Total Number of Events not used to trigger

Unsolicited Responses

Fixed at




Proprietary File

via Other

Mechanism

----------------

1.9.5 Hold time after class 1 event:

A configurable value of 0 indicates that responses are not

delayed due to this parameter.

Class 1 not used to trigger Unsolicited Responses

Fixed at ms




Proprietary File

via Other

Mechanism

----------------





Fixed at ms




Proprietary File

via Other

Mechanism

----------------





Fixed at ms




Proprietary File

via Other

Mechanism

----------------

1.9.8 Hold time after event assigned to any class:

A configurable value of 0 indicates that responses are not Class events not used to trigger Unsolicited

Proprietary File

via Other




delayed due to this parameter. Responses

Fixed at ms




Mechanism

----------------

1.9.9 Retrigger Hold Time:

The hold-time timer may be retriggered for each new

event detected (increased possibility of capturing all the

changes in a single response) or not retriggered (giving

the master a guaranteed update time).

Hold-time timer will be retriggered for each new

event detected (may get more changes in next response)

Hold-time timer will not be retriggered for each new

event detected (guaranteed update time)

Not retriggered Proprietary File

via Other

Mechanism

----------------

1.9.10 Other Unsolicited Response Trigger Conditions: Proprietary File

via Other

Mechanism

----------------

1.10 OUTSTATION PERFORMANCE Capabilities Current Value

If

configurable

list methods

1.10.1 Maximum Time Base Drift (milliseconds per

minute):

If the device is synchronized by DNP, what is the clock

drift rate over the full operating temperature range.

Fixed at ms

Range to ms

Selectable from ms

Other, describe


via Other

Mechanism

----------------

1.10.2 When does outstation set IIN1.4:

When does the outstation set the internal indication IIN1.4

NEED_TIME

Never

Asserted at startup until first Time Synchronization

request received

Periodically every seconds

Periodically, range to seconds

Periodically, selectable from seconds

seconds after last time sync

108000 seconds after last sync Proprietary File

via Other

Mechanism

----------------




Range to seconds after last time sync

Selectable from seconds after last time sync

When time error may have drifted by ms

When time error may have drifted by range to ms

When time error may have drifted by selectable from

ms

1.10.3 Maximum Internal Time Reference Error when

set via DNP (ms):

The difference between the time set in DNP Write Time

message, and the time actually set in the outstation.

Fixed at ms

Range to ms

Selectable from ms

Other, describe


via Other

Mechanism

----------------

1.10.4 Maximum Delay Measurement Error (ms):

The difference between the time reported in the delay

measurement response and the actual time between

receipt of the delay measurement request and issuing the

delay measurement reply.

Fixed at 0ms

Range to ms

Selectable from ms

Other, describe


via Other

Mechanism

----------------

1.10.5 Maximum Response Time (ms):

The amount of time an outstation will take to respond

upon receipt of a valid request. This does not include the

message transmission time.

Fixed at 0ms

Range to ms

Selectable from ms

Other, describe


via Other

Mechanism

----------------

1.10.6 Maximum time from start-up to IIN 1.4 assertion

(ms): Fixed at 0ms

Range to ms

Selectable from ms

Other, describe


via Other

Mechanism

----------------

1.10.7 Maximum Event Time-tag error for local Binary

and Double Bit I/O (ms):

The error between the time-tag reported and the absolute

Fixed at 0ms

Range to ms


via Other

Mechanism




time of the physical event. This error includes the Internal

Time Reference Error.

Note: The current value of this parameter is available

remotely using protocol object Group 0 Variation 217.

Selectable from ms

Other, describe

----------------

1.10.8 Maximum Event Time-tag error for local I/O

other than Binary and Double Bit data types (ms): Fixed at 0ms

Range to ms

Selectable from ms

Other, describe

0 ms

1.11 INDIVIDUAL FIELD OUTSTATION PARAMETERS Value of Current Setting

If

configurable

list methods

1.11.1 User-assigned location name or code string (same as g0v245): Proprietary File

via Other

Mechanism

----------------

1.11.2 User-assigned ID code/number string (same as g0v246): Proprietary File

via Other

Mechanism

----------------

1.11.3 User-assigned name string for the outstation (same as g0v247): Proprietary File

via Other

Mechanism

----------------

1.11.4 Device Serial Number string (same as g0v248): Proprietary File

via Other

Mechanism

----------------

1.12 SECURITY PARAMETERS Capabilities Current Value If

configurable




list methods

1.12.1 DNP3 device support for secure authentication:

The support for secure authentication is optional in DNP3

devices. Indicate here if the device supports secure

authentication.

If the device does not support secure authentication then

ignore the rest of this section.

If the device does support secure authentication then

specify the version(s) that are supported in the device. The

version number is an integer value defined in the DNP3

Specification. The Secure Authentication procedure

defined in IEEE 1815-2010 is version 2. The Secure

Authentication procedure defined in IEEE 1815-2012 is

version 5.

Secure Authentication not supported

If Secure Authentication is supported, what Version(s) are

supported:

Fixed at 2


Supports security

Version: 2

Proprietary File

via Other

Mechanism

----------------

1.12.2 Maximum number of users:

The secure authentication algorithm provides support for

multiple users. The device must support details for each

user (update keys, session keys, etc). A user is identified by

a 16-bit user number, allowing a maximum of 65535

users. Devices are not mandated to support this number of

potential users. Indicate here the actual limit to the

number of simultaneous users that can be supported.

Maximum nunber of users supported: 1 Maximum number of users

supported: 1

Proprietary File

via Other

Mechanism

----------------

1.12.3 Security message response timeout:

Authentication of critical messages may involve additional

message exchanges (challenges and responses) which can

require an extension to the normal DNP3 message

response timeout. This timeout specifies an additional time

to be used when the extra security transactions are

involved. The maximum allowable timeout extension

should not exceed 120 seconds.

Fixed at 2ms





via Other

Mechanism

----------------

1.12.4 Aggressive mode of operation (receive):

DNP3 devices may (optionally) accept "aggressive" mode

requests, where challenge data used for authentication is

appended to a critical message rather than needing to be

solicited via a separate message exchange.

Yes, accepts aggressive

mode requests

No, does not accept

aggressive mode requests

Proprietary File

via Other

Mechanism

----------------




1.12.5 Aggressive mode of operation (issuing):

DNP3 devices must support the issuing of "aggressive"

mode of operation, where challenge data used for

authentication is appended to a critical message rather

than needing to be solicited via a separate message

exchange. Specific instances of devices may have the use

of aggressive mode switched off.

Yes, issues aggressive mode

requests

No, does not issue

aggressive mode requests

Proprietary File

via Other

Mechanism

----------------

1.12.6 Session key change interval:

To counter an attack that compromises the session key, the

session key is changed at regular intervals. The maximum

interval is 2 hours. Outstation devices invalidate the

current set of session keys if they have not been changed

by the master station after a period of twice this

configured value.

To accommodate systems with infrequent communications,

this change interval can be disabled and just the session

key change message count used (see 1.12.7)

Can be disabled

When enabled


Enabled

900 seconds

Proprietary File

via Other

Mechanism

----------------

1.12.7 Session key change message count:

In addition to changing the session key at regular

intervals, the key shall also be changed after a specified

number of messages have been exchanged. The maximum

allowable value for this message count is 10,000

Configurable, range 1 to 10000 1000 Proprietary File

via Other

Mechanism

----------------

1.12.8 Maximum error count:

To assist in countering denial of service attacks, a DNP3

device shall stop replying with error codes after a number

of successive authentication failures. This error count has

a maximum value of 10. Setting the error count to zero

inhibits all error messages.

Configurable, range 0 to 10 2

Proprietary File

via Other

Mechanism

----------------

1.12.9 MAC algorithm requested in a challenge

exchange:

Part of the authentication message is hashed using an

MAC algorithm. Secure Authentication version 2 specifies

that DNP3 devices must support SHA-1 and may

optionally support SHA-256 for this hashing process.

Secure Authentication version 5 specifies that SHA-256 is

the default. The output of the MAC algorithm is truncated

(the resulting length dependant on the media being used).

SHA-1 (truncated to the leftmost 4 octets)





AES-GMAC

SHA-1 (10)

Proprietary File

via Other

Mechanism

----------------




Other, explain:

1.12.10 Key-wrap algorithm to encrypt session keys:

During the update of a session key, the key is encrypted

using AES-128 or optionally using other algorithms.

AES-128

AES-256

RSAES-OAEP-1024 / SHA-1



Other, explain:

AES-128

Proprietary File

via Other

Mechanism

----------------

1.12.11 Cipher Suites used with DNP implementations

using TLS:

When TLS is supported, DNP3 Secure Authentication

mandates the support of TLS_RSA_WITH_AES_128_SHA.

The specification has a number of recommended cipher

suite combinations. Indicate the supported Cipher Suites

for implementations using TLS.

Not relevant - TLS is not used

TLS_RSA encrypted with AES128

TLS_RSA encrypted with RC4_128

TLS_RSA encrypted with 3DES_EDE_CBC

TLS_DH, signed with DSS, encrypted with

3DES_EDE_CBC

TLS_DH, signed with RSA, encrypted with

3DES_EDE_CBC

TLS_DHE, signed with DSS, encrypted with

3DES_EDE_CBC

TLS_DHE, signed with RSA, encrypted with

3DES_EDE_CBC

TLS_DH, signed with DSS, encrypted with AES128

TLS_DH, signed with DSS, encrypted with AES256

TLS_DH encrypted with AES128

TLS_DH encrypted with AES256

Other, explain:

Proprietary File

via Other

Mechanism

----------------

1.12.12 Change cipher request timeout:

Implementations using TLS shall terminate the connection

if a response to a change cipher request is not seen within


Fixed at

Not relevant

Proprietary File

via Other

Mechanism




this timeout period. Configurable, range to



----------------

1.12.13 Number of Certificate Authorities supported:

Implementations using TLS shall support at least 4

Certificate Authorities. Indicate the number supported.

0

Proprietary File

via Other

Mechanism

----------------

1.12.14 Certificate Revocation check time:

Implementations using TLS shall evaluate Certificate

Revocation Lists on a periodic basis, terminating a

connection if a certificate is revoked.


Fixed at hours

Configurable, range to hours

Configurable, selectable from hours


Not relevant

Proprietary File

via Other

Mechanism

----------------

1.12.15 Additional critical function codes:

The DNP3 specification defines those messages with

specific function codes that are critical and must be used

as part of a secure authentication message exchange.

Messages with other function codes are optional and

changes to this list should be noted here.

Note: Secure Authentication version 5 defines additional

functions as critical that were not considered critical in

version 2. These are shown in the next column annotated

with "V2 only".

Additional function codes that are to be considered as

"critical":

0 (Confirm)

1 (Read)

7 (Immediate freeze)

8 (Immediate freeze - no ack)

9 (Freeze-and-clear)

10 (Freeze-and-clear - no ack)

11 (Freeze-at-time)

12 (Freeze-at-time - no ack)

22 (Assign Class)

23 (Delay Measurement)

25 (Open File) - V2 only

26 (Close File) - V2 only

Proprietary File

via Other

Mechanism

----------------




27 (Delete File) - V2 only

28 (Get File Info) - V2 only

30 (Abort File) - V2 only

129 (Response)

130 (Unsolicited Response)

1.12.16 Other critical fragments:

Other critical transactions can be defined and should be

detailed here. Examples could be based on time (for

example: the first transaction after a communications

session is established). Other examples could be based on

specific data objects (for example: the reading of specific

data points).

1.12.17 Support for remote update key changes:

Devices implementing secure authentication version 5 of

later have the option to support remote update key

changes. If remote update key change is supported then

the procedure using symmetric cryptography is

mandatory. Additional support for the procedure using

asymmetric (public key) cryptography is optional.

Remote update key change by symmetric

cryptography

Remote update key change by asymmetric

cryptography

Proprietary File

via Other

Mechanism

----------------

1.13 BROADCAST FUNCTIONALITY Capabilities Current Value

If

configurable

list methods

This section indicates which functions are supported by the device when using broadcast addresses. Note that it is mandatory for outstations to be configurable to enable or

disable the support for each function in order to comply with the requirements of the IED conformance tests dated 2012 and later.

Note that this section shows only entries that may have a meaningful purpose when used with broadcast requests.

1.13.1 Support for broadcast functionality: Disabled

Enabled

Configurable

Proprietary File

via Other

Mechanism

----------------

1.13.2 Write functions (FC = 2) supported with

broadcast requests:

Write clock (g50v1 with qualifier code 07) Write clock: Disabled

Clock:

Proprietary File




Disabled

Enabled

Configurable, other (described elsewhere)

Write last recorded time (g50v3 with qualifier code 07)

Disabled

Enabled


Clear restart (g80v1 with qualifier code 00 and index = 7,

value = 0)

Disabled

Enabled


Write to any other group / variation / qualifier code

Disabled

Enabled


Write last recorded time:

Disabled

Clear restart: Enabled

Write any other: Disabled

via Other

Mechanism

----------------

Time:

Proprietary File

via Other

Mechanism

----------------

Restart:

Proprietary File

via Other

Mechanism

----------------

Other:

Proprietary File

via Other

Mechanism

----------------

1.13.3 Direct operate functions (FC = 5) supported with

broadcast requests: Disabled

Enabled


Disabled Proprietary File

via Other

Mechanism

----------------

1.13.4 Direct operate, no acknowledgement functions

(FC = 6) supported with broadcast requests: Disabled

Enabled



via Other

Mechanism

----------------

1.13.5 Immediate freeze functions (FC = 7) supported

with broadcast requests: Disabled

Enabled


Enabled Proprietary File

via Other

Mechanism

----------------




1.13.6 Immediate freeze, no acknowledgement functions


Enabled



via Other

Mechanism

----------------

1.13.7 Freeze and clear functions (FC = 9) supported


Enabled



via Other

Mechanism

----------------

1.13.8 Freeze and clear, no acknowledgement functions


Enabled



via Other

Mechanism

----------------

1.13.9 Freeze at time functions (FC = 11) supported with


Enabled



via Other

Mechanism

----------------

1.13.10 Freeze at time, no acknowledgement functions


Enabled



via Other

Mechanism

----------------

1.13.11 Cold restart functions (FC = 13) supported with


Enabled



via Other

Mechanism

----------------

1.13.12 Warm restart functions (FC = 14) supported


Enabled



via Other

Mechanism

----------------




1.13.13 Initialize data functions (FC = 15) supported


Enabled



via Other

Mechanism

----------------

1.13.14 Initialize application functions (FC = 16)

supported with broadcast requests: Disabled

Enabled



via Other

Mechanism

----------------

1.13.15 Start application functions (FC = 17) supported


Enabled



via Other

Mechanism

----------------

1.13.16 Stop application functions (FC = 18) supported


Enabled



via Other

Mechanism

----------------

1.13.17 Save configuration functions (FC = 19)


Enabled



via Other

Mechanism

----------------

1.13.18 Enable unsolicited functions (FC = 20)

supported with broadcast requests:

Enable unsolicited by event Class (g60v2, g60v3 and

g60v4 with qualifier code 06)

Disabled

Enabled


Enable unsolicited for any other group / variation /

qualifier code

Disabled

Enabled

By event class: Enabled

By any other: Enabled

Class:

Proprietary File

via Other

Mechanism

----------------

Other:

Proprietary File

via Other

Mechanism

----------------





1.13.19 Disable unsolicited functions (FC = 21)

supported with broadcast requests:

Disable unsolicited by event Class (g60v2, g60v3 and

g60v4 with qualifier code 06)

Disabled

Enabled


Disable unsolicited for any other group / variation /

qualifier code

Disabled

Enabled


By event class: Enabled

By any other: Enabled

Class:

Proprietary File

via Other

Mechanism

----------------

Other:

Proprietary File

via Other

Mechanism

----------------

1.13.20 Assign class functions (FC = 22) supported with


Enabled



via Other

Mechanism

----------------

1.13.21 Record current time functions (FC = 24)


Enabled



via Other

Mechanism

----------------

1.13.22 Activate configuration functions (FC = 31)


Enabled



via Other

Mechanism

----------------

2 Mapping between DNP3 and IEC 61850 Objects

This optional section allows each configuration parameter or point in the DNP Data map to be tied to an attribute in the IEC 61850 object models (and vice-versa).

Earlier versions of this section (up to version 2.07) used mappings based on an "access point" (section 2.1.1 and then a series of XPath references (section 2.1.2). Section

2.1.2 has been superseded in version 2.08 onwards with mappings defined using either predefined rules (section 2.1.3) or specified as an equation (section 2.1.4). The list

of pre-defined rules is found in the IEEE 1815-1 document.

The following display has been selected to be in a tabular form.




MAPPING BETWEEN DNP3 AND IEC 61850 OBJECTS

3 Capabilities and Current Settings for Device Database (Outstation only)

The following tables identify the capabilities and current settings for each DNP3 data type. Details defining the data points available in the device are shown in part 5 of this Device Profile.

3.1 SINGLE-BIT BINARY INPUT POINTS

Static (Steady-State) Object Number: 1

Event Object Number: 2

.

Capabilities

(leave tick-boxes blank if this data type is not

supported)

Current Value

If

configurable

list methods

3.1.1 Static Variation reported when variation 0

requested or in response to Class polls: Variation 1 - Single-bit packed format

Variation 2 - Single-bit with flag

Based on point index (add column to table in part 5)

One Proprietary File

via Other

Mechanism

----------------

3.1.2 Event Variation reported when variation 0

requested or in response to Class polls:

Note: The support for binary input events can be

determined remotely using protocol object Group 0

Variation 237.

Variation 1 - without time

Variation 2 - with absolute time

Variation 3 - with relative time


Three Proprietary File

via Other

Mechanism

----------------

3.1.3 Event reporting mode:

When responding with event data and more than one event

has occurred for a data point, an Outstation may include

all events or only the most recent event.

"All events" must be checked to be compliant.

Only most recent

All events


All events Proprietary File

via Other

Mechanism

----------------

3.1.4 Binary Inputs included in Class 0 response: Always

Never

Only if point is assigned to a class


Always Proprietary File

via Other

Mechanism

----------------

3.2 DOUBLE-BIT INPUT POINTS






.

Capabilities


supported)

Current Value

If

configurable

list methods



Note: The support for double-bit inputs can be determined


Variation 1 - Double-bit packed format

Variation 2 - Double-bit with flag



via Other

Mechanism

----------------


requested or in response to Class polls: Variation 1 - without time


Variation 3 - with relative time



via Other

Mechanism

----------------





"All events" must be checked to be compliant.

Only most recent

All events



via Other

Mechanism

----------------

3.2.4 Double Bit Inputs included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.3 BINARY OUTPUT STATUS AND CONTROL RELAY OUTPUT BLOCK

Binary Output Status Object Number: 10

Binary Output Event Object Number: 11

CROB Object Number: 12

Binary Output Command Event Object Number: 13

.

Capabilities


supported)

Current Value

If

configurable

list methods




3.3.1 Minimum pulse time allowed with Trip, Close and

Pulse On commands: Fixed at 0 ms (hardware may limit this further)


Based on point index (see tables

in part 5)

Proprietary File

via Other

Mechanism

----------------

3.3.2 Maximum pulse time allowed with Trip, Close and

Pulse On commands: Fixed at 2147483647 ms (hardware may limit this

further


Based on point index (see tables

in part 5)

Proprietary File

via Other

Mechanism

----------------

3.3.3 Binary Output Status included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.3.4 Reports Output Command Event Objects: Never

Only upon a successful Control

Upon all control attempts

On success Proprietary File

via Other

Mechanism

----------------


requested or in response to Class polls: Variation 1 - Continuous control

Variation 2 - Continuous control, binary output status



via Other

Mechanism

----------------



Note: The support for binary output events can be


Variation 222.

Variation 1 - without time




via Other

Mechanism

----------------

3.3.7 Command Event Variation reported when variation

0 requested or in response to Class polls: Variation 1 - without time




via Other

Mechanism

----------------








Only most recent

All events


via Other

Mechanism

----------------

3.3.9 Command Event reporting mode:




Only most recent

All events


via Other

Mechanism

----------------

3.3.10 Maximum Time between Select and Operate: Not Applicable

Fixed at 5seconds




Variable, explain Based on point index (add

column to table in part 5)


via Other

Mechanism

----------------

3.4 COUNTERS / FROZEN COUNTERS

Static Counter Object Number: 20

Static Frozen Counter Object Number: 21

Counter Event Object Number: 22

Frozen Counter Event Object Number: 23

.

Capabilities


supported)

Current Value

If

configurable

list methods

3.4.1 Static Counter Variation reported when variation 0

requested or in response to Class polls: Variation 1 - 32-bit with flag

Variation 2 - 16-bit with flag

Variation 5 - 32-bit without flag



Five Proprietary File

via Other

Mechanism

----------------




3.4.2 Counter Event Variation reported when variation 0


Note: The support for counter events can be determined




Variation 5 - 32-bit with flag and time




via Other

Mechanism

----------------

3.4.3 Counters included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.4.4 Counter Event reporting mode:



all events or only the most recent event. Only the most

recent event is typically reported for Counters. When

reporting only the most recent event the counter value

returned in the response may be either the value at the

time that the event is queued or it may be the value at the

time of the response.

A: Only most recent (value at time of event)

B: Only most recent (value at time of response)

C: All events


Most recent - event time

3.4.5 Static Frozen Counter Variation reported when

variation 0 requested or in response to Class polls: Variation 1 - 32-bit with flag







Nine Proprietary File

via Other

Mechanism

----------------

3.4.6 Frozen Counter Event Variation reported when

variation 0 requested or in response to Class polls:

Note: The support for frozen counter events can be





via Other

Mechanism

----------------




Variation 225. Variation 5 - 32-bit without flag



3.4.7 Frozen Counters included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.4.8 Frozen Counter Event reporting mode:



all events or only the most recent event. All events are

typically reported for Frozen Counters

Only most recent frozen value

All frozen values


Most recent Proprietary File

via Other

Mechanism

----------------

3.4.9 Counters Roll Over at: 16 Bits (65,535)

32 Bits (4,294,967,295)

Fixed at





Based on point index

3.4.10 Counters frozen by means of: Master Request

Freezes itself without concern for time of day

Freezes itself and requires time of day

Other, explain:

Master Request

3.5 ANALOG INPUT POINTS



Deadband Object Number: 34




.

Capabilities


supported)

Current Value

If

configurable

list methods


requested or in response to Class polls: Variation 1 - 32-bit with flag




Variation 5 - single-precision floating point with flag

Variation 6 - double-precision floating point with flag



via Other

Mechanism

----------------



Note: The support for analog input events can be


Variation 231.

Variation 1 - 32-bit without time


Variation 3 - 32-bit with time


Variation 5 - single-precision floating point w/o time

Variation 6 - double-precision floating point w/o time

Variation 7 - single-precision floating point with time

Variation 8 - double-precision floating point with time



via Other

Mechanism

----------------




all events or only the most recent event. Only the most

recent event is typically reported for Analog Inputs. When

reporting only the most recent event the analog value

returned in the response may be either the value at the

time that the event is queued or it may be the value at the

time of the response.

A: Only most recent (value at time of event)

B: Only most recent (value at time of response)

C: All events


Most recent - event time Proprietary File

via Other

Mechanism

----------------




3.5.4 Analog Inputs included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.5.5 How Deadbands are set: A. Global Fixed

B. Configurable through DNP

C. Configurable via other means

D. Other, explain:

Based on point index - column in part 5 specifies

which of the options applies, B, C, or D

B

Proprietary File

via Other

Mechanism

----------------

3.5.6 Analog Deadband Algorithm:

simple- just compares the difference from the

previous reported value

integrating- keeps track of the accumulated change

other- indicating another algorithm

Simple

Integrating

Other, explain:


Simple Proprietary File

via Other

Mechanism

----------------

3.5.7 Static Frozen Analog Input Variation reported

when variation 0 requested or in response to Class polls: Variation 1 - 32-bit with flag


Variation 3 - 32-bit with time-of-freeze

Variation 4 - 16-bit with time-of-freeze






3.5.8 Frozen Analog Input Event Variation reported Variation 1 - 32-bit without time




when variation 0 requested or in response to Class polls:

Note: The support for frozen analog input events can be


Variation 230.









3.5.9 Frozen Analog Inputs included in Class 0

response: Always

Never



3.5.10 Frozen Analog Input Event reporting mode:



all events or only the most recent event. All events are

typically reported for Frozen Analog Inputs.

Only most recent frozen value

All frozen values


3.6 ANALOG OUTPUT STATUS AND ANALOG OUTPUT CONTROL BLOCK

Analog Output Status Object Number: 40

Analog Output Control Block Object Number: 41

Analog Output Event Object Number: 42

Analog Output Command Event Object Number: 43

.

Capabilities


supported)

Current Value

If

configurable

list methods

3.6.1 Static Analog Output Status Variation reported

when variation 0 requested or in response to Class polls: Variation 1 - 32-bit with flag



Two Proprietary File

via Other

Mechanism

----------------






3.6.2 Analog Output Status included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.6.3 Reports Output Command Event Objects: Never

Only upon a successful Control

Upon all control attempts

Never



Note: The support for analog output events can be


Variation 219.











via Other

Mechanism

----------------

3.6.5 Command Event Variation reported when variation

0 requested or in response to Class polls: Variation 1 - 32-bit without time







via Other

Mechanism

----------------











Only most recent

All events


via Other

Mechanism

----------------

3.6.7 Command Event reporting mode:




Only most recent

All events


via Other

Mechanism

----------------

3.6.8 Maximum Time between Select and Operate: Not Applicable

Fixed at 5seconds




Variable, explain Based on point index (add

column to table in part 5)


via Other

Mechanism

----------------

3.7 SEQUENTIAL FILE TRANSFER

Object Number: 70

. Capabilities Current Value

If

configurable

list methods

3.7.1 File Transfer Supported: Yes

No (set 3.7.6 to "Fixed at 0" and do not complete

other entries in section 3.7)


via Other

Mechanism

----------------




3.7.2 File Authentication:

Indicates whether a valid authentication key must be

obtained prior to open and delete requests.

Always

Sometimes, explain

Never

Sometimes Proprietary File

via Other

Mechanism

----------------

3.7.3 File Append Mode:

Indicates if a file can be opened and appended to versus

just overwritten.

Always

Sometimes, explain

Never


via Other

Mechanism

----------------

3.7.4 Permissions Support:

Indicates the device is capable of using the indicated

permissions.

Owner Read Allowed: 0x0100

Owner Write Allowed: 0x0080

Owner Execute Allowed: 0x0040

Group Read Allowed: 0x0020

Group Write Allowed: 0x0010

Group Execute Allowed: 0x0008

World Read Allowed: 0x0004

World Write Allowed: 0x0002

World Execute Allowed: 0x0001

Owner Read

Owner Write

Owner Execute

Group Read

Group Write

Group Execute

World Read

World Write

World Execute

Proprietary File

via Other

Mechanism

----------------

3.7.5 Multiple Blocks in a Fragment:

File data is transferred in a series of blocks of a maximum

specified size. This indicates whether only a single block

or multiple blocks will be sent in fragment.

Yes

No

No

3.7.6 Max number of Files Open at one time: Fixed at 1




1

3.8 OCTET STRING POINTS







If

configurable

list methods





Only most recent

All events



via Other

Mechanism

----------------

3.8.2 Octet Strings included in Class 0 response: Always

Never




via Other

Mechanism

----------------

3.9 VIRTUAL TERMINAL PORT NUMBERS (POINTS)




If

configurable

list methods

This version of the Device Profile has no requirement for describing Virtual Terminal point capabilities and current settings. This page is intentionally left blank, existing

as placeholder for future use.

3.10 DATA SET PROTOTYPE

Object Number: 85

Variation Number: 1


If

configurable

list methods

This version of the Device Profile has no requirement for describing Data Set Prototype capabilities and current settings. This page is intentionally left blank, existing as

placeholder for future use.

3.11 DATA SET DESCRIPTOR CONTENTS AND CHARACTERISTICS

Object Number: 86




Variation Numbers: 1 and 2

This version of the Device Profile has no requirement for describing Data Set Descriptor capabilities and current settings. This page is intentionally left blank, existing as

placeholder for future use.

4 Implementation Table The following implementation table identifies which object groups and variations, function codes and qualifiers the device supports in both requests and responses. The

Request columns identify all requests that may be sent by a Master, or all requests that must be parsed by an Outstation. The Response columns identify all responses that

must be parsed by a Master, or all responses that may be sent by an Outstation.

DNP OBJECT GROUP & VARIATION

REQUEST

Master may issue

Outstation must parse

RESPONSE

Master must parse

Outstation may issue

Object

Group

Number

Variation

Number Description

Function Codes

(dec)

Qualifier Codes

(hex)

Function Codes

(dec)

Qualifier Codes

(hex)

1 0 Binary Input - any variation 1(read) 00, 01 (start-stop),

06 (no range, or

all),

07, 08 (limited qty),

17, 27,

28 (index)

1 1 Binary Input - Single-bit packed 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)




1 2 Binary Input - Single-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

2 0 Binary Input Change Event - any variation 1(read) 06 (no range, or

all),

07, 08 (limited qty)

2 1 Binary Input Change Event - without time 1(read) 06 (no range, or

all),


129 (Response) 17, 28 (index)

2 1 Binary Input Change Event - without time 130 (Unsol. Resp.) 17, 28 (index)

2 2 Binary Input Change Event - with absolute time 1(read) 06 (no range, or

all),



2 2 Binary Input Change Event - with absolute time 130 (Unsol. Resp.) 17, 28 (index)

2 3 Binary Input Change Event - with relative time 1(read) 06 (no range, or

all),



2 3 Binary Input Change Event - with relative time 130 (Unsol. Resp.) 17, 28 (index)

3 0 Double-bit Input - any variation 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,




28 (index)

3 1 Double-bit Input - Double-bit packed 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

3 2 Double-bit Input - with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

4 0 Double-bit Input Change Event - any variation 1(read) 06 (no range, or

all),


4 1 Double-bit Input Change Event - without time 1(read) 06 (no range, or

all),



4 1 Double-bit Input Change Event - without time 130 (Unsol. Resp.) 17, 28 (index)

4 2 Double-bit Input Change Event - with absolute time 1(read) 06 (no range, or

all),



4 2 Double-bit Input Change Event - with absolute time 130 (Unsol. Resp.) 17, 28 (index)

4 3 Double-bit Input Change Event - with relative time 1(read) 06 (no range, or

all),






4 3 Double-bit Input Change Event - with relative time 130 (Unsol. Resp.) 17, 28 (index)

10 0 Binary Output - any variation 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 28 (index)

10 1 Binary Output - packed format 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 28 (index)

129 (Response) 00, 17, 28 (index)

10 1 Binary Output - packed format 2(write) 00, 01 (start-stop)

10 2 Continuous Control - output status with flags 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 28 (index)

129 (Response) 00, 17, 28 (index)

11 0 Binary Output Change Event - any variation 1(read) 06 (no range, or

all),


11 1 Binary Output Change Event - status without time 1(read) 06 (no range, or

all),



11 1 Binary Output Change Event - status without time 130 (Unsol. Resp.) 17, 28 (index)




11 2 Binary Output Change Event - status with time 1(read) 06 (no range, or

all),



11 2 Binary Output Change Event - status with time 130 (Unsol. Resp.) 17, 28 (index)

12 1 Binary Output Command (CROB) - control relay output

block

3(select) 17, 27,

28 (index)

129 (Response) echo of request


block

4(operate) 17, 27,

28 (index)



block

5(direct op.) 17, 27,

28 (index)



block

6(direct op, no ack) 17, 27,

28 (index)

20 0 Counter - any variation 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

20 0 Counter - any variation 7(freeze) 00, 01 (start-stop),

06 (no range, or

all),


20 0 Counter - any variation 8(freeze, no ack) 00, 01 (start-stop),

06 (no range, or

all),





20 0 Counter - any variation 9(freeze & clear ) 00, 01 (start-stop),

06 (no range, or

all),


20 0 Counter - any variation 10(frz & clr, no ack) 00, 01 (start-stop),

06 (no range, or

all),


20 1 Counter - 32-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

20 2 Counter - 16-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

20 5 Counter - 32-bit without flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

20 6 Counter - 16-bit without flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

129 (Response) 00, 17, 28 (index)




28 (index)

22 0 Counter Change Event - any variation 1(read) 06 (no range, or

all),


22 1 Counter Change Event - 32-bit with flag 1(read) 06 (no range, or

all),



22 1 Counter Change Event - 32-bit with flag 130 (Unsol. Resp.) 17, 28 (index)

22 2 Counter Change Event - 16-bit with flag 1(read) 06 (no range, or

all),



22 2 Counter Change Event - 16-bit with flag 130 (Unsol. Resp.) 17, 28 (index)

22 5 Counter Change Event - 32-bit with flag and time 1(read) 06 (no range, or

all),



22 5 Counter Change Event - 32-bit with flag and time 130 (Unsol. Resp.) 17, 28 (index)

22 6 Counter Change Event - 16-bit with flag and time 1(read) 06 (no range, or

all),



22 6 Counter Change Event - 16-bit with flag and time 130 (Unsol. Resp.) 17, 28 (index)

30 0 Analog Input - any variation 1(read) 00, 01 (start-stop),

06 (no range, or all)




30 1 Analog Input - 32-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

30 2 Analog Input - 16-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

30 3 Analog Input - 32-bit without flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

30 4 Analog Input - 16-bit without flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

30 5 Analog Input - single-precision, floating-point with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

32 0 Analog Input Change Event - any variation 1(read) 06 (no range, or

all),





32 1 Analog Input Change Event - 32-bit without time 1(read) 06 (no range, or

all),



32 1 Analog Input Change Event - 32-bit without time 130 (Unsol. Resp.) 17, 28 (index)

32 2 Analog Input Change Event - 16-bit without time 1(read) 06 (no range, or

all),



32 2 Analog Input Change Event - 16-bit without time 130 (Unsol. Resp.) 17, 28 (index)

32 3 Analog Input Change Event - 32-bit with time 1(read) 06 (no range, or

all),



32 3 Analog Input Change Event - 32-bit with time 130 (Unsol. Resp.) 17, 28 (index)

32 4 Analog Input Change Event - 16-bit with time 1(read) 06 (no range, or

all),



32 4 Analog Input Change Event - 16-bit with time 130 (Unsol. Resp.) 17, 28 (index)

32 5 Analog Input Change Event - single-precision, floating-

point without time

1(read) 06 (no range, or

all),




point without time

130 (Unsol. Resp.) 17, 28 (index)





point with time


all),




point with time


40 0 Analog Output Status - any variation 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

40 1 Analog Output Status - 32-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

40 2 Analog Output Status - 16-bit with flag 1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)

40 3 Analog Output Status - single-precision, floating-point with

flag

1(read) 00, 01 (start-stop),

06 (no range, or

all),


17, 27,

28 (index)

129 (Response) 00, 17, 28 (index)




41 1 Analog Output Block - 32-bit 3(select) 17, 27,

28 (index)


41 1 Analog Output Block - 32-bit 4(operate) 17, 27,

28 (index)


41 1 Analog Output Block - 32-bit 5(direct op.) 17, 27,

28 (index)


41 1 Analog Output Block - 32-bit 6(direct op, no ack) 17, 27,

28 (index)

41 2 Analog Output Block - 16-bit 3(select) 17, 27,

28 (index)


41 2 Analog Output Block - 16-bit 4(operate) 17, 27,

28 (index)


41 2 Analog Output Block - 16-bit 5(direct op.) 17, 27,

28 (index)


41 2 Analog Output Block - 16-bit 6(direct op, no ack) 17, 27,

28 (index)

41 3 Analog Output Block - single-precision, floating-point 3(select) 17, 27,

28 (index)


41 3 Analog Output Block - single-precision, floating-point 4(operate) 17, 27,

28 (index)


41 3 Analog Output Block - single-precision, floating-point 5(direct op.) 17, 27,

28 (index)





41 3 Analog Output Block - single-precision, floating-point 6(direct op, no ack) 17, 27,

28 (index)

42 0 Analog Output Change Event - any variation 1(read) 06 (no range, or

all),


42 1 Analog Output Change Event - 32-bit without time 1(read) 06 (no range, or

all),



42 1 Analog Output Change Event - 32-bit without time 130 (Unsol. Resp.) 17, 28 (index)

42 2 Analog Output Change Event - 16-bit without time 1(read) 06 (no range, or

all),



42 2 Analog Output Change Event - 16-bit without time 130 (Unsol. Resp.) 17, 28 (index)

42 3 Analog Output Change Event - 32-bit with time 1(read) 06 (no range, or

all),



42 3 Analog Output Change Event - 32-bit with time 130 (Unsol. Resp.) 17, 28 (index)

42 4 Analog Output Change Event - 16-bit with time 1(read) 06 (no range, or

all),



42 4 Analog Output Change Event - 16-bit with time 130 (Unsol. Resp.) 17, 28 (index)

42 5 Analog Output Change Event - single-precision, floating-

point without time


all),







point without time



point with time


all),




point with time


50 1 Time and Date - absolute time 1(read)

07 (limited qty = 1)

129 (Response) 07 (limited qty = 1)

50 1 Time and Date - absolute time 2(write)


50 3 Time and Date - absolute time at last recorded time 2(write)


51 1 Time and Date CTO - absolute time, synchronized 129 (Response) 07 (limited qty = 1)

51 1 Time and Date CTO - absolute time, synchronized 130 (Unsol. Resp.) 07 (limited qty = 1)

51 2 Time and Date CTO - absolute time, un-synchronized 129 (Response) 07 (limited qty = 1)

51 2 Time and Date CTO - absolute time, un-synchronized 130 (Unsol. Resp.) 07 (limited qty = 1)

52 1 Time Delay - coarse 129 (Response) 07 (limited qty = 1)

52 2 Time Delay - fine 129 (Response) 07 (limited qty = 1)




60 1 Class Objects - class 0 data 1(read) 06 (no range, or all)

60 2 Class Objects - class 1 data 1(read) 06 (no range, or

all),


60 2 Class Objects - class 1 data 20(enable unsol.) 06 (no range, or all)

60 2 Class Objects - class 1 data 21(disable unsol.) 06 (no range, or all)


all),





all),




80 1 Internal Indications - packed format 1(read) 00, 01 (start-stop) 129 (Response) 00, 01 (start-stop)

80 1 Internal Indications - packed format 2(write) 00 (start-stop)

120 1 Authentication - Challenge 32(auth req) 5B (free format) 131 (Auth. Resp.) 5B (free format)




120 2 Authentication - Reply 32(auth req) 5B (free format) 131 (Auth. Resp.) 5B (free format)

120 3 Authentication - Aggressive Mode any 5B (free format) 129 (Response) 5B (free format)

120 3 Authentication - Aggressive Mode 130 (Unsol. Resp.) 5B (free format)

120 4 Authentication - Session Key Status Request 32(auth req) 5B (free format)

120 5 Authentication - Session Key Status 131 (Auth. Resp.) 5B (free format)

120 6 Authentication - Session Key Change 32(auth req) 5B (free format)

120 7 Authentication - Error 33(auth req, no ack) 5B (free format) 131 (Auth. Resp.) 5B (free format)

120 9 Authentication - HMAC any 5B (free format) 129 (Response) 5B (free format)

120 9 Authentication - HMAC 130 (Unsol. Resp.) 5B (free format)

5 Data Points List (outstation only) This part of the Device Profile shows, for each data type, a table defining the data points available in the device or a description of how this information can be obtained if

the database is configurable.

5.1 Definition of Binary Input Point List: List of addressable points. Points that do not exist (for example, because an option

is not installed) are omitted from the table.

Note: the number of binary inputs present in the device, and the maximum binary

input index, are available remotely using object Group 0 Variations 239 and 238.

Fixed, list shown in table below

Configurable (current list may be shown in table below)

Other, explain:

Binary Input points list:

Point

Index Name

Event

Class

Name for State

when value is 0

Name for State

when value is 1 Description




Assigned

(1, 2, 3 or

none)

5.2 Definition of Double Bit Input Point List: List of addressable points. Points that do not exist (for example, because an option


Note: the number of double-bit inputs present in the device, and the maximum

double-bit input index, are available remotely using object Group 0 Variations 236

and 235.



Other, explain:

Double-bit Input points list:

Point

Index Name

Event

Class

Assigned

(1, 2, 3 or

none)

Name for State

when value is 0

(intermediate)

Name for State

when value is 1

(off)

Name for State

when value is 2

(on)

Name for State

when value is 3

(indeterminate)

Description

5.3 Definition of Binary Output Status / Control Relay Output Block Points

List: List of addressable points. Points that do not exist (for example, because an option


Note: the number of binary outputs present in the device, and the maximum binary

output index, are available remotely using object Group 0 Variations 224 and 223.



Other, explain:

Binary Output Status and CROB points list:

Supported Control Operations

Event Class

Assigned

(1,2,3 or none)

Point

Index Name Select/Operate

Direct

Operate

Direct

Operate

- No

Ack

Pulse

On

Pulse

Off

Latch

On

Latch

Off Trip Close

Count

> 1

Cancel

Currently

Running

Operation

Name

for

State

when

value

is 0

Name

for

State

when

value

is 1

Change Command Description

5.4 Definition of Counter / Frozen Counter Point List: List of addressable points. Points that do not exist (for example, because an option






Note: the number of counters present in the device, and the maximum counter index,

are available remotely using object Group 0 Variations 229 and 228.


Other, explain:

Counter / Frozen Counter points list:

Point

Index Name

Event Class

Assigned to

Counter Events

(1, 2, 3 or none)

Frozen Counter

Exists (Yes or

No)

Event Class

Assigned to

Frozen Counter

Events (1, 2, 3

or none)

Description

5.5 Definition of Analog Input Point List: List of addressable points. Points that do not exist (for example, because an option


Note: the number of analog inputs present in the device, and the maximum analog

input index, are available remotely using object Group 0 Variations 233 and 232.



Other, explain:

Analog Input points list:

. Transmitted Value Scaling .

Point

Index Name

Event

Class

Assigned

(1, 2, 3 or

none)

Min

int / flt

Max

int / flt Multiplier Offset Units Resolution Description

5.6 Definition of Analog Output Status / Analog Output Block Point List: List of addressable points. Points that do not exist (for example, because an option


Note: the number of analog outputs present in the device, and the maximum analog

output index, are available remotely using object Group 0 Variations 221 and 220.



Other, explain:

Analog Output points list:

. Supported Control Operations Transmitted

Value Scaling .

Event Class

Assigned (1, 2, 3

or none)

.

Point Name Select/Operate Direct Direct Min Max Min Max Units Resolution Change Command Description




Index Operate Operate

- No

Ack

5.7 Definition of File Names that may be read or written: Fixed, list shown in table below


Other, explain:

Sequential Files list:

. Authentication

Required for: .

File Name

Event Class

Assigned (1, 2,

3 or none)

Read Write Delete Description

5.8 Definition of Octet String Point List: List of addressable points. Points that do not exist (for example, because an option




Other, explain:

Octet String points list:

Point

Index Name

Event Class

Assigned (1, 2,

3 or none)

Description

5.9 Definition of Virtual Terminal Port Numbers: List of addressable points. Points that do not exist (for example, because an option




Other, explain:

Ports list:

Virtual

Port

Number

Name

Event Class

Assigned (1,

2, 3 or none)

Description




(Point

Index)

5.10 Definition of Data Set Prototypes: List of all data set prototypes. The following table is repeated for each Data Set

Prototype defined.

Note: the number of data set prototypes known to the device are available remotely

using object Group 0 Variations 212 and 213.



Other, explain:

5.11 Definition of Data Set Descriptors: List of all data set descriptors. The following table is repeated for each Data Set

Descriptor defined.

Note: the number of data sets known to the device are available remotely using

object Group 0 Variations 214 and 215.



Other, explain:

5.12 Data Set Descriptors - Point Index Attributes The following table is optional and correlates data set elements to point indexes of standard DNP3 Data Objects. The element number below refers to the position in the

present value object (object 87) or event (object 88) data set and will not match the element number in the data set descriptor or data set prototype tables above.

---------- End of Device Profile for Reference Device ----------

------------------------------- End of Complete Device Profile -------------------------------

Copyright © 2016 QEI



QEI provides a wide variety of Automation Products and services to the Electric Utility Industry. QEI's customers are a mixture of major utilities, government and military agencies as well as global Electrical Transmission and Distribution OEM's.

45 Fadem Road Springfield, NJ USA T: +973-379-7400 F: +973-346-2138

W: www.qeiinc.com

http://www.qeiinc.com/

Documents

QN-901 Q-NET RTU PROTOCOL SERVERS · 2019. 1. 30. · The original LAN-based Qnet product operates with a proprietary protocol to allow bi-directional data exchange and control between