---
title: 'Аномально довгі сеанси'
description: Вузли парку, чиї сеанси звʼязку тривають аномально довго відносно власної норми, з індивідуальними IQR-порогами на вузол, оцінкою серйозності та аналізом кореневих причин на основі інцидентів.
section: AI Analytics
weight: 7
related:
- ai-analytics/fleet-reports/events-explorer
---
import Alert from '@/components/docs/Alert.astro';
import Image from '@/components/docs/Image.astro';
Звіт **«Аномально довгі сеанси»** аналізує телеметричні сеанси звʼязку по всьому парку вузлів обліку та виявляє пристрої, локації, дні й типи коректорів, де звʼязок працює нестабільно або потребує надмірно довгого часу для передачі даних.
Шапка звіту містить сім KPI: компанія, охоплення парку, готовність даних, кількість вузлів з аномаліями, кількість аномальних сеансів, максимальна тривалість сеансу, загальна кількість часових інцидентів і період аналізу. Головне число — це кількість вузлів з аномаліями із загальної кількості вузлів парку; інциденти — це часові кластери, де пʼять або більше вузлів мають довгі сеанси одночасно.
Звіт відповідає на практичні питання експлуатації:
- які вузли мають занадто довгі сеанси звʼязку;
- які сеанси вважаються аномальними саме для цього вузла;
- де проблема локальна: антена, SIM-карта, живлення, модем, місце встановлення;
- де проблема схожа на інцидент базової станції або оператора мобільної мережі;
- чи є масові часові інциденти на парку;
- які дні були найбільш проблемними;
- які типи коректорів частіше потрапляють у довгі сеанси;
- скільки енергії орієнтовно витрачено на повторні або подовжені передачі;
- які вузли потребують виїзду із зовнішньою антеною, репітером або перевіркою SIM;
- де потрібно перевіряти оператора мобільної мережі або якість покриття в конкретній локації.
Звіт не оцінює коректність комерційного обліку газу і не є forensic-звітом з обходу обліку. Він
аналізує лише сеанси звʼязку: тривалість, частоту аномалій, масштаб інцидентів, якість сигналу та
ймовірну причину довгих сеансів.
## Місце звіту в системі
Звіт належить до експлуатаційної діагностики телеметрії. Він не повинен змішувати дві різні ситуації:
1. **Немає звʼязку взагалі.** Вузол не виходить на звʼязок, даних немає.
2. **Звʼязок є, але сеанси занадто довгі.** Вузол передає дані, але робить це повільно, нестабільно або з повторними спробами.
Цей звіт аналізує **другу** ситуацію. Там, де звʼязку, архіву чи даних немає взагалі, використовуйте звіт Top Problem Nodes; там, де потрібно перевірити, чи придатні дані одного вузла для обліку, використовуйте Consumption Analytics.
## Для кого призначений звіт
| Роль | Що отримує зі звіту |
| ------------------------ | ------------------------------------------------------------------------------- |
| Керівник експлуатації | загальна картина по парку, кількість вузлів з аномаліями, масові інциденти |
| Інженер звʼязку | список вузлів з поганим RSSI, довгими сеансами і локальними проблемами |
| Диспетчер | пріоритетний список заявок і проблемних днів |
| Виїзна бригада | топ-вузли для перевірки антени, SIM, живлення і місця встановлення |
| Інженер інтеграції | діагностика готовності даних, API-покриття та випадки відсутності даних сеансів |
| Закупівельний спеціаліст | порівняльний розріз за типами коректорів |
| Аналітик парку | RCA-гіпотези: базова станція, оператор, прошивка, локальний вузол |
## Що звіт не робить
Звіт не повинен:
- доводити несправність конкретного модема без виїзду;
- вважати довгий сеанс прямим доказом поганого приладу;
- автоматично звинувачувати сервер або оператора мобільної мережі;
- змішувати «немає даних» з «немає аномалій»;
- порівнювати тривалість сеансів усіх вузлів одним загальним порогом;
- вважати короткий період з малою кількістю сеансів статистично надійним;
- робити висновок про якість моделі приладу без урахування кількості пристроїв у вибірці;
- замінювати радіотехнічне обстеження місця встановлення;
- вважати оцінку втрати батареї точним вимірюванням;
- використовувати AI-коментар як джерело діагностики.
## Основні терміни
| Термін | Значення |
| ----------------- | ----------------------------------------------------------------------------------- |
| Сеанс звʼязку | один епізод зʼєднання пристрою із системою передачі даних |
| Тривалість сеансу | час від початку до завершення сеансу |
| Нормальний сеанс | сеанс, тривалість якого знаходиться в індивідуальній нормі вузла |
| Довгий сеанс | сеанс, тривалість якого перевищує індивідуальний IQR-поріг вузла |
| `IQR` | міжквартильний розмах: `Q3 − Q1` |
| `Q1` | перший квартиль тривалостей сеансів |
| `Q3` | третій квартиль тривалостей сеансів |
| `UpperFence` | верхня межа норми: `Q3 + 1.5 × IQR` |
| `RSSI` | рівень радіосигналу, dBm |
| `CSQ` | індекс якості сигналу GSM, може бути перерахований у dBm |
| `Btm` | напруга батареї або показник живлення пристрою |
| `Long share` | частка довгих сеансів серед усіх сеансів вузла |
| `Severity score` | підсумкова оцінка проблемності вузла за довгими сеансами |
| Інцидент | часовий кластер, де довгі сеанси зʼявилися одразу у кількох вузлів |
| `RCA` | аналіз ймовірної причини: базова станція, мережа, сервер, прошивка, локальний вузол |
| `Battery loss` | орієнтовна оцінка енергії, витраченої на зайву тривалість передачі |
## Загальна логіка звіту
Звіт будується як парковий аналіз сеансів звʼязку.
```text
Список вузлів парку
→ отримання сеансів звʼязку
→ перевірка готовності даних
→ індивідуальна норма сеансів для кожного вузла
→ пошук довгих сеансів за IQR
→ розрахунок score по кожному вузлу
→ групування довгих сеансів у часові інциденти
→ визначення ймовірної причини RCA
→ розподіл гіпотез по вузлах
→ топ проблемних вузлів
→ розріз за типами коректорів
→ розріз за днями та місяцями
→ рекомендації для експлуатації
```
Головний принцип:
```text
довгий сеанс визначається відносно норми конкретного вузла,
а не відносно загального фіксованого порогу по всьому парку.
```
Це важливо, оскільки різні прилади, регіони, оператори мобільних мереж та режими опитування можуть мати різні нормальні тривалості сеансів.
## Параметри запуску
| Параметр | Значення |
| ----------------------------------- | ------------------------------------------------------------------------------------------- |
| Дата з / Дата по | межі вікна аналізу |
| Вікно аналізу, днів | резервне вікно, що використовується, коли дати порожні (за замовчуванням 30) |
| Вузлів на тип коректора | розмір вибірки на тип; `0` означає всі вузли парку |
| Мінімум сеансів на вузлі для IQR | мінімальна кількість сеансів, яку вузол має мати, щоб кваліфікуватися (за замовчуванням 30) |
| Кількість проблемних вузлів у звіті | розмір таблиці топ-N (за замовчуванням 50) |
| LLM-аналіз | опціональний AI-наратив, що пояснює результати |
| Компанія-постачальник | обмежує аналіз парком одного постачальника |
## Вхідні дані
### Основні дані
| Дані | Для чого потрібні |
| --------------------- | ----------------------------------------------------------- |
| Список вузлів | визначити парк аналізу |
| Тип коректора | побудувати розріз за моделями |
| `Equipment ID` | отримати сеанси конкретного пристрою |
| Сеанси звʼязку | основа звіту |
| Час початку сеансу | групування за днями, місяцями та годинами |
| Тривалість сеансу | головний аналізований показник |
| `RSSI` / `CSQ` | оцінка якості радіосигналу |
| `Btm` / батарея | оцінка впливу живлення |
| Організація / локація | атрибуція інциденту: локальний клієнт, базова станція, парк |
### Мінімально необхідний набір
Для коректного аналізу вузла потрібні:
- ідентифікатор пристрою;
- не менше мінімальної кількості сеансів;
- тривалість кожного сеансу;
- timestamp кожного сеансу.
Якщо тривалість сеансу відсутня, такий сеанс не бере участі в IQR-аналізі.
## Готовність даних: data-gate
Перед розрахунком аномалій звіт перевіряє, чи можна взагалі виконувати аналіз. Блок готовності даних показує розмір парку, розмір після фільтра за компанією, скільки вузлів віддали дані сеансів і скільки з них пройшли мінімум сеансів для IQR. Це **критично важлива** діагностика — без неї легко сплутати «немає аномалій» з «немає даних для аналізу».
### Основні показники готовності
| Показник | Формула / значення |
| ---------------------------------- | -------------------------------- |
| Вузлів у парку | `N_park` |
| Вузлів у вибірці | `N_sampled` |
| Вузлів з даними сеансів | `N_with_data` |
| Вузлів, що пройшли мінімум сеансів | `N_qualified` |
| Усього сеансів | `N_sessions` |
| API-викликів | `N_calls` |
| API-помилок | `N_errors` |
| Частка API-помилок | `N_errors / N_calls × 100%` |
| Покриття даними | `N_with_data / N_sampled × 100%` |
| Покриття IQR-вибіркою | `N_qualified / N_sampled × 100%` |
### Частка API-помилок
$$
APIErrorRate =
\frac{N_{errors}}{N_{calls}} \times 100\%
$$
### Покриття даними
$$
Coverage_{with\_data} =
\frac{N_{with\_data}}{N_{sampled}} \times 100\%
$$
### Покриття вузлами, придатними для IQR
$$
Coverage_{qualified} =
\frac{N_{qualified}}{N_{sampled}} \times 100\%
$$
### Статуси готовності
| Статус | Умова | Що означає |
| -------------- | ------------------------------------------- | ----------------------------------- |
| `OK` | є достатня вибірка для IQR | звіт можна читати як робочий |
| `DEGRADED` | вибірка мала, але аналіз можливий | висновки обережні |
| `INCONCLUSIVE` | помилок багато або покриття критично низьке | висновки за аномаліями недостовірні |
| `NO_DATA` | немає даних сеансів | аналіз неможливий |
| `NO_FLEET` | після фільтра немає вузлів | нічого аналізувати |
### Критичні умови
Аналіз вважається неможливим, якщо:
$$
APIErrorRate \ge 50\%
$$
або:
$$
Coverage_{with\_data} < 5\%
$$
або:
$$
N_{qualified} = 0
$$
«Немає аномалій» і «немає даних для аналізу» — різні стани. Якщо дані сеансів відсутні, звіт не
повинен писати, що аномалій не знайдено.
## Мінімум сеансів на вузлі
Для надійного IQR-аналізу кожен вузол повинен мати достатню кількість сеансів.
### Мінімальний поріг
За замовчуванням:
$$
N_{sessions,station} \ge 30
$$
Якщо у вузла менше сеансів, індивідуальна норма вважається статистично ненадійною, і вузол не проходить IQR-фільтр.
### Чому потрібен мінімум
IQR використовує квартильні оцінки. При малій кількості спостережень квартиль стає нестабільним:
- один випадковий довгий сеанс може завищити поріг;
- один короткий період звʼязку може занизити поріг;
- неможливо відрізнити норму вузла від випадковості.
## Індивідуальна норма тривалості сеансу
### Чому норма індивідуальна
Не можна використовувати один загальний поріг для всього парку, наприклад «усі сеанси більше 10 хвилин погані». У різних вузлів різні умови звʼязку:
- різні типи коректорів;
- різні оператори мобільних мереж;
- різний RSSI;
- різні обсяги архіву;
- різні розклади опитування;
- різні місця встановлення;
- різні антени.
Тому для кожного вузла розраховується власна статистична норма.
### Відбір валідних тривалостей
Для кожного вузла беруться лише додатні тривалості:
$$
D = \{d_i \mid d_i > 0\}
$$
де:
- `d_i` — тривалість i-го сеансу в секундах.
### Квартилі
Тривалості сортуються за зростанням.
$$
D_{sorted} = sort(D)
$$
Перший квартиль:
$$
Q1 = percentile(D, 25\%)
$$
Медіана:
$$
Q2 = median(D)
$$
Третій квартиль:
$$
Q3 = percentile(D, 75\%)
$$
### Міжквартильний розмах
$$
IQR = Q3 - Q1
$$
### Верхня межа норми за правилом Tukey fence
Для кожного вузла розраховується індивідуальна верхня межа норми:
$$
UpperFence = Q3 + 1.5 \times IQR
$$
Це класичне правило Tukey fences для виявлення викидів.
### Довгий сеанс
Сеанс вважається аномально довгим, якщо:
$$
d_i > UpperFence
$$
де:
- `d_i` — тривалість сеансу;
- `UpperFence` — індивідуальний поріг цього вузла.
Якщо у вузла зазвичай сеанси короткі, його поріг буде низьким. Якщо у вузла зазвичай сеанси довші,
його поріг буде вищим. Звіт виявляє саме аномалію **відносно власної норми вузла**.
## Базові показники вузла
Для кожного вузла розраховуються такі показники.
### Загальна кількість сеансів
$$
N_{total} = count(D)
$$
### Кількість довгих сеансів
$$
N_{long} = count(d_i > UpperFence)
$$
### Частка довгих сеансів
$$
Pct_{long} =
\frac{N_{long}}{N_{total}} \times 100\%
$$
### Середня тривалість усіх сеансів
$$
AvgDuration =
\frac{\sum d_i}{N_{total}}
$$
### Середня тривалість довгих сеансів
$$
AvgLongDuration =
\frac{\sum_{d_i > UpperFence} d_i}{N_{long}}
$$
### Максимальна тривалість
$$
MaxLongDuration =
max(d_i \mid d_i > UpperFence)
$$
### Середній RSSI
$$
RSSI_{avg} =
\frac{\sum RSSI_i}{N_{RSSI}}
$$
де `N_RSSI` — кількість сеансів із доступним значенням RSSI.
## Score проблемності вузла
### Сенс score
Score показує, наскільки вузол проблемний за довгими сеансами. Він враховує три виміри:
1. **частку довгих сеансів**;
2. **наскільки довгі сеанси перевищують норму**;
3. **абсолютну кількість довгих сеансів**.
Такий підхід дозволяє не переоцінювати поодинокий викид і не недооцінювати вузол із великою кількістю помірно довгих сеансів.
### Компонент A — частка довгих сеансів
$$
A =
min(100,\;4 \times Pct_{long})
$$
Інтерпретація:
| Частка довгих | A |
| ------------: | --: |
| 5% | 20 |
| 10% | 40 |
| 25% | 100 |
| >25% | 100 |
### Компонент B — відносна тривалість
$$
B =
min
\left(
100,\;
8 \times \frac{AvgLongDuration}{max(1, MedianDuration)}
\right)
$$
де `MedianDuration` — медіанна тривалість сеансу вузла.
Інтерпретація:
| AvgLong / Median | B |
| ---------------: | --: |
| 2× | 16 |
| 5× | 40 |
| 10× | 80 |
| 12.5× | 100 |
### Компонент C — кількість довгих сеансів
$$
C =
min(100,\;N_{long})
$$
Тобто 100 і більше довгих сеансів дають максимальний внесок за цим компонентом.
### Підсумковий score
$$
Score =
0.5 \times A
+
0.3 \times B
+
0.2 \times C
$$
де:
- `A` — частка довгих сеансів;
- `B` — відносна тривалість довгих сеансів;
- `C` — абсолютна кількість довгих сеансів.
Підсумковий score обмежується діапазоном:
$$
0 \le Score \le 100
$$
### Інтерпретація score
| Score | Рівень |
| ----: | --------------------------------- |
| ≥ 80 | критичний вузол звʼязку |
| 60–80 | високий пріоритет |
| 40–60 | середній пріоритет |
| 20–40 | спостереження / планова перевірка |
| < 20 | слабкий сигнал |
Score не доводить причину. Високий score говорить, що вузол часто та/або сильно перевищує свою
норму тривалості сеансів. **Причина визначається окремо через RCA.**
## Оцінка втрати батареї на довгих сеансах
### Сенс
Довгий сеанс збільшує час передачі і може додатково витрачати батарею. Звіт дає **орієнтовну** оцінку зайвої витрати енергії. Це не точне вимірювання батареї, а експлуатаційна оцінка.
### Зайвий час передачі
Для кожного довгого сеансу розраховується перевищення над медіанною нормою вузла:
$$
ExtraTime_i =
max(0,\;d_i - MedianDuration)
$$
Сумарний зайвий час:
$$
ExtraTime_{total} =
\sum_{i \in LongSessions} ExtraTime_i
$$
### Струм передачі
Для наближеної оцінки використовується базовий струм передачі:
$$
I_{TX} = 340 \; mA
$$
### Втрати батареї
$$
BatteryLoss_{mAh} =
\frac{I_{TX} \times ExtraTime_{total}}{3600}
$$
де:
- `ExtraTime_total` — у секундах;
- `I_TX` — струм у міліамперах;
- результат — у mAh.
Для відображення в Ah:
$$
BatteryLoss_{Ah} =
\frac{BatteryLoss_{mAh}}{1000}
$$
### Обмеження
Ця оцінка не враховує:
- реальний профіль струму конкретної моделі;
- режим сну;
- retries на рівні модема;
- потужність передавача;
- температуру;
- вік батареї;
- ємність батареї;
- якість мережі в момент передачі.
Тому її потрібно читати як **оцінку масштабу**, а не як лабораторне вимірювання.
## RSSI та CSQ
### RSSI
`RSSI` показує рівень радіосигналу в dBm. Чим ближче значення до нуля, тим сильніший сигнал.
Приблизна інтерпретація:
| RSSI | Оцінка |
| ----------: | -------------- |
| ≥ −65 dBm | хороший сигнал |
| −65…−75 dBm | прийнятний |
| −75…−85 dBm | слабкий |
| < −85 dBm | дуже слабкий |
### CSQ
Деякі пристрої передають не RSSI у dBm, а `CSQ` — індекс якості GSM-сигналу. Якщо значення схоже на CSQ, його можна перерахувати:
$$
RSSI_{dBm} =
-113 + 2 \times CSQ
$$
Приклад:
$$
CSQ = 29
$$
$$
RSSI = -113 + 2 \times 29 = -55 \; dBm
$$
### Локально слабкий сигнал
Якщо:
$$
RSSI_{avg} < -85 \; dBm
$$
і аномалії вузла не збігаються з масовими парк-інцидентами, причина може бути класифікована як:
```text
weak signal at the installation site
```
## Групування довгих сеансів в інциденти
Аномалії групуються за часовими вікнами. Якщо в одній годині одразу кілька вузлів отримали довгі сеанси — це **не локальна проблема вузла**, а інцидент мережі, сервера або оператора. Гіпотеза визначається автоматично за шириною охоплення — кількістю вузлів, моделей і клієнтів у вікні.
### Навіщо потрібне групування
Якщо в одній і тій самій годині довгі сеанси зʼявилися одразу у багатьох вузлів, це, найімовірніше, не локальна проблема одного приладу. Це може бути:
- проблема базової станції;
- локальне перевантаження оператора;
- масовий мережевий інцидент;
- регламентна серверна операція;
- особливість прошивки певної моделі.
### Часовий кошик
Кожен довгий сеанс поміщається в часовий кошик:
$$
Bucket(t) =
floor\left(
\frac{t}{1h}
\right) \times 1h
$$
Тобто всі події всередині однієї години потрапляють в один кошик.
### Інцидент
Часовий кошик вважається інцидентом, якщо в ньому зачеплено не менше:
$$
N_{stations,bucket} \ge 5
$$
вузлів.
### Показники інциденту
Для кожного інциденту розраховуються:
| Показник | Формула |
| ---------------------------- | -------------------------------- |
| кількість вузлів | `count(unique station_id)` |
| кількість моделей | `count(unique equipment_type)` |
| кількість клієнтів / локацій | `count(unique customer_id)` |
| кількість сеансів | `count(long sessions in bucket)` |
| середній RSSI | `average(RSSI)` |
| топ моделей | `top equipment types by count` |
## RCA: атрибуція причини інциденту
Зведення по парку визначає головного винуватця — вишку базової станції, сервер, мережу, прошивку чи локальний вузол — дає атрибуцію провини за вузлами з аномаліями та формує план дій. Опціональний AI-наратив унизу пояснює числа простою мовою, але не змінює їх.
RCA — це класифікація ймовірної причини довгих сеансів.
### Можливі гіпотези
| Гіпотеза | Сенс |
| ----------------- | ----------------------------------------------- |
| `Server driver` | масовий збій драйвера збирання |
| `Server routine` | регулярна серверна операція або обслуговування |
| `Network outage` | збій оператора мобільної мережі |
| `Cell tower` | проблема конкретної базової станції або локації |
| `Firmware` | проблема моделі пристрою / прошивки |
| `Local signal` | слабкий сигнал у місці встановлення |
| `Battery low` | низьке живлення / деградація батареї |
| `Isolated device` | локальна несправність конкретного вузла |
| `Mixed causes` | змішані причини |
### Широкий серверний інцидент
Інцидент класифікується як серверний, якщо одночасно зачеплено багато вузлів, багато моделей і багато клієнтів. Умовно:
$$
N_{stations} \ge ServerWideStations
$$
$$
N_{models} \ge ServerWideModels
$$
$$
N_{customers} \ge ServerWideCustomers
$$
У звіті це означає:
```text
wide fleet incident, not similar to a local single-node problem.
```
### Мережевий збій оператора
Якщо зачеплено кілька моделей і кілька клієнтів, але масштаб не дотягує до серверного збою:
$$
N_{models} \ge 3
$$
і:
$$
N_{customers} \ge 3
$$
то гіпотеза:
```text
mobile network failure / operator incident
```
### Проблема базової станції
Якщо зачеплено багато вузлів, але вони належать до однієї або двох локацій / клієнтів:
$$
N_{customers} \le 2
$$
і:
$$
N_{stations} \ge CellMinStations
$$
то гіпотеза:
```text
base station problem or local coverage problem
```
### Проблема прошивки або моделі
Якщо зачеплено одну модель, але різних клієнтів:
$$
N_{models} = 1
$$
і:
$$
N_{customers} \ge 3
$$
то гіпотеза:
```text
firmware / device model peculiarity
```
### Змішані причини
Якщо умови не дають однозначної класифікації, інцидент отримує статус:
```text
mixed causes
```
## Повторювана серверна рутина
Іноді масові серверні інциденти відбуваються в одну й ту саму годину доби.
### Умова
Якщо є не менше трьох server-wide інцидентів в одну й ту саму годину доби:
$$
N_{server\_incidents,same\_hour} \ge 3
$$
то вони можуть бути класифіковані як:
```text
server routine
```
### Сенс
Це може вказувати на регулярне нічне завдання, обслуговування архіву, batch-процес або масову операцію, яка впливає на тривалість сеансів.
## Атрибуція причини по кожному вузлу
Після пошуку парк-інцидентів звіт визначає, що домінує у кожного вузла: зовнішні інциденти чи локальна проблема.
### Частка аномалій вузла, що потрапили в парк-інциденти
$$
InIncidentPct =
\frac{N_{long,in\_incidents}}{N_{long}} \times 100\%
$$
### Якщо більшість аномалій збіглася з парк-інцидентами
Якщо:
$$
InIncidentPct \ge 70\%
$$
то домінуюча причина вузла береться з парк-інциденту:
```text
network_outage / cell_tower / firmware / server
```
Це означає:
```text
the device is probably not the main culprit; it suffered together with others.
```
### Перевірка низької батареї
Якщо аномалії не пояснені парк-інцидентами, перевіряється живлення. Нехай:
$$
Btm_{first}
$$
— перше доступне значення батареї в довгих сеансах, а:
$$
Btm_{last}
$$
— останнє доступне значення. Падіння:
$$
BtmDrop =
Btm_{first} - Btm_{last}
$$
Гіпотеза `battery_low` можлива, якщо:
$$
Btm_{first} < 3500 \; mV
$$
і:
$$
BtmDrop > 200 \; mV
$$
### Перевірка локально слабкого сигналу
Якщо:
$$
RSSI_{avg} < -85 \; dBm
$$
то гіпотеза:
```text
weak signal at the installation site
```
### Ізольована несправність вузла
Якщо:
- аномалії не збігаються з парк-інцидентами;
- батарея не пояснює картину;
- RSSI не критично слабкий;
то причина класифікується як:
```text
local malfunction of the node
```
## Розподіл гіпотез по парку
Для кожного вузла обирається домінуюча причина. Коли більшість вузлів постраждали від парк-інцидентів, сам вузол не винний; лише меншість має ізольовану локальну проблему. Це змінює план дій: головне зусилля спрямовується на базові станції та оператора, а не на масовий виїзд до кожного вузла з аномаліями.
Звіт показує, скільки вузлів віднесено до кожної домінуючої причини.
### Формула частки гіпотези
$$
Share_{hypothesis} =
\frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\%
$$
### Групи причин
Для управлінського зведення гіпотези можна обʼєднувати:
| Група | Включає |
| --------------------------- | ----------------------------------------------------------------- |
| мережа / сервер | `server_driver`, `server_routine`, `network_outage`, `cell_tower` |
| локальні проблеми пристроїв | `isolated_device`, `local_signal`, `battery_low` |
| модель / прошивка | `firmware` |
| змішані | `mixed` |
### Інтерпретація
| Домінує | Що робити |
| ----------------- | --------------------------------------------------------------------- |
| `Cell tower` | перевірити покриття, оператора, зовнішні антени у зачеплених клієнтів |
| `Local signal` | виїзд до конкретного вузла, антена, репітер, місце встановлення |
| `Isolated device` | діагностика модема, SIM, живлення, прошивки |
| `Firmware` | перевірити версію ПЗ і звернутися до постачальника |
| `Server routine` | перевірити регулярні процеси платформи |
| `Network outage` | запитати оператора мобільної мережі за часом і зоною |
## Топ проблемних вузлів
Таблиця топ проблемних вузлів ранжує вузли за композитним score (0–100), побудованим із частки довгих сеансів, їхньої середньої тривалості та кількості. Клік по рядку розкриває найдовші сеанси вузла зі значеннями RSSI та `Btm` — це використовується для планування виїзду.
### Призначення
Таблиця показує, куди їхати або що перевіряти в першу чергу.
### Колонки таблиці
| Колонка | Значення |
| ------------------ | ----------------------------------- |
| Вузол | назва та ID вузла |
| Коректор | тип приладу |
| Сеансів | загальна кількість валідних сеансів |
| Довгих | кількість аномально довгих сеансів |
| Частка | відсоток довгих сеансів |
| Середній довгий | середня тривалість довгих сеансів |
| Максимальний сеанс | найгірший знайдений сеанс |
| `RSSI` середній | якість радіосигналу |
| Втрата батареї | розрахункова зайва енергія |
| Score | композитна оцінка проблемності |
### Як читати топ
Високий score може виникати з різних причин:
- велика частка довгих сеансів;
- дуже довгі окремі сеанси;
- велика абсолютна кількість довгих сеансів;
- поєднання цих факторів.
Для планування виїзду потрібно читати не лише score, але й:
- `RSSI`;
- гіпотезу RCA;
- втрату батареї;
- максимальний сеанс;
- потрапляння в парк-інциденти;
- тип коректора.
## Топ проблемних діб
Усі аномальні сеанси групуються за календарними добами. День з найбільшою кількістю аномалій — це, найімовірніше, де стався парк-інцидент. Кожен день розкривається у список вузлів з їхніми аномаліями, максимальним сеансом і посиланнями. Це корисно для розбору масових подій і перевірки регулярності.
### Призначення
Розріз за добами показує дні, коли довгі сеанси масово виникали на парку.
### Показники дня
| Показник | Значення |
| ------------------ | --------------------------------- |
| Дата | календарний день |
| Довгих сеансів | кількість довгих сеансів за день |
| Вузлів | скільки вузлів зачеплено |
| Середній довгий | середня тривалість довгих сеансів |
| Максимальний сеанс | найгірший випадок дня |
| Найгірший вузол | вузол з максимальним сеансом |
### Інтерпретація
| Картина | Можлива причина |
| ------------------------- | ------------------------------------------------------------------ |
| багато вузлів в один день | мережевий або парк-інцидент |
| один вузол щодня | локальна проблема |
| сплеск у вихідний | операторська мережа / технічні роботи |
| сплеск в однаковий час | регулярне завдання або розклад |
| зростання за місяцями | деградація мережі, сезонне перевантаження, зміна режиму опитування |
## Розріз за типами коректорів
Блок покриття показує, що було перевірено з парку за кожним типом коректора: скільки вузлів у вибірці, скільки віддали дані, скільки пройшли IQR і скільки демонструють аномалії. Якщо у типу зазначено «норма», дані прийшли, але аномалій не знайдено. «Немає даних» означає, що тип не віддає тривалість сеансів в API — для деяких моделей це нормально.
Розкрийте тип, щоб побачити всі його вузли з аномаліями; розкрийте вузол, щоб побачити конкретні довгі сеанси з часом, тривалістю, RSSI та `Btm`. Колір підсвічування сеансу залежить від того, наскільки сеанс довший за норму вузла.
### Призначення
Розріз за типами коректорів показує, які моделі частіше потрапляють в аномально довгі сеанси.
### Показники за типом
| Показник | Значення |
| ----------- | ------------------------------------ |
| У вибірці | скільки вузлів цього типу в парку |
| З даними | скільки вузлів віддали дані сеансів |
| Пройшли IQR | скільки вузлів мають мінімум сеансів |
| Аномалій | кількість довгих сеансів |
| Стан | норма / аномалії / немає даних |
### Важливе обмеження
**Не можна напряму порівнювати типи коректорів лише за кількістю аномалій.** Потрібно враховувати:
- скільки пристроїв цього типу в парку;
- скільки з них віддали дані;
- скільки пройшли мінімум сеансів;
- де вони встановлені;
- в яких мережах працюють;
- чи однаковий у них режим опитування;
- чи не сконцентровані вони в одного клієнта.
### Нормована частка аномалій за типом
Для коректного порівняння можна використовувати:
$$
TypeAnomalyRate =
\frac{N_{long,type}}{N_{sessions,type}} \times 100\%
$$
або:
$$
TypeAffectedRate =
\frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\%
$$
## Розріз за часом: динаміка та місяці
Графік денної динаміки показує, скільки аномальних сеансів сталося на парку кожного дня вікна. Видно «спалахи» — дні поганого звʼязку в мережі загалом. Пік, що збігається з реєстром інцидентів, зазвичай є серією проблем базової станції в одній локації.
Розріз за календарними місяцями допомагає побачити сезонність або довгостроковий тренд. Масовий місячний пік відповідає тій самій серії інцидентів, що й у денній динаміці; поступове зростання з часом — кандидат на деградацію звʼязку або батарей.
### Призначення
Розріз за місяцями показує сезонність або довгостроковий тренд довгих сеансів.
### Показник місяця
$$
N_{long,month} =
count(long\_sessions \; in \; month)
$$
### Частка місяця
Якщо потрібно показати частку:
$$
Share_{month} =
\frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\%
$$
### Інтерпретація
| Картина | Можливе пояснення |
| ---------------------- | ------------------------------------------------ |
| різкий місячний сплеск | зміна мережі, масовий збій, сезонне навантаження |
| поступове зростання | деградація звʼязку або батарей |
| сплеск взимку | погодні умови, навантаження мережі, живлення |
| сплеск після оновлення | прошивка, налаштування, розклад опитування |
## Колірне підсвічування конкретних сеансів
При розкритті вузла його окремі довгі сеанси підсвічуються за силою перевищення індивідуального порогу, а також показуються точні значення RSSI та `Btm` у момент кожного довгого сеансу. Саме це потрібно виїзній бригаді: низький RSSI вказує на проблему радіосигналу, а нормальна напруга батареї виключає батарею.
### Ratio перевищення
$$
Ratio_i =
\frac{d_i}{UpperFence}
$$
### Інтерпретація
| Ratio | Колір / рівень |
| ----: | ------------------- |
| 1–2× | слабке перевищення |
| 2–5× | середнє перевищення |
| ≥5× | сильне перевищення |
Це допомагає швидко відрізнити помірно довгі сеанси від екстремальних.
## Що робити за результатами звіту
### Якщо причина — базова станція
Перевірити:
- якість покриття в локації;
- альтернативного оператора мобільної мережі;
- зовнішню антену;
- репітер;
- повторюваність інцидентів за днями;
- сусідні вузли тієї ж локації;
- перевантаження мережі в конкретні години.
### Якщо причина — локальний вузол
Перевірити:
- антену;
- SIM-карту;
- модем;
- живлення;
- батарею;
- розʼєми;
- місце встановлення;
- перешкоди;
- версію прошивки;
- налаштування розкладу передачі.
### Якщо причина — слабкий сигнал
Дії:
- виміряти RSSI на місці;
- спробувати винести антену;
- перевірити напрямок антени;
- перевірити альтернативного оператора;
- поставити зовнішню антену або репітер.
### Якщо причина — батарея
Дії:
- перевірити `Btm` на місці;
- замінити батарею за потреби;
- перевірити струм споживання;
- перевірити частоту retries;
- перевірити, чи не перевантажує пристрій мережу повторними спробами.
### Якщо причина — модель / прошивка
Дії:
- згрупувати вузли за версією ПЗ;
- перевірити release notes постачальника;
- запитати відомі проблеми;
- порівняти з іншими моделями в тих самих локаціях;
- протестувати режим звʼязку в лабораторії.
## AI-коментар
Опціональний AI-коментар читає RCA і пише короткий, зрозумілий людині план виїзду для бригади. Це **мовне пояснення, а не джерело діагностики** — усі числа та причини визначаються формулами та правилами вище.
### Що AI може робити
- коротко переказати RCA;
- пояснити головного ймовірного винуватця;
- виділити топ-вузли;
- сформулювати план виїзду;
- пояснити розріз за моделями.
### Що AI не може робити
AI **не може**:
- змінити IQR-поріг;
- змінити список довгих сеансів;
- змінити score;
- визначити істинну причину без даних;
- замінити радіотехнічне обстеження;
- замінити виїзд;
- бути доказовою базою.
Аналіз детермінований. AI-коментар слід читати лише як пояснювальний текст — усі числові висновки
визначаються формулами та правилами.
## Типові помилки інтерпретації
### Помилка: довгий сеанс = поганий прилад
Невірно. Довгий сеанс може бути спричинений мережею, базовою станцією, слабким сигналом, серверною рутиною, локальною антеною, SIM-картою або батареєю.
### Помилка: багато аномалій у моделі = модель погана
Невірно. Потрібно нормувати на кількість пристроїв, кількість сеансів, локації та операторів мобільних мереж.
### Помилка: немає аномалій = все добре
Невірно, якщо даних сеансів немає або покриття занадто низьке.
### Помилка: високий RSSI виключає проблему звʼязку
Не завжди. Можливі проблеми оператора, перевантаження, прошивки, серверного прийому, повторні передачі або помилки протоколу.
### Помилка: battery loss = точна витрата батареї
Невірно. Це оцінка, побудована на зайвому часі передачі та умовному струмі.
### Помилка: один екстремально довгий сеанс робить вузол головним проблемним
Не завжди. Score враховує не лише максимум, але й частку, середню тривалість і кількість довгих сеансів.
## Мінімальні критерії повноцінного звіту
Звіт вважається методично повним, якщо містить:
- період аналізу;
- охоплення парку;
- статус data-gate;
- кількість вузлів у парку;
- кількість опитаних вузлів;
- кількість вузлів з даними сеансів;
- кількість вузлів, що пройшли IQR-поріг;
- кількість сеансів у вибірці;
- кількість довгих сеансів;
- кількість вузлів з аномаліями;
- максимальну тривалість сеансу;
- кількість часових інцидентів;
- розподіл RCA-гіпотез;
- формулу IQR-порогу;
- формулу score вузла;
- формулу battery loss;
- правила RCA-класифікації;
- таблицю топ проблемних вузлів;
- розріз за днями;
- розріз за типами коректорів;
- розріз за місяцями;
- дисклеймер про приблизність battery loss;
- дисклеймер про роль AI;
- рекомендації щодо дій.
## Зведена формула звіту
Для кожного вузла:
$$
D = \{d_i \mid d_i > 0\}
$$
$$
IQR = Q3(D) - Q1(D)
$$
$$
UpperFence = Q3(D) + 1.5 \times IQR
$$
$$
LongSessions =
\{d_i \mid d_i > UpperFence\}
$$
$$
Pct_{long} =
\frac{|LongSessions|}{|D|} \times 100\%
$$
$$
A = min(100,\;4 \times Pct_{long})
$$
$$
B =
min
\left(
100,\;
8 \times
\frac{AvgLongDuration}{max(1, MedianDuration)}
\right)
$$
$$
C = min(100,\;|LongSessions|)
$$
$$
Score =
0.5A + 0.3B + 0.2C
$$
Оцінка зайвої витрати батареї:
$$
ExtraTime_{total} =
\sum_{d_i \in LongSessions}
max(0,\;d_i - MedianDuration)
$$
$$
BatteryLoss_{mAh} =
\frac{340 \times ExtraTime_{total}}{3600}
$$
Групування інцидентів:
$$
Bucket(t) =
floor(t / 1h) \times 1h
$$
$$
Incident =
Bucket \; where \; N_{unique\_stations} \ge 5
$$
## Рекомендований дисклеймер
```text
The report detects abnormally long communication sessions relative to each
node's individual norm. The result is used for prioritising diagnostics of
communications, antennas, SIM cards, power, carriers and base stations. The
report is not proof of a specific device's malfunction without a field visit and
does not assess the correctness of commercial gas metering.
```
## Звʼязок з іншими звітами
| Якщо потрібно зрозуміти | Використовувати |
| ----------------------------------------------------- | --------------------- |
| які вузли довго тримають звʼязок і витрачають батарею | цей звіт |
| у яких вузлів немає звʼязку або архіву | Top Problem Nodes |
| чи можна закривати період за конкретним вузлом | Consumption Analytics |
| чи є підозра на недооблік | Suspicious Nodes |
| чому конкретний вузол підозрілий | Metering Bypass |
| коли міняти батареї | Battery Forecast |
Такий поділ запобігає змішуванню довгих сеансів звʼязку з комерційними, метрологічними та forensic-висновками.