Sub.

: Supervisory Control Fundamentals

Lec.2 – Real Time Systems

Senior-lecturer: Samigulin Timur Ildusovich

Almaty, 2019
Real-Time Systems
For long time, SCADA operated independently of other computer-
based systems, and the issue of whether it was a real-time system was
unimportant. Increasingly, however, we are now finding that SCADA is
interfacing with applications that can operate on either a scheduled or
a requested basis. A little thought about what SCADA systems are
expected to do and, for that matter, what the letters in SCADA actually
stand for will lead to the conclusion that SCADA fits somewhere
between real-time and batch operation. It has elements of each. This
unit will consider the aspects of SCADA systems that make them similar
to real-time systems and how those aspects contribute to decisions
affecting the design of SCADA systems.
Learning objectives
1) Understand the terms that deal with time response.
2) Understand the criteria to be considered when selecting
scan interval.
3) Know the factors that affect decisions about where to place
calculation or computing elements.
What Really is Real Time?
• The term real-time control is defined as "pertaining to the
performance of a computation during the actual time that the related
physical process transpires." In the context of SCADA it refers to the
response of the control system to changes in the process. In rigorous
terms, a real-time control system is one that introduces no time delay
or dead time between the reception of a process measurement and
the outputting of a control signal.
• In fact, nearly all control systems must introduce some time delay.
Those that introduce an amount without any measurable effect are
usually called real-time control systems. It may be helpful to think of
batch mode control as being the opposite of real-time control.
• Most systems that control
continuous processes operate in
real time.
• Consider figure 1. The controlled
variable signal is fed to the input of
the control system with no time
delay. The controller operates on
this signal as quickly as possible
with the control algorithm. The
manipulated variable is output to
the process immediately. Time
delays exist in the control side of
the system, but they are usually Figure 1 – Most continuous process control minimizes time delay
kept very short.
• Figure 2 shows a simple SCADA with
the MTU scanning three RTUs.
• The MTU asks RTU number 1 for
flow information about the flow
through FE-101, then it asks each of
the other RTUs about flow through
their flow elements. The scan
interval (sometimes called "scan
period") is the time between one
conversation with an RTU and the
next conversation with the same
RTU. It is obvious that the Figure 2 - MTU Asks Each RTU In Turn About Its Flow Information
constraints of the SCADA system
and its method of low-speed
scanning are going to introduce a
time delay.
 Figure 3 plots the delay. The decision whether to
allow the control to be affected by the scan interval can
only be made by someone familiar with the process. At
the early stages of design of the SCADA system, scan
interval can be selected to mitigate against some of the
time delay effects.
In particular, systems for indicating status or for
alerting operators to process conditions that are out of
limits (alarms) attempt to introduce as little time delay as
"economically feasible." This is an important phrase when
considering SCADA. It does not mean "as little time as
possible." It means that the time response to the alarm
must be considered when determining how quickly the
alarm must be made known to the operator.
The following three examples will help to clarify
this. For each example, a process upset or equipment
failure has been recognized. The SCADA system signals
the operator that an alarm condition exists. The operator
then responds to return the process to nominal.

Figure 3 – Time delay with SCADA system

Example 1
• Out-of-limits condition: A beam pump on an oil well located at site
10-22 has stopped. Such pumps lift oil from the underground
reservoir. When the pump stops, the flow of oil stops.
• Alarm signal: "Beam pump 10-22 stopped."
• Likely response: On the next scheduled visit to this part of the oil
field, the field operator will plan to spend enough time at this site to
determine the cause of the pump's failure, will write up a description
of the failure, and will call in appropriate maintenance personnel to
repair it.
• The economically feasible time delay for this response is on the order
of hours—perhaps as much as twenty-four hours.
Example 2
• Out-of-limits condition: An electric submersible pump on an oil well
located at site 6-33 has stopped.
• Alarm signal: "Pump 6-33 stopped."
• Likely response: Electric submersible pumps are expensive, high-
volume pumps. For this reason, they are installed on high-volume
wells. Because this well produces a very large amount of oil and
downtime is important to the company, a maintenance crew will be
dispatched, day or night, as soon as the alarm is received.
• The economically feasible time delay for this response is on the order
of minutes—perhaps as much as one hour.
Example 3
• Out-of-limits condition: An electric switch between generator number
G510 and the electric transmission system has opened.
• Alarm signal: "Generator G510 switch open."
• Likely response: A generator that is presently in the spinning reserve
mode will be connected to the transmission grid as soon as possible.
• The economically feasible time delay for this response is on the order
of a few seconds—perhaps five seconds.
• From these three examples, it should be clear that
the response time the process requires should be
the overriding consideration when determining
what is and what is not "real time." Rigorously
speaking, real time is response with no measurable
time delay. Practically, real time means that the
time delay of the system is not long enough to
introduce problems in control. For this reason,
much of SCADA is considered to be real-time
control, even though a recognized time delay is
associated with it.
Communications Access and “Master-Slave”

• Electronic machines can talk to

each other in several ways.
Depending on the purpose of
their conversation, the required
speed, and the machines' status
relative to each other, different
access methods may be used. The
communications requirements
both determine and are
controlled by the communications
protocol selected.
• This is not a text on communications, so it will not describe many of
the communications access methods that exist. The communications
method used by most existing SCADA systems is called "master-
slave." In a master-slave arrangement, only one of the machines (in
this case the host or MTU) is capable of initiating communication. The
MTU calls one RTU, gives instructions, asks for information updates,
and orders the RTU to respond. The MTU then listens for the answer.
The RTU answers as soon as the MTU has finished talking, then stops
talking and listens for more orders. The MTU moves to the second
RTU and goes through the same procedure. The MTU talks to each
RTU, then returns to the first. The RTU cannot initiate a message; it
can send a message only when specifically ordered by the MTU to do
so.
• The process of talking to each RTU in order and then going back to
the first RTU to begin the cycle all over again is called "scanning."
Determining Scan Interval
• Control should not be compromised by excessive time delay; however,
there are time constraints imposed by the rate at which data can be
transferred between the MTU and the RTU. It therefore follows that
there is a "best rate" at which to scan the RTUs for data. One of the
factors that determines scan interval must be the number of RTUs that
have to be scanned. An estimate of the likely number of RTUs, made
early in the design phase, will probably be sufficient to determine what
this number is.
• A second factor to be considered is the amount of data that must be
passed on each conversation. This will be determined by the size of
the facility at each remote site and the amount of independence the
remote site control is capable of exercising. Depending on these, the
data to be gathered can be as little as one status point or as much as
several hundred status and alarm points, as well as several dozen
meter totalizer points and several dozen analog values. To
communicate, each status or alarm point requires one (usually) or
two bits (less frequently) of data. Since each meter or analog point
will be transcribed to a binary word, each point requires about
sixteen bits. (This will vary with different equipment but is a close
enough number for this calculation.)
• For simplicity as well as for safety reasons, it is best to select the
largest RTU when evaluating points. Multiply this point count by the
total number of RTUs to get the count of all data coming back from all
RTUs.
• Remember that a conversation is usually a transfer of data in both
directions. It is important to include the time taken for the MTU to
talk to each RTU. This will include both the time for the MTU to ask
the RTU for information and the time for the MTU to give other
instructions to each RTU. Again, at the design stage the best way to
take these two times into account is to evaluate what this point count
is for the largest outgoing message and then multiply by the number
of RTUs. This should provide a conservative result because the
messages from MTU to RTU are usually shorter than the messages
from RTU to MTU. Evaluating each RTU individually may be beneficial
if the exercise is being done on an existing system.
• The third factor is the data rate. The number of bits per second (bps)
that can be transmitted over the communications medium is
important in determining scan interval, but at the early design stages
this number may be flexible. Bps numbers may be traded back and
forth to develop an optimum. At this point in the process of
determining scan interval, consider that there are two data rate
groupings. The first, which is used on voice-grade telephone lines and
most UHF radio-modem communications systems, is between 300
and 2400 bps. Using 1200 bps in the calculation will give you a good
first estimate. The second data rate grouping applies if a special
communications medium is being considered. It may be as low as
19,200 bps or as high as 10 million bps. For systems that are complex
enough to require these data rates there will be a specialist on the
design team who can provide a meaningful data rate for this
calculation.
• The fourth factor in determining scan interval is communications
efficiency, which may be thought of through the following ratio: the
time spent moving the data of interest divided by the total time spent
communicating. Much of the inefficiency is obvious. For example,
part of each message must include the RTU address, which is not
really data that holds any interest. Some of the inefficiency is not so
obvious, however.
• Error-detection codes are frequently used, and these take time.
Similarly, radio turn-on times may take more time than the message.
These will be dealt with in Units 6 and 7, respectively, but as a first
approximation use the following numbers for communications
efficiency: dedicated telephone line, 70 percent; radio, 40 percent;
dial-up telephone, less than 1 percent.
Example 4
• Based on the preceding discussion, calculate a scan interval for a
SCADA system.

