FOCUS: PIPELINES New demands for pipeline shaping scada systems

Ray S. Whaley
Pipeline Consultant
Houston

Michael L. Wheeler
PanEnergy Corp.
Houston

• Glossary [78965 bytes]

In the U.S. operating world following Federal Energy Regulatory Commission Order 636 (1992), operating a pipeline has radically changed, with pipeline companies becoming transporters of natural gas rather than buyers and sellers of gas.

The business cycle has decreased from monthly to daily and is now quickly moving to "within-day."

These developments necessitate changes in how the pipeline is run as well as in how operations departments interact with other business units. The result is the need for more functions and enhanced performance from the primary source for pipeline information, the scada system.

Operations, training

The gas-control department is the center of pipeline operation and the traditional owner and user of scada-system software. As the pipeline business evolves, pipeline operations must change. Some of the greatest changes relate to the time scales in which the pipeline is operated.

Operational changes to pipeline conditions are occurring more frequently, burdening gas-control operators to monitor and control the pipeline more closely. Pushing the pipeline to maximum efficiency requires that the reliability of the control system be increased.

Finally, heightened safety concerns have led pipeline companies to make improvements to operational procedures better to protect not only the pipeline and its product, but also the people and the environment near the pipeline.

Further, since the late 1980s, training of gas dispatchers has gained new attention among operators.

At that time, it was projected that government regulations would soon mandate formal training of operators. Although these regulations have not materialized, training remains an issue for many pipeline companies for various reasons.

Probably the most significant reasons would be the trend in most gas-control centers of the declining experience base among the dispatchers. For large complex pipeline systems, it is generally felt that 2-3 years of supervised on-the-job experience is required to train a gas controller properly. For most pipeline companies, this requirement represents an enormous investment in capital and time.

In an effort to decrease the time needed to bring on new controllers, most companies have initiated some formalized training program. Training, in any of its forms, has presented new challenges for scada master-station software.

Alarm handling; safety

Characterization, enunciation, and archival of alarms are capabilities of a scada master station software system which set it apart from other business applications.

The large number of alarms enunciated during pipeline operation can be difficult for an operator to assimilate properly. The pipeline of the 1990s, and to a larger extent of the next century, will have an even greater need for sophisticated alarm handling.

Increased automation of valve and compressor stations has generated a much larger set of potential alarms. Tighter control over the operation of the pipeline for safety and efficiency will also increase the number of alarms.

To meet the needs of gas-control operations, alarm handling must be expanded from the traditional ability of most scada systems. Alarm systems must be able to apply reasoning to group alarms so that the operator is alerted to those which represent dangers or emergencies without losing the ability to review less immediately severe alarms.

As pipeline operation becomes more complex, the alarming of conditions to the operator must be flexible and informative. This is particularly true as the experience base of pipeline operators continues to decline.

The need for more "after the fact" reporting and analysis of alarms is increasing with increased regulatory and litigation pressures. This will require relational archival of alarms.

The increasing importance of pipeline safety has led to a greater use of automated systems, such as remote control valves. While providing a means of quickly shutting in portions of the pipeline, these valves have also put a new demand on the gas controller to determine which valves to close after a pipeline rupture.

Although reliability has always been a requirement, there is renewed pressure to make systems as fail-safe as possible. Scada systems must be capable of staying active more than 99% of the time and include sophisticated capability to fail-over to a hot-standby system.

Disaster-recovery sites, a requirement for many pipelines, make it necessary that this hot-standby capability be performed over wide area networks.

Data, therefore, have become more valuable, producing the need for greater protection of their integrity which has led to wider use of "disk mirroring" (redundancy of storage) and other techniques to ensure soundness of data.

Business requirements

Until recently, choosing scada-system software depended almost entirely on the needs of gas-control operators. Data from the scada system was almost exclusively used in operations. Business applications functioned at a different level and on much larger time scales than did the real-time environment of gas control.

As pipeline companies seek to maximize throughput while minimizing the cost of operation, however, it is becoming necessary to function, on the business side, on shorter time scales. This has led to a closer coupling between real-time operations data and the business-application results which used to be exclusively in the domain of the mainframe computer.

As stated, FERC Order 636 forever changed pipeline companies from buyers and sellers of gas to providers of transportation for others' gas. More to the point, it has meant moving from a monthly to a daily business cycle.

Each day, customers nominate their transportation and storage of gas. Nomination of gas is from point to point (receipt to delivery) on the system and into or out of storage. It is generally the job of business units outside of gas control to schedule these nominations on the pipeline.

Gas Control, in physically operating the pipeline, must be aware of the schedule of gas because it has a large effect on the planned operation of the pipeline. If customers deviate significantly from the plan, gas control must know as soon as possible.

