7.1 Introduction

The daily operation of pipelines has long since been computerized by “SCADA” systems (supervisory control and data acquisition). In its simplest definition, SCADA is a computer network that gathers all the pipeline operational data and brings it into a control room for humans to view and make control actions on. In other words, SCADA can be thought of as the eyes and ears of the people who control the pipelines. SCADA has brought measurable and tangible benefits to the owners and operators of pipeline assets, most notably in terms of safety due to the real-time nature of the SCADA control systems.

Because of the proven benefits provided by SCADA to pipeline owners, as well as to the environment and public at large, SCADA systems are considered mission-critical and vital equipment to pipelines. In fact, most jurisdictions around the world have legislated that SCADA systems be installed as a necessary part of all petroleum pipeline systems.

The SCADA system consists of several parts including sensors, RTUs/PLCs, computer servers, computer workstations, communication infrastructure, computer networking equipment, and various peripherals (such as a GPS accurate time reference source and many other items). Some equipment is, by necessity, located out at field site locations, while the focal point of the SCADA system is located in one or more pipeline control rooms.

Unfortunately, the industry use of the term SCADA is somewhat ambiguous; some use the term to refer only to the software displaying operational data to the pipeline controllers, such as pressures, temperatures, densities, and flow rates, while others using the term also include the sensors and the RTUs that manage them. In this chapter, the term SCADA will be used in reference to both the pipeline control software and the RTUs which sit out in the field and interface to the sensors.

SCADA systems can generally be classified as either enterprise level or as HMI systems. HMI SCADA systems are simpler and historically were limited to data collection and presentation, whereas full-fledged enterprise SCADA goes further by including many additional features. Examples of features distinguishing HMI and enterprise-level SCADA are as follows:

• Ability for additional “emergency backup” control rooms.
  
• The quantity of I/O points the SCADA system can manage.
  
• Hardened system to protect against hackers and cyberthreats.
  
• A “human factors” interface to avoid human operator error and enhance efficiency.
  
• Ability to replay historical events captured by the SCADA system for incident review or training.
  
• Operator training scenarios.
  
• Advanced alarm management.
  
• Operator shift handover report.
  
• Rapid polling of screens being viewed by operators.
  
• Interfacing to related computer systems such as leak detection, batch tracking, energy management system, equipment maintenance systems, and pipeline hydraulic simulation.

There can sometimes be confusion with those not familiar with the industry about a similar product called DCS (distributed control system). While very similar in many regards, in that both SCADA and the DCS ultimately collect and display data from sensors in a real-time fashion, the DCS was designed to be used in processing plants where the physical distances between the sensor and computer control system are relatively small. SCADA, on the other hand, can span distances of almost any geographical distance. Large pipelines often exceed 5000 km in length with sensors spread across the entire length, and this is the domain of SCADA systems, where the DCS would not be able to do this.

7.2 SCADA Computer Servers

The backbone of the SCADA equipment in the control rooms is the SCADA server computers. These computers communicate with and gather data from the RTUs and PLCs out in the field, maintain the SCADA real-time database, maintain a historical database of past values, an interface to other computer systems, and generally do everything except provide the graphical interface for the human SCADA operators.

Best practices for maximizing pipeline integrity require that each SCADA server should contain internal redundancy in the form of dual power supplies, RAID hard drives, dual Ethernet interfaces (connected to dual SCADA LANs), and possibly dual CPUs.

To further the concept of redundancy, SCADA servers are delivered in pairs so as to provide a main unit and a hot standby. A good SCADA system will improve upon this by load sharing between the two servers under normal circumstances and reverting to one or the other server if either should fail.

SCADA servers may be Windows-based, but UNIX servers are often better suited to industrial applications such as SCADA due to the Windows operating system not having been designed for “real-time” applications.

In all but the smallest SCADA systems, the servers are usually delivered without video display, mouse, nor keyboard. Rather they are normally rack-mounted computer hardware providing the background work of the SCADA system. The SCADA system’s user interface is provided through the SCADA workstations.

7.3 SCADA Computer Workstations

The SCADA workstations exist to present the GUI to the human operators. SCADA workstations are often outfitted with multiple LCD panels with a specific arrangement designed with the physical control room layout in mind. 2 × 3, 1 × 4, and 2 × 2, are all common arrangements.

The number of SCADA workstations in each control room should be a function of the pipeline operations and is proportional to the length of the pipeline(s) being controlled (larger companies usually have a network consisting of numerous pipelines, all being controlled from within one control room). Obviously, the minimum is one SCADA workstation, whereas the largest pipeline control rooms contain up to 30 SCADA workstations.

Due to the client/server software model, SCADA workstation hardware need not be as hardened as the SCADA servers. Often high-end, off-the-shelf PCs are the best choice for SCADA workstations. Usually, the most important parameter of the SCADA workstation is its graphics ability, which is a function of the video card in the computer.

Although there is no need for high fidelity, most SCADA systems produce alarm sounds when a process variable exceeds its nominal range. As such, SCADA workstations should have volume-adjustable audio capability.

Currently, the human operator interfaces with the SCADA workstation mostly by use of the mouse, and to a lesser extent the keyboard. However, emerging trends are increasingly augmented with haptic touch screens.

7.4 Hierarchy

Enterprise-level SCADA systems should be able to be implemented in a hierarchical fashion. In a large distributed system, it may be desirable, for example, to have completely independent SCADA systems for each separate region, but a higher-level master SCADA system that receives summary data from each of the lower SCADA systems, thus forming a hierarchy. In fact, this idea of a hierarchy of SCADA systems can consist of more than just two levels; conceptually, it should support three or more levels. For example, SCADA at a municipal level, then provincial level, and finally national level or, alternatively, a pipeline company could have separate SCADA systems for its gas pipelines versus crude pipelines versus its liquid products pipelines and an overall SCADA system on top whose database is the sum of the three lower-level SCADA systems.

Depending on the pipeline operator’s needs, it is not always necessary to push the entire database up to the next level of hierarchy. Instead, it should be possible to identify the specific data in the lower-level database that are needed in the higher-level database. Thus by picking and choosing data points, a customized summary of data can be pushed up to the next level of hierarchy.

From a pipeline integrity point of view, one benefit that this approach can provide is additional personnel to observe and review operations in real-time.

7.5 Runtime and Configuration Databases

Although not universal in all SCADA systems, best practices in SCADA technology require that there be separate databases for the live runtime data and system configuration. The main reason for this is to allow for system changes to be made and possibly tested out on a development server before being committed to the runtime system. Any SCADA package that does not provide this database separation will have system development being done on the live runtime (production) database. Obviously, the consequences of making an error when editing a database is more severe if those changes are made on the live runtime database.

