Chapter 3. Protocols

Table of Contents
CDC Synchronous Protocol
ELCOM Protocol
Indactic 33
ICCP Protocol
Landis & Gyr 8479 protocol
RTI Protocol
Redac 70 protocol
AEG A250 PLC driver for FIX


DNP 3.0 over TCP/IP and ethernet

Fri, 17 Jan 1997 17:30:55 -0500

Hi, I'm starting to work on an RTU replacement project and I am thinking about using DNP 3.0 on top of TCP/IP. I've seen some info that sugguests that this is a viable option, so what difficulties has anyone experienced doing this? I remember some past discussion here about the suitability of TCP/IP for control applications, this RTU is used only for data acquistion right now. On the master station end, I'm hoping to acquire unix based software that will run under Solaris on a Sun workstation and convert to NT at a later date. There is some pressure to use NT now for the master station. Any sugguestions here? Thanks, Norm Dang

Re: DNP 3.0 over TCP/IP and ethernet

Mon, 20 Jan 1997 09:28:09 +1000

Norm Dang writes: DNP over TCP/IP is a current topic of discussion for the DNP Technical Committee. There might be a confirmed recommendation coming out of the next meeting in late January. Contact the DNP User Group (and join it) for more info. When in doubt: stick with the standard. As to the suitability of TCP/IP for controls: that's your call. The accountants usually have difficulty understanding why it is so important to pay for a deterministic communications system just to be sure that things happen when you want them to. .

|         Andrew West                .          Foxboro-LN      | 
|    Hardware Group Leader       _--_|\      42 McKechnie Drive  | 
|  Telephone: +61 7 3340 2164   /     *\ -- Eight Mile Plains   | 
|  Facsimile: +61 7 3340 2100   \_,--._/      Queensland 4113    | 
|  Email:        v          Australia       | 

Re: DNP 3.0 over TCP/IP and ethernet

Mon, 20 Jan 1997 09:19:56 +0800

Your subject suggested that you were using ethernet. In this case you can do what you want, but you don't say why you would do this. Implementations of DNP3.0 are relatively easy to find, over TCP/IP would be a custom implementation. Both TCP/IP and DNP 3.0 have appropriate layer 2 protocols and a major issue is resolving how you handle this. Staying with off the shelf solutions is best (preferably based on standards such as DNP 3.0 or IEC870/5 unless there are compelling reasons not to. If there is a possibility that part of your communications would be over radio, either now or in the future, then you need to be more careful, as there are deficiencies in the available layer 2 protocols for TCP/IP and radio, and you would need to have developed some solutions specially for your application. This problem doesn't exist with a straight DNP 3.0 implementation. Implementing TCP/IP over radio without an adequate error detecting and correcting protocol is asking for problems.

Ian Wiese                                
Phone 619 420 2610 Water Corporation of Western Australia   
Fax   619 420 3179                        
Home  619 448 7487

Re: DNP 3.0 over TCP/IP and ethernet

Mon, 20 Jan 1997 18:45:09 -0500

Hi Ian, I have about 80 obselete "FM" type RTUs spread over several hundred square miles. These RTUs are used strictly for data acqusition at electrical transformer stations. Each RTU is connected back to a central data collection site by dual redundant dedicated leased circuits. At the time these FM RTUs were installed, control of the transformer stations was done by on-site personnel or by older "bench board" SCADA systems (20-30 years ago). The operating group is now in a modernization program and is installing DNP ready RTUs (Harris D20s) to be used for station control. At modernized stations there are now 2 RTUs, the new D20 and my old FM. I would like to retire the FM and collect data via a multi ported D20. The most expensive cost of our data acquistion system is the cost of the leased lines. If the D20 is capable of TCP/IP ethernet connection, I could use a commerical frame relay system and standard network communication equipment to transport the data back to the central collection point. This would signicantly lower the the communications cost and provide higher reliability than the dedicated leased circuits. I curious about what to do at the master end. I'm hoping to find an "off the self" unix/NT solution or failing that, a DNP source library so I can insert the data into an existing unix database and then uploading it into a mainframe for processing. Thanks, Norm

Re: DNP 3.0 over TCP/IP and ethernet

