Dnp v3.00 and Iec 60870-5-101 Implementations in Intelligent

Nu-lec Pty Ltd DNP V3.00 and IEC60870-5-101

of 21

DNP V3.00 and IEC 60870-5-101 IMPLEMENTATIONS ININTELLIGENT ELECTRICAL DEVICES (IEDs)

O’Sullivan Neil;Mikli, Lauri.

NU-LEC PTY LTD

1. Summary

This paper looks at a manufacturer’s slave implementation of both DNP V3.00 and

IEC60870-5-101 communications protocol in intelligent electrical devices (IEDs) and

makes a comparison of the advantages and disadvantages from the perspective of this

manufacturer.

2. Introduction

Rationalisation and privatisation in the global electrical distribution industry is forcing

utilities to consider new ways to optimise their business from both a performance and

cost perspective. Utilities are increasingly required to meet the performance criteria

set by the regulators of these newly privatised companies. This is making remote

control and automation of their distribution networks a real necessity if they are to

meet these requirements.

Distribution utility regulators are tending to apply several benchmarked criteria and

performance indicators on electricity distribution utilities. These performance criteria

directly reflect how profitable a utility is and also form the basis for their regulation.

This manufacturer recognised this trend almost a decade ago and began developing a

range of pole mounted Intelligent Electronic Devices (IED’s) with a range of features

and functionality designed to help the modern electricity utility meet these criteria.

This paper discusses the two main open architecture protocols to emerge from the

proprietary communications era. Of these two, DNP was largely influenced by North

and South America, together with the African and Asian regions, while 60870-5-101

has been heavily influenced by the European community. Both of these protocols are

specified, developed and controlled by regulatory committees to ensure they allow


of 21

inter-operability between different implementor’s equipment. These regulatory groups

are the DNP V3.00 User Group and International Electrotechnical Commission (IEC)

60870-5 Technical Committee 57 Working Group 03.

3. Reporting Model

Whilst this paper looks at slave implementations of these protocols it is important to

choose the protocol network topology which best supports the electricity utility’s

needs. Points to consider are the communications medium, network topology and

whether continuous polling or report by exception / unsolicited reporting is required.

One example of this is a situation where a utility wants to control and monitor their

entire population of IED’s but don’t have the necessary bandwidth or VHF/UHF radio

coverage to use continuous polling under all system conditions. To get around this

limitation they may want to utilise a combination cellular, satellite or dialup landline

to communicate with remote IED’s. At present the best solution would be to use

DNP’s balanced transmission, report by exception communications. 60870-5-101

does support balanced transmission, report by exception communications but it is

limited to point to point communications only. It would not be suitable for the above

multi-drop, multiple communications media situations.


of 21

4. Protocol Architecture

Both DNP and 60870-5-101 use a simplified 3 layer version of the Open System

Interconnection (OSI) 7 layer reference model known as the Enhanced Performance

Architecture (EPA). It is important to know this basic design in order to understand

the various terminology and principles involved with using either protocol.

Layer

7 Application <=> Application

6 Presentation

5 Session

4 Transport (DNP Transport)

3 Network

2 Link <=> Link

1 Physical <=> Physical

OSIReference

Model

EnhancedArchitecture Model

Performance

4.1 Physical Layer

The physical layer refers to the physical media over which the protocol is transmitted.

This is usually a physical medium such as RS-232, RS-485 or V23 FSK using media

such as fibre, radio or satellite.

Examples of its functions are handling the state of the media (eg collision detection)

and transmission controls (eg RTS/CTS) to ensure synchronisation successful transfer

of data.

Currently both protocols are in the process of developing standards of behaviour for

each protocol on networks such as Ethernet.


of 21

4.2 Link Layer

The link layer provides a logical link between the sender and receiver of data. It also

provides mechanisms to determine and overcome, physical layer error characteristics

such as noise.

The 60870-5-1 standard defines four different frame types for the link layer. Both

protocols make use of one of these.

60870-5-1

Frame Type

Hamming

Distance

(error bits)

Security Maximum

Length

(bytes)

IEC60870-5-101 FT1.2 4 8 bit checksum 255

