Equivalent Unity Feedback System

Feedback control is the invisible engine that powers much of our modern world, from simple home appliances to complex aerospace vehicles. We use the language of block diagrams to map out how these systems work, comparing what we want with what we get and making corrections. The simplest and most intuitive representation is the unity feedback system, where the output is directly compared to the input command. However, real-world systems are rarely so simple; sensors used for measurement have their own delays and dynamics, creating what is known as a non-unity feedback system. This discrepancy presents a challenge: how can we analyze these more complex, realistic systems using the powerful yet simple tools developed for the ideal case?

This article bridges that gap by introducing the elegant concept of the ​​equivalent unity feedback system​​. It is a powerful analytical technique that allows us to transform any non-unity feedback system into an equivalent one with unity feedback, preserving its exact input-output behavior. This transformation provides a standardized framework, making the analysis of system performance, particularly steady-state error, clear and consistent. In the following chapters, we will first explore the "Principles and Mechanisms" behind this transformation, deriving the key formulas and understanding its immediate benefits. Following that, in "Applications and Interdisciplinary Connections," we will see how this theoretical tool provides deep insights into the behavior of real-world systems, from semiconductor manufacturing to satellite control.

In our journey to understand and command the world around us, we build systems—from the humble thermostat in your home to the sophisticated autopilot in an airplane—that regulate themselves. The magic behind this self-regulation is the concept of ​​feedback​​. It’s a simple, profound idea: look at what you’re getting, compare it to what you want, and adjust your actions accordingly. In the language of control engineering, we represent this dance of signals and responses using block diagrams, a kind of flowchart for dynamics.

Imagine you’re steering a car, trying to keep it in the center of a lane. Your eyes (the sensor) see the car’s actual position, your brain (the controller) compares this to the desired position (the center line), and your hands (the actuator) turn the steering wheel to correct any deviation. In the most straightforward scenario, the information your eyes provide is a direct, unadulterated picture of reality. You see the position, and you react to that exact position.

This ideal case is what we call a ​​unity feedback system​​. The name comes from the fact that the feedback path has a "gain" of one—the signal fed back for comparison is the exact output of the system. If the desired output is given by a reference signal $R(s)$ and the actual output is $Y(s)$, the error that drives the system is simply $E(s) = R(s) - Y(s)$. This is beautifully simple. It's the most direct comparison between "what I want" and "what I have." Most of our introductory tools for analyzing system performance, like stability and accuracy, are developed for this clean, intuitive setup.

Nature, however, rarely deals in such pristine simplicities. The sensors we use to measure the world are themselves physical systems. A thermometer doesn’t register a temperature change instantaneously; it takes time to heat up or cool down. A tachometer measuring engine speed might have its own electrical dynamics. These imperfections mean that the signal fed back to the controller is not the pure output $Y(s)$, but a modified, filtered, or delayed version of it.

We model this modification with a transfer function in the feedback path, which we call $H(s)$. If $H(s)$ is not equal to 1, we have a ​​non-unity feedback system​​. Now, the signal being compared to our reference $R(s)$ is not the true output $Y(s)$, but a "reported" output, $B(s) = H(s)Y(s)$. The signal that actually drives the controller, which we call the ​​actuating signal​​, becomes $E_a(s) = R(s) - H(s)Y(s)$.

This seemingly small change throws a wrench in our simple analytical machinery. The error we truly care about—the actual discrepancy between our goal and our result, $R(s) - Y(s)$—is no longer the signal being used to drive the correction. How, then, can we use our well-established tools, which were built for the unity feedback world, to analyze this more complex, realistic situation? Do we have to invent a whole new set of rules?

Here we arrive at a beautiful piece of intellectual sleight-of-hand, an algebraic transformation so elegant it feels like magic. The goal is to find a new system, one that has unity feedback, but which behaves, to the outside world, exactly like our original non-unity system. "Exactly" means that for the same input $R(s)$, it must produce the identical output $Y(s)$. We are looking for an ​​equivalent unity feedback system​​.

Let's do the math. It's simpler than you might think.

The overall input-output relationship, or the ​​closed-loop transfer function​​, for our original system with forward path $G(s)$ and feedback path $H(s)$ is: $\frac{Y(s)}{R(s)} = T(s) = \frac{G(s)}{1 + G(s)H(s)}$