Therefore, 20 x 896 = 20,000 bits to move at a data rate

of 1200 bps, which would take 20,000 bits + 1,200 bps = 17
seconds at 100 percent efficiency.
At 40 percent efficiency, the scan interval is 17 seconds
= 0.4 = 42.5 seconds.
It would be good design practice to round this 42
seconds up to one minute. Having calculated this number,
it would be wise to ensure that no process functions will
be adversely affected by a delay of one minute. If such
functions do exist but only at one or two of the RTUs, the
problems may be addressed by scanning each of those
RTUs twice in the scan.
Example 5

• If the scan rate were acceptable for all except RTU number 5 in a
system of five RTUs, the scanning program could be set up as follows:
• RTU 1, RTU 2, RTU 5, RTU 3, RTU 4, RTU 5, RTU 1...
• As with most quick-fix solutions, there are limits to how often this can
be done without degrading the rest of the system
• If most of the RTUs show process functions that are marginally good
or bad from a timing point of view, the best solution may be to
increase the data rate (in this case, from 1200 bps to 2400 bps). It is
important to realize that doubling the data rate will not reduce the
scan period by one half.
• Communications efficiency is a nonlinear function of data rate. If
many problems are identified and the process requires a response
time that is orders-of-magnitude shorter than the problems will allow,
it may be necessary to review the communications method. It may be
that some functions should be removed from the SCADA system.
• Provision should be made for additions to the amount of data to be
transmitted. Most SCADA systems have functions added to them over
their lives; few have functions deleted. Next topic will address some
of the activities that should not be dependent on the
communications system.
 Where to Compute?
