The thesis, in plain English.
Seven chapters. Six interactive figures. The PhD as a working artefact, not a summary.
Premise A network you can audit, not assume.
Aerospace sensor networks rarely get designed end-to-end. They accrete: each subsystem owner adds the sensors they need, each generation adds a few more, no one owns the whole picture. The result is a network simultaneously over-instrumented in some places — redundant sensors that contribute nothing to a diagnosis — and blind in others, with failure modes nothing currently sees1.
The premise of this thesis is that sensor selection is a multi-objective decision under uncertainty, and therefore amenable to the same treatment we give every other multi-objective decision: explicit objectives, explicit constraints, an explicit search procedure, and an explicit Pareto front to choose from. The list of fault modes the network is supposed to catch is the input. The ranked, scored sensor configuration is the output3.
The cross-subsystem evaluation in this thesis covers 25 fault modes across four subsystems — Engine, Fuel, EPS, and ECS — drawn from the airline-case scenario in the 2026 paper16. Each fault is the failure of a real component on a B737-class aircraft. The question the rest of the thesis asks is: from a candidate suite of 96 sensors, which subset detects this list with the best trade-off across cost, weight, and reliability?
MOSOF A search, not an opinion.
The Multi-Objective Sensor Optimisation Framework treats the sensor-selection problem as a constrained search over a binary inclusion vector: each candidate sensor is in or out. The fitness functions are the things stakeholders fight about — cost, weight, suite reliability, diagnostic coverage — and the search returns the Pareto-optimal set across them3.
Concretely: the search engine is a non-dominated sorting genetic algorithm in the NSGA-II family11. Population size 80, 100 generations, simulated-binary crossover with ηc=20, polynomial mutation with ηm=20. The front is identified by Deb's fast non-dominated sort; selection by crowding distance. None of this is novel — what's novel is the fitness functions, which is what the next chapter is about.
In benchmarking on canonical 3-objective DTLZ2, MOEA/D edges out the others by a hair on hypervolume13; NSGA-II and SPEA2 land within statistical noise of each other1112. The choice of solver matters less than the choice of fitness functions, which is the thing this thesis adds.
NDCI Sensors aren't equal — measure the inequality.
The Normalised Diagnostic Contribution Index — NDCI2 — is the second contribution and the one the framework needs to do its job. NDCI gives every candidate sensor a comparable score for its share of system-level diagnostic capability, derived from three components: Sensitivity (S), Uniqueness (U), and Separation Power (SP).
S quantifies how strongly sensor i responds across the full fault set (a sensor that doesn't move is a sensor we don't need). U quantifies how distinct its response signature is from the other sensors' (two sensors that always respond identically only count as one). SP quantifies how separable the across-fault responses are when projected onto sensor i's axis (a sensor that says "something's wrong" but can't say what is worth less than one that can isolate the fault). Each is normalised to $[0,1]$ so the three add up to a comparable score2.
The qualitative result that justifies the measure: across the four subsystems, NDCI consistently elevates sensors the engineering intuition undervalues (Waft-bleed and hS4 in Engine; ACfluoro V and ACinstr V in EPS; Thi-SHX and Tout-turb in ECS) and demotes sensors that look load-bearing but aren't (Tci-CHX remains largely static across ECS faults)4.
Case study The B737-800, four subsystems, twelve sensors.
The validation case is a Boeing 737-800-class aircraft with the four subsystems above. The candidate catalogue contains 96 sensors across seven families — Flow, Torque, Pressure, Temperature, Thermodynamic, Electrical, and Computed — each with cost ranges and MTBF distributions documented in the thesis5.
The trade-off the search confronts is concrete: every additional sensor adds cost (in US dollars, sensor purchase + installation), weight (which costs fuel for the lifetime of the airframe), and reduces suite reliability (modelled as series-equivalent MTBF, $1/\sum_i 1/\text{MTBF}_i$). The search picks subsets that maximise diagnostic coverage subject to those penalties.
The published knee — read off the Pareto front and confirmed against the NDCI ranking — is a 12-sensor suite at 0.69 normalised diagnostic performance, $36k, 145 kh series-equivalent MTBF9. The interactive figure above is the exact composition; reallocating it sub-optimally (try moving sensors out of Engine, which has the fattest fault set) makes the cost in coverage immediately visible.
Validation Walk every point on the front.
The validation chapter is, mostly, the Pareto front itself. The 2025 paper validated the framework on the ECS subsystem alone2; the 2026 paper widened it to the full cross-subsystem case and produced the front you can walk through below1. Every point shown is non-dominated. The recommended knee (highlighted) is the same one in the figure above.
The numerical headline in the validation tables: NDCI suites match or beat mRMR baselines on balanced classification accuracy across all four subsystems with fewer or equal sensors. ECS NDCI 0.812 with 6 sensors vs mRMR 0.812 with 8; Engine NDCI 0.926 with 9 vs mRMR 0.778 with 12; EPS NDCI 0.731 with 8 vs mRMR 0.346 with 1278. The MOSOF + NDCI combination doesn't merely match the alternative; on the harder subsystems it lifts performance with fewer sensors.
Limits What the framework does and doesn't claim.
A framework that produces a single recommended sensor configuration sounds like an oracle. It isn't, and the thesis is careful about where the limits are.
First, the diagnostic-coverage objective is computed against the declared fault set. The framework can't recommend a sensor for a fault that isn't on the list. Adding new faults to the catalogue (a wider failure-mode-and-effects analysis) is upstream work the framework consumes, not produces.
Second, the search assumes the cost / weight / MTBF data on the candidate sensors is correct. It is, in practice, vendor-supplied and varies. The framework outputs a Pareto front; how robust the chosen knee is to data-input perturbations is a sensitivity question the thesis poses but doesn't fully resolve. A worked sensitivity analysis is queued for the next paper.
Third — and this is the one the framework absolutely does not solve — NDCI is silent on certification. A sensor that scores high on NDCI but isn't EASA-approved can't go on an aircraft, no matter what the search says. The framework hands a ranked shortlist to the certification engineer, not a fait accompli.
What it unlocks The same thinking, taken further.
The thesis closes the loop on a methodological question: if you take sensor selection seriously as a multi-objective decision, you can audit it, you can rerun it, and you can defend the result to the people whose objectives you weighted. That much is delivered.
What it unlocks beyond the academic contribution is practical. The two ventures attached to this work — AcoustR and Sensorry — apply the same NDCI thinking to two different sensor problems: AcoustR pushes the limit case (one microphone, maximum information), Sensorry packages the MOSOF workflow as engineering tooling. The 2026 paper is the bridge between the thesis and those products; the proof page is the bridge for visitors who want to see the whole arc end-to-end.
If your problem looks like the one in chapter IV — a sensor network you inherited rather than designed — the right next step is the proof page, which walks the same case end-to-end with the live data and links to the published paper.