Sessioni lunghe

Nodi della flotta le cui sessioni di comunicazione durano in modo anomalo rispetto alla loro stessa norma, con soglie IQR per nodo, un punteggio di gravità e un'analisi delle cause radice basata sugli incidenti.

Il report Sessioni lunghe analizza le sessioni di comunicazione di telemetria sull’intera flotta di nodi di misura e identifica dispositivi, posizioni, giorni e tipi di correttore in cui le comunicazioni funzionano in modo instabile o richiedono un tempo eccessivo per trasmettere i dati.

L’intestazione del report riporta sette KPI: azienda, copertura della flotta, prontezza dei dati, numero di nodi con anomalie, numero di sessioni anomale, durata massima della sessione, numero totale di incidenti orari e periodo di analisi. Il dato in evidenza è il conteggio dei nodi con anomalie sul totale della flotta; gli incidenti sono cluster orari in cui cinque o più nodi presentano sessioni lunghe simultaneamente.

Il report risponde a domande operative concrete:

quali nodi hanno sessioni di comunicazione troppo lunghe;
quali sessioni sono considerate anomale per questo specifico nodo;
dove il problema è locale: antenna, scheda SIM, alimentazione, modem, sito di installazione;
dove il problema appare come un incidente della stazione base o dell’operatore di rete mobile;
se sono presenti incidenti orari massivi sull’intera flotta;
quali giorni sono stati i più problematici;
quali tipi di correttore cadono più spesso in sessioni lunghe;
quanta energia è stata approssimativamente spesa in ritrasmissioni o trasmissioni prolungate;
quali nodi richiedono un sopralluogo con antenna esterna, ripetitore o verifica della SIM;
dove occorre verificare l’operatore di rete mobile o la qualità della copertura in una posizione specifica.

Dove si colloca il report

Il report appartiene alla diagnostica operativa della telemetria. Non deve confondere due situazioni differenti:

Nessuna comunicazione affatto. Il nodo non si connette, non ci sono dati.
La comunicazione esiste, ma le sessioni sono troppo lunghe. Il nodo trasmette i dati ma lo fa lentamente, in modo instabile o con tentativi ripetuti.

Questo report analizza la seconda situazione. Dove non c’è alcuna comunicazione, archivio o dato, utilizza il report Nodi più problematici; dove occorre verificare se i dati di un singolo nodo siano idonei alla misura, utilizza Consumption Analytics.

A chi è destinato il report

Ruolo	Cosa ottiene dal report
Responsabile delle operazioni	quadro complessivo della flotta, numero di nodi con anomalie, incidenti massivi
Ingegnere delle comunicazioni	elenco dei nodi con RSSI scadente, sessioni lunghe e problemi locali
Dispatcher	elenco prioritizzato dei ticket e dei giorni problematici
Squadra di campo	nodi prioritari per verifiche di antenna, SIM, alimentazione e sito di installazione
Ingegnere di integrazione	diagnostica della prontezza dei dati, copertura API e casi di dati di sessione mancanti
Specialista degli acquisti	ripartizione comparativa per tipo di correttore
Analista della flotta	ipotesi sulle cause radice: stazione base, operatore, firmware, nodo locale

Cosa il report non fa

Il report non deve:

dimostrare che uno specifico modem sia difettoso senza un sopralluogo;
considerare una sessione lunga come prova diretta di un dispositivo difettoso;
attribuire automaticamente la colpa al server o all’operatore di rete mobile;
confondere “nessun dato” con “nessuna anomalia”;
confrontare la durata delle sessioni di tutti i nodi con un’unica soglia comune;
considerare statisticamente affidabile un periodo breve con poche sessioni;
trarre conclusioni sulla qualità di un modello di dispositivo senza tenere conto del numero di dispositivi nel campione;
sostituire un’indagine radiotecnica del sito di installazione;
considerare la stima della perdita di batteria come una misura precisa;
utilizzare il commento dell’IA come fonte di diagnostica.

Termini chiave

