Dlouhé relace

Uzly flotily, jejichž komunikační relace probíhají abnormálně dlouho vzhledem k jejich vlastní normě, s prahy IQR pro jednotlivé uzly, skóre závažnosti a analýzou hlavní příčiny na základě incidentů.

Report Dlouhé relace analyzuje telemetrické komunikační relace napříč celou flotilou měřicích uzlů a identifikuje zařízení, lokality, dny a typy přepočítávačů, kde komunikace funguje nestabilně nebo zabírá nadměrný čas k přenosu dat.

Záhlaví reportu nese sedm KPI: společnost, pokrytí flotily, připravenost dat, počet uzlů s anomáliemi, počet anomálních relací, maximální dobu trvání relace, celkový počet hodinových incidentů a období analýzy. Hlavním číslem je počet uzlů s anomáliemi z celkového počtu ve flotile; incidenty jsou hodinové shluky, kdy pět nebo více uzlů má dlouhé relace současně.

Report odpovídá na praktické provozní otázky:

které uzly mají komunikační relace, jež jsou příliš dlouhé;
které relace jsou pro tento konkrétní uzel považovány za anomální;
kde je problém lokální: anténa, SIM karta, napájení, modem, místo instalace;
kde problém vypadá jako incident základnové stanice nebo mobilního operátora;
zda se napříč flotilou vyskytují hromadné hodinové incidenty;
které dny byly nejproblematičtější;
které typy přepočítávačů častěji upadají do dlouhých relací;
kolik energie bylo přibližně spotřebováno na opakované přenosy nebo prodloužené přenosy;
které uzly vyžadují výjezd do terénu s externí anténou, opakovačem nebo kontrolou SIM;
kde je třeba zkontrolovat mobilního operátora nebo kvalitu pokrytí v konkrétní lokalitě.

Kam report patří

Report patří do provozní diagnostiky telemetrie. Nesmí směšovat dvě odlišné situace:

Žádná komunikace vůbec. Uzel se nepřipojuje, nejsou žádná data.
Komunikace existuje, ale relace jsou příliš dlouhé. Uzel data přenáší, ale dělá to pomalu, nestabilně nebo s opakováním.

Tento report analyzuje druhou situaci. Tam, kde není žádná komunikace, archiv ani data, použijte report Top problémové uzly; tam, kde potřebujete ověřit, zda jsou data jednoho uzlu vhodná k měření, použijte Analytiku spotřeby.

Pro koho je report určen

Role	Co z reportu získá
Provozní manažer	celkový obraz flotily, počet uzlů s anomáliemi, hromadné incidenty
Komunikační inženýr	seznam uzlů se špatným RSSI, dlouhými relacemi a lokálními problémy
Dispečer	prioritizovaný seznam tiketů a problémových dnů
Terénní četa	top uzly ke kontrole antény, SIM, napájení a místa instalace
Integrační inženýr	diagnostika připravenosti dat, pokrytí API a případy chybějících dat relací
Specialista nákupu	srovnávací rozpad podle typu přepočítávače
Analytik flotily	hypotézy hlavní příčiny: základnová stanice, operátor, firmware, lokální uzel

Co report nedělá

Report nesmí:

prokázat, že konkrétní modem je vadný, bez výjezdu do terénu;
považovat dlouhou relaci za přímý důkaz špatného zařízení;
automaticky obviňovat server nebo mobilního operátora;
směšovat „žádná data“ s „žádné anomálie“;
porovnávat dobu trvání relací všech uzlů jediným společným prahem;
považovat krátké období s několika málo relacemi za statisticky spolehlivé;
vyvozovat závěry o kvalitě modelu zařízení bez zohlednění počtu zařízení ve vzorku;
nahrazovat radiotechnický průzkum místa instalace;
považovat odhad ztráty baterie za přesné měření;
používat komentář AI jako zdroj diagnostiky.

Klíčové pojmy

Pojem	Význam
Komunikační relace	jedna epizoda připojení zařízení k systému přenosu dat
Doba trvání relace	čas od zahájení relace po její dokončení
Normální relace	relace, jejíž doba trvání spadá do individuální normy uzlu
Dlouhá relace	relace, jejíž doba trvání překračuje individuální práh IQR uzlu
`IQR`	mezikvartilové rozpětí: `Q3 − Q1`
`Q1`	první kvartil dob trvání relací
`Q3`	třetí kvartil dob trvání relací
`UpperFence`	horní mez normy: `Q3 + 1.5 × IQR`
`RSSI`	úroveň rádiového signálu, dBm
`CSQ`	index kvality GSM signálu, lze převést na dBm
`Btm`	napětí baterie nebo ukazatel napájení zařízení
`Long share`	podíl dlouhých relací mezi všemi relacemi uzlu
`Severity score`	finální posouzení míry problému uzlu podle dlouhých relací
Incident	hodinový shluk, kdy se dlouhé relace objevily současně u několika uzlů
`RCA`	analýza pravděpodobné příčiny: základnová stanice, síť, server, firmware, lokální uzel
`Battery loss`	přibližný odhad energie spotřebované na nadměrnou dobu přenosu

