Analysis guides decision to expand or replace SCADA Interim steps can extend life of systems rendered obsoleted by technology

and business changed.

While technical advances and business changes are combining to render some older pipe line supervisory control and data acquisition (SCADA) systems prematurely obsolete, several techniques are available to help operators extend their systems useful life. With their system stabilized, operators can focus on accumulating data to technical documental and economically justify partial or full system replacement. Stabilizing system. On many older SCADA systems, there comes a time when maintenance costs become prohibitively high, hardware breaks routinely and the spare- components inventory dwindles. Some system components are no longer manufactured and, even if the original supplier is still in business, service often is unavailable or unacceptable. Usually, by the time maintenance problems get this severe the system is old enough to justify replacement. But what can be done when replacement has not been adequately planned and budgeted? Finding spare parts and other sources of services is not difficult. Operators can star with the original supplier. If that firm is not in business, try their former employees. Identify other system users and service providers. More than likely, the system was one of several produced by the supplier, and some have been taken out of service. It may be possible to get spare parts form former users. Develop a network of key contacts who can offer parts, documentation and other service sources. This is the simplest way to keep and old system working. It does not involve deredesign. The parts can be obtained at little cost. Even without alternate service sources, the larger spares inventory should help withstand the longer repair times and higher non- repairable rates associated with older equipment. Finally, stabilizing an older system provides time to plan a lasting solution. That will involve expanding the system as needed, including upgradeing or replacing components. Upgrading remote stations. Before upgrading remote terminal units (RTUs), operators must determine equipment limitations and what tasks the equipment is expected to perform over the next several years, RTUs usually are limited to a fixed number of points or a fixed number of I/O card slots. Often, space is provided for I/O card installation and/or I/O terminations in the field, up to some predetermined limit. Some RTUs can be expanded by adding another card chassis, but the power supply may not be able to ankle the added load. Even if there is room for an additional card chassis, there may not be room for the necessary I/O terminations. These difficulties make field upgrade a questionable proposition.

When RTU expansion requires more than simply adding I/O cards or terminating wires, a field upgrade probably should not be attempted. Instead, build an RTU form spare components, then substitute it for the field RTU, and return the replaced units parts to the sparecomponents inventory. If several RTUs are to be expanded this way, it may be useful to buy one new RTU and configure it to serve the systems largest site. Take the replaced RTU and use its parts, along with purchased parts, to build the next one. Continue this process until all the RTUs probably will word at smaller sites with little modifications. Some RTUs cannot be expanded. They must be replaced or paired with a second unit. Replacing remote stations. If forced to replace remotes, operators should consider decommissioning a few, and substituting new ones. The advantages of this partial decommissioning are reduced maintenance problems and a stock of spare parts that buys more time to deal with the remaining remotes. By replacing only a few RTUs at first, operators get to experience any resulting problems before it is too late to change course. Once the replacement program is fine- tuned, operators can proceed as quickly as resources allow. This selective- replacement solution is not without its problems. First, compatibility with the existing master station needs to be a confirmed. It may be necessary to have some customs hardware or software designed for the new RTUs to properly interface to the system. Ensure that the replacement RTUs can provide any additional functionality that may be required during their lifetimes (10 or more years). Operators should move cautiously because these considerations may increase risk. Master station limits. The most obvious sign that the system has reached maximum capacity is that it will not accommodate additional points. This condition usually is caused by memoryaddressing limitations in the older software. Sluggish performance is another symptom that indicates a master unit (MTU) is approaching its capacity. Points and displays are not updated as foten as they once were or more importantly, as often as needed for safe and efficient operation. The system also is less responsive to operator input. As more pints are added performance deteriorates at a faster pace until it reaches unacceptable. Sluggish performance has three common causes. Firs, the system could be approaching full utilization of the central processing unit (CPU). Sluggish performance will continue to deteriorate as more points are added. Even at 100% utilization, the CPU most likely will continue to operate, albeit slowly. Another casue is full memory utilization. This is common on virtual- memory machines that swap programs to and from disk to use memory more efficiently. As pints are added, they must be fixed in memory and are not allowed to be swapped. This results in less memory available for swapping, slowing the machines response or locking it up.

