WRS Case: Use AI to Find Compressed-Air Leaks, but Measure Repairs, Not Alerts

What the WRS Energie Case Shows

WRS Energie + Druckluft is a German microbusiness focused on compressed-air efficiency. The European Digital Innovation Hubs case lists it as a company with 1–9 employees. WRS combines measurement hardware, engineering audits and the cloud-based AnalyzAir platform, which turns flow, pressure, humidity and compressor-operation data into indicators, alerts and recommendations.

The EDIH record says that more than 100 customers use the solution and that compressed-air efficiency can improve by up to 30%. Those numbers require careful wording: they are vendor-reported outcomes reproduced in an official startup-support case, not an independent audit of one controlled factory deployment. The EDIH engagement itself focused primarily on partnerships, financing and scaling WRS rather than a controlled algorithm comparison.

Independent guidance confirms the scale of the underlying problem. The US Department of Energy sourcebook on compressed-air systems states that leaks can consume 20–30% of compressor output. A poorly maintained plant may lose around 20%, while a systematic detection and repair programme can reduce leakage below 10%.

For a Russian SME manufacturer, the practical conclusion is not to buy one particular foreign service. It is to adopt the workflow: measure a baseline, detect a deviation, turn it into a repair order, verify the repair and only then calculate savings. AI can help inside that loop, but it does not replace the sensor, the maintenance technician or the post-repair measurement.

Why a Leak Detector Alone Is Not Enough

A one-off ultrasonic survey can locate a specific hissing joint, but it does not answer three management questions:

• how much air and money the whole section is losing;
• which deviations return after repairs;
• whether compressor operation changed enough for lower flow to reduce electricity use.

Conversely, a telemetry model may detect a shift in night-time flow or an unusual pressure-to-power relationship without locating the physical point. A working system therefore combines continuous measurements with portable surveys. The algorithm narrows the search area and sets priority, a specialist confirms the location and cause, and the maintenance system tracks closure.

This is a crucial automation boundary. An alert is not an outcome. The outcome appears when the leak is repaired, flow falls in a comparable operating state, pressure remains acceptable, and compressor controls respond efficiently.

Architecture for an On-Premises Setup

The basic design does not need a large language model. At equipment level, it needs an electricity meter for the compressor, pressure and flow sensors and, where relevant, dew-point, temperature and valve-state measurements. Ultrasonic survey findings should be linked to the plant section, equipment identifier and photographs.

The pipeline can then work as follows:

• an industrial gateway reads Modbus, OPC UA or existing controller signals;
• an MQTT broker sends data to a local time-series database;
• a data-quality service rejects impossible values, marks gaps and stores sensor status;
• a calculation layer derives kWh per cubic metre, off-production baseline flow, pressure drop and loaded runtime;
• a model estimates the expected state for the shift, product and temperature;
• deviations pass deterministic duration and impact rules;
• a confirmed signal creates a draft work order in the CMMS or repair log;
• the responsible employee accepts it, records the cause and verifies the result after repair.

An on-premises deployment fits plants where telemetry belongs to a closed operational network, connectivity is unstable, or the company wants direct custody of its equipment history. One factory usually needs only a standard server or industrial PC; time-series analytics rarely requires a GPU. A cloud design may be more convenient across many sites with one analytics team, but outbound traffic, history retention, supplier access and offline operation must then be addressed explicitly.

An LLM can be added at the end to draft a readable shift report or explain which measurements drove a priority score. It should not independently change compressor setpoints or close work orders. Those actions belong behind rules, roles and human approval.

Data the Model Needs

The starting point is not a scarce history of failures but a description of normal operation. The baseline period must cover production shifts, idle time, weekends, different products and seasonal conditions. Every time series should be linked to operating state: running, changeover, stopped or blow-off.

A useful dataset includes:

• active power and state for every compressor;
• pressure before and after key sections;
• flow at the main line and major consumers;
• temperature and dew point when they affect quality;
• shift schedule, output and line state;
• survey, leak, repair and verification records;
• sensor version, calibration date and missing-data indicators.

The first model can be a robust baseline forecast plus residual analysis. It estimates expected flow for the current operating state and raises a signal when actual flow remains above the acceptable band. A more complex algorithm makes sense only after the plant can close such signals and return verified outcomes to the dataset.

Training and validation should be split by time. Randomly mixing adjacent minutes creates an unrealistically easy test. A better approach trains on several weeks and validates on the following period, including shutdowns and production changes.

Economics: Calculate Verified Savings

The WRS claim of “up to 30%” cannot be copied into another plant’s budget. A site-specific baseline comes first. A rough planning model is:

`benefit = power × operating hours × tariff × loss share × repaired share × compressor response factor`.

Consider a hypothetical 90 kW compressor running 6,000 hours per year at RUB 8 per kWh. Assume 20% of output is lost, half of that loss can be removed, and compressor controls convert only 60% of the flow reduction into real electricity savings. The modelled benefit is about RUB 259,000 per year: `90 × 6,000 × 8 × 0.20 × 0.50 × 0.60`.

This is not a forecast or a WRS result; it is an example with explicit assumptions. Sensors, installation, survey work, repairs, support and employee time must still be deducted. The response factor matters because lower air demand does not always reduce electricity use proportionally, especially when compressor controls are not retuned. DOE guidance explicitly recommends reevaluating supply controls after leaks are repaired.

The primary pilot metric is not anomaly count but verified roubles saved per closed work order. Supporting metrics include:

• the share of signals that lead to a confirmed problem;
• time from signal to repair;
• recurrence of the same leak;
• change in off-production baseline flow;
• preservation of required pressure at critical consumers;
• data-collection and human-verification cost.

Limitations and Risks

Higher flow may come from a new pneumatic tool, a blow-off operation, a product change or a failed sensor rather than a leak. Without production context, the model will create false work orders.

Low pressure should not be treated automatically by raising the setpoint; that can hide losses and increase consumption. Any change to compressor controls requires a responsible engineer and verification against equipment requirements.

Another risk is an alert graveyard. If a work order has no owner, deadline, financial estimate and follow-up measurement, analytics only adds another screen. The pilot should be limited to an area where the maintenance team can actually repair defects.

Finally, telemetry reveals plant operating patterns. An on-premises system still needs separate service accounts, OT-network segmentation, access logs and time-series backups. A model should not gain write access to controllers merely because it can read their data.

A Four-Week Practical Pilot

1. Select one compressor circuit and appoint an owner for the economic outcome.
2. Record pressure, flow, power and production state without intervention.
3. Run a night or weekend test and a manual ultrasonic survey.
4. Create a leak register with location, estimated loss, owner and deadline.
5. Repair several priority defects and repeat measurements under comparable load.
6. Only then train a simple baseline-flow model and run it in shadow mode.
7. Decide whether to scale based on verified kWh and money, not an attractive anomaly chart.

If basic metering already reveals an obvious repair list, execute it first. AI becomes valuable where manual surveys miss changes between inspections or where hundreds of signals need prioritisation. Vnutrik may hear every hiss, but paid results begin after the wrench and the verification measurement.