The purpose of the configuration database is to hold the SCADA system parameters. This would be information such as how many RTUs and PLCs there are. How many I/O data points each contains, the computer address of each one, the login user IDs for each human SCADA operator, and generally all system information.

The purpose of the live runtime database is to not only use the configuration database as a framework but also to populate it with live data.

These two databases are linked through a process called a commit.

The best SCADA systems will offer a feedback mechanism between the live runtime database and the configuration database. The meaning of “feedback” in this context is a software mechanism to allow the human SCADA operators to fine-tune certain system parameters on the live runtime database and to have those parameters automatically updated in the offline configuration database. This is a unique and uncommon action as the data flow is normally from the offline configuration database into the live runtime database. Feedback is normally automated for only a small subset of the overall system parameters.

7.6 Fault Tolerance

In any SCADA system that includes interfacing to more than a single RTU or PL,C it is an important design criterion that the SCADA host should be fault-tolerant. The general design question to keep in mind is: “Is there a single component (software or hardware) that if it fails will prevent SCADA from monitoring and controlling the critical field devices?” Note that a failure of a single RTU will prevent monitoring and control of field devices connected to that RTU, but should not affect the other RTUs, and so usually failure to communicate with a single RTU is not considered critical. However, if there is a single RTU that is considered critical, then that RTU itself should have some fault tolerance built into it, such as a dual communication line, dual processor, or the entire RTU could have a hot standby RTU.

The simplest level of SCADA fault tolerance is called “cold standby” and achieved by providing two identical pieces of hardware installed with identical software. If any component fails, then the failed device is manually swapped out with the spare from the cold standby. As this requires a skilled technician on call, the main drawback of this method is the time it takes to fix a problem, and the second drawback is that it requires a regular maintenance step to ensure that the spare devices are working properly and available to be swapped in.

The second level of fault tolerance is called “warm standby.” It is similar to the cold standby setup, but the hardware is physically installed and running. If any component fails, it should be set up so that it can be easily swapped out as a whole unit by moving a switch or moving some cables. This significantly shortens the time to fix a problem and lessens the requirements for the technician that initiates the swap. The warm standby still should be checked regularly to make sure it is functional. In this setup, there are often procedures that must be followed after a switch over as the most current configuration might not be installed on the warm standby computer, and recent information such as current process variable setpoints would have to be re-entered.

The third level of fault tolerance is called “hot standby.” It is similar to the warm standby setup, except that databases on the two hosts are kept up to date, and it is possible to easily switch control between the two computers. How up to date the hot standby server is varies by the SCADA vendor and can be as little as a fraction of a second to as high as several hours old. For a hot standby setup, the communication links to the RTUs must be designed to be easily switched from one SCADA server to the other. Ethernet connections are fairly easy to switch over; serial connections will require a changeover switch. In this setup, the SCADA host software should be able to automatically initiate a swap if it detects a failure of the active host, or the operator should be able to initiate a swap.

The fourth level of fault tolerance is called “function-level fault tolerance.” It is similar to hot standby, except that if a single function fails, for example, a serial port used to talk to an RTU, it is no longer necessary to fail over the entire host computer. In this mode, individual SCADA features can be swapped over from one server to another. This makes an overall SCADA system much more tolerant of small failures and makes it much easier to test standby hardware. This also opens up the possibility for load-sharing when a stand-by would otherwise be unused.

In any fault-tolerant system it is very important that the standby hardware be tested on a regular basis. The most reliable means of testing this is by initiating a swap on a regular basis such as once a month. Depending on the hardware, it might be possible to test backup lines automatically. For example, to test backup communications to an RTU, the RTU must be able to support talking with two hosts at the same time. Remember that a backup system that is never tested is very likely to not be working when it is really needed and thus would not provide any fault tolerance.

7.7 Redundancy

Beyond the above-mentioned software concept of fault tolerance, physical redundancy is one of the most effective tools a pipeline operator can employ to improve pipeline safety and integrity. The basic notion is to provide two pieces of equipment to do a single job: a main and a backup. This concept of the main and backup can be simultaneously employed at three levels. The lowest level of physical redundancy exists within the computer servers themselves. The SCADA servers should be designed with dual power supplies, dual Ethernet interfaces, RAID hard drives, and dual CPUs.

Once each SCADA server is built with inherent redundancy, the second step is to provide not just one such server but two such SCADA servers in the control room. In this way, even if one SCADA server is rendered ineffective, a backup SCADA server remains available to take over. This is important because even though many components of each server are provided with a backup, not all components are. For example, the motherboard itself is not redundant. Although it is unlikely that all those components would fail, if they did fail, then the entire SCADA server would be out of commission, and so it makes sense to have a backup.

Beyond these is the third and final level of redundancy, which is redundancy of entire control rooms. This is a growing trend in SCADA systems and has legitimate value. History has shown that natural forces can be unpredictable and intense. Threats of tsunami, earthquake, tornado, fire, hurricane, and so on make an entire control room vulnerable. Even if a control room contains two SCADA servers, each of which has redundant components, a tsunami will knock out both servers if it knocks out one, hence the logic behind a second control room situated some distance away, often 50–100 km distance between control rooms.

Although the concepts of fault tolerance (described above) and redundancy overlap, there do exist some differences.

Clearly, the best approach is to use both redundancy and fault tolerance.

7.8 High Availability

Redundancy, as just described, relies on additional software or hardware to be used as backup in the event that the main functionality fails. The primary goal of high availability is to ensure system uptime in the event of a failure.

With the continuing adoption of commercial off-the-shelf (COTS) technologies, typically from the business environment into the operations realm, bringing the associated capabilities with it, redundancy can now be economically further enhanced to a high availability arrangement.

High availability is a concept that involves the elimination of single points of failure to make sure that if one of the elements, such as a server, fails, the service is still available. This can be achieved through a combination of physical equipment and virtual environments with suitable software known as an orchestrator to manage the different elements contributing to an “always on” environment.

One of the roles of the orchestrator is that in the event of a failure, it is rapidly detected and another instance of the function is brought into service.

High availability systems operate as a single, unified system that can run the same functions of the primary system they support so that if a service fails, another node can take over immediately to ensure the service remains operational. High availability if executed properly eliminates downtime, including support for updating or adding new capabilities without downtime.

Being able to update and maintain the SCADA system without requiring a physical outage of the process, for example, to install a security patch as the name implies, increases the availability and reliability of the system as a whole.

7.9 Human Factor Design in SCADA Systems

