Author: Lester Abbey
Managing Director
Abbey Systems

Presented: Inaugural New Zealand SCADA Conference 28-29 October 2003, Auckland, NZ

ABSTRACT
This paper will cover broad issues pertaining to SCADA Systems.

The paper will be divided into five sections:

The first will provide an overview of SCADA – what we need from it, why we have it, the business drivers behind SCADA and a broad description of the basic components.

The second section will cover the history of SCADA systems to date, and the influence that existing systems and technologies will have on the future.

The third section describes the issues facing SCADA; ownership of communications, structure of base station software, the role of standards, reliability.

The fourth section introduces the new technologies available and describes how they will affect the future of SCADA.

The map for the future: the fifth and final section presents the author’s vision of the way SCADA systems will communicate with their outstations (RTUs) in the next ten to twenty years - what technologies will be popular, what standards will be in use and how to plan now for the future. The concept and consequences of the Master site not being location dependent is covered here as well. Throughout this section will be references to the original application requirement - so as to not get immersed in dazzling technology for its own sake.

AUTHOR
Lester Abbey has been the managing director of Abbey Systems since its founding in 1978. Abbey Systems designs, manufactures and installs telemetry and SCADA systems for water, wastewater, power distribution, gas and broadcasting applications. They are currently releasing their 5th generation of product for the Water industry - the Swampfox.


1 INTRODUCTION

S.C.A.D.A – Supervisory Control and Data Acquisition - can mean many things to many people. From the selection of papers and my own experience, this paper will be about SCADA systems that deal with large reticulation systems such as water, gas and electricity. This is special because of the importance of communications and distance in these types of systems. For the purposes of this paper we call this Wide Area SCADA. There are other types of SCADA systems – notably those employed in factories and assembly lines which influence the technologies and applications of the reticulation SCADA that is mentioned above.

1.1 WHAT IS THE JOB OF SCADA
Gathering, analyzing and reacting to information from the plant that is connected to the system. The rest is detail. However, “The devil lies in the detail” This paper will make no attempt to cover all the various issues raised by detail but will provide some illustrative examples.

1.1.1 THE BASICS
Alarms are the most immediate and generally the most important function of a SCADA system. Although SCADA systems have far greater functionality, Alarms such as reservoir low, pump fail, CB trip are a core function and must be communicated to those who can rectify the situation reliably and quickly. Although this seems fairly trivial in light of the far more sophisticated and powerful applications that a SCADA system is capable of, it should be taken very seriously. If the system cannot perform the Alarm function reliably it will lose credibility and its other uses will not be trusted. Secondly it must display the vital information clearly and without error. In many systems realtime display is not a primary function (especially Water Systems) but it is almost always a feature and if it is not accurate the rest of the system becomes distrusted.

1.1.2 INFORMATION
Collection of information such as reservoir level, feeder current, pump state and equipment hours is another important function of telemetry systems. Typically this information is used to program and target maintenance, make control decisions, gather information for future planning and display current system status. In sophisticated water and power systems the information is used in real time to make sophisticated decisions about water and power network management. This information is used by four primary processes – alarms, display, process control and reporting. Information update time and accuracy/validity requirements are different for these processes and often different for various components of a SCADA system.

1.1.3 CONTROLS
Controls may be issued by either the central station or other sites in response to information gathered by the telemetry system. A simple example of this is a control to turn a pump on when the associated reservoir is low. Complex control scenarios such as balancing flows to a treatment plant or regulating valves to maintain a pressure, are often required and are influential in determining communications network capability.

1.2 WHY HAVE A SCADA SYSTEM
In order to provide a framework for understanding SCADA the question “Why have a SCADA system” is posed. This is rarely done and often in response to this question some very technical answers are given e.g. “To establish radio communications to outstations” or “achieve 2 GHz wide bandwidth coverage over the area”. Specific reasons are often too general and lack focus on the actual outputs that are expected to benefit the SCADA user. An example of this is “We need the system to monitor our pumps”. Other reasons advanced are along the lines of “Everybody else has one, ergo - we need one too” or “We’ve upgraded our existing system to keep up with the technology”. Only rarely do we encounter a specification that specifies the system outputs and the perceived benefits. This is the key to SCADA however – what do we really need it for? Some basic needs are listed below.

1.2.1 SAVE TIME
The time taken to travel to remote sites to gather information or issue controls, to sift through manually entered data, write out a report or perform any of the functions that a SCADA system does as a matter of course is considerable. Timesaving benefits go far beyond the man hours saved – timeliness of alarms, actions, controls have high monetary value as well.