Termine	Significato
Sessione di comunicazione	un episodio di connessione del dispositivo al sistema di trasmissione dati
Durata della sessione	tempo dall’inizio al completamento della sessione
Sessione normale	una sessione la cui durata rientra nella norma individuale del nodo
Sessione lunga	una sessione la cui durata supera la soglia IQR individuale del nodo
`IQR`	scarto interquartile: `Q3 − Q1`
`Q1`	primo quartile delle durate delle sessioni
`Q3`	terzo quartile delle durate delle sessioni
`UpperFence`	limite superiore della norma: `Q3 + 1.5 × IQR`
`RSSI`	livello del segnale radio, dBm
`CSQ`	indice di qualità del segnale GSM, convertibile in dBm
`Btm`	tensione della batteria o indicatore di alimentazione del dispositivo
`Long share`	quota di sessioni lunghe su tutte le sessioni di un nodo
`Severity score`	valutazione finale del livello di problematicità di un nodo per sessioni lunghe
Incidente	cluster orario in cui le sessioni lunghe sono comparse simultaneamente su più nodi
`RCA`	analisi della causa probabile: stazione base, rete, server, firmware, nodo locale
`Battery loss`	stima approssimativa dell’energia spesa per la durata di trasmissione in eccesso

Logica generale del report

Il report è costruito come analisi delle sessioni di comunicazione sull’intera flotta.

text

Elenco dei nodi della flotta
→ recupera le sessioni di comunicazione
→ verifica la prontezza dei dati
→ norma individuale della sessione per ciascun nodo
→ ricerca delle sessioni lunghe tramite IQR
→ calcola il punteggio per ciascun nodo
→ raggruppa le sessioni lunghe in incidenti orari
→ determina la probabile causa RCA
→ distribuisce le ipotesi tra i nodi
→ nodi più problematici
→ ripartizione per tipo di correttore
→ ripartizione per giorni e mesi
→ raccomandazioni per le operazioni

Il principio fondamentale:

text

una sessione lunga è definita rispetto alla norma di un nodo specifico,
non rispetto a una soglia fissa comune all'intera flotta.

Questo è importante perché dispositivi, regioni, operatori di rete mobile e modalità di interrogazione diversi possono avere durate normali delle sessioni differenti.

Parametri di esecuzione

Parametro	Significato
Data da / Data a	confini della finestra di analisi
Finestra di analisi, giorni	finestra di ripiego usata quando le date sono vuote (predefinito 30)
Nodi per tipo di correttore	dimensione del campione per tipo; `0` indica tutti i nodi della flotta
Sessioni minime per nodo per IQR	numero minimo di sessioni necessarie a un nodo per qualificarsi (predefinito 30)
Numero di nodi problematici nel report	dimensione della tabella top-N (predefinito 50)
Analisi LLM	narrativa IA opzionale che spiega i risultati
Azienda di servizi	restringe l’analisi alla flotta di un singolo fornitore

Dati di ingresso

Dati principali

Dato	A cosa serve
Elenco dei nodi	determinare la flotta di analisi
Tipo di correttore	costruire la ripartizione per modello
`Equipment ID`	recuperare le sessioni di uno specifico dispositivo
Sessioni di comunicazione	nucleo del report
Ora di inizio della sessione	raggruppamento per giorni, mesi e ore
Durata della sessione	l’indicatore analizzato principale
`RSSI` / `CSQ`	stima della qualità del segnale radio
`Btm` / batteria	stima dell’influenza dell’alimentazione
Organizzazione / posizione	attribuzione dell’incidente: cliente locale, stazione base, flotta

Insieme minimo richiesto

Per una corretta analisi di un nodo, sono necessari i seguenti elementi:

identificatore del dispositivo;
almeno il numero minimo di sessioni;
durata di ciascuna sessione;
timestamp di ciascuna sessione.

Se la durata della sessione è assente, tale sessione non partecipa all’analisi IQR.

Prontezza dei dati: il gate dei dati

Prima di calcolare le anomalie, il report verifica se l’analisi possa essere effettivamente eseguita. Il blocco di prontezza dei dati mostra la dimensione della flotta, la dimensione dopo il filtro per azienda, quanti nodi hanno restituito dati di sessione e quanti di essi hanno superato il minimo di sessioni per l’IQR. Si tratta di una diagnostica di importanza critica: senza di essa, “nessuna anomalia” si confonde facilmente con “nessun dato per l’analisi”.

Indicatori principali di prontezza

Indicatore	Formula / valore
Nodi nella flotta	`N_park`
Nodi nel campione	`N_sampled`
Nodi con dati di sessione	`N_with_data`
Nodi che hanno superato il minimo di sessioni	`N_qualified`
Sessioni totali	`N_sessions`
Chiamate API	`N_calls`
Errori API	`N_errors`
Tasso di errore API	`N_errors / N_calls × 100%`
Copertura dei dati	`N_with_data / N_sampled × 100%`
Copertura del campione IQR	`N_qualified / N_sampled × 100%`