Tue, 21 Jan 1997 09:22:01 EST

Just to ride on Ians coat tails, I was the co-chairman of the IETF subcommitte on TCP/IP compression when we put the Internet together and I have seen this same mistake made many times. , TCP was NOT specified as a reliable connection, infact the most common method of load balancing in TCP/IP networks is to discard packets!. It was the upper layer protocols ( NFS, FTP and others) which made the connection reliable, that is error free and would deal with the retransmission of dropped packets. Ditto for Frame relay. The standard method of controlling committed information rate on commercally available ports is to drop packets. Remember Frame relay is not X.25 level III! It has no error correction or guarnateed delivery mechanism. Soo if what you want is DNP 3 over TCP/IP I strongly suggest you use an upper layer protocol to provide the reliable connection for its transport.

Re: DNP 3.0 over TCP/IP and ethernet

Wed, 22 Jan 1997 11:04:47 -0600

DNP 3.0 is a protocol developed by Harris which has been placed in the public domain. This protocol is a subset of the IEC 870-5 protocol. The IEC protocol is widely used in Europe in the Electric Utilities sector. The DNP 3.0 protocol has gained much popularity in the past 2 years in the USA, again mostly in the Electric Utilities sector. The IEC protocol definition defines 3 layers from the ISO 7-layer stack: Physical (Layer 1), Data Link (Layer 2), and Application (Layer 7). In the IEC definition of physical layer we find: RS-232; CCITT V.11, V.24, V.28, etc.; Async; Character (octet) oriented The DNP 3.0 spec adds RS-485 to the transmission medium. I do not see a problem with putting the IEC protocol on Ethernet as the transmission medium. TCP/IP are layers 4 and 3 respectively of the ISO stack. It is common to see TCP/IP on the Ethernet transmission medium. The push lately has been to use standard TCP/IP as a RTU/PLC communications protocol. TCP (Layer 4) is not reliable delivery. Typically, ISO layers 6 or 7 are used to provide reliable delivery mechanisms. In the new GE Series 30/90 PLC for example, the Ethernet interface uses TCP/IP along with some familiar applications (you can 'ping' a GE PLC for example). Harris added a limited Transport (Layer 4) function to the IEC spec to allow data block/file transfers (blocks larger than the max. frame len. defined by the IEC). It supports message assembly and disassembly. Note that some OSI data links are actually "super data link transports" and perform these transport level functions in the data link itself. I might also add that the DNP spec refers to a NETMAN which "provides limited network services...". I said all of this to say the following. Layer 7 of the DNP 3.0 protocol PROVIDES RELIABLE DELIVERY. This is absolutely necessary because DNP (and IEC 870-5) are intended to be used over radio links and other transmission mediums which in no way could provide a connection-oriented (reliable) delivery mechanism. If you want to put DNP 3.0 on TCP/IP, no problem. Disregard the DNP Transport layer (which is pseudo-Transport anyway), and use the TCP to perform the transport functions. Then use the DNP 3.0 data link layer to provide the data link functions. Because the DNP 3.0 application layer provides for extensive error detection and error recovery techniques, the loss of packets from the TCP/IP layers will be discovered and taken care of. As the Harris document says, [this layer] "...ensures the outstation and master station can cope with all occurrences of messages being lost or delayed on a communication network." We have implemented DNP 3.0 here at AccessWare for ABB among others. If anyone desires help in this area, let me know. I can handle simple questions using this forum. We can handle larger requests for a fee... David Joy Director of Applications Engineering AccessWare, Inc.

Ref: c:/emacs/protocols/msg00005.sgml

(Fwd) DNP Test-sets

Fri, 14 Mar 1997 08:19:52 +0800

------- Forwarded Message Follows ------- Date: Thu, 13 Mar 1997 22:18:56 +0800 To: From: Francois Mathieu Subject: DNP Test-sets I am trying to get in touch with vendors of DNP3.0 test sets. If anyone knows of any, can you please post a contact name, e-mail address, fax number, or web-site? Thank-you /francois Systems Analyst, CAE Electronics Ltd.

    DNP3.0 test sets

Re: (Fwd) DNP Test-sets

