Dlhé relácie

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.

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.

Kam správa zapadá

Správa patrí do oblasti prevádzkovej diagnostiky telemetrie. Nesmie miešať dve odlišné situácie:

Žiadna komunikácia. Uzol sa vôbec nepripája, nie sú dáta.
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

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.

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:

podiel dlhých relácií;
nakoľko dlhé relácie presahujú normu;
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

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

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

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

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

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.

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.

Súvisiace témy

Prehliadač udalostí

Naposledy aktualizované 26. júna 2026

Bola táto stránka užitočná?