Tasso di errore API

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

Copertura dei dati

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

Copertura per nodi idonei all’IQR

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

Stati di prontezza

Stato	Condizione	Cosa significa
`OK`	esiste un campione sufficiente per l’IQR	il report può essere letto come operativo
`DEGRADED`	il campione è piccolo ma l’analisi è possibile	le conclusioni sono prudenti
`INCONCLUSIVE`	molti errori o copertura criticamente bassa	le conclusioni sulle anomalie sono inaffidabili
`NO_DATA`	nessun dato di sessione	l’analisi è impossibile
`NO_FLEET`	nessun nodo dopo il filtraggio	nulla da analizzare

Condizioni critiche

L’analisi è considerata impossibile se:

APIErrorRate \ge 50\%

oppure:

Coverage_{with\_data} < 5\%

oppure:

N_{qualified} = 0

Sessioni minime per nodo

Per un’analisi IQR affidabile, ciascun nodo deve disporre di un numero sufficiente di sessioni.

Soglia minima

Per impostazione predefinita:

N_{sessions,station} \ge 30

Se un nodo ha meno sessioni, la norma individuale è considerata statisticamente inaffidabile e il nodo non supera il filtro IQR.

Perché serve un minimo

L’IQR utilizza stime sui quartili. Con un numero ridotto di osservazioni, il quartile diventa instabile:

una singola sessione lunga casuale può sovrastimare la soglia;
un singolo periodo di comunicazione breve può sottostimare la soglia;
diventa impossibile distinguere la norma del nodo dalla casualità.

Norma individuale della durata della sessione

Perché la norma è individuale

Non è possibile usare un’unica soglia comune per l’intera flotta, ad esempio “tutte le sessioni più lunghe di 10 minuti sono cattive”. Nodi diversi hanno condizioni di comunicazione diverse:

tipi di correttore diversi;
operatori di rete mobile diversi;
RSSI diversi;
volumi di archivio diversi;
pianificazioni di interrogazione diverse;
siti di installazione diversi;
antenne diverse.

Pertanto, per ciascun nodo viene calcolata la propria norma statistica.

Selezione delle durate valide

Per ciascun nodo si prendono solo le durate positive:

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

dove:

d_i — durata della i-esima sessione in secondi.

Quartili

Le durate vengono ordinate in ordine crescente.

D_{sorted} = sort(D)

Primo quartile:

Q1 = percentile(D, 25\%)

Mediana:

Q2 = median(D)

Terzo quartile:

Q3 = percentile(D, 75\%)

Scarto interquartile

IQR = Q3 - Q1

Limite superiore della norma con barriera di Tukey

Per ciascun nodo viene calcolato un limite superiore individuale della norma:

UpperFence = Q3 + 1.5 \times IQR

Questa è la classica regola delle barriere di Tukey per il rilevamento degli outlier.

Sessione lunga

Una sessione è considerata anomalmente lunga se:

d_i > UpperFence

dove:

d_i — durata della sessione;
UpperFence — la soglia individuale di questo nodo.

Indicatori di base del nodo

Per ciascun nodo vengono calcolati i seguenti indicatori.

Numero totale di sessioni

N_{total} = count(D)

Numero di sessioni lunghe

N_{long} = count(d_i > UpperFence)

Quota di sessioni lunghe

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

Durata media di tutte le sessioni

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

Durata media delle sessioni lunghe

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

Durata massima

MaxLongDuration = max(d_i \mid d_i > UpperFence)

RSSI medio

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

dove N_RSSI è il numero di sessioni con un valore RSSI disponibile.

Punteggio di problematicità del nodo

Significato del punteggio

Il punteggio indica quanto un nodo sia problematico in termini di sessioni lunghe. Tiene conto di tre dimensioni:

quota di sessioni lunghe;
di quanto le sessioni lunghe superano la norma;
numero assoluto di sessioni lunghe.

Questo approccio evita di sopravvalutare un outlier isolato e di sottovalutare un nodo con un gran numero di sessioni moderatamente lunghe.

Componente A — quota di sessioni lunghe

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

Interpretazione:

Quota di lunghe	A
5%	20
10%	40
25%	100
>25%	100

Componente B — durata relativa

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

dove MedianDuration è la durata mediana delle sessioni del nodo.