1.2.2 AVOID TROUBLE
A SCADA system’s primary purpose is to give advance warning of trouble. Some big picture answers as to what the SCADA system is used for elicits the following responses: Power Board Chief engineer “Keep the power going to our customers” Water Board Engineer “ Make sure the reservoirs have water in them”Wastewater Engineer “Make sure that sewage doesn’t run down the streets” These simple requirements are major reasons for having and keeping the SCADA system. Putting a monetary value on these outputs is difficult but quantifiable in terms of fines under the Resource Management Act.

1.2.3 ACHIEVE SYSTEM WIDE PROCESSES
SCADA systems afford the user an opportunity to monitor and control processes that take place over a wide geographical area. For example, balancing flows into a sewage treatment plant or an energy management system. These applications can cause considerable financial savings in running costs (flow balance) and capital costs (energy management) which can pay for the cost of SCADA in itself.

1.2.4 SAVE MANPOWER
Before SCADA systems (with telemetry) were implemented, remote sites such as substations and pumping stations were either manned or inspected frequently. The need for this was eliminated (or greatly reduced anyway) by the implementation of wide area SCADA. This was the primary economic driver for SCADA system implementation in the first great wave of comprehensive systems in the 1970’s and 1980’s.

1.3 FUTURE TRENDS
Although SCADA systems are in a state of flux at the moment it is possible to discern some trends for the future.

1.3.1 COMMUNICATIONS
In general, the use of communications networks, (wireless in particular) is burgeoning and this is a trend expected to continue in the future. Communications for telemetry purposes is expected to follow the mainstream trends and make use of the more advanced networks and equipment that will inevitably become available over the next ten years. The major feature will be the conflict between bandwidth and coverage. Most modern systems opt for increased bandwidth at the expense of coverage.

1.3.2 SYSTEM COMPOSITION
Future systems will not be as homogenous as the systems installed in the past decades. Currently most systems are a combination of legacy systems and enhancements. This trend will continue as it will be uneconomic to do a complete system replacement.

2 A BRIEF HISTORY

2.1 IN THE BEGINNING
SCADA didn’t suddenly emerge as a complete functioning entity – rather it grew out of various disparate technologies and needs. In the case of wide area SCADA, simple landline based telemetry systems were installed and monitored centrally by means of lamp indication. Sometimes these indications were scanned by a minicomputer and changes of state were printed. More sophisticated computer systems were used for local (e.g. treatment plant, power plant) monitoring, and to a lesser extent, control.

2.1.1 COMMUNICATIONS
Communications to remote sites was generally through a pair of copper wires. Simple tones were transmitted to a central point or in some cases a resistive loop was used. Information was limited to less than 10 digitals and one analog per pair of wires. These landline communications systems had a star configuration and were relatively expensive. The landlines were prone to error but in a way that didn’t affect the whole system.

2.1.2 CENTRAL SITE
More often than not the central site was an array of lamps and gauges which could be viewed by an operator. For reporting, an operator copied down the values on forms.

2.2 THE “DINOSAURS”
Systems installed in the 1970s and 1980’s are now commonly referred to as “Dinosaur Systems”. They were big, they were expensive and they ruled the earth. These systems were all manufactured and installed by one company who was responsible for total system operation. In New Zealand Leeds & Northrup, Westinghouse and Plessey ruled the power industry, Abbey Systems and Philips (later Qtech) ruled the local body terrain. These companies would have their own line of equipment (designed and manufactured in-house) and software. They would normally be responsible for engineering, configuration, communications network, installation and commissioning. The protocols between the RTU and Master Station were all Proprietary as was the Base station software and often the base station hardware.

2.2.1 CENTRAL SITE
For larger systems the central site was a minicomputer and hot standby talking through a variety of Proprietary devices to the communications network. The changeover system was specifically engineered to switch the computers, communications equipment and peripherals smoothly. The software was also written to communicate with the same companies RTUs and fully utilize all the features.

2.2.2 COMMUNICATIONS SYSTEM
The communications system was supplied by the vendor. It was chosen to suit the RTU and master station technology. The communications were typically via landline or UHF radio. Speeds ranged between 300-1200 bps. Communications protocols were generally Proprietary and incorporated features that would give a functionality edge over the competition.

2.2.3 REMOTE TERMINAL UNITS
Remote Terminal Units (RTUs) were designed and manufactured by the vendor to match communications and master station capability. Remote terminal units were manufactured by the same company that supplied (and wrote) the base station software and communications equipment. They were the defining feature of the system – RTU capabilities were the standard by which the systems were measured – the accuracy of the time stamping, total I/O capability, isolation standards were the measures used for excellence.

