Custom AI System for Environmental Monitoring

We design and deploy artificial intelligence systems: from prototype to production-ready solutions. Our team combines expertise in machine learning, data engineering and MLOps to make AI work not in the lab, but in real business.
Showing 1 of 1All 1564 services
Custom AI System for Environmental Monitoring
Medium
~1-2 weeks
Frequently Asked Questions

AI Development Areas

AI Solution Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1360
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    957
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1188
  • image_logo-advance_0.webp
    B2B Advance company logo design
    646
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    929

Custom AI System for Environmental Monitoring

We've seen industrial plants exceed allowable concentration limits while their monitoring systems lagged by a full day, making timely response impossible. Our AI environmental monitoring system solves this: it integrates data from stationary posts, satellites, and low-cost sensors in real time, predicts pollution 72 hours ahead, and automatically alerts when thresholds are breached.

The core principle is to cut reaction time from a day to 15 minutes. This is achieved through a combination of IoT networks, predictive models, and integration with state information systems (FGIS "Industry", AIS "Industrial Ecology"). Our track record: 10+ years in AI monitoring, over 40 implementations at industrial facilities.

Why an AI System Outperforms Classical Stations

Traditional Rosgidromet stations provide accurate but sparse readings (every 20 minutes or less). Manual sampling adds hours of delay. Our AI solution merges heterogeneous sources:

  • Stationary posts (high accuracy, low density)
  • Low-cost sensors (low accuracy, high density) — calibrated against reference stations
  • Satellite imagery (Sentinel-5P, MODIS) — global coverage every 1-2 days

We use a hybrid architecture: sensor data is first calibrated against reference stations, then spatially interpolated (Kriging) and time-forecasted using LSTM. The result is a pollution map with 1 km resolution and a 3-day forecast.

How We Build the Data Collection Infrastructure

The infrastructure has three tiers: field devices, on-site aggregation, and cloud analytics.

Low-cost sensors form a dense network. We use Plantower PMS7003 and Sensirion SPS30 for PM2.5/PM10, Alphasense NO2-BE for NO2. Typical node cost is $50–200, 100 times cheaper than a professional station. Accuracy is lower, but after calibration using the method below, error drops to 15–20%.

def calibrate_low_cost_sensor(low_cost_readings, reference_readings, method='linear'):
    """Calibrate LCS against nearest reference station"""
    if method == 'linear':
        model = LinearRegression().fit(low_cost_readings, reference_readings)
        return model  # apply to future LCS data
    elif method == 'rf':
        model = RandomForestRegressor().fit(low_cost_readings, reference_readings)
        return model

Satellite data (Sentinel-5P, Landsat, MODIS) provides global coverage and detects anomalies (fires, emissions).

What Predictive Models We Use

We apply two approaches: deterministic dispersion models (Gaussian plume, AERMOD) and machine learning for time series.

Air quality forecast — LSTM with 24-hour time series of PM2.5 from all regional stations plus weather forecast (NWP). The model outputs a 24/48/72-hour forecast for each grid cell.

# LSTM + spatial interpolation
# State: 24-hour PM2.5 time series from all stations in region
# + NWP weather forecast (wind, temperature, atmospheric mixing)
# Output: PM2.5 for next 24/48/72 hours for each grid cell

model = StackedLSTM(
    input_size=n_stations * n_pollutants + n_meteo_vars,
    hidden_size=128,
    forecast_hours=72
)

Dispersion models (Gaussian plume) — given a known emission source, they calculate the pollution zone. We use AERMOD (regulatory model from US EPA) and its Russian counterpart OND-90. ML adjustments boost accuracy by 30% over purely deterministic models.

Source detection — an inverse problem: determine source coordinates from concentration distribution. We use optimization and convolutional networks (encoder of the concentration field image → coordinates).

Case Study: Reducing Response Time for a Chemical Plant

At a chemical plant in the Moscow region, the existing monitoring used manual sampling with a 24-hour delay. After deploying our system with 40 low-cost sensors and a single reference station, we achieved real-time readings. Within two weeks, the LSTM model was predicting PM2.5 spikes 6 hours ahead with 85% accuracy. When a batch process released excess NO2, the system alerted the plant manager within 2 minutes, allowing immediate corrective action. The plant avoided a fine of 2 million RUB and reduced average exceedance duration from 18 hours to 30 minutes.