Obecná logika reportu

Report je sestaven jako analýza komunikačních relací v rámci celé flotily.

text

Seznam uzlů flotily
→ načtení komunikačních relací
→ kontrola připravenosti dat
→ individuální norma relace pro každý uzel
→ vyhledání dlouhých relací pomocí IQR
→ výpočet skóre pro každý uzel
→ seskupení dlouhých relací do hodinových incidentů
→ určení pravděpodobné příčiny RCA
→ rozdělení hypotéz mezi uzly
→ top problémové uzly
→ rozpad podle typu přepočítávače
→ rozpad podle dnů a měsíců
→ doporučení pro provoz

Hlavní princip:

text

dlouhá relace je definována vzhledem k normě konkrétního uzlu,
nikoli vzhledem ke společnému pevnému prahu napříč celou flotilou.

To má význam, protože různá zařízení, regiony, mobilní operátoři a režimy dotazování mohou mít odlišné normální doby trvání relací.

Parametry spuštění

Parametr	Význam
Datum od / Datum do	hranice okna analýzy
Okno analýzy, dny	záložní okno použité, když jsou data prázdná (výchozí 30)
Uzlů na typ přepočítávače	velikost vzorku na typ; `0` znamená všechny uzly flotily
Minimum relací na uzel pro IQR	minimální počet relací, který uzel potřebuje k zařazení (výchozí 30)
Počet problémových uzlů v reportu	velikost tabulky top-N (výchozí 50)
Analýza LLM	volitelný narativ AI vysvětlující výsledky
Energetická společnost	omezuje analýzu na flotilu jednoho dodavatele

Vstupní data

Hlavní data

Data	K čemu jsou potřeba
Seznam uzlů	určení analyzované flotily
Typ přepočítávače	sestavení rozpadu podle modelu
`Equipment ID`	načtení relací konkrétního zařízení
Komunikační relace	jádro reportu
Čas zahájení relace	seskupení podle dnů, měsíců a hodin
Doba trvání relace	hlavní analyzovaný ukazatel
`RSSI` / `CSQ`	odhad kvality rádiového signálu
`Btm` / baterie	odhad vlivu napájení
Organizace / lokalita	přiřazení incidentu: lokální zákazník, základnová stanice, flotila

Minimální požadovaná sada

Pro správnou analýzu uzlu je potřeba následující:

identifikátor zařízení;
alespoň minimální počet relací;
doba trvání každé relace;
časové razítko každé relace.

Pokud chybí doba trvání relace, tato relace se neúčastní analýzy IQR.

Připravenost dat: datová brána

Před výpočtem anomálií report kontroluje, zda lze analýzu vůbec provést. Blok připravenosti dat zobrazuje velikost flotily, velikost po filtru společnosti, kolik uzlů vrátilo data relací a kolik z nich prošlo minimem relací pro IQR. To je kriticky důležitá diagnostika — bez ní lze snadno zaměnit „žádné anomálie“ za „žádná data k analýze“.

Hlavní ukazatele připravenosti

Ukazatel	Vzorec / hodnota
Uzly ve flotile	`N_park`
Uzly ve vzorku	`N_sampled`
Uzly s daty relací	`N_with_data`
Uzly, které prošly minimem relací	`N_qualified`
Celkem relací	`N_sessions`
Volání API	`N_calls`
Chyby API	`N_errors`
Chybovost API	`N_errors / N_calls × 100%`
Pokrytí dat	`N_with_data / N_sampled × 100%`
Pokrytí vzorku IQR	`N_qualified / N_sampled × 100%`

Chybovost API

APIErrorRate = \frac{N_{errors}}{N_{calls}} \times 100\%

Pokrytí dat

Coverage_{with\_data} = \frac{N_{with\_data}}{N_{sampled}} \times 100\%

Pokrytí uzly vhodnými pro IQR

Coverage_{qualified} = \frac{N_{qualified}}{N_{sampled}} \times 100\%

Stavy připravenosti