The third cause is full communications channels. In this condition, the points take too long to update. However, response to operator input should not be affected, unless the response requires use of the communications line. A cursory look will not always reveal the cause of sluggish performance. To further complicate diagnosis, the three causes often act in concert. Suppose the communications line is determined to be at the culprit. Increasing communications capacity will then place a heavier demand on CPU and memory. This only shifts the cause of the sluggishness and has little effect on overall performance. There are other factors that can limit master station expansion. Without assistance from the original supplier, expansion often is impossible due to lack of source code and adequate development facilities. Upgrading master station. MTU upgrades fall into three basic categories: Adding more remotes and points. Adding new applications programs. Adding of changing drivers to communicate with new types of remotes

MTU upgrading can be expensive, so the decision must be carefully considered. Before attempting upgrades, operators should thoroughly analyze their system to ensure he upgrade is technically feasible and the investment is not wasted on a system with limited remaining useful life. The analysis should include: Review future requirements. This includes more than just the number of points that eventually will be added. Also consider future functionality. Evaluate barriers to expansion. Operators need to anticipate and estimate the cost to cross each technical barrier the upgrade reveals. Estimate sots and prepare a schedule to accomplish the upgrade.

Replacing master station. Sometimes replacing the entire system of just the MTU is the best choice. Either project is a major undertaking. Without adequate planning and preparations, serious disruptions to the companys operations can occur. Expansion is determined to be impossible. Expansion is possible, but not cost- effective. Expanding the system would be too risky because the resulting capacity is unknown, no one with experience in the system can be found and development tools and documentation are incomplete.

Bad reasons to replace a system: Just because it is in the budget. For the sake of using new technology.

Justifying replacement. Almost as important as the replacement process is the justification for replacement. SCADA system users and maintainers usually have a gut feel for when as system

needs to be replaced. However, unless that need can be effectively communicated to management, authorization for a new SCADA system will be withheld. This is only reasonable, after all. Replacing a SCADA system represents a large capital outlay, and as said before, there are ways to stretch their useful lifetimes. Furthermore, with technology changing so quickly, there is the reasonable fear that the replacement will soon be obsolete. So without a compelling argument for replacement, management really should deny the request. An effective budget proposal for the replacement of a SCADA system should include the following elements. Needs analysis. This part of the proposal should discuss present and future needs, and prove that the existing system cant meet the needs. Benefits analysis. This discusses the benefits to be derived from a new system. It relates the benefits to cost improvements. Maybe the new system will allow personnel reassignments or provide a service that increases company competitiveness. If operators will be able to expand the system without hiring contractors, the benefits analysis should report that. Cost analysis. Operators should compare upgrade costs to replacement costs. Estimate the cost of expanding and maintaining the existing system at the level needed to meet all needs and to receive all desired benefits. Show these expenditures as yearly costs over several years. Then show the cost of acquiring and maintaining a new system over the same time. If operators are unable to arrive at either a needs- based, or cost- based justification, they probably should give up on the replacement idea, and reconsider expanding the existing system.

Migration process. SCADA migration should be thought of as a process, not a goal. In other words, as the company moves from its present system to a new one, operators should think not only about the immediate changes, but also about future changes. What can be done now to make the next replacement easier? By designing with sub- system replacement in mind, operators reduce their risk by turning a large project into a series of smaller projects, spread over an extended time. The alternative is to replace the system as one large high- risk, high- profile project, whose commissioning must, by necessity, be compressed into an unreasonably short time frame. In designing the system, operators should keep the applications programs separate from the SCADA functions. Vendors should be required to supply a high- level language interface to the SCADA database, both real- time and historical data. Also require vendors to supply an SQL interface or, at least, some method for exporting data to a third- party, relational, objectoriented database. With this database, operators can do all reports, data analysis functions, and long- term data storage there. This division of responsibilities can even be carried into the SCADA system itself. Operators should consider separating SCADA functions into data gathering and man- machine interface. Putting the data- gathering functions into a client- server front- end processor further

strengthens this separation. It then becomes technically and financially reasonable to upgrade or replace these modules independently from one another.