The pipeline industry in recent years has formally acknowledged the value of human factor design in SCADA systems—shown through recent U.S. regulations such as the amendments made to 49 CFR Parts 192 and 195 regarding Control Room Management (CRM) and the Pipeline Inspection, Protection, Enforcement, and Safety Act (PIPES) requiring a human factor plan to CRM. The value of assuring that central control systems are designed to provide early detection of abnormal situations, in a manner which does not provide a stressful environment for the human operator while also recognizing the need of fatigue management, has been recognized in the refining and process industries for many years. There is a wealth of knowledge from the ISA, NPRA, and other organizations that can be applied and adapted to the pipeline industry.

The key elements of an effective human factors plan for control room management (see references) require the design of the SCADA system to equip the operator with the information needed to properly operate the pipeline safely and reliably. The manner appropriate for delivering this information needs to consider the ways humans process information, at all times of the day, after many hours on shift, as well as how to capture and transfer this information through to the next shift.

After the National Transportation Safety Board intensively investigated the root cause of past pipeline incidents, they identified five areas for improvement: graphic displays, alarm management, operator training, fatigue management, and leak detection. Graphic displays and fatigue management have common elements, but in addition, the physical control room design has a significant role to play in fatigue management via elements such as room lighting, monitor placement, and separation of areas of responsibility.

As computer graphic displays are the primary method for control room operators to visualize the big picture of the state of their entire pipeline operations, this is often considered the top opportunity for improvement when first implementing a “Human Factors Approach.” The recommended practice for pipeline SCADA displays API RP 1165 is expected to be followed, and expert practitioners have applied the research from industrial psychologists to achieve significant improvements in operator comprehension and speed of response. Some of the main considerations when developing graphics optimized for human factors are to “selectively use reserved colors” against a gray-scale background versus the traditional “black background utilizing the full color spectrum.” Also, providing a confirmation identification element that can help color-insensitive personnel confirm their understanding of the situation is key to allowing a clear diagnosis of the issues by the general control room population.

These advancements to graphic display designs have reliably shown improvements to comprehension and response time of over 50% and in addition have shown that the learning curve is significantly reduced for inexperienced personnel who tend to be the most vulnerable during times of emergency. Despite the recognized value of using a “human factors” gray-scale approach, it is often difficult for existing operators to be enthusiastic about losing their black background graphics. As with any change, there is an adjustment time, additional work, and re-training. However, operators who move on to a new area of responsibility do appreciate the human factor gray-scale approach and are able to master the new area earlier than ever before.

Of course, taking a human factor approach to pipeline design, operations, and maintenance has applications and benefits beyond the control room—as is shown in the human factors chapter (Chapter 15) in this book.

7.10 Alarm Rationalization, Management, and Analysis

Alarms notify human operators about abnormal situations so that they can respond in a timely and effective manner to resolve problems before they escalate. Studies have shown that the ability of operators to react to alarms depends largely on how well alarms are rationalized and managed.

In the early days of SCADA, alarms had to be hard-wired to physical constructs such as flashing lights and sirens. These physical limitations forced designers to be very selective about what to alarm upon. By comparison, modern software-based alarms are often considered free. This creates a common mindset where anything that can be alarmed upon is configured to do so. The result is a SCADA control room with a constant overload of alarms, often unnecessary or unimportant, which operators are expected to filter through when searching for “real” alarms with serious consequences.

Efficient alarm management begins with proper alarm rationalization. Every alarm configured in the system must be considered carefully by a team of experts with operational domain knowledge. Consequences with regards to safety, finance, and the environment must be factored in. The goal is to create as few alarms as possible, while accounting for all serious consequences. The approved alarms and procedures for responding to each alarm should be captured in a Master Alarm Database (MADb), which is then periodically reviewed by the team. The MADb serves as the foundation for configuring alarms within the SCADA system.

Alarms must capture an operator’s attention, and depending on the severity of the alarm, this is done using a combination of graphic effects such as flashing colors and repeated sounds. It should be easy for the operator to distinguish the process variable in alarm from other process variables which are not in alarm. For example, a red flashing border stands out against an otherwise gray screen. Operators should then examine and acknowledge the alarm.

Information which can help the operator react to the alarm should be easily accessible from the context of the alarm.

A summary list of recent alarms helps operators identify when an alarm occurred, the nature of the alarm, its severity and scope, whether it is still in alarm, and whether an operator has acknowledged it. A searchable list of historical alarms helps both operators and analysts to track alarms over long periods of time to detect important patterns. These lists can be filtered and sorted.

Sometimes, alarms need to be suppressed. Operators can suppress alarms for a short period, for example, when a sensor is temporarily malfunctioning. Alarms can be configured to be suppressed for long periods of time, for example, when a point is still being commissioned. Dynamic logic can also suppress alarms, for example, suppressing a low-pressure alarm for a pipe when the corresponding valve is closed.

Long-term operational use reveals badly configured alarms. There is an arsenal of techniques to correct these configuration issues, based on analysis of recurring trends. Analog alarms which constantly chatter between low and high values can apply deadbands to mute the noise. Digital alarms that quickly switch states multiple times can apply on-delays and off-delays to stabilize the state transitions. Incidental alarms for a device power outage can be presented as a single group of alarms. Analytical tools can hone in the most frequent offenders, which when dealt with can reduce unnecessary alarms by large percentages. As established earlier, fewer alarms make alarms more manageable for operators in real-time environments.

7.11 Incident Review and Replay

In any SCADA system, there will be situations that arise that the management will want to have reviewed to find out what exactly happened and whether the operator had sufficient information available to properly handle the situation. A SCADA system should provide tools to make it possible to review these situations. Some SCADA systems include audio recorders on all phone lines and radio channels for this kind of review. It is also possible to record the operator screens to verify whether the operator went to the correct screens to diagnose a problem. The disk storage requirements for this are quite high, so the number of hours of storage will have to be limited.

There are also potential personnel issues with this level of monitoring, which should be carefully reviewed.

A SCADA system should also provide tools to analyze the precise order that things occurred in, preferably to the millisecond. The activities that need to be monitored are as follows: when field devices such as valves or circuit breakers changed status, when operator commands were sent out, and when operators acknowledged alarms. Additional information such as updates for analog values from the field can also be very useful in analyzing an incident to check if an analog changed before a command or in response to a command. A simple tool might look something like a text log of each change, but that is difficult and time-consuming to review, but does contain very precise information. A better system will replay the incident using the same screens that are available to the operator showing the current state of the system. The best system will include both the text and GUI interface and allow for slow replay and pauses. In summary, it is important that an incident that occurred be able to be recorded and made available for review in an offline system.