Interpretazione:

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

Componente C — numero di sessioni lunghe

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

Vale a dire, 100 o più sessioni lunghe forniscono il contributo massimo da questa componente.

Punteggio finale

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

dove:

A — quota di sessioni lunghe;
B — durata relativa delle sessioni lunghe;
C — numero assoluto di sessioni lunghe.

Il punteggio finale è limitato all’intervallo:

0 \le Score \le 100

Interpretazione del punteggio

Score	Livello
≥ 80	nodo di comunicazione critico
60–80	priorità alta
40–60	priorità media
20–40	osservazione / verifica programmata
< 20	segnale debole

Stima della perdita di batteria sulle sessioni lunghe

Significato

Una sessione lunga aumenta il tempo di trasmissione e può consumare ulteriormente la batteria. Il report fornisce una stima approssimativa del dispendio energetico in eccesso. Non è una misura precisa della batteria, bensì una stima operativa.

Tempo di trasmissione in eccesso

Per ciascuna sessione lunga si calcola l’eccesso rispetto alla norma mediana del nodo:

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

Tempo in eccesso totale:

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

Corrente di trasmissione

Per la stima approssimativa si utilizza una corrente di trasmissione di base:

I_{TX} = 340 \; mA

Perdita di batteria

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

dove:

ExtraTime_total — in secondi;
I_TX — corrente in milliampere;
risultato — in mAh.

Per la visualizzazione in Ah:

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

Limitazione

Questa stima non tiene conto di:

il profilo di corrente effettivo del modello specifico;
la modalità di sospensione;
i tentativi ripetuti a livello del modem;
la potenza del trasmettitore;
la temperatura;
l’età della batteria;
la capacità della batteria;
la qualità della rete al momento della trasmissione.

Va quindi letta come una stima dell’ordine di grandezza, non come una misura di laboratorio.

RSSI e CSQ

RSSI

RSSI indica il livello del segnale radio in dBm. Più il valore è vicino allo zero, più forte è il segnale.

Interpretazione approssimativa:

RSSI	Valutazione
≥ −65 dBm	segnale buono
−65…−75 dBm	accettabile
−75…−85 dBm	debole
< −85 dBm	molto debole

CSQ

Alcuni dispositivi non trasmettono l’RSSI in dBm ma il CSQ — l’indice di qualità del segnale GSM. Se il valore appare come CSQ, può essere convertito:

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

Esempio:

CSQ = 29

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

Segnale localmente debole

Se:

RSSI_{avg} < -85 \; dBm

e le anomalie del nodo non coincidono con incidenti massivi della flotta, la causa può essere classificata come:

text

segnale debole nel sito di installazione

Raggruppamento delle sessioni lunghe in incidenti

Le anomalie vengono raggruppate in finestre orarie. Se più nodi hanno ricevuto sessioni lunghe nella stessa ora, non si tratta di un problema locale del nodo ma di un incidente di rete, server o operatore. L’ipotesi è determinata automaticamente in base all’ampiezza della copertura — il numero di nodi, modelli e clienti nella finestra.

Perché serve il raggruppamento

Se le sessioni lunghe sono comparse su molti nodi nella stessa ora, è molto probabile che non si tratti di un problema locale di un singolo dispositivo. Potrebbe trattarsi di:

un problema della stazione base;
un sovraccarico locale dell’operatore;
un incidente di rete massivo;
un’operazione programmata del server;
una peculiarità del firmware di uno specifico modello.

Bucket orario

Ogni sessione lunga viene collocata in un bucket orario:

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

Vale a dire, tutti gli eventi entro un’ora ricadono in un unico bucket.

Incidente

Un bucket orario è considerato un incidente se sono coinvolti almeno:

N_{stations,bucket} \ge 5

nodi.

Indicatori dell’incidente

Per ciascun incidente vengono calcolati i seguenti elementi:

Indicatore	Formula
numero di nodi	`count(unique station_id)`
numero di modelli	`count(unique equipment_type)`
numero di clienti / posizioni	`count(unique customer_id)`
numero di sessioni	`count(long sessions in bucket)`
RSSI medio	`average(RSSI)`
modelli principali	`top equipment types by count`

RCA: attribuzione della causa dell’incidente

Sintesi dell'indagine sulle cause radice

