---
title: 'Dlhé relácie'
description: Uzly flotily, ktorých komunikačné relácie trvajú abnormálne dlho vzhľadom na ich vlastnú normu, s individuálnymi IQR-prahmi pre uzol, skóre závažnosti a analýzou koreňovej príčiny na základe incidentov.
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';
Správa **Dlhé relácie** analyzuje telemetrické komunikačné relácie v celej flotile meracích uzlov a identifikuje zariadenia, lokality, dni a typy prepočítavačov, kde komunikácia funguje nestabilne alebo si vyžaduje nadmerne dlhý čas na prenos dát.
Hlavička správy nesie sedem KPI: spoločnosť, pokrytie flotily, pripravenosť dát, počet uzlov s anomáliami, počet anomálnych relácií, maximálne trvanie relácie, celkový počet hodinových incidentov a obdobie analýzy. Hlavné číslo je počet uzlov s anomáliami z celkového počtu flotily; incidenty sú hodinové klastre, kde päť alebo viac uzlov má dlhé relácie súčasne.
Správa odpovedá na praktické otázky prevádzky:
- ktoré uzly majú príliš dlhé komunikačné relácie;
- ktoré relácie sa považujú za anomálne práve pre daný uzol;
- kde je problém lokálny: anténa, SIM-karta, napájanie, modem, miesto inštalácie;
- kde problém pripomína incident základňovej stanice alebo mobilného operátora;
- či existujú hromadné hodinové incidenty vo flotile;
- ktoré dni boli najproblémovejšie;
- ktoré typy prepočítavačov sa častejšie dostávajú do dlhých relácií;
- koľko energie bolo orientačne spotrebovanej na opakované alebo predĺžené prenosy;
- ktoré uzly vyžadujú výjazd s externou anténou, opakovačom alebo kontrolou SIM;
- kde je potrebné skontrolovať mobilného operátora alebo kvalitu pokrytia v konkrétnej lokalite.
Správa nehodnotí správnosť obchodného merania plynu a nie je forenzná správa o obchádzaní merania.
Analyzuje len komunikačné relácie: trvanie, frekvenciu anomálií, hromadnosť incidentov, kvalitu
signálu a pravdepodobnú príčinu dlhých relácií.
## Kam správa zapadá
Správa patrí do oblasti prevádzkovej diagnostiky telemetrie. Nesmie miešať dve odlišné situácie:
1. **Žiadna komunikácia.** Uzol sa vôbec nepripája, nie sú dáta.
2. **Komunikácia je, ale relácie sú príliš dlhé.** Uzol prenáša dáta, ale robí to pomaly, nestabilne alebo s opakovanými pokusmi.
Táto správa analyzuje **druhú** situáciu. Tam, kde nie je vôbec žiadna komunikácia, archív ani dáta, použite správu Najproblémovejšie uzly; tam, kde je potrebné overiť, či sú dáta jedného uzla použiteľné na meranie, použite Analytiku spotreby.
## Pre koho je správa určená
| Rola | Čo zo správy získa |
| -------------------- | ----------------------------------------------------------------------------- |
| Vedúci prevádzky | celkový pohľad na flotilu, počet uzlov s anomáliami, hromadné incidenty |
| Inžinier komunikácie | zoznam uzlov so slabým RSSI, dlhými reláciami a lokálnymi problémami |
| Dispečer | prioritný zoznam tiketov a problémových dní |
| Výjazdová brigáda | top uzly na kontrolu antény, SIM, napájania a miesta inštalácie |
| Integračný inžinier | diagnostiku pripravenosti dát, pokrytie API a prípady chýbajúcich dát relácií |
| Špecialista nákupu | porovnávací rez podľa typov prepočítavačov |
| Analytik flotily | RCA-hypotézy: základňová stanica, operátor, firmvér, lokálny uzol |
## Čo správa nerobí
Správa nesmie:
- dokazovať poruchu konkrétneho modemu bez výjazdu;
- považovať dlhú reláciu za priamy dôkaz zlého prístroja;
- automaticky obviňovať server alebo mobilného operátora;
- miešať „žiadne dáta" so „žiadnymi anomáliami";
- porovnávať trvanie relácií všetkých uzlov jedným spoločným prahom;
- považovať krátke obdobie s malým počtom relácií za štatisticky spoľahlivé;
- robiť záver o kvalite modelu prístroja bez zohľadnenia počtu zariadení vo vzorke;
- nahrádzať rádiotechnickú obhliadku miesta inštalácie;
- považovať odhad straty batérie za presné meranie;
- používať AI-komentár ako zdroj diagnostiky.
## Kľúčové pojmy
| Pojem | Význam |
| ------------------- | --------------------------------------------------------------------------------------- |
| Komunikačná relácia | jedna epizóda spojenia zariadenia so systémom prenosu dát |
| Trvanie relácie | čas od začiatku do ukončenia relácie |
| Normálna relácia | relácia, ktorej trvanie sa nachádza v individuálnej norme uzla |
| Dlhá relácia | relácia, ktorej trvanie presahuje individuálny IQR-prah uzla |
| `IQR` | medzikvartilové rozpätie: `Q3 − Q1` |
| `Q1` | prvý kvartil trvaní relácií |
| `Q3` | tretí kvartil trvaní relácií |
| `UpperFence` | horná hranica normy: `Q3 + 1.5 × IQR` |
| `RSSI` | úroveň rádiového signálu, dBm |
| `CSQ` | index kvality GSM signálu, ktorý je možné prepočítať na dBm |
| `Btm` | napätie batérie alebo ukazovateľ napájania zariadenia |
| `Long share` | podiel dlhých relácií zo všetkých relácií uzla |
| `Severity score` | celkové hodnotenie problémovosti uzla podľa dlhých relácií |
| Incident | hodinový klaster, kde sa dlhé relácie objavili naraz u viacerých uzlov |
| `RCA` | analýza pravdepodobnej príčiny: základňová stanica, sieť, server, firmvér, lokálny uzol |
| `Battery loss` | orientačný odhad energie spotrebovanej na nadbytočné trvanie prenosu |
## Všeobecná logika správy
Správa je postavená ako analýza komunikačných relácií celej flotily.
```text
Zoznam uzlov flotily
→ získanie komunikačných relácií
→ kontrola pripravenosti dát
→ individuálna norma relácií pre každý uzol
→ vyhľadanie dlhých relácií podľa IQR
→ výpočet score pre každý uzol
→ zoskupenie dlhých relácií do hodinových incidentov
→ určenie pravdepodobnej príčiny RCA
→ rozdelenie hypotéz podľa uzlov
→ top problémových uzlov
→ rez podľa typov prepočítavačov
→ rez podľa dní a mesiacov
→ odporúčania pre prevádzku
```
Hlavný princíp:
```text
dlhá relácia sa určuje vzhľadom na normu konkrétneho uzla,
a nie vzhľadom na spoločný pevný prah celej flotily.
```
Je to dôležité, pretože rôzne prístroje, regióny, mobilní operátori a režimy dopytovania môžu mať rôzne normálne trvania relácií.
## Parametre spustenia
| Parameter | Význam |
| --------------------------------- | ----------------------------------------------------------------------------- |
| Dátum od / Dátum do | hranice okna analýzy |
| Okno analýzy, dni | záložné okno použité, keď sú dátumy prázdne (predvolene 30) |
| Uzlov na typ prepočítavača | veľkosť vzorky na typ; `0` znamená všetky uzly flotily |
| Minimum relácií na uzol pre IQR | minimálny počet relácií, ktorý uzol potrebuje na kvalifikáciu (predvolene 30) |
| Počet problémových uzlov v správe | veľkosť tabuľky top-N (predvolene 50) |
| LLM-analýza | voliteľný AI-naratív vysvetľujúci výsledky |
| Spoločnosť | obmedzí analýzu na flotilu jedného dodávateľa |
## Vstupné dáta
### Hlavné dáta
| Dáta | Na čo slúžia |
| ---------------------- | ---------------------------------------------------------------- |
| Zoznam uzlov | určiť flotilu analýzy |
| Typ prepočítavača | zostaviť rez podľa modelov |
| `Equipment ID` | získať relácie konkrétneho zariadenia |
| Komunikačné relácie | základ správy |
| Čas začiatku relácie | zoskupenie podľa dní, mesiacov a hodín |
| Trvanie relácie | hlavný analyzovaný ukazovateľ |
| `RSSI` / `CSQ` | hodnotenie kvality rádiového signálu |
| `Btm` / batéria | hodnotenie vplyvu napájania |
| Organizácia / lokalita | atribúcia incidentu: lokálny klient, základňová stanica, flotila |
### Minimálne potrebný súbor
Na správnu analýzu uzla sú potrebné:
- identifikátor zariadenia;
- aspoň minimálny počet relácií;
- trvanie každej relácie;
- časová značka každej relácie.
Ak trvanie relácie chýba, takáto relácia sa nezúčastňuje IQR-analýzy.
## Pripravenosť dát: data-gate
Pred výpočtom anomálií správa kontroluje, či je možné analýzu vôbec vykonať. Blok pripravenosti dát ukazuje veľkosť flotily, veľkosť po filtri spoločnosti, koľko uzlov vrátilo dáta relácií a koľko z nich prešlo minimom relácií pre IQR. Je to **kriticky dôležitá** diagnostika — bez nej je ľahké zameniť „žiadne anomálie" so „žiadne dáta na analýzu".
### Základné ukazovatele pripravenosti
| Ukazovateľ | Vzorec / hodnota |
| ----------------------------------- | -------------------------------- |
| Uzlov vo flotile | `N_park` |
| Uzlov vo výbere | `N_sampled` |
| Uzlov s dátami relácií | `N_with_data` |
| Uzlov, ktoré prešli minimum relácií | `N_qualified` |
| Celkovo relácií | `N_sessions` |
| API-volaní | `N_calls` |
| API-chýb | `N_errors` |
| Podiel API-chýb | `N_errors / N_calls × 100%` |
| Pokrytie dátami | `N_with_data / N_sampled × 100%` |
| Pokrytie IQR-výberom | `N_qualified / N_sampled × 100%` |
### Podiel API-chýb
$$
APIErrorRate =
\frac{N_{errors}}{N_{calls}} \times 100\%
$$
### Pokrytie dátami
$$
Coverage_{with\_data} =
\frac{N_{with\_data}}{N_{sampled}} \times 100\%
$$
### Pokrytie uzlami vhodnými pre IQR
$$
Coverage_{qualified} =
\frac{N_{qualified}}{N_{sampled}} \times 100\%
$$
### Stavy pripravenosti
| Stav | Podmienka | Čo znamená |
| -------------- | --------------------------------------------- | ------------------------------------- |
| `OK` | je dostatočný výber pre IQR | správu možno čítať ako funkčnú |
| `DEGRADED` | výber je malý, ale analýza je možná | opatrné závery |
| `INCONCLUSIVE` | chýb je veľa alebo pokrytie je kriticky nízke | závery o anomáliách nie sú spoľahlivé |
| `NO_DATA` | nie sú dáta relácií | analýza nie je možná |
| `NO_FLEET` | po filtri nie sú uzly | nie je čo analyzovať |
### Kritické podmienky
Analýza sa považuje za nemožnú, ak:
$$
APIErrorRate \ge 50\%
$$
alebo:
$$
Coverage_{with\_data} < 5\%
$$
alebo:
$$
N_{qualified} = 0
$$
„Žiadne anomálie" a „žiadne dáta na analýzu" sú rôzne stavy. Ak dáta relácií chýbajú, správa
nesmie písať, že sa anomálie nenašli.
## Minimum relácií na uzle
Pre spoľahlivú IQR-analýzu musí každý uzol mať dostatočný počet relácií.
### Minimálny prah
V predvolenom nastavení:
$$
N_{sessions,station} \ge 30
$$
Ak má uzol menej relácií, individuálna norma sa považuje za štatisticky nespoľahlivú a uzol neprejde IQR-filtrom.
### Prečo je potrebné minimum
IQR používa kvartilové odhady. Pri malom počte pozorovaní sa kvartil stáva nestabilným:
- jedna náhodná dlhá relácia môže zvýšiť prah;
- jedno krátke obdobie komunikácie môže prah znížiť;
- nie je možné odlíšiť normu uzla od náhody.
## Individuálna norma trvania relácie
### Prečo je norma individuálna
Nemožno použiť jeden spoločný prah pre celú flotilu, napríklad „všetky relácie dlhšie ako 10 minút sú zlé". Rôzne uzly majú rôzne podmienky komunikácie:
- rôzne typy prepočítavačov;
- rôzni mobilní operátori;
- rôzne RSSI;
- rôzne objemy archívu;
- rôzne rozvrhy dopytovania;
- rôzne miesta inštalácie;
- rôzne antény.
Preto sa pre každý uzol počíta vlastná štatistická norma.
### Výber platných trvaní
Pre každý uzol sa berú len kladné trvania:
$$
D = \{d_i \mid d_i > 0\}
$$
kde:
- `d_i` — trvanie i-tej relácie v sekundách.
### Kvartily
Trvania sa zoradia vzostupne.
$$
D_{sorted} = sort(D)
$$
Prvý kvartil:
$$
Q1 = percentile(D, 25\%)
$$
Medián:
$$
Q2 = median(D)
$$
Tretí kvartil:
$$
Q3 = percentile(D, 75\%)
$$
### Medzikvartilové rozpätie
$$
IQR = Q3 - Q1
$$
### Horná hranica normy Tukey fence
Pre každý uzol sa počíta individuálna horná hranica normy:
$$
UpperFence = Q3 + 1.5 \times IQR
$$
Toto je klasické pravidlo Tukey fences na identifikáciu odľahlých hodnôt.
### Dlhá relácia
Relácia sa považuje za anomálne dlhú, ak:
$$
d_i > UpperFence
$$
kde:
- `d_i` — trvanie relácie;
- `UpperFence` — individuálny prah daného uzla.
Ak má uzol obvykle krátke relácie, jeho prah bude nízky. Ak má uzol obvykle dlhšie relácie, jeho
prah bude vyšší. Správa identifikuje anomáliu **vzhľadom na vlastnú normu uzla**.
## Základné ukazovatele uzla
Pre každý uzol sa počítajú nasledujúce ukazovatele.
### Celkový počet relácií
$$
N_{total} = count(D)
$$
### Počet dlhých relácií
$$
N_{long} = count(d_i > UpperFence)
$$
### Podiel dlhých relácií
$$
Pct_{long} =
\frac{N_{long}}{N_{total}} \times 100\%
$$
### Priemerné trvanie všetkých relácií
$$
AvgDuration =
\frac{\sum d_i}{N_{total}}
$$
### Priemerné trvanie dlhých relácií
$$
AvgLongDuration =
\frac{\sum_{d_i > UpperFence} d_i}{N_{long}}
$$
### Maximálne trvanie
$$
MaxLongDuration =
max(d_i \mid d_i > UpperFence)
$$
### Priemerné RSSI
$$
RSSI_{avg} =
\frac{\sum RSSI_i}{N_{RSSI}}
$$
kde `N_RSSI` je počet relácií s dostupnou hodnotou RSSI.
## Score problémovosti uzla
### Zmysel score
Score ukazuje, nakoľko je uzol problémový z hľadiska dlhých relácií. Zohľadňuje tri rozmery:
1. **podiel dlhých relácií**;
2. **nakoľko dlhé relácie presahujú normu**;
3. **absolútny počet dlhých relácií**.
Tento prístup zabraňuje preceneniu jednotlivého odľahlého prípadu a zabraňuje podceneniu uzla s veľkým počtom mierne dlhých relácií.
### Komponent A — podiel dlhých relácií
$$
A =
min(100,\;4 \times Pct_{long})
$$
Interpretácia:
| Podiel dlhých | A |
| ------------: | --: |
| 5% | 20 |
| 10% | 40 |
| 25% | 100 |
| >25% | 100 |
### Komponent B — relatívne trvanie
$$
B =
min
\left(
100,\;
8 \times \frac{AvgLongDuration}{max(1, MedianDuration)}
\right)
$$
kde `MedianDuration` je mediánové trvanie relácie uzla.
Interpretácia:
| AvgLong / Median | B |
| ---------------: | --: |
| 2× | 16 |
| 5× | 40 |
| 10× | 80 |
| 12.5× | 100 |
### Komponent C — počet dlhých relácií
$$
C =
min(100,\;N_{long})
$$
To znamená, že 100 a viac dlhých relácií dáva maximálny príspevok tohto komponentu.
### Výsledné score
$$
Score =
0.5 \times A
+
0.3 \times B
+
0.2 \times C
$$
kde:
- `A` — podiel dlhých relácií;
- `B` — relatívne trvanie dlhých relácií;
- `C` — absolútny počet dlhých relácií.
Výsledné score je obmedzené rozsahom:
$$
0 \le Score \le 100
$$
### Interpretácia score
| Score | Úroveň |
| ----: | ------------------------------- |
| ≥ 80 | kritický uzol komunikácie |
| 60–80 | vysoká priorita |
| 40–60 | stredná priorita |
| 20–40 | sledovanie / plánovaná kontrola |
| < 20 | slabý signál |
Score nedokazuje príčinu. Vysoké score hovorí, že uzol často a/alebo silno prekračuje svoju
vlastnú normu trvania relácií. **Príčina sa určuje samostatne cez RCA.**
## Odhad straty batérie pri dlhých reláciách
### Zmysel
Dlhá relácia zvyšuje čas prenosu a môže dodatočne spotrebúvať batériu. Správa poskytuje **orientačný** odhad nadbytočnej spotreby energie. Nie je to presné meranie batérie, ale prevádzkový odhad.
### Nadbytočný čas prenosu
Pre každú dlhú reláciu sa počíta prekročenie nad mediánovou normou uzla:
$$
ExtraTime_i =
max(0,\;d_i - MedianDuration)
$$
Sumárny nadbytočný čas:
$$
ExtraTime_{total} =
\sum_{i \in LongSessions} ExtraTime_i
$$
### Prúd prenosu
Na približný odhad sa používa základný prúd prenosu:
$$
I_{TX} = 340 \; mA
$$
### Strata batérie
$$
BatteryLoss_{mAh} =
\frac{I_{TX} \times ExtraTime_{total}}{3600}
$$
kde:
- `ExtraTime_total` — v sekundách;
- `I_TX` — prúd v miliampéroch;
- výsledok — v mAh.
Pre zobrazenie v Ah:
$$
BatteryLoss_{Ah} =
\frac{BatteryLoss_{mAh}}{1000}
$$
### Obmedzenie
Tento odhad nezohľadňuje:
- skutočný profil prúdu konkrétneho modelu;
- režim spánku;
- opakované pokusy na úrovni modemu;
- výkon vysielača;
- teplotu;
- vek batérie;
- kapacitu batérie;
- kvalitu siete v okamihu prenosu.
Preto sa má čítať ako **odhad rádu veľkosti**, a nie ako laboratórne meranie.
## RSSI a CSQ
### RSSI
`RSSI` ukazuje úroveň rádiového signálu v dBm. Čím je hodnota bližšie k nule, tým je signál silnejší.
Približná interpretácia:
| RSSI | Hodnotenie |
| ----------: | ------------ |
| ≥ −65 dBm | dobrý signál |
| −65…−75 dBm | prijateľný |
| −75…−85 dBm | slabý |
| < −85 dBm | veľmi slabý |
### CSQ
Niektoré zariadenia neprenášajú RSSI v dBm, ale `CSQ` — index kvality GSM signálu. Ak hodnota pripomína CSQ, je možné ju prepočítať:
$$
RSSI_{dBm} =
-113 + 2 \times CSQ
$$
Príklad:
$$
CSQ = 29
$$
$$
RSSI = -113 + 2 \times 29 = -55 \; dBm
$$
### Lokálne slabý signál
Ak:
$$
RSSI_{avg} < -85 \; dBm
$$
a anomálie uzla sa nezhodujú s hromadnými flotilovými incidentmi, príčina môže byť klasifikovaná ako:
```text
slabý signál v mieste inštalácie
```
## Zoskupenie dlhých relácií do incidentov
Anomálie sa zoskupujú podľa hodinových okien. Ak v jednej hodine naraz niekoľko uzlov dostalo dlhé relácie, **nie je to lokálny problém uzla**, ale incident siete, servera alebo operátora. Hypotéza sa určuje automaticky podľa šírky pokrytia — počtu uzlov, modelov a klientov v okne.
### Prečo je zoskupenie potrebné
Ak sa v tej istej hodine dlhé relácie objavili u mnohých uzlov naraz, zrejme to nie je lokálny problém jedného prístroja. Môže to byť:
- problém základňovej stanice;
- lokálne preťaženie operátora;
- hromadný sieťový incident;
- regulárna serverová operácia;
- zvláštnosť firmvéru určitého modelu.
### Hodinový kôš
Každá dlhá relácia sa umiestni do hodinového koša:
$$
Bucket(t) =
floor\left(
\frac{t}{1h}
\right) \times 1h
$$
To znamená, že všetky udalosti v rámci jednej hodiny padajú do jedného koša.
### Incident
Hodinový kôš sa považuje za incident, ak v ňom je zasiahnutých minimálne:
$$
N_{stations,bucket} \ge 5
$$
uzlov.
### Ukazovatele incidentu
Pre každý incident sa počítajú:
| Ukazovateľ | Vzorec |
| ------------------------ | -------------------------------- |
| počet uzlov | `count(unique station_id)` |
| počet modelov | `count(unique equipment_type)` |
| počet klientov / lokalít | `count(unique customer_id)` |
| počet relácií | `count(long sessions in bucket)` |
| priemerné RSSI | `average(RSSI)` |
| top modelov | `top equipment types by count` |
## RCA: atribúcia príčiny incidentu
Súhrn flotily určuje hlavného vinníka — základňovú stanicu, server, sieť, firmvér alebo lokálny uzol — poskytuje atribúciu viny pre uzly s anomáliami a tvorí plán činnosti. Voliteľný AI-naratív dole vysvetľuje čísla ľudským jazykom, ale nemení ich.
RCA je klasifikácia pravdepodobnej príčiny dlhých relácií.
### Možné hypotézy
| Hypotéza | Zmysel |
| ----------------- | ----------------------------------------------------- |
| `Server driver` | hromadné zlyhanie zberného ovládača |
| `Server routine` | pravidelná serverová operácia alebo údržba |
| `Network outage` | výpadok mobilnej siete operátora |
| `Cell tower` | problém konkrétnej základňovej stanice alebo lokality |
| `Firmware` | problém modelu zariadenia / firmvéru |
| `Local signal` | slabý signál v mieste inštalácie |
| `Battery low` | nízke napájanie / degradácia batérie |
| `Isolated device` | lokálna porucha konkrétneho uzla |
| `Mixed causes` | zmiešané príčiny |
### Široký serverový incident
Incident sa klasifikuje ako serverový, ak je súčasne zasiahnutých mnoho uzlov, mnoho modelov a mnoho klientov. Podmienečne:
$$
N_{stations} \ge ServerWideStations
$$
$$
N_{models} \ge ServerWideModels
$$
$$
N_{customers} \ge ServerWideCustomers
$$
V správe to znamená:
```text
široký flotilový incident, ktorý nevyzerá ako lokálny problém jedného uzla.
```
### Sieťový výpadok operátora
Ak je zasiahnutých niekoľko modelov a niekoľko klientov, ale rozsah nedosahuje serverové zlyhanie:
$$
N_{models} \ge 3
$$
a:
$$
N_{customers} \ge 3
$$
potom hypotéza:
```text
výpadok mobilnej siete / operátorský incident
```
### Problém základňovej stanice
Ak je zasiahnutých mnoho uzlov, ale patria do jednej alebo dvoch lokalít / klientov:
$$
N_{customers} \le 2
$$
a:
$$
N_{stations} \ge CellMinStations
$$
potom hypotéza:
```text
problém základňovej stanice alebo lokálneho pokrytia
```
### Problém firmvéru alebo modelu
Ak je zasiahnutý jeden model, ale rôzni klienti:
$$
N_{models} = 1
$$
a:
$$
N_{customers} \ge 3
$$
potom hypotéza:
```text
firmvér / zvláštnosť modelu prístroja
```
### Zmiešané príčiny
Ak podmienky nedávajú jednoznačnú klasifikáciu, incident dostane stav:
```text
zmiešané príčiny
```
## Opakovaná serverová rutina
Niekedy sa hromadné serverové incidenty vyskytujú v rovnakú hodinu dňa.
### Podmienka
Ak existujú najmenej tri server-wide incidenty v rovnakú hodinu dňa:
$$
N_{server\_incidents,same\_hour} \ge 3
$$
potom môžu byť klasifikované ako:
```text
server routine
```
### Zmysel
Môže to naznačovať pravidelnú nočnú úlohu, údržbu archívu, batch-proces alebo hromadnú operáciu, ktorá ovplyvňuje trvanie relácií.
## Atribúcia príčiny pre každý uzol
Po vyhľadaní flotilových incidentov správa určuje, čo prevažuje u každého uzla: externé incidenty alebo lokálny problém.
### Podiel anomálií uzla, ktoré padli do flotilových incidentov
$$
InIncidentPct =
\frac{N_{long,in\_incidents}}{N_{long}} \times 100\%
$$
### Ak väčšina anomálií spadla s flotilovými incidentmi
Ak:
$$
InIncidentPct \ge 70\%
$$
potom sa dominantná príčina uzla preberá z flotilového incidentu:
```text
network_outage / cell_tower / firmware / server
```
To znamená:
```text
zariadenie pravdepodobne nie je hlavný vinník; postihlo ho to spolu s ostatnými.
```
### Kontrola nízkej batérie
Ak anomálie nie sú vysvetlené flotilovými incidentmi, kontroluje sa napájanie. Nech:
$$
Btm_{first}
$$
je prvá dostupná hodnota batérie v dlhých reláciách, a:
$$
Btm_{last}
$$
je posledná dostupná hodnota. Pokles:
$$
BtmDrop =
Btm_{first} - Btm_{last}
$$
Hypotéza `battery_low` je možná, ak:
$$
Btm_{first} < 3500 \; mV
$$
a:
$$
BtmDrop > 200 \; mV
$$
### Kontrola lokálne slabého signálu
Ak:
$$
RSSI_{avg} < -85 \; dBm
$$
potom hypotéza:
```text
slabý signál v mieste inštalácie
```
### Izolovaná porucha uzla
Ak:
- anomálie sa nezhodujú s flotilovými incidentmi;
- batéria nevysvetľuje obraz;
- RSSI nie je kriticky slabý;
potom je príčina klasifikovaná ako:
```text
lokálna porucha uzla
```
## Distribúcia hypotéz vo flotile
Pre každý uzol sa vyberá dominantná príčina. Keď väčšinu uzlov postihli flotilové incidenty, samotný uzol nie je vinný; len menšina má izolovaný lokálny problém. To mení plán činnosti: hlavné úsilie smeruje na základňové stanice a operátora, nie na hromadný výjazd k zakaždému uzlu s anomáliami.
Správa ukazuje, koľko uzlov je priradených ku každej dominantnej príčine.
### Vzorec podielu hypotézy
$$
Share_{hypothesis} =
\frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\%
$$
### Skupiny príčin
Pre manažérsky súhrn je možné hypotézy zlúčiť:
| Skupina | Zahŕňa |
| -------------------------- | ----------------------------------------------------------------- |
| sieť / server | `server_driver`, `server_routine`, `network_outage`, `cell_tower` |
| lokálne problémy zariadení | `isolated_device`, `local_signal`, `battery_low` |
| model / firmvér | `firmware` |
| zmiešané | `mixed` |
### Interpretácia
| Prevažuje | Čo robiť |
| ----------------- | -------------------------------------------------------------------- |
| `Cell tower` | preveriť pokrytie, operátora, externé antény u zasiahnutých klientov |
| `Local signal` | výjazd ku konkrétnemu uzlu, anténa, opakovač, miesto inštalácie |
| `Isolated device` | diagnostika modemu, SIM, napájania, firmvéru |
| `Firmware` | kontrola verzie SW a obrátenie sa na dodávateľa |
| `Server routine` | preveriť pravidelné procesy platformy |
| `Network outage` | spýtať sa mobilného operátora na čas a zónu |
## Top problémových uzlov
Tabuľka top problémových uzlov zoraďuje uzly podľa kompozitného score (0–100) zostaveného z podielu dlhých relácií, ich priemerného trvania a ich počtu. Kliknutie na riadok rozvinie najdlhšie relácie uzla s hodnotami RSSI a `Btm` — to sa používa na plánovanie výjazdu.
### Účel
Tabuľka ukazuje, kam ísť alebo čo skontrolovať v prvom rade.
### Stĺpce tabuľky
| Stĺpec | Význam |
| ----------------- | ----------------------------------- |
| Uzol | názov a ID uzla |
| Prepočítavač | typ prístroja |
| Relácií | celkový počet platných relácií |
| Dlhých | počet anomálne dlhých relácií |
| Podiel | percento dlhých relácií |
| Priemerná dlhá | priemerné trvanie dlhých relácií |
| Maximálna relácia | najhoršia nájdená relácia |
| `RSSI` priemerné | kvalita rádiového signálu |
| Strata batérie | vypočítaná nadbytočná energia |
| Score | kompozitné hodnotenie problémovosti |
### Ako čítať top
Vysoké score môže vznikať z rôznych dôvodov:
- veľký podiel dlhých relácií;
- veľmi dlhé jednotlivé relácie;
- veľký absolútny počet dlhých relácií;
- kombinácia týchto faktorov.
Pre plánovanie výjazdu treba čítať nielen score, ale aj:
- `RSSI`;
- hypotézu RCA;
- stratu batérie;
- maximálnu reláciu;
- spadanie do flotilových incidentov;
- typ prepočítavača.
## Top problémových dní
Všetky anomálne relácie sa zoskupujú podľa kalendárneho dňa. Deň s najväčším počtom anomálií je s najväčšou pravdepodobnosťou miesto, kde nastal flotilový incident. Každý deň sa rozvinie do zoznamu uzlov s ich anomáliami, maximálnou reláciou a odkazmi. Užitočné na rozbor hromadných udalostí a kontrolu pravidelnosti.
### Účel
Rez podľa dní ukazuje dni, keď sa dlhé relácie hromadne vyskytovali vo flotile.
### Ukazovatele dňa
| Ukazovateľ | Význam |
| ----------------- | -------------------------------- |
| Dátum | kalendárny deň |
| Dlhých relácií | počet dlhých relácií za deň |
| Uzlov | koľko uzlov bolo zasiahnutých |
| Priemerná dlhá | priemerné trvanie dlhých relácií |
| Maximálna relácia | najhorší prípad dňa |
| Najhorší uzol | uzol s maximálnou reláciou |
### Interpretácia
| Obraz | Možná príčina |
| ----------------------- | -------------------------------------------------------------- |
| mnoho uzlov v jeden deň | sieťový alebo flotilový incident |
| jeden uzol každý deň | lokálny problém |
| nárast cez víkend | operátorská sieť / technické práce |
| výkyvy v rovnakom čase | pravidelná úloha alebo rozvrh |
| rast po mesiacoch | degradácia siete, sezónne preťaženie, zmena režimu dopytovania |
## Rez podľa typov prepočítavačov
Blok pokrytia ukazuje, čo sa z flotily preverilo pre každý typ prepočítavača: koľko uzlov je vo výbere, koľko vrátilo dáta, koľko prešlo IQR a koľko vykazuje anomálie. Ak typ ukazuje „norma", dáta prišli, ale anomálie sa nenašli. „Žiadne dáta" znamená, že typ neodovzdáva trvanie relácií do API — pre niektoré modely je to normálne.
Rozviňte typ a uvidíte všetky jeho uzly s anomáliami; rozviňte uzol a uvidíte jeho konkrétne dlhé relácie s časom, trvaním, RSSI a `Btm`. Farba zvýraznenia relácie závisí od toho, nakoľko je relácia dlhšia ako norma uzla.
### Účel
Rez podľa typov prepočítavačov ukazuje, ktoré modely sa častejšie dostávajú do anomálne dlhých relácií.
### Ukazovatele podľa typu
| Ukazovateľ | Význam |
| ---------- | ------------------------------------- |
| Vo výbere | koľko uzlov daného typu je vo flotile |
| S dátami | koľko uzlov odovzdalo dáta relácií |
| Prešli IQR | koľko uzlov má minimum relácií |
| Anomálií | počet dlhých relácií |
| Stav | norma / anomálie / žiadne dáta |
### Dôležité obmedzenie
**Nemožno priamo porovnávať typy prepočítavačov iba podľa počtu anomálií.** Treba zohľadniť:
- koľko zariadení daného typu je vo flotile;
- koľko z nich odovzdalo dáta;
- koľko prešlo minimum relácií;
- kde sú nainštalované;
- v akých sieťach pracujú;
- či majú rovnaký režim dopytovania;
- či nie sú sústredené u jedného klienta.
### Normovaný podiel anomálií podľa typu
Na korektné porovnanie možno použiť:
$$
TypeAnomalyRate =
\frac{N_{long,type}}{N_{sessions,type}} \times 100\%
$$
alebo:
$$
TypeAffectedRate =
\frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\%
$$
## Rez podľa času: dynamika a mesiace
Graf dennej dynamiky ukazuje, koľko anomálnych relácií sa udialo vo flotile každý deň okna. Vidno „výbuchy" — dni zlej komunikácie v sieti celkovo. Vrchol, ktorý sa zhoduje s registrom incidentov, je typicky séria problémov základňovej stanice v jednej lokalite.
Rez podľa kalendárnych mesiacov pomáha vidieť sezónnosť alebo dlhodobý trend. Hromadný mesačný vrchol zodpovedá tej istej sérii incidentov, ktorú vidno v dennej dynamike; plynulý rast v čase je kandidátom na degradáciu komunikácie alebo batérie.
### Účel
Rez podľa mesiacov ukazuje sezónnosť alebo dlhodobý trend dlhých relácií.
### Ukazovateľ mesiaca
$$
N_{long,month} =
count(long\_sessions \; in \; month)
$$
### Podiel mesiaca
Ak je potrebné zobraziť podiel:
$$
Share_{month} =
\frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\%
$$
### Interpretácia
| Obraz | Možné vysvetlenie |
| --------------------- | --------------------------------------------------- |
| ostrý mesačný výkyv | zmena siete, hromadné zlyhanie, sezónne zaťaženie |
| postupný rast | degradácia komunikácie alebo batérie |
| výkyv v zime | poveternostné podmienky, zaťaženie siete, napájanie |
| výkyv po aktualizácii | firmvér, nastavenia, rozvrh dopytovania |
## Farebné zvýraznenie konkrétnych relácií
Pri rozvinutí uzla sa jeho jednotlivé dlhé relácie zvýrazňujú podľa sily prekročenia individuálneho prahu a zobrazujú sa presné hodnoty RSSI a `Btm` v okamihu každej dlhej relácie. Práve to potrebuje výjazdová brigáda: nízke RSSI poukazuje na problém s rádiovým signálom, zatiaľ čo normálne napätie batérie batériu vylučuje.
### Ratio prekročenia
$$
Ratio_i =
\frac{d_i}{UpperFence}
$$
### Interpretácia
| Ratio | Farba / úroveň |
| ----: | ------------------- |
| 1–2× | slabé prekročenie |
| 2–5× | stredné prekročenie |
| ≥5× | silné prekročenie |
To pomáha rýchlo odlíšiť mierne dlhé relácie od extrémnych.
## Čo robiť podľa výsledkov správy
### Ak je príčina základňová stanica
Preveriť:
- kvalitu pokrytia v lokalite;
- alternatívneho mobilného operátora;
- externú anténu;
- opakovač;
- opakovateľnosť incidentov podľa dní;
- susedné uzly tej istej lokality;
- preťaženie siete v konkrétnych hodinách.
### Ak je príčina lokálny uzol
Preveriť:
- anténu;
- SIM-kartu;
- modem;
- napájanie;
- batériu;
- konektory;
- miesto inštalácie;
- rušenie;
- verziu firmvéru;
- nastavenia rozvrhu prenosu.
### Ak je príčina slabý signál
Činnosti:
- zmerať RSSI na mieste;
- skúsiť premiestniť anténu;
- skontrolovať smerovanie antény;
- preveriť alternatívneho operátora;
- nainštalovať externú anténu alebo opakovač.
### Ak je príčina batéria
Činnosti:
- skontrolovať `Btm` na mieste;
- v prípade potreby vymeniť batériu;
- skontrolovať prúd spotreby;
- skontrolovať frekvenciu opakovaných pokusov;
- skontrolovať, či zariadenie nepreťažuje sieť opakovanými pokusmi.
### Ak je príčina model / firmvér
Činnosti:
- zoskupiť uzly podľa verzie SW;
- skontrolovať poznámky k vydaniu dodávateľa;
- vyžiadať známe problémy;
- porovnať s inými modelmi v rovnakých lokalitách;
- otestovať komunikačný režim v laboratóriu.
## AI-komentár
Voliteľný AI-komentár číta RCA a píše krátky, ľudsky čitateľný plán výjazdu pre brigádu. Je to **jazykové vysvetlenie, nie zdroj diagnostiky** — všetky čísla a príčiny určujú vzorce a pravidlá vyššie.
### Čo AI môže robiť
- stručne prerozprávať RCA;
- vysvetliť hlavného pravdepodobného vinníka;
- vyzdvihnúť top uzly;
- sformulovať plán výjazdu;
- vysvetliť rez podľa modelov.
### Čo AI nemôže robiť
AI **nemôže**:
- zmeniť IQR-prah;
- zmeniť zoznam dlhých relácií;
- zmeniť score;
- určiť skutočnú príčinu bez dát;
- nahradiť rádiotechnickú obhliadku;
- nahradiť výjazd;
- byť dôkazovou bázou.
Analýza je deterministická. AI-komentár treba čítať len ako vysvetľujúci text — všetky číselné
závery určujú vzorce a pravidlá.
## Typické chyby interpretácie
### Chyba: dlhá relácia = zlý prístroj
Nesprávne. Dlhá relácia môže byť spôsobená sieťou, základňovou stanicou, slabým signálom, serverovou rutinou, lokálnou anténou, SIM-kartou alebo batériou.
### Chyba: mnoho anomálií u modelu = model je zlý
Nesprávne. Treba normovať na počet zariadení, počet relácií, lokality a mobilných operátorov.
### Chyba: žiadne anomálie = všetko je v poriadku
Nesprávne, ak nie sú dáta relácií alebo je pokrytie príliš nízke.
### Chyba: vysoké RSSI vylučuje problém komunikácie
Nie vždy. Možné sú problémy operátora, preťaženie, firmvér, serverové prijímanie, opakované prenosy alebo chyby protokolu.
### Chyba: strata batérie = presná spotreba batérie
Nesprávne. Je to odhad postavený na nadbytočnom čase prenosu a podmienečnom prúde.
### Chyba: jedna extrémne dlhá relácia robí uzol hlavným problémovým
Nie vždy. Score zohľadňuje nielen maximum, ale aj podiel, priemerné trvanie a počet dlhých relácií.
## Minimálne kritériá plnohodnotnej správy
Správa sa považuje za metodicky úplnú, ak obsahuje:
- obdobie analýzy;
- pokrytie flotily;
- stav data-gate;
- počet uzlov vo flotile;
- počet opýtaných uzlov;
- počet uzlov s dátami relácií;
- počet uzlov, ktoré prešli IQR-prahom;
- počet relácií vo výbere;
- počet dlhých relácií;
- počet uzlov s anomáliami;
- maximálne trvanie relácie;
- počet hodinových incidentov;
- distribúciu RCA-hypotéz;
- vzorec IQR-prahu;
- vzorec score uzla;
- vzorec straty batérie;
- pravidlá RCA-klasifikácie;
- tabuľku top problémových uzlov;
- rez podľa dní;
- rez podľa typov prepočítavačov;
- rez podľa mesiacov;
- disclaimer o približnosti straty batérie;
- disclaimer o úlohe AI;
- odporúčania k činnostiam.
## Súhrnný vzorec správy
Pre každý uzol:
$$
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
$$
Odhad nadbytočnej spotreby batérie:
$$
ExtraTime_{total} =
\sum_{d_i \in LongSessions}
max(0,\;d_i - MedianDuration)
$$
$$
BatteryLoss_{mAh} =
\frac{340 \times ExtraTime_{total}}{3600}
$$
Zoskupenie incidentov:
$$
Bucket(t) =
floor(t / 1h) \times 1h
$$
$$
Incident =
Bucket \; where \; N_{unique\_stations} \ge 5
$$
## Odporúčaný disclaimer
```text
Správa identifikuje anomálne dlhé komunikačné relácie vzhľadom na individuálnu
normu každého uzla. Výsledok sa používa na prioritizáciu diagnostiky
komunikácie, antén, SIM-kariet, napájania, operátorov a základňových staníc.
Správa nie je dôkazom poruchy konkrétneho prístroja bez výjazdu a nehodnotí
správnosť obchodného merania plynu.
```
## Súvis s inými správami
| Ak je potrebné pochopiť | Použiť |
| -------------------------------------------------------- | ---------------------- |
| ktoré uzly dlho držia komunikáciu a spotrebúvajú batériu | túto správu |
| ktoré uzly nemajú komunikáciu alebo archív | Najproblémovejšie uzly |
| či možno uzatvoriť obdobie konkrétneho uzla | Analytika spotreby |
| či je podozrenie z nedomerania | Podozrivé uzly |
| prečo je konkrétny uzol podozrivý | Obchádzanie merania |
| kedy meniť batérie | Predpoveď batérie |
Toto rozdelenie zabraňuje miešaniu dlhých komunikačných relácií s obchodnými, metrologickými a forenznými závermi.