Now, consider a hypothetical unity feedback system with a new, yet-to-be-determined forward path, let's call it $G_{eq}(s)$. Its closed-loop transfer function is: $\frac{Y(s)}{R(s)} = T_{eq}(s) = \frac{G_{eq}(s)}{1 + G_{eq}(s)}$

For these two systems to be "equivalent," their overall transfer functions must be identical. So, we set $T(s) = T_{eq}(s)$: $\frac{G_{eq}(s)}{1 + G_{eq}(s)} = \frac{G(s)}{1 + G(s)H(s)}$

Our task now is to solve this equation for $G_{eq}(s)$. It's a bit of algebraic housekeeping. We cross-multiply to get: $G_{eq}(s) \big(1 + G(s)H(s)\big) = G(s) \big(1 + G_{eq}(s)\big)$

Expanding both sides gives: $G_{eq}(s) + G_{eq}(s)G(s)H(s) = G(s) + G(s)G_{eq}(s)$

Now, we gather all the terms containing our unknown, $G_{eq}(s)$, on one side: $G_{eq}(s) + G_{eq}(s)G(s)H(s) - G(s)G_{eq}(s) = G(s)$

Factoring out $G_{eq}(s)$ yields: $G_{eq}(s) \big(1 + G(s)H(s) - G(s)\big) = G(s)$

And with one final division, the rabbit is out of the hat. The equivalent forward path is: $\boxed{G_{eq}(s) = \frac{G(s)}{1 + G(s)H(s) - G(s)}}$ This can also be written in the perhaps more intuitive form: $G_{eq}(s) = \frac{G(s)}{1 + G(s)\big(H(s) - 1\big)}$

This remarkable formula is our philosopher's stone. It allows us to take any non-unity feedback system, no matter how complicated its $G(s)$ and $H(s)$ might be, and transmute it into a unity feedback system with a new effective forward path, $G_{eq}(s)$. This process is demonstrated with various specific systems in problems,, and. The underlying principle is always the same: preserve the overall input-output behavior.

So, we've performed this clever transformation. What have we gained? The primary benefit is clarity and standardization, especially when we analyze a system's accuracy. One of the most important questions we can ask about a control system is: "Does it eventually reach its target?" The difference between the desired value and the actual value as time goes to infinity is called the ​​steady-state error​​.

For a standard unity feedback system, the error is $E(s)=R(s)-Y(s)$, and its steady-state value can be found using well-known formulas involving ​​static error constants​​ ($K_p, K_v, K_a$). These constants are calculated directly from the system's open-loop transfer function, $G(s)$.

But for a non-unity system, what is the "error"? Is it the actuating signal $E_a(s) = R(s) - H(s)Y(s)$ at the summing junction, or is it the true tracking error $E(s) = R(s) - Y(s)$? This is a crucial point of confusion. If you try to apply the standard formulas to the true tracking error $E(s)$, they don't work. The mathematical forms don't match.

Our transformation provides the answer. By converting the system to its unity feedback equivalent with forward path $G_{eq}(s)$, we now have a system where the error at the summing junction is the true tracking error, $R(s) - Y(s)$. We can now apply all our standard tools for steady-state error analysis to this new system, using its open-loop transfer function, $G_{eq}(s)$, to find the error constants. We have restored the simple picture and can proceed with confidence.

Alternatively, another way to look at it is to recognize that the core dynamics of feedback are governed by the ​​loop gain​​, which for the original system is $G(s)H(s)$. If you analyze the steady-state value of the actuating signal $E_a(s)$, you find that it depends on the loop gain $G(s)H(s)$ in the exact same way that the error in a unity system depends on its loop gain $G(s)$. For this reason, many engineers define the static error constants for a non-unity system directly from the loop gain $G(s)H(s)$. This is a valid shortcut, but it requires you to remember that the error you are calculating is the steady-state actuating signal, not the steady-state tracking error. To find the true tracking error, you'd need an extra calculation step.