This interrelation of the gas controller's operating plan and the nominations from the customers produces the requirement that the scheduled volumes and the deviations of the actual volumes from these scheduled volumes are made available to the gas controller throughout the day.

Increasingly, gas controllers must also be aware of business opportunities in order to work better with the gas marketers and customers. Changes in economic and physical environments can force almost daily changes in operational philosophies.

With this increase of data movement back into the gas-control environment, scada systems must be capable of integrating real-time pipeline data with information from other data sources for display to the operator.

The move to performing business functions on shorter time scales is resulting in an increase in the volume of data which must be handled by the scada software.

Attempts to provide customers with greater flexibility, while protecting the deliverability of the pipeline through the enforcement of tariffs, have demanded that volumes be available hourly (or more frequently). This quick update of pipeline information can only be supplied by the scada system.

As more business units require operational data to perform their functions, the need to distribute data outside the traditional scada world is increasing.

Breaking down the barriers between operational data and business data makes securing the operational data of renewed importance. Firewalls must be put in place to maintain the integrity of pipeline data.

Use of operational data in business functions has produced a requirement for more-sophisticated data reduction and data handling. Raw pipeline data must be processed to produce information of value to the business units.

In addition to the need for tighter integration of data within a pipeline company, there are increasing needs to distribute pipeline information to the outside world.

Pipeline companies are now allowing customers and regulators to review operational pipeline data. Many companies are looking to use the Internet to provide an inexpensive vehicle for providing information outside the company.

Maintenance, reliability

Customers want a scada system that is both maintainable and reliable. Scada systems that require many custom software links, protocols, and special expertise are difficult to maintain.

Customers also want open standards which will allow them easily to link remote terminal units (RTUs) from multiple vendors and easily implement third-party software packages. It is a truism that a system which is more easily maintainable will be more reliable.

Customers will no longer accept a scada system which uses specialized hardware which is only available from and maintainable by the scada vendor. Customers want the scada system to be composed of readily available hardware components.

For consoles, this points to the use of PCs running Windows 95 or Windows NT. Not only are PCs inexpensive, they are easily upgraded and maintained by personnel within the pipeline company.

For reliability, customers require redundancy in many of the scada system components. The system should be able to have alternative communications paths in the event of communications failure (Fig. 1 [33921 bytes]). A common requirement is to have a backup for disaster recovery.

Pipeline companies also desire a scada system that is scalable. The almost daily addition of new field instrumentation requires a degree of flexibility in a scada system that is much greater than older generations provided.

And users would like to be able to take advantage of upgrades in functionality without large license-fee charges or costly downtime during software change-out.

Scada-system technology has progressed significantly from the specialized systems of the 1980s. Recent developments are producing powerful and flexible systems to address the emerging needs of the pipeline industry.

Advances have been made in the basic structure of scada software and its dependence on specialized hardware. Data-handling capabilities are becoming powerful, with full links of the realtime databases (necessary to meet the reliability and speed requirements of scada systems) to commercial relational databases.

Perhaps the most dramatic advances have been in the capabilities of the interfaces with humans. Such interfaces are being developed as powerful graphical representations of information.

Platforms

Several years ago, the platform of choice for scada master stations was VAX running VMS.

With the emergence of the workstation and server markets, UNIX became a major player in the scada world. Vendors taking advantage of the openness of the UNIX market and availability of software products now dominate the high-end scada market.

Most recently, the scada market has been moving towards Windows NT as the dominant operating system. Windows NT promises many of the strengths of both VMS and UNIX.

For example, NT will run on multiple hardware platforms, not being tied to any particular hardware vendor. Although most applications are being developed for NT running on Intel-based hardware, it will be capable of running on much of the server technology (DEC Alpha, for example) where speed is of concern.

Since NT is being developed by a single company (Microsoft), it should be more uniform across hardware platforms than even UNIX. NT also offers a great degree of scalability because it runs on anything from PCs to high-end multiple CPU server-class machines.

Windows NT (or Windows 95) is being adopted first by some scada vendors as a console platform. It is anticipated that later it will be adopted as the scada host or server.

The use of NT for the console platform has many advantages, including the ability to display scada screens on the same console as many common business applications which have been developed for the Windows environment.

Intel-based systems are becoming more prevalent and much more powerful, and Intel is the hardware platform of choice for Windows NT. Therefore, it is anticipated that there will be more applications developed under NT running on Intel hardware than on any other platform.

As Intel CPUs gain in processor speed and capability, the clear advantage in remaining with any other hardware platform will lessen.

Data handling

Scada master stations have traditionally been built around a proprietary real-time, memory-resident database which was necessary for reliability and execution speed.