• Have you noticed as you travel on a freeway
that is well lighted by mercury or sodium
lamps that the spokes on the hubcaps of the
car next to you are visible and are slowly
turning—sometimes backward, sometimes
forward? This is the "strobe effect," and it
happens because the street lights give off a
burst of light every 1/60 second (every 1/50
second if your power system is 50 Hz). If the
spokes of the hubcap are turning so that a
spoke is at (or near) the same position that
another spoke was 1/60 of a second ago, your
eyes will be fooled into thinking they are
seeing the same spoke.
• Figure 4 shows how this works. To clarify
the illustration, one of the spokes (the one
in the twelve o'clock position) in Figure 4(A)
has been smeared by road tar. If we assume
a 30-inch-diameter wheel with six spokes,
the configuration shown in Figure 4(B) will
happen 1/60 of a second later if the car is
going 53.55 mph, and the configuration in
Figure 4(C) will happen 1/60 second after Figure 4 – Sampling frequency and “aliasing”
that of Figure 4(B).
Now take off the road tar. Imagine that the car is going 107.1 mph or 160.65 mph or any
integral multiple of 53.55 mph. If you could see (or sample) only the relative position of the
spokes, you would have no way to tell how fast the car is going. The spokes would not appear
to move. If the car were going a bit slower, the hubcap would appear to rotate backward; if
the car were moving a bit faster, it would appear to rotate forward slowly.
• So, for a case that has the physical constraints we have described, there is
something magic about 53.55 mph and the sampling frequency of 60 Hz.
• The "magic" is that for every integral multiple of 53.55 mph, a spoke (we
don't know which one) passes through the top vertical position. Now turn
the problem around. Say we know that the range of speeds is between 0
mph and 53.55 mph and we wish to calculate the minimum frequency of
the strobe so we can unambiguously determine the speed. How could we
do it?
• Since we know that it takes 1/60 of a second for the spoke to advance one
position, we must fire the strobe a bit faster than 1 /60 of a second if we
want to sample the situation that exists before the spoke gets there. The
frequency must be faster than 60 Hz, because at 60 Hz one spoke could
masquerade as another. In this example, 60 Hz is called the "aliasing
frequency." For a similar situation in which the number of spokes is changed
to twelve, the aliasing frequency would be 120 Hz.
• This is all very interesting, you say, but what does it have to do with
SCADA? If the physical attributes of the process to be controlled,
including the highest natural frequency of the process, are known the
aliasing frequency can be calculated. The process parameters can be
sampled effectively at frequencies higher than the aliasing frequency but
not at lower frequencies. So this simple test of how frequently the
process must be sampled can tell if the scan frequency is adequate for
sampling.
• If it is adequate and if the measurement is not too critical, the process
can be sampled, the raw data can be scanned, the calculation (or
computation) can be done in the MTU, and the result can be sent back to
the RTU and processed. On the other hand, those processes that have
aliasing frequencies higher than the selected scanning frequency must
have the computations done before the scanning. These computations
must take place in the RTU or some other equipment at the same
location as the RTU.
• The following two examples will illustrate this point.
Example 6
• Given that, from Example 4, a scan interval of one minute is practical,
determine where the calculations should be performed to measure the
amount of water produced from a well using a tank metering system.
Such metering systems are used on irrigated farms to keep track of the
amount of water diverted to a field. Water flows into the tank until it is
full, then stops. A valve is then opened to start the flow of water from the
tank to the field. When the tank becomes empty, the drain valve closes,
and the tank refills. It takes four minutes to fill the tank and four minutes
to drain the tank. Status switches on the drain valve are monitored by the
SC ADA system. When the drain valve is dosed, the refill valve is open and
vice versa.
• Question: Can the flow totalizing be done at the MTU?
Answer:
• Since the scan interval is one minute (from Example 1) and the
aliasing frequency (the highest cycling frequency in the process) is
one cycle (of the refill valve) in four minutes, this calculation would be
an acceptable one to do at the MTU.
Example 7
• Question: Assume the same conditions as in Example 4-6, except that
only forty seconds are required to refill the tank. Can the flow
totalizing be done at the RTU?
Answer:
• Since the drain valve contains operating frequencies (one cycle / 40
seconds or 0.025 Hz) higher than the scan frequency (one cycle / 60
seconds or 0.017 Hz), there will be cycles that are short enough for the
valve to close and then open before the SCADA system completes a scan.
• The MTU will have no way to know that the cycle happened. In this case,
the totalizing should be done at the RTU. Note that the entire operation
may cycle in less than a scan period, but if the part of the cycle that is being
sampled cycles in less than a scan period you will get the wrong
measurement. The RTU should use a sampling frequency higher than the
MTU scan frequency and one designed to cover the process aliasing
frequency. But as we will see in Unit 8, that is not an onerous requirement.
• The periods of scan intervals within most RTUs are usually on the order of
milliseconds.
• Given that some rather simple calculations can be used to determine
which computations should be done at the MTU and which should be
done at the RTU, there remains the question of what hardware
should be used to perform auxiliary calculations at the RTU's location.
Because of the enormous reduction in the cost of small computer
hardware, it is now feasible to purchase a computer that is powerful
enough to complete, in a timely manner, all of the calculations, all of
the instruction to sensors, and all of the storage of historical data that
may be needed at the site. This means that it is possible to have the
computer-based RTU do all of the remote site calculations.
• There are several reasons why you do not want to put "all your eggs
in one basket" and do all of the calculations in the RTU. As will be
explained in next topics, safety-related considerations call for the use
of fail-safe logic for safety shutdowns. Regulatory requirements may
mandate that meter totalizer logic be located in separate locked
enclosures. Small, simple RTUs supported by special-purpose logic
modules may be more price competitive than large, complex RTUs
that can do all of the logic calculations. Finally, some control
calculations require input data from more than one remote site.
These control functions are most logically completed at the MTU.
Simple orders can then be sent to the appropriate RTUs to effect the
controls.
EXERCISES 1
• Real time is relative. For the following process concerns, determine if
the response time is adequate:
a. Customer billing for gas through a meter is issued once per month.
The scan rate is once per hour.
b. Customer billing for gasoline is based on individual fill-ups, each
lasting ninety seconds. The scan rate o f the meter is once per hour.
c. Two meters measuring gas into and out of a pipeline are scanned
every ten minutes. An alarm is generated if the sum of the last four inlet
measurements exceeds the sum of the last four outlet measurements.
EXERCISES 2
• An RTU recognizes that a motor that should be running has stopped.
It is 2:00 a.m. For this motor failure, overtime is not allowed, so no
maintenance crew will be sent to investigate until 9:00 a.m.
a. Would a ten-minute scan rate be acceptable?
b. Would a one-hour scan rate be acceptable?
c. Would a twenty-four-hour scan rate be acceptable?
EXERCISES 3
1) An RTU determines that afire is burning in the chlorine injection
building of a water treatment plant. Because this is an extremely
serious condition, what can the RTU do to notify the MTU without
waiting for the next scan?
2) Describe one way that the scan rate for a single RTU could be
increased beyond the scan rate for the other RTUs.
3) What is the range of data rates for most SCADA systems?
4) Name three things that detract from communications efficiency.
5) In Example 1, what would be the scan interval if a dedicated
telephone line, not a UHF radio, were the communications medium?
EXERCISES 4
• The liquid level in a column gravity separator is observed to cycle with
a two-minute period from one maximum level to the next. What
would be the effect of sampling this level with the following:
a. A two-minute scan rate?
b. A thirty-second scan rate?