7.12 Data Quality

One of the many aspects critical to the proper use of a SCADA system is the integrity and quality of the data displayed to the human operator in the control room. There are several conditions that may adversely affect the data being displayed, and it is important that the operator be aware of what these conditions might be and when they are occurring. Because SCADA systems are computerized and are thus aware of the context in which the data were gathered, they can also infer the quality of the data and advise the operator if the data are questionable. For example, if the communication link between the SCADA server computers and an RTU is broken for whatever reason, most SCADA systems can inform the human operator that the data being displayed are stale. It is important for the operator to know that the data currently displayed for RTU in question have lost their “real-time” nature.

While the list of possible data quality conditions is quite long, Table 7.1 shows some typical data quality conditions:

7.13 Operator Logbook and Shift Handover

The 49 CFR Parts 192 and 195 regarding control room management (CRM) provides a clear definition on the needs for Shift Handover. “Pipeline Operators must also establish a means for recording shift changes and other situations in which responsibility for pipeline operations is handed over from one controller to another. The procedures must include the content of information to be exchanged during the turnover.” The intent is to capture important information that has been provided or has occurred during the shift—and which the next or future shifts should be aware of in order to responsibly operate the pipeline.

Operators have long kept physical handwritten logbooks; however, electronic logbooks and shift handover software tools are now the norm. These electronic tools can range from being an integrated part of the SCADA system to separate stand-alone software. There are advantages to both approaches. With the advance of these software tools, control room operators now have much better access to fuller (and now searchable) information of what has happened in previous shifts. Information access can also be role-based at the operator, shift supervisor, manager, and other levels. Systems which allow operators to select entries based on drop-down selections (thus require less typing) tend to obtain fuller information; also, the information is more standardized and sortable.

Key information captured in operator logbook and shift handover tools can include the following:

• Operations/maintenance orders/schedules for the day provided by management/supervisors
  
  
  
  • With operator checklist ability that the orders have been read, are underway, completed and/or if delayed understanding on why.
  
  
• Ability to search for past “similar experiences” to aid in trouble-shooting unusual situations.
  
• Lessons learned
  
• Personnel planning: Easy-access regarding past/future personnel on shift for planning purposes
  
  
  
  • With now a more trackable understanding of their abilities.
  
  
• Multi-faceted information capture: More sophisticated integrated systems allow for the “drag and drop” capture of rich information regarding process graphics and trends—that allow a full “snapshot” of operations for full information transfer.
  
• Integrated reporting
  
• Integrated procedure management
  
• And more

With this information now more easily available, currently, operators are better equipped to avoid information transfer loss during shift handover, which has in the past been a significant contributor to pipeline incidents and/or operation inefficiencies.

7.14 Training

There are many aspects to consider when it comes to SCADA systems and how they relate to pipeline integrity. One often forgotten aspect is the human element and the need for training. All too often when a SCADA system is commissioned, the pipeline operating staff receive a set of training courses on the use of the SCADA system, but what about eventual staff turnover? When new SCADA staff are hired, who will teach them the system and with what credentials? Once a new SCADA system has been delivered, it rarely happens that the pipeline owner hires the SCADA vendor to return to the facility to teach new staff members.

Indeed, training via experienced workers offers several benefits but can sometimes also have some disadvantages as experienced workers are not necessarily skilled teachers. A full- featured SCADA system can compensate, in part, by providing training tools.

The ultimate in training aids is a full hydraulic model built onto a SCADA simulation workstation that is identical to a real SCADA workstation. Such a facility would not only look but also feel like the actual SCADA system, with accurate hydraulic calculated results for the SCADA operator’s actions. For many companies, however, such a hydraulic model is prohibitively expensive, as these packages often cost more than the entire SCADA system itself.

A reasonable compromise is a training tool that simulates the look of the SCADA system but is not connected to a hydraulic model (i.e., a tool that looks like but does not feel like the real system). Lacking the hydraulic model means the trainee cannot take actions and observe the results of their decisions, but such a training tool can provide a different training benefit: There is at least one SCADA system available that has a SCADA training simulator that functions by replaying previously recorded time periods of SCADA activity. It allows a trainer to insert pauses and questions for the trainee to respond to but is limited in that whatever decision a human trainee makes, when he continues the replay, there is only one decision tree that can be followed. Regardless of this, such a tool would give the trainee hands-on time at the controls of an identical SCADA system and could be given prerecorded scenarios to follow. The scenarios could be both best practices in terms of how to do regular duties as well as the possibility to replay accidents or incidents.

With training tools, new employees can be trained more quickly and more effectively than without and also affords the opportunity to have each human SCADA operator certified for a variety of procedures and emergency response. All these ideas will improve the daily operation of the pipeline, avoid costly accidents, and thus contribute toward greater pipeline integrity.

7.15 SCADA Security

Since SCADA is fundamental to pipeline operations, it follows that SCADA security is fundamental to pipeline security and integrity. SCADA, as a mission-critical element to pipeline operations, is vulnerable to a variety of threats and, thus, needs protection.

The first type of SCADA protection to discuss is physical security. The SCADA infrastructure (servers, workstations, communication equipment, and RTUs) needs to be physically protected by access control systems. It should not be possible for the general public to gain access to these assets. Access control for an RTU is often achieved by putting the RTU in a weather-protected enclosure and then locking the enclosure. Sometimes, the enclosure also has a perimeter fence around it to add an additional barrier. This can be augmented with a prosecution quality CCTV system.

As for the SCADA servers and workstations, this equipment is usually located in an office building, and thus it is quite easy to have this equipment behind locked doors. To increase access control to the SCADA control room, it is also possible to add further access controls to the individual equipment room(s). Such facilities usually have a separate environmentally controlled server room to host the SCADA and other computer servers.

Beyond physical access control, the SCADA equipment needs to be protected from the environment to continue to operate properly: SCADA servers should be temperature-controlled; RTUs should be protected from the ambient environment (dust, moisture, hazardous gases, etc.), and the entire control room should be located out of harm’s way and away from natural disaster zones.

In addition to physical security in the form of access control and environmental protection, because a SCADA system relies on computers and networks to communicate between different elements that constitute a SCADA system, it also needs to be hardened against cyberthreats. This means that the SCADA servers and workstations should prevent unauthorized programmatic access by locking down all I/O ports (USB ports, CD drives, Ethernet ports, serial ports, etc.). Connections between SCADA computers should also be made via secure channels such as SSL.

7.16 Cybersecurity

