A room is to be kept at a comfortable temperature, or a vessel containing some material is to be kept at a specific temperature.

The input is the amount of heat applied; this may be the dial setting on the stove, the voltage applied to the heating element, or the flow of heating oil to the furnace.

In any case, the temperature of the heated object is the output of the process.

This example is a conventional control problem, where the control strategy—including the choice of input and output signals—is pretty clear. Notice that the control strategy can vary: central heating often has only an on/off controller, whereas stoves let you regulate their power continuously.

Although simple in principle, this example does serve to demonstrate some of the challenges of control engineering in the physical world. We said that the output of the plant is “the temperature” and that its input is “the heat supplied.” Both are physical quantities that are not easy to handle directly. Just imagine having to develop a physical device to use as a PID-controller that takes “a temperature” as input and produces a proportional amount of “heat” as output! For this reason, most control loops make use of electronic control signals. But this requires the introduction of additional elements into the control loop that can turn electric signals into physical action and observed quantities into electric signals (see Figure 5-3, top).

Figure 5-3. Typical physical control loops, including transducers to convert between physical quantities and control signals (which are usually electrical signals). Top: Schematic. Bottom: A control loop configuration for the heated vessel example, showing the observed quantities and control signals in some detail.

Elements that convert back and forth between control signals and physical quantities are generally known as transducers. A transducer that measures a physical quantity and turns it into a control signal is called a sensor, and a transducer that transforms a control signal into a physical control action is called an actuator. In the case of the heated vessel, the sensor might be a thermocouple (transforming a measured temperature into a voltage), and the actuator would be a heating element, transforming an applied voltage into heat (Figure 5-3, bottom). If the vessel to be heated is large (such as a reaction vessel in the chemical industry) or if high temperatures are required (as in a furnace), then a single actuator might not be enough; instead we might find additional power amplifiers between the controller and the actual heating element.

Transducers introduce additional complexity into the control loop, including nonlinearities and nontrivial dynamics. Sensors in particular may be slow to respond and may also be subject to measurement noise. (The latter might need to be smoothed using a filter, introducing additional lags.) Actuators, for their part, are subject to saturation, which occurs when they physically cannot “keep up” with the control signal. This happens when the control signal requires the actuator to produce a very large control action that the actuator is unable to deliver. Actuators are subject to physical constraints (there are limits on the amount of heat a heating element can produce per second and on the speed with which a motor can move, for example), limiting their ability to follow control signals that are too large.

In computer systems, transducers rarely appear as separate elements (we do not need a special sensor element to observe the amount of memory consumed, for instance), and—with the exception of actuator saturation—most of their associated difficulties do not arise. Actuator saturation, however, can be a serious concern even for purely virtual control loops. We will return to this topic in Chapter 10 and in the case studies in Part III.

Consider an item cache—for instance, a web server cache. If a request is made to the system, the system first looks in the cache for the requested item and returns it to the user if the item is found. Only if the item is not found will the item be retrieved from persistent storage. The cache can hold a finite number of items, so when an item is fetched from persistent storage, it replaces the oldest item currently in the cache. (We will discuss this system in detail as a case study in Chapter 13.)

The quantity that can be controlled directly is the number of items in the cache.

The quantity that we want to influence is the resulting “hit” or success rate. We desire that some fraction (such as 90 percent) of user requests can be completed without having to access the persistent storage mechanism.

Observe that the quantities identified as “input” and “output” from a control perspective have nothing to do with the incoming user requests or the flow of items into and out of the cache. This is a good example of how the control inputs and outputs can be quite different from the functional inputs and outputs of a system—it is important not to confuse the two!

Also, the definition of the output signal is still rather vague. What does “90 percent hit rate” mean in practice? Ultimately, each hit either succeeds or fails: the outcome is binary. Apparently we need to average the results of the last n hits to arrive at a hit rate, which leads us to ask: how large should n be? If n is large, then the outcome will be less noisy but the memory of the process will be longer, so it will respond more slowly to changes (see Chapter 3). Selecting a specific value for n therefore involves a typical engineering trade-off.

We also need to define how the average is to be taken. Do we simply calculate a straight average over the last n requests? Or should we rather weight more recent requests more heavily than older requests? For practical implementations, it may be convenient to employ an exponential smoothing method (a recursive digital filter), where the value of the hit rate s_t at time t is calculated as a mixture of the outcome of the most recent user request σ_t and the previous value of the hit rate:

Here, σ_t is either 0 or 1, depending on the outcome of the most recent cache request. The smaller α is, the smoother the signal will be. (In fact, we can choose whether to consider the filter as part of the system itself or to treat it as a separate component. In the former case, the system output will be the smoothed hit rate; in the latter case, the system output will be the string of 0’s and 1’s corresponding to the outcome of the most recent request.)

Finally, we should discuss the notion of “time” t. From the preceding remarks it is clear that the system will not produce a new and different value of its output unless a user request is made. We must decide when control inputs (that is, changes to the size of the buffer) can be made: only synchronously with user requests, or asynchronously at any time that we desire (for instance, periodically once per second)? In the asynchronous case, the main “worker thread” of the cache (the one that handles user requests) will be separate from the “control thread” that handles control inputs. This is yet another reminder that control flow and functional flow are quite separate things.

Imagine a central server performing some task. It could be a web server serving user requests, or a compute server performing CPU-intensive jobs, or even a DB server. In any case, we can control the number of active “worker” instances (the number of threads in the case of the web server, or the number of CPUs for the compute server, and so on). Incoming requests are assigned to the next available worker instance; it will take the worker some (random) amount of time to complete each request. Requests that cannot be served immediately are submitted to a queue. There is no guarantee that the throughput of the server will scale linearly with the number of active worker instances! (More specific systems fitting this general description will be discussed in detail in Chapter 15 and Chapter 16.)

We can select the number of active worker instances directly.

Ultimately, we want to make sure tasks are flowing through the system without being held up. However, we have a wide selection of metrics that can be used for that purpose. These include:

Which of these quantities to use will be one of the design choices.

In this example, we observe again that the functional flow of requests into the controlled system has nothing to do with the input and output signals that we use for control purposes. Moreover, and also as in the previous example, we find that the control input is easy enough to find, yet we have considerable freedom in the definition of the process output.

From a business domain perspective, the maximum age among all the requests in the queue seems like a good metric because it represents a quantity that is immediately relevant: the worst-case waiting time. However, because it depends on a single element only, this metric will be noisier than the average waiting time across all elements currently in the queue. On the other hand, the average waiting time responds more slowly to changes in the environment because the effect of any change is “averaged out” over the number of items in the queue. This is not desirable: we want signals that make any change visible quickly so that we can respond to them without delay.

Any form of smoothing or averaging operation slows signals down, but a poor choice of raw signal can also result in delayed visibility. The age of the last completed request has this property: if we use this quantity as a control signal, then we will not learn about the growth of the queue until every item has actually propagated through the queue to a worker instance! With this choice of monitored quantity, we are in the undesirable position that—by the time we learn what’s going on—it’s already too late to do something about it. For this reason, we want to begin monitoring items as soon as possible, that is, when they enter the queue and not when they leave it.

Although the maximum or average age of items in the queue may be a desirable control signal from a business domain perspective, it may not be available on technical grounds. We may not know the time stamp for each item’s arrival simply because this information is not being recorded! In this case, we may have to fall back on using the number of items currently in the queue. This quantity has the advantage that it is both easy to obtain and responds quickly to changes, but it is less directly related to the property that we really want to control. (The queue length actually does not matter much provided that items are being processed at a rapid rate.) In the end, the net change in the length of the queue may seem like a good compromise: it responds quickly, does not depend on a single item, and is relevant from a domain perspective. Too bad it cannot be observed directly! We must calculate it as the difference between the previous and the current queue length—a procedure that still requires us to fix the interval at which we observe the queue length.

All the quantities discussed so far tend to decrease as the input quantity (namely the number of active worker instances) is increased, so we will need to use a loop structure suitable for this kind of input/output directionality. In contrast, the last two items in the list of possible output signals (requests completion rate and amount of idle time) tend to increase with the number of server instances available.

Consider a merchant selling some arbitrary product. The merchant has the goal of selling a certain number of units every day; the merchant’s primary control mechanism is the item price, which can be adjusted on a daily basis. (An application of this situation is discussed as a case study in Chapter 14.)

The price per unit.

The number of units sold.