Whether you choose to perform the full transformation to $G_{eq}(s)$ or use the loop gain shortcut, the fundamental idea is the same. We are leveraging a deeper understanding of the system's structure to apply a simple, unified set of rules. This ability to find an equivalent, simpler problem is not just a trick; it is the essence of powerful scientific and engineering thinking. It reveals the underlying unity in seemingly different systems and allows us to master their behavior.

We have now seen the mathematical machinery for transforming a control system with a complex feedback path into an "equivalent" one with simple, unity feedback. You might be tempted to ask, "Why bother with this algebraic sleight of hand? Is it just a trick to make exam problems solvable?" This is a fair question, and the answer reveals something beautiful about the nature of engineering and physics. The transformation is not just a trick; it's a new pair of glasses. It allows us to look at a dizzying variety of systems—from the inside of a microchip factory to a satellite spinning in the void—and see them all through a single, powerful lens. It unifies our understanding by allowing us to apply one set of principles to predict the behavior of them all.

The core of the issue is this: the error that a controller "sees" is not always the error that we, the designers or users, actually care about. A controller acts on the difference between the command signal, $r(t)$, and the signal coming from its sensor, let's call it $b(t)$. But the true performance error is the difference between the command, $r(t)$, and the actual physical output, $y(t)$. If the sensor is not a perfect, crystal-clear window to reality—and no sensor ever is—then $b(t)$ will not be the same as $y(t)$. The equivalent unity feedback model is the tool that elegantly bridges this gap, letting us predict the true error, $r(t) - y(t)$, using the same simple rules every time. Let’s explore where this powerful idea takes us.

One of the most profound lessons from control theory is that you cannot separate a system from its observer. The act of measurement is part of the dynamics. In our case, the sensor isn't just a passive reporter; it's an active participant in the feedback loop, with its own delays, gains, and quirks. The equivalent unity feedback model forces us to confront this reality.

Imagine you are designing a control system for a Rapid Thermal Processing chamber in a semiconductor manufacturing plant, a place where silicon wafers are heated with incredible precision. To avoid defects, the temperature must be held rock-steady at a setpoint. A clever engineer might design the heating element and its controller to be a "Type 1" system, which theory tells us should follow a constant setpoint with zero steady-state error. It seems like the problem is solved.

But then we build the system and find a small, but persistent, error. The temperature is always off by a fraction of a degree. What went wrong? The culprit is the sensor—the pyrometer measuring the wafer's temperature. It has its own dynamics; it takes time to respond, and its output voltage might not be a perfectly scaled version of the temperature. It has a transfer function, $H(s)$, that isn't just the number 1. When we use our transformation to find the equivalent system, we discover the bitter truth. Even though the plant itself was Type 1, the non-ideal sensor makes the equivalent system behave in a way that allows for a steady-state error. The derived error, $e_{ss} = R_{0}(1-b/K_{s})$, depends critically on the sensor's parameters. This isn't a failure of our theory; it's a triumph! The mathematics predicted this subtle error and even told us its source: the sensor's DC gain, $H(0) = K_s/b$. To eliminate the error, we don't need to redesign the heater; we need a better-calibrated sensor. This principle applies everywhere, from medical devices to chemical plants: your system is only as good as your ability to measure it.

The "type" of a system is one of the most elegant concepts in this field. It's a single number that tells us what kinds of commands a system can follow without eventually falling behind. A Type 0 system can track a constant position but will lag a constant velocity. A Type 1 system can track a constant velocity with a fixed lag. A Type 2 system can track a constant acceleration with a fixed lag. This ability is governed by the number of pure integrators (poles at $s=0$) in the system's open-loop transfer function.

Now, where do these all-important integrators come from? In a simple unity-feedback system, we just count them in the plant, $G(s)$. But the real world is a dance of multiple interacting parts. Consider a simple servomechanism where the plant is Type 0, but the sensor in the feedback path is Type 1 (it has an integrator, perhaps due to some internal state accumulation). Does this give us a Type 1 system? Our intuition might say yes, adding an integrator anywhere should increase the type. But the mathematics of the equivalent system, $G_{eq}(s)$, says no. The transformation reveals that the combination results in an equivalent system that is still Type 0. The integrator in the feedback path does not contribute to the system type in the way we might expect.