New cybersecurity regulations have been promulgated and continue to evolve in response to the growing threat arising as a direct result of the increased connectivity between business and operation systems. Consequently, cybersecurity is a mandatory requirement for any network-connected device, which, with the predominant use of microprocessor-based controllers and sensors means for all intents and purposes every device connected to the SCADA environment.

Traditional SCADA systems were largely based on proprietary protocols and private networks with limited connectivity to any external systems. However, starting in the 1990s, commercial off-the-shelf (COTS) technology such as Windows™-based interfaces, servers, and other business system hardware has made its way into the OT/SCADA space. The adoption of common infrastructure also made it easier to connect to the IT/business world, which when combined with the benefits of machine-to-machine data transfer has resulted in increasing interconnectedness of all systems. This commonality and connectedness result in similar vulnerabilities but with different outcomes. Figure 7.1 shows representative elements and cybersecurity priorities of the office environment on the left and the SCADA environment on the right.

The most significant difference between the OT and IT environment is that in the OT environment, unlike the business realm where an individual computer can be isolated from the network, it is not possible to shut down or isolate a compromised OT controller because doing so will in most cases lead to a production outage and in others an unsafe failure condition, and hence is to be avoided if possible.

In addition to using different hardware, which is typically ruggedized for the environment in which it will be used, the roles of the elements in the IT and OT space are also different. The Purdue Enterprise Reference Architecture (PERA) or Purdue model was developed at Purdue University in the 1990s as a functional reference model to describe what each layer between the process and all other systems through to the enterprise. (external supply chains were not an issue then.)

7.16.3 Demilitarized Zone

Because the data contained in a SCADA system are useful to other departments of a pipeline company, it is very common for there to be a connection between the SCADA system and other business systems. Direct connections between the office and control environments should be avoided. The use of a demilitarized zone (DMZ) as a buffer between the SCADA and business networks will mitigate the possibility of a virus or other cyberthreats from reaching the mission-critical SCADA network.

The DMZ, also known as the process information network, is the “buffer” between the information technology (IT) business systems and the operations technology (OT) automation and control (SCADA) systems.

The purpose of a DMZ is to ensure no direct connections from the IT and other external networks to the OT systems. The DMZ connections are configured so that approved devices on the IT and OT networks can write to and request information from the DMZ, but the two networks cannot transfer data between each other directly.

DMZs also provide controlled access to services used by external personnel to access the control system network and equipment.

7.17 SCADA Standards

There is a wide range of standards for SCADA available as of this writing. Most standards focus on a specific area of SCADA such as alarm management, security, or graphic display. Some standards apply to process industries in general, while others are for individual industries such as oil and gas, pipeline, electrical, and transportation. Some are created by formal regulatory bodies which require organizations to adhere strictly to requirements, while others are from established consortiums that recommend guidelines that may form the basis of future regulatory requirements.

Standards often borrow from each other, building upon legacy documents to add variations or new requirements. Core themes from various standards include the following:

• Ensuring only authorized users have access to sensitive information and actions.
  
• Providing greater awareness for operators using SCADA displays.
  
• Reducing overall stress levels for operators to improve responsiveness.
  
• Providing alternate views of data in various contexts for various purposes,
  
• Maintaining data integrity for audits and analysis.
  
• Using simple symbols to convey common objects.
  
• Scoping data at various levels, allowing users to drill down from overviews.
  
• Interactivity between different modules for seamless workflows.

Essential standards for the pipeline industry include the following:

• Safety: PHMSA 49 CFR 192/195.
  
• Alarms: ISA 18.2 (IEC 62682), API 1167, EEMUA 191 ISA-101/IEC 63303 (HMI).
  
• Control rooms: API 1168, PHMSA CRM.
  
• SCADA: API 1165, ISA 5.5, ISA-112 (in development).
  
• Security: API 1164, IEC 62443/ISA 99, ISO27001.

While some standards or requirements are very specific and detailed, others tend to leave room for interpretation. Thus, different SCADA providers may provide different solutions to meet selected standards. In general, standard compliance by organizations is achieved by best practices, which a SCADA system can help achieve. Understanding of human factors and industry workflows is essential to interpreting and implanting standards.

7.18 Pipeline Industry Applications

While at its most basic definition, a SCADA system simply presents operational data to humans in a control room for them to take action, the reality is that after years of R&D and continued refinement, SCADA systems now offer much more than this basic functionality. One way that SCADA systems offer more is by adding optional software application modules. While there may be many such applications to choose from, three important ones for pipeline integrity are as follows: leak detection, batch tracking, and dynamic line coloring.

7.19 Machine Learning and Artificial Intelligence

Artificial intelligence (AI) and machine learning (ML) have successfully saved costs, increased revenue, and achieved other performance metrics for well-known pipeline companies in Canada, the United States, and around the world. This methodology has proved effective because pipeline systems are often too complex for their behavior to be accurately predicted with first-principle calculation or simulation software. The AI ML approach uses historical data from the SCADA system to create a predictive model that can quickly and accurately estimate system flow rates. An AI ML solution can be implemented to provide control room operators recommendations in real time so that pipelines can be confidently operated in an optimized manner.

This overview is intended to give you an idea of the types of optimization benefits that can be achieved with this technology. It will not address the areas of predictive failure or predictive maintenance, nor is it intended to guide you in completing your own project. Benefits can be realized for oil or gas pipelines.

7.20 Communication Media

Like any computer-based structure, SCADA requires connections between the different elements or nodes (controller, workstation, server, gateway, etc.) of the system.

While the RTUs gather data from a variety of instrumentation, these data must be communicated up to the SCADA server computers, and a variety of communication media can be employed to effect this communication. The selection of communication media is influenced by factors such as purchase and install price, operating price, reliability, availability, bandwidth, and of course geographical considerations. Another aspect is suitability for data transmission via serial or Ethernet methods. Because of the widely distributed nature of SCADA systems, as described below, they use a broad range of media to distribute messages between nodes.

7.21 Communication Infrastructure

Depending on the communications media employed for any given SCADA system, a collection of appropriate infrastructure equipment is required.

For those SCADA systems using Ethernet-based media between the SCADA servers and RTUs, Ethernet switches are needed with at least one port for each RTU, which could increase to hundreds for large systems. Some users design for two (or more) communication paths to each RTU, meaning even more Ethernet ports.

The communications infrastructure needed for serial-based communications can be somewhat more involved. For example, dial up lines will need one serial port for each RTU (or additional ports for each RTU if redundant communication paths are desired). But computer servers do not have so many physical serial ports—usually just one or two, and therefore serial port expanders can be used. Such devices usually present a single Ethernet connection to the server on one side and offer several serial ports on the other side (from 1, to 8, 16, 32, or more).

