SCADA goes long

  

SCADA uses long distance communication tools to allow an operator to monitor and control multiple processes spread across miles, but be careful of the functions you put on the communications link

FAST FORWARD SCADA applies to very large processes. One operator with complex communication equipment can handle it. Time critical functions should be under local automatic control.

By Stuart Boyer

Supervisory control and data acquisition (SCADA) is the technology we use to control processes that extend over long distances.  Occasionally, in a plant, there are parts of the process that are so far away from the control room that a SCADA system can be included in the plant distributed control system (DCS) to reach them. Usually controlling these processes is simple, involving measuring flows or temperatures, monitoring alarms, opening or closing valves, turning motors on or off, opening or closing switches, and adjusting set points on controllers located near the process.  While this control is simple, it is usually very important.  Also, the speed with which we respond to information about these processes is not critical—the response time is not urgent.  If these statements are true, why has SCADA become such a popular technology?

Defining a process control system

A long time ago, all processes were controlled manually.  Most processes were "batch."  That is, the person that was in charge would mix the correct amount of each ingredient, would add heat to bring the mixture to a selected temperature, would stir for an experimentally determined time, and would cool the product.  Often, the method of telling if the amount of each ingredient was correct was a personal preference of the mixer, and the temperature was estimated by knowing how long the heat had been applied.  The speed of cooling was controlled by the ambient temperature.

Eventually, someone noticed the quality of the product depended on who was doing the mixing.  Shortly after this, experiments were conducted to determine what made one mixer's product better than that of another mixer.  Better measurements of the ingredients were tried.  Thermometers were used to control the temperature.  Mechanical stirring was applied to eliminate the human tendency to stir less rather than more.  Different rates of change of cooling were evaluated, and the best rates were selected.  In short, process instrumentation was introduced to improve the quality of the product.

At about this time, the person who controlled these factors was reading all of the instruments and manually adjusting fuel and stirring rates, adding ingredients at the right time, and removing the heat and providing cooling water of the right temperature and at the right rate.  That person was probably also cleaning the pots after every batch of product was made.

As process instrumentation improved, it became practical to convert some classes of process from "batch" to "continuous".  Process fluids could now be added to and removed from the process container without stopping the flow.  Generator voltages and currents could be controlled without turning off the generator to adjust settings of the machine.  Materials could be shaped to the proper dimension without stopping the shaping process to measure if they were now the correct size.  When done properly, this continuous processing resulted in massive increases in throughput.  But it also required more dedicated attention of the operator because failure to notice a change in process measurement would surely result in product that was out of specification.

The next developments integrated the measuring and control functions. A controller that pinched down on the fuel when the mixture got too hot was easy to build and could be relied upon to do a better job than an operator whose attention may wander.  It was not much of a stretch to develop devices that could control the rate of change of temperature, other devices that could change from adding heat to removing heat after a preselected time, and even more devices that could add and stir the proper amounts of ingredients.  The operator's function became one of monitoring all of these devices to ensure they did the right things.  When the operator was no longer continuously occupied running one process, management decided to assign two or three processes to each operator.  Control shifted from one corner of the process to a room dedicated to control.  The increased distance from the process to the control room meant pneumatic and hydraulic lines became prohibitively expensive and pairs of copper electric lines, each pair dedicated to one signal, replaced them.

Too far for comfort

There have always been some processes that require an operator to attend, but not very often.  Think of hydro-electric power stations or agricultural irrigation systems that can run for days with no operator intervention, but must have a valve opened or closed to start or stop the power generation or irrigation. Think of an oilfield, where the produced fluids must be diverted through a separation system to measure how much of it is oil, water, and/or gas.  In these cases, the work that the operator must perform can be done in a few minutes, but travelling to and from the site may take hours.

Until about 50 years ago, technology was not available to provide remote monitoring and control.  People had to be based at each site where a process was working, or they had to drive from one location to another so they could sample the conditions often enough to be effective.  Then, dedicated wire pairs, often leased from telephone companies, started to be used to move simple switch status from remote areas to central locations where people could monitor what was happening. At first, data flowed only in one direction, usually from the process to the central operator. Being one way, this was not SCADA.  It was simple telemetry.

It was not long before radio signals were used to move this telemetry data from very remote locations to operations rooms. However, early systems were sometimes as slow as one bit every two or three minutes, and lacking communications security technology, the systems depended on receiving multiple instances of the signal and comparing them to ensure it was not just noise that was being received.  Success with systems like these prompted research to address the problems that were known about.  Signal distortion caused by different reactions to inductive and capacitive reactances of the communications media limited the distances that signals could be transmitted and still be understood.  Military and space programs were pioneers in telemetry, and they determined digital signals could be successfully moved over greater distances.  In addition, digital signals could attach a small addition to the end of the message, which would indicate if a communication error had occurred during transmission.