Although scada systems still require this type of real-time database for the storage of scanned data, the data-handling capability of today's systems has been extended dramatically.

The need to archive operational data so that they can be easily manipulated and retrieved has led many vendors to use commercial relational databases as the long-term repository for pipeline data. Some have provided this capability in the form of a bridge, allowing the user to specify which database is to be used.

Others have fully integrated one of the popular databases into their product to improve the performance of the system. In this type of application, it seems that most vendors have gravitated toward the use of Oracle or Sybase.

The archival of data in a relational form allows access by other applications outside the scada system. In this way, scada vendors are meeting the requirements of pipeline companies to use scada data in business applications outside the traditional gas-control environment (Fig. 2 [20134 bytes]).

Some scada systems use a secondary relational database for this purpose. The primary database is used to provide advanced applications in the control-room environment. A data manager moves information from the primary database to the secondary database.

Some scada systems use a secondary relational database for this purpose and to protect the integrity of the primary database. The primary database contains historical measurement data and the results of advanced scada applications.

A data manager task within the scada system moves information from the primary database to the secondary database where it can be accessed by other business units and applications.

This structure provides a "fire wall" between the scada system data and external applications.

Passing of information to and from the scada system through relational databases also allows for a tighter integration between the scada system and third-party applications.

The presence of scada data in the relational database allows free access to this information for applications that are executing functions which run in real-time, such as leak detection, batch and composition tracking, and simulation modeling, to name a few.

Applications designed to reduce the operational data into an information stream to be used by other business units inside the corporation also have access to the data in as much detail as is required.

Applications can freely output the results of their calculations to tables with similar structures inside the relational database, thereby allowing the incorporation of this information within scada applications.

This free interchange of information allows the scada software to function more as an integrated environment rather than the niche application of years past.

Communications

Scada systems utilize primarily two types of communications:

• The system communicates with RTUs in the field.

• Scada software must also communicate the data to the controller through console graphics and also to field personnel via fax, pagers, corporate network, dial-in phone lines, etc. (Fig. 1 [33921 bytes]).

Future technology will provide access to scada information via intranets and the Internet.

Pipeline companies with interconnections have a need to exchange operational data. Currently, this requires either a direct link to another company's RTU or a custom host-to-host link. When secure data-interchange standards are developed, exchanging operational information via the Internet may become commonplace.

Communication with field devices can occur in many ways: microwave, cellular, satellite, leased line, etc. The trend has been to use multiple methods of communicating because each method will have a cost or performance advantage for a given installation. This trend will continue with the Internet providing one more means of communicating with field devices.

In addition, pipeline companies are requiring that their scada systems connect to many different vendors' RTUs.

As of today, there are few widely used open standards for protocols which would easily allow this type of flexibility.

Scada vendors have responded to the lack of standards by bundling many RTU protocols with their systems and in some cases by supplying tool-kits that allow the development of custom protocols within the scada system.

The electric-power industry is developing standards which may cross over into the oil and gas industry.

The Utility Communications Architecture (UCA) developed by the Electric Power Research Institute (EPRI) is showing promise of taking hold in the electric power industry. There has been talk within the oil and gas industry of adopting it as a standard.

Perhaps the largest area of development in the modern scada system is in the human interface.

In an effort to support the trend toward less expertise among the pipeline operator work force and the need for systems which are easier to use, much effort has been put into building more intuitive graphically oriented user interfaces.

Windows front ends

Older systems were built around proprietary graphics-based software which was sometimes limited in capability and difficult to learn and maintain.

Most modern scada systems have moved or are moving to Windows 95 or Windows NT front ends as opposed to the X-Windows based graphical user interfaces (GUIs) of several years ago. This movement to the Windows standard is obviating the need for specialized display-system hardware.

The adoption of the Windows standard also provides increased flexibility in the integration of applications data within the control room.

Although these systems allow for easy integration of data into the scada environment through the use of the relational database structure, systems which run in Windows can be integrated into the controller's work environment with no migration of data because the application can be presented alongside the scada applications on the same system displays.

If the look-and-feel of the external application conforms to Windows standards, the mere presentation of the application in the same environment provides for a fairly seamless operation.

The human interface is no longer tied tightly to the real-time database as in systems from the last decade. Recent advances have provided the capability to display virtually any data stored in a relational database table.

Real-time data can normally be mixed on any display with data from external or scada applications. The interface between the GUI and the database has also become standardized, making use of standard database and software module linking procedures.

Data access has become more versatile. Some systems provide for the mirroring of all real-time data on each computer on the network, allowing fast access to real-time data from any application.

Outside the control room

The standardization of the user interface to function on commonly available Intel-based systems has provided a means to allow access to the scada system from outside the control room.

