FOPDT Identification from Step Tests: Reading K, τ and L

Every classical PID table — Ziegler–Nichols, Cohen–Coon, IMC, SIMC, AMIGO — assumes you already know three numbers: the steady-state gain K, the apparent time constant τ, and the apparent dead time L. Those numbers do not come from the controller faceplate. They come from an open-loop step, historically called a reaction curve or bump test. A bad bump produces a confident-looking FOPDT model that is wrong in the one place the formulas are most sensitive, usually L or K, and then a “tuning problem” that was an identification problem all along.

This article is the upstream job: how to design the bump, when the process has actually reached steady state, how to read K from ΔPV/ΔMV, how the tangent construction compares with the 28 % / 63 % points and the Sundaresan–Krishnaswamy two-point formulas, how to tell integrating behaviour from self-regulating, what to do with noisy CSV data, and how to type the result into PID Solver 360’s plant fields. The worked example is a steam-heated tank. The same workflow feeds the auto tuner and the closed-loop simulator.

You do not need a first-principles digital twin. You need a model whose step response has the same final change, the same delay, and the same dominant lag as the plant the PID will face. FOPDT is that model for most self-regulating process loops.

Why FOPDT is the identification target

A first-order-plus-dead-time plant is

G(s) = K · e^(−L s) / (τ s + 1)

In the time domain, after a step Δu at t = 0,

y(t) = y0                             for t ≤ L
y(t) = y0 + K Δu (1 − e^(−(t−L)/τ))   for t > L

That S-curve is what a heater, a well-mixed tank, many exchangers, and a surprising number of quality loops look like once you ignore the first wiggle. Higher-order lags get lumped into a larger L and a single τ. The lumped model is wrong as physics and right as an input to a PID rule, provided you identified it at the operating point you will control.

The dimensionless ratio R = L/τ decides which rule later makes sense. You cannot know R until the bump is finished. Engineers who skip identification and “just raise Kp” are choosing R unconsciously, usually as “this feels laggy”, which is how delay-dominant analyser loops get jacket-vessel gains.

PID Solver 360 also offers first-order without delay, second-order, and integrating plants. Use those when the bump shows them. Do not upgrade the model structure to look sophisticated if the S-curve is already FOPDT. Extra poles you cannot see are extra parameters you will fit to noise.

Designing the bump

Controller in manual. That is not negotiable. A closed-loop “step” in setpoint identifies the complementary sensitivity, not the plant. You would then need to deconvolve the PID, which is a different experiment and a good way to contaminate K.

Wait for a genuine pre-bump steady state. PV should be flat compared with the move you are about to cause. A tank that is still recovering from the last feed change will give you a ramp plus a step, and the apparent K will be fiction. Record at least a minute of pre-data on a slow temperature loop, more if the historian is noisy; you will average that window for y0.

Step the manipulated variable, do not pulse it and do not ramp it over a minute. The FOPDT formulas assume a step in u. A ramp smears L. A pulse never shows K. Size the step so that ΔPV is several times the noise standard deviation and well inside the linear region:

• Too small: K is noise over noise. A 1 °C change on a transmitter that wanders 0.4 °C is not a gain measurement.
• Too large: the valve hits a stop, flashing starts, a relief lifts, or you leave the linear installed characteristic. You have identified a different plant.
• Typical start on a 0–100 % valve: 5–10 % if that is safe; 2–4 % on a sensitive pressure loop; more on a sluggish heater if operations will tolerate it.

Bump around the normal throughput. Equal-percentage valves and temperature-dependent heat transfer make K a function of MV. A model taken at 20 % fire will not serve a PID that lives at 70 % fire. If the unit must run at two very different rates, take two bumps and expect two models.

Log t, u (MV) and y (PV) at a sample interval small compared with L. If you think L is 15 s, a 10 s compressed historian average is not a dataset. Disable exception reporting and swinging-door compression for the test if you can, or export the raw controller scan. Note engineering units on the loop sheet at the moment of the test, not later from memory.

Tell operations what will happen to PV. A bump that surprises a board operator gets put back to auto halfway through, which ruins the tail you need for K.

Waiting for steady state

The tail of the test is the gain measurement. For a true first-order lag, 63 % of the change happens in one τ after the delay, 95 % in about 3τ, 99 % in about 5τ. A practical hold time is

t_hold ≳ L + 5 τ