Finally, it occurred to someone that if field data could be gathered, then instructions could be sent.  Putting together all of these things allowed rudimentary SCADA to be implemented.

Why not call it CADA?

Since our initial definition described SCADA as a tool to "… control processes that extend over …," it would seem reasonable to call it "control and data acquisition," or CADA.  The reason we do not do this is based on the acknowledged lack of reliability of communication for SCADA systems.  Geographically small processes like refineries, cement plants, and power plants can be built with dedicated wires from the central controller to each sensor and actuator.  The reliability of these communication paths is very high. For processes like these, we can risk having the actuator position be completely dependent on what the controller orders.  We can depend on a continuous control signal from the central controller to the actuator.

SCADA systems are not reliable enough for us to make this assumption because they depend on radio and/or leased utility lines.  Instead, we arrange to have a dedicated, but sometimes limited, controller located close to the process, and we use the SCADA system to make changes to set points of these controllers, as a supervisor would do if there were one on site.  If a change in set point does not successfully navigate the communication system, it is not a big deal.  Feedback about the success of the change will be provided to the master terminal unit (MTU) at the next status reporting time, and if the change did not happen, the instruction can be sent again.

Consider something as simple as opening a valve.  If there were a supervisor close to the valve, the supervisor would open a switch that would interrupt the power to a solenoid that supplies air to the valve.  A SCADA system operator would open a switch in a central controller.  That switch position would be included in the next instruction to a remote terminal unit (RTU), perhaps half an hour later.  The RTU would receive the instruction and store it in a memory location dedicated to the intended valve.  Almost immediately after, the valve solenoid power would be interrupted, and air to the solenoid would be removed.  The valve would close.  At the next routine scan, the RTU would send all valve status indications.  If the valve had moved properly, nothing more needs be done.  If the valve had failed to move, an alarm would be generated, alerting the operator to the failure, and the instruction could be resent.

Limited functionality

Functionality of SCADA is limited.  Take a look at what SCADA systems do:

SCADA systems gather status points: Status points are discrete, binary values.  A motor is either running, or it is not.  An on/off valve is either open, or it is closed; electrical power is either available, or it is not.  The central operator needs to know the status of many of these equipments to operate the process properly.  Equipment status switches at each facility can be wired to the nearest RTU.  The RTU stores each of them in binary digital form, as either a one or a zero, in a location dedicated to that equipment.  The status of each of these switches will be transmitted to the MTU when the MTU demands them.

SCADA systems gather analog values: Analog values are more complex than discrete values.  An analog value tells how open a valve is, tells how hot a furnace tube is, or tells how much current is flowing through an electrical conductor.  These are often gathered as pure analog values, converted to some intermediate analog value, such as milliamps of current, for collection at the RTU, turned into digital values of more than one bit, time stamped at each RTU, and transmitted to the MTU when the MTU demands them.

SCADA systems gather totalized data: At each of the widely distributed process locations, some very simple measurements can be used to indicate production.  Electrical generating stations measure power and integrate it over time into energy.  Irrigation metering stations measure flow rate and integrate it over time into flow.  Pipeline input stations measure product impurities and integrate it over time into average impurity levels.  These integrated values are sampled, turned into digital values of more than one bit, stored at each RTU, and transmitted to the MTU when the MTU demands them.

SCADA systems monitor alarms: Alarms are more complex than status points.  For some alarms, such as a fire or intrusion alarm, the field indication of the alarm may be exactly the same as a status point, and one state of the switch always implies an alarm condition. For many functions, it is not enough to know the status of a piece of equipment. Alarms for these functions are an indication that an equipment status is different from what the operator expected or ordered.  For these functions, the field indication may be the same as a status point, but logic, either at the remote site or at the master site, must interpret the switch position and compare it to what has been ordered to determine if an alarm exists or not.  For still other alarms, the field indication may be an analog measurement, and the alarm condition may be understood only when that measurement is compared to an expected value in the MTU.

SCADA systems allow supervisory control: SCADA systems allow an operator located at the central location and using human-machine interface (HMI) connected to the MTU to make changes in the set points of simple process controllers located in the remote locations.  These set points are addressed not only to the RTU but to the specific controller at that RTU.  The controller may be a separate piece of equipment located close to the RTU, or it may be a function within the RTU.

The controller is that part of the control system that will provide a continuous signal to the process actuator, based on the set point received from the MTU.  In addition, the controller or the actuator will report back through the RTU to the MTU to advise the operator how things are progressing.

HMI at the RTU