La sintesi della flotta individua il principale responsabile — torre cellulare, server, rete, firmware o nodo locale — fornisce un’attribuzione di responsabilità tra i nodi con anomalie e formula un piano d’azione. Una narrativa IA opzionale in fondo spiega i numeri in linguaggio semplice ma non li modifica.

L’RCA è la classificazione della causa probabile delle sessioni lunghe.

Ipotesi possibili

Ipotesi	Significato
`Server driver`	guasto massivo del driver di raccolta
`Server routine`	operazione o manutenzione ordinaria del server
`Network outage`	guasto dell’operatore di rete mobile
`Cell tower`	problema di una specifica stazione base o posizione
`Firmware`	problema del modello / firmware del dispositivo
`Local signal`	segnale debole nel sito di installazione
`Battery low`	bassa alimentazione / degrado della batteria
`Isolated device`	malfunzionamento locale di uno specifico nodo
`Mixed causes`	cause miste

Incidente esteso del server

Un incidente è classificato come del server se sono coinvolti simultaneamente molti nodi, molti modelli e molti clienti. Convenzionalmente:

N_{stations} \ge ServerWideStations

N_{models} \ge ServerWideModels

N_{customers} \ge ServerWideCustomers

Nel report, ciò significa:

text

incidente esteso della flotta, non simile a un problema locale di un singolo nodo.

Guasto della rete dell’operatore

Se sono coinvolti diversi modelli e diversi clienti, ma l’ampiezza non raggiunge quella di un guasto del server:

N_{models} \ge 3

N_{customers} \ge 3

allora l’ipotesi è:

text

guasto della rete mobile / incidente dell'operatore

Problema della stazione base

Se sono coinvolti molti nodi, ma appartengono a una o due posizioni / clienti:

N_{customers} \le 2

N_{stations} \ge CellMinStations

allora l’ipotesi è:

text

problema della stazione base o problema di copertura locale

Problema di firmware o modello

Se è coinvolto un solo modello, ma presso clienti diversi:

N_{models} = 1

N_{customers} \ge 3

allora l’ipotesi è:

text

peculiarità del firmware / modello del dispositivo

Cause miste

Se le condizioni non producono una classificazione univoca, l’incidente riceve lo stato:

text

cause miste

Routine ricorrente del server

A volte gli incidenti massivi del server si verificano alla stessa ora del giorno.

Condizione

Se sono presenti almeno tre incidenti estesi del server alla stessa ora del giorno:

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

possono essere classificati come:

text

routine del server

Significato

Ciò può indicare un job notturno ricorrente, una manutenzione dell’archivio, un processo batch o un’operazione massiva che incide sulla durata delle sessioni.

Attribuzione della causa per nodo

Dopo la ricerca degli incidenti della flotta, il report determina cosa predomina in ciascun nodo: incidenti esterni o un problema locale.

Quota delle anomalie di un nodo che ricadono negli incidenti della flotta

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

Se la maggior parte delle anomalie ha coinciso con incidenti della flotta

Se:

InIncidentPct \ge 70\%

allora la causa dominante del nodo è desunta dall’incidente della flotta:

text

network_outage / cell_tower / firmware / server

Questo significa:

text

il dispositivo probabilmente non è il principale responsabile; ha subito il problema insieme agli altri.

Verifica della batteria scarica

Se le anomalie non sono spiegate dagli incidenti della flotta, si verifica l’alimentazione. Sia:

Btm_{first}

il primo valore disponibile della batteria nelle sessioni lunghe, e:

Btm_{last}

l’ultimo valore disponibile. La caduta:

BtmDrop = Btm_{first} - Btm_{last}

L’ipotesi battery_low è possibile se:

Btm_{first} < 3500 \; mV

BtmDrop > 200 \; mV

Verifica del segnale localmente debole

Se:

RSSI_{avg} < -85 \; dBm

allora l’ipotesi è:

text

segnale debole nel sito di installazione

Malfunzionamento isolato del nodo

Se:

le anomalie non coincidono con gli incidenti della flotta;
la batteria non spiega il quadro;
l’RSSI non è criticamente debole;

allora la causa è classificata come:

text

malfunzionamento locale del nodo

Distribuzione delle ipotesi sull’intera flotta

Per ciascun nodo viene selezionata la causa dominante. Quando la maggior parte dei nodi ha subito incidenti della flotta, il nodo stesso non è colpevole; solo una minoranza presenta un problema locale isolato. Ciò modifica il piano d’azione: lo sforzo principale è rivolto alle stazioni base e all’operatore, non a un sopralluogo massivo su ogni nodo con anomalie.