Once the necessary number of serial ports have been added to a serial communications design, the next consideration is a changeover switch, which at its most basic conceptual idea is a three-ended device with two serial port inputs and one serial port output. The idea is that the changeover switch will connect either the A input port or the B input port to the output serial port. The purpose for this switch is to route the serial data line from an RTU to either the primary SCADA server (A) or backup SCADA server (B). This idea is then repeated for each serial communication line such that all RTU serial lines are connected through the A or B ports, ultimately reaching either the primary or backup SCADA server. In this way, if one SCADA server should fail, the RTU communication lines can be swung over to the other SCADA server to continue the essential service of retrieving RTU data. Due to the potentially large number of serial ports, a changeover switch should ideally be rack-mounted with the ability to add “slide in” modules, allowing the changeover switch to be grown to the appropriate size with the ability to increase in size to account for future expansion.

Beyond the changeover switch are the modems. Each serial communication line will require a modem at the RTU end and at the SCADA control room end. While it is quite common for these modems to be individual units, some companies provide modem solutions that are able to reduce the overall modem infrastructure. For example a “6 pack modem” uses just one serial port from the SCADA servers to give access to six separate serial modem lines. While this type of solution offers great savings in terms of communications hardware and provides simplicity, it does imply a custom implementation where the modem vendor needs to make application-specific versions of the communications protocol software to drive the six-pack modem.

While the above paragraphs describe some common infrastructure for a dial up serial implementation, similar hardware elements would be needed for a leased line implementation, while a fiber optic or satellite implementation would deviate further.

Some communications hardware may be optional and not necessarily required for communications. For example, hardware encryptors can be added, which can provide a layer of cybersecurity to the communication path. Or some radio communication networks can benefit from data repeaters to amplify the wireless data signal.

In contrast to the media-dependent infrastructure, all SCADA implementations will have an Ethernet LAN for the SCADA servers, SCADA workstations, printers, etc. In fact, the majority of SCADA control rooms use dual LANs for network redundancy. Single or dual, an Ethernet switch is the focal point of each LAN. In addition to these switches, most SCADA systems need to pass data up to business systems, and to isolate the SCADA control room network from these business systems, a firewall can be used. But use caution by putting too much trust in a firewall: indeed, they add a measure of security to the mission-critical SCADA LAN, but additional measures should also be employed.

Quite often, elements of the communications infrastructure hardware maintain statistics that can provide an insight into the degree of success or indications of problems in transferring data from the RTU up into the SCADA servers. Since RTU communications are vital to a SCADA system’s operation, and since SCADA plays a role with pipeline integrity, there should be someone assigned to periodically review these communication statistics.

7.22 Communications Integrity

One aspect of overall pipeline integrity is communications integrity, meaning that the operational data contained in the RTU/PLC database be accurately transmitted to the SCADA servers and vice versa. The inability to do this will surely compromise pipeline operations. To protect against this, several strategies are simultaneously employed.

One of the ideas used to improve communications integrity is that of CRCs or checksums on data packets. These are mathematically computed codes added by the sender of each message these codes depend on the message contents. When each message is received, its code is re-computed and compared to the transmitted code. If they are identical, the message has been received intact; otherwise, it is known to be corrupted. The ability to use these codes depends very much on the computer protocol used between the sender and receiver. CRCs and checksums are mostly used to protect against noise on a communication channel.

A layer of communications integrity that can be used in addition to CRCs or checksums is encryption. This is a method whereby the transmitting computer uses a non-trivial number sequence (a “key”) to obfuscate the entire data message before it is sent. The receiving computer must have the same encryption key to re-compose the message after it is received. Encryption enhances pipeline integrity by hiding details of the SCADA messages being reverse-engineered when the communication protocol is known, something that is quite easy to do especially when using wireless data communications. Encryption must be supported by the computer protocol used between the SCADA servers and RTUs/PLCs.

Authentication is one more method to protect pipeline integrity by using certificates between the two ends of any communication channel. These certificates ensure that messages are being exchanged between authorized devices. For example, in a non-authenticated scenario, it could be that an intruder is injecting protocol-compliant messages into the SCADA hosts, or PLCs/RTUs and in doing so take control of the infrastructure. While this threat is diminished by adding encryption, a capable hacker can also add matching encryption to his malicious data packets. But adding authentication will invalidate the data packets injected by a hacker. However, much like the strategies mentioned above, authentication depends very much on the computer protocol being used. Authentication is not compatible with many popular protocols (such as Modbus).

In summary, it is understood that SCADA plays a vital role in pipeline integrity and SCADA is, at its root, all about sending data over communication lines. It follows, therefore, that pipeline integrity depends to some degree upon SCADA communications integrity.

7.23 RTUs and PLCs

RTUs and PLCs are basically functionally equivalent. Both RTUs and PLCs connect to a collection of sensors and actuators, collect the raw signals, and convert those signals into engineering values. These engineering values are stored in a database and when interrogated, these database values are transmitted to the SCADA host. Most SCADA systems utilize anywhere from one to several hundred RTUs or PLCs.

7.24 Database

RTUs and PLCs maintain an internal database which represents the current value of all the process variables connected to them. These data are ultimately communicated up to the SCADA hosts and as it represents vital pipeline operational data, its integrity must be maintained by the RTU or PLC, and there are several methods to achieve this.

First, the CPU card of an RTU should have some method of keeping the RAM database alive temporarily if the power to the RTU is lost for any reason. Older RTUs and PLCs achieve this via a backup battery, but a better approach is a super capacitor, the reason being that battery performance decays as the battery ages. A supercapacitor should be able to keep the RTUs RAM data alive for several days, ample time to repair or swap out a dead power supply, or otherwise fix the power problem.

In addition to the live data maintained in RAM, the database configuration should be maintained in nonvolatile memory such as a flash ROM on the CPU card. Proper RTU maintenance practices would dictate that copies of the configuration database also be held in an offline repository, such as on a laptop and removable media.

The better RTUs will also maintain a historical data buffer. This is used to store RTU data values during periods of SCADA communication outages. In such an event, the RTU will buffer new data values from the live field process variables, and once communications to the SCADA hosts are repaired, it will relay the buffered data up to the SCADA hosts. While this feature does not solve the problem of failed communications, it does allow the SCADA host to insert old data values into its permanent historical database. While this important feature is available in better RTUs, the best ones will relay this old buffered data up to the SCADA servers as a lower-priority task once communications are restored. By doing so, the RTU will first relay the critical live data values and will report the older values as bandwidth allows at a lower priority.