You do not know τ before the test, so use a conservative prior. If similar heaters on the site take 15 minutes to settle, do not stop at six. Cutting the test when the trend “looks flat” on a zoomed-out historian is the standard way to underestimate K and τ together: the PV still had 10 % left to go, you treated that as the final value, and every later time constant shrinks.

A check while you sit there: if PV is still moving in the same direction at a rate that would accumulate another 10 % of the observed change in one more τ-guess, you are not done. Integrating processes never pass this check; they are not FOPDT. Noisy processes pass it only in the average of a window, not on a single sample.

After you return MV to the original value, you can optionally record the down step. A second K that disagrees with the up step by more than 15–20 % is telling you about hysteresis, a direction-dependent heat loss, or a valve that did not go where you wrote. Do not average two incompatible gains and call it science. Pick the direction that matches how the PID will move from the normal point, or fix the valve.

Reading K from ΔPV / ΔMV

K = (y∞ − y0) / (u_after − u_before)

y0 is the mean PV before the step, not the last sample. y∞ is the mean PV over a window at the end, not the final spike. u_after − u_before is the actual MV change, which is not always what you typed if the output is limited or the valve positioner lagged and you used a measured position.

Units must match the controller. If the DCS PID uses PV in engineering units and OP in percent, K is in PV-units per percent. If both are 0–100 % of span, K is dimensionless. Mixing those is the most common factor-of-span error in this entire workflow. Write the units next to K on the sheet: 1.00 °C/%, not 1.00.

K can be negative. Cooling-water valves, some pressure let-downs, and reverse-acting installed characteristics produce ΔPV opposite ΔMV. The identification should keep the sign. PID Solver 360 uses the sign of K to set controller action. Do not abs() the gain and then wonder why the tuner looks odd.

If Δu is essentially zero, you did not bump. If ΔPV is essentially zero, the step was too small, the sensor is dead, or you are sitting on a constraint. Do not proceed to τ and L. There is no S-curve.

The tangent method

Ziegler and Nichols drew a tangent at the inflection point of the S-curve. The intercept of that tangent with the initial-PV line is L. The intercept with the final-PV line minus L is τ. Equivalently, the maximum slope s_max of the reaction curve satisfies

τ = K Δu / s_max

and L is the time where the tangent through the steepest point crosses y0.

On a clean, densely sampled laboratory curve this is defensible. On an industrial trend it is the method most sensitive to noise, because the inflection is where you differentiate the PV. Two engineers will draw two tangents. The one who draws a steep tangent gets a small τ and a large L, which then produces a timid Kp in some rules and a wild Kp in rules that divide by L after mixing up the pair. I still teach the tangent so people can read old papers. I do not use it as the primary fit when a two-point method is available.

If you must use a tangent on a noisy curve, smooth first with a filter much faster than τ (a moving average of a few samples, not a one-minute average that eats L), then draw one tangent and stop arguing about the second decimal on L.

The 28 % and 63 % method

A first-order lag, once it starts after L, reaches 28.3 % of its final change at t = L + 0.333 τ and 63.2 % at t = L + τ (because 1 − e^(−1) ≈ 0.632). Those two times, measured from the MV step, are

t28 = L + (1/3) τ
t63 = L + τ

which rearrange to the working formulas

τ = 1.5 (t63 − t28)
L = t63 − τ

or equivalently L = 1.5 t28 − 0.5 t63. The 63 % point is the one-time-constant mark everyone remembers. The 28 % point exists to separate delay from lag. Using only 63 % and guessing L from “when it first moved” is how L gets set to the first noise excursion.

Procedure:

• Compute Δy = y∞ − y0 and the two levels y0 + 0.283 Δy and y0 + 0.632 Δy.
• Interpolate the crossing times on the sampled record; do not pick the nearest second by eye if you can avoid it.
• Apply the formulas. If L comes out negative, the response is faster than a delayed first-order at this sampling; set L = 0 only as a first-order model, and do not feed L = 0 into Ziegler–Nichols.

This method still needs a settled y∞. If you cut the test early, both levels are wrong and t63 is early.

Two-point method (Sundaresan–Krishnaswamy)

Sundaresan and Krishnaswamy used the same 28.3 % and 63.2 % crossings with a slightly different emphasis that PID Solver 360 implements as the first fit on a bump CSV:

τ = 1.5 (t63 − t28)
L = 1.5 t28 − 0.5 t63