Stav	Podmínka	Co to znamená
`OK`	existuje dostatečný vzorek pro IQR	report lze číst jako funkční
`DEGRADED`	vzorek je malý, ale analýza je možná	závěry jsou opatrné
`INCONCLUSIVE`	mnoho chyb nebo kriticky nízké pokrytí	závěry o anomáliích jsou nespolehlivé
`NO_DATA`	žádná data relací	analýza je nemožná
`NO_FLEET`	žádné uzly po filtrování	není co analyzovat

Kritické podmínky

Analýza je považována za nemožnou, pokud:

APIErrorRate \ge 50\%

nebo:

Coverage_{with\_data} < 5\%

nebo:

N_{qualified} = 0

Minimum relací na uzel

Pro spolehlivou analýzu IQR musí mít každý uzel dostatečný počet relací.

Minimální práh

Ve výchozím nastavení:

N_{sessions,station} \ge 30

Pokud má uzel méně relací, individuální norma se považuje za statisticky nespolehlivou a uzel neprojde filtrem IQR.

Proč je minimum potřeba

IQR využívá odhady kvartilů. Při malém počtu pozorování se kvartil stává nestabilním:

jedna náhodná dlouhá relace může práh nadhodnotit;
jedno krátké období komunikace může práh podhodnotit;
stává se nemožným odlišit normu uzlu od náhodnosti.

Individuální norma doby trvání relace

Proč je norma individuální

Nelze použít jediný společný práh pro celou flotilu, např. „všechny relace delší než 10 minut jsou špatné“. Různé uzly mají různé komunikační podmínky:

různé typy přepočítávačů;
různé mobilní operátory;
různé RSSI;
různé objemy archivu;
různé rozvrhy dotazování;
různá místa instalace;
různé antény.

Proto má každý uzel vypočtenou vlastní statistickou normu.

Výběr platných dob trvání

Pro každý uzel se berou pouze kladné doby trvání:

D = \{d_i \mid d_i > 0\}

kde:

d_i — doba trvání i-té relace v sekundách.

Kvartily

Doby trvání se seřadí vzestupně.

D_{sorted} = sort(D)

První kvartil:

Q1 = percentile(D, 25\%)

Medián:

Q2 = median(D)

Třetí kvartil:

Q3 = percentile(D, 75\%)

Mezikvartilové rozpětí

IQR = Q3 - Q1

Horní mez normy podle Tukeyho hradby

Pro každý uzel se počítá individuální horní mez normy:

UpperFence = Q3 + 1.5 \times IQR

Jde o klasické pravidlo Tukeyho hradeb pro detekci odlehlých hodnot.

Dlouhá relace

Relace se považuje za abnormálně dlouhou, pokud:

d_i > UpperFence

kde:

d_i — doba trvání relace;
UpperFence — individuální práh tohoto uzlu.

Základní ukazatele uzlu

Pro každý uzel se počítají následující ukazatele.

Celkový počet relací

N_{total} = count(D)

Počet dlouhých relací

N_{long} = count(d_i > UpperFence)

Podíl dlouhých relací

Pct_{long} = \frac{N_{long}}{N_{total}} \times 100\%

Průměrná doba trvání všech relací

AvgDuration = \frac{\sum d_i}{N_{total}}

Průměrná doba trvání dlouhých relací

AvgLongDuration = \frac{\sum_{d_i > UpperFence} d_i}{N_{long}}

Maximální doba trvání

MaxLongDuration = max(d_i \mid d_i > UpperFence)

Průměrné RSSI

RSSI_{avg} = \frac{\sum RSSI_i}{N_{RSSI}}

kde N_RSSI je počet relací s dostupnou hodnotou RSSI.

Skóre problému uzlu

Význam skóre

Skóre ukazuje, jak problematický je uzel z hlediska dlouhých relací. Zohledňuje tři dimenze:

podíl dlouhých relací;
o kolik dlouhé relace překračují normu;
absolutní počet dlouhých relací.

Tento přístup zabraňuje nadhodnocení jednorázové odlehlé hodnoty a zabraňuje podhodnocení uzlu s velkým počtem mírně dlouhých relací.

Komponenta A — podíl dlouhých relací

A = min(100,\;4 \times Pct_{long})

Interpretace:

Podíl dlouhých	A
5%	20
10%	40
25%	100
>25%	100

Komponenta B — relativní doba trvání

B = min \left( 100,\; 8 \times \frac{AvgLongDuration}{max(1, MedianDuration)} \right)

kde MedianDuration je mediánová doba trvání relace uzlu.

Interpretace:

AvgLong / Median	B
2×	16
5×	40
10×	80
12.5×	100

Komponenta C — počet dlouhých relací

