Quale software AVM gestisce GTFS-RT e NeTEx? Un AVM moderno pubblica a terra i dati di servizio in formati aperti (GTFS e GTFS-RT, e a seconda dei casi NeTEx e SIRI), mentre ITxPT è un'altra cosa: è lo standard che regola come gli apparati dialogano dentro l'autobus. Confondere i due livelli è uno degli errori più frequenti nei capitolati.
A bordo di un autobus urbano convivono oggi AVM, validatori, contapasseggeri, indicatori di linea, monitor di informazione, videosorveglianza e router. Per anni ogni fornitore ha portato la propria centralina, i propri cavi e il proprio protocollo, con il risultato che sostituire un apparato significava spesso rifare l'integrazione di tutti gli altri. ITxPT nasce per rompere questa dipendenza: vediamo cosa copre, cosa non copre e come scriverlo in un capitolato.
Cos'è ITxPT e chi lo definisce?
ITxPT (Information Technology for Public Transport) è un'associazione internazionale senza scopo di lucro con sede a Bruxelles. È nata nel 2013 con nove membri fondatori, come prosecuzione del progetto europeo EBSF (European Bus System for the Future). L'UITP è tra i membri fondatori e presiede il consiglio di amministrazione. Tra i fondatori figura anche IVECO BUS, che nel 2018 ha annunciato l'adozione dell'architettura elettrica ITxPT su tutta la gamma urbana, interurbana e turistica.
L'associazione riunisce autorità, operatori, costruttori e fornitori IT: la pagina dei membri elenca oltre cento organizzazioni, tra cui:
- Francia: RATP, SNCF e Semitan (Nantes) tra gli operatori, RTM (Marsiglia) e Tisséo Collectivités (Tolosa) tra le autorità. Tisséo è stata la prima autorità organizzatrice francese ad aderire, come membro strategico.
- Spagna: il Consorcio Regional de Transportes de Madrid (CRTM) tra le autorità, oltre a fornitori come Datik e Indra.
- Belgio: De Lijn, TEC, STIB e SNCB tra gli operatori.
- Paesi Bassi: GVB (Amsterdam) e RET (Rotterdam) tra gli operatori.
- Italia: STA, Strutture Trasporto Alto Adige (Bolzano), tra le autorità, oltre a fornitori come Almaviva e Hitachi Rail.
Le specifiche sono pubbliche e gratuite: basta registrarsi al Documentation Center. I membri hanno accesso a materiali aggiuntivi.
Cosa contengono le specifiche S01, S02, S03 e S04?
La seconda generazione delle specifiche (ITxPT 2.0) è stata completata nel 2017 ed è organizzata in quattro parti:
| Parte | Titolo | Cosa copre |
|---|---|---|
| S01 | Installation Requirements | Requisiti hardware del veicolo: alimentazione, interfacce, cablaggio, rete |
| S02 | Onboard Architecture | Servizi software a bordo e protocolli su rete IP |
| S03 | Back-office Architecture | Interoperabilità tra servizi di back office |
| S04 | Over the Air Architecture | Scambio minimo di messaggi tra sistema centrale e apparati di bordo |
La parte operativa per chi scrive un capitolato è soprattutto la S02, divisa in servizi numerati:
- S02P01 Inventory: ogni modulo in rete si annuncia e dichiara identità e stato.
- S02P02 Time: un orario comune a tutti gli apparati.
- S02P03 GNSSLocation: la posizione diffusa una sola volta a tutti.
- S02P04 FMStoIP: i dati FMS del costruttore (chilometri, consumi, motore) su IP.
- S02P05 VEHICLEtoIP: altri segnali, come le porte.
- S02P06 AVMS: linea, corsa e fermata condivise con gli altri apparati.
- S02P07 APC: i dati dei contapasseggeri.
- S02P08 MADT: il terminale autista.
- S02P09 MQTTbroker: lo scambio di messaggi tramite broker MQTT.
Le specifiche evolvono con rilasci major (al massimo uno all'anno), minor e patch; di recente si sono aggiunte una specifica sul conteggio passeggeri orientata all'occupazione e la S04P04 sui processi di logon.
Il label ITxPT: cosa certifica
Il label è il sigillo che attesta la conformità di un apparato, di un software o di un servizio alle specifiche, dopo test eseguiti da un laboratorio ITxPT. Il catalogo pubblico distingue moduli, sistemi di back office e veicoli, e per ogni prodotto indica la versione delle specifiche e il rapporto di test.
In gara contano due precisazioni. Il label vale per un prodotto e per una versione delle specifiche, non per un'azienda. E un modulo etichettato non implementa necessariamente tutti i servizi: un white paper del settore pubblicato nel 2021 rilevava che, su circa 60 moduli presenti allora nel catalogo, solo cinque esponevano il servizio AVMS. Chiedere "un apparato ITxPT" senza dire quali servizi non basta.
Architettura IP a bordo o centralina proprietaria?
Nel modello tradizionale ogni sottosistema ha la sua centralina e i collegamenti sono punto a punto, spesso su protocolli seriali proprietari: ogni nuova funzione richiede un nuovo cavo e una nuova integrazione.
Con ITxPT il veicolo ha una rete Ethernet/IP comune e ogni apparato pubblica e consuma servizi standard. Ad Amsterdam GVB ha avviato nel 2019 con InTraffic un nuovo sistema di informazione a bordo e un AVMS per bus e tram basati su ITxPT. Secondo il responsabile informativo di GVB, la soluzione riduce i costi "perché serve meno equipaggiamento a bordo", e un solo sistema invia le informazioni alla centrale di esercizio invece di uno per apparato.
Il tema della centralina unica a bordo, con GPS, diagnostica e manutenzione, è trattato nel nostro articolo sulla telematica di bordo per il TPL. Qui interessa un punto diverso: ITxPT non impone una centralina unica, impone interfacce comuni. Si può avere un router, un validatore e un contapasseggeri di tre fornitori diversi, purché parlino gli stessi servizi.
Perché ITxPT conta in Italia adesso
Rinnovo flotte e gare
Il PNRR ha finanziato un rinnovo massiccio del parco autobus urbano. Il DM 530 del 23 dicembre 2021 ripartiva circa 1,9 miliardi di euro per il rinnovo dei bus nei comuni interessati, con dotazioni di circa 292 milioni per Roma e 249 milioni per Milano (fonte: lentepubblica.it, marzo 2022). Ogni bus nuovo fissa l'architettura di bordo per tutta la sua vita utile: con rete IP e servizi ITxPT accoglie apparati di fornitori diversi, con cablaggi proprietari lega l'operatore al fornitore originale.
ART 53/2024: AVM e contapasseggeri diventano indicatori misurati
La delibera ART n. 53/2024 sulle condizioni minime di qualità del TPL su strada trasforma gli apparati di bordo in oggetto di misura. L'Allegato A definisce, tra gli altri:
- l'indicatore AVM, che valuta "l'effettivo funzionamento dei sistemi di bordo" come quota delle vetture-km rilevate dall'AVM rispetto a quelle che il contratto prevede di esercire con veicoli attrezzati;
- l'indicatore RIL, che "misura l'effettivo funzionamento dei sistemi di bordo che consentono la rilevazione dei dati di frequentazione", calcolato come quota delle corse con dati di frequentazione rilevati, con un livello minimo "non inferiore all'80%";
- l'indicatore AFF sull'affollamento, descrittivo salvo che il contratto affidi al gestore la progettazione del servizio.
La delibera chiede inoltre che i dati del conteggio automatico siano raccolti con continuità su tutti i veicoli attrezzati e che siano accessibili a terzi, con riferimento al punto di accesso nazionale previsto dal Regolamento delegato (UE) 2017/1926.
Conseguenza pratica: se il contapasseggeri non conosce la corsa in corso, il dato di frequentazione non è attribuibile e l'indicatore RIL ne soffre. È esattamente il problema che il servizio AVMS di ITxPT risolve, condividendo linea, corsa e fermata con gli altri apparati.
Bigliettazione elettronica
Lo stesso vale per i validatori: una validazione senza corsa e fermata associate serve alla contabilità, non all'analisi della domanda. Orario comune e informazione di servizio condivisa permettono di incrociare validazioni, conteggi e posizioni.
ITxPT a bordo, GTFS-RT, NeTEx e SIRI a terra: due livelli diversi
ITxPT S02 descrive come gli apparati si parlano all'interno del veicolo. GTFS, GTFS-RT, NeTEx e SIRI descrivono come i dati di servizio vengono scambiati e pubblicati tra sistemi a terra e verso il pubblico.
| Livello | Domanda a cui risponde | Standard tipici |
|---|---|---|
| Dentro il veicolo | Come si scambiano posizione, corsa, conteggi e dati del veicolo tra apparati? | ITxPT S01, S02 |
| Tra veicolo e centrale | Come arrivano i dati di bordo al sistema centrale? | ITxPT S04, MQTT, API del fornitore |
| Tra sistemi a terra e verso il pubblico | Come si pubblicano orari, previsioni e posizioni? | GTFS, GTFS-RT, NeTEx, SIRI |
Ne derivano tre conseguenze:
- Un apparato con label ITxPT non pubblica automaticamente un feed GTFS-RT o SIRI. La pubblicazione è responsabilità del sistema centrale.
- Un AVM che esporta GTFS-RT non è per questo "compatibile ITxPT", e viceversa.
- Il capitolato deve chiedere entrambe le cose, separatamente, se servono entrambe.
Perché l'Italia non imponga ancora un formato unico tra GTFS-RT, SIRI e NeTEx è spiegato nel nostro articolo dedicato a GTFS-RT, SIRI e NeTEx in Italia.
Cosa chiedere in capitolato
"Sistemi conformi allo standard ITxPT" è una formula troppo generica. Meglio essere precisi:
- Per i veicoli: rete di bordo conforme a ITxPT S01, indicando la versione delle specifiche, con eventuale label veicolo riportato nel catalogo ITxPT.
- Per ogni apparato: l'elenco dei servizi S02 richiesti (per esempio Inventory, Time, GNSSLocation, AVMS, APC) e se il prodotto deve essere etichettato, con rapporto di test.
- Per il contapasseggeri: associazione di ogni conteggio a corsa e fermata, raccolta continua e tasso di corse con dati rilevati compatibile con l'indicatore RIL.
- Per l'AVM: quota di vetture-km rilevate, gestione delle interruzioni di rete e conservazione dei timestamp.
- Per i dati a terra: formati di pubblicazione richiesti (GTFS e GTFS-RT, oppure NeTEx e SIRI se l'ente lo prevede), frequenza di aggiornamento e accesso per il punto di accesso nazionale.
- Per la proprietà del dato: accesso dell'ente ai dati grezzi e alle API, senza dipendenza dal fornitore.
Per un AVM che funziona su smartphone e tablet, come Pysae, che esporta GTFS e GTFS-RT, la domanda utile in fase di progetto non è "ITxPT sì o no", ma quali dati di bordo servono davvero al sistema centrale e attraverso quale interfaccia vanno raccolti. Meglio una verifica caso per caso che una compatibilità dedotta da un'etichetta. Per il funzionamento di un AVM in cloud si veda la nostra guida al sistema AVM per il trasporto pubblico.
FAQ
ITxPT sostituisce GTFS-RT, NeTEx o SIRI?
No. ITxPT regola il dialogo tra apparati dentro il veicolo (e in parte con il back office), mentre GTFS-RT, NeTEx e SIRI servono a scambiare e pubblicare i dati di servizio tra sistemi a terra e verso app e paline. Sono livelli complementari.
Il label ITxPT garantisce che due apparati funzionino insieme?
Garantisce che ciascuno rispetti i servizi per cui è stato testato, in una versione precisa delle specifiche. Per l'interoperabilità effettiva occorre verificare che i due apparati implementino gli stessi servizi e versioni compatibili.
ITxPT è obbligatorio in Italia?
No, nessuna norma nazionale lo impone. Può però essere richiesto dall'ente nei capitolati di fornitura di veicoli e apparati, ed è utile per misurare in modo affidabile gli indicatori AVM e RIL della delibera ART 53/2024.
Fonti: ITxPT, sito ufficiale, pagine Members, Specifications e Catalogue (consultate a ottobre 2026); ITxPT, "ITxPT 2.0 Released" e "ITxPT 2.0 new release is arriving" (2017); ITxPT, "How ITxPT specifications are created"; ITxPT, "ITxPT welcomes Tisséo Collectivités"; Trapeze Group, white paper "ITxPT: Information Technology for Public Transport" (2021); IVECO BUS, comunicato "IVECO BUS pionera en el Protocolo ITxPT" (21 febbraio 2018); ICT Group, "ITxPT: plug-and-play IT-systems" (28 febbraio 2019); Autorità di Regolazione dei Trasporti, delibera n. 53/2024 e Allegato A; lentepubblica.it, "PNRR, autobus ecologici" (marzo 2022).