Il report mostra quanti nodi sono attribuiti a ciascuna causa dominante.

Formula della quota di ipotesi

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

Gruppi di cause

Per la sintesi gestionale, le ipotesi possono essere raggruppate:

Gruppo	Include
rete / server	`server_driver`, `server_routine`, `network_outage`, `cell_tower`
problemi locali del dispositivo	`isolated_device`, `local_signal`, `battery_low`
modello / firmware	`firmware`
miste	`mixed`

Interpretazione

Predomina	Cosa fare
`Cell tower`	verificare la copertura, l’operatore, le antenne esterne presso i clienti coinvolti
`Local signal`	sopralluogo sul nodo specifico, antenna, ripetitore, sito di installazione
`Isolated device`	diagnostica di modem, SIM, alimentazione, firmware
`Firmware`	verificare la versione del software e contattare il fornitore
`Server routine`	verificare i processi ordinari della piattaforma
`Network outage`	interrogare l’operatore di rete mobile per orario e zona

Nodi più problematici

La tabella dei nodi più problematici classifica i nodi in base a un punteggio composito (0–100) costruito a partire dalla quota di sessioni lunghe, dalla loro durata media e dal loro numero. Facendo clic su una riga si espandono le sessioni più lunghe del nodo con i valori RSSI e Btm — utili per pianificare un sopralluogo.

Scopo

La tabella mostra dove recarsi o cosa verificare per primo.

Colonne della tabella

Colonna	Significato
Nodo	nome e ID del nodo
Correttore	tipo di dispositivo
Sessioni	numero totale di sessioni valide
Lunghe	numero di sessioni anomalmente lunghe
Quota	percentuale di sessioni lunghe
Media lunghe	durata media delle sessioni lunghe
Sessione massima	peggiore sessione riscontrata
`RSSI` medio	qualità del segnale radio
Perdita di batteria	energia in eccesso stimata
Score	punteggio composito di problematicità

Come leggere la classifica

Un punteggio elevato può derivare da motivi diversi:

una quota elevata di sessioni lunghe;
singole sessioni molto lunghe;
un grande numero assoluto di sessioni lunghe;
una combinazione di questi fattori.

Per pianificare un sopralluogo, leggi non solo il punteggio ma anche:

RSSI;
l’ipotesi RCA;
la perdita di batteria;
la sessione massima;
se ricade negli incidenti della flotta;
il tipo di correttore.

Giorni più problematici

Tutte le sessioni anomale vengono raggruppate per giorno di calendario. Il giorno con il maggior numero di anomalie è molto probabilmente quello in cui si è verificato un incidente della flotta. Ciascun giorno si espande nell’elenco dei nodi con le loro anomalie, la sessione massima e i collegamenti. Ciò è utile per investigare eventi massivi e verificarne la ricorrenza.

Scopo

La ripartizione per giorni mostra i giorni in cui le sessioni lunghe sono comparse massivamente sull’intera flotta.

Indicatori del giorno

Indicatore	Significato
Data	giorno di calendario
Sessioni lunghe	numero di sessioni lunghe della giornata
Nodi	quanti nodi sono coinvolti
Media lunghe	durata media delle sessioni lunghe
Sessione massima	caso peggiore della giornata
Nodo peggiore	nodo con la sessione massima

Interpretazione

Quadro	Causa possibile
molti nodi in un singolo giorno	incidente di rete o della flotta
un nodo ogni giorno	problema locale
un picco nel fine settimana	rete dell’operatore / lavori di manutenzione
picchi alla stessa ora	attività o pianificazione ricorrente
crescita mensile	degrado della rete, sovraccarico stagionale, cambio della modalità di interrogazione

Ripartizione per tipo di correttore

Il blocco di copertura mostra cosa è stato verificato della flotta per ciascun tipo di correttore: quanti nodi sono nel campione, quanti hanno restituito dati, quanti hanno superato l’IQR e quanti presentano anomalie. Se un tipo mostra “norma”, i dati sono arrivati ma non sono state riscontrate anomalie. “Nessun dato” significa che il tipo non restituisce la durata della sessione nell’API — per alcuni modelli questo è normale.

Ripartizione dettagliata per tipo di correttore

Espandi un tipo per vedere tutti i suoi nodi con anomalie; espandi un nodo per vedere le sue specifiche sessioni lunghe con ora, durata, RSSI e Btm. Il colore di evidenziazione della sessione dipende da quanto la sessione è più lunga della norma del nodo.

