Chapter 2. Communications

Table of Contents
GSM
Modems
Terminal Servers
X.25
Inmarsat-C
Data Radio
What is multicast?
Power line carrier
PLC Communications
Protocol converter
Integration of SCADA Data and Voice

GSM

RTU suppliers

Being a member of a company that supplies SCADA systems, mainly for electric utilities, and since we are evaluating developing a new RTU or integrating a RTU from a different supplier, I?d be interested on receiving information about suppliers of RTUs and the specifications of their RTUs (pole mount and substation) . Best regards Antonio Carrapatoso

 EFACEC Sistemas de Electronica S.A..
 Rua  Eng. Frederico Ulrich
 Apartado 3078
 P4470 MOREIRA MAIA
 PORTUGAL
 
 Phone - 351 2 9402000
 Fax - 351 2 9485428
 e-mail - amc@efacecse.mailpac.pt

Re: RTU suppliers

Tue, 18 Mar 1997 12:15:41 -0600

There are several suppliers of RTUs in the Remote Terminal Units (RTU) category of the Products directory of the ElectricNet OnLine Directory at http://www.electricnet.com Antonio Carrapatoso wrote: --

 Bob Libbey
 rlibbey@electricnet.com
 ElectricNet OnLine Directory
 http://www.electricnet.com
 Tel: 972-298-2333    Fax: 972-298-2322

RE: RTU suppliers

Tue, 18 Mar 1997 12:17:27 -0600

The best RTU supplier by far is GE-Harris (formally Westronics) in Calgary Canada. We have used their RTUs in all of our projects and I am continually amazed how versatile their D20 family of RTUs is. Their pole mounted RTU known as the DART, is one of the only poletop RTUs I know that supports transducerless measurements, that is connect directly to the CTs and PTs (Voltage Transformer). The DART uses DSP technology to calculate additional parameters such as phase, power factor, power, energy, etc. The DART can also be used to do fault detection and isolation. GE-Harris have a range of distributed I/O modules which connect to a high speed link in the substation which reduces the cost of installation by reducing labor and wiring. One of the I/O modules, the D20AC module permits transducerless measurements in the substation. Think of the cost savings if you could eliminate most transducers in a substation. Their latest product the D25 is probably their most amazing product yet. I won't attempt to describe this product as it does so many things. GE-Harris has a large protocol library which allows the D20/D200 RTU to talk to most IED (Intelligent Electronic Devices) such as protection relays, revenue meters, PLCs, other RTUs, etc. What I like most about the D20 family is its ability to scale from a small RTU to a very large RTU without having to throw anything away. When you decide to implement Substation Automation, you use the same hardware and simply add applications and protocols. GE-Harris has a large range of Substation Automation applications and I believe they are the number one suppliers of RTUs and Substation Automation solutions in the world. Companies such as Siemens, ABB, and others have supplied D20 RTUs in many of their projects. Anyone interested should contact GE-Harris directly. The GE-Harris person to contact is Gary Moore at garym@hdap.com or phone Canada (403) 243-3335 Regards

 John Synesiou			jsynesio@us-power.com
 U.S. Power, Inc			Phone (612)826-1111
 6497 City West Parkway	Fax   (612)826-1003
 Eden Prairie
 MN, 55344

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

GSM Short Messaging Service for SCADA

Thu, 10 Apr 1997 12:22:58 +0100

I am responsible for distribution automation for the Electricity Supply Board (ESB) in Ireland and I am currently looking at communications media for pole-top devices. The key characteristics of the desired communications scheme is the desire to scan these units at a long periodic rate (perhaps once a day) in order to conserve battery power at the remote unit in the event of a prolonged loss-of-supply, while catering for remote-initiated communications in the event of a power system disturbance. ESB already has a communications network for is substation SCADA system which is partly based on polling radio. While this radio system could be adapted to incorporate pole-top devices, it would not be possible to allow the remote unit to transmit spontaneously within the normal scanning cycle. More frequent scanning of the RTU would require an increase in the battery capacity at the remote site. Another communications option would be packet radio, but unfortunately there is no operator offering such a service in Ireland and ESB's current DA project would not be a suitable driver for the development of a private network by ESB itself. This brings me to my current investigation of data communications over GSM. Two modes are available, straight data transmission using GSM's "modem" like data facility or the Short Messaging Service (SMS). GSM's data service is very straight-forward and there are GSM units (such as the Siemens) which provide a simple RS-232 port and can be controlled using standard modem-like AT commands (with the additional "AT+C" extended cellular commands). In this mode, most RTUs with standard dial-up or dial back-up support, are capable of communicating over GSM. However, the economic attraction lies with the SMS mode, where data is sent in short packets (about 160 bytes) in a store-and-forward mode. It is likely that network operators will offer low tariffs for such low density, non-peak traffic (typically, cyclic scans would be done in the small wee hours and only remote-initiated communications would be classed as urgent). The problem with SMS is the need to encapsulate the data message in the SMS frame, including the messaging centre number, recipient address, etc. as well as perhaps converting the message into 7-bit characters for those networks unable to cater for full 8-bit characters. While suppliers of modern RTUs will undoubtedly be able to develop suitable software to allow such encapsulation (at a price of course), older RTUs may not be so easily adapted. This brings me (finally) to my question. Does anybody have any experience of (a) implementing RTU communications via SMS and (b) knowledge of a device which will encapsulate/decode the SMS frame. The key requirements for the device mentioned in (b) are as follows:

1. RS-232 input and output,

2. ability to configure messaging service centre recipient nos.

3. capable of appearing as a modem to the RTU,

4. ideally should be able to initialise the GSM unit (i.e. select operator, transmit PIN number(s), etc.)

5. be able to identify incoming message origin and discard (and report?) messages from invalid sources, Desirable additional features would be:

6. ability to distinguish between incoming SMS messages and GSM data, SMS messages would be directed to the RTU communications port while GSM data might be directed to the configuration port (e.g for RTU configuration, download of disturbance records from an intelligent protection relay, etc.)

7. device integrated into the GSM unit. So far, the best GSM unit that we have seen is the Siemens M1, which is specifically designed for data over GSM and comes complete with RS-232 port. It has the added advantage that it doesn't have any voice facility and is therefore unlikely to be used for unauthorised purposes. However, it does not support any of the added features I have described. I would welcome any thoughts or suggestions on the above. Regards, Eamonn Connolly, _____ _____________

ESB Distribution Dept.,                  (_____) /  _________  \
 Lr. Fitzwilliam St.,                      _____  \  \     ___)  )
 Dublin 2,                                (_____)  \  \   (___  
 Ireland.                                  _________\  \  ____)  )
                                          (____________/ (______/
 Phone:  +353-1-702 7924
 Fax:	+353-1-678 5143
 e-mail:	eamonn.connolly@n1.esb.ie

Re: GSM Short Messaging Service for SCADA

Sun, 13 Apr 1997 19:24:15 -0400

Hi Emmon, It's been a long time. We have done some work recently on the broad spectrum radio offerings that implement the store and forward functions as you describe. The interface from the RTU to the radio is a simple RS232 interface, the radio actually encapsulates the RTU protocol for transmission (of course this is using a modern 8-bit protocol. The big industry interest here is in the water SCADA business; this market seems to be pushing the technology more than EP or COG. Our intitial testing has been with FoxSCADA master station and C50 RTU using DNP

Ref: c:\scada\041997\msg00011.xml

GSM Short Messaging Service for SCADA

Sun, 20 Apr 1997 10:53:04 +0200

Hi The SMS service is really a very good service to exchange short messages between a RTU and a control center. Since it looks like the SMS service was an after thought for the normal GSM service it has some limitations. One problem is the 7 bit byte, but it can be worked around, but this does reduce the actual message size to 140 characters. Some of the GSM providers does provide 8 bit byte data service, but they are rare. We use a system where we exchange SMS messages between GSM telephone, meaning with also have a GSM telephone at the host computer site. It will cut the price and give more reliable service. This will also reduce to store forward delay to less than 10 seconds for a message. The price for SMS is very resonable about 0.05 USD in Denmark. We are using this service to monitor vehicles all over Europe and there is no roaming charge yet. Another advantage is it is not necessary to have a modem or PCMCIA connection to the telephone, there is a direct connection to the telephone from a RS232 port on the computer. The PCMCIA card is very expensive. Using the GSM data channel is also possible but then you are limited to 9.6 Kbaud maybee not a problem. The interface is expensive and you will need both a Data and Voice SIM card plus monthly charge for both. It is no problem to seperate the two message channels it is done in the telephone. We send about 3000 bytes every morning to one about 650 busses, it is all done with SMS. For this project we have a X.25 channel to the GSM provider. We considered the combination but it was more straight forward to use the SMS service only. You can forget the old 32 bit BCH data package for some old (very old) RTU's it was also synchronous data so you would need a protocol converter anyway. I can not recommend the Siemens M1 telephone. It does not do voice and in some countries it is against the regulations to have a GSM service without being able to do emergency calls, maybee not in Ireland. The telephone is old design and very expensive, and it only operates in none transparent mode for data transmission. This means your own software will have to sort through a lot of garbage to find the correct data. Siemens has promised a transparent mode for several years but we have not seen it. The advantage is the RS 232 interface and the modem build in the telephone. The packaging of the telephone is also good. Look around there is other and less expensive solutions around. We also use the GSM data service to transfer compressed video data, here we use the Nokia 2110 telephone. I hope this will put a little more light on how we use the SMS/GSM service.

 Jannick Johnsson
 Scan Project Solutions
 Denmark
 http://www.pip.dknet.dk/~pip1573

Ref: c:\scada\041997\msg00012.xml