Open data e mobilità: come NeTEx, SIRI e OpRa trasformano i dati in infrastruttura

Per molti anni l’open data nel trasporto pubblico è stato associato soprattutto alla pubblicazione di file e API: fermate, linee, orari, posizione dei mezzi. Oggi il tema si è spostato. La disponibilità del dato resta necessaria, ma il suo valore dipende sempre più dalla capacità di descriverlo in modo coerente tra operatori, territori e piattaforme.

Il progetto AccessiNeTEx sperimentato a Torino rende concreto questo passaggio. La Città ha testato una piattaforma per raccogliere e gestire informazioni sull’accessibilità del trasporto pubblico utilizzando il modello NeTEx e il profilo europeo EPIAP. Il dato sull’accessibilità non rimane quindi confinato a una singola applicazione: può essere strutturato, scambiato e riutilizzato da sistemi differenti.

Una fermata può essere descritta semplicemente con un nome e delle coordinate. Per un passeggero con esigenze specifiche servono informazioni molto più dettagliate: presenza di ascensori, rampe, scale mobili, accessi, percorsi interni, servizi di assistenza, caratteristiche dei veicoli e compatibilità tra veicolo e banchina.

NeTEx permette di rappresentare queste informazioni attraverso un modello dati comune. Il profilo europeo EPIAP estende questa struttura proprio alle informazioni necessarie per descrivere l’accessibilità nei servizi di passenger information.

Il vantaggio è architetturale prima ancora che informativo. Se Torino, Milano, Parigi o un operatore ferroviario descrivono gli stessi concetti attraverso strutture compatibili, un journey planner o una piattaforma MaaS può utilizzarli senza costruire ogni volta un’integrazione proprietaria diversa per ciascuna fonte.

NeTEx, SIRI e OpRa fanno parte dello stesso ecosistema concettuale basato su Transmodel, il modello europeo di riferimento per il trasporto pubblico. Transmodel definisce concetti, relazioni e strutture comuni; gli standard di scambio traducono questo modello in formati utilizzabili dai sistemi informativi.

La distinzione più utile è temporale e funzionale:

• NeTEx rappresenta prevalentemente ciò che è pianificato e strutturale.
• SIRI rappresenta ciò che sta accadendo o è previsto nel breve termine.
• OpRa rappresenta ciò che è effettivamente accaduto e viene registrato per analisi e controllo.

Un esempio rende immediata la relazione. Per una corsa autobus delle 8:15, NeTEx può descrivere linea, percorso, fermate e orario programmato. SIRI può comunicare alle 8:07 che il mezzo arriverà alle 8:19. OpRa può registrare successivamente che il passaggio reale è avvenuto alle 8:21 e utilizzare quel dato per misurare puntualità e regolarità.

NeTEx, Network Timetable Exchange, è la specifica CEN dedicata allo scambio di orari e dati correlati al trasporto pubblico. È organizzata in sei parti, ognuna dedicata a uno specifico dominio funzionale.

Una stazione ferroviaria, per esempio, può essere rappresentata come uno Stop Place composto da più punti di fermata, ingressi e aree fisiche. Una linea autobus può essere collegata alle fermate che serve e ai diversi itinerari effettuati.

Una stessa linea può percorrere lo stesso itinerario ma avere frequenze diverse il sabato, oppure terminare alcune corse prima del capolinea. Queste differenze possono essere rappresentate senza creare dataset separati e incompatibili.

Un sistema può, ad esempio, descrivere un biglietto urbano da 90 minuti, il relativo ambito territoriale e le condizioni di validità in una forma comprensibile anche da altri sistemi.

Il concetto di profilo è centrale: lo standard completo è molto ampio; il profilo stabilisce quali elementi devono essere utilizzati e con quali regole, così da rendere realmente interoperabili implementazioni diverse.

La differenza è sostanziale. Sapere che una stazione esiste appartiene al livello base della rete. Sapere dove si trovano ingressi, ascensori e percorsi interni aggiunge profondità al modello. Sapere se il percorso tra ingresso e banchina è effettivamente utilizzabile da una persona con mobilità ridotta porta l’informazione nel dominio dell’accessibilità.