2.2.4 NOSTALGIA
Many users were very happy in the days of the dinosaurs. The system was well understood, it generally worked well and had features such as hot standby which worked better than subsequent systems. Most of these systems were predictable. Any problems and the supplier was required to fix it. Training on the system was provided on standard courses by the supplier. There was one set of manuals.

2.2.5 THE PASSING OF THE DINOSAURS
Although these systems worked well and were highly regarded pressure for change came from several factors:
1. The user was hostage to the vendor – it was financially and operationally impractical to totally abandon System A for System B.
2. One was restricted to what the vendor’s system could do - if system A couldn’t do what system B could there was no easy way to achieve system B capability except by changing to system B. (see 1 above).
3. Various power boards would merge causing the problem of operating two incompatible systems.

2.3 TODAY’S SYSTEMS
Today’s systems still retain a legacy from the dinosaurs. It is fair to say that most SCADA systems at this moment are in a state of transition from a legacy system to a more Open system with multiple vendors and service providers. Most systems in NZ consist of a number of components of varying functionality and age. There is often evidence of a legacy system (dinosaur bones), some experiments with technology (small wireless LAN network, IEDs reporting directly to master station) fairly new master station software and some new RTUs integrated into the network

2.3.1 STATE OF TRANSITION
The systems today are a result of a new master station architecture or communications system imposed on the previous system. There is a strong movement towards “Open” standards and a desire to take advantage of technological advances that the legacy ‘dinosaur’ systems were unable to incorporate. The plan is to eventually settle on a flexible master station architecture using Open protocols to communicate to RTUs from a choice of vendors.

2.3.2 OPEN-ISH
In the push to achieve Open standards many SCADA users have found that it isn’t as easy as once thought. There is the problem of incorporating the Proprietary standards of the legacy system. The Open standards have varying degrees of acceptance and success. In communications between Master and RTU there is a war between DNP3 and IEC standards. Sometimes a big new standard which is touted as the solution to everything (UCA2) dies of its own mass. Another fly in the ointment is the propensity for protocols to allow customizing – such as private dtat files. As soon as a vendor uses these files for his own purposes – such as downloading parameters to their RTUs - there goes inter-operability.

2.4 A LOOK AT THE FUTURE
There are a number of technological and commercial drivers at work which muddy the waters as to a future system. There are several things that will happen which are safe to predict – the dominance of IP based communications, legacy system content, and greater connection with other processes and systems.

2.4.1 COMMUNCATION PROTOCOLS
Systems will still have to cope with a variety of communications protocols from the legacy protocols of yesterday, (C2025, HDLC, PDOS) to the competing protocols of today (DNP3, IEC870 etc), with attempts to standardise in the future. There seems to be a conflict in the complexity of protocols, making them difficult to use,and the need for complexity to perform the function required. This may never be resolved.

2.4.2 CONVERGENCE OF TECHNOLOGIES
Power network SCADA systems will see the merging of function between the various electronic devies for protection and transformer controls and the function of RTUs. The IEDs had serial protocols which could be used for long distance communication. With the advent of system wide WAN networks and Ethernet capability of the IEDs it is possible to communicate directly with the primary devices such as protection relays and transformer controllers. In pump stations this is happening as well – pump station controllers now have communication capability, which could lead to them taking the function of RTUs. In the other direction, intelligent programmable RTUs can take on the job of pump controllers (or in the case of the power industry, bay controllers), eliminating the need for these devices.

2.4.3 INTERCONNECTION WITH OTHER SYSTEMS
SCADA systems will be more and more required to interconnect with other related systems such as billing, GIS, EMS, water management and other SCADA systems from neighbouring authorities.

2.4.4 OWNERSHIP OF COMMUNICATIONS SYSTEM
The ownership of the communication network can be an important consideration. Financially, it makes sense to use communication providers such as Telecom and Vodaphone. These companies also have the expertise to implement the complex high bandwidth systems that are becoming more popular in SCADA systems. A privately owned system has the advantage over a communications service provider in times of emergency. The concern with a shared network such as cellular, is that the infrastructure may well be swamped with calls, blocking essential data from reservoirs and pump stations. With a private network (and make sure that it is really private) the communications traffic can be controlled by the utility that owns it.

2.4.5 PERSISTANCE OF LEGACY SYSTEMS
You’ll never get away from them. Once a SCADA system has been installed – as most of them were in the days of dinosaurs - it is too expensive to do a complete replacement. Not only that but operationally it is impossible to decommission the SCADA while installing a brand new system. Systems will evolve rather than arrive and the management of that evolution is the key to keeping a good system at the present and for the future.

3 ISSUES