However, keeping copies of the live runtime data and configuration data does not go far enough to ensure database integrity. The databases themselves should have a checksum or other validation code to ensure they are not corrupted.

7.25 User-Defined Programs

Modern RTUs have the capability to add user-defined programs. This is a feature that allows the pipeline owner/operator to build arbitrary functions into the RTU based on any input trigger condition or schedule. While proprietary methods do exist for some RTU vendors, there is an internationally recognized standard for doing this, which is IEC-61131. These user-defined programs can be anything from a simple sum of multiple flows to very complex behavior that can optimize operations in real-time or increase the safety of pipeline operations, including pipeline integrity.

Some RTUs come preloaded from the factory with some user-defined programs to put the RTU into a “safe mode” if it should lose communications to the SCADA servers. The specific definition of what a “safe mode” is depends on different pipeline operators, but generally, it means adjusting setpoints and other parameters away from maximum operational limits and toward moderate values without shutting down the pipeline. By moving the setpoints away from maximum operational limits during communication outages, it means that for periods of time that the human pipeline operators are unable to observe or affect the pipeline operations, the pipeline will automatically revert to a more conservative operating capacity, the specifics of which should be specified by each different pipeline owner/operator, and possibly customized further for each separate RTU. By doing so, pipeline integrity is automatically preserved even while live operational data are not available.

7.26 RTU/PLC Integrity

Reliable data are vital to pipeline integrity, and as such, the equipment that generates and transmits operational data has a dramatic effect on pipeline integrity. RTUs and PLCs are the front-line equipment that provides these operational data, and as such, pipeline integrity is linked to the integrity of these devices.

RTUs and PLCs should be robust and capable of performing properly even in the event of physical upsets such as noncritical component failure. In other words, RTUs and PLCs should be “high-availability” devices. This is best achieved by making the critical components redundant. Some vendors offer redundant power supplies for their RTUs, or dual CPU cards, but the ultimate in high availability is entirely redundant RTUs, meaning that for each RTU needed, two are actually delivered. Doing so provides dual CPUs, dual power supplies, and dual I/O cards. While very rare, there are vendors who can offer such RTUs and in doing so assist pipeline owners/operators achieve greater pipeline operational integrity.

Another feature of RTUs and PLCs that can contribute toward greater integrity is the ability to “hot swap” its components. This means, for example, that a PLC I/O card can be removed and replaced with another without need to power down the entire PLC. Similar for RTUs or PLCs that have dual CPU cards or dual power supplies, a failed component can be removed without shutting down the device while a replacement component is added.

7.27 Safety Systems

Consistent with the increased awareness of safety by the industry as a whole, safety instrumented functions as implemented in Safety Instrumented Systems (SIS) and capabilities are becoming more common in project specifications and regulations. SIS have very rigorous requirements specified in standards based on IEC-61508 covering their full life cycle including specialized Safety Integrity Level (SIL) controllers. Integration of these specialized systems into the overall SCADA environment must also meet specific requirements as defined in IEC-61511 (ISA-84) and related standards.

Because of the way in which SCADA systems are built and developed, it is not practical to certify the full SCADA system; however it is possible to integrate the individual safety nodes into SCADA.

7.28 IOT/IIOT

IoT (Internet of Things) includes all the “connected devices” around us from smart thermostats, security cameras, intelligent doorbells, appliances, etc., that use Ethernet communications to connect to each other, along with the associated databases and user interfaces. IIoT is the industrial application of IoT; hence, the additional “I.” IIoT devices typically have additional requirements as well such as suitability for the ambient environment including enclosures, security, maintainability, and electrical area classifications.

IoT and IioT can be placed pretty much anywhere, and consequently, they tend to be widely distributed, relatively independent, communicate using a variety of protocols, and especially in the industrial setting are expected to be installed and then function without additional action for 10+ years. This scenario is similar to the typical SCADA environment which gathers data from a wide range of geographically diverse inputs, stores the information, then when necessary sends a response signal to an actuating device, and notifies the operator of changes in state.

7.29 Electrical Classification Compliance

Electrical area classifications are based on the electrical codes for the country of interest, which are largely consistent with IEC 79.

Hazardous (classified) areas as those where fire or explosion hazards may exist due to the presence of flammable gases, vapors, liquids, combustible dust, or ignitable fibers. Electrical area classification is the process of determining the existence and extent of hazardous locations in a facility containing any of those substances. In the context of electrical equipment, the following terms—area classification, hazardous locations, hazardous (classified) locations, and classified areas—are all synonymous with electrical area classification.

The basis of the classification is to prevent a fire or explosion, and as a result, the classification and controls are based on the “fire triangle” shown in Figure 7.3.

7.29.1 Area Classifications

In North America (United States and Canada), area classifications were historically based on the class/division system, while the remaining world uses the zone system. The zone system is becoming increasingly common in North America now as well.

The hazardous area classification system determines the required protection techniques and methods for electrical installations in the location.

The class/division/group system is as follows:

• Classes: defines the general nature of the hazardous material in the surrounding atmosphere.
  
• Divisions: defines the probability of the hazardous material being present in the surrounding atmosphere.
  
• Groups: defines the type of the hazardous material in the surrounding atmosphere

The international zone-based system uses zones and groups:

• Zones: defines the general nature (or properties) of the hazardous material—if its gas or dust—and the probability of the hazardous material in the surrounding atmosphere
  
• Groups: defines the type of the hazardous material and (partly) the location of the surrounding atmosphere

7.29.1.1 Class Division versus Zones

Table 7.3 shows how the class/division compares against the zones for different types of hydrocarbons.

In the case of hydrocarbon liquids, propane is normally the lightest hydrocarbon and therefore first to vaporize so that at least in liquid systems, Class D is the most common.

Facilities are designed to minimize the likelihood of leakage; one consequence of this is that 95% of classified areas in North America are Division 2, which means the substance referred to by the class has a low probability of producing an explosive or ignitable mixture and is present only during abnormal conditions for a short period of time—such as a container failure or system breakdown.

Awareness of the area classification is normally documented in an area classification drawing, which normally includes the necessary transition area from potential sources of ignition.

Typical gas	Class/division	Zone
Acetylene	A	IIC
Hydrogen	B
Ethylene	C	IIB
Propane	D	IIA

The electrical codes also describe different ways to design for and perform work within a classified area. The three ways to design for electrical protection are as follows:

1. Explosion proof: design an enclosure to contain an explosion.
   
2. Intrinsic safety: manage the amount of energy entering the area.
   
