--- title: 'Dlouhé relace' description: '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ů.' 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'; 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 se sedmi KPI 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ě. Report neposuzuje správnost komerčního měření plynu a není forenzní zprávou o obcházení měření. Analyzuje pouze komunikační relace: dobu trvání, četnost anomálií, rozsah incidentů, kvalitu signálu a pravděpodobnou příčinu dlouhých relací. ## Kam report patří Report patří do provozní diagnostiky telemetrie. Nesmí směšovat dvě odlišné situace: 1. **Žádná komunikace vůbec.** Uzel se nepřipojuje, nejsou žádná data. 2. **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 Diagnostika připravenosti dat 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 $$ „Žádné anomálie“ a „žádná data k analýze“ jsou různé stavy. Pokud data relací chybí, report nesmí uvádět, že nebyly nalezeny žádné anomálie. ## 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. Pokud má uzel obvykle krátké relace, jeho práh bude nízký. Pokud má uzel obvykle delší relace, jeho práh bude vyšší. Report identifikuje anomálii **vzhledem k vlastní normě 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: 1. **podíl dlouhých relací**; 2. **o kolik dlouhé relace překračují normu**; 3. **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 | Skóre nedokazuje příčinu. Vysoké skóre říká, že uzel často a/nebo silně překračuje svou vlastní normu doby trvání relace. **Příčina se určuje samostatně pomocí RCA.** ## 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ů Registr 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 vyšetřování hlavní příčiny 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 $$ a: $$ 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 $$ a: $$ 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 $$ a: $$ 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 $$ a: $$ 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 Rozdělení hypotéz 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 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 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 Pokrytí 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 Dynamika dlouhých relací podle dnů 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 měsíců 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í Nejdelší relace uzlu 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 Plán výjezdu do terénu od 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. Analýza je deterministická. Komentář AI by měl být čten pouze jako vysvětlující text — všechny číselné závěry jsou určeny vzorci a pravidly. ## 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.