3.1 OPEN VS PROPRIETARY
This issue is often thought to be settled in favour of Open systems; however, the early success of Proprietary systems lingers on and there is still a market for one stop shop (Proprietary) systems. Many Proprietary systems have “openings” in them so that they are inter-operable with other vendors’ systems – they just work better with their own components. Attached in the appendix is a short article on this subject.

3.1.1 WHAT IS MEANT BY OPEN
Open commonly means that a system is standards-based rather than vendor-based. These standards define the interface between various subsystems. The purpose is to allow the user to select equipment and vendors that conform to the standards with a view to getting the most appropriate solution – be it capital cost, quality, service etc. Vendor neutrality, flexibility and the ability to keep up with technology are cited as the primary advantages of an Open system.

3.1.2 THE ROLE OF STANDARDS
An Open system relies on multiple vendors adhering to established standards. When these standards are clear, simple, mature and well defined, the interface between system components is easy and true openness is achievable. When there is ambiguity in standards, or competition, Open systems become more of a problem.

3.1.3 HOW OPEN IS OPEN
Sometime the standards governing interconnection between various components of an Open system are so complex or so ambiguous that connection between components can be achieved only by experts. An example is IEDs using DNP3 or IEC 870. Prior to these protocols being introduced, it was a matter of wiring up 5 to 8 wires, and a limited but effective monitoring and control was achieved. Now in order to configure and test these devices when they use a complex serial protocol, a week is often needed. In part this is due to the increased functionality but a large part of the commissioning time is spent disabling unwanted function, selecting the appropriate registers and ensuring that the correct polling strategies are implemented.

3.1.4 WHO REALLY CONTROLS AN OPEN SYSTEM
If the Open system is too complex the user can then become the hostage of the system integrators rather than the vendor, and one of the primary benefits of Open systems is lost.

3.2 INFORMATION DISTRIBUTION
At the heart of a SCADA system is information gathering. This is all fine and good but once gathered something has to be done with it – else why gather it? The amount and quality of information is then a prime issue and with new intelligent devices in the field, high bandwidth communications paths and huge server capacity at the master station information overload is easy to achieve. Just because it’s easy doesn’t mean that it’s desirable. Many SCADA systems today suffer from information overload – the best way to prevent this is to analyse what information is required.

3.2.1 ENGINEERING INFORMATION – DIGESTED LATER
Much of the information brought into a SCADA master is useful for engineers to study at leisure. This is best stuffed into a database package where ease of retrieval is paramount. This information is said to be used for fault finding, future planning and network design. It is interesting to note however that some studies show that this stored information is rarely if ever retrieved. Perhaps an audit would be useful rather than cramming the database with surplus information “just in case”.

3.2.2 REGULATORY INFO
Statutory reports are required by various government agencies on utility performance and compliance with regulations. This must be gathered and the data validity ensured. This should be a high priority.

3.2.3 CONTROL ROOM OPERATOR
The control room operator needs to have enough information to do his job. A careful balance between not enough information easily at hand and information overload is required. During emergencies the information such as CB state, reservoir level must be easily accessible and clearly presented in real time. Screens should be uncluttered. Alarm information is the most important.

3.2.4 AUTOMATED SYSTEMS, DMS, EMS, LOAD MANAGEMENT, WATER MANAGEMENT
Information must be presented to these automatic control systems in order for them to be useful. This information does not need to be available to the operator or even reporting systems, but its validity is vital to these management systems. This sums up what is actually required. All too many users gather lots of extra info - 1) because it’s available and 2) because it might come in handy.

3.3 STANDARDS
The issue of standards is crucial to the future of SCADA and to the Open vs Proprietary debate. We’ve covered standards in previous sections but there are issues arising from standards that all SCADA designers and users should be aware of SEQ CHAPTER \h \r 1With telemetry and SCADA systems these standards govern the connections between; instrumentation and Remote Terminal Units (RTU) (this would cover connection type, contact ratings, isolation, current levels etc); RTU and communications bearer (covering impedance, communications protocol, signalling techniques and frequencies); and communications bearer to Master Station. The general rule is, the simpler and more complete a standard is, the easier it is to adopt an Open system approach. A complex or incomplete standard will leave areas of ambiguity; major components may comply to the same standard but not connect well to one another because of the ambiguities and missing items in a standard. Standards are best for mature applications. They will not change to incorporate new functionality, they are well understood by vendors, integrators and technicians. Standards can be incomplete or ambiguous. SEQ CHAPTER \h \r 1An example of this is RS-232. It is distressing to note the number of users, who upon noting that an RTU is equipped with an RS-232 port, expect that the RTU will be able to communicate with other serial devices. RS-232 covers electrical signal levels, signal flow control and is associated with various connector standards but it does NOT cover data format, speed of transmission, and the meaning of the data that is sent. Sometimes important standards are vendor driven – Microsoft is a prime example of this but there are others as well. There was a perception that DNP3 was a tool of GE Harris, but it is now well supported by many other vendors. When a standard is vendor driven other vendors can be half hearted in their implementation – unless the standard becomes dominant or is a particularly good standard e.g. Modbus. Sometimes standards can change so often that they become a moving target. This can affect “openness” greatly in that components that interacted well five years ago no longer do because only one of them has implemented the latest changes. The IEC standards seem to be doing this at the moment. Obsolescent standards present another problem. There are plenty of standards that governed system development that are now just obsolete. DDE is an example. Ten years ago this was a must for linking to other information systems. It was slow and buggy but the only widely accepted standard on the block. Now it’s considered the kiss of death to use this.