Fri, 14 Mar 1997 10:50:07 +1000

We have used Applied System's Engineering's DNP Test Set. One of ASE's staff is on the DNP Technical Committee, so the implementation is up to date with any revisions put through by the committee. Contact Jack Verson at or for information.

 |         Andrew West                .          Foxboro-LN      |
 |    Hardware Group Leader       _--_|\      42 McKechnie Drive  |
 |  Telephone: +61 7 3340 2164   /     *\ -- Eight Mile Plains   |
 |  Facsimile: +61 7 3340 2100   \_,--._/      Queensland 4113    |
 |  Email:        v          Australia       |

Ref: c:\scada\031997\msg00001.xml

UCA vs DNP vs IEC870-5

Wed, 7 May 1997 15:35:17 +0000

Hello Anyone has comparative information on these protocols: I don't need specific information, general comparison will do. Regards Nuno J. Nunes

 |  O artista e' um bom artista, nao havia nechechidade... |
 |        Nuno Jardim Nunes - Computer Science Unit        |
 |   Dep. Mathematics - University of Madeira - Portugal   |
 | Address: Largo do Municipio, 9000 - Funchal - Portugal  |
 | Contact: Voice: 351-(0)91-225111, Fax: 351-(0)91-225111 |
 | e-mail :                       |
 | URL    :            |

Re: UCA vs DNP vs IEC870-5

Thu, 8 May 1997 05:40:59 +1000

They all transfer SCADA data, and hence do basically the same thing. The difference is in the detail. Check out the FAQ area at for some answers. Cheers,

 |         Andrew West                .       Foxboro Australia   |
 |  Embedded Systems Engineer     _--_|\      42 McKechnie Drive  |
 |  Telephone: +61 7 3340 2164   /     *\ -- Eight Mile Plains   |
 |  Facsimile: +61 7 3340 2100   \_,--._/      Queensland 4113    |
 |  Email:        v          Australia       |

Re: Unidentified subject!

Sat, 10 May 1997 17:14:02 +1000

Sriend up being very "standard". The thing in favour of Modbus is the "lowest common denominator" effect: It is so simple that almost every manufacturer offers support for some subset of Modbus on most devices. Hence to perform simple functions it may be quite adequate.

 |         Andrew West                .       Foxboro Australia   |
 |  Embedded Systems Engineer     _--_|\      42 McKechnie Drive  |
 |  Telephone: +61 7 3340 2164   /     *\ -- Eight Mile Plains   |
 |  Facsimile: +61 7 3340 2100   \_,--._/      Queensland 4113    |
 |  Email:        v          Australia       |

Ref: c:\scada\051997\msg00018.xml

Re: (Fwd) DNP behaviour questions

Thu, 7 Aug 1997 15:21:19 MDT

Hi Francois, As you may know, I am the secretary of the DNP DNP User's Group Technical Committee. The questions you bring up have been discussed at length in the committee recently. I refer you to the minutes of the last several meetings, which can be found on the DNP web site, The resolution of item (2) has been posted there as a Technical Bulletin. Technical bulletins from the committee represent decisions that have been made but have yet to be incorporated into the DNP documentation. Your item (1) has been resolved (although perhaps not to your satisfaction, judging by your comments) and will be posted as a Technical Bulletin as soon as I can manage it. I have briefly summarized the decisions below: It's still not defined, although I would pick 0. Rather than adding a function code or synchronization procedure that would make some DNP implementations obsolete, the committee chose to increase the security on sequence number checking. Now if the master's first sequence number matches the last one received by the slave, the slave must check the entire message byte-for-byte against the last one received before assuming it is a retransmission. With this and a ban against application layer retries of output operations, confusions regarding sequence numbering can be mostly eliminated. Most masters tend to start up with a poll, in any case. The ruling on this is that a RESET LINK is not required if unconfirmed requests are being used. The sole purpose of the RESET LINK is to synchronize the Frame Count Bits (FCBs). The FCBs are not used for unconfirmed frames, so a RESET LINK is unnecessary and wastes bandwidth. See the web site for the formal text of this decision. The implementations which send a RESET LINK as a result of an application layer timeout certainly provide a viable workaround, but they are "mixing layers" a bit. In my opinion, a RESET LINK should only be sent as the result of a data link layer timeout, not an application layer timeout. Sincerely,

 Grant Gilchrist, P.Eng. 
 GE-HARRIS Energy Control Systems             Tel: (403) 214-4519                              Fax: (403) 287-7946
 4525 Manilla Rd. S.E. Calgary, Alberta, CANADA T2G 4B6
 "Any sufficiently advanced technology is indistinguishable from magic" -Clarke