Alerting and Reporting

Air quality indices: Russian AQI, WHO 2021 Guidelines, AQI USA. Mapping table:

Index PM2.5 (µg/m³) Hazard Level Color
AQI <3 Low Green
AQI 3–10 Moderate Yellow
AQI 10–25 High Orange
AQI >25 Very High Red

Automatic alerts:

  • MPC exceedance → SMS to public + mobile app
  • NDE exceedance → notification to Rosprirodnadzor
  • Emergency release → EMERCOM + plant

Regulatory compliance: Federal Law 174, Government Decree 205, Ministry of Natural Resources Order 522. Integration with FGIS "Industry" and regional GIS.

What's Included in the Work

When you order an AI environmental monitoring system, we provide:

  • Site survey and equipment selection
  • Architecture design for data collection and storage
  • Low-cost sensor calibration and network deployment
  • Predictive model building (LSTM, Gaussian plume)
  • Integration with state reporting systems
  • Dashboards and alert system
  • Documentation, staff training, and 1-month support
More on system components

The system can include additional modules: mobile app for the public, integration with enterprise BIM models, automatic reporting to Rosprirodnadzor. Timelines and cost depend on module composition.

Timelines and Cost

Basic system (IoT monitoring + visualization + AQI forecast) — 8–10 weeks. Full platform (source attribution, regulatory reporting, alerting) — 5–6 months. Cost is calculated individually after site audit. We guarantee compliance with Federal Law 174. Over 10 years of experience in environmental monitoring systems.

Evaluate your project in 1 day — just contact us. Get a consultation on implementing AI environmental monitoring.

When does a time series forecasting model fail in production?

The CFO requests a quarterly sales forecast. An analyst builds SARIMA on three years of data, achieves MAPE 8.3% on the test set, and deploys. Two months later, the metric in production jumps to 23%. The root cause: the model was trained on pre‑COVID data, tested on a stable period, but production hit a promotion and supply chain disruption. Data leakage plus distribution shift—perfect notebook numbers, a broken forecast in reality. We have seen this pattern dozens of times across retail, fintech, and IoT. Our team has delivered more than 50 forecasting projects over 5+ years.

Incorrect cross-validation. Standard train_test_split for time series creates data leakage: the model sees future values during training. The correct approach is TimeSeriesSplit or walk‑forward validation with an expanding window.

Multiple seasonality. Hourly electricity consumption has three seasonalities: daily (24h), weekly (168h), yearly (8760h). SARIMA handles only one. Prophet can handle multiple but scales poorly to thousands of series.

Missing values and anomalies. A missing sensor reading is information (the sensor turned off), not NaN. Linear interpolation destroys this signal. Proper handling depends on the missingness mechanism.

Cold start. A new SKU in a 50,000‑item assortment has no history, yet a forecast is needed. Standard approaches fail; cross‑learning or feature‑based methods are required.

Why is model selection critical for your data?

Prophet (Meta) – a solid start for business data with clear seasonality and holidays. Fast setup, interpretable, built‑in outlier detection. Fails on irregular patterns and does not scale beyond ~10k series without parallelization.

Gradient boosting on features (LightGBM, XGBoost) – often underestimated. Engineer lags (t‑1, t‑7, t‑28), rolling means, day‑of‑week, holidays. The model trains on all series simultaneously, solving cold start via transfer learning. MAPE in retail often beats neural nets with proper feature engineering.

TFT (Temporal Fusion Transformer) – a transformer designed for interpretable forecasting with covariates. Built‑in variable selection, temporal attention, quantile outputs. Available in pytorch‑forecasting. Requires ~10,000+ records per series for stable training.

PatchTST – splits the series into patches (like ViT for images), capturing local patterns better than classic transformers. Excellent for long‑horizon forecasting (96–720 steps ahead).

N‑HiTS, N‑BEATS – attention‑free neural architectures, faster than TFT, competitive accuracy. N‑BEATS won the M4/M5 benchmarks for tasks without covariates.

Method Covariates Scale (series) Interpretability Complexity
Prophet Yes (regressors) Up to 10k High Low
LightGBM + features Yes 100k+ Medium Medium
TFT Yes 1k–100k High High
PatchTST No/limited Any Low Medium
N‑HiTS No Any Low Low