3.3.1 SOFTWARE STANDARDS
Software standards generally concern the operating system (MS Windows, Unix Linux etc) and interfaces to other software packages (OPC, ODBC). These standards are generally well understood and mature. MS Windows is the most popular and the most problematic – it has many options and is fairly fast moving. A new version is released every two years and compatibility with previous versions is not always guaranteed. For this reason Unix is often used on large systems and Linux is rising in popularity for smaller ones.

3.3.2 COMMUNICATIONS PROTOCOL STANDARDS
DNP3 and the IEC standards (IEC 870-101,102 etc) are in competition as SCADA protocols and there are problems with each. Although they are large and complex protocols they still lack message types for parameter download, program download and other features of many systems. These still remain Proprietary to vendors. An attempt to standardize these was made in UCA 2 which was such a monster that it died of its own weight. Our European friends are threatening an even bigger one to replace it though.

3.3.3 ENVIRONMENTAL STANDARDS
SCADA systems, especially the outstations, have to survive in harsh environments, both climactically and industrially with problems such as high voltage spikes, gas or corrosive atmosphere. For that reason the equipment associated with SCADA has special design features which are not found in mainstream office equipment. Occasionally someone tries to use this type of equipment (desktop PC) in an outstation environment – and this is when the environmental standards should be applied.

3.4 SYSTEM RELIABILITY
After some major blackouts where a more reliable SCADA system (or rather network of systems) would have possibly avoided disaster, reliability of system is at the forefront. By reliability of the system we mean in its entirety – from inputs to outputs. This includes the instrumentation such as CTs, contacts, pressure gauges etc to the installation to the RTU, the communications network, the master station communications front end to the base station itself including software and peripherals. This reliability must extend to the interfaces between the various subsystems of a SCADA system. A system operator wants to trust that when his system tells him that a CB is open or a reservoir is full that it is 100% correct; he cares not whether most of the system was perfect and it was only the transducer or IED that was out of sorts. Lack of reliability impacts on system performance and value in far more ways than the direct cost of whatever measurement or alarm was lost. When operators and users distrust the system many of the benefits from having such a system are lost – maintenance reports are not used because they are considered ‘unreliable”. Alarms are not acted on, controls are done manually, losing one important advantage that SCADA confers. System reliability is getting more difficult to achieve, particularly when systems are in transition between legacy systems and Open systems. Below are some factors which can affect system reliability.

3.4.1 COMPLEXITY OF SYSTEM
Generally the more complex a system the more things there are than can go wrong. Simplicity, which is always desirable, can be even more difficult to achieve. With legacy systems, “flexible” Open systems allowing a wide choice of equipment complexity is the order of the day.

3.4.2 SYSTEM HOMOGENAETY
If a system comprises components that are closely matched either by vendor or specification the tendency is for the system to perform more reliably. No matter how clear and well formed interconnection standards are if components of a systems are specifically designed to work with one another. Also from a maintenance standpoint the less variation in system components the easier it is to understand and maintain.

3.4.3 QUALITY OF COMPONENTS
The quality of system components can affect system reliability but one must bear in mind that overall system reliability is only as good as its weakest component. Therefore care should be taken when selecting system components that the quality level is approximately the same for different parts. It’s pointless having a high quality, multiple path, fail safe communications system connected to a master station which crashes frequently.

3.4.4 QA MEASURES.
Careful, thorough testing and consistent procedures are a key to ensuring any system has improved reliability. This is expensive and time consuming. It can also be difficult to achieve if part of the network has to be taken out of service for effective testing. However it is worth the effort.

