Un operatore di trasporto pubblico metropolitano affronta tre decisioni accoppiate: quali linee di autobus operare, con quale frequenza in ogni fascia oraria, e quali fermate serve ciascuna linea. Problema canonico di ricerca operativa nel TPL: Public Transit Network Design and Frequency Setting Problem (FSP).
In breve
Ti suona familiare?
- Operiamo 50-300 linee in città; percorso e fermate di ciascuna linea sono stati disegnati anni fa e non sono rivisti periodicamente — aggiungere una linea per un nuovo quartiere costa settimane al pianificatore.
- La frequenza di ogni linea (un autobus ogni 8 min in punta, ogni 20 fuori punta) la fissa il pianificatore a intuito; il legame fra dati di domanda e modello numerico è debole.
- Le lamentele degli utenti si dividono in due: 'ho aspettato 15 minuti la mattina e l'autobus era pieno' e 'la sera circolano autobus vuoti, soldi pubblici sprecati' — non riusciamo a ottimizzare entrambi i lati numericamente.
- Ai nodi di interscambio i passeggeri attendono arrivi sincronizzati; il tempo di trasbordo oscilla fra 8 e 20 minuti tra due linee; non riusciamo a sostenere un orario periodico clock-face.
- Aumentare la frequenza di una linea (= più autobus) è legato a un aumento di budget; nella trattativa annuale non riusciamo a presentare un report strutturato del tipo 'con N autobus in più la soddisfazione cresce di tanto'.
- La città cresce e il pattern di domanda cambia (nuovi centri direzionali, campus universitari, connessioni esterne); le linee esistenti non rispondono — nessun metodo numerico per ottimizzare l'insieme delle linee.
- Si discute il corridoio BRT (autobus rapido) o l'integrazione con metro/tram; nella rete attuale non possiamo separare numericamente le linee chiaramente adduttrici da quelle a servizio diretto.
Perché è importante
Come si risolve
Profondità tecnica
Come si risolve
Profondità tecnicaIn una frase: Fornisci i flussi origine-destinazione dei passeggeri e l’insieme delle linee candidate; un modello matematico sceglie congiuntamente quali linee operare e la frequenza per fascia oraria (5/8/10/15/20 min) — minimizza attesa + tempo di viaggio + costo operativo insieme.
Nella letteratura di Ricerca Operativa (disciplina che usa matematica e informatica per risolvere decisioni di business) il problema si chiama Public Transit Network Design and Frequency Setting Problem (FSP). La visione accademica organizza la pianificazione del TPL in cinque stadi: (i) progettazione di rete (quali linee, quali percorsi), (ii) assegnazione delle frequenze (frequenza per linea per fascia oraria), (iii) timetabling (quale corsa a quale minuto), (iv) assegnazione dei veicoli (quale autobus a quale corsa), (v) assegnazione dei conducenti (quale autista a quale autobus). #091 copre i primi due strati; gli altri tre sono problemi separati. Soluzione in tre stadi:
1. Modellazione. Dati di ingresso: (a) domanda — matrice origine-destinazione (flusso fermata-fermata per fascia, da 6-12 mesi di biglietto/tessera elettronica), (b) rete — viaria (lunghezza tratto, velocità media, traffico per fascia), fermate candidate (esistenti + proposte), linee candidate (80-300 candidate, in maggioranza esistenti più alcune nuove), (c) flotta — numero totale autobus, tipo (autobus urbano standard, snodato, midibus — capacità e costi orari diversi), finestre di manutenzione, capacità delle rimesse, (d) parametri di vincolo — distanza massima a piedi (300-500 m), attesa massima (punta < 8 min, fuori punta < 15 min, notte < 25 min), tempo totale massimo (con trasbordo), tetto del fattore di carico (85% della capacità). Variabili di decisione: quale linea candidata si opera (0/1), per linea operata frequenza per fascia (continua o discreta: 5/8/10/12/15/20 min), autobus assegnati per linea (= frequenza × tempo di ciclo). Vincoli: budget totale di flotta, ogni fermata coperta da almeno una linea, sincronizzazione ai nodi di interscambio, tetto di carico, distanza a piedi massima, attesa massima. Obiettivo: multi-obiettivo — minimo attesa + viaggio del passeggero (soddisfazione) più minimo pesato costo operativo (autobus × costo orario + carburante + manutenzione); il peso è decisione di policy comunale.
2. Decisione con solver. Formulazione classica in due stadi: prima progettazione di linee (simile a set covering), poi frequenza per linea via analisi marginale. Approccio moderno: MIP combinato (Mixed-Integer Linear Programming — ottimizzazione con alcune variabili 0/1 e altre continue) — progettazione + frequenza insieme. Approccio per generazione di colonne (partire con un piccolo pool di pattern e aggiungere quelli utili passo per passo): ogni linea candidata è una colonna (pattern), il master problem sceglie le linee e alloca la frequenza. Modellazione dell’attesa — con arrivi Poisson dei passeggeri, attesa media = 1/(2×frequenza) (formula analitica); per gli effetti di carico, correzione non lineare. Scala media (50-150 linee, 20-40 fasce) si risolve con solver MIP maturi in ore; scala grande (300+ linee, 50+ fasce) richiede generazione di colonne o metaeuristiche (metodi di ricerca intelligenti — genetico, tabu, LNS). Multi-obiettivo come somma pesata o gerarchico (prima tempo passeggero, poi costo); analisi di Pareto presentata al comitato comunale.
3. Integrazione di campo. Output a tre strati: (a) mappa di progettazione di rete — quali linee, percorso + elenco fermate (piano annuale della centrale operativa, revisione stagionale), (b) tabella delle frequenze — matrice linea × fascia (5/8/10/15/20 min), (c) bozza di orario periodico — frequenza × tempo di ciclo → minuto di partenza stimato per corsa (passo successivo: timetabling, soluzione separata). L’output FSP alimenta il Sistema Intelligente di Trasporto (ITS): conteggio passeggeri in tempo reale, posizione del bus (AVL — Automatic Vehicle Location), dati di tessera. Revisione annuale o stagionale di rete (programma estate/inverno, integrazione nuovi quartieri), aggiustamento mensile delle frequenze (festività, riapertura scuole). Comitato trimestrale TPL: attesa reale vs piano, fattore di carico, sondaggio di soddisfazione, report di shift modale.
Alternative
Manuale più foglio di calcolo
GratuitoZero licenza
Per chi: Comune piccolo (<500K ab.), 10-40 linee, 80-150 autobus
- + Zero costi software
- + Conta la conoscenza locale della rete del pianificatore
- + Revisione annuale gestibile in rete piccola
- − Sopra 50 linee il pianificatore satura
- − Spazio frequenza × linea × fascia non ottimizzabile a mano
- − Attesa del passeggero non misurata numericamente, solo percepita
- − Sincronizzazione di trasbordo non disegnabile a mano
- − Analisi di capacità (per decisioni di investimento) debole
Software locale di gestione TPL
Aziendale400K-2M TRY licenza + 150K-600K TRY/anno manutenzione (osservazione mercato TR)
Per chi: Comune medio (500K-2M ab.), 40-150 linee, 150-400 autobus
- + UI in turco, supporto locale
- + Tessera elettronica + AVL integrati
- + Database linea-fermata-corsa + report di base pronti
- + Vicino alla normativa TR (report annuali)
- − Modulo di ottimizzazione FSP generalmente assente — decisioni linea e frequenza ancora manuali
- − Modello multi-obiettivo (tempo vs costo) debole
- − Sincronizzazione di trasbordo limitata
- − Nessuna integrazione con ottimizzazione accademica di linee e frequenze
Software internazionale di pianificazione TPL
Aziendale1-4M EUR licenza + 200K-800K EUR/anno manutenzione (mercato grandi comuni)
Per chi: Grande metropoli (2M+ ab.), 150+ linee, 400+ autobus, BRT/metro integrati
- + Modulo FSP maturo — MIP, generazione di colonne, metaeuristiche
- + Progettazione multi-modale (bus + metro + tram)
- + Periodico clock-face + sincronizzazione integrati
- + Report di analisi di capacità ricchi per investimenti
- − Licenza alta + lunga (18-30 mesi) implementazione
- − Personalizzazione ai formati locali TR aggiunge tempo
- − Formazione del team operativo programma esteso
- − Supporto locale spesso da remoto
Solver open-source + modulo FSP proprio
Open SourceLicenza gratuita; sviluppo interno 24-48 settimane o 1-2.5M TRY consulenza
Per chi: Metropoli con team tecnico, quando serve integrazione con ITS esistente
- + Nessuna quota di licenza
- + Formulazioni di progettazione di linee + frequenze ben definite con solver open-source
- + Generazione di colonne + metaeuristiche in letteratura aperta
- + Dati di campo (tessera, AVL) integrati direttamente
- − Specialista OR + team integrazione ITS interni indispensabili
- − Passaggio dal prototipo accademico al sistema di campo richiede tempo
- − Manutenzione resta in casa
- − Integrazione multi-modale è sviluppo extra
Raccomandazione
Chiedi nell'incontro
- Avete un modulo di progettazione di rete (insieme di linee) oppure solo assegnazione di frequenze? Quando si aggiunge o si rimuove una linea, il sistema ri-ottimizza?
- L'approccio di assegnazione di frequenze è analitico (formula 1/(2×frequenza)), MIP o metaeuristico? Come è modellata la correzione del fattore di carico?
- È supportata l'ottimizzazione multi-obiettivo (attesa vs costo operativo)? Come si presenta la frontiera di Pareto al comitato decisionale?
- Il sincronizzazione ai nodi di interscambio è vincolo hard o soft? Come si ottimizza l'attesa fra due linee che si connettono?
- In quale formato si ingerisce la matrice di domanda (tessera, OD)? Si aggiorna ogni 6 mesi o annualmente?
- Vincolo di flotta (autobus totali fissi) + finestre di manutenzione + capacità rimesse — come integrati? L'abbinamento linea × frequenza × autobus è automatico?
- Durante il pilota potete consegnare un report comparativo di 12-16 settimane (attesa, carico, costo) rispetto all'assegnazione manuale precedente?
- Se il contratto termina, in quale formato possiamo esportare la storia del design di linee, le tabelle di frequenze, la matrice di domanda, la statistica di carico e l'archivio orari?
Dettagli tecnici
Nota editoriale
Il problema in gergo comune si chiama ‘frequenza dell’autobus’, ‘pianificazione di linee’ o ‘programma di servizio’. Nella letteratura accademica porta due strati collegati ma separati: Transit Network Design (design di linee — quali linee operano, quali fermate servono) e Frequency Setting Problem (FSP) (frequenza per linea per fascia). Insieme sono i primi due stadi della gerarchia di pianificazione; i tre restanti sono timetabling (come in #076 per gli orari periodici ferroviari), assegnazione dei veicoli (quale autobus a quale corsa) e assegnazione dei conducenti (quale autista a quale autobus).
Problemi che sembrano vicini ma sono diversi: #039 School Bus Routing Problem (SBRP) è trasporto scolastico a orario fisso — l’orario di inizio della scuola è hard, ubicazione delle fermate + assegnazione studente-fermata + percorsi sono accoppiati; due corse al giorno in due direzioni; identità dei passeggeri nota. #076 Train Timetabling Problem (TTP) è orario ferroviario — infrastruttura fissa (binario unico, raddoppi), ogni treno programmato singolarmente, coordinamento periodico clock-face. #047 Dial-a-Ride Problem (DARP) è trasporto a chiamata — nessun percorso fisso, il cammino del veicolo è dinamico alla chiamata del passeggero. #091, invece, risponde a ‘quali linee operano + a quale frequenza’ sulla rete urbana di autobus a percorso fisso — i passeggeri vanno a una fermata fissa su una linea fissa, le corse sono cicliche.
Punto più dimenticato nella pratica: il trade-off numerico congiunto fra soddisfazione del passeggero e costo operativo. I pratici regolano la frequenza una variabile alla volta a intuito (‘questa linea è piena, su la frequenza’); l’approccio accademico mette attesa del passeggero (analitica 1/(2×frequenza) con correzione non lineare per il carico) e tempo di trasbordo in un modello numerico e ottimizza congiuntamente con il costo operativo (autobus × costo orario + carburante + manutenzione). Con una frontiera di Pareto al comitato comunale si presentano scelte numeriche tipo ‘se il budget cresce del 10%, l’attesa scende del 25%’ — la regolazione intuitiva non costruisce questo schema.
Secondo punto dimenticato: sincronizzazione ai nodi di interscambio. Se due linee si incontrano nello stesso interscambio, con il minuto di arrivo di una e quello di partenza dell’altra pianificati a 2-4 minuti di distanza, il tempo di trasbordo è minimo; senza, un’attesa di 10-20 minuti rompe la soddisfazione. Si gestisce con orario periodico clock-face (passo successivo: timetabling, soluzione separata). L’output FSP deve portare le frequenze in una famiglia di periodo comune (es. frequenze a scaglioni 6-12-24 minuti); senza codifica, la sincronizzazione cede sul campo.
Roadmap passo-passo — per PMI
Stadio 1 — Misurare prima di pianificare. Almeno 12 mesi di dati: salite/discese con tessera (matrice OD dove ricavabile), conteggi linea × fermata × fascia, fattore di carico di linea, attesa reale vs piano (sondaggio alla fermata + AVL). Inventario flotta: numero autobus, tipo (capacità + costo orario), calendario manutenzione, rotazione rimesse. Inventario rete: linee esistenti (percorsi + fermate), ubicazione fermate, traffico per segmento.
Stadio 2 — Estrarre il capitale di conoscenza. Pattern di domanda per fascia (punta mattina 07:00-09:00, giornata, punta pomeriggio 17:00-19:00, sera, notte). Profilo del passeggero: lavoro-scuola-acquisti. Curva di carico delle linee: quale si riempie a quale ora, quale va vuota. Insieme di nuove linee candidate (nuovi quartieri, centri direzionali, campus). Nodi di interscambio e tempi attuali.
Stadio 3 — Pilota. 12-16 settimane. Per un sottoinsieme (es. 15-20 delle 80 linee, focus sulla punta) eseguire l’assegnazione FSP MIP in parallelo alla manuale. La decisione resta al comitato; l’FSP fornisce proposta. Criteri di successo fissati prima: attesa media −15% minimo, deviazione standard del carico di linea −20% (bilanciamento), costo operativo stabile o −5%.
Stadio 4 — Rollout. 18-30 mesi fino alla rete completa + timetabling + assegnazione veicoli + integrazione ITS. Revisione annuale (programma estate/inverno, integrazione di nuovi quartieri). Comitato trimestrale: report attesa, aggiornamento fattore di carico, sondaggio soddisfazione, analisi di shift modale.
Rischi — cosa può andare storto
- Deriva nella previsione di domanda (mutamento demografico). La matrice OD è costruita su 6-12 mesi di storia; nuovi centri, campus, aree residenziali e commercio cambiano il pattern rapidamente. Senza ricalibrazione ogni 6-12 mesi, l’output FSP si stacca dalla realtà. Monitoraggio mensile con tessera + riottimizzazione annuale completa sono obbligatori.
- Taglio di budget (la flotta si riduce). I bilanci comunali subiscono pressione ciclica; un ’tolti 30 autobus dalla flotta’ a metà anno rompe l’ipotesi FSP. Variante FSP robusta (scenari di flotta ±15%) o analisi Pareto condizionata al budget vanno presentate al comitato.
- Aumento del tempo di viaggio per congestione. Il tempo di ciclo di linea dipende dal traffico; stessa frequenza in punta richiede più autobus. Senza dati di traffico (velocità per segmento per fascia) nel modello, il piano non si realizza (autobus insufficienti). Le misurazioni vanno ricalibrate ogni 6 mesi.
- Lock-in su un unico fornitore ITS. Se il contratto ITS omette ’esportazione annuale in formato standard dei dati di tessera, storia AVL, statistica di conteggio, archivio linea-corsa’, uscire significa perdere la memoria operativa. Il modulo FSP e l’ITS devono restare disaccoppiati (API standard).
Vista tecnica sui metodi di soluzione
| Approccio | Scala tipica | Tempo di risoluzione | Ottimo garantito? |
|---|---|---|---|
| Frequenza euristica (pianificatore + regola) | Rete piccola, <40 linee | immediato | No, 50-70% ottimo |
| Ceder-Wilson due stadi (linea → frequenza) | Rete media, 40-100 linee | minuti-ore | Sì (ogni stadio localmente) |
| MIP FSP combinato | Rete media-grande, 50-150 linee | ore | Sì (entro bound) |
| Generazione di colonne (Borndörfer et al.) | Rete grande, 150-300 linee | molte ore | Buon bound inferiore/superiore |
| Metaeuristica (genetico, tabu, LNS) | Molto grande + multi-modale | ore-continuo | No, buona qualità pratica |
Funzione obiettivo scelta:
- Obiettivo 1 — Minimo attesa + viaggio del passeggero: Focus sulla soddisfazione.
- Obiettivo 2 — Minimo costo operativo: Focus sul budget.
- Obiettivo 3 — Massimo ridership (shift modale): Spinta sul TPL; guadagno dall’auto.
- Obiettivo 4 — Fattore di carico bilanciato: Bilanciare linee sature e vuote; focus efficienza.
Multi-obiettivo: somma pesata (tempo del passeggero pesante, costo secondario) o gerarchico (budget prima, poi tempo) o analisi della frontiera di Pareto.
Fonti accademiche
Elencate nel campo sources del frontmatter.
Fonti
- Ceder, A. e Wilson, N. H. M. (1986). Bus network design. Transportation Research Part B: Methodological, 20(4), 331-344. Riferimento fondativo per il design delle linee TPL.
- Ceder, A. (2007). Public Transit Planning and Operation: Theory, Modelling and Practice. Elsevier. Libro di testo canonico; gerarchia di pianificazione e modelli di frequenza.
- Ibarra-Rojas, O. J., Delgado, F., Giesen, R. e Munoz, J. C. (2015). Planning, operation, and control of bus transport systems: A literature review. Transportation Research Part B: Methodological, 77, 38-75. Rassegna moderna completa.
- Schöbel, A. (2012). Line planning in public transportation: models and methods. OR Spectrum, 34(3), 491-510. Rassegna di letteratura sulla line planning.
- Borndörfer, R., Grötschel, M. e Pfetsch, M. E. (2007). A column-generation approach to line planning in public transport. Transportation Science, 41(1), 123-132. Approccio per generazione di colonne.
- YÖK Centro Tesi del Consiglio dell’Istruzione Superiore — parole chiave: ’toplu taşıma’, ‘otobüs hat’ o ’transit ağ’ — 20+ tesi dall’accademia TR. tez.yok.gov.tr
Glossario
- Transit Network Design
- Problema di OR che decide in una rete urbana quali linee di autobus (o tram, metro) operare, quali fermate serve ciascuna linea e quale percorso seguire — sotto budget operativo totale, copertura della domanda e qualità di interscambio.
- Frequency Setting
- Sotto-problema operativo che determina con quale frequenza ogni linea di TPL viene servita per fascia oraria (es. un autobus ogni 6, 10 o 20 minuti), in base al profilo di domanda, alla flotta e agli obiettivi di qualità di servizio.
- MIP
- Modello di ottimizzazione in cui alcune variabili decisionali devono essere numeri interi (es. numero di camion, numero di turni).
- School Bus Routing
- Variante del VRP (Vehicle Routing Problem) in cui gli autobus prendono e lasciano studenti assegnati alle fermate, sotto vincoli di capacità, tempo massimo di viaggio, coordinamento degli orari e equità della distanza a piedi.