C = min(100,\;N_{long})

To znamená, že 100 nebo více dlouhých relací dává maximální příspěvek z této komponenty.

Finální skóre

Score = 0.5 \times A + 0.3 \times B + 0.2 \times C

kde:

A — podíl dlouhých relací;
B — relativní doba trvání dlouhých relací;
C — absolutní počet dlouhých relací.

Finální skóre je omezeno rozsahem:

0 \le Score \le 100

Interpretace skóre

Score	Úroveň
≥ 80	kritický komunikační uzel
60–80	vysoká priorita
40–60	střední priorita
20–40	sledování / plánovaná kontrola
< 20	slabý signál

Odhad ztráty baterie při dlouhých relacích

Význam

Dlouhá relace prodlužuje dobu přenosu a může navíc spotřebovat baterii. Report poskytuje přibližný odhad nadměrného výdaje energie. Nejde o přesné měření baterie, nýbrž o provozní odhad.

Nadměrná doba přenosu

Pro každou dlouhou relaci se počítá překročení mediánové normy uzlu:

ExtraTime_i = max(0,\;d_i - MedianDuration)

Celková nadměrná doba:

ExtraTime_{total} = \sum_{i \in LongSessions} ExtraTime_i

Přenosový proud

Pro přibližný odhad se používá základní přenosový proud:

I_{TX} = 340 \; mA

Ztráta baterie

BatteryLoss_{mAh} = \frac{I_{TX} \times ExtraTime_{total}}{3600}

kde:

ExtraTime_total — v sekundách;
I_TX — proud v miliampérech;
výsledek — v mAh.

Pro zobrazení v Ah:

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

Omezení

Tento odhad nezohledňuje:

skutečný proudový profil konkrétního modelu;
režim spánku;
opakování na úrovni modemu;
výkon vysílače;
teplotu;
stáří baterie;
kapacitu baterie;
kvalitu sítě v okamžiku přenosu.

Měl by být proto čten jako odhad řádové velikosti, nikoli jako laboratorní měření.

RSSI a CSQ

RSSI

RSSI ukazuje úroveň rádiového signálu v dBm. Čím blíže je hodnota nule, tím silnější je signál.

Přibližná interpretace:

RSSI	Hodnocení
≥ −65 dBm	dobrý signál
−65…−75 dBm	přijatelný
−75…−85 dBm	slabý
< −85 dBm	velmi slabý

CSQ

Některá zařízení nepřenášejí RSSI v dBm, ale CSQ — index kvality GSM signálu. Pokud hodnota vypadá jako CSQ, lze ji převést:

RSSI_{dBm} = -113 + 2 \times CSQ

Příklad:

CSQ = 29

RSSI = -113 + 2 \times 29 = -55 \; dBm

Lokálně slabý signál

Pokud:

RSSI_{avg} < -85 \; dBm

a anomálie uzlu se neshodují s hromadnými incidenty flotily, lze příčinu klasifikovat jako:

text

slabý signál v místě instalace

Seskupení dlouhých relací do incidentů

Anomálie se seskupují do hodinových oken. Pokud několik uzlů obdrželo dlouhé relace ve stejnou hodinu, nejde o lokální problém uzlu, ale o incident sítě, serveru nebo operátora. Hypotéza se určuje automaticky podle šíře pokrytí — počtu uzlů, modelů a zákazníků v okně.

Proč je seskupení potřeba

Pokud se dlouhé relace objevily u mnoha uzlů ve stejnou hodinu, nejde nejspíše o lokální problém jednoho zařízení. Mohlo by jít o:

problém základnové stanice;
lokální přetížení operátora;
hromadný síťový incident;
plánovanou operaci serveru;
zvláštnost firmwaru konkrétního modelu.

Hodinový koš

Každá dlouhá relace se umístí do hodinového koše:

Bucket(t) = floor\left( \frac{t}{1h} \right) \times 1h

To znamená, že všechny události v rámci jedné hodiny spadají do jednoho koše.

Incident

Hodinový koš je považován za incident, pokud je zasaženo alespoň:

N_{stations,bucket} \ge 5

uzlů.

Ukazatele incidentu

Pro každý incident se počítá následující:

Ukazatel	Vzorec
počet uzlů	`count(unique station_id)`
počet modelů	`count(unique equipment_type)`
počet zákazníků / lokalit	`count(unique customer_id)`
počet relací	`count(long sessions in bucket)`
průměrné RSSI	`average(RSSI)`
top modely	`top equipment types by count`

RCA: přiřazení příčiny incidentu