DNP V3.00 FT3 6 16 bit CRC 255

As can be seen in the table above, both protocols transmit identical maximum length

messages but the DNP protocol has a higher hamming distance. This means that with

DNP two more single bit errors must occur than in 60870-5-101 before a corrupted

message will be mistakenly identified as a healthy message.

The frame type determines the link level functions and characteristics available for

each protocol:

• Message start and end identification bytes

• Destination and Source Addressing (up to 65534 addresses for DNP and a varying

address field size for IEC which allows for up to 16777215 addresses).

• Message Length Information

• Error detection using Cyclic Redundancy Checking (CRC) and Checksums

• Link services. These include message handling abilities such as:

1. Reset link

2. Reset user application

3. Link level Send/Confirm service

4. Link Status Requests


of 21

4.3 DNP Pseudo-Transport Layer

The DNP protocol varies from the EPA 3 layer model by adding a fourth layer - a

pseudo-transport layer. The pseudo-transport layer segments application layer

messages into multiple link messages and provides a segment tracking mechanism.

60870-5-101 limits the size of its application layer messages to that of the link layer

(255 bytes) and hence does not require transport layer fragmentation.

4.4 Application Layer

The application layer builds messages based on the need for, or the availability of,

user data. Once messages are built, they are passed down to the data link layer and

eventually communicated over the physical layer.

The application layer uses function codes to indicate the purpose, or requested

operation, of the message. The functions include:

• Reporting - Polled report by exception, Unsolicited Responses

• Time Synchronisation

• Read/Write message identification

• Digital Control Commands eg Select before Operate, Direct Operate

• Freeze and Clear commands for counters

• Time-stamped events

• Data Groups/classes

5. DNP V3.00 Subset Levels

The DNP protocol was designed as a generic SCADA data protocol and by its nature

therefore contains a very large suite of data object types. Historically it was possible

for both a master vendor and an IED vendor to claim support for the DNP protocol

without the devices being able to fully communicate with one another. For example,

one implementation might process analogs using one type of DNP analog object

format, which is specifically applicable to its implementation, while the other device

may be using another analog format. No data transfer is possible despite both devices

using valid DNP data formats. To combat this problem, and preserve the open

standards philosophy, the DNP User Group defined three levels of implementation


of 21

that established a minimum set of behavioural rules and data objects types supported

by a device. The size and nature of the device determines the appropriate level that

should be supported by the vendor. 60870-5-101 does not have any predefined

subsets. It relies solely on interoperability tables that we will explain later.

5.1 Level 1

This is the simplest implementation of DNP. It is intended for use between a master

station or data concentrator and a small end device (eg. Meter, relay or capacitor bank

controller). The input and output points of the slave devices are typically local to the

device.

5.2 Level 2

This level of implementation defines a slightly larger subset of DNP features than the

Level 1 implementation. It is intended to be used between a master station or data

concentrator and either a large IED or a small Remote Terminal Unit (RTU). Like

level 1 implementations, the input and output points of the slave device would be

local to the device. The functionality available in the Nu-Lec Optimised Family of

products require Level 2 functionality.

5.3 Level 3

This level of implementation is the largest subset of DNP. It does not cover all DNP

features but does contain the majority of useful, popular items. It is intended for use

between a master and a medium size slave device (e.g. RTU, Data Concentrator).

There are not yet many slaves with full level 3 compliance in the market place. The

input and output points in level 3 implementations are both local and remote. Remote

points are usually obtained via serial links to external devices.

6. IEC 60870-5-101 and its companion standards.

From these writers perspective, there appears to be much confusion in relation to IEC

companion standards 60870-5-101 and 60870-5-103. We believe some of this

confusion arises because DNP3 is specified in three levels and anyone who


of 21

understands DNP naturally assumes 60870-5-101 has a similar set of levels and subset

level functionality. This is not the case. The 60870-5-103 companion standard is an

extension, not a subset, of the 60870-5-101 standard and is designed for specific use

in data interchange between protection equipment and a substation control system.