Although dial-in access has been common for many years, users accessing the system remotely were accustomed to limited access to data and virtually no reasonable access to graphics.

Because the primary display engine in the newest scada systems is Windows based, the barriers to full remote access to the same displays used in the control rooms have been removed.

Users can dial into the network with the appropriate passwords and view virtually any display needed to review pipeline data and even make changes to the system. This greatly simplifies remote access by control room supervisors who may be physically removed from gas control to review a pipeline situation.

Displays' definitions are kept locally on the PC so that only updated data are sent over the phone line, keeping network and phone traffic to a minimum.

Display maintenance is handled via smart-monitoring programs which detect that the display has changed from the one currently on the remote machine and then download the updated screen definition only when necessary.

Advances have also been made in wireless communication. Systems are now being fielded that can accept and use cellular communications. Critical alarms can be automatically raised to supervisors and other on-call personnel using pagers with text capability.

Some scada vendors advertise the capability to access scada displays and data through a corporate intranet. Some browser-access capability, much like that used on the Internet, is starting to become available.

This type of access, although not particularly useful to the controller, can be important where many people within a company have some need to review scada data but are not frequent enough users to justify any normal scada access.

Training in the mechanics of accessing the needed data is reduced because the search-engine capabilities of these systems will allow even the uninitiated (possessing the appropriate security clearance) to find the needed material quickly. This capability can readily be extended to give access to the scada system through the Internet.

The advent of private and public key access security systems will ultimately allow companies to provide this capability to their customers without compromising the integrity of their systems.

Important new technologies becoming available include the adoption of object-oriented data and functions, the inclusion of rules-based logic within the scada system, and the adoption of geographic information system capability.

Object technology

The software industry is currently progressing toward object technology. Objects hold the promise of not only reducing development time of the scada system and components, but also of increasing the ease of adding new field devices, communications devices, and applications.

Artificial intelligence

Use of rules-based logic or expert systems within scada will be a major enhancement in the near future. Scada systems currently include simple rules for alarming when high or low limits are exceeded or when measured values change too rapidly.

The problem with these simple limits is that they lead to a proliferation of frequently meaningless alarms and are unable to evaluate situations involving multiple points or sites.

Rules-based logic has the potential of reducing the amount of data operators must review while increasing the amount of meaningful information. Rules do this by automating the analysis performed by an operator to check out the meaning of limit alarms and by allowing more complex checks of multiple sites or values.

Drawbacks to the use of these systems include the high cost of purchasing a third-party artificial intelligence package and the high degree of technical expertise required to set up and maintain it. Currently, customers must either use the simple rules "hard coded" into the scada system or purchase a complete AI package.

Scada vendors will easily increase the usability of their systems by providing as standard software a third alternative which allows the creation of more complex rules while not requiring use and purchase of a third-party package.

Schematics integration

Customers are struggling to determine how automatic mapping and facility mangement (AM/FM) and geographic information systems (GIS) and schematic drawings integrate into the scada system.

Operators benefit from having data presented on top of schematic representations of the pipeline and stations. These schematics, to be useful, must be updated to reflect changes which occur in the physical facilities.

Also desirable would be the ability to view more-detailed information like streets, subdivisions, facilities, and other pipelines that relate to the pipeline being operated and its facilities.

GIS has the ability to provide this type of information.

Being "connected"

Perhaps the most exciting advancement for scada systems is interaction with the user.

The emergence of the Internet and the connectivity it provides make it a natural vehicle for communicating results both to company personnel outside of the corporate offices and to outsiders who have a need-to-know.

Scada providers are moving toward providing browser capability with the latest Internet development tools (the Java programming language for example). This will allow the user to set up easier access from outside the control room, allowing field personnel to review not only data as it is scanned from the field but also the results of scada and external applications that heretofore have been relatively inaccessible or at the least, expensive.

This capability will be available with no more sophisticated equipment than a laptop PC with a modem and a phone line. Customers will be able to access applications to get up-to-the-minute information regarding available capacity, schedules, nominations, and deliverability.

Browsers will make it possible to provide advanced functionality without the need for extensive training for the user of the system.

In order to allow a more widespread access to pipeline information, systems will be developed which will be able to understand requests for information which are not in a rigid computer syntax.

Acknowledgments

The authors would like to acknowledge the assistance and contributions of Howard Shaw of Texas Eastern Transmission Corp., Houston; Kerry Reed of Panhandle Eastern Pipe Line Co., Houston; Peter Dean, Valmet Automation, Calgary; Larry Smith and Ken Hanks of GSE Systems, Columbia, Md.; Ardis Bartle of Praxis Instruments, Houston; and Doug Denzer of Teledyne Brown Engineering, Richardson, Tex.

The Authors