Scopo

La ripartizione per tipo di correttore mostra quali modelli cadono più spesso in sessioni anomalmente lunghe.

Indicatori per tipo

Indicatore	Significato
Nel campione	quanti nodi di questo tipo sono presenti nella flotta
Con dati	quanti nodi hanno restituito dati di sessione
Superato IQR	quanti nodi hanno il minimo di sessioni
Anomalie	numero di sessioni lunghe
Stato	norma / anomalie / nessun dato

Limitazione importante

Non è possibile confrontare direttamente i tipi di correttore basandosi sul solo numero di anomalie. Occorre tenere conto di:

quanti dispositivi di questo tipo sono presenti nella flotta;
quanti di essi hanno restituito dati;
quanti hanno superato il minimo di sessioni;
dove sono installati;
in quali reti operano;
se hanno la stessa pianificazione di interrogazione;
se sono concentrati presso un unico cliente.

Quota di anomalie normalizzata per tipo

Per un confronto corretto, è possibile utilizzare:

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

oppure:

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

Ripartizione temporale: dinamiche e mesi

Dinamiche delle sessioni lunghe per giorno

Il grafico delle dinamiche giornaliere mostra quante sessioni anomale si sono verificate sull’intera flotta in ciascun giorno della finestra. Sono visibili dei “bagliori” — giorni di comunicazione scadente sull’intera rete. Un picco che coincide con il registro degli incidenti è tipicamente una serie di problemi della stazione base in un’unica posizione.

La ripartizione per mesi di calendario aiuta a cogliere la stagionalità o un trend di lungo periodo. Un picco mensile massivo corrisponde alla stessa serie di incidenti osservata nelle dinamiche giornaliere; una crescita graduale nel tempo è un candidato a un degrado della comunicazione o della batteria.

Scopo

La ripartizione per mesi mostra la stagionalità o un trend di lungo periodo delle sessioni lunghe.

Indicatore del mese

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

Quota del mese

Se occorre mostrare una quota:

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

Interpretazione

Quadro	Spiegazione possibile
picco mensile improvviso	cambio di rete, guasto massivo, carico stagionale
crescita graduale	degrado della comunicazione o della batteria
picco invernale	condizioni meteo, carico di rete, alimentazione
picco dopo un aggiornamento	firmware, impostazioni, pianificazione di interrogazione

Evidenziazione cromatica per sessione

Quando un nodo viene espanso, le sue singole sessioni lunghe sono evidenziate in base all’intensità del superamento della soglia individuale, e vengono mostrati i valori precisi di RSSI e Btm al momento di ciascuna sessione lunga. Questo è ciò di cui la squadra di campo ha bisogno: un RSSI basso indica un problema di segnale radio, mentre una tensione di batteria normale esclude la batteria.

Rapporto di superamento

Ratio_i = \frac{d_i}{UpperFence}

Interpretazione

Ratio	Colore / livello
1–2×	superamento debole
2–5×	superamento medio
≥5×	superamento forte

Questo aiuta a distinguere rapidamente le sessioni moderatamente lunghe da quelle estreme.

Cosa fare in base ai risultati del report

Se la causa è una stazione base

Verifica:

la qualità della copertura nella posizione;
un operatore di rete mobile alternativo;
un’antenna esterna;
un ripetitore;
la ricorrenza degli incidenti per giorno;
i nodi vicini nella stessa posizione;
il sovraccarico della rete in ore specifiche.

Se la causa è un nodo locale

Verifica:

l’antenna;
la scheda SIM;
il modem;
l’alimentazione;
la batteria;
i connettori;
il sito di installazione;
le interferenze;
la versione del firmware;
le impostazioni della pianificazione di trasmissione.

Se la causa è un segnale debole

Azioni:

misurare l’RSSI in loco;
provare a riposizionare l’antenna;
verificare l’orientamento dell’antenna;
verificare un operatore alternativo;
installare un’antenna esterna o un ripetitore.

Se la causa è la batteria

Azioni:

verificare Btm in loco;
sostituire la batteria se necessario;
verificare la corrente di consumo;
verificare la frequenza dei tentativi ripetuti;
verificare se il dispositivo sovraccarica la rete con i tentativi ripetuti.

Se la causa è il modello / firmware

Azioni:

