Corrector Failure Atlas

Atlas of abnormal situations across the fleet by corrector type — event categories per model with per-node drill-down.

A consolidated map of abnormal situations and event logs across the entire fleet of gas correctors, broken down by device model. The report is for operations and metrology teams: it answers which corrector types experience which faults, how often, and which event logs each model actually reports into the IIoT Platform. This is an “atlas” — it does not rank individual points but shows the overall picture by device type.

What it shows

The main screen is a “corrector model × event category” matrix: the rows are device types, the columns are fault categories, and the cells contain the event count. Any cell is clickable and expands the top points of that model with events of the given category.

Category	What it means
Metrology	Sensors (pressure, temperature) out of operating range, reading substitution
Power / battery	Battery discharge, problems with the device’s power supply
Communications	Session and connection errors, data-exchange failures
Configuration	Changes to device settings, parameter edits

In addition, the report shows a log-coverage map — which models actually have which logs working, and which have no archive by the nature of the device (for example, telemetry units instead of correctors).

How it works

For each corrector type a sample of points is taken, and for each point the available event logs are loaded over the analysis window. Different models name their logs differently, so the report knows which log to request from which model:

Archive type	What this log is
`nesht` / `nesht_svod`	Log of entries into abnormal situations
`changes` / `settings_update`	Log of settings and parameter changes
`alarm` / `fault`	Alarm and fault logs (some models)
`seance`	Communication-session log; communication errors are caught via the session status code

Each event is recognized by the pair “device model + event code” and sorted into one of four categories (metrology, power/battery, communications, configuration). Everything is then consolidated into a “model × category” matrix and a table of the most frequent codes. The correspondence between models and their logs has been confirmed by an actual fleet check, not merely by the devices’ stated documentation.

Run parameters

Parameter	Default	What it means
Event window, days	30	Event-collection window, in days
Nodes per corrector type (sample)	50	How many points per corrector type to sample (for speed)
Parallel fetch workers	8	Number of parallel download threads
Utility company (fleet filter)	from context	Filter by organization (utility / DSO)

How to read the result

Compare models against one another: if one corrector type has sharply more events in the “metrology” or “communications” category than the rest, that is grounds to take a closer look at the model as a whole. Clicking a cell brings up the specific points where you can dig in further.

What to keep in mind:

The report is built on a sample, not the whole fleet. For a model with a thousand points a sample is taken (50 by default), so the numbers indicate the scale of the phenomenon rather than an exact count across all points.
Not all devices report abnormal-situation logs. If a model’s matrix is empty, this may mean either an absence of faults or that it has no such log by the nature of the device — the log-coverage map explains this.