That is the same algebra as above. The identification code then optionally refines L on a small grid, keeping K from the step and recomputing τ from the 63 % constraint τ ≈ t63 − L, picking the pair that reduces RMSE against the FOPDT step. That refine step is why a hand calculation and the app can differ by a second or two on L without anyone being wrong. If they differ by a factor of two, your y0/y∞ windows or the step time are wrong.

Other two-point pairs exist (20 % and 60 %, 35 % and 85 %). They change the weighting of the early curve versus the tail. Stick to 28/63 unless you have a documented reason; mixing pairs in a team is how loop sheets become incomparable.

A fit is not finished until you overlay the FOPDT step on the measured PV. RMSE that looks small in engineering units can still hide a systematic late tail, which is usually a second lag you lumped badly. If the overlay misses the delay and the tail in opposite directions, try a second-order model rather than torturing L.

Worked example: steam-heated tank

A coil-in-tank temperature loop is put in manual at 42 % steam valve. PV sits at 78.4 °C. At t = 0 the valve is stepped to 50 % and held. After a long wait PV sits at 86.4 °C.

Δu = 50 − 42 = 8 %
Δy = 86.4 − 78.4 = 8.0 °C
K  = 8.0 / 8 = 1.00 °C/%

Interpolated crossings from the step instant:

28.3 % of 8.0 °C = 2.26 °C  →  PV = 80.66 °C  at t28 = 38 s
63.2 % of 8.0 °C = 5.06 °C  →  PV = 83.46 °C  at t63 = 72 s

Two-point FOPDT:

τ = 1.5 × (72 − 38) = 1.5 × 34 = 51 s
L = 1.5 × 38 − 0.5 × 72 = 57 − 36 = 21 s
R = 21 / 51 ≈ 0.41

This is a mixed loop, not strongly lag-dominant and not dead-time dominant. Ziegler–Nichols, Cohen–Coon and IMC / Lambda are all in play; none is forbidden by R alone. A sanity overlay: the model should still be near y0 until 21 s, then rise through 80.7 °C near 38 s and 83.5 °C near 72 s, and finish near 86.4 °C by about 21 + 5×51 ≈ 280 s. If your recorded test was only two minutes long, you did not have y∞ and this K is a lower bound.

Open-loop Ziegler–Nichols PID on these numbers would be Kp = 1.2 × 51 / (1.00 × 21) = 2.91 %/°C, Ti = 42 s, Td = 10.5 s. IMC PID with λ = 2L = 42 s would be far calmer. Identification does not pick the rule; it makes the comparison possible in the tuner.

Integrating versus self-regulating

A self-regulating process approaches a new steady PV in open loop. An integrating process — liquid level with a mismatch of in and out, some gas headers, inventory on a conveyor — ramps at a slope set by K_i Δu. The FOPDT K is infinite; the formulas in this article do not apply.

Visual test: after the delay, is the PV’s rate of change falling toward zero (self-regulating) or holding a roughly constant slope (integrating)? A slow tank can look integrating for the first two minutes and still be self-regulating at twenty. Waiting is the diagnostic.

If you force FOPDT on a ramp, you will pick an arbitrary y∞ at the moment you got bored, compute a huge τ and a moderate K, and then a PID that is wrong in every term. Use an integrating-plus-delay model K_i e^(−Ls)/s and the matching SIMC or Lambda rules. PID Solver 360 has an integrating plant type; use it instead of inventing a fake K.

A process can also be runaway (open-loop unstable), for example some exothermic reactors. The bump will accelerate, not settle. Stop the test, return to a safe state, and do not fit FOPDT. That is a different identification problem and a different controller structure.

Noisy data

Noise does not bias K if you average long enough at both ends. It does bias crossing times if you take the first sample that touches 28.3 %. Interpolate on a lightly smoothed copy of PV, or average multiple crossings if the signal chatters around the level. Do not apply a 30-second filter before measuring L on a loop whose delay is 20 seconds; you will manufacture delay.

Outliers (a frozen transmitter, a one-sample spike) should be removed before y∞ is computed. A single spike in the tail window can shift K more than the whole physical bump.

If the noise band is comparable to ΔPV, enlarge the bump or fix the measurement. No identification method, including least squares, invents a K that is not in the data. They can only distribute the noise into τ and L.

Derivative-quality PV is not required for FOPDT identification. You are not fitting a second derivative. You are fitting a delay and a lag. Resist the urge to high-pass the signal.

CSV import mindset