The 60870-5 standard for Transmission Protocols consists of five basic parts (60870-

5-1 to 5) and a set of companion standards (eg 60870-5-101 and 103). The diagram

below highlights the roles of each part in defining 60870-5.

User Telecontrol

Process Layer

IEC 60870-5-103 Informative Interface of Protection Equipment

IEC 60870-5-101 Basic Telecontrol Tasks

IEC 60870-5-5 Basic Application Functions

Application Layer IEC 60870-5-4 Definition and Coding of Application Information Elements

IEC 60870-5-3 General Structure of Application Data

Datalink Layer IEC 60870-5-2 Link Transmission Procedures

Physical Layer IEC 60870-5-1 Transmission Frame Format

EPA Model

The 60870-5-101 Companion Standard for Basic Telecontrol Tasks defines a set of

data types and services, as detailed in 60870-5-1 to 5, that are suitable for telecontrol

systems eg a substation control system. These data types are generic and include data

such as single and double binary point statuses and commands, counters, analogs and

set-points.

The 60870-5-103 Companion Standard for the Informative Interface of Protection

Equipment includes more detail than 60870-5-101. It extends the set of data types and

services by defining specific data types formats and communication behaviour for

distance protection, transformer differential protection and line differential protection.

These data types can include combined digital and analog data like currents, voltages,

fault indications and disturbance data.


of 21

7. Device Interoperability

To aid end users with the integration of devices, and early identification of problems

such as the one outlined in the DNP subset section, both protocols have incorporated

detailed compliance tables in their standards. These tables provide a standard format

for easy checking of the functions and data types supported by an implementation.

The DNP protocol breaks down its compliance tables into two parts. The Device

Profile document defines compliance with various application and link layer issues

such as implementation level and deviations from the basic level criteria. The

Implementation Table defines the data objects and message types supported by the

device. An example of a Level 2 DNP V3.00 Device Profile for the Nu-lec N Series

Recloser is located in Appendix A. Its companion implementation table is given in

Appendix B.

The 60870-5-101 refers to its compliance tables as its Interoperability Statement. It

contains information about the device’s support of all EPA layers. This information

includes data such as supported network configuration, transmission details, link

transmission procedure, and implemented data objects. An example of an 60870

Interoperability Statement for the Nu-lec N Series Recloser is given in Appendix C.

8. Protocol Compliance Testing

7.1 DNP Testing

It is our opinion that one of DNP communications protocol’s strengths are the very

detailed compliance certification test procedures produced and maintained, by the

DNP V3.00 user group. These are currently available for slave implementation levels

1 and 2. From an end user’s perspective, this allows them to specify a DNP V3.00

Level 1 or 2 (at this time) implementation that has been fully compliance tested to the

DNP V3.00 user group’s certified compliance test procedures. They can be sure these

implementations have been tested and certified by a third party and will interface

correctly to DNP master implementations that meet the DNP master standards. It

should be noted that the certification of a device only proves it is protocol compliant.


of 21

It does not certify operation of the device nor does it certify the point list of the

device.

The test procedures cover the following areas in brief:

1.Pretest Review2. Link Layer

2.1 Reset Link and Passive Confirm support2.2 Test Link2.3 Request Link Status2.4 Test Retries

3.Transport Layer3.1 Desired Behaviour

4.Application Layer4.1 Binary Output Status4.2 Binary Outputs4.3 Analog Output Status4.4 Analog Outputs4.5 Class Data4.6 Indications4.7 Time4.8 Cold Restart4.9 Binary Input4.10 Binary Input Change4.11 Binary Counters4.12 Binary Counters, Event4.13 Analog Input4.14 Analog Change Event

7.2 60870-5-101 Testing

At present testing is a weakness of the 60870-5-101 protocol because there are

currently no official certification procedures available. It is expected this situation

will change as the protocol becomes more commonly used and adopted by both

master station and IED vendors. When this happens a certification testing procedure

will become essential. At this time testing is mainly provided by a company called

KEMA, located in the Netherlands. It is popularly considered the de-facto acceptable

certification body although there are others. The best way for a user to ensure a

specific slave manufacturer’s 60870-5-101 implementation is acceptable, is to

