Chapter 06

Black-Box Software Sensing

Seen from outside, a Kalman filter is nothing but a map from the measured signals to the unmeasured state. That map can be identified from data instead of constructed from a model — which trades away the need for physics and buys, in return, a requirement that is easy to miss: during training you must own the very sensor you intend to delete.

Reading: ~23 min Interactive: 1 widgets Source: Polimi MIDA2 2025/26 — Lecture 21, slides 8–17 (Ch. 2.4 — black-box SW-sensing) · Polimi MIDA2 2025/26 — Lecture 22 (Ch. 2.4 — architectures and the comparison)

01 · The idea

A Kalman filter is just a map from measurements to the state

Chapter 04 built a state estimator out of physics: a replica of the plant, an innovation, a gain derived from a Riccati equation. This chapter throws all of that away and keeps only the input/output behaviour — and gets a working software sensor anyway.

Look at the Kalman filter from outside, ignoring its internals. Two signals go in — the input $u(t)$ and the measurement $y(t)$ — and one comes out, $\hat x(t)$ . Nothing about that description mentions $F$ , $H$ , or a covariance. It is a MIMO LTI map $\{u,y\}\mapsto\hat x$ , and that is all an external observer can see.

key

The pivot of the chapter, and it is purely a change of viewpoint

If the estimator is just a map, then instead of constructing that map from a model, you can identify it from data. The estimation problem becomes a system-identification problem: $u$ and $y$ are the inputs, and $x$ is the output.

That is the whole idea. Everything below is consequences.

The baseline being challenged

It is worth writing down what the Kalman filter actually offers, because the black-box route inverts the first two points exactly:

	Kalman filter
a white-box model $\{F,G,H\}$	required — a hard prerequisite
a training dataset	in principle not needed (in practice one is used to tune $V_1$ and $V_2$ )
how it is obtained	constructive, via a feedback-correction scheme
totally unmeasurable signals	can estimate them, in principle

What black-box costs instead

Recasting as identification needs data, and not just any data:

The training dataset

$\{u(1),\dots,u(N)\},\qquad \{y(1),\dots,y(N)\},\qquad \boxed{\{x(1),\dots,x(N)\}}$

The trade, in one line — and the part everyone misses

The Kalman filter needs a model but no data. The black-box software sensor needs no model but needs ground-truth measurements of the state itself.

Which means: to train the algorithm that replaces a physical sensor, you must install that physical sensor on a development vehicle and run it. The method removes the sensor from the product, not from the programme. Note the qualifier on the box above — $x(t)$ is required only during the training stage, never afterwards, which is exactly why the trade is worth making at volume.

The object being identified

With that dataset, fit a parametric map from both measured signals to the state:

The black-box software sensor

$\hat x(t)=S_{ux}(z;\theta)\,u(t)+S_{yx}(z;\theta)\,y(t)$

one transfer function from the input to the state and one from the output to the state, both parameterised by $\theta$ . Fit it by least squares against the ground truth:

The performance index

J_N(\theta)=\frac1N\sum_{t=1}^{N}\Big(x(t)-\big(S_{ux}(z;\theta)u(t)+S_{yx}(z;\theta)y(t)\big)\Big)^{2}, \qquad \hat\theta_N=\arg\min_\theta J_N(\theta)

✓

Those are matrices, not scalars

The compact notation hides the size of the problem. For a plant with $m$ inputs, $p$ outputs and $n$ states, $S_{ux}$ is an $n\times m$ matrix of transfer functions and $S_{yx}$ is $n\times p$ :

\begin{bmatrix}\hat x_1\\ \vdots\\ \hat x_n\end{bmatrix} =\begin{bmatrix}S_{ux_{11}}&\cdots&S_{ux_{1m}}\\ \vdots&\ddots&\vdots\\ S_{ux_{n1}}&\cdots&S_{ux_{nm}}\end{bmatrix} \begin{bmatrix}u_1\\ \vdots\\ u_m\end{bmatrix} +\begin{bmatrix}S_{yx_{11}}&\cdots&S_{yx_{1p}}\\ \vdots&\ddots&\vdots\\ S_{yx_{n1}}&\cdots&S_{yx_{np}}\end{bmatrix} \begin{bmatrix}y_1\\ \vdots\\ y_p\end{bmatrix}

So this is a MIMO identification problem, not a scalar one — which immediately determines which method can solve it.

02 · The trade-off

Model-based versus black-box