Le sei Parti di NeTEx appartengono allo standard europeo CEN/TS 16614 e coprono domini funzionali differenti: rete, orari, tariffe, passenger information, modalità alternative e accessibilità.

Un profilo serve invece a rendere lo standard concretamente applicabile in uno specifico contesto. NeTEx è molto ampio e consente diverse alternative di modellazione; il profilo seleziona gli elementi necessari, ne precisa l’utilizzo e può stabilire quali informazioni siano obbligatorie.

Il Profilo Italiano NeTEx nasce con questa finalità. Le linee guida nazionali v4.0.1 lo definiscono come riferimento per l’interscambio dei dati tra Regional Access Point — RAP — e National Access Point — NAP. Il documento parte dal profilo europeo per le informazioni ai passeggeri e aggiunge progressivamente gli elementi richiesti dal contesto nazionale.

Le linee guida italiane v4.0.1 articolano il profilo in cinque livelli, che ampliano progressivamente il patrimonio informativo rappresentato.

Costituisce la base del Profilo Italiano ed è orientato a coprire le specifiche della Parte 4 di NeTEx, cioè EPIP.

Comprende gli elementi necessari a descrivere il servizio in maniera interoperabile per l’informazione al passeggero: organizzazioni, rete, fermate, linee, percorsi, calendari e corse.

Una piattaforma può così ricevere in maniera standardizzata la Linea 10, conoscere l’operatore, sapere quali StopPlace serve, quale percorso segue e quali VehicleJourney sono programmati durante la giornata.

Il secondo livello aggiunge informazioni utili a correlare il servizio di trasporto pubblico agli aspetti contrattuali di interesse delle pubbliche amministrazioni.

È una caratteristica significativa del profilo italiano perché estende il dato oltre la pura passenger information.

Lo stesso servizio può essere collocato anche all’interno della struttura di responsabilità e governance con cui viene programmato e affidato. Il dato può quindi diventare parte dell’infrastruttura informativa utilizzata da ente regolatore, amministrazione e operatori.

Il terzo livello aggiunge le informazioni relative alla tariffazione.

Entrano nel perimetro strutture tariffarie, prodotti, condizioni di utilizzo e altri oggetti necessari a rappresentare il prezzo e le regole di accesso al servizio.

A questo livello il sistema può conoscere non soltanto che esiste un collegamento tra A e B, ma anche quale prodotto tariffario è applicabile e secondo quali condizioni.

Per journey planner evoluti, MaaS e sistemi di vendita, pianificazione del viaggio e condizioni economiche diventano così parti dello stesso patrimonio informativo.

Il quarto livello amplia il perimetro ai servizi di trasporto alternativi al trasporto pubblico tradizionale.

Il modello può quindi includere progressivamente servizi diversi da autobus, tram, metropolitana e ferrovia.

È un passaggio particolarmente rilevante per ecosistemi MaaS e journey planner multimodali, nei quali la rete di mobilità comprende servizi differenti che devono poter essere descritti attraverso una semantica comune.

Il quinto livello introduce le informazioni di accessibilità associate a elementi quali Quay, StopPlace, Line e VehicleJourney.

È il livello direttamente rilevante per il caso AccessiNeTEx.

Una stazione può quindi essere rappresentata non solo attraverso posizione, fermate e linee che la servono, ma anche attraverso attributi che aiutano a comprendere le condizioni con cui il servizio può essere utilizzato.

Consideriamo una stazione denominata “Centrale”.

• Al Livello 1 possiamo rappresentare lo StopPlace, le linee che lo servono, le corse e gli orari.
• Al Livello 2 possiamo aggiungere gli elementi utili a collegare il servizio alla struttura amministrativa e contrattuale.
• Al Livello 3 possiamo rappresentare gli elementi tariffari associati.
• Al Livello 4 la stessa area può essere collegata a ulteriori servizi di mobilità.
• Al Livello 5 possiamo aggiungere le caratteristiche di accessibilità necessarie a comprendere se fermata, banchina, linea o specifica corsa siano adatte a determinate esigenze.