compliance test it with their specific master station implementation. This would

normally be achieved by using a master station simulator from the master station

manufacturer.


of 21

9. Comparison Between DNP V3.00 and IEC60870-5-101

This section lists the similarities and differences between the DNP and 60870-5-101

protocols3.

8.1 General

The protocols have many similarities in their functionality. Each permits:

• Collection of binary (digital) data

• Collection of analogue data

• Collection, freezing and clearing of counters

• Single pass or two-pass control of binary (digital) outputs

• Single pass or two-pass control of analog outputs

• Reporting of binary and analog events (report by exception)

• Time synchronisation

• Time-stamping events

• Grouping data objects

• File Transfer

Both protocols permit polling for all data (this is normally done at startup to collect

the initial state of the slave), and subsets of data. Both normally operate by only

collecting events (changes) from the field.

8.2 Differences

• DNP does not conform exactly to the frame format specified by the IEC: The DNP

frame adds start and stop bits to each octet of the FT3 frame format (using a 16-bit

CRC) to allow the use of standard asynchronous data communications equipment.

The IEC chose to use the less-secure FT1.2 (which already includes start and stop

bits) for 101 so that they would not need to specify a new frame format.

• DNP only uses balanced link services. 60870-5-101 may use balanced or

unbalanced services.


of 21

• DNP supports only a single addressing format. 60870-5-101 allows most of the

options specified in 60870-5-2. The DNP addressing format supports peer-to-peer

operation, the 101 format does not.

• DNP introduces a pseudo-transport layer (OSI layer 4) to build application data

messages larger than a single data link frame. Each 60870-5-101 message must be

contained in a single data link frame.

• DNP permits more than one object type to appear in a message. 60870-5-101 only

permits a single object type in a message.

• DNP requires an application layer message to contain a poll request (or any other

command). Polling in 60870-5-101 can be triggered by a link-layer message

containing no application data.

• 60870-5-101 includes a concept of “Cause of transmission” not included in DNP.

This permits a 60870-5-101 device to cause data to become available (pseudo-

events) for a larger number of reasons than available to a DNP device.

• DNP groups data into four classes. This may be used to prioritise event reporting.

One class is for “static” data: current values of inputs; the other three are for

“event” data: reporting changes. All four classes may be requested simultaneously.

IEC groups data into two classes, and while not explicitly stated in the 60870-5-

101 standard, one class is intended for “cyclic” data, and the other class is for all

other data. Only one class or the other may be requested in a single poll. The

device indicates in the link layer which class should be polled for next.

• DNP supports unsolicited reporting using a collision-avoidance mechanism for

multi-drop systems. 60870-5-101 only permits unsolicited reporting on point-to-

point links where collision is impossible.

• DNP relies on the data link address to identify the source of the application data.

60870-5-101 uses the data link address to identify where the frame should be

delivered, and includes the data addresses within the application data.

• Because DNP allows more than one data type in a message, it includes more

complex data type and identity information in the application data than 60870-5-

101. Hence parsing a DNP message is more complex than parsing a 60870-5-101

message.


of 21

• DNP defines a number of implementation subsets that simplify determining if

equipment will interoperate. Each DNP device vendor indicates which DNP

objects and functions are supported in a standard-format "Device profile". The

intent of this is to maximise the likelihood that devices from different vendors will

work together with minimal configuration. 60870-5-101 includes an

interoperability chapter defining how a vendor indicates which objects and options

are implemented. There are no defined subsets. This requires careful analysis to

ensure that devices will work together or can be configured to work together.

• DNP is maintained by the technical committee of the DNP User Group. This body

provides information about the protocol, and clarifies ambiguous areas of the

protocol definition. The IEC does not provide information to clarify the

interpretation of its standards. Questions are best addressed to a vendor of a

product that supports 60870-5-101.

8. Conclusion

Both DNP V3.00 and IEC 60870-5-101 communications protocols go a long way to

solving the interoperability problems common in previous generations of remote

control systems. Selecting the correct protocol for your utility depends very much on

your SCADA master system’s ability to support one or both of these protocols and

