Аномально длинные сеансы связи

Узлы парка, чьи сеансы связи аномально длинны относительно их собственной нормы, с индивидуальными IQR-порогами, оценкой проблемности и анализом первопричин на основе инцидентов.

Отчёт «Аномально длинные сеансы связи» анализирует телеметрические сеансы связи по всему парку узлов учёта и выявляет устройства, локации, дни и типы корректоров, где связь работает нестабильно или требует чрезмерно долгого времени для передачи данных.

В шапке отчёта семь KPI: компания, охват парка, готовность данных, число узлов с аномалиями, число аномальных сеансов, максимальная длительность сеанса, общее число часовых инцидентов и период анализа. Главное число — количество узлов с аномалиями из общего числа в парке; инциденты — это часовые кластеры, где пять и более узлов имеют длинные сеансы одновременно.

Отчёт отвечает на практические вопросы эксплуатации:

какие узлы имеют слишком долгие сеансы связи;
какие сеансы считаются аномальными именно для данного узла;
где проблема локальная: антенна, SIM-карта, питание, модем, место установки;
где проблема похожа на инцидент базовой станции или оператора связи;
есть ли массовые часовые инциденты на парке;
какие дни были наиболее проблемными;
какие типы корректоров чаще попадают в длинные сеансы;
сколько энергии ориентировочно потрачено на повторные или удлинённые передачи;
какие узлы требуют выезда с внешней антенной, репитером или проверкой SIM;
где нужно проверять оператора связи или качество покрытия в конкретной локации.

Место отчёта в системе

Отчёт относится к эксплуатационной диагностике телеметрии. Он не должен смешивать две разные ситуации:

Нет связи вообще. Узел не выходит на связь, данных нет.
Связь есть, но сеансы слишком длинные. Узел передаёт данные, но делает это медленно, нестабильно или с повторными попытками.

Данный отчёт анализирует вторую ситуацию. Где связи, архива или данных нет вообще, используйте отчёт «Топ проблемных узлов»; где нужно проверить, пригодны ли данные одного узла для учёта, используйте «Аналитику потребления».

Для кого предназначен отчёт

Роль	Что получает из отчёта
Руководитель эксплуатации	общую картину по парку, число узлов с аномалиями, массовые инциденты
Инженер связи	список узлов с плохим RSSI, длинными сеансами и локальными проблемами
Диспетчер	приоритетный список заявок и проблемных дней
Выездная бригада	топ-узлы для проверки антенны, SIM, питания и места установки
Инженер интеграции	диагностику готовности данных, покрытие API и случаи отсутствия данных сеансов
Закупочный специалист	сравнительный разрез по типам корректоров
Аналитик парка	RCA-гипотезы: базовая станция, оператор, прошивка, локальный узел

Что отчёт не делает

Отчёт не должен:

доказывать неисправность конкретного модема без выезда;
считать длинный сеанс прямым доказательством плохого прибора;
автоматически обвинять сервер или оператора связи;
смешивать «нет данных» с «нет аномалий»;
сравнивать длительность сеансов всех узлов одним общим порогом;
считать короткий период с малым числом сеансов статистически надёжным;
делать вывод о качестве модели прибора без учёта числа устройств в выборке;
заменять радиотехническое обследование места установки;
считать оценку потери батареи точным измерением;
использовать AI-комментарий как источник диагностики.

Основные термины

Термин	Значение
Сеанс связи	один эпизод соединения устройства с системой передачи данных
Длительность сеанса	время от начала до завершения сеанса
Нормальный сеанс	сеанс, длительность которого находится в индивидуальной норме узла
Длинный сеанс	сеанс, длительность которого превышает индивидуальный IQR-порог узла
`IQR`	межквартильный размах: `Q3 − Q1`
`Q1`	первый квартиль длительностей сеансов
`Q3`	третий квартиль длительностей сеансов
`UpperFence`	верхняя граница нормы: `Q3 + 1.5 × IQR`
`RSSI`	уровень радиосигнала, дБм
`CSQ`	индекс качества сигнала GSM, может быть пересчитан в дБм
`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` / батарея	оценка влияния питания
Организация / локация	атрибуция инцидента: локальный клиент, базовая станция, парк

