Un autobus extraurbano che attraversa una valle appenninica, una galleria o una zona di confine tra due celle perde il segnale per qualche minuto, a volte per decine di minuti. Per l'autista non cambia nulla. Per i sistemi di bordo, invece, cambia quasi tutto: il validatore non può interrogare la banca, l'AVM non trasmette la posizione, il feed GTFS-Realtime smette di aggiornarsi e la palina alla fermata successiva continua a mostrare un'informazione che non è più vera.
Nessun operatore può garantire la copertura mobile lungo tutto il percorso. La domanda giusta è quindi: cosa deve continuare a funzionare, cosa può essere recuperato dopo e cosa va dichiarato al passeggero come non affidabile?
La copertura mobile in Italia: migliora, ma non è continua lungo le linee
I piani pubblici hanno migliorato la situazione. Con il Piano Italia 5G finanziato dal PNRR, il consorzio guidato da INWIT con TIM e Vodafone ha portato la copertura 5G in 973 aree bianche, per circa 500 km² di territorio, raggiungendo il target europeo entro il 31 maggio 2026. Un secondo filone del piano prevede il collegamento in fibra (backhaul) di oltre 11.000 siti radiomobili esistenti. L'AGCOM, dal canto suo, pubblica la Broadband Map con la copertura delle reti 2G, 3G, 4G e 5G.
Tre precisazioni però contano per chi gestisce autobus:
- Una mappa di copertura non è una garanzia di servizio in movimento. La copertura dichiarata descrive una probabilità di segnale in un punto, non la continuità di sessione dati su un veicolo a 70 km/h che passa da una cella all'altra, attraversa gallerie o scende in fondovalle.
- Il Piano Italia 1 Giga riguarda la rete fissa. Porta fibra agli indirizzi (civici), non migliora la connessione di un autobus in linea.
- Le linee extraurbane servono proprio i territori meno coperti. Secondo l'ISTAT (dati 2020), le aree interne comprendono 3.834 comuni, il 48,5% dei comuni italiani, il 58,8% della superficie nazionale e il 22,7% della popolazione, circa 13,4 milioni di persone. Sono i territori della Strategia Nazionale Aree Interne (SNAI), dove il trasporto pubblico è spesso l'unica alternativa all'auto.
Per una rete extraurbana, l'interruzione di rete non è un incidente: è una condizione ordinaria di esercizio.
Bigliettazione: cosa fa un validatore quando è offline
Titoli tradizionali e smart card
Per carte magnetiche, smart card o QR code, un validatore ben progettato lavora già in locale: conserva liste di titoli bloccati (black list) o, in alcuni sistemi, liste di titoli ammessi (white list), la tabella tariffaria e le regole di validità. Le validazioni vengono registrate in memoria e sincronizzate con il back office al ritorno della rete. Il rischio principale è la freschezza delle liste: un abbonamento revocato la mattina resta accettato finché il validatore non riceve l'aggiornamento.
Carte bancarie contactless (EMV)
Il caso EMV è più delicato, perché la decisione di pagamento spetterebbe alla banca emittente. Nel trasporto pubblico il modello standard risolve il problema con l'autorizzazione differita: il validatore verifica l'autenticità della carta in locale (Offline Data Authentication), la confronta con una lista di rifiuto locale e accetta il viaggio in meno di un secondo. L'addebito vero e proprio avviene dopo, spesso aggregando i viaggi della giornata.
Il documento tecnico dello U.S. Payments Forum sulle open payments nel trasporto definisce chiaramente il rischio che ne deriva, il "first ride risk": il rischio di non essere pagati quando la transazione, successivamente, viene rifiutata. Il viaggio è già stato concesso.
In Italia il meccanismo è lo stesso. TPL FVG indica che l'addebito avviene il giorno successivo o nei giorni seguenti, e che in caso di pagamento non riuscito la carta viene bloccata automaticamente e va sbloccata tramite l'assistenza. Arriva Italia (Cremona, Brescia) spiega che una carta viene rifiutata se i pagamenti dei viaggi precedenti non sono andati a buon fine, e che lo sblocco passa dal portale del viaggiatore saldando il dovuto. A Milano, ATM ha esteso il contactless a tutta la rete di superficie nell'aprile 2023, con circa 1.500 nuovi dispositivi a bordo di bus, tram e filobus; a Roma il Tap&Go di ATAC è attivo su tutte le linee di superficie, bus di Roma TPL inclusi.
Cosa cambia quando il validatore è offline per un tratto lungo?
- Le liste di rifiuto non si aggiornano. Una carta appena finita in lista viene ancora accettata a bordo. Più lunga è l'assenza di rete, più cresce l'esposizione al first ride risk.
- Le transazioni restano in memoria. Arrivano al centro in ritardo, e sono recuperabili solo se memoria locale e sincronizzazione sono affidabili.
- La tariffa a zone o chilometrica dipende dalla posizione. Se la fermata di salita arriva da un servizio remoto, una perdita di rete può produrre un titolo calcolato male. La posizione deve venire dal GNSS di bordo.
AVM e GTFS-Realtime: il dato che scade
Due usi diversi della stessa posizione
La posizione del veicolo serve a due cose che non hanno la stessa tolleranza al ritardo:
- Informazione in tempo reale (paline, app, open data): ha valore solo se è fresca. Una posizione di dieci minuti fa non serve a nessuno.
- Dato storico di esercizio (corse effettuate, puntualità, chilometri): ha valore anche se arriva con un'ora di ritardo, purché arrivi completo e con il timestamp corretto.
Confondere i due usi è l'errore più comune: il primo non si recupera, il secondo sì.
Cosa dicono gli standard
Le best practice GTFS-Realtime raccomandano di aggiornare il feed almeno ogni 30 secondi e che i dati di Trip Updates e Vehicle Positions non abbiano più di 90 secondi. Raccomandano inoltre con forza di fornire, per ogni veicolo, il timestamp della misura effettiva della posizione, non quello di pubblicazione del feed.
Google, nella documentazione per i partner, precisa che se un'entità sparisce dal feed torna all'orario programmato, che le Vehicle Positions sono considerate obsolete dopo 15 minuti e i Trip Updates dopo un'ora, e che dati vecchi ripubblicati con timestamp aggiornati producono informazioni inesatte.
Cosa vede il passeggero
Durante l'interruzione, lo scenario tipico è questo:
- il back office conserva l'ultima posizione nota e congela la previsione, oppure la estrapola dall'orario;
- la palina continua a mostrare "3 min" per un autobus che in realtà è fermo in coda da dieci;
- l'app di terze parti, se il feed è ben fatto, torna all'orario teorico; se il feed ripubblica dati vecchi come nuovi, mostra un ritardo falso.
Su una linea a frequenza oraria, un'informazione sbagliata è peggio di nessuna: può far perdere l'unica corsa utile.
Il rischio contrattuale: corse effettuate ma non certificate
La delibera ART n. 53/2024 sulle condizioni minime di qualità del TPL su strada fissa l'indicatore di puntualità (Misura 12) con tolleranze distinte per urbano ed extraurbano, con una soglia di ritardo di 5 minuti per l'urbano e di 10 minuti per l'extraurbano. La misura si basa sulle corse per cui è garantito il monitoraggio automatico tramite apparati di bordo, ad esempio AVM; le altre sono oggetto di verifica a campione. La stessa delibera richiede informazioni in tempo reale alle fermate e tramite app, e l'accessibilità dei dati su posizione e circolazione dei mezzi.
Da qui discendono tre rischi concreti per l'azienda:
- Corse non monitorate. Se una corsa ha buchi di posizione estesi, può non essere riconosciuta come effettuata dal sistema di certificazione. Il servizio è stato reso, ma non è dimostrabile.
- Puntualità distorta. Passaggi in fermata ricostruiti male o mancanti alterano la percentuale di corse puntuali, in un senso o nell'altro.
- Chilometri contestabili. Se il chilometraggio si basa sulla traccia GNSS trasmessa, ogni buco è un'incertezza nel rapporto con l'ente affidante o l'agenzia della mobilità.
Sulla rete extraurbana, quindi, la copertura mobile può incidere sugli indicatori contrattuali, se il sistema di bordo non resiste alle interruzioni.
Buone pratiche per sistemi di bordo resilienti
| Componente | Senza rete | Rischio | Pratica consigliata |
|---|---|---|---|
| Validatore titoli | Validazioni in locale | Liste di blocco non aggiornate | Liste locali, sincronizzazione frequente, allarme sull'età delle liste |
| Validatore EMV | Accetta con autorizzazione differita | First ride risk che cresce con la durata | Deny list locale, soglie di rischio, sincronizzazione prioritaria al ritorno della rete |
| AVM | Posizione non trasmessa | Corse non certificate, km incerti | Store and forward con timestamp di misura |
| GTFS-RT | Feed non aggiornato | Previsioni congelate o false | Rimuovere il veicolo dal feed oltre soglia, non ripubblicare dati vecchi |
| Paline e app | Ultima previsione | Informazione errata | Degrado controllato, indicazione "dato non in tempo reale" |
1. Store and forward come regola, non come opzione
Ogni posizione, passaggio in fermata e validazione va registrato in locale con il timestamp della misura e trasmesso appena la rete torna, in ordine cronologico. Il back office deve accettare dati arrivati in ritardo e ricostruire la corsa, senza confonderli con il tempo reale.
2. Calcolo dell'avanzo e ritardo a bordo
Se lo scostamento dall'orario si calcola sul veicolo, a partire dal GNSS locale e dall'orario caricato a bordo, l'autista continua a vedere il proprio anticipo o ritardo anche in galleria. Il GNSS non dipende dalla rete mobile: è un errore di progetto farlo dipendere da un calcolo remoto.
3. Ridondanza di rete, dove ha senso
Doppia SIM o SIM multi-operatore riducono le zone bianche, perché la copertura dei diversi operatori non coincide. Non eliminano gallerie e fondovalle: la ridondanza va vista come riduzione del problema, non come soluzione.
4. Degrado controllato dell'informazione
Oltre una certa soglia di assenza di dati, il sistema centrale deve smettere di proiettare la vecchia previsione, togliere il veicolo dal feed GTFS-RT o marcarlo come non aggiornato, e mostrare in palina l'orario programmato con una dicitura esplicita, del tipo "orario programmato, dato non in tempo reale". È meglio una verità parziale che una precisione finta.
5. Mappare le zone senza segnale
Conoscere le tratte in cui i veicoli perdono sistematicamente la rete permette di spiegarlo all'ente affidante e di calibrare le soglie di degrado linea per linea.
Cosa implica per un'azienda TPL o un'agenzia della mobilità
Chi redige un capitolato dovrebbe chiedere: cosa registra il veicolo quando non c'è rete, per quanto tempo, con quale timestamp? Come vengono trattati i dati arrivati in ritardo nel calcolo di corse effettuate e puntualità? Cosa vede il passeggero dopo 2, 5 e 15 minuti senza dati?
Pysae, ad esempio, utilizza come apparato di bordo un'app su smartphone che registra le posizioni in locale e le ritrasmette al ritorno della rete, secondo il principio dello store and forward. È il tipo di comportamento da richiedere a qualunque fornitore: il dato di esercizio deve sopravvivere all'interruzione, anche quando l'informazione in tempo reale, per definizione, non può farlo.
FAQ
Un validatore EMV funziona senza connessione a bordo?
Sì, nella maggior parte dei sistemi di trasporto: verifica la carta in locale, controlla una lista di rifiuto e accetta il viaggio, con addebito differito. Il rischio è che la lista non sia aggiornata e che il pagamento venga poi rifiutato dalla banca.
Le posizioni registrate offline servono al tempo reale?
No. Una posizione trasmessa con dieci minuti di ritardo non serve alle paline né alle app. Serve invece a ricostruire la corsa effettuata, la puntualità e i chilometri, a condizione che conservi il timestamp della misura.
Cosa dovrebbe mostrare una palina se il bus non trasmette?
Dopo una soglia definita, l'orario programmato con l'indicazione esplicita che il dato non è in tempo reale. Continuare a proiettare l'ultima previsione nota induce il passeggero in errore.
Fonti: INWIT, "Piano Italia 5G Densificazione del PNRR: obiettivo raggiunto" (2026); Dipartimento per la trasformazione digitale, Piano Italia 5G; AGCOM, Broadband Map; ISTAT, "La geografia delle aree interne nel 2020" (2022); U.S. Payments Forum, "Transit Contactless Open Payments: Use Cases and Technical Solutions" (2018); TPL FVG, servizi contactless; Arriva Italia Cremona, viaggiare con carta contactless; Urbanfile, ATM completa il pagamento contactless in tutta la rete (2023); ATAC, Tap&Go; MobilityData / gtfs.org, GTFS Realtime Best Practices; Google Transit Partners Help, "How data gaps affect realtime feeds"; ART, delibera n. 53/2024 e Allegato A.
Da fare prima della pubblicazione: aggiungere la copertina Banana Pro; verificare le soglie ART di 5 e 10 minuti (Misura 12, Allegato A delibera 53/2024) e il dato "oltre 11.000 siti backhaul" (pagina governativa di gennaio 2024); confermare con il prodotto il comportamento store and forward dell'app Pysae.