3.4.5 MAINTENANCE ISSUES
A SCADA system requires timely maintenance. Instrumentation drifts, connections corrode, communications channels overload. Sometimes forklifts back into RTUs. At issue is identifying when there is a problem with the SCADA system itself and attending to it promptly (before the system loses credibility - see 3.4). This is not trivial in a system with 10,000 I/O points, 200 RTUs 20 comms channels and 15 master station machines. It is impossible to monitor and verify the validity of all I/O points or even check them regularly. The SCADA system covers a wide area and many parts (e.g. repeaters) are not easily accessible. Scheduled maintenance is good but entirely useful, the record is that some components fail repeatedly while other identical ones operate quite happily for 20 years or so. Fortunately many SCADA components are self monitoring or obviously non-functioning, so monitoring SCADA systems alarms is a start. A register of faults is useful in identifying soft spots such as equipment types more prone to failure.


4 NEW TECHNOLOGIES

4.1 IEDs
IEDs (Intelligent Electronic Devices) are now dominating the market for protection and control relays in substations. These devices are replacing electromechanical circuitry with microprocessor software, and give the user more sophisticated protection techniques – including substation wide protection. (the protection algorithm of one relay can affect other relays in the same sub). These IEDs were able to provide so much new information that it could only be conveyed to the RTU via a serial port. These ports had rudimentary SCADA communications capability which has grown ever more sophisticated. The more modern IED’ are LAN enabled and with the convergence of technologies bringing LAN or WAN into substations, the IED can more and more bypass RTUs and communicate directly with the Master Unit. RTUs become vestigial and then redundant when a substation becomes part of a system wide LAN.

4.2 DISTRIBUTED ARCHITECTURE
SCADA base station software has grown considerably from the large packages initially operating in the Dinosaur systems. It has also moved from a single (or duplicated) mainframe configuration to a distributed architecture of multiple machines interconnected by LAN. This approach has many advantages – the same application can be running simultaneously in more than one machine – if one application (or machine) crashes then the other can continue seamlessly. Sometimes the processing load is distributed among machines with the system gracefully degrading when one or more machines become unavailable. A third feature of distributed architecture is having different applications run on different machines: EMS on one (or more), Control Room SCADA on another, database software on a third subsystem. Machines interface using well-defined and popular standards such as OPC and ODBC.

4.3 WIRELESS LAN
The wireless LAN is a result of two technologies that will intersect when used for telemetry. The first technology is one being developed for office buildings – low powered but high data rate radio modems which allow the office LAN to propagate throughout the building and allow PCs to connect without the need for expensive wiring. Then there are WAN technologies using high-powered spread spectrum radios. These systems are more robust and give better coverage but the bandwidth is much lower. The upshot of this is that there will be a multitude of products available which will make the establishment of LAN and WAN networks relatively easy.

4.3.1 ADVANTAGES AND DISADVANTAGES OF LAN COMMUNICATIONS
LAN communications is the direction in which communications is heading, be it wireless or cabled (landline). There are some major advantages for telemetry systems in this. The most important is the fact that messages between the RTU and Master can be transmitted by a number of different paths. If one path is inaccessible the LAN protocol (TCP/IP) will try another route. Because of the popularity of LAN style communications there is an ever-increasing amount of equipment available for implementing these networks - spread spectrum Ethernet radios, routers that can survive in harsh environments. Another advantage is the ease of interfacing with office technologies. LAN based telemetry systems can interface directly into most SCADA software packages. A final advantage is the “distributed” nature of LAN communications. There needs to be no focal point in a network, the Master can be located at any node. RTUs can communicate directly with one another without the need for sending through the Master. Having said this however, there are some disadvantages that must be considered. LANs require much more bandwidth than is required by the application, so it will be more difficult to obtain complete coverage – particularly for sewage pump stations and outlying stations. The cost is also high at present. As this application becomes more commonplace the cost is expected to reduce. The complexity of these systems is also a minus, the technology is not mature and requires lots of routing, setup and other adjustments just to get working. Last but not least – involvement with LANs means that the user becomes a hostage to the IT section of the utility. The IT culture is not conducive to telemetry and its 24 hour a day, 365 days a year operation. This has been a problem in every installation that we’ve been involved in.

4.4 DATA OVER CELLULAR
Data over cellular is gaining popularity. This technology allows the infrastructure of various cell phone networks to be used for telemetry. This saves a lot of capital expenditure but has the limitations of lack of network control and possible coverage issues.

4.5 OPTICAL FIBRE NETWORKS
The use of fibre for communications purposes is burgeoning. Saturn uses fibre networks to bring internet and video signals into households and many large companies have their own fibre networks. Wellington City is trialling CityLink – a fibre network in the CBD. Fibre networks are just getting started so it is difficult to discern a cost structure that will hold steady for the future. The advantage of fibre is reliability. Unlike copper it doesn’t corrode, short circuit, deteriorate or have other problems associated with copper circuits. It also has the advantage of a high bandwidth. To run fibre to the RTUs in pump stations can be expensive with trenching and running of fibre cables from each pump station to a multiplexing point (which can be many kilometers away). The cost of fibre itself can also be high. There is an opportunity to put fibre cables alongside pipes when installing them, saving the cost of trenching etc for cabling alone.