Souhrn flotily identifikuje hlavního viníka — vysílač, server, síť, firmware nebo lokální uzel — poskytuje přiřazení viny napříč uzly s anomáliemi a vytváří akční plán. Volitelný narativ AI ve spodní části vysvětluje čísla srozumitelným jazykem, ale nemění je.

RCA je klasifikace pravděpodobné příčiny dlouhých relací.

Možné hypotézy

Hypotéza	Význam
`Server driver`	hromadné selhání sběrného ovladače
`Server routine`	pravidelná operace serveru nebo údržba
`Network outage`	selhání mobilního operátora
`Cell tower`	problém s konkrétní základnovou stanicí nebo lokalitou
`Firmware`	problém modelu zařízení / firmwaru
`Local signal`	slabý signál v místě instalace
`Battery low`	nízké napájení / degradace baterie
`Isolated device`	lokální porucha konkrétního uzlu
`Mixed causes`	smíšené příčiny

Rozsáhlý serverový incident

Incident je klasifikován jako serverový, pokud je současně zasaženo mnoho uzlů, mnoho modelů a mnoho zákazníků. Podmíněně:

N_{stations} \ge ServerWideStations

N_{models} \ge ServerWideModels

N_{customers} \ge ServerWideCustomers

V reportu to znamená:

text

rozsáhlý incident flotily, nepodobá se lokálnímu problému jediného uzlu.

Výpadek sítě operátora

Pokud je zasaženo několik modelů a několik zákazníků, ale rozsah nedosahuje na selhání serveru:

N_{models} \ge 3

N_{customers} \ge 3

pak je hypotéza:

text

selhání mobilní sítě / incident operátora

Problém základnové stanice

Pokud je zasaženo mnoho uzlů, ale patří k jedné nebo dvěma lokalitám / zákazníkům:

N_{customers} \le 2

N_{stations} \ge CellMinStations

pak je hypotéza:

text

problém základnové stanice nebo lokální problém pokrytí

Problém firmwaru nebo modelu

Pokud je zasažen jeden model, ale napříč různými zákazníky:

N_{models} = 1

N_{customers} \ge 3

pak je hypotéza:

text

zvláštnost firmwaru / modelu zařízení

Smíšené příčiny

Pokud podmínky nevedou k jednoznačné klasifikaci, incident obdrží stav:

text

smíšené příčiny

Opakující se serverová rutina

Někdy se hromadné serverové incidenty dějí ve stejnou hodinu dne.

Podmínka

Pokud existují alespoň tři rozsáhlé serverové incidenty ve stejnou hodinu dne:

N_{server\_incidents,same\_hour} \ge 3

lze je klasifikovat jako:

text

serverová rutina

Význam

To může naznačovat pravidelnou noční úlohu, údržbu archivu, dávkový proces nebo hromadnou operaci, která ovlivňuje dobu trvání relace.

Přiřazení příčiny na uzel

Po vyhledání incidentů flotily report určuje, co u každého uzlu převažuje: externí incidenty, nebo lokální problém.

Podíl anomálií uzlu spadajících do incidentů flotily

InIncidentPct = \frac{N_{long,in\_incidents}}{N_{long}} \times 100\%

Pokud se většina anomálií shodovala s incidenty flotily

Pokud:

InIncidentPct \ge 70\%

pak se dominantní příčina uzlu přebírá z incidentu flotily:

text

network_outage / cell_tower / firmware / server

To znamená:

text

zařízení nejspíše není hlavním viníkem; trpělo společně s ostatními.

Kontrola vybité baterie

Pokud anomálie nejsou vysvětleny incidenty flotily, kontroluje se napájení. Nechť:

Btm_{first}

je první dostupná hodnota baterie v dlouhých relacích a:

Btm_{last}

je poslední dostupná hodnota. Pokles:

BtmDrop = Btm_{first} - Btm_{last}

Hypotéza battery_low je možná, pokud:

Btm_{first} < 3500 \; mV

BtmDrop > 200 \; mV

Kontrola lokálně slabého signálu

Pokud:

RSSI_{avg} < -85 \; dBm

pak je hypotéza:

text

slabý signál v místě instalace

Izolovaná porucha uzlu

Pokud:

anomálie se neshodují s incidenty flotily;
baterie obraz nevysvětluje;
RSSI není kriticky slabé;

pak se příčina klasifikuje jako:

text

lokální porucha uzlu

Rozdělení hypotéz napříč flotilou

Pro každý uzel se vybírá dominantní příčina. Když většina uzlů trpěla incidenty flotily, uzel samotný za to nemůže; pouze menšina má izolovaný lokální problém. To mění akční plán: hlavní úsilí směřuje na základnové stanice a operátora, nikoli na hromadný výjezd do terénu ke každému uzlu s anomáliemi.