your network topology. In fact, there would be benefits to ensure both protocols are

supported by their Master stations. This would provide the absolute maximum in

flexibility of choice when interfacing to IEDs. It is obvious from this paper that the

IEC60870-5-101 protocol has still not matured to the same level as DNP V3.00 but

this is coming.


of 21

References

1. International Standards

Telecontrol equipment and systems – Part 5: Transmission Protocols:

Section 1 - Transmission Frame Format,

Section 2 - Link Transmission Procedures,

Section 3 - General Structure of Application Data,

Section 4 - Definition and Coding of Application Information Elements,

Section 5 - Basic Application Functions,

Section 101 - Basic Telecontrol Tasks,

Section 103 – Informative Interface of Protection Equipment,

International Electrotechnical Commission Publication 870-5-101: 1995.

2. DNP V3.00 “Basic 4”: Data Link Layer, Transport Functions, Application

Layer and Application Object Library; Subset Definitions.

3. West. Andrew, C. – Triangle Microworks Inc. “Communications Standards in

Power Control”.


of 21

4.

Appendix A

DNP V3.00 Device Profile

The DNP V3.00 device profile defines the mapping of all data points used, in the standard formatrecommended by the DNP users group.



Vendor Name: Nu-Lec P/L,Brisbane, Australia Device Name: CAPM-4 Controller

Highest DNP Level Supported

For Requests: 2 For Responses: 2

Device Function: Slave

Conforms to DNP V3.00 level 2 subset definition requirements with many additional level 3 featuresbuilt in.

These extra features include the parsing of read requests (FC 1) for the following objects and/orqualifiers:• Binary Input (Object 1 Variations 0 Qualifiers 00, 01)• Binary Input (Object 1 Variation 1 Qualifiers 00, 01, 06)• Binary Output (Object 10 Variation 0 Qualifiers 00, 01)• Binary Output (Object 10 Variation 2, Qualifiers 00, 01, 06)• Binary Counter (Object 20 Variation 6 Qualifiers 00, 01, 06)• Frozen Counter (Object 21 Variation 10 Qualifiers 00, 01, 06)• Analogue Input (Object 30 Variation 0, Qualifiers 00, 01)• Analogue Input (Object 30 Variations 1, 2, 3, 4 Qualifiers 00, 01, 06)• Analogue Change Event (Object 32 Variations 1, 2 Qualifiers 06, 07, 08)• Analogue Output Status (Object 40 Variation 1, 2 Qualifiers 00, 01)• Analogue Output Block (Object 41 Variation 1, 2 Qualifiers 00, 01, 07, 08, 17, 28)

Also, the following functions are included:• Function codes 7, 8, 9, 10 for Binary Counters (Object 20 Variation 6)• Function code 14, Warm Restart• Function code 20, Enable Unsolicited Messages• Function code 21, Disable Unsolicited Messages• Function code 22, Assign Data Classes


of 21

Maximum Data Link Frame Size (octets):

Transmitted: 292 Received: 292

Maximum Application Fragment Size (octets):

Transmitted: 2048 Received: 249

Maximum Data Link Retries: Configurable 0..255

Maximum Application Layer Retries: None

Requires Data Link Layer Confirmation:

Configurable, 3 settings Never, Always, Sometimes (on multi frame fragments only)

Requires Application Layer Confirmation:

Sometimes (only when reporting event data or when sending multifragment responses)

Timeouts while waiting for: Data Link Confirm: Configurable Application Confirm: Configurable Need Time Delay: Configurable Select Operate Delay: Configurable Unsolicited Response Notification: Configurable Unsolicited Response Retry Delay: ConfigurableTimeouts not supported:Complete Appl. Fragment: NoneComplete Appl Response: NoneExecutes Control Operations:

WRITE Binary Outputs: Never SELECT/OPERATE: Always DIRECT OPERATE: Always DIRECT OPERATE - NO ACK: Always

Pattern control operations are not supported

WRITE Analogue Outputs: Never SELECT/OPERATE: Always DIRECT OPERATE: Always DIRECT OPERATE - NO ACK: Always

