Stability & Steady-State Error: Will It Settle, and Where?

Two questions every controller must answer

Imagine you nudge the steering wheel of a car a few degrees and let go. A good car straightens out smoothly and tracks the road. A badly-tuned one might weave back and forth in ever-wider swings until it spins off — or it might settle, but always drift slightly to the left of where you aimed. Those are exactly the two failure modes of *any* controlled system: it can be unstable (the wiggle grows), and it can have error (it settles in the wrong place). Before you tune a single gain in a later rung, you have to be able to test for both.

These two are independent. A system can be rock-solid stable and *still* park itself a metre from the target forever. Another can be dead-on accurate yet violently unstable. So engineers split the acceptance test in two: stability asks *does the transient die out?* and steady-state accuracy asks *where does the survivor land?* The whole of this rung is the toolkit for answering each — cheaply, before you ever switch on hardware.

BIBO stability and the left-half-plane rule

The clean, engineering-grade definition of stability is BIBO: *Bounded Input, Bounded Output*. If every input that stays within finite limits produces an output that also stays within finite limits, the system is BIBO-stable. Push a stable amplifier with a 1-volt signal and you get a finite output; push an unstable one and the output runs off to the rails no matter how gentle your input. It is the formal version of 'a poke produces a wiggle, not an explosion.'

From rung 3 you already have the geometric test. Write the closed-loop transfer function and find its poles — the roots of the denominator. Each pole at s = σ + jω contributes a term shaped like e^(σt) to the response. If σ is negative the term decays; if σ is positive it grows without bound. So the rule is breathtakingly simple: a system is stable if and only if every pole lies strictly in the left half of the s-plane (σ < 0). One pole sneaks into the right half — even by a hair — and the whole system is unstable.

             jω
              ^
     UNSTABLE  |  STABLE
   (poles run  |  (poles decay)
    off to ∞)  |
        x      |     x      <- left-half pole: e^(σt), σ<0, dies out
               |    /
   ────────────+──────────────> σ
         x     |
         |     |   poles ON the jω axis (σ=0):
   right-half  |   marginally stable -> sustained oscillation,
   pole grows  |   neither grows nor decays

The pole map of stability. Left half = decaying transients = stable. Right half = growing transients = unstable. On the jω axis = endless ringing (marginal).

Routh–Hurwitz: stability without finding the roots

The left-half-plane rule is perfect — except for one nuisance. Finding the poles means factoring the denominator polynomial, and for a third-order or higher system that is a genuine slog (and impossible by hand once a tunable gain K is sitting inside the coefficients). In 1876 Edward Routh found a way around it, refined by Adolf Hurwitz: you can decide whether *all* roots have negative real parts by looking only at the coefficients — never solving for a single root.

The recipe has two parts. Necessary first check: for any stable polynomial, every coefficient must be present and all the same sign — a missing or sign-flipped coefficient is an instant 'unstable.' The full test: build the Routh array, a little table cross-multiplied down from the coefficients. The system is stable if and only if every entry in the first column has the same sign. Each sign change in that first column counts exactly how many poles sit in the right half-plane.

Let's run a real third-order example. Suppose a feedback loop gives the characteristic polynomial s³ + 6s² + 11s + 6. Every coefficient is present and positive, so it survives the necessary check — but that alone does not prove stability for third order and up. Build the array:

Characteristic polynomial:  s^3 + 6 s^2 + 11 s + 6

   Routh array            first column
   ─────────────────────  ───────────
   s^3 |   1      11          1
   s^2 |   6       6          6
   s^1 |   b1      0          b1
   s^0 |   c1                 c1

   b1 = (6*11 - 1*6) / 6  = (66 - 6)/6  = 60/6 = 10
   c1 = (b1*6 - 6*0) / b1 = (10*6)/10   = 6

   First column:  1, 6, 10, 6   -> all POSITIVE, no sign changes
   => 0 right-half-plane poles  => STABLE

   (Sanity check: s^3+6s^2+11s+6 = (s+1)(s+2)(s+3),
    roots at -1, -2, -3 -- all in the left half-plane. ✓)

A worked Routh–Hurwitz test. The first column stays one sign throughout, so all three poles are in the left half-plane — confirmed by the factored roots −1, −2, −3.

The real power shows when a gain is symbolic. If a controller gain K appears inside the coefficients, the first-column entries become expressions in K. Demanding that they all stay positive turns into a set of inequalities — and those inequalities hand you the exact range of K for which the loop stays stable. That single move, finding the critical gain at which a pole crosses onto the jω axis, is one of the most-used calculations in all of control design.

Steady-state error and the final-value theorem

