Respect Murphy’s Law and don’t remote control all systems via SCADA

Remote control — What Not to SCADA

Every technology has applications for which it seems admirably suited, other applications for which it seems only marginally suited, and a group of applications for which it simply should not be used. When a technology is very young, it is often not clear which of those applications should be avoided.

As the technology matures, the hard school of experience clearly identifies some of them. In this technical article, we will discuss whether some types of control and data acquisition application should not depend on SCADA for their operation.

Murphy’s Law and Remote Control

Murphy lives! If you want to prove it, butter a slice of bread and drop it on the floor. If your intention is to prove that it will always fall butter-side-down, you will almost certainly note that this is so only about 50 percent of the time. On the other hand, if you drop it accidentally, it always falls butter-side down.

You can test the system. You can perform all manner of evaluations on each and every individual part of the system. You can run performance checks on the system as a whole. You can consult the experts. How many times has Stuart (author) been told by maintenance technical specialists, “That system must be absolutely reliable. It hasn’t failed since I’ve been here!”

Believe it: If you depend on a remote control or data acquisition system to handle some critical function, it will fail. The more critical the function, the faster and more catastrophically it will fail.

Over the years, signals that could potentially be placed on a SCADA system have been evaluated to determine which ones could cause a problem. The specific signals needed by individual industries will vary, but the general types of signals are fairly consistent.

Safety Instrumented Systems

All processes should be equipped with a safety instrumented system if through failure of some part they may cause injury to a member of the public or a worker, or may cause damage to the equipment or the environment. Safety instrumented systems should be designed to override the normal control systems.

The normal control system, of course, is designed to monitor the operation parameters of the process and to make adjustments as necessary to keep the process within limits. This will ensure that the product meets a predefined specification and that process and related equipment do not leak, burn, explode, or otherwise come into potentially harmful contact with people or the environment.

But the normal control system does not always work properly.

Sometimes this is a result of mechanical failure. Sometimes the feedstock didn’t meet specifications, or the energy source failed. Occasionally, the targets that the operator established for the normal controls to achieve were incorrect. Figure 1 lists the three characteristics around which safety instrumented systems are designed.

Figure 1 – Three main design characteristics of safety instrumented systems

1. Should be able to override normal control system.
2. Should not share components with normal controls.
3. Should be as simple as possible.

And, if the safety instrumented system follows the maxim of the US army, “KISS (Keep It Simple, Stupid!),” with a minimum number of parts, electrical contacts, and instructions, it will invariably work better.

The last two of these three conditions for safety instrumented systems argue against the inclusion of the SCADA system in the safety instrumented system.

With respect to the continued operation of the control system, it would be feasible to tie the sensors and actuators dedicated to the safety instrumented system into the SCADA. It would usually not be feasible to install a second RTU, communications system or MTU just for the safety instrumented system. Figure 2 shows how complex the situation could get for even a simple system.

“Keeping it simple” may be a relative concept, but few qualified designers would argue that SCADA is sufficiently simple to qualify as an appropriate element for a safety instrumented system. This is not to say that SCADA cannot be used to enhance the safety of geographically diverse systems.

Pipelines are often protected from leaks by measuring inflow and outflow, subtracting the two, and closing block valves along the line if the difference gets too large. What it does say, however, is that the sensing, logic, and actuation features of a safety instrumented system at a local site should not rely on the SCADA system.

In fact the design of a process that is to be controlled and monitored by a SCADA system should always include an assessment of the result of each conceivable type of failure of the SCADA. These assessments will identify some failures that can be classified as “high risk”.

Risk is measured as the product of probability of failure and consequence of failure. If the probability is high and the consequence is negligible, then the risk is not high. Similarly, if the probability approaches zero but the consequence is high, then the risk is not high.

Figure 3 shows a matrix of this method for establishing generic risk.

The evaluation of risk is becoming an engineering specialty in its own right. It should be undertaken by people who are familiar with the process, equipment, operating conditions, and evaluation methods. High risk failures should be guarded against by installing local safety instrumented systems.

The International Society of Automation (ISA) has developed a standard, ANSI/ISA-84.01 – Programmable Electronic Systems for Use in Safety Systems, which deals with the requirements of safety instrumented systems.

Example of what not to remote control

The following example illustrates one of the few high-risk applications in which SCADA is involved in a safety-related system. Even here, local loop protection may be involved. This example is SCADA system monitors the inflow and outflow of a liquid hydrocarbon pipeline.

At the MTU location, calculations are done to determine if the inflow is equal to or less than the outflow. If more liquid is measured going into the line than going out of it, the MTU will recognize a leak and will send a message to the RTU at each end that will cause a block valve at each of those two locations to close. As an alternative, the MTU may send an alarm message to the operator who will then decide whether to shut in the line by closing the remotely operated valves.

Rather than allow the pump to continue forcing oil into the line, the designer should assume that the MTU will not send a timely shutdown instruction.

A local shut-down loop, as shown in Figure 6 above, that is based on low pressure or on the rate of change of pressure drop will not detect small leaks as quickly, but will provide protection for large leaks. The large ones are those with the most severe consequences.

Reference // SCADA Supervisory Control and Data Acquisition by Stuart A Boyer (Purchase paperback from Amazon)