Maximum Select/Operate Delay Time: Configurable 1 .. 65535 ms

Count > 1: Never Pulse On: Always Pulse Off: Never Latch On: Always Latch Off: Always Trip/Close: Sometimes Raise/Lower: Never Queue: Never Clear Queue: Never

Pulse On and Pulse Off times are ignored

Reports Binary Input Change Events when nospecific variation requested:

Configurable with / without time

Reports time tagged Binary Input Change Eventswhen no specific variation requested:

Binary Input Change with Time

Sends Unsolicited Responses: Enable/Disable Unsolicited supported

Static Data in Unsolicited Responses:Never

Supports Collision Avoidance:Configurable

Collision Avoidance Detection Method:DCD


of 21

Default Counter Object:Default Object: 20Default Variation: 06

Counter Roll Over at: 65535

Sends Multi-Fragment Responses: Yes


of 21

Appendix B

DNP V3.00 Implementation Table for a Nu-Lec N SeriesRecloser

OBJECT REQUEST(slave must parse)

RESPONSE(master must parse)

Obj Var Description Func Codes(dec)

Qual Codes(hex)

FuncCodes

QualCodes(hex)

1 0 Binary Input - All Variations 1 22 00, 01 06 N/A N/A

1 1 Binary Input 1 00, 01, 06 129 00, 012 0 Binary Input Change - All

Variations1 06, 07, 08 N/A N/A

2 1 Binary Input Change without Time 1 06, 07, 08 129, 130 17, 282 2 Binary Input Change with Time 1 06, 07, 08 129, 130 17, 282 3 Binary Input Change with Relative

Time1 06, 07, 08 N/A N/A

10 0 Binary Output - All Variations 1 00, 01 06 N/A N/A

10 2 Binary Output Status 1 00, 01, 06 129 00, 0112 1 Control Relay Output Block 3, 4, 5, 6 17, 28 129 Echo of

request

20 0 Binary counter – All Variations 1,7,8,9, 10 22 00, 01 06 N/A N/A

20 6 16 Bit Binary Counter without flag 1 00, 01, 06 129 00, 0121 0 Frozen Counter – All variations 1 22 00, 01 06 N/A N/A

21 10 16 Bit Frozen Counter without flag 1 00, 01, 06 129 00, 0130 0 Analogue Input - All Variations 1 22 00, 01 06 N/A N/A

30 1 32 Bit Analogue Input 1 00, 01, 06 129 00, 0130 2 16 Bit Analogue Input 1 00, 01, 06 129 00, 0130 3 32 Bit Analogue Input without Flag 1 00, 01, 06 129 00, 0130 4 16 Bit Analogue Input without Flag 1 00, 01, 06 129 00, 0132 0 Analogue Change Event - All

Variations1 06, 07, 08 N/A N/A

32 1 32 Bit Analogue Change Eventwithout Time

1 06, 07, 08 129, 130 17, 28

32 2 16 Bit Analogue Change Eventwithout Time

1 06, 07, 08 129, 130 17, 28

32 3 32 Bit Analogue Change Eventwith Time

1 06, 07, 08 129, 130 17, 28

32 4 16 Bit Analogue Change Eventwith Time

1 06, 07, 08 129, 130 17, 28

40 0 Analogue Output Status - AllVariations

1 00, 01 06 N/A N/A

40 1 32 Bit Analogue Output Status 1 00, 01, 06 129 00, 0140 2 16 Bit Analogue Output Status 1 00, 01, 06 129 00, 0141 1 32 Bit Analogue Output Block 3, 4, 5, 6 00, 01, 07, 08,

17, 28129 Echo of

request

41 2 16 Bit Analogue Output Block 3, 4, 5, 6 00, 01, 07, 08, 129 Echo ofrequest


of 21

OBJECT REQUEST(slave must parse)

RESPONSE(master must parse)

Obj Var Description Func Codes(dec)

Qual Codes(hex)

FuncCodes

QualCodes(hex)

17, 282 07

(quantity = 1)N/A N/A50 1 Time and Date

1 07(quantity = 1)