Report ukazuje, kolik uzlů je přiřazeno k jednotlivým dominantním příčinám.

Vzorec podílu hypotézy

Share_{hypothesis} = \frac{N_{stations,hypothesis}}{N_{stations,with\_anomalies}} \times 100\%

Skupiny příčin

Pro manažerský souhrn lze hypotézy seskupit:

Skupina	Zahrnuje
síť / server	`server_driver`, `server_routine`, `network_outage`, `cell_tower`
lokální problémy zařízení	`isolated_device`, `local_signal`, `battery_low`
model / firmware	`firmware`
smíšené	`mixed`

Interpretace

Převažuje	Co dělat
`Cell tower`	zkontrolovat pokrytí, operátora, externí antény u zasažených zákazníků
`Local signal`	výjezd do terénu ke konkrétnímu uzlu, anténa, opakovač, místo instalace
`Isolated device`	diagnostika modemu, SIM, napájení, firmwaru
`Firmware`	zkontrolovat verzi softwaru a kontaktovat dodavatele
`Server routine`	zkontrolovat pravidelné procesy platformy
`Network outage`	dotázat se mobilního operátora podle času a zóny

Top problémové uzly

Tabulka top problémových uzlů řadí uzly podle kompozitního skóre (0–100) sestaveného z podílu dlouhých relací, jejich průměrné doby trvání a jejich počtu. Kliknutí na řádek rozbalí nejdelší relace uzlu s hodnotami RSSI a Btm — používá se k plánování výjezdu do terénu.

Účel

Tabulka ukazuje, kam jet nebo co zkontrolovat jako první.

Sloupce tabulky

Sloupec	Význam
Uzel	název a ID uzlu
Přepočítávač	typ zařízení
Relace	celkový počet platných relací
Dlouhé	počet abnormálně dlouhých relací
Podíl	procento dlouhých relací
Průměr dlouhých	průměrná doba trvání dlouhých relací
Maximální relace	nejhorší nalezená relace
Průměr `RSSI`	kvalita rádiového signálu
Ztráta baterie	odhadovaná nadměrná energie
Score	kompozitní skóre problému

Jak číst top

Vysoké skóre může vzniknout z různých důvodů:

velký podíl dlouhých relací;
velmi dlouhé jednotlivé relace;
velký absolutní počet dlouhých relací;
kombinace těchto faktorů.

Pro plánování výjezdu do terénu čtěte nejen skóre, ale také:

RSSI;
hypotézu RCA;
ztrátu baterie;
maximální relaci;
zda spadá do incidentů flotily;
typ přepočítávače.

Top problémové dny

Všechny anomální relace se seskupují podle kalendářního dne. Den s největším počtem anomálií je nejpravděpodobněji ten, kdy došlo k incidentu flotily. Každý den se rozbalí do seznamu uzlů s jejich anomáliemi, maximální relací a odkazy. To je užitečné pro vyšetřování hromadných událostí a kontrolu opakování.

Účel

Rozpad podle dnů ukazuje dny, kdy se dlouhé relace objevily hromadně napříč flotilou.

Ukazatele dne

Ukazatel	Význam
Datum	kalendářní den
Dlouhé relace	počet dlouhých relací za den
Uzly	kolik uzlů je zasaženo
Průměr dlouhých	průměrná doba trvání dlouhých relací
Maximální relace	nejhorší případ dne
Nejhorší uzel	uzel s maximální relací

Interpretace

Obraz	Možná příčina
mnoho uzlů v jediný den	síťový incident nebo incident flotily
jeden uzel každý den	lokální problém
špička o víkendu	síť operátora / údržbové práce
špičky ve stejný čas	pravidelná úloha nebo rozvrh
měsíční růst	degradace sítě, sezónní přetížení, změna režimu dotazování

Rozpad podle typu přepočítávače

Blok pokrytí ukazuje, co bylo z flotily zkontrolováno pro každý typ přepočítávače: kolik uzlů je ve vzorku, kolik vrátilo data, kolik prošlo IQR a kolik vykazuje anomálie. Pokud typ vykazuje „norma“, data dorazila, ale žádné anomálie nebyly nalezeny. „Žádná data“ znamená, že typ nevrací dobu trvání relace v API — pro některé modely je to normální.

Podrobný rozpad podle typu přepočítávače

Rozbalte typ, abyste viděli všechny jeho uzly s anomáliemi; rozbalte uzel, abyste viděli jeho konkrétní dlouhé relace s časem, dobou trvání, RSSI a Btm. Barva zvýraznění relace závisí na tom, o kolik je relace delší než norma uzlu.