4.5.1 PUBLIC FIBRE NETWORKS
Things like Wellington’s CityLink are examples of a public fibre network. Connection fees are very high at the moment (about $6,000 for our building) and the bandwidth is far in excess of what is needed for an entire system, much less a single pump station. We expect these networks to increase in scope and decrease in connection price but they will always be more expensive than wireless in urban areas.

4.5.2 PRIVATE FIBRE NETWORK
Water and wastewater utilities are in the position of being able to implement private fibre networks by installing fibre alongside reticulated plant such as pipelines. They would have to invest in infrastructure such as fibre multiplexors and termination systems.

5 MAP FOR THE FUTURE

5.1 COST EFFECTIVNESS
Up to the present a primary driver of development in SCADA systems is technological improvement. More features, faster, more data, more functionality. However there comes a point when the job that needs doing (as described in section 1.2) doesn’t require more functionality. The increased benefit for the user for technological innovation is not as great as in previous decades. The Dinosaur systems were a huge advantage over a SCADA–less network. Since then we’ve been icing the cake. Although engineers design and purchase systems there will be an increasing input from the hard nosed bean counters. Engineers are inclined to be more interested in features and technology, financial people focus on cost vs benefit. As benefits become more nebulous (or intricate and incomprehensible to the lay person) the financial person’s eyebrows will arch and the focus will turn to the cost side of the equation. There are certain bedrock items that cannot be discounted and will always play a part in SCADA system design.

5.1.1 MAINTENANCE COSTS
A SCADA system that consists of several generations of equipment interconnected by a plethora of standards and techniques will be harder to maintain. This should be taken into account when a system is incrementally improved by adding some RTUs from Vendor C whose price was better (the previous upgrade in another sector was from vendor B) and trying a different comms strategy to get the higher bandwidth necessitated by the new features of IED X. Each purchasing decision made sense when considered in isolation –the overall result is a dog’s breakfast.

5.1.2 CAPITAL COST OF EQUIPMENT
The capital cost of SCADA includes all of the equipment and labour needed to commission it. A new or single vendor system typically incurs a large capital cost at the outset but this should be offset by low operating costs. When one is evaluating the capital costs of various options the following should be factored in:

5.1.3 RUNNING COSTS
The running costs of a SCADA system include capital depreciation, maintenance, channel fees. There are also fault costs, operator training, stocking of spares. These costs are generally lower for homogenous systems with a strong technical direction. A shared communication network has fewer capital costs and can have low running costs if the communications configuration is done properly and charges are for amount of data.

5.1.4 COSTS OF UNAVAILABILITY
This is difficult to quantify but should include the possibility of fines for violating a resource consent after an unreported sewage flood or empty reservoir. If a control system is implemented which relies on communications and fails as a result of communications failure, there can be serious consequences.

5.2 USE OF STANDARDS
Standards will evolve further in the next decade but will solidify when 1.) it is a good standard, and 2.) the technology or process described by this standard is mature and unlikely to change.

5.2.1 COMMUNICATIONS STANDARDS
There are several levels of communications standards that need to be addressed here - the way in which messages get from point A to point B and the content and organization of these messages. The first challenge – delivering messages, is being solved with the widely accepted TCP/IP. This pops up everywhere – on LANs, the internet, WAN and even in substation control systems. It is not yet the universal answer because it requires lots of processing power and bandwidth to implement but the widespread acceptance of this protocol ensures that there is also a huge investment in hardware that is IP capable. Where things still get unhinged is how the messages (so faithfully delivered by TCP/IP) are organized. There are still a number of competing standards with no clear winner. As standards become more all encompassing they also become more complex and difficult to implement. The length of time for DNP3 to be widely used is proof of that.

5.2.2 CONNECTION STANDARDS
These standards will more and more govern the serial protocols and the isolation of serial ports that are used on devices interconnecting. Discrete connection, such as DI, DO and AI, AO, will remain but in a lesser capacity.

5.3 EASE OF USE
As SCADA systems become more complex and have added functionality they can become harder to use. This can be overcome by modularizing components such as SCADA software, database management, EMS and other application into manageable size projects that can be operated and understood by the interested parties. It will no longer be possible for one person to understand all facets of the system as it has in the past, however.

5.4 OWNERSHIP OF COMMUNICATIONS SYSTEMS
The trend for communications systems is towards higher bandwidth. This is pushing the complexity of communications systems to a point where a high degree of expertise is required and the capital cost of equipment is becoming unaffordable.