Минимально необходимый набор

Для корректного анализа узла нужны:

идентификатор устройства;
не менее минимального числа сеансов;
длительность каждого сеанса;
временна́я метка каждого сеанса.

Если длительность сеанса отсутствует, такой сеанс не участвует в 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 показывает, насколько узел проблемен по длинным сеансам. Он учитывает три измерения:

долю длинных сеансов;
насколько длинные сеансы превышают норму;
абсолютное число длинных сеансов.

Такой подход позволяет не переоценивать единичный выброс и не недооценивать узел с большим количеством умеренно длинных сеансов.

Компонент 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	слабый сигнал

Оценка потери батареи на длинных сеансах

Смысл

Длинный сеанс увеличивает время передачи и может дополнительно расходовать батарею. Отчёт даёт ориентировочную оценку лишнего расхода энергии. Это не точное измерение батареи, а эксплуатационная оценка.

Лишнее время передачи

Для каждого длинного сеанса рассчитывается превышение над медианной нормой узла:

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 — ток в миллиамперах;
результат — в мА·ч.

Для отображения в А·ч:

BatteryLoss_{Ah} = \frac{BatteryLoss_{mAh}}{1000}

Ограничение

Эта оценка не учитывает:

реальный профиль тока конкретной модели;
режим сна;
повторные попытки на уровне модема;
мощность передатчика;
температуру;
возраст батареи;
ёмкость батареи;
качество сети в момент передачи.

Поэтому её нужно читать как оценку масштаба, а не как лабораторное измерение.

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

То есть все события внутри одного часа попадают в один bucket.

Инцидент

Часовой bucket считается инцидентом, если в нём затронуто не менее:

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 на месте;
заменить батарею при необходимости;
проверить ток потребления;
проверить частоту повторных попыток;
проверить, не перегружает ли устройство сеть повторными попытками.

Если причина — модель / прошивка

Действия:

сгруппировать узлы по версии ПО;
проверить примечания к выпускам поставщика;
запросить известные проблемы;
сравнить с другими моделями в тех же локациях;
протестировать режим связи в лаборатории.

AI-комментарии

Необязательный AI-комментарий читает RCA и пишет короткий, понятный человеку план выезда для бригады. Это языковое пояснение, а не источник диагностики — все числа и причины определяются формулами и правилами выше.

Что AI может делать

кратко пересказать RCA;
объяснить главного вероятного виновника;
выделить топ-узлы;
сформулировать план выезда;
объяснить разрез по моделям.

Что AI не может делать

AI не может:

изменить IQR-порог;
изменить список длинных сеансов;
изменить score;
определить истинную причину без данных;
заменить радиотехническое обследование;
заменить выезд;
быть доказательной базой.

Типовые ошибки интерпретации

Ошибка: длинный сеанс = плохой прибор

Неверно. Длинный сеанс может быть вызван сетью, базовой станцией, слабым сигналом, серверной рутиной, локальной антенной, 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

Связь с другими отчётами

Если нужно понять	Использовать
какие узлы долго держат связь и тратят батарею	этот отчёт
у каких узлов нет связи или архива	Топ проблемных узлов
можно ли закрывать период по конкретному узлу	Аналитика потребления
есть ли подозрение на недоучёт	Подозрительные узлы
почему конкретный узел подозрителен	Подозрение на обход учёта
когда менять батареи	Прогноз состояния батарей

Такое разделение нужно, чтобы длинные сеансы связи не смешивались с коммерческими, метрологическими и экспертными выводами.

Связанные темы

Обозреватель событий

Последнее обновление 26 июня 2026 г.

Эта страница была полезной?