SCADA : Gaining the recognition in process technology
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.
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?
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.
Operational 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.
SCADA v/s 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
SCADA Functionality
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.
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.
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.
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.
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.
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
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.