Both approaches deliver the same object — an algorithm that reconstructs an unmeasured quantity from measured ones. They differ on six dimensions, and the exam asks for exactly those six.

A 3-mark theory question with a six-row marking scheme

“Compare and briefly discuss the main characteristics (pros and cons) of a model-based SW-sensing method (K.F.) and a black-box SW-sensing method” — set on 14/07/2025 for 3 marks. It is a pure compare-and-contrast, and the table below is the answer. Six rows, no mathematics.

An answer that lists advantages of both without ever saying which capability each one has that the other lacks does not finish the question. The two rows that decide real designs are the last two.

	Kalman filter (model-based)	Black-box
needs a physical model	yes	no
needs a training dataset	in principle no; in practice yes, to tune $V_1$ , $V_2$	yes, and it must contain $x$
interpretability	yes — every matrix means something	no — the parameters mean nothing
easy re-tuning for a similar plant	yes	no — a fresh campaign every time
achievable quality	good, bounded by the model	very good, bounded by the data
can estimate un-measurable states	yes	no

Read across the rows and the two methods fail in different directions. The Kalman filter’s ceiling is its model: a biased model gives a biased estimate however clean the data. The black-box sensor’s ceiling is its dataset — and on a complex nonlinear plant with a rich dataset that ceiling is higher, which is why the quality row favours it.

why

Which to reach for

Use the Kalman filter when a trustworthy model exists, when the estimate needs an error bar (chapter 05’s $\bar P$ is one, and black-box has no equivalent), or when the target was never measurable in the first place.

Use black-box when modelling the plant is infeasible but a well-instrumented prototype can be built and driven — and when the production volume justifies the development campaign, which is the same economics argument that opened chapter 04.

2025-07-q52025Q05KF vs black-box SW-sensingmedium3 pts

Compare and briefly discuss the main characteristics (pros and cons) of a model-based SW-sensing method (K.F.) and a black-box SW-sensing method.

03 · The linear case

Identifying the sensor — with an algorithm you already have

For a linear plant the problem posed in §01 is a MIMO state-space identification, and the course has already built the tool that solves it.

The map to be identified takes $\{u,y\}$ to $x$ , and the general method for recovering a MIMO state-space model from input/output data is 4SID — chapter 02’s algorithm, applied here with the plant’s output $y$ demoted to an input of the estimator and the state $x$ promoted to its output.

key

Chapter 02 is not a standalone topic — it is this chapter's engine

It is easy to read 4SID as a self-contained identification method and this chapter as a self-contained sensing method. They are one pipeline: the software sensor is identified by 4SID. That is why subspace-identification is a hard prerequisite here, alongside kalman-filter.

Once $S_{ux}(z;\hat\theta_N)$ and $S_{yx}(z;\hat\theta_N)$ have been estimated, the physical sensor for $x(t)$ can be removed and replaced by the algorithm. That is the deliverable, and at that point the development-time cost from §01 has already been paid.

When the plant is nonlinear

The idea survives unchanged; only the model class has to grow. A nonlinear plant needs nonlinear models, and §04 is the taxonomy of how to build them. Before that, one piece of notation, because the architecture diagrams are unreadable without it:

Linear and dynamic

A delay, a filter, a transfer function. Has memory, obeys superposition.

Nonlinear but static

A map applied instant by instant — a neural network layer with no feedback, a lookup table, a saturation. No memory.

Nonlinear and dynamic

Both at once. The most general and, as §04 shows, the hardest to train and to certify.

The whole design game in §04 is where to put the dynamics — because if all the memory can be pushed into the linear part, only a static function has to be trained.

04 · Nonlinear

Four architectures, and the one that bites

Three architectures plus a meta-architecture that composes with any of them. They differ in exactly one thing — how the dynamics are handled — and that one choice decides whether stability is free, expensive, or absent.

Set twice, in consecutive sittings