Lo stesso oggetto fisico acquista così una rappresentazione digitale progressivamente più ricca.

È in questo senso che va letto il riferimento al Level 5 nel caso Torino: il progetto utilizza il livello del Profilo Italiano dedicato alle informazioni di accessibilità.

SIRI, Service Interface for Real Time Information, è lo standard europeo per lo scambio di informazioni in tempo reale tra sistemi del trasporto pubblico. È basato anch’esso su Transmodel e comprende diversi servizi funzionali, ciascuno destinato a uno specifico tipo di informazione.

• SIRI-PT — Production Timetable: comunica la produzione pianificata per una determinata giornata operativa.
• SIRI-ET — Estimated Timetable: aggiorna la corsa con gli orari stimati di arrivo e partenza.
• SIRI-SM — Stop Monitoring: offre la vista centrata sulla fermata, indicando quali mezzi stanno arrivando e con quale previsione.
• SIRI-VM — Vehicle Monitoring: offre la vista centrata sul veicolo, con posizione e stato corrente.
• SIRI-SX — Situation Exchange: descrive perturbazioni, incidenti, eventi pianificati e altre situazioni che modificano il servizio.
• SIRI-FM — Facility Monitoring: comunica variazioni nella disponibilità di impianti e facilities per i passeggeri.
• SIRI-CM — Connection Monitoring: supporta il coordinamento delle coincidenze tra servizi.
• SIRI-CA — Control Actions: rappresenta azioni di controllo adottate dagli operatori durante la gestione real-time.

Consideriamo una stazione con ascensore censito in NeTEx. Alle 7:30 il sistema di manutenzione rileva un guasto. La struttura fisica della stazione non è cambiata, quindi il dato NeTEx rimane valido. Ciò che cambia è lo stato operativo della facility: SIRI-FM può rendere disponibile questa informazione ai sistemi di passenger information. Se il guasto causa anche una deviazione del servizio o una limitazione della stazione, SIRI-SX può descrivere la situazione.

Lo stesso principio vale per una corsa. NeTEx dice che il bus dovrebbe arrivare alle 8:15; SIRI-ET aggiorna la previsione alle 8:19; SIRI-SM permette alla palina o all’app di mostrare “4 minuti”.

OpRa, Operating Raw Data and Statistics Exchange, presidia un dominio diverso: i dati operativi osservati che devono essere raccolti e conservati per analizzare il servizio e misurarne la qualità.

Il suo ruolo riguarda informazioni come:

• tempi di passaggio effettivi;
• fermate realmente effettuate;
• dati di domanda disponibili;
• eventi operativi;
• altre informazioni osservate utili a ricostruire come il servizio è stato effettivamente prodotto.

SIRI serve a gestire e informare mentre il servizio sta accadendo. OpRa consente invece di ricostruire, analizzare e misurare il servizio dopo che è accaduto.

Supponiamo che una linea abbia orario programmato alle 8:15.

• NeTEx: arrivo programmato 08:15.
• SIRI: arrivo previsto 08:19.
• Dato osservato: arrivo effettivo 08:21.

Quel dato osservato può alimentare il dominio OpRa e diventare input per un KPI di puntualità. Se lo stesso fenomeno si ripete per settimane, l’autorità può verificare se il problema è episodico o strutturale.

L’utilità aumenta ulteriormente combinando questi dati con conteggi passeggeri, validazioni o altre fonti operative. La semantica dell’indicatore può rimanere comune anche quando il dato originario proviene da tecnologie differenti.

L’ecosistema può essere letto come una sequenza.

La stessa catena sostiene decisioni diverse:

• il passeggero utilizza soprattutto le informazioni programmate e real-time;
• la control room lavora sul livello operativo;
• il planner confronta pianificato e osservato;
• l’autorità misura le performance;
• il data analyst individua pattern ricorrenti;
• il management può utilizzare gli indicatori per modificare servizio, contratti o investimenti.