RE: 870-5-101 Technical Questions

Tue, 19 Aug 1997 01:41:06 -0400

On end of the General Interrogation response with an ASDU type 100 (interrogation command) containing a Cause of Transmission of Activation Termination. The Test command (C_TS_NA_1) can be used to check the communication path to and from the RTU. The IEC 870-5-101 companion standard section defines the fixed test pattern as hexadecimal 55AA. This is a very common test pattern because it translates to a pattern of alternating ones and zeros (binary 01010101 10101010). This may not be a Health Check in the manner you wish, since the RTU is only given the option of not responding instead of responding with some sort of error status. I am not aware of any predefined system status points in IEC 870-5-101. I think you are probably looking for something similar to the DNP Internal Indication Bits returned in each response message to indicate conditions such as device restart, device trouble, local mode, bad configuration, etc.. I would recommend creating Single Point Information (type 1) points for each condition to be monitored. Changes in these points can be sent to the client (master) immediately in a spontaneous transmission. I hope this helps in your understanding of the protocol and let me know if you have any further questions. Best regards, Jim

 Jim F. Coats, Triangle MicroWorks Inc.
 Solutions for Communication Protocol Development
 2213 Middlefield Court    Raleigh, North Carolina  27615   USA
 Phone: +1 (919) 870-6615    Fax: +1 (919) 870-6692
 Web Site:

Ref: c:\scada\081997\msg00000.xml

DNP behaviour questions

Thu, 07 Aug 1997 08:44:11 -0700

Hello all, I've come accross DNP protocol situations where different equipments from different manufacturers seem to behave differently. I'd appreciate the group's input on this.

1. What should be the first application sequence number?

As part of the application control byte, the sequence number is supposed to increment after each successful exchange from the master. If the master sends the same sequence number again in a fragment, this tells the RTU to re-transmit the fragment.

Because of this, at start-up, the RTU and the master must agree about what is the first application sequence number. In other protocols, this is done by some sort of "connect" message, where both sides can reset their initial sequence numbers. In DNP, however, the only connection message is at the link-layer (reset function).

I've seen masters start with sequence number 0, 7, or any number. The master, when it starts up, coule send the number which is telling the RTU to re-send the last fragment.

What should be the first sequence number?

2. Should masters reset the slave on start-up, or whenever communication times out?

When a master is configured to use unconfirmed (at the data link layer) application requests, the master uses the slave's application response as an application message acknowledgement.

But if the RTU is starting-up, it will not respond at all to unconfirmed application requests because it requires a data-link reset first. The RTU cannot send a "NACK" to the master because the master has sent an unconfirmed request.

Some masters (which, in my opinion, behave correctly), time-out on the application request, and eventually (after some retries), send a data-link reset request. This solves the problem.

But I've seen some master stations which, when using unconfirmed requests, refuse to send a data link reset. What can be done?

I've seen masters that, when using unconfirmed requests, start directly with unconfirmed application request, without resetting the data link. If the RTU is starting-up (and requires a reset), it would normally send a NACK if the master had requested a confirmed application request.

 Systems Analyst, CAE Electronics Ltd.

Ref: c:\scada\081997\msg00015.xml

IEC-60870-101 more interoperational than DNP3.0

Mon, 18 Aug 1997 22:27:29 PDT

Hello anyone, There is any expertise can tell me that IEC-60870-101 is more inter-operational than DNP3.0. As far I know aboutDNP 3.0, there are some undefined behaviors that might cause inter-operational problems among different vendors. Does the IEC-60870-101/102 have the similar features ? Jim Cai ______________________________________________________ Get Your Private, Free Email at

Ref: c:\scada\081997\msg00025.xml