---
title: 'Sessioni lunghe'
description: "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."
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';
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.
Il report non valuta la correttezza della misura fiscale del gas e non costituisce una perizia
forense sull'elusione della misura. Analizza esclusivamente le sessioni di comunicazione: durata,
frequenza delle anomalie, ampiezza degli incidenti, qualità del segnale e probabile causa delle
sessioni lunghe.
## Dove si colloca il report
Il report appartiene alla diagnostica operativa della telemetria. Non deve confondere due situazioni differenti:
1. **Nessuna comunicazione affatto.** Il nodo non si connette, non ci sono dati.
2. **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
$$
"Nessuna anomalia" e "nessun dato per l'analisi" sono stati differenti. Se i dati di sessione sono
assenti, il report non deve dichiarare che non sono state riscontrate anomalie.
## 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.
Se un nodo ha solitamente sessioni brevi, la sua soglia sarà bassa. Se un nodo ha solitamente
sessioni più lunghe, la sua soglia sarà più alta. Il report individua un'anomalia **rispetto alla
norma propria del 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:
1. **quota di sessioni lunghe**;
2. **di quanto le sessioni lunghe superano la norma**;
3. **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 |
Il punteggio non dimostra una causa. Un punteggio elevato indica che il nodo supera frequentemente
e/o fortemente la propria norma di durata delle sessioni. **La causa è determinata separatamente
tramite RCA.**
## 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
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
$$
e:
$$
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
$$
e:
$$
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
$$
e:
$$
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
$$
e:
$$
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.
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
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.
L'analisi è deterministica. Il commento dell'IA va letto soltanto come testo esplicativo — tutte
le conclusioni numeriche sono determinate da formule e regole.
## 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.