Multi-target tracking, sensor fusion and estimation

The algorithm is the small part

Look at one number first. The association engine behind these articles runs in 2.5 ms, inside a 100 ms cycle. A few hundred lines of arithmetic. Now ask what stands around it in a real airborne programme: a safety assessment, an error budget, a calibration procedure, worst-case timing analysis, structural coverage of every line of code, qualified tools, a configuration index, problem reports.

On a real programme the algorithm is a small fraction of the work. People who come from the university side usually do not believe this until they see one programme from inside. The standards that define all of it are ARP4754A for the system and DO-178C for the software, and the rest of this tour walks through the parts that cost the most.

The level is not chosen

DO-178C sorts software by what happens when it fails. Catastrophic failure means level A. Our case is milder: the tracker only advises a human operator. The worst failure is misleading data — a confirmed track with a small reported error and nothing real under it. The operator loses situation awareness, so the condition is Major and the software lands on level C.

Now note what happens if the output commands a manoeuvre instead of advising a person. Same tracker, same code — and the level jumps to B, with nearly double the independent verification. The assurance level comes from the system context, not from the software itself. You cannot pick it to save money.

Accuracy comes from calibration

Here is the least intuitive result in the whole design. Take the full error budget of one bearing measurement: centroid noise, lens distortion, motion smear, time stamping, and knowledge of where the sensor points. The last term is 99% of the variance.

So a better lens buys nothing, and a better survey of the mount buys almost everything. Accuracy is created on the ground, by calibration, and the algorithm can only preserve it. One consequence worth sitting with: the calibration file becomes airborne data, with its own part number. A wrong file crashes nothing — it gives confident wrong answers, the failure from the level discussion, arriving through the back door.

The worst case must be a number

A demo can say: it runs fast, we measured it. Avionics cannot. A measurement only tells what happened on the inputs you tried; certification asks for the worst case, as a number, proven from the structure of the code. Memory the same — fixed before the system ever runs, not observed while it does.

And the real code for such a system is written in C, to the MISRA C coding standard. This is not about style. MISRA exists to make the worst case analysable: it bans dynamic memory, unbounded loops, and the corners of C where the compiler is free to surprise you. One more thing people forget: the analysis tools themselves need qualification under DO-330, because a timing analyser that under-reports is a tool that hides an error. The reference code behind the deterministic engines is substantially progressed toward MISRA C:2012, with a documented gap analysis. Not compliant, and I do not claim it is.

Failure is a design input

In a real programme you write the failure table before you finish the design. Each row: what breaks, how the system detects it, what it does. A failure that cannot be detected is not a failure mode, it is a hazard, and you redesign until none remains.

Two examples from this system. Lose one of the three nodes, and the tracker cannot separate real targets from ghost intersections any more: accuracy drops from 41 m to 150–190 m, and no tuning can recover it, because the information is simply not in the geometry. The right response is to warn the operator, not to re-tune. And a knocked boresight is the nasty one: it produces precise, confident, wrong bearings, and the detection is indirect and late. That failure is what sets the recalibration schedule.

Verification, and the paper trail

Every requirement gets a test that traces to it, with a pass criterion written before the test runs. Together the tests must reach every statement in the code; whatever they do not reach is dead code to remove, or deactivated code to prove unreachable.

Then the layer nobody budgets for: the verification matrix, the configuration index that says exactly what was built from what, a problem report for every defect. This is not bureaucracy — it is what makes a result reproducible and a defect count. On a real programme this evidence is the deliverable. The code is almost a by-product.

What is not claimed

To be clear about this demo: no hardware was built, nothing here went through a qualification programme, and nothing is offered for certification credit. The algorithms in the method articles are real and measured — the deterministic core is verified against a reference implementation bit for bit, and the performance numbers are five-seed medians. But the system in this essay is an illustration, not a product.

If you take one thing from here, take this. When someone shows you a tracking algorithm and calls it a system, ask about the calibration plan and the worst-case timing. The answers tell you how far they really got.