Účel

Rozpad podle typu přepočítávače ukazuje, které modely častěji upadají do abnormálně dlouhých relací.

Ukazatele podle typu

Ukazatel	Význam
Ve vzorku	kolik uzlů tohoto typu je ve flotile
S daty	kolik uzlů vrátilo data relací
Prošlo IQR	kolik uzlů má minimum relací
Anomálie	počet dlouhých relací
Stav	norma / anomálie / žádná data

Důležité omezení

Typy přepočítávačů nelze přímo porovnávat pouze podle počtu anomálií. Je třeba zohlednit:

kolik zařízení tohoto typu je ve flotile;
kolik z nich vrátilo data;
kolik prošlo minimem relací;
kde jsou nainstalována;
ve kterých sítích pracují;
zda mají stejný rozvrh dotazování;
zda jsou soustředěna u jediného zákazníka.

Normalizovaný podíl anomálií podle typu

Pro správné porovnání lze použít:

TypeAnomalyRate = \frac{N_{long,type}}{N_{sessions,type}} \times 100\%

nebo:

TypeAffectedRate = \frac{N_{stations\_anomalous,type}}{N_{stations\_qualified,type}} \times 100\%

Rozpad podle času: dynamika a měsíce

Graf denní dynamiky ukazuje, kolik anomálních relací se vyskytlo napříč flotilou v každý den okna. Jsou viditelné „záblesky“ — dny špatné komunikace napříč celou sítí. Špička, která se shoduje s registrem incidentů, je typicky série problémů základnové stanice v jediné lokalitě.

Rozpad podle kalendářních měsíců pomáhá vidět sezónnost nebo dlouhodobý trend. Hromadná měsíční špička odpovídá téže sérii incidentů viděných v denní dynamice; postupný růst v čase je kandidátem na degradaci komunikace nebo baterie.

Účel

Rozpad podle měsíců ukazuje sezónnost nebo dlouhodobý trend dlouhých relací.

Ukazatel měsíce

N_{long,month} = count(long\_sessions \; in \; month)

Podíl měsíce

Pokud potřebujete zobrazit podíl:

Share_{month} = \frac{N_{long,month}}{\sum N_{long,all\_months}} \times 100\%

Interpretace

Obraz	Možné vysvětlení
ostrá měsíční špička	změna sítě, hromadné selhání, sezónní zátěž
postupný růst	degradace komunikace nebo baterie
zimní špička	povětrnostní podmínky, zátěž sítě, napájení
špička po aktualizaci	firmware, nastavení, rozvrh dotazování

Barevné zvýraznění jednotlivých relací

Při rozbalení uzlu se jeho jednotlivé dlouhé relace zvýrazňují podle míry překročení individuálního prahu a zobrazují se přesné hodnoty RSSI a Btm v okamžiku každé dlouhé relace. To je přesně to, co terénní četa potřebuje: nízké RSSI ukazuje na problém s rádiovým signálem, zatímco normální napětí baterie baterii vylučuje.

Poměr překročení

Ratio_i = \frac{d_i}{UpperFence}

Interpretace

Ratio	Barva / úroveň
1–2×	slabé překročení
2–5×	střední překročení
≥5×	silné překročení

To pomáhá rychle odlišit mírně dlouhé relace od extrémních.

Co dělat na základě výsledků reportu

Pokud je příčinou základnová stanice

Zkontrolujte:

kvalitu pokrytí v lokalitě;
alternativního mobilního operátora;
externí anténu;
opakovač;
opakování incidentů podle dne;
sousední uzly ve stejné lokalitě;
přetížení sítě v konkrétních hodinách.

Pokud je příčinou lokální uzel

Zkontrolujte:

anténu;
SIM kartu;
modem;
napájení;
baterii;
konektory;
místo instalace;
rušení;
verzi firmwaru;
nastavení rozvrhu přenosu.

Pokud je příčinou slabý signál

Akce:

změřit RSSI na místě;
pokusit se přemístit anténu;
zkontrolovat orientaci antény;
zkontrolovat alternativního operátora;
nainstalovat externí anténu nebo opakovač.

Pokud je příčinou baterie

Akce:

zkontrolovat Btm na místě;
v případě potřeby vyměnit baterii;
zkontrolovat odběrový proud;
zkontrolovat četnost opakování;
zkontrolovat, zda zařízení nepřetěžuje síť opakováními.

Pokud je příčinou model / firmware

Akce:

