AI-Enabled Real-Time Digital Twin System for Health Monitoring, Fault Prediction and Mission Reliability Enhancement of Aero Piston Engines used in MALE UAVs.
DRDO · Robotics and Drones · Software
The architecture the statement asks for is sound but there is no aero piston engine data anywhere for you to ground it in, so unless you can get real telemetry off some instrumented engine, you will be predicting faults you injected into a simulator you wrote.
What it actually is
Long-endurance surveillance drones run on piston engines, and if one fails mid-flight the mission and often the aircraft are lost. Current monitoring only raises an alarm after something has already gone wrong. The ask is a live virtual copy of the engine that mirrors the real one from its sensor feed, spots degradation early, estimates how much life is left, and lets engineers replay a flight afterwards.
What to build
A digital twin with the six components the statement lays out: a virtual engine model synchronised to live telemetry through a real-time ingestion path over CAN or an engine controller interface; a health monitoring layer computing indices from the parameters the statement names individually including RPM, cylinder head and exhaust gas temperature, oil pressure and temperature, fuel flow, vibration signature, alternator health and injection timing; a predictive diagnostics layer for the eight named fault modes from misfire and injector abnormality through lubrication issues, sensor drift and combustion instability; an AI layer providing anomaly detection, remaining useful life estimation and maintenance recommendations; a simulation and replay capability reproducing engine behaviour under high altitude, endurance, hot weather and rapid throttle transitions; and an operator dashboard carrying health status, alerts, efficiency trends and mission-wise reports.
Smallest thing that wins the room
Replay a mission profile with a developing fault seeded into it and show the twin flagging the divergence between predicted and observed cylinder head temperature well before any threshold alarm would fire, with the remaining useful life curve bending as it does.
How crowded this one gets
A guess, projected from the 2025 statements — the last year where both the submission counts and the winners were published.
Quieter than 65% of the 226 · #80 of 226 by expected field
A normal-sized field. Your idea has to be good, not miraculous.
Why: defence, intelligence and space bodies drew small fields.
This is a guess, not a fact
Nobody has published 2026’s numbers yet. This is an analysed estimate from last year’s pattern, so please do not take it as the truth — check the live counter on the SIH portal before you decide anything. The range covers the middle half of likely outcomes, so one statement in two lands outside it. Entry closes at 500 ideas per statement, so no range goes past that — a statement that reaches the cap fills and shuts rather than drawing an unlimited crowd. The model reads only three things a team can see before choosing — software or hardware, the theme, and what kind of body posted it — and those explain about a quarter of the variation in last year’s field sizes (R² 0.25 on held-out statements). Trust the band more than the number, and the ordering more than either. It cannot see how good your idea is, which is the part that actually decides it.
The scores
The number is the shorthand. The line under it is the reason.
Acceptance potential
2/5This is circular validation at the centre of the statement — with no real engine data you simulate the engine, inject the degradation, train on that output and report accuracy against it — and a DRDO propulsion panel will ask about the data provenance in the first minute.
Feasibility
2/5There is no public telemetry for aero piston engines and certainly no run-to-failure dataset for one, the widely used public turbofan degradation data is a different machine entirely, and the engine performance maps a physics model would need are manufacturer property — so you build the engine simulator, generate the faults, train on your own output and validate against the same simulator.
Innovation scope
3/5Six components are specified with their contents enumerated and the fault modes and monitored parameters listed individually, but the statement's innovation areas section genuinely invites open approaches — physics-informed learning, hybrid thermodynamic and data-driven models, explainable diagnosis — which is where any real contribution would sit.
Clarity
4/5Very detailed on scope, naming every monitored parameter, every fault mode, all six modules and the expected deliverables, though it never states what prediction horizon or accuracy would constitute success and never acknowledges that the data underpinning all of it does not exist.
Effort
MassiveA physics-based engine model, a real-time ingestion path, a health indexing layer, eight fault predictors, remaining useful life estimation, a mission simulation and replay engine and an operator dashboard is six substantial modules, and the thermodynamic model alone is a serious piece of work.
Demo-ability
MediumA mission replay with a fault emerging and a remaining useful life curve bending is watchable and reasonably compelling, but every number in it originated in your own simulator, so the demo shows your model detecting your own injected fault.
In its favour
- Green flag: The residual approach — comparing observed sensor values against what a physics model says they should be — is the right architecture here and is genuinely defensible even on simulated data, because the model is grounded in thermodynamics rather than learned from the same synthetic set
- Green flag: If your institution has any instrumented internal combustion engine on a test rig, even an automotive one, real CAN telemetry from it transforms this submission from synthetic to grounded
- Green flag: The statement's own innovation areas list physics-informed AI and explainable diagnosis, which gives you licence to make model-grounded reasoning rather than raw prediction accuracy your claim
- Green flag: DRDO is a T1 sponsor and a propulsion-literate panel will reward correct engine understanding far more than dashboard polish
Against it
- Red flag: No aero piston engine telemetry or run-to-failure data exists publicly, so both the training data and the validation data come from a simulator you wrote — this is the classic circular setup and it is fatal if you do not confront it openly
- Red flag: Eight named fault modes each have distinct signatures across different sensors, and a team that builds one detector and relabels its outputs has answered one eighth of the diagnostic requirement
- Red flag: The turbofan degradation datasets teams reach for by reflex are a different machine with different failure physics, and substituting them without saying so is exactly the shortcut a propulsion judge will catch
- Red flag: Remaining useful life is meaningless without a defined end-of-life criterion, and the statement never gives one, so you are inventing the quantity you claim to predict
What you will be writing
- physics-informed thermodynamic engine model
- SocketCAN telemetry ingestion from ECU/FADEC
- LSTM or transformer remaining useful life estimation
- residual-based anomaly detection against model prediction
- SHAP explainable fault attribution
- React operator dashboard with mission replay
- Predictive maintenance
- UAV propulsion
- Digital twin systems
Prior art to read before you start
engine health monitoring and fault prediction · remaining useful life estimation · physics-informed digital twin
Analysed by Claude Opus. Every score above is a judgment call with its reasoning attached — kindly cross-check this against the official statement on the SIH portal before your team commits to it.