AI/ML-Based Intelligent Anomaly Detection for Automatic Weather Stations (AWS)
Ministry of Earth Sciences (MoES) · Disaster Management · Software
The sponsor gave you free data, sanctioned anomaly injection and published the marking scheme, and the scope is small enough to finish properly — win it on the one hard part, which is letting a real heatwave through while catching a drifting sensor.
What it actually is
Automatic weather stations feed the forecasting system continuously, and when a sensor drifts, freezes or fails the bad readings flow straight into the models. Simple range checks catch the obvious errors and miss the subtle ones. The ask is a system that learns what normal looks like for temperature, pressure and humidity and flags the faulty readings without flagging genuine extreme weather.
What to build
A real-time quality control layer over the three parameters the statement restricts you to, combining a temporal model that learns each station's normal daily and seasonal behaviour, a rate-of-change and frozen-value detector for the specific fault signatures named including spikes, stuck sensors and communication dropouts, and a multivariate consistency check exploiting the physical relationships between temperature, pressure and humidity so a combination that is individually plausible but jointly impossible gets caught; each detection carrying a severity and confidence score with an explanation naming which parameter and which behaviour triggered it, a root-cause classification distinguishing fault types, a slow-drift monitor flagging calibration degradation before it becomes an outright fault, an optional imputed replacement value, and a station health dashboard — with the discipline that a genuine heatwave must pass through unflagged.
Smallest thing that wins the room
Stream a real station's record with injected faults through the system and show a frozen sensor and a spike both caught with explanations, while a genuine heatwave in the same record passes through untouched.
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 44% of the 226 · #128 of 226 by expected field
A normal-sized field. Your idea has to be good, not miraculous.
Why: central ministry statements sat below the average.
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
4/5The sponsor published its own weighted evaluation rubric, which tells you exactly where to spend effort and is close to unheard of, the data is free, anomaly injection is sanctioned, the scope is small enough to complete properly, and the core discrimination between a real extreme and a sensor fault is a genuinely interesting problem rather than a threshold check.
Feasibility
5/5Everything needed is available and the statement removes the usual objections itself — long historical weather station records are freely published worldwide, only three parameters are in scope, and the statement explicitly permits simulated anomalies and states that evaluation will be on anomaly-injected data, so injection is the sanctioned methodology rather than a workaround.
Innovation scope
3/5The objectives, the fault types, the required outputs and the suggested techniques including explainability methods and edge deployment are all enumerated, but how you separate a genuine meteorological extreme from a sensor fault using only three variables is left entirely open and is the real problem.
Clarity
5/5Exceptionally well specified and unusual in publishing its own evaluation rubric with weightages across innovation, detection accuracy, real-time capability, explainability, scalability, deployability, visualisation and energy efficiency, alongside the exact parameters, the fault signatures, the required outputs and a worked example.
Effort
MediumThree parameters, a bounded set of fault types, an explainability layer and a dashboard is a genuinely contained scope by the standards of this portal — the optional edge deployment adds work but the core system is achievable well within the time and can therefore be finished properly rather than stubbed.
Demo-ability
EasyInjecting a fault into a live stream and watching it caught with a stated reason, while a real heatwave in the same record passes through, demonstrates both halves of the problem in one continuous run that any judge follows without explanation.
In its favour
- Green flag: The statement publishes a weighted evaluation rubric down to the percentage, which is close to unheard of — it tells you that innovation and detection accuracy carry nearly half the marks and that visualisation carries five percent, so effort allocation is decided for you
- Green flag: Anomaly injection is explicitly sanctioned and named as the evaluation method, so the usual circularity objection against synthetic faults does not apply here at all
- Green flag: Only three parameters are in scope and the scope is genuinely small, which means unlike almost everything else on this portal you can actually finish and polish rather than stub
- Green flag: Long free historical weather station records are abundant globally, so you can learn realistic seasonal and diurnal normals from real data before injecting anything
Against it
- Red flag: The statement says to use only temperature, pressure and humidity, yet its own worked example resolves the case by comparing against neighbouring stations — that spatial check is the strongest signal available and it sits outside the permitted parameter list, so decide your reading of this and state it explicitly
- Red flag: The central difficulty is that a genuine heatwave and a drifting sensor both look like an out-of-distribution reading, and a detector tuned to catch faults will flag real extreme weather — which for a meteorological agency is a much worse failure than a missed fault
- Red flag: Frozen values are trivially detectable and spikes nearly so, so a submission that catches only those has solved what threshold-based quality control already handles and answered none of the statement's actual motivation
- Red flag: Explainability carries stated weight in the rubric, so an attribution layer bolted on at the end will read as an afterthought against the criterion it was meant to satisfy
What you will be writing
- seasonal-trend decomposition for per-station normals
- multivariate consistency via psychrometric relationships
- isolation forest and autoencoder residual detection
- SHAP attribution for anomaly explanation
- streaming detection with bounded latency
- ESP32 edge deployment of quantised detector
- Sensor data quality control
- Anomaly detection
- Meteorological observation networks
Prior art to read before you start
real-time sensor anomaly detection · distinguishing genuine events from instrument faults · explainable quality control with confidence scoring
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.