SCADA over Frame Relay has low bandwidth demand.
So why would we even bring up the discussion about bandwidth when using our BPF (a SCADA FRAD communications device) for SCADA over Frame Relay? Because the issue comes up every single time a customer installs a system. The Frame Relay vendor, i.e. the phone company, always suggests far more bandwidth than is required... sometimes thousands of times more than needed! Why is this? Because all the phone company models for Frame Relay are based on connecting Local Area Networks (LANs) through routers. Little or no phone company analysis has been done on the bandwidth requirements for asynchronous SCADA polling over Frame Relay networks. Almost none of their sales people have even heard of it, much less been trained in it.
SCADA bandwidth needs are very different from those of LANs. LANs connected with routers normally demand far more data than host controlled SCADA systems. Any personal computer anywhere on the LAN can send or receive files at the will of the user. If the network has a central server with many branch locations, the amount of data that can arrive at the central server site may at times be the sum of all the branch location data.
But as we said, SCADA does not operate this way. SCADA systems have a host computer that polls the remote SCADA locations just one remote station (known as a RTU) at a time. Only one remote station answers at a time. Data traffic is either a poll from the host to the remote or a response to a poll from the remote RTU to the host computer. In addition to the one-way-at-a-time operation (half duplex), Frame Relay networks have propagation delay (similar to radios and modems) that further contributes to the low bandwidth demand. Round trip propagation times range from 50 to 100 milliseconds.
When comparing LAN to SCADA over Frame Relay, it is easy to see the dramatic differences in bandwidth demand. Consider a router connected LAN with a central administrative site and a half dozen remote sites. Suppose the remote sites are connected at 56 Kbps, an aggregate total of 336 Kbps. Any remote site can send data to or request data from the central site or one of the other 5 remote sites at any time. Therefor peak demand could be 336 Kbps at the central site. This is unlikely to be the long-term bandwidth demand, but the bandwidth demand is quite high during the busiest times of the day. In this example, it is typical to engineer the central site for 128 or 256 Kbps of bandwidth.
Contrast this to a SCADA system with a central site and a single SCADA polling circuit to 6 remote locations. The SCADA host computer likely has asynchronous polling at 9600 bps. The DCB BPF encapsulates this traffic into Frame Relay. A host system poll is typically 6 bytes. Presume for our discussions the following: a maximum bandwidth demand scenario, where an RTU sends back a 256-byte block of data in response to each poll; a propagation delay of 50 milliseconds round trip; link speeds into the Frame Relay network of 56 Kbps. Using these assumptions the host will poll and get responses about 3 times per second. The total bandwidth used from the central site outbound will be about 1000 bits per second, and the total bandwidth used inbound from the remote sites will be about 7500 bps. The number of drops being polled has no effect on the inbound bandwidth requirements since only one remote at a time will answer a poll. 7.5 Kbps is only 13% of the available bandwidth of a 56 Kbps connection and is in fact about 3 times more than we have measured on active circuits.
It is safe to say that a single 56 Kbps circuit is loafing when supporting one polling circuit and can easily handle the six SCADA polling circuits.
SCADA Frame Relay Products are listed at http://www.dcbnet.com/products.html#scada . Additional white papers and tutorials are available for download at HTTP://www.dcbnet.com/apnotes.html#scada .
|Data Comm for
2949 County Road 1000 E
Dewey, Il 61840
Toll Free: 800-4-DCB-NET
Toll Free: 800-432-2638
|Email: Contact Page
|All DCB web pages copyright ©1995- Data Comm for
Business, All rights reserved.
EtherPath®, EtherSeries®, EtherPoll®, EtherBridge® and EtherModem® are Registered Trademarks of Data Comm for Business, Inc.