The plot thickens when we look at more complex architectures, like a satellite attitude control system with multiple nested loops. Here, the satellite's dynamics, $G_2(s)$, contain an integrator, suggesting Type 1 behavior. However, there is a "minor loop" where a rate-gyro measures the satellite's angular velocity and feeds it back internally. When we perform the block diagram reduction and then find the single equivalent unity feedback system for the whole contraption, we find it is Type 0! The inner feedback loop has effectively "cancelled" the benefits of the integrator for steady-state error performance. This is a spectacular example of how feedback topology fundamentally shapes a system's character. We can add, remove, or nullify the effect of integrators not by changing the physical components, but simply by changing how we wire them together.

Perhaps the most exciting application of this concept is not in designing systems, but in understanding them. Imagine you are an astronomer pointing a large satellite antenna. You command the antenna to track a target accelerating across the sky (a parabolic input). You observe that the antenna lags behind the target, but this lag eventually settles to a constant, non-zero angle.

What can you deduce from this single observation? Without ever seeing a circuit diagram or a mechanical drawing, you can state with certainty that the equivalent unity feedback system is ​​Type 2​​. A Type 0 or Type 1 system's error would have grown infinitely, and a Type 3 system would have settled to zero error. This is the scientific method in action: from a specific observation, we infer a general, underlying property.

We can push this detective work to astonishing levels. Consider a system whose plant is known to be Type 2. In theory, it should track a ramp input with zero steady-state error. But, in an experiment, we find it has a small, but finite, non-zero error. This is a puzzle. The plant is doing its job, so something else must be interfering. The culprit, once again, is the sensor, $H(s)$. For a Type 2 plant to produce a finite ramp error, the mathematics of the final value theorem demand that the sensor's transfer function must have a very specific form. The equivalent system must be Type 1, which has a finite ramp error. This occurs if the sensor's DC gain is exactly unity ($H(0)=1$), but it has dynamic behavior such that the first derivative of its transfer function at $s=0$ is non-zero ($H'(0) \neq 0$). In physical terms, this means the sensor gives the correct reading in the steady state (for a constant signal) but has a lag or lead characteristic when the signal is changing. From a simple error measurement, we have deduced the subtle dynamic nature of our sensor! This power of inference is crucial for diagnosing and debugging complex systems in the real world. If a system misbehaves, this analysis points a finger at the likely source. And as a consequence of the equivalent system being Type 1, its error when trying to track a parabola will now be infinite.

Ultimately, we want to build things that work, and work well. The equivalent system model gives us the quantitative tools to predict performance and design systems to meet specifications.

Let's design an active suspension for a car. The goal is a smooth ride. We can model the road's profile as a series of inputs to our system. Tracking a parabolic input is like driving through a smooth dip. The system's ability to do this is measured by the "static acceleration error constant," $K_a$. Using our equivalent model, we can derive a formula for $K_a$ that connects it directly to the physical parameters of the controller gain, actuator dynamics, and sensor properties. The resulting expression, $K_a = \frac{K a d}{b d - e K a}$, is not just an abstract formula; it's a design guide. If we want a larger $K_a$ (which means smaller error), the equation tells us exactly which physical knobs to turn.

Or consider again the satellite, now tasked with tracking a moving target at a constant angular velocity (a ramp input). By analyzing the non-unity feedback system, we can predict the exact steady-state pointing error: $e_{ss} = b \cdot \frac{p_{1}p_{2} - K}{K p_{2}}$. This equation is a prediction. But it's also an opportunity. Notice that if we are free to choose the controller gain $K$, we could choose it such that $K = p_1 p_2$. In this case, the steady-state error becomes zero! This is the heart of control engineering: analyzing a system to understand its inherent limitations, and then cleverly designing a controller to overcome them. The transformation to an equivalent unity feedback system is what gives us the clear framework to perform this analysis and achieve such elegant results.

In the end, the concept of an equivalent unity feedback system is far more than a mathematical convenience. It is a profound statement about the nature of systems. It teaches us that no component acts in isolation and that the connections between them are as important as the components themselves. It provides a unified language to describe, predict, and ultimately design the behavior of a vast range of technologies that shape our world. It is a beautiful example of how a simple shift in perspective can turn a complex, confusing picture into one of remarkable clarity and power.