3. Purging: dilute or eliminate the hazardous gas from reaching an explosive concentration.

7.29.1.2 Explosion-proof

This is the most commonly used technique in North America and works on the basis that if there is an explosion, it is contained within the enclosure with sufficient surface area to cool the resulting gases below the temperature to cause ignition in the surrounding environment. This requirement for a tight seal is why explosion-proof enclosures must always be properly secured and tightened using all the bolts, while also keeping the flange faces clean and scratch-free to prevent possible bypassing of gases because the required tight tolerances are not maintained.

Because the circuits inside an explosion-proof enclosure could cause an explosion when exposed, should a hazardous gas be present, working on equipment using this protective measure always requires a hot work permit.

7.29.1.3 Purging

As indicated above and the name implies, purge protection first sweeps any potentially hazardous gases from the enclosure before energy is applied and then maintains a slight positive pressure against atmosphere (i.e., the pressure outside the enclosure) to keep hazardous gases from entering the cabinet. Purging is often used as an alternate to explosion-proof for large enclosures/cabinets such as small analyzer systems.

For class/division applications, the levels of pressurization covered by NFPA 496 are defined as follows:

• Type X: Enables use of equipment suitable for unclassified locations within the protected enclosure where the equipment would otherwise be required to be suitable for Division 1 locations.
  
• Type Y: Enables use of equipment suitable for Division 2 locations within the protected enclosure where the equipment would otherwise be required to be suitable for Division 1 locations.
  
• Type Z: Enables use of equipment suitable for unclassified locations within the protected enclosure where the equipment would otherwise be required to be suitable for Division 2 locations.

Again like for explosion-proof, because when the enclosure/cabinet is open hazardous gases could potentially contact an ignition source, working on equipment using this protective measure always requires a hot work permit.

7.29.1.4 Intrinsic Safety

Intrinsic safety (IS) differs from explosion-proof, in that the associated electronics are designed to keep the available energy low enough that ignition for the rated class is not possible.

Because not all equipment can be designed to be intrinsically safe (for example, the I/O card or controller in a control room, which is an unclassified area) could introduce energy to the field end of the cable, manufacturers have designed (passive) isolators and (active) barriers to separate the IS and non-IS circuits. Isolators use diodes and resistors to manage the energy going to the classified area and normally have low voltage (i.e., 24 V on both sides), while barriers are powered and often have high voltage (AC) on one side and then passive 24 VDC signals on the classified side of the barrier.

Intrinsic safety is defined by a number of IEC 60079 standards that need to be followed by designers of this type of equipment.

Because intrinsically safe systems are not able to store sufficient energy to ignite a hazardous gas mixture, live work is possible on the IS side of the circuit. When working in a field cabinet using barriers, hot work permits will still be necessary.

7.30 Acronyms, Abbreviations, and Terms

Common terms

Bibliography

1. Abnormal Situation Management® (ASM) (2000) Consortium Guidelines—Effective Operator Display Design. Version 2.01 (July 28).
   
2. American National Standards Institute/International Society of Automation (2009) Management of Alarm Systems for the Process Industries. ANSI/ISA-18.2-2009. Research Triangle Park, NC, USA: ISA. ISBN 978-1-9360007-19-6.
   
3. American Petroleum Institute (2021) Pipeline Control Systems Cybersecurity, 3rd ed., Standard 1164, Product Number D11043, Washington, DC.
   
4. American Petroleum Institute (2022) Pipeline SCADA Displays, 2nd ed., Recommended Practice 1165, Product Number D116502, Washington, DC.
   
5. American Petroleum Institute (2016) Pipeline SCADA Alarm Management, 2nd ed., Recommended Practice 1167, Product Number D116702, Washington, DC.
   
6. American Petroleum Institute (2015) Pipeline Control Room Management, 2nd ed., Recommended Practice 1168, Product Number D11682, Washington, DC.
   
7. Boyer, S.A. (2010) SCADA: Supervisory Control and Data Acquisition, 4th ed., ISA-International Society of Automation, Research Triangle Park, NC, USA. ISBN 978-1-93600-709-7.
   
8. Boyes, W. (editor) (2010) Instrumentation Reference Book, 4th ed., Butterworth-Heinemann, Burlington, MA, USA. ISBN 978-0-7506-8308-1.
   
9. Bullemer, P.T., Reising, D.V., Errington, J., and Hadjukiewicz, J. (2004) Interaction Requirements Methods for Effective Operator Interfaces. ASM® Consortium Technical Book, Version 1.0.
   
10. Endsley, M.R. (1988) Situation awareness global assessment technique (SAGAT). Proceedings, National Aerospace and Electronics Conference (NAECON), pp. 789–795. IEEE, New York.
    
11. Endsley, M.R. (2012) Building situation awareness in oil & gas operations, SA Technologies, Inc. Presentation. Pipeline Conference and Cybernetics Symposium.
    
12. Endsley, M.R. and Jones, D.G. (2004). Designing for Situational Awareness: An Approach to User-Centered Design, 2nd ed., Taylor & Francis, Boca Raton, FL, USA.
    
13. Engineering Equipment Materials Users’ Association (2019) Control Rooms: A Guide to Their Specification, Design, Commissioning and Operation, 3rd ed., EEMUA Publication No. 201, London: EEMUA. ISBN: 978 0 85931 224 0.
    
14. Engineering Equipment Materials Users’ Association (2013) Alarm Systems—A Guide to Design, Management and Procurement, 3rd ed., EEMUA Publication No. 191, London: EEMUA. ISBN 978 0 85931 192 2.
    
15. Errington, J. (2013) Human Factors Planning for Control Room Management, Banff Pipeline Workshop, Banff, Alberta, Canada.
    
16. Few, S. (2006) Information Dashboard Design: The Effective Visual Communication of Data, O’Reilly Media, Inc., Sebastopol, CA, USA.
    
17. Mohammad, R. (2013) Control Centre Human Factors Graphics and Interface Design, Banff 2013 Pipeline Workshop, Banff, Alberta, Canada.
    
18. Pipeline and Hazardous Materials Safety Administration (2009) Pipeline Safety: Control Room Management/Human Factors, Amended Regulations 49 CFR Parts 192 and 195 (December 3), PHMSA, Washington, DC.
    
19. Rothenberg, D.H. (2019) Situation Management for Process Control, ISA-International Society of Automation, Research Triangle Park, NC, USA. ISBN: 978-1-945541-65-0.
    
20. Willowglen Systems (1990–2013) SCADACOM Reference Manuals, Willowglen Systems, Edmonton, Canada.