raggruppare i nodi per versione del software;
consultare le note di rilascio del fornitore;
richiedere i problemi noti;
confrontare con altri modelli nelle stesse posizioni;
testare la modalità di comunicazione in laboratorio.

Commento dell’IA

Il commento dell’IA opzionale legge l’RCA e redige un breve piano di sopralluogo leggibile per la squadra. Si tratta di una spiegazione linguistica, non di una fonte di diagnostica — tutti i numeri e le cause sono determinati dalle formule e dalle regole sopra esposte.

Cosa può fare l’IA

riassumere brevemente l’RCA;
spiegare il principale probabile responsabile;
evidenziare i nodi principali;
formulare un piano di sopralluogo;
spiegare la ripartizione per modelli.

Cosa non può fare l’IA

L’IA non può:

modificare la soglia IQR;
modificare l’elenco delle sessioni lunghe;
modificare il punteggio;
determinare la causa reale senza dati;
sostituire un’indagine radiotecnica;
sostituire un sopralluogo;
costituire una base probatoria.

Errori tipici di interpretazione

Errore: sessione lunga = dispositivo difettoso

Errato. Una sessione lunga può essere causata dalla rete, dalla stazione base, da un segnale debole, da una routine del server, da un’antenna locale, dalla scheda SIM o dalla batteria.

Errore: molte anomalie per un modello = il modello è difettoso

Errato. Occorre normalizzare per numero di dispositivi, numero di sessioni, posizioni e operatori di rete mobile.

Errore: nessuna anomalia = tutto a posto

Errato se non ci sono dati di sessione o la copertura è troppo bassa.

Errore: un RSSI elevato esclude un problema di comunicazione

Non sempre. Possono esserci problemi dell’operatore, sovraccarico, firmware, ricezione lato server, tentativi ripetuti o errori di protocollo.

Errore: perdita di batteria = consumo esatto della batteria

Errato. Si tratta di una stima costruita sul tempo di trasmissione in eccesso e su una corrente convenzionale.

Errore: una singola sessione estremamente lunga rende il nodo il principale problema

Non sempre. Il punteggio tiene conto non solo del massimo, ma anche della quota, della durata media e del numero di sessioni lunghe.

Criteri minimi per un report completo

Un report è considerato metodologicamente completo se contiene:

periodo di analisi;
copertura della flotta;
stato del gate dei dati;
numero di nodi nella flotta;
numero di nodi interrogati;
numero di nodi con dati di sessione;
numero di nodi che hanno superato la soglia IQR;
numero di sessioni nel campione;
numero di sessioni lunghe;
numero di nodi con anomalie;
durata massima della sessione;
numero di incidenti orari;
distribuzione delle ipotesi RCA;
formula della soglia IQR;
formula del punteggio del nodo;
formula della perdita di batteria;
regole di classificazione RCA;
tabella dei nodi più problematici;
ripartizione per giorni;
ripartizione per tipo di correttore;
ripartizione per mesi;
avvertenza sulla natura approssimativa della perdita di batteria;
avvertenza sul ruolo dell’IA;
raccomandazioni per le azioni.

Formula consolidata del report

Per ciascun nodo:

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

Stima del consumo di batteria in eccesso:

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

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

Raggruppamento degli incidenti:

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

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

Avvertenza raccomandata

text

Il report rileva sessioni di comunicazione anomalmente lunghe rispetto alla norma
individuale di ciascun nodo. Il risultato è utilizzato per prioritizzare la
diagnostica di comunicazioni, antenne, schede SIM, alimentazione, operatori e
stazioni base. Il report non costituisce prova del malfunzionamento di uno
specifico dispositivo senza un sopralluogo e non valuta la correttezza della
misura fiscale del gas.

Relazione con altri report

Se devi capire	Usa
quali nodi mantengono lunga la comunicazione e scaricano la batteria	questo report
quali nodi non hanno comunicazione o archivio	Nodi più problematici
se il periodo può essere chiuso per uno specifico nodo	Consumption Analytics
se c’è il sospetto di sotto-misura	Nodi sospetti
perché uno specifico nodo è sospetto	Elusione della misura
quando sostituire le batterie	Previsione della batteria

Questa separazione evita che le sessioni di comunicazione lunghe si confondano con conclusioni commerciali, metrologiche e forensi.

Argomenti correlati

Esplora eventi

Ultimo aggiornamento il 23 giugno 2026

Questa pagina è stata utile?