Why AI air monitoring system development gets stuck on data
A classic failure at the start is loss of calibration of stations. An electrochemical sensor drifts away from factory settings over several months, readings shift, but the series remains smooth: no spikes, no breaks that an operator would notice.
A model trained on such a scale reproduces the shift as the norm — and a 'quiet' district looks dirtier than a neighboring one without any grounds.
The second source of errors is gaps in telemetry. A dead battery, a gateway restart, a channel break — and holes appear in the series, which are closed by interpolation during data preparation.
The model stops distinguishing 'no data' from 'clean air', and at the output we get false alarms or, worse, a missed pollution episode.
Next is desynchronization of stations and disparate sources. Local sensors, city stations, and weather reports come with different polling intervals and different timestamps, some with delay.
Until all this is brought to a common time axis and spatial reference, comparing stations with each other and transferring patterns from one to another yields nothing.
Sensor noise and drift, gaps, desynchronization are three different failures, and they are treated differently: cross-checking of stations, a separate 'no data' status instead of interpolation, a unified time grid.
That is why the development of an AI air monitoring system begins not with model selection, but with the data preparation pipeline — we analyze how this is addressed.
What predictive air quality monitoring provides
Threshold signaling triggers when the sensor has already accumulated concentration: we record the peak rather than prevent it.
A predictive model works on the joint behavior of stations, weather series, and the calendar of city events — it reacts to the slope of the curve and pollution transfer from neighboring districts, rather than to a single spike in value.
The share of false alarms drops from 30–40%, typical for rigid thresholds, to single-digit percentages at the same level of detection of real exceedances.
The time to detection of an exceedance is reduced from tens of minutes to 2–5: the signal arrives before the concentration reaches its maximum, and the responsible person has time to act.
The forecast horizon is from several hours to a day, with an expected increase in error toward the end of the window. This is enough to suspend work at a site, change watering and cleaning routes, or warn schools without waiting for confirmation from measurements.
Data completeness after cleaning is a prerequisite, not cosmetics: communication with stations drops, sensors drift between calibrations, some values are outliers from local sources.
The pipeline for validation and recovery of series raises the share of points suitable for training and computation from 70–80% to more than 95%; without it, the model learns from noise and loses accuracy precisely on sharp episodes.
A separate class of failures that cannot be treated in threshold schemes is addressed: a false alarm reduces operator trust, notifications are turned off — and a real exceedance goes unnoticed.
We verify model behavior against independent measurements, including open city archives OpenAQ and data from reference stations, so that metrics remain verifiable rather than declarative.
Methods of data collection and calibration: comparison of approaches
The accuracy ceiling of the entire system is set not by the model but by the input data: an uncalibrated sensor drifts within weeks, and cross-sensitivity to humidity and oxidizers produces false peaks where the background is clean. Below are real collection options that are chosen at the start, and their limits.
| Option | When suitable | Limitations |
|---|---|---|
| Stationary stations | Urban background, control of sanitary zones, long observation series | Cost of site and power limits network density; point coverage |
| Mobile sensors | Street mapping, search for local sources, one-time emissions | Requires geolocation and correction for movement speed; drift is faster |
| Satellite imagery | Large areas, plume transport, multi-year trends | Coarse grid resolution, dependence on cloud cover, only column-integrated concentration |
| Hybrid scheme | Entire city: background, detail by district and mutual verification | More difficult merging of heterogeneous series and building a correction model |
The hybrid scheme works only if there are reference comparison stations: they are used to build correction for readings of cheap sensors, and the calibration model itself is retrained by season and after sensor replacement.
The acceptance criterion here is the share of valid measurements and reproducibility of the daily profile, not the number of points on the map.
Implementation stages: from data audit to pilot operation
Pilot operation is not a one-time model launch, but a sequence of works where each stage leaves a verifiable artifact: a registry of sources, a flow diagram, model configurations, a verification protocol.
The order is important: a model trained on unstudied sources accurately reproduces sensor errors and produces a plausible but incorrect forecast.
- Data source audit. We inventory monitoring stations and external feeds, examine arrival frequency, gaps, calibration drift, duplicates, and discrepancies in units of measurement. The result is a table of source suitability: what goes into the model, what requires verification, and what we exclude.
- Data flow diagram. We describe the path from sensor to storage and data marts: buffering during communication breaks, timestamps, unit conversion, reprocessing of 'late' records. The scheme is agreed upon before model tuning — otherwise features are computed differently in training and in operation.
- Feature preparation and model tuning. We collect historical series, synchronize weather data and calendar, clean outliers. We separately tune the concentration forecast model and the anomaly detection model — they have different sensitivity requirements and different costs of false alarms.
- Backtesting on historical data. We run the models on a holdout period, including episodes with fires, inversions, and equipment failures. We compare with reference measurements and look not at average error but at behavior at peaks — that is where the solution brings value.
- Pilot operation. We launch in parallel with the current monitoring loop, compare alerts with actual events, tune thresholds so that notifications do not turn into noise.
- Handover and team training. We provide documentation, retraining regulations, the procedure for adding new stations, and analysis of typical failures. The customer's engineers perform a typical model update on their own.
Each stage ends with a short demonstration, so discrepancies in data and expectations surface at the beginning of the work, not at launch.
What you are left with after system handover: artifacts and regulations
A working system is not just a service that responds to requests. Along with it, you receive a kit that your team can use to operate, retrain, and develop it without us: from the data flow diagram to regulations defining who and when is authorized to change settings.
- Architecture diagram: the measurement path from sensor to data marts and reports, service boundaries, failure points, and degradation modes — a new engineer can understand it from the document, not from chat.
- Processing pipeline configurations: cleaning, aggregation, and conversion rules, alarm thresholds, schedules — taken out of code, so they can be modified without releasing a new version.
- Data access policies: roles, differentiation by site and measurement types, logging of access, procedure for granting and revoking rights.
- Calibration regulations: frequency of comparison with a reference, drift recording, tolerances and actions when exceeded, person responsible for signing.
- Operating instructions: typical scenarios, diagnostics of gaps in the stream, behavior during degradation of readings, escalation procedure.
- Quality check sets and reference metrics: each retraining is accepted based on them — the model does not go into operation if it has degraded on the control sample.
- Engineering decision log: why these particular thresholds and filters were chosen — during incident analysis, the logic can be restored from the record, not from memory.
The kit is structured so that the system remains manageable without us: pipeline edits do not require a version release, calibration follows regulations, access follows policy.
Case study: city network of stations — from false alarms to forecast
The city network of stations was assembled from stations of different vendors: some reported measurements once an hour, some once every five minutes, and some stations had daily communication outages.
The dispatcher saw a stream in which values could not be compared directly, and threshold rules triggered on any sensor anomaly.
We began merging heterogeneous stations by bringing all measurements to a unified scheme: a common set of indicators, a unified time scale, and an explicit quality flag for each record.
We verified validation against the open archive OpenAQ — this way, real pollution episodes were separated from equipment failures.
What changed on the network
| Metric | Before | After |
|---|---|---|
| False alarms | more than half of alarms — sensor failures | isolated, confirmed by neighboring stations |
| Data completeness | series with gaps, some stations excluded from analysis | almost all stations are suitable for analysis |
| Response time | hours from spike to signal | minutes |
| Exceedance forecast | absent | warning several hours before the episode |
The exceedance forecast relies on a bundle of neighboring stations and weather parameters: if two or three stations in the same zone record a rise, the system issues a warning in advance.
The duty shift has time to notify responsible parties and go to the source instead of analyzing the episode after the fact.
What turned out to be decisive was not equipment replacement but merging: cross-checking of stations gives more than a single accurate sensor. The loop scales to new stations without retraining from scratch — a new station is included in the common validation logic.
What to do if the sensor network is already deployed but the data is dirty?
The network is already installed and running, data goes into reports, decisions depend on it — no one will agree to stop collection to 'redo everything properly'.
At the same time, some stations have drifted calibration, there are hourly gaps somewhere, and different manufacturers have their own time formats and units.
So the first step is to subscribe to the network in read-only mode without changing the working loop.
A second processing layer appears alongside: raw values are written as before, while on top there is validation for gaps, outliers, stuck readings, and drift relative to neighboring stations.
Operation does not stop for even an hour, and each correction is recorded in a log with the rule indicated.
Retrospective cleaning of the archive follows the same rules as the stream. We run history through the same checks and get a unified scale: records from the past period and new data are considered equally and stop contradicting each other.
Original values are stored alongside, so during analysis it is clear what came from the sensor and what was imputed.
Merging heterogeneous data is the most painstaking part. Stations are polled at different frequencies, timestamps come in different time zones, and gas analyzers and dust monitors have incompatible units.
We bring everything to a common time and scale, tie it to weather parameters and reference verification — this way a single peak can be distinguished from a real event, rather than guessing whether it is a failure or an outlier.
Gradual connection reduces risk. We start with one station or sensor type: we look at the share of rejected values and discrepancy with control measurements, and only then expand to the next group.
As a result, the customer gets a clean archive retrospectively and predictable data going forward, without taking any node out of service or stopping monitoring.
Common engineer doubts: answering technical questions
Below are questions most often asked by operations and quality assurance engineers when a solution moves from pilot operation to permanent. For each point there is a working procedure, not a promise: it can be checked on your data before launch.
Is historical data enough if observation stations were installed recently?
A series shorter than a full season does not let the model see annual dynamics.
In this case, training is done on open archives of neighboring territories with transfer to your data, and weather parameters — wind direction and speed, humidity, temperature — work as features linking the external series to yours.
For the first months, the system operates in advisory mode: it marks events, but the decision remains with the operator. As soon as a continuous series of your own is accumulated, the model is retrained on it and switched to operating mode.
How does an outlier differ from an exceedance — will there be false alarms?
These are two different classes of events, and they have different thresholds.
An outlier is a single spike; it is caught by comparison with the median of a sliding window and cross-checking with neighboring stations: a simultaneous rise at several points indicates real transport, while a single peak indicates interference or sensor failure.
An exceedance is a sustained level above the norm during an averaging window specified by regulations. Notifications, logs, and reporting for them are separate, so sensor noise does not go into official summaries.
What happens if a station stops communicating?
Stations transmit telemetry via MQTT, and we monitor not only useful readings but also service ones: power supply voltage, current, air flow through the measurement chamber.
A gap in the series, a frozen level, or an increase in noise puts the station into an unreliable status — it is marked on the map rather than silently distorting the picture.
The model builds an estimate for the area from neighboring stations with adjustment for weather drift and honestly shows the zone where data is insufficient.
Where is data stored and who has access to it?
Raw series, labeling results, and model versions reside in your infrastructure; only an anonymized summary goes outside if needed for publication.
Access is differentiated by roles — operator, analyst, administrator see different things, actions are logged, and access can be revoked without stopping the system. An archive export for regulatory authorities is compiled as a separate report for a specified period.
How often does the model need to be retrained?
Scheduled — by season: sources change, heating modes, prevailing wind direction. Early — due to drift: if quality on the control sample stays below the agreed threshold for several days in a row, training starts automatically.
The model version is fixed, the solution can be rolled back to the previous one, and comparison of two versions on the same segment of history shows what exactly changed.
Let's discuss the task: what to send to get an estimate and a plan
To come back with a timeline estimate and a plan, we do not need a ready technical project — source data and answers to a few questions are enough.
The cost and complexity of an air monitoring system are determined not by the size of the territory, but by the density of stations, the quality of accumulated telemetry, and what pollution decisions are being made today.
- Composition of stations. How many points, where they are located, what sensors are on board (dust, nitrogen dioxide, ozone, carbon monoxide), at what height air is sampled, and how power and communication are provided at the site.
- Telemetry export. A file or access to storage for several months: timestamps with time zone, units of measurement, notes on calibrations and downtime. From this data we assess whether the history is sufficient for training.
- List of monitoring tasks. What the system should do: signal exceedances, build a city-wide pollution map, analyze the likely source, or compute a forecast.
- Forecast requirements. Forecast horizon and step, allowable error over the horizon, for which stations and substances we compute — this determines both the model and the scope of work.
- Reference measurements. Data from a reference station or laboratory measurements — they are used to adjust for humidity and temperature; otherwise, cheap sensors produce bias.
- Procedure for approving stages. Who accepts the result, whether integration with the dispatch center or environmental agencies is needed, whether you are ready for pilot operation on part of the stations before scaling to the entire network.
From this set, a plan is assembled: data preparation, model training and validation, signals to the operator, and regulations for comparison with reference measurements.
Describe the task and send what you already have — we will come back with a timeline estimate and a breakdown of stages.
