IAE, ISE and ITAE: what PID optimisation actually minimises
Definitions of IAE, ISE, ITAE and ITSE, trapezoidal integration, why ISE is aggressive, and how Nelder–Mead searches Kp Ki Kd without lying.
A PID has three knobs and a plant that will not sit still. Classical rules pick a point in that three-dimensional space from a model and a folklore of what “good” looks like. Numerical optimisation picks a point by driving a scalar cost to a minimum. The scalar is the whole argument. IAE, ISE, ITAE and ITSE are four different opinions about which errors matter, and an optimiser will faithfully become the opinion you typed. This article defines those integrals, shows how to compute them on sampled data without cheating, explains why ISE looks fast and violent while ITAE looks later and calmer, and then treats Nelder–Mead search of Kp, Ki and Kd as an engineering tool with constraints, local minima, and an obligation to start from something like SIMC — plus the ways the whole procedure lies when the model is wrong.
PID Solver 360 implements the integrals on the simulated error and exposes them as optimiser objectives. Pair this article with closed-loop simulation metrics for rise time and overshoot, how to reduce overshoot for the time-domain knobs, and how to tune a PID controller for the model-first workflow. Use the optimiser after the auto tuner, not instead of it.
Why a scalar cost exists at all
Hand-tuning is multi-objective whether you admit it or not: you are watching overshoot, settle, valve travel, noise, and a load that arrived at 2 a.m. A numerical method cannot watch. It can only compare two numbers J(θ1) and J(θ2) for a parameter vector θ = (Kp, Ki, Kd) or (Kp, Ti, Td). The integral criteria exist because they collapse a whole trajectory e(t) into one number that is smooth enough to search and interpretable enough to defend.
They are not laws of nature. Nothing in the plant “wants” ITAE to be small. You want something — a quality peak not exceeded, a compressor not surged, a temperature back inside a band before the next batch step — and you choose a J that correlates with that want. When it does not correlate, optimisation is a very confident way to get the wrong loop.
A second reason for integrals is fairness. Peak overshoot ignores a long ugly tail. Rise time ignores everything after 90 %. IAE counts the whole story. That fairness is also a trap: the story’s length T is part of the definition. Change T and you change the ranking of controllers. Optimise on 20 s of a 3-minute temperature loop and you will crown a violent Kp that looks brilliant before the lag has finished answering.
IAE: every unit of error costs the same
Integral of absolute error is
IAE = ∫_0^T |e(t)| dtA 10-unit error for 1 s costs 10. A 1-unit error for 10 s costs 10. Sign does not matter; a positive lobe and a negative lobe cannot cancel. That last property is essential. The raw integral of e is driven to zero by any PI controller that reaches the setpoint with equal area above and below, even if the PV is still swinging. IAE stays large until the swinging stops.
IAE is the default general-purpose cost for process PID. It treats a brief spike and a long hang as interchangeable if the areas match, which is often closer to “how much off-spec mass left the tank” than a squared criterion is. It is less obsessed with the first instant than ISE, and less obsessed with the far tail than ITAE, provided T is not huge.
What IAE punishes, in tuning terms: sluggish Kp (the error sits there), sluggish Ki (the tail sits there), and oscillation (area keeps accumulating every half-cycle). What it does not punish enough: a sharp overshoot of short duration, if you care about a hard PV peak more than about mass. A 30 % spike that lasts 2 s on a 100 s record can be a minority of IAE and a majority of the quality incident.
Units of IAE are (error units) × time. A 5 °C step on a 300 s record produces a different number than a 2 °C step on 100 s. Compare IAE only at equal T, equal step size, and equal definition of e (engineering units versus percent of span). Normalising,
IAE_n = IAE / (|Δ| T)gives a dimensionless mean-absolute-error that you can compare across experiments. PID Solver 360 reports the raw integral on the simulated trajectory; when you quote numbers in a report, state T and Δ.
ISE: large errors are expensive, small ones are cheap
Integral of squared error is
ISE = ∫_0^T e(t)² dtA 10-unit error for 1 s costs 100. A 1-unit error for 10 s costs 10. The first instant after a step, when |e| = |Δ|, dominates. The optimiser therefore spends actuator authority immediately: high Kp, often high Ki, derivative if it shaves the initial decay. Overshoot is a secondary cost because once |e| has dropped, squaring makes the tail cheap.
ISE is the right opinion when a large excursion is the incident — a pressure spike toward a relief valve, a level toward a trip, a current toward a drive limit. It is the wrong opinion when the spec is “do not go past SP” or “do not ring”, which is most quality temperature and composition loops. If you minimise ISE and then reject the result for overshoot, you asked ISE a question it does not answer.
ISE also interacts badly with noise and with coarse sampling. A one-sample spike of size E costs E² Ts. Unfiltered D that twitches OP will twitch PV a little and donate a surprising amount of ISE. An ISE-optimal Kd on a noise-free model is often unusable on the plant. Put noise in the simulation or cap Kd.
Units are (error units)² × time. Normalise by Δ² T if you must compare steps. Because of the square, a loop on a 0–100 % PV and the same loop on a 0–500 °C PV are not comparable until you scale e.
ITAE: late error is the enemy
Integral of time-weighted absolute error is
ITAE = ∫_0^T t |e(t)| dtA 10-unit error at t = 1 s costs 10. The same 10-unit error at t = 50 s costs 500. Early mistakes are cheap; lingering mistakes are not. The resulting tunings tend to accept a slower rise and a smaller overshoot in exchange for a tail that dies and stays dead. That is why ITAE has a reputation for “nice” PID loops, and why it is a better default than ISE for most process work.
ITAE’s sensitivity to T is stronger than IAE’s, because leftover SSE produces a cost that grows like T² / 2:
if e(t) → e_ss ≠ 0, ITAE ~ |e_ss| T² / 2A PI loop that has not quite finished integrating, or a P-only loop with offset, will have ITAE dominated by the end of the record. Extend T and the ranking of controllers can reverse. Practical rules: run until the 2 % band has been held for a while, confirm SSE is numerically negligible, and only then compare ITAE. If you must compare unfinished runs, you are not comparing controllers; you are comparing how much offset each one still has at an arbitrary cutoff.
ITAE punishes hunting that ISE might forgive, because each late wiggle is multiplied by a large t. It also punishes a timid Ki that leaves a long exponential crawl, even if overshoot was zero. That is the settle-versus-overshoot tension written as an integral. Combine ITAE with an overshoot constraint if the spec cares about both; do not expect ITAE alone to respect a hard peak limit.
ITSE and other cousins
Integral of time-weighted squared error is
ITSE = ∫_0^T t e(t)² dtIt is ISE’s aggression with ITAE’s impatience about the tail. In practice it is less popular than ITAE: the square still overweights the first peak, and the t-weight still demands a finished record. If you already know you want ISE’s philosophy, ISE is clearer. If you want a calm tail, ITAE is clearer. Mention ITSE so that a paper or a DCS option does not surprise you; do not make it the default.
Weighted sums appear once the spec is mixed:
J = w1 IAE + w2 max(0, OS − OS_max)² + w3 (saturation fraction)Those weights are the real tuning. An optimiser will ride the Pareto front until it hits the term you made expensive. Document w_i. A champion J that nobody can explain is not a design.
Integral of squared input or of Δu is sometimes added to punish valve travel. On a sticky valve that is a better proxy for maintenance than ISE of error. PID Solver 360’s core objectives remain the error integrals; if valve travel is the true cost, watch OP in the simulator and cap Kd rather than pretending ITAE saw the packing.
Trapezoidal integration: the discrete integral must match the samples
The controller is sampled. The cost must be sampled. Rectangle (right Riemann) sums are
IAE ≈ Σ |e_k| TsThey are biased if e is systematically falling across the interval. The trapezoidal rule,
IAE ≈ Σ (|e_k| + |e_{k−1}|) Ts / 2and similarly for e² and t |e|, is the natural discrete analogue of the continuous integral at second-order accuracy. PID Solver 360 uses trapezoidal accumulation on the simulated error. If you reimplement ITAE in a spreadsheet with a right-rectangle sum, your numbers will not match, especially with a coarse Ts.
Two implementation details change ITAE more than the choice of Euler versus trapezoid.
Time stamp. Use t at the sample, or the midpoint of the interval, consistently. Mixing t_k with a rectangle of width Ts is a first-order error that grows with T.
Reset of e. If the record includes a long pre-step where e = 0, ITAE is unaffected (t |0| = 0) but T in a normalised cost is wrong. Start the integral at the step instant, or start the clock there. If a second disturbance arrives at t = 80 s, ITAE from 0 still weights that error by ~80; that may be what you want (late events are expensive) or not (you wanted two separate experiments).
For ISE, trapezoidal integration of e² is not the same as squaring a trapezoidal integral of e. Never square IAE and call it ISE. Never compare ISE across different Ts without converging Ts first: a coarse step that misses a peak underestimates ISE, and an Euler-unstable plant stepper can invent peaks. The plant integrator and the cost integrator are different objects; RK4 on the plant plus trapezoid on e is the consistent pair.
Why ISE is aggressive and ITAE prefers later calm
Consider a one-parameter cartoon: a second-order closed loop whose damping ζ you can set, with ωn fixed. Low ζ: fast rise, large overshoot, long ring. High ζ: slow rise, little overshoot, no ring. ISE, dominated by the initial |e| ≈ |Δ|, prefers the low-ζ move that collapses e quickly, and treats the ring as a cheap remainder. ITAE, dominated by t times the ring, prefers high ζ. IAE sits in the middle. That cartoon is why textbooks say “ITAE tunings are less oscillatory than ISE tunings”. It survives on FOPDT-plus-PID, with delay adding a floor to how much initial e you can possibly kill: before t = L, e has not seen the move, and ISE still charges |Δ|² L no matter what Kp you pick. Aggressive ISE then over-spends after the delay, which is exactly Ziegler–Nichols-like overshoot.
A numerical sketch on a FOPDT plant with K = 1, τ = 10, L = 2, unit step, PI only, T = 80, Ts small. A SIMC-like pair (Kp ≈ 2.5, Ti ≈ 8) might post OS ≈ 10 %, IAE ≈ 6.8, ISE ≈ 4.1, ITAE ≈ 55. An ISE-optimal search from that start might move to Kp ≈ 3.4, Ti ≈ 5.5, OS ≈ 28 %, IAE ≈ 6.1, ISE ≈ 3.6, ITAE ≈ 70. ISE improved; the loop got uglier. An ITAE-optimal search might move to Kp ≈ 2.1, Ti ≈ 9.5, OS ≈ 5 %, IAE ≈ 7.2, ISE ≈ 4.5, ITAE ≈ 48. ITAE improved by killing the tail and the overshoot together, at the price of a slower first move. Those numbers are illustrative of direction, not a table to load; run your own model in the optimiser. The qualitative ranking is stable: ISE buys Kp, ITAE buys patience, IAE negotiates.
When the duty is disturbance rejection, repeat the comparison on a load step, not only on SP. ISE on a load step still wants a large early correction, which is often exactly the duty. ITAE on a load step still wants the error gone later, which is also the duty. The split is milder than on SP steps, which is another reason 2-DoF (setpoint weighting) is a better way to calm SP than switching the optimiser to ITAE and hoping the load path survives. Optimise ITAE on a load experiment if load is the job; use b to fix SP overshoot, as in the overshoot article.
Nelder–Mead and numerical search of Kp, Ki, Kd
Nelder–Mead is a derivative-free simplex search. In three parameters it keeps four points in (Kp, Ki, Kd) space, evaluates J at each, and reflects, expands, contracts or shrinks the simplex toward better J. It does not need gradients of ITAE with respect to Kp, which is fortunate because those gradients are noisy once you have delay, saturation and a sampled PID.
It is not magic. It is a local downhill walker. Properties that matter for PID:
It respects nothing you do not encode. If Kd = 40 reduces ITAE on a noise-free model, it will go there. Bound the gains:
Kp ∈ [Kp_min, Kp_max]
Ki ∈ [0, Ki_max]
Kd ∈ [0, Kd_max]and reject or penalise evaluations that violate OP limits you care about, OS_max, or minimum gain and phase margin. A hard reject (J = huge) is simple and makes the simplex collapse away from illegal points if at least one vertex is legal. A smooth penalty is easier to search but easier to cheat with a small w.
It needs a scale. Kp = 2.5, Ki = 0.3, Kd = 8 live on different axes. Simplex methods behave better if you search in log-gains or in (Kp, Ti, Td) with Ti and Td in seconds. Searching Ki near zero is how you accidentally build a P controller that looks fine on a short T.
It will find a wall. Saturation makes J almost constant in directions that only increase an already-clamped OP. The simplex then flattens and reports a “minimum” that is really “any Kp above 6 looks the same”. Inspect OP. If the champion saturates for half the run, you have optimised a bang-bang heater, not a PID.
PID Solver 360’s optimiser is this kind of search: a scalar J from the simulated trajectory, starting from the gains you give it. Give it SIMC. Give it bounds. Give it a T that includes settle. Then read the Bode margins of the champion, because ITAE does not see robustness.
Local minima and why the start should be SIMC
J(Kp, Ki, Kd) on a delayed, saturating loop is not a bowl. Delay makes the gradient of overshoot with respect to Kp change sign near the ultimate gain: below Ku, more Kp reduces IAE; above Ku, more Kp explodes IAE. That ridge is a local structure. Starts from a timid P-only point may crawl toward a slow PI minimum. Starts from Ziegler–Nichols may sit in a high-overshoot basin that is a local ISE minimum and a terrible plant. Starts from SIMC or AMIGO sit in the basin that robust rules already found, and Nelder–Mead then shaves a few percent of ITAE without crossing Ku.
Multiple controller structures are multiple basins. PI (Kd = 0) and PID can both be locally optimal. If the measurement is noisy, the PID basin’s ITAE on a clean model is a lie. Constraining Kd = 0, or running both searches, is more honest than a 3-D search that always “discovers” D.
A practical protocol:
- Identify K, τ, L. Confirm the open-loop step.
- Compute SIMC/IMC/AMIGO in the auto tuner.
- Simulate. If OS and margins are already acceptable, stop. Optimisation is optional polish.
- If not, start Nelder–Mead from the best classical set, with bounds around it (for example Kp within a factor of two, Ti within a factor of two, Td from 0 to the classical Td).
- Repeat from a second start (AMIGO if you started at SIMC) and keep the better legal champion.
- Perturb K and L by 20–30 % and re-evaluate J and OS without re-optimising. If the champion dies, it was a model-fit, not a loop.
If step 6 fails, enlarge λ rather than tightening the optimiser. Robustness is a different objective than ITAE on the nominal G(s).
When optimisation lies: the wrong model, the wrong experiment, the wrong T
The optimiser is a microscope. It will focus on whatever you put on the slide.
Wrong G(s). If L is 30 % low, ITAE-optimal Kp is 30-ish percent high in the usual SIMC scaling Kp ~ 1/(λ + L). The champion then has thin PM on the real plant. Optimisation cannot see the missing delay. Identify first; see the tuning guide. A beautiful ITAE on a first-order plant with L set to 0 is a famous lie for any loop with piping.
Wrong experiment. Optimising a setpoint step with b = 1 produces low Kp. The load response suffers. Optimising a tiny step that never saturates produces gains that saturate on a real operator move. Match Δ, match limits, match whether D sees SP, match Ts.
Wrong T. Too short: ISE/ITAE ignore the tail, Ki is left wrong, SSE has not appeared. Too long with residual offset: ITAE is all SSE, the search cranks Ki without regard to overshoot. Use the 2 % settle as a gate: if ts is undefined, J is not comparable.
Wrong noise. Zero noise: Kd infinity (or the upper bound). Plant noise: Kd toward 0. Use the noise you have, or constrain Td.
Wrong discretisation. Euler plant stepper ringing at 2 Ts: the optimiser damps a numerical oscillation with Kd or with low Kp. Use RK4, Ts ≤ τ/10, as in the digital PID article.
Wrong success criterion. “ITAE went down 8 %” is not a reason to load new gains if OS went from 6 % to 19 % or PM from 50° to 28°. Always read the metrics dashboard and the Bode numbers. The integral is a tie-breaker among loops that already passed the spec, not a replacement for the spec.
Linear model, nonlinear valve. Optimisation on G(s) = K e^{−Ls}/(τs+1) will not know that at 80 % travel the gain doubled. Schedule, detune, or optimise against two models and keep the gains that survive both.
A workflow that keeps the integrals honest
Build a model that overlays the bump test. Choose Ts, limits, anti-windup, and derivative filter as they will run. Pick the experiment that matches the duty: load step for regulation, SP step for servo, both if you have 2-DoF knobs.
Use IAE as a general integral, ITAE when the complaint is a long tail or residual hunt, ISE only when large early error is the incident. Constrain overshoot, gain bounds, and if possible PM/GM. Start from SIMC. Integrate with trapezoid on e, RK4 on the plant, T past settle.
Then take the champion back to the simulator and to the Bode plot. If you would not defend the step and the margins without the ITAE number, do not defend them with it. PID Solver 360’s optimiser is a fast way to walk downhill from a good rule. It is not a substitute for knowing what downhill means. The integral you minimise is a sentence in English: IAE says “all error counts”, ISE says “big error counts extra”, ITAE says “late error counts extra”. Write that sentence next to the gains you ship, so the next engineer knows which opinion the loop was built to satisfy.
Put this into practice — model your process, auto-tune it and check the stability margins.
Launch PID Solver 360