“Describe the architectures for black-box SW-sensing that combine a linear-dynamical part with a non-linear static part (#2 and #3). Briefly discuss their relative pros and cons” — 3 marks, set with an identical stem on 12/02/2026 and 26/06/2026. The question bank deduplicates the two into one entry, so the automatic frequency count reads one question where the archive has two; this chapter’s derived weight is correspondingly conservative.

The marking scheme is the shared design idea, then #2’s guaranteed stability against its dimension blow-up, then #3’s smaller regressor vector against its deployment instability. Naming the open-loop-training / closed-loop-deployment mismatch is what separates a full answer from a diagram.

Architecture #1 — a recurrent network

Take a classic static neuron — weighted sum, bias, sigmoid — and add a single $z^{-1}$ feedback path from its output back into its own summing junction. That one red arrow turns a nonlinear static map into a nonlinear dynamic one, and a network of such neurons is a very general nonlinear dynamical function that can be trained to be an optimal software sensor.

Presented, then rejected — do not read #1 as the recommendation

It is the most general and most intuitive solution, and it is not much used, for two reasons:

training costs are large — a recurrent network is expensive to optimise;
stability of the trained solution is very hard to guarantee — there is no structural argument, only empirical testing.

Architectures #2 and #3 exist precisely to fix these two objections. Quoting #1 as the answer to the exam question misses the point of the lecture.

Architecture #2 — the FIR split

Split the sensor in two. A linear, dynamic, parameter-free front end: a bank of unit delays producing $u(t-1),\dots,u(t-n_u)$ and $y(t),y(t-1),\dots,y(t-n_y)$ . Then a nonlinear but static back end $f(\cdot\,;\theta)$ — typically an ordinary feed-forward network — mapping all of those regressors to $\hat x(t)$ .

key

All the dynamics are fixed; only a static map is trained

The delay bank has no parameters. Training touches nothing but $f(\cdot\,;\theta)$ , a static function — and both of architecture #1’s objections evaporate at once. Training a static map is cheap, and a structure with no recursion cannot diverge, so FIR architecture stability is guaranteed by construction.

The price is dimension. Counting the regressors for an $m$ -input, $p$ -output, $n$ -state plant:

The input dimension of the static map

$f(\cdot\,;\theta):\ \mathbb R^{\,(m\cdot n_u)+\big(p\cdot(n_y+1)\big)}\longrightarrow\mathbb R^{\,n}$

which grows fast with channel count and memory depth, inflating both the parameter count and the amount of data needed to fit it.

✓

Why n_u but n_y + 1

The asymmetry is not a typo. The $u$ -chain starts at $u(t-1)$ — the map is strictly causal in the input — while the $y$ -chain includes $y(t)$ itself, because the current measurement is available when the estimate is formed. Same reason the Kalman filter may use $y(t)$ and the predictor may not.

Architecture #3 — the IIR split

Identical two-stage layout, plus a third delay chain: past values of the state, $x(t-1),\dots,x(t-n_x)$ , also wired into the static map. The front end is now recursive.

The advantage is the classic IIR-over-FIR one. In #2 memory is built up by stacking delays; in #3 the recursion carries memory, so a few delays on $u$ , $y$ and $x$ suffice. The regressor vector and the network both shrink substantially.

The architecture that is trained is not the architecture that is deployed

During training the $x$ -delay chain is fed the measured ground-truth $x(t)$ — the model runs open-loop, a scheme called teacher forcing. In production there is no measured $x$ , so the chain must be fed the model’s own estimate $\hat x(t)$ , closing a loop around the whole estimator.

That loop was never exercised during training. It can drift, and it can diverge — and the failure appears only after deployment, when every training metric looked excellent. Stability was guaranteed by construction in #2 and is forfeited in #3.

#2 — the safe default

Reliability over model size. Trained and deployed in the same configuration, so training performance transfers honestly. Choose it unless the dimension count makes it impractical.

#3 — when #2 will not fit

Choose it when channel count or memory depth blows up #2’s input vector — and then verify closed-loop stability separately, because nothing else will.

Meta-architecture #4 — let physics choose the regressors

Not a competitor to #1–#3 but a stage placed in front of any of them. Instead of feeding raw $u(t)$ and $y(t)$ into the estimator, insert a pre-processing block built from physical know-how that emits a short list of physically meaningful regressors $R_1,R_2,R_3,\dots$ ; only the second stage is identified from data.

The gain is dimension. On the lecture’s vehicle example, estimating tyre forces from a dozen raw channels — four wheel speeds, two accelerations, three body rates, two steering angles — collapses to four slip angles plus a longitudinal speed, because tyre physics says force depends on slip, not on wheel speed directly. Five regressors instead of eleven, before a single parameter is fitted.

key

The gray-box move, applied to sensing

Physics chooses what to look at; data fits how it maps. That is the same division of labour chapter 07 uses for identification, and the lecture’s recommendation here is unambiguous: try #4 if you can. The cost is that the pre-processing block needs a domain expert — which is exactly the modelling effort black-box was meant to avoid, bought back deliberately because it pays for itself.

A recursive black-box software sensor is trained on a dataset containing the ground-truth state, and tracks it almost perfectly on both training and validation data. Deployed on the vehicle, its estimate slowly drifts away over a few minutes. What is the most likely cause?

2026-02-q42026Q04Black-box SW-sensor architecturesmedium3 pts

Describe the architectures for Black-Box SW-sensing that combine a linear-dynamical part with a non-linear static part (architectures

05 · The hard limit

What black-box software sensing cannot do

The comparison table has one row that is not a trade-off but a wall, and it is the reason chapter 04 is not superseded by this one.

A black-box sensor cannot estimate a quantity that was never measured. The method is supervised: it fits a map against ground truth, so no ground truth means nothing to fit. If a state is un-measurable states — no instrument exists, or none can be installed even on a prototype — there is no training set and there is no software sensor.

The Kalman filter has no such restriction. It needs the state to be observable, which is a property of $F$ and $H$ , not of the instrumentation budget. Chapter 04 §01 posed feasibility as a rank test precisely because that is all it takes.

Two smaller limits follow the same pattern.

No error bar

Chapter 05’s $\bar P$ quantifies the estimate’s accuracy, and the Riccati recursion produces it before any data exists. A black-box sensor offers no equivalent — validation error on a held-out set is an average over the data you happened to collect, not a covariance.

No portability

Change a physical parameter and a Kalman filter follows: edit $\{F,G,H\}$ and re-solve. A black-box sensor holds that parameter implicitly in fitted weights, so a variant plant needs a fresh data campaign and a fresh training run.

Deep dive Why this chapter is worth its low exam weight

Two stems, three sittings, 3 marks each — the lightest chapter in the module by recorded marks. It is also the newest: neither question appears before 2025, and the architectures question was then set in two consecutive sittings. On the archive’s own evidence the topic is being introduced, not retired.

The other reason to read it properly is structural. This chapter is where three earlier chapters meet: chapter 01’s state-space description supplies the object being estimated, chapter 02’s 4SID is the solver, and chapter 04’s Kalman filter is the baseline being challenged. Meta-architecture #4 then sets up chapter 07 by making the same move in the opposite direction — letting physics constrain a data-driven fit.

Load-bearing ideas

The reframing: from outside, a state estimator is a MIMO LTI map $\{u,y\}\mapsto\hat x$ . Identify it instead of constructing it, and the model requirement disappears.
The trade: the Kalman filter needs a model and no data; the black-box sensor needs no model and a dataset containing the ground-truth state — so the sensor being replaced must exist during development. It is removed from the product, not from the programme.
The object fitted: $\hat x(t)=S_{ux}(z;\theta)u(t)+S_{yx}(z;\theta)y(t)$ with a quadratic index over the measured $x$ . $S_{ux}$ and $S_{yx}$ are matrices of transfer functions, so this is a MIMO identification — solved by 4SID.
Six-row comparison: model needed (KF yes / BB no) · dataset (KF no / BB yes) · interpretability (KF yes / BB no) · re-tuning (KF yes / BB no) · quality (KF good / BB very good) · un-measurable states (KF yes / BB no).
Architecture #1 — recurrent network, $z^{-1}$ inside the neuron. Most general, rarely used: expensive to train, no stability guarantee.
Architecture #2 — FIR — fixed delay bank plus a trained static map. Stable by construction; input dimension $(m\,n_u)+\big(p(n_y+1)\big)$ , and note $u$ starts at $u(t-1)$ while $y$ includes $y(t)$ .
Architecture #3 — IIR — adds a recursive $x$ -chain, so far fewer delays are needed; but training is teacher-forced on ground truth and deployment closes the loop on $\hat x$ , so it can go unstable in production, after training looked perfect.
Meta-architecture #4 — physics-derived regressors ahead of any of the above; far smaller input vector, needs a domain expert. Try it if you can.
The wall: no ground truth, no black-box sensor. Observability is a rank test; a training set is a procurement problem.

Exam radar. This chapter is tested as theory only — no numbers have ever been asked of it. Two stems, both worth 3 marks. Be able to write §02’s six-row table from memory and say which row is a wall rather than a trade-off. Then be able to describe #2 and #3 as the same split with one feedback chain added, and name what that chain buys (smaller regressor vector) and what it costs (the open-loop-training / closed-loop-deployment mismatch, invisible until deployment). Both questions are recent and one was repeated immediately, so treat the low derived weight as a floor rather than a forecast.