Vous êtes sur la page 1sur 8
Conference Papers THE BENEFITS OF NETWORKED SCADA SYSTEMS UTILIZING IP-ENABLED NETWORKS Robert H. McClanahan, Arkansas Electric Cooperative Corporation (0-7803-7470-3/02/$17.00 ©2002 IEEE cs, ‘THE BENEFITS OF NETWORKED SCADA SYSTEMS UTILIZING IP-ENABLED NETWORKS Robert H. McClanahan Vice President, Information Technology ‘Arkansas Elecric Cooperative Corporation P.O. Box 194208 Litle Rock, Arkansas 72219-4208 Phone: (501) 570-2403 Fax: (501) 570-2903 E-mail: meclanahan@aececom Abstract - Yesterday's SCADA systems were monolithic in architecture and had litle in the way of networking features. While they did an excellent job of polling remote terminal units (RTUs) at substations and controlling switehgear, thelr master stations offered litle in the way of networking flexibility. Today's SCADA systems are far more network-enabled than thelr predecessors and, when coupled with IP-enabled networks, provide opportunities to take advantage of the ‘convergence of voice, data and control data streams onto such networks, This paper will examine the benefits of SCADA systems, RTUs and communications systems t utilize the flexibility and cost savings afforded by IP- ‘enabled networks. LL INTRODUCTION Convergence is aterm that has received a great deal of airtime in recent years. Vendors, consultants and industry nis have been preaching about the benefits to be derived from networks that support muliple services. While much of that discussion has been somewhat subjective and vaporous in the past, recent developments in applications for TP. enabled (Internet Protocol) networks have made convergence an achievable, real-world goal ‘The goal ofthis paper is to explore options and benefits available with the implementation of networked Supervisory Control And Data. Acquisition (SCADA) systems on TP. enabled networks. 1s not intended to be a definitive Work fon the subject, but rather provides & venue to discuss several of the issues’ associated with such implementations. The evolution of SCADA system architectures will be discussed, along with the ability to implement those architectures ‘cross various network topologies. A brief overview of open network concept is also included to help the reader beter ‘understand basic network principles and the advantages of ‘open networks. Lastly, a brief discussion of some communications options made more viable by the changes in SCADA architecture is presented. IL. THREE GENERATIONS OF SCADA ‘ARCHITECTURE, ‘Our Cooperative first installed a SCADA. system in the carly 1980's, Since that time, there have been two major changes in dhe overall design of SCADA. systems, representing a tal of three generations of SCADA architecture. The Cooperative has taken advantage of each of these changes to upgrade the system to capture the benefits ‘of the improvements in the new architecture. One of those two upgrades occurred in 1988 and the other i currently underway. ‘To grasp he significance of the convergence of numerous business applications towards TP-enabled networks and SCADA's involvement in such, an understanding ofeach of these three generations of SCADA architecture is needed ‘This should assist the reader in better understanding the extent of the changes ia SCADA systems and how they Felate to other business functions. A. 1 Generation - Monolithic When SCADA systems were first developed, the concept of computing in general centered on “mainframe” systems ~ 4 single monolithic system that performed all computing functions, Networks were generally non-existent and each centralized system stood alone, As a result, SCADA systems ‘were standalone systems with virally no connectivity to other systems ‘The wide-area networks (WAN) that were implemented to communicate with remote terminal units (RTUs) were designed with & single purpose in mind - that of ‘communicating with RTUs in the field and nothing else. In addition, the WAN protecols in use today were largely unknown atthe time ‘The protocols in use on SCADA networks were developed by the vendors of RTU equipment and were often tweated as proprietary. This meant that, for some RTU protocols, no ther vendors wer allowed to build equipment hat communicated via these protocols. In addition, these prerocols were generally very “lean”, supporting virtually no set functionality beyond that required to scan and control points Within the remote device. This meant that it was generally not feasible to intermingle ether types of data traffic with the [TU communications on the network, Connectivity tothe SCADA master station itself was very Timited. Without network connectivity, connections to the raster were typically done at the bus level via an often- proprietary adaptor or controler plugged into the CPU backplane. Again, this limited connectivity to that provided bythe system vendor. Failover and redundancy in these 1" generation systems ‘was accomplished by the use of two identically equipped ‘mainframe systems connected at the tus level. One system was configured as the primary system, while the second was, configured as 2 standby system. The stundby system's primary function vas to monitor the primary and take over in the event of a detected failure. This type of standby ‘operation meant that lie of no processing was dane on the Standby system. ta distribute the processing across multiple systems, Multiple stations, each with a specific function, were connected 10 a LAN and shared information with each other in real-time. ‘These stations were typically of the mini-computer clas "rather than mainframes, and were smaller and Jess expensive than their 1" generation predecessor, Some of these distributed stations served as. communications processors, primarily communicating with field devices such ar RTUs. Some served as operator interfaces, providing the human-machine interface (HMI) for system operators. Stil aters served as calculation processors ‘or database servers. The distribution of individual SCADA system fonctions seross multiple systems provided more processing power forthe system as & whole than would have been available ina single processor. ‘The networks that connected these individual systems were generally based on LAN protocols and were not capable of reaching beyond the limits of the Local evironment. The CCooperative’s 2" generation SCADA system had a Timit of 600 total fect of cable between stations on the network. This greatly limited the LAN to litle more than a convenient way fo connect multiple stations within a single room or series of nets, Some of the LAN protocols that were used were of @ proprietary nature, where the vendor created its own network protocol or version thereof rather than pulling an existing ‘one off the shelf. This allowed a vendor to optimize its LAN ‘protocol for realtime trafic, but it limited (or etfectively liminated) the connection of network devices from other ‘vendors tothe SCADA LAN, Figure 1-1 Generation SCADA Architecture Some limited connectivity to external systems was available through low-speed serial connections utilizing communication standards such as S252, The ‘Cooperative's frst SCADA matter was linked to an sternal host via such an interface. This allowed data from the master to be exported to 4 more general-purpose computer system, where the telemetered data could be mare easily processed, shared and archived. In short, the frst generation of SCADA systems was generally Timited to hardware, software and. peripheral devices that were provided, or at least seleced, by the SCADA vendor. B. 2% Generation - Distributed ‘The next generation of SCADA systems began 10 take advantage of developments and improvement in system ‘miniaturization and local-area networking (LAN) technology igure 2 2nd Generation SCADA Architecture Distribution of system functionality across network- ‘connected systems served. not only to increase processing, power, but also to improve the redundancy and reliability of fhe system as a whole, Rather than the simple Primary/standby failover scheme that was utilized in many 1 generation systems, the distributed architecture often kept 3-2