5.4.1 MORE COMPLEX SYSTEMS REQUIRE ADVANCED SKILLS
The trend towards higher bandwidth has put the ability to install, commission and operate these communications out of the reach of the technical skills of most utility operators.

5.4.2 SHARING BANDWIDTH
There is only so much room in the spectrum and it’s filling up fast. The name of the game will be sharing channels more efficiently and this is best done by a communications provider who manages its allocated part of the spectrum. A communications provider will also have the tools and skills to eliminate any unwanted interference in its allocated spectrum. A private channel is at risk from this.

5.4.3 LOWER COST OF OWNERSHIP
Because of the efficiencies of having one service provider manage the infrastructure and frequency and the lack of capital expenditure, the cost of using communications providers will tend to be lower in the future than that of having a private network. In addition, the running costs of a private network are probably going to rise as the technology becomes more complex and expensive to maintain and the price of spectrum increases.

5.5 INTERCONNECTION WITH OTHER SYSTEMS
Master station software will become more modular, with other products taking over reporting, management and other functions sometimes found in today’s systems. This is because each application has its own peculiarities and specialist companies often do better at them than SCADA software companies. This is particularly true of large database handling but also apples to GIS, energy management etc. The interconnection standards are good and we have little trouble with them. OPC is used for connecting to other SCADA systems and ODBC for database software.

5.6 OUTSOURCE SCADA
As systems become more complex more trained human resource is needed to operate and maintain the system effectively. With many reticulation system operators downsizing and cutting back we find that the maintenance of SCADA systems is becoming more and more outsourced. In some cases the operation of SCADA is outsourced. The situation is nearing the point where it may be feasible to set up a company to deliver SCADA outcomes to the user. The company chooses, installs, maintains and operates SCADA systems on behalf of reticulation system operators. This company would have expertise in SCADA (which would be scarce in many councils and smaller power authorities) and may benefit from existing comms infrastructures and economies of scale. This company would be contracted to deliver alarm annunciation, reports and control strategies to the user.

Watch this space.

5.7 HOW TO UPGRADE NOW TO BE READY FOR THE FUTURE
At the moment we are at a crossroads in technology for SCADA. We know that TCP/IP will be the major protocol and technique for the future but at the moment it is expensive and difficult to implement. It needs to mature. So what can we do now if we want to be ready for the developments that we know are coming?

5.7.1 AVOID PROPRIETARY TECHNOLOGIES
Some communications companies come up with technical innovations that can give significant performance advantage. These are patented and restricted to the innovator companies. The trend is for these to be very successful or widespread but the technology is superseded and it becomes unavailable. (Iridium is an example).

5.7.2 TCP/IP CAPABLE SYSTEM COMPONENTS
IP addresses and TCP protocol will be the dominant protocol of the future. At present there are not too many systems using this and most are flaky at the moment. While TCP based systems are too green at the moment they will mature and become the “way to go”. RTUs should have Tbase 10 connection and TCP/IP capability so that they will be ready for an implementation of a WAN type communications network.

5.8 AGAINST THE TREND
If the current system delivers the results that are required and the vendor is providing good support and is likely to do so for the future – why change?


6 CONCLUSIONS

6.1 SYSTEMS WILL CARRY THEIR HISTORY WITH THEM
It will be too difficult to discard an existing system and replace it with a new state of the art system. There are both operational and financial reasons for this. Systems of the future will comprise a siginificant ‘legacy’ component and improvements will be made on an incremental basis. It is important to manage this correctly to prevent the system becoming a dog’s breakfast.

6.2 THERE WILL BE A TREND TO USE COMMUNICATIONS PROVIDERS
Although there are good financial and operational reasons for having a private system there will be less and less financial and maintenance incentive to retain them.

6.3 TCP/IP WILL BE THE DOMINANT PROTOCOL
TCP/IP is a rugged, multi-path protocol that is widely implemented across the computer and data communications industry. Its features of multiple possible routes and robust scaleable connection make it ideal for telemetry applications. Rarely do specialist applications and mainstream technologies have such a convergence.

6.4 COST OF OWNERSHIP WILL BE OF PRIME IMPORTANCE
Technology is outstripping the needs of SCADA systems. The benefit is not increasing as fast as the costs. When this happens the cost of ownership becomes a prime driver and technological improvement should be focused in this direction

6.5 UNDERSTANDING AND USE OF STANDARDS IS VITAL
Because SCADA systems are held together by various standards their use and understanding is vital. The standards chosen to define the system should be mature, simple and well understood. This is not always possible but the trend is in that direction.