How do we deploy TFT in production?

A typical pipeline via pytorch‑forecasting:

training = TimeSeriesDataSet(
    data,
    time_idx="time_idx",
    target="sales",
    group_ids=["store", "sku"],
    min_encoder_length=max_encoder_length // 2,
    max_encoder_length=max_encoder_length,  # 120 days
    min_prediction_length=1,
    max_prediction_length=max_prediction_length,  # 28 days
    static_categoricals=["store_type", "category"],
    time_varying_known_reals=["price", "promo_flag"],
    time_varying_unknown_reals=["sales"],
    target_normalizer=GroupNormalizer(groups=["store", "sku"], transformation="softplus"),
)

A common mistake: the default target_normalizer (StandardScaler) breaks predictions for series with zero values (no sales on weekends). GroupNormalizer with transformation="softplus" is the correct choice for count data.

Case study: retail demand forecasting

A chain of 120 stores, 8,000 SKUs, 28‑day forecast horizon. The original system: SARIMA per series, MAPE 18.4%, retraining cycle – 6 hours. We replaced it with TFT on PyTorch + pytorch‑forecasting: a single model for all series, MAPE 11.2%, retraining – 40 minutes on an A10G. Feature importance via variable selection revealed that day_before_holiday influences more than the holiday date itself. Annual savings on inference alone exceeded $50,000.

Step‑by‑step configuration

  1. Data collection and preparation. Handle missing values (mark NaN, interpolate only for technical failures), aggregate to required frequency, engineer covariates (holidays, promotions, prices).
  2. Create TimeSeriesDataSet. Set group_ids (store + SKU), time index, forecast horizon. Choose target_normalizer based on target distribution.
  3. Train a baseline. Prophet or LightGBM first – to understand complexity.
  4. Train TFT. Use TemporalFusionTransformer with loss=QuantileLoss(), tune learning rate and hidden layer sizes.
  5. Validate and interpret. Walk‑forward test, analyze variable selection, build attention heatmaps.

How to properly evaluate forecast quality?

RMSE alone is misleading – it over‑penalizes large values. Our standard set:

  • MAPE – interpretable, unstable near zero.
  • sMAPE – symmetric, avoids division by small numbers.
  • MASE (Mean Absolute Scaled Error) – normalized relative to a naive seasonal forecast, ideal for comparing series of different scales.
  • Pinball loss – for probabilistic forecasting, inventory management.
Metric When to use Drawback
MAPE Business reporting, series without zeros Unstable for small values
sMAPE Model comparison Asymmetric interpretation
MASE Multi‑scale series, benchmarks Needs seasonal naive baseline
Pinball loss Probabilistic models Multiple values for different quantiles

We guarantee a model card with these metrics on the validation set and walk‑forward results on at least 6 months of history.

What deliverables do you receive?

  • Documentation of chosen architecture and hyperparameter rationale.
  • Reproducible training and inference pipeline (Docker + CI/CD + Airflow/Prefect).
  • Committed code with unit tests for key components.
  • Team training: retraining, output interpretation, deployment of new versions.
  • 3 months of post‑delivery support (consultations, bug fixes, fine‑tuning).

The model is deployed via FastAPI or Triton Inference Server. Retraining is scheduled (e.g., weekly) via Airflow with drift validation and automatic rollback if metrics deteriorate.

Process and timeline

We start with EDA: visualization, ADF test, STL decomposition, analysis of missing values and outliers. This takes 2–3 days but often reveals systemic data issues that block forecasting. Then we build a baseline (naive seasonal, Prophet), engineer features for LightGBM, and select a neural architecture if needed. Walk‑forward validation with a realistic horizon. Deployment via API with automatic retraining scheduled via Airflow or Prefect.

Timeline: MVP forecast on one data type – 3–6 weeks. Hierarchical forecasting system with automation – 2–5 months. Cost is calculated individually based on data volume, number of series, and required accuracy.

Our team consists of certified ML engineers (AWS ML Specialty, GCP Professional ML Engineer) with 5+ years on the market and over 50 completed forecasting projects. Contact us for a free analysis of your data – we will assess the task and provide initial recommendations within 1–2 days. Request a consultation to ensure your forecasts work in production, not just in a notebook.