129 07, (quantity1)

52 2 Time Delay Fine N/A N/A 129 07, (quantity1)

60 1 Class 0 Data 1 06 N/A N/A

160 2 Class 1 Data20,,21, 22

06, 07, 08 N/A N/A

160 3 Class 2 Data20, 21, 22

06, 07, 08 N/A N/A

160 4 Class 3 Data20, 21, 22

06, 07, 08 N/A N/A

80 1 Internal Indications 2 00 index = 7 N/A N/A

No Object 13 14 23 N/A N/A N/A

Note1. All shaded areas are the additional level 3 or above function, objects, variations and/or

qualifiers supported by CAPM.2. Bold italics response function codes represent CAPM default objects. These are the object

variations that the CAPM will issue as in its response to an event (class 1, 2, 3) or integrity(class 1, 2, 3, 0) poll, or in a response to a variation 0 read request, or in an unsolicitedresponse message. Where more than one data object variation is highlighted then defaultobject can be configured.

3. All Request and Response options marked N/A are not applicable.

DNP Function CodesRequest Response

FunctionCode

Description FunctionCode

Description FunctionCode

Description

1 Read 9 Freeze and Clear 129 Response2 Write 10 Freeze and Clear, No Ack3 Select 13 Cold Restart

130 UnsolicitedResponse

4 Operate 14 Warm Restart5 Direct Operate 20 Enable Unsolicited Msgs6 Direct Operate, No Ack 21 Disable Unsolicited Msgs7 Immediate Freeze 22 Assign Class8 Immediate Freeze, No Ack 23 Delay Measurement


of 21

Appendix C

IEC 60870 Interoperability Statement for a Nu-Lec NSeries RecloserNetwork configuration⌧ Point-to-point ⌧ Multipoint-party line

� Multiple point-to-point � Multipoint-star

Physical layerTransmission speed (control direction)Unbalanced interchange Unbalanced interchange Balanced interchangecircuit V.24/V.28 circuit V.24/V.28 circuit X.24/X.27Standard Recommended if >1 200 bit/s� 100 bit/s ⌧ 2400 bit/s � 2400 bit/s � 56000 bit/s� 200 bit/s ⌧ 4800 bit/s � 4800 bit/s � 64000 bit/s⌧ 300 bit/s ⌧ 9600 bit/s � 9600 bit/s⌧ 600 bit/s � 19200 bit/s⌧ 1200 bit/s � 38400 bit/s

Transmission speed (monitor direction)Unbalanced interchange Unbalanced interchange Balancedinterchangecircuit V.24/V.28 circuit V.24/V.28 circuit X.24/X.27Standard Recommended if >1 200 bit/s� 100 bit/s ⌧ 2400 bit/s � 2400 bit/s � 56000 bit/s� 200 bit/s ⌧ 4800 bit/s � 4800 bit/s � 64000 bit/s⌧ 300 bit/s ⌧ 9600 bit/s � 9600 bit/s⌧ 600 bit/s � 19200 bit/s⌧ 1200 bit/s � 38400 bit/s

Link layerFrame format FT 1.2, single character 1 and the fixed time out interval are used exclusivelyin this companion standard.Link transmission procedure Address field of link� Balanced transmission � Not present (balanced

transmission only)⌧ Unbalanced transmission ⌧ One octet

⌧ Two octetsFrame length � Structured 255 Maximum length L (number of octets) ⌧ Unstructured


of 21

Application Layer

Transmission mode for application dataMode 1 (Least significant octet first), as defined in clause 4.10 of IEC 870-5-4, is usedexclusively in this companion standard.

Common address of ASDU⌧ One octet ⌧ Two octets

Information object address

� One octet � structured

⌧ Two octets ⌧ unstructured

� Three octets

Cause of transmission⌧ One octet � Two octets (with originator address)

Selection of standard ASDUs

Process information in monitor direction⌧ <1> := Single-point information M_SP_NA_1

⌧ <2> := Single-point information with time tag M_SP_TA_1

⌧ <3> := Double-point information M_DP_NA_1

⌧ <4> := Double-point information with time tag M_DP_TA_1