Now assume the system passed the stability test — the transient dies, and something is left over. Does that survivor sit *on* the target or short of it? The gap between where you commanded the output to go and where it actually settles is the [[ee-steady-state-error|steady-state error]], usually written e_ss. A thermostat that asks for 21 °C and holds 20.4 °C has a steady-state error of 0.6 °C — annoying, persistent, and entirely predictable in advance.

The tool that predicts it without simulating a single second is the final-value theorem: the long-run value of a signal equals lim (s→0) of s·E(s), where E(s) is the Laplace transform of the error. Multiply the error transform by s, slide s down to zero, and out pops the resting error. There is one ironclad rule for using it: the system must already be stable. Apply the theorem to an unstable system and it cheerfully returns a finite, completely fictitious number.

Unity-feedback loop, open-loop transfer function G(s):

        R(s) --->(+)---->[ G(s) ]----+----> C(s)
                  ^-                 |
                  |__________________|

   Error:   E(s) = R(s) / (1 + G(s))
   Final-value theorem:  e_ss = lim (s->0) s * R(s) / (1 + G(s))

   The three classic test inputs (R(s)) :
     step      r(t)=1        R(s) = 1/s      "can it reach a level?"
     ramp      r(t)=t        R(s) = 1/s^2    "can it track a slope?"
     parabola  r(t)=t^2/2    R(s) = 1/s^3    "can it track acceleration?"

Error of a unity-feedback loop and the three standard reference inputs used to probe it — a step, a ramp, and a parabola.

Why those three inputs? Because they form a ladder of difficulty. A [[ee-step-response|step]] asks the system to reach and hold a fixed level. A ramp asks it to keep pace with a target moving at constant speed — like a radar antenna following a plane crossing the sky. A parabola asks it to keep up with a constantly accelerating target. Each is harder than the last, and a system that aces the step may fall hopelessly behind the ramp.

System type: counting the integrators

Here is the elegant part. Whether a loop tracks a step, a ramp, or a parabola with zero error comes down to one integer: the system type, defined as the number of pure integrators (factors of 1/s, i.e. poles at the origin) in the open-loop transfer function G(s). An integrator is a memory that keeps accumulating error — and that accumulation is exactly what wipes the error out. Count the 1/s factors and you can read off the steady-state error from a tiny table, no calculus required.

  System type = number of 1/s factors (origin poles) in open-loop G(s)

  Error constants:  Kp = lim G(s)   Kv = lim s G(s)   Ka = lim s^2 G(s)
                       s->0            s->0              s->0

  ┌────────┬──────────────┬──────────────┬──────────────┐
  │  Type  │  STEP error  │  RAMP error  │ PARABOLA err │
  ├────────┼──────────────┼──────────────┼──────────────┤
  │   0    │  1/(1+Kp)    │      ∞        │      ∞        │  finite step err
  │   1    │     0        │    1/Kv      │      ∞        │  tracks step!
  │   2    │     0        │      0        │    1/Ka      │  tracks ramp too
  └────────┴──────────────┴──────────────┴──────────────┘

  Pattern: each added integrator kills the error to one harder input,
  and leaves a finite error on the NEXT one up the ladder.

The system-type table. Each integrator you add zeros the error on one input and reduces the next-harder input from infinite to a finite, computable error.

Read the table as a story. A Type 0 system (no integrator) has a finite but non-zero step error — like a plain proportional thermostat that always settles a little short. A Type 1 system has one integrator, so its step error is *exactly zero*, but it still lags a moving (ramp) target by a finite amount. A Type 2 system tracks ramps perfectly and leaves only a finite error on accelerating targets. Notice the pattern: each integrator buys you perfection on one input and a finite error on the next-harder one.

Putting it together: the acceptance test

From now on, every controller you design in a later rung will be graded against the same two-part exam, and you already own the grading rubric. Stability first, accuracy second — in that order, because accuracy is meaningless on something that won't settle.

Write the closed-loop characteristic polynomial (the denominator of the closed-loop transfer function, i.e. 1 + G(s)H(s) set to zero).
Run the necessary check: all coefficients present, all the same sign. Fail here and you're done — it's unstable.
Build the Routh array and confirm the first column never changes sign. If a gain K is symbolic, solve the inequalities for the stable range of K.
Only now, with stability confirmed, count the integrators in the open-loop G(s) to get the system type.
Read the type table (or apply the final-value theorem) to predict the step / ramp / parabola error. Decide if it meets spec.
If the error is too big, add integral action to raise the type — then loop back to step 1, because you've just changed the poles and must re-check stability.

That final loop-back is the whole craft in miniature. You raise the type to kill error, which nudges the poles rightward and threatens stability, which sends you back to Routh–Hurwitz. Stability and accuracy are not two separate chores — they are two ends of the same lever, and the feedback designer's job is to find the spot where both stay in bounds. Later rungs — root locus, Bode and Nyquist methods — are all just richer ways to see and tune this one balance.