PID Solver 360 expects a bump table of t,u,y or t,y (unit step in u assumed). That matches how you should think about the file, even if you first fit by hand.

• Time should be monotonic and in consistent units (seconds recommended). Starting at t = 0 at the step is convenient; if the step is later, the fit still works if u jumps in the file.
• Comment lines and obvious headers should not be numeric junk in the first column.
• Do not include the closed-loop recovery after you put the controller back to auto; that is a different u(t).
• Do not splice two bumps into one file without a clear single step. The detector looks for the largest jump in u.
• Check the parsed Δu and Δy against the loop sheet before you trust τ and L.

The point of the CSV is reproducibility. A screenshot of a trend is not an identification. Six months later you want to refit with a different method. Keep the file with the loop sheet.

When you paste data, look at the overlay the tool draws. If measured PV and model PV disagree in the delay region, your step instant is wrong (common when t is historian time and the MV change was compressed). If they disagree in the tail, K or the hold time is wrong. If they disagree in the middle with good K and L, τ or the structure is wrong.

Common mistakes

Too small a bump. Operations wanted “no one to notice”. Nobody noticed, including the identification. Repeat with a step that clears the noise by a factor of five or more.

Valve in saturation. MV at 100 % or a positioner at the stop. Δu you wrote is not Δu the plant saw. K is too small, τ looks long, and the PID you compute will then saturate in the same direction on the first disturbance.

Nonlinear gain. One bump at one end of the range. The PID is linear. Either stay near that point, schedule, or accept that Lambda with a conservative λ is the remaining degree of freedom. A second bump at a second MV is cheaper than a year of complaints.

Returning to auto too early. The tail is truncated, K is low, IMC Kp comes out high, and you blame the tuner.

Using SP instead of PV units, or OP instead of valve position, inconsistently. Pick the signals the PID actually writes and reads.

Calling the first wiggle `L`. Transmitter bounce is not dead time. L is how long the S-curve is delayed, from the two-point formulas or a careful overlay, not from the first pixel that moved.

Fitting FOPDT to a level ramp. Covered above; it still happens weekly.

Changing two things. A bump during a feed-rate change identifies a combination of inputs. Hold the other handles still.

Ignoring controller form later. Identification is in plant units. Tuning must use the same units. The model is not at fault if someone types K = 1 because “normalised is simpler” and then downloads Kp into a °C/% block.

Converting to PID Solver 360 plant fields

In the solver, a FOPDT plant is the triple K, tau, L (and the sign of K for action). For the steam tank:

K    = 1.00
tau  = 51
L    = 21

with time in seconds. If you identified in minutes, convert; mixing τ = 0.85 min with L = 21 s is a silent disaster. The docs describe the plant types and the controller form the simulator uses. Match them.

After the fields are filled, do not jump straight to a live download. Run the tuner for at least SIMC and IMC, and one classical rule as a reference. Simulate a setpoint step and a load step. If the FOPDT overlay on the bump was mediocre, the closed-loop plot is a lower bound on surprise, not a promise.

If the bump was second-order-looking (an S-curve with a long toe and a different curvature), use a second-order plant and let the solver apply the half-rule when a FOPDT rule needs it, or stay in simulation on the second-order model. Forcing the tank example into L = 0, τ = 72 s because “63 % is 72 seconds” throws away 21 s of delay the PID will have to live with.

Identification troubleshooting checklist

If K disagrees with a steady-state heat balance or a vendor gain by a factor of two, believe the bump only after you have checked spans, wet legs, and whether the valve moved. Physics is a prior; it is not always the installed truth.

If L is larger than you can explain with pipe, well and analyser, look at compression, a slow wireless publish time, and a filter already in the PV path. Filters are extra L and extra τ. Either include them in the model (the PID will see them) or bypass the filter for the test and put it back consistently.

If τ changes a lot when you move the 63 % level by 5 % of Δy, the tail is not settled or the process is not first-order. Hold longer or change structure.

If two bumps a day apart disagree, the plant is time-varying (fouling, composition, inventory). Tune for the condition you must live with, and plan to re-identify. A single immortal FOPDT model is a wish.

FOPDT identification is not a prelude you rush so you can get to the interesting formulas. It is the interesting part: it is the only measurement of the plant the PID will ever see, short of a relay test. Spend the wait time. Average the tail. Overlay the model. Then, and only then, let PID Solver 360 turn K, tau and L into a controller you are willing to download.