� <5> := Step position information M_ST_NA_1

� <6> := Step position information with time tag M_ST_TA_1

� <7> := Bitstring of 32 bit M_BO_NA_1

� <8> := Bitstring of 32 bit with time tag M_BO_TA_1

⌧ <9> := Measured value, normalised value M_ME_NA_1

⌧ <10> := Measured value, normalised value with time tag M_ME_TA_1

⌧ <11> := Measured value, scaled value M_ME_NB_1

⌧ <12> := Measured value, scaled value with time tag M_ME_TB_1

� <13> := Measured value, short floating point value M_ME_NC_I

� <14> := Measured value, short floating point value with time tag M_ME_TC_1

⌧ <15> := Integrated totals M_IT_NA_1

� <16> := Integrated totals with time tag M_IT_TA_1

� <17> := Event of protection equipment with time tag M_EP_TA_1

� <18> := Packed start events of protection equipment with time tag M_EP_TB_1

� <19> := Packed output circuit information of protection equipment with time tag M_EP_TC_1

� <20> := Packed single-point information with status change detection M_PS_NA_1

� <21> := Measured value, normalised value without quality descriptor M_ME_ND_1

Process information in control direction⌧ <45> := Single command C_SC_NA_1


of 21

⌧ <46> := Double command C_DC_NA_1

� <47> := Regulating step command C_RC_NA_1

� <48> := Set point command, normalised value C_SE_NA_1

� <49> := Set point command, scaled value C_SE_NB_1

� <50> := Set point command, short floating point value C_SE_NC_1

� <51> := Bitstring of 32 bit C_BO_NA_1

System information in monitor direction⌧ <70> := End of initialisation M_EI_NA_1

System information in control direction⌧ <100> := Interrogation command C_IC_NA_1

⌧ <101> := Counter interrogation command C_CI_NA_1

⌧ <102> := Read command C_RD_NA_1

⌧ <103> := Clock synchronisation command C_CS_NA_1

� <104> := Test command C_TS_NB_1

⌧ <105> := Reset process command C_RP_NC_1

⌧ <106> := Delay acquisition command note 1 C_CD_NA_1

Parameter in control direction⌧ <110> := Parameter of measured value, normalised value P_ME_NA_1

⌧ <111> := Parameter of measured value, scaled value P_ME_NB_1

� <112> := Parameter of measured value, short floating point value P_ME_NC_1

� <113> := Parameter activation P_AC_NA_1

File transfer� <120> := File ready F_FR_NA_1

� <121> := Section ready F_SR_NA_1

� <122> := Call directory, select file, call file, call section F_SC_NA_1

� <123> := Last section, last segment F_LS_NA_1

� <124> := Ack file, ack section F_AF_NA_1

� <125> := Segment F_SG_NA_1

� <126> := Directory F_DR_TA_1

Basic application functions

Station initialisation⌧Remote initialisation

General Interrogation⌧ global

� group 1 � group 7 � group 13

� group 2 � group 8 � group l4



of 21


� group 5 � group 11

� group 6 � group 12

Clock synchronisation⌧ Clock synchronisation

Command transmission⌧ Direct command transmission

⌧ Select and execute command

� Direct set point command transmission

� Select and execute set point command

� C_SE_ACTTERM used

� No additional definition

⌧ Short pulse duration

⌧ Long pulse duration

⌧ Persistent output

Transmission of Integrated totals⌧ Counter request � General request counter

⌧ Counter freeze without reset � Request counter group 1

⌧ Counter freeze with reset � Request counter group 2

⌧ Counter reset � Request counter group 3

� Request counter group 4Parameter loading⌧ Threshold value

� Smoothing factor

⌧ Low limit for transmission of measured value

⌧ High limit for transmission of measured value

Parameter activation� Act/deact of persistent cyclic or periodic transmission of the addressed object

File transfer� File transfer in monitor direction

� File transfer in control direction

Dnp v3.00 and Iec 60870-5-101 Implementations in Intelligent

Documents

Transcript of Dnp v3.00 and Iec 60870-5-101 Implementations in Intelligent