Predictive models of sensor dynamics

"You keep asking me what the temperature is. What I can tell you is what the temperature was, filtered through a lump of metal with opinions of its own. Give me a model of the metal and I will give you back the present."

A Patiently Lagging AI Agent

The sensor as a dynamical system

The what: a predictive model of sensor dynamics is a map from the trajectory of the true quantity \(u(t)\) to the trajectory of the sensor output \(y(t)\), mediated by an internal sensor state \(x(t)\). The simplest and most common case is a first-order linear sensor, the behavior of any transducer whose reading relaxes toward the true value with a single time constant \(\tau\):

Here \(x\) is what the sensing element has "equilibrated to" so far, \(\tau\) is how sluggish it is (large \(\tau\) means slow), and \(v\) is readout noise. The why of writing it this way is that it separates two things Chapter 2 conflated: the instantaneous calibration curve (how a reading maps to a value once everything settles) and the dynamics (how long settling takes and what the reading does in the meantime). Many sensors need a second-order model instead, \(\ddot{x} + 2\zeta\omega_n\dot{x} + \omega_n^2 x = \omega_n^2 u\), which adds resonance: a lightly damped accelerometer or pressure sensor overshoots and rings at its natural frequency \(\omega_n\) before settling. Both are special cases of a linear time-invariant system with a transfer function \(H(s) = Y(s)/U(s)\), and the sensor's bandwidth, rise time, and phase lag all fall out of \(H\). The predictive model is this operator, discretized to your sample rate so it can be stepped one tick at a time.

Three ways to build the forward model

The how spans a spectrum from pure physics to pure data. A white-box model writes the ODE from first principles and measures its few parameters (\(\tau\) from a step-response test, \(\omega_n\) and \(\zeta\) from a ringdown); it is interpretable, needs almost no data, and extrapolates, but only as far as your physics is honest. A black-box model ignores the physics and fits a sequence model (an ARX/state-space system identified from input-output logs, or a small recurrent or state-space network from Chapter 16) directly to paired \((u, y)\) records; it captures effects you never wrote down but demands representative data and can extrapolate badly. A grey-box model, the workhorse of digital twins, keeps the physical ODE as scaffolding and learns only the parts the equations miss, and it earns its own section (55.5). The choice is governed by how much you trust your physics against how much labeled dynamics data you can gather. Whatever the family, the discretized model has the same shape as a Kalman transition and observation pair (Chapter 9): a state update \(x_{k} = f(x_{k-1}, u_{k-1})\) and an emission \(y_k = g(x_k)\), which is precisely why the twin can later be dropped straight into an estimator in Section 55.6.

import numpy as np

def sensor_forward(u, tau, dt, x0=None, noise=0.0, rng=None):
    """Predict a first-order sensor's output stream from the TRUE quantity u.
    tau: sensor time constant (s); dt: sample period (s).
    Exact zero-order-hold discretization of tau*x' = u - x."""
    rng = rng or np.random.default_rng(0)
    a = np.exp(-dt / tau)                 # how much of the old state survives one tick
    x = float(u[0]) if x0 is None else x0
    y = np.empty(len(u))
    for k, uk in enumerate(u):
        x = a * x + (1.0 - a) * uk        # relax toward the current true value
        y[k] = x + (noise * rng.standard_normal() if noise else 0.0)
    return y

dt, tau = 0.1, 2.0                        # 10 Hz sampling, 2 s sensor lag
t = np.arange(0, 20, dt)
u_true = np.where(t < 5, 20.0, 80.0)      # a step from 20 to 80 units at t = 5 s
y_pred = sensor_forward(u_true, tau, dt, noise=0.5)

# time for the reading to cross 63% of the step: should land near tau after the step
crossed = t[(t >= 5) & (y_pred >= 20 + 0.63 * 60)][0] - 5
print(f"predicted 63% rise time: {crossed:.1f} s   (tau = {tau} s)")

Listing 55.1 is the atom of the whole chapter: a routine that takes what the world is doing and returns what the sensor will say. Swap the one-line update for an identified state-space matrix or a learned network and the interface is unchanged, which is what lets Section 55.2 call it millions of times to manufacture synthetic sensor data.

What real sensors add: drift, hysteresis, and cross-sensitivity

A clean linear \(\tau\) is the honeymoon. Real transducers layer on effects that a static calibration cannot see and that make a dynamic model necessary. Drift is slow wandering of the baseline or gain over hours to months (electrochemical gas sensors, MEMS bias), modeled as an extra slow state \(b(t)\) with its own random-walk dynamics added to the reading. Hysteresis means the output depends on the direction of change, so the reading on the way up differs from the reading on the way down at the same true value; it needs an internal memory state and cannot be captured by any single-valued curve. Cross-sensitivity couples in nuisance inputs, most often temperature: a strain gauge or a lidar's range both drift with their own temperature, so the honest model is \(y = g(x, T, \dots)\) with the extra channels as inputs. Saturation and slew limits clip and rate-limit the output nonlinearly near the range edges. The reason to name these explicitly is that each one is a specific, well-understood term you add to the forward model, and each is a fault mode a predictive-maintenance system (Chapter 36) watches for; a twin that omits them will look healthy while the real instrument quietly degrades.

Fitting and trusting the model

The when and the how-good. You need a predictive dynamics model whenever the measurand moves fast relative to the sensor (comparable to or faster than \(\tau\)), whenever you must simulate the sensor to make synthetic data or a twin, or whenever lag, drift, or cross-sensitivity would corrupt a decision. Fit it from a paired record of a known input and the sensor's response: a step or chirp excitation for white/grey-box parameters, or ordinary operating logs for black-box identification, always with the leakage-safe split discipline of Chapter 5 so that test trajectories are genuinely unseen dynamics and not neighboring windows of a training run. Then evaluate on the axis that matters for a forward model: not one-step error, which is flattered by the signal barely changing between samples, but free-running rollout error, where the model is driven by the true input but predicts \(y\) for a long horizon from its own evolving state. A model with tiny one-step error can still drift catastrophically over a rollout if its \(\tau\) or its integrator is slightly off, and that rollout gap is exactly what Section 55.7 formalizes into a validation protocol for twins. Report it with a calibrated uncertainty band (Chapter 18), because a forward model without error bars is an assertion, not a prediction.

What's Next

In Section 55.2, we put this forward model to work as a factory. Once a sensor's dynamics, noise, drift, and cross-sensitivities are captured in a runnable model, you can drive it with an unlimited variety of simulated scenarios, including faults you could never safely stage on real hardware, and mint labeled synthetic sensor streams to train detectors on. The predictive model of dynamics built here is the engine; simulation and synthetic sensor data are what it produces.