Some locations remote from the central control location are manned, and some are not. If the remote location is manned and is set up to be operated manually, the RTU will normally be provided with equipment to tell the operator at that location what is happening with the process and to allow the operator to make adjustments to the process.  This is the RTU HMI. 

The complexity of this HMI varies with the complexity of the process and with the likelihood that an operator will be using it.  For very simple processes with few inputs and outputs, the HMI may consist of some lights and/or physical meters to advise the operator and some switches and/or potentiometers to allow the operator to adjust the process equipment.  This type of HMI may or may not operate through the RTU. 

For more complex processes and for those that normally have an operator running the process, the HMI will probably be more complex and more expensive.  It will probably be a graphic presentation, indistinguishable from distributed control system graphical user interfaces, and complete with touch screens, process and trend graphics, alarm sounds and logs, and perhaps hardcopy printouts.

If the remote location is unmanned, the HMI may be similar to the simple HMI described above, or it may be non-existent.  If there is no HMI at the location, the RTU may be set up to accept a laptop computer that will act as the HMI when an operator must attend.

HMI at the MTU

For almost every SCADA system, there will be a computer based HMI at the MTU.  All MTUs are built on computers; and although early pipeline, electrical, and irrigation SCADA systems had entire walls of flashing lights on graphical HMIs, these are being replaced with computer screens that provide more information more effectively.  

Equipment layout sketches of each remote process section are projected onto the MTU HMI.  Each of these sketches can be called up by the operator, and the appropriate sketch can be programmed to automatically appear when a control function is being addressed by the operator.  Valves, motors, and other process elements under the control of the operator are color coded so a quick glance will suffice to update the operator about the process status.  Mouse controls or touchscreens will enable simple access so the operator may easily adjust process parameters.  Alarms will have different reactions depending on their criticality, extending to calling the operator's cell phone in some instances.

Process and personnel safety

Control of the processes is important, and certainly the types of processes that have been mentioned are potentially dangerous.  How can we get away with using a slow, unreliable communication system?

The first line of defense must not rely on the communication system.  Every dangerous process monitored and controlled by a SCADA system must have a safety system located at the site of the process.  It must be capable of taking the process to a safe state under all conceivable circumstances, including failure of power, failure of wires, and failure of sensors.  Enough information has been written about safety that it is not necessary to say more about it here.

Of course, when the safety system has acted to put the process into a safe condition, the SCADA system can report this back to the operator through the communication system.

Mature technology for many industries

In addition to the industries that did the early technology development work in the 1960s and 1970s—oil and gas, electrical transmission, railways, pipelines, and irrigation—SCADA is being applied to industries that have large, simple processes and can benefit from the combination of data gathering through telemetry and simple supervisory control.  For really long distance SCADA, it is hard to imagine outdoing the supervisory control of a Mars Rover, wandering around another planet, but taking instruction from an Earth-bound driver.

ABOUT THE AUTHOR

Stuart Boyer P.E. (ILIADENG@telus.net) is an electrical engineer and Life Member of ISA.  Most of his career has dealt with SCADA or other process control systems.  He has been active in ISA, serving as District Vice President and on several technical standards committees.  Boyer contributed to the Instrument Engineers' Handbook and is the author of SCADA, Supervisory Control and Data Acquisition, an ISA text now in its fourth edition.  He occasionally teaches courses in SCADA or Process Instrumentation.

How SCADA works Process control depends on moving data describing the process to the controller and moving control instructions from the controller to the process actuators.  When the distances from the process to the controller get too large, supervisory control and data acquisition (SCADA) systems interpose specialized communication equipment so monitoring and control can still work. One operator, sitting in front of a human-machine interface (HMI) is in charge.  The HMI connects to a master terminal unit (MTU) that sends and receives digitally coded information, sometimes over thousands of miles, to monitor and supervise the process.  Each concentration of process sensors or actuators is connected to a remote terminal unit (RTU).   The SCADA system is composed of one MTU and (usually) more than one RTU. SCADA systems do not have to talk fast.  Because they are providing a supervisory function, they just have to sketch out to the RTUs what direction to take.  They can do this by changing set points at the RTU location. RTUs send information back to the operator at the MTU.  Some of this information is for accounting, and some is for overall control. System design must consider the communication system is not very reliable, and significant periods of time may go by with no communication between MTU and RTUs. This may put additional strains on the process safety system. From the late 1960s, SCADA has been getting better, and it is now a mature technology for controlling geographically large processes.

 

RESOURCES SCADA: Supervisory Control and Data Acquisition, 4th Edition www.isa.org/link/SCADA4_bk Clearly Superior www.isa.org/intech/20090201 What Happens in Plant Stays in Plant www.isa.org/intech/20070301