seskupit uzly podle verze softwaru;
zkontrolovat poznámky k vydání od dodavatele;
vyžádat si známé problémy;
porovnat s jinými modely ve stejných lokalitách;
otestovat komunikační režim v laboratoři.

Komentář AI

Volitelný komentář AI čte RCA a píše krátký, lidsky čitelný plán výjezdu do terénu pro četu. Jde o jazykové vysvětlení, nikoli o zdroj diagnostiky — všechna čísla a příčiny jsou určeny vzorci a pravidly výše.

Co AI dokáže

stručně převyprávět RCA;
vysvětlit hlavního pravděpodobného viníka;
zvýraznit top uzly;
formulovat plán výjezdu do terénu;
vysvětlit rozpad podle modelů.

Co AI nedokáže

AI nemůže:

změnit práh IQR;
změnit seznam dlouhých relací;
změnit skóre;
určit skutečnou příčinu bez dat;
nahradit radiotechnický průzkum;
nahradit výjezd do terénu;
sloužit jako důkazní základ.

Typické chyby interpretace

Chyba: dlouhá relace = špatné zařízení

Nesprávné. Dlouhou relaci může způsobit síť, základnová stanice, slabý signál, serverová rutina, lokální anténa, SIM karta nebo baterie.

Chyba: mnoho anomálií u modelu = model je špatný

Nesprávné. Je třeba normalizovat podle počtu zařízení, počtu relací, lokalit a mobilních operátorů.

Chyba: žádné anomálie = vše je v pořádku

Nesprávné, pokud nejsou žádná data relací nebo je pokrytí příliš nízké.

Chyba: vysoké RSSI vylučuje problém s komunikací

Ne vždy. Mohou existovat problémy operátora, přetížení, firmware, příjem na straně serveru, opakování nebo chyby protokolu.

Chyba: ztráta baterie = přesná spotřeba baterie

Nesprávné. Jde o odhad postavený na nadměrné době přenosu a smluvním proudu.

Chyba: jedna extrémně dlouhá relace činí z uzlu hlavní problém

Ne vždy. Skóre zohledňuje nejen maximum, ale také podíl, průměrnou dobu trvání a počet dlouhých relací.

Minimální kritéria úplného reportu

Report je považován za metodicky úplný, pokud obsahuje:

období analýzy;
pokrytí flotily;
stav datové brány;
počet uzlů ve flotile;
počet dotázaných uzlů;
počet uzlů s daty relací;
počet uzlů, které prošly prahem IQR;
počet relací ve vzorku;
počet dlouhých relací;
počet uzlů s anomáliemi;
maximální dobu trvání relace;
počet hodinových incidentů;
rozdělení hypotéz RCA;
vzorec prahu IQR;
vzorec skóre uzlu;
vzorec ztráty baterie;
pravidla klasifikace RCA;
tabulku top problémových uzlů;
rozpad podle dnů;
rozpad podle typu přepočítávače;
rozpad podle měsíců;
upozornění na přibližnou povahu ztráty baterie;
upozornění na roli AI;
doporučení pro akce.

Konsolidovaný vzorec reportu

Pro každý uzel:

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 nadměrné spotřeby baterie:

ExtraTime_{total} = \sum_{d_i \in LongSessions} max(0,\;d_i - MedianDuration)

BatteryLoss_{mAh} = \frac{340 \times ExtraTime_{total}}{3600}

Seskupení incidentů:

Bucket(t) = floor(t / 1h) \times 1h

Incident = Bucket \; where \; N_{unique\_stations} \ge 5

Doporučené upozornění

text

Report detekuje abnormálně dlouhé komunikační relace vzhledem k individuální
normě každého uzlu. Výsledek se používá k prioritizaci diagnostiky komunikace,
antén, SIM karet, napájení, operátorů a základnových stanic. Report není důkazem
poruchy konkrétního zařízení bez výjezdu do terénu a neposuzuje správnost
komerčního měření plynu.

Vztah k dalším reportům

Pokud potřebujete porozumět	Použijte
které uzly drží komunikaci dlouho a vyčerpávají baterii	tento report
které uzly nemají komunikaci ani archiv	Top problémové uzly
zda lze období uzavřít pro konkrétní uzel	Analytiku spotřeby
zda existuje podezření na podměřování	Podezřelé uzly
proč je konkrétní uzel podezřelý	Obcházení měření
kdy vyměnit baterie	Předpověď baterie

Toto oddělení brání tomu, aby se dlouhé komunikační relace směšovaly s komerčními, metrologickými a forenzními závěry.

Související témata

Průzkumník událostí

Naposledy aktualizováno 23. června 2026

Byla tato stránka užitečná?