In this example, the choice of input and output quantities is obvious; but what exactly constitutes the “plant” and its dynamics merits some discussion.

The input and output for this problem (namely, price and units sold) are related through what economists call the demand curve (although they tend to interchange the respective roles of price and demand). Typical shapes of the demand curve—using our identification of independent and dependent variables—are shown in Figure 5-4. (Note that these curves, too, have the property that increasing the input leads to a decrease in output, which makes the use of the “inverted” loop structure necessary.)

If the merchant knew this curve, then there would be no need for a feedback system to control demand: the merchant could simply pick the exact price that would result in the sale of the desired number of units. However, in general the merchant does not know the demand curve—hence the need for a system that automatically applies corrective actions as needed.

So then where is the “memory” that, according to the discussion in Chapter 3, is the hallmark of systems with nontrivial dynamics? At first, it might appear as if there is no memory: at the beginning of each day, the vendor can fix a new price that becomes effective immediately. Nevertheless, the memory is there—in this case, it is quite literally in the vendor’s head! The feedback mechanism will not work if the merchant randomly chooses a new price every day. Instead, for the feedback loop to be closed, the price the merchant quotes tomorrow must be based on the number of units sold today, which in turn is a consequence of today’s price. The feedback controller in this case does not so much produce a new price as it produces an update to the current price.

So far we have assumed that the demand curve itself does not change over time—or, at least, that it changes sufficiently slowly that these changes can be ignored for day-to-day price finding. Furthermore, we assumed that the price–demand relationship is deterministic, without random variations. That’s not likely to be the case in practice (demand typically fluctuates), but this does not pose a fundamental challenge. The demand could be averaged over a few days to obtain a smooth control signal, even though this operation will introduce some inevitable delays.

Figure 5-4. Two typical shapes of the demand curve, which relates the number of units sold to their price.

We also have not mentioned how the merchant chooses the number of units to sell every day. Couldn’t the merchant make more money by selling more units at a lower price? That’s an interesting question, but it is extremely important to remember that feedback control does not provide any help in answering it! Feedback control is a mechanism to track a reference signal—not more, not less. In particular, feedback control makes no statement, which value for the setpoint is “optimal.” That question must be answered separately; once it has been answered, feedback can be used to execute on this plan.

Finally, keep in mind that the terms “merchant,” “price,” and “demand” in this example are largely metaphorical. Similar considerations apply in other situations, as long as there is a long sequence of fundamentally similar transactions that are being completed over time. A consumer, repeatedly buying from a supplier, fits the same model. Note also that the “price” or “cost” need not be measured in monetary units. For example, the task server example discussed previously can be expressed in these terms—provided the server is able to report on the “effort” expended in a way that can be used as a control signal.

Many computer systems require active cooling (using fans) to keep components at acceptable operating temperatures. (See Chapter 17 for an in-depth discussion of this example.)

The input is the fan speed or the voltage applied to the fan—the details will depend on the interface provided by the system.

It may appear as if the process we want to control is the CPU and so its temperature should be the output, but this is not quite right. The process we want to control is the cooling of the CPU by the fan; therefore the proper way to measure this process is the reduction in temperature achieved. Remember that if the process is off (that is, if the fan is not running) the output should be zero, and that the process output should increase in line with the input. (Yet another example of an “inverted” output signal.)

This example is interesting, because the physics is exactly the same as in the heating example that opened this chapter, yet many details that are relevant for a control application are different. We have already seen that we need to be careful with the choice of output signal. Another possible misidentification concerns the process dynamics.

The temperature of a computer component has its own dynamics, which are the same as that of any other heated element: once switched on, the temperature will increase and eventually reach a thermal equilibrium in which the component gives off as much heat as is being supplied externally. But that is not the dynamic we want to control! Instead, the dynamic that we care about from a control perspective is how quickly the temperature of the chip drops once the fans are turned on. The “off” state of this process is a chip in thermal equilibrium, not a chip that is switched off.

But this poses an interesting operational problem: a chip in thermal equilibrium is “fried” and does not function anymore (otherwise, we wouldn’t need active cooling to begin with). Therefore, the baseline is a chip operating at its maximum permissible temperature, with just enough cooling being supplied to keep it there. As the fan speed increases, we can see how much and how quickly the temperature drops and thereby observe the dynamics of the actual control process.