La rilevanza degli standard europei sta anche qui. Non servono soltanto a imporre un formato comune: costruiscono una semantica condivisa del servizio di mobilità, dalla pianificazione alla produzione reale.

Un ulteriore standard completa il quadro: OJP — Open Journey Planning.

OJP non descrive principalmente un dataset. Definisce un’interfaccia aperta attraverso la quale journey planner differenti possono interrogarsi e costruire itinerari distribuiti, anche interregionali o transfrontalieri.

NeTEx, SIRI e OpRa standardizzano soprattutto le informazioni e gli scambi associati al servizio. OJP lavora invece sull’interoperabilità tra motori di journey planning.

Un journey planner italiano può quindi interrogare un sistema svizzero senza dover necessariamente importare e replicare preventivamente tutto il dataset svizzero. Ogni sistema può continuare a calcolare la propria parte del viaggio e cooperare attraverso un’interfaccia comune.

Questo diventa particolarmente rilevante quando l’obiettivo è costruire servizi realmente multimodali e transfrontalieri.

Dichiarare semplicemente “utilizziamo NeTEx” dice relativamente poco.

Due sistemi possono essere entrambi conformi allo standard e utilizzare subset differenti, campi opzionali diversi o profondità informative incompatibili.

Lo standard fornisce il linguaggio comune; il profilo stabilisce come quel linguaggio deve essere utilizzato in un determinato ecosistema. I livelli del Profilo Italiano precisano poi progressivamente quale patrimonio informativo deve essere rappresentato.

Per un’amministrazione o un operatore, la domanda progettuale diventa quindi più precisa: quale standard utilizziamo, quale profilo adottiamo, quale livello informativo ci serve e per sostenere quale servizio?

La risposta incide direttamente su architettura, qualità del dato, responsabilità degli operatori, capitolati, integrazioni e capacità future di riutilizzo.

Gli stessi standard possono sostenere use case molto differenti.

• Un journey planner può individuare itinerari compatibili con specifiche esigenze di mobilità.
• Una piattaforma MaaS può combinare trasporto pubblico, sharing e servizi on-demand.
• Una control room può utilizzare dati dinamici per gestire perturbazioni.
• Un’autorità può utilizzare dati storici e osservati per verificare KPI e livelli di servizio.

La standardizzazione permette quindi di separare progressivamente il dato dall’applicazione che lo utilizza.

È una condizione fondamentale per evitare che ogni nuovo servizio digitale richieda una nuova catena di integrazioni punto-punto.

L’interoperabilità tecnica non elimina il problema della qualità.

Per alimentare correttamente questi ecosistemi occorre stabilire:

• chi produce il dato;
• chi lo aggiorna;
• chi verifica la coerenza semantica;
• quale frequenza di aggiornamento è richiesta;
• quali livelli di qualità devono essere rispettati.

Il passaggio da dataset isolati a un’infrastruttura nazionale basata su profili condivisi rende queste responsabilità ancora più rilevanti: un errore prodotto alla fonte può propagarsi attraverso RAP, NAP, journey planner e applicazioni utilizzate dal passeggero.

Il tema dell’open data entra quindi direttamente nel modello operativo.

AccessiNeTEx è interessante perché mostra questa evoluzione su un caso concreto.

Un’applicazione per l’accessibilità diventa il punto di ingresso per costruire informazioni strutturate secondo un modello europeo e una profondità informativa coerente con il Profilo Italiano.

Lo stesso approccio può estendersi a infomobilità, MaaS, monitoraggio delle performance, pianificazione del servizio e regolazione.

La traiettoria europea porta verso un ecosistema nel quale operatori, amministrazioni e piattaforme condividono progressivamente modelli, semantica e regole di rappresentazione del dato, oltre ai dataset.

È questo passaggio che può trasformare l’open data da semplice obbligo di pubblicazione a vera infrastruttura digitale per la mobilità.