Blogs Dal legacy al digitale: perché la gestione dei requisiti e del ciclo di vita deve cambiare nel settore rail

Dal legacy al digitale: perché la gestione dei requisiti e del ciclo di vita deve cambiare nel settore rail

20 maggio 2026

Marco Forlingieri è Senior Director Product Line Engineering (PLE) in PTC e Chair della INCOSE PLE Working Group. Esperto internazionale di Model-Based Systems Engineering (MBSE) e Model-Based Product Line Engineering (MB‑PLE), ha guidato iniziative complesse in ambiti aerospace, difesa, automotive e ferroviario in Europa, USA e APAC. È autore del volume di riferimento Model-Based Product Line Engineering (Wiley). Con un Master in Innovation & Technology Management presso l’Università Tecnica di Berlino e un MBA all’Università di Twente nei Paesi Bassi, Marco vanta oltre 15 anni di esperienza in aziende leader nei settori A&D e Transportation, tra cui Airbus e Bombardier, oltre che in realtà internazionali del software e della consulenza come IBM e Accenture.

Vedi tutti gli articoli di questo autore

Quando i progetti ferroviari raggiungono milioni di ore di ingegneria, o semplicemente falliscono.

In media, un moderno programma di veicoli ferroviari richiede oltre due milioni di ore di ingegneria.

Nel peggiore dei casi, come dimostrano esempi ben noti di SNCF in Francia e Renfe in Spagna, a distanza di quasi dieci anni, i programmi falliscono strutturalmente, generando ritardi enormi, danni reputazionali e centinaia di milioni di euro di extra-costi.

In entrambi i casi, sono stati consegnati treni troppo “larghi” che non potevano operare sull’infrastruttura prevista: banchine in Francia, gallerie in Spagna. Non si è trattato di errori di produzione tardivi, ma di fallimenti di ingegneria di sistema. Situazioni analoghe sono molto più frequenti di quanto si ammetta apertamente.

Nella mia esperienza diretta nel settore ferroviario, una decisione strutturale rilevante, il passaggio da norme su carbody in alluminio a una carbody in acciaio per un treno a due piani, è stata identificata come critica solo quando il progetto era già in una fase avanzata, innescando riprogettazioni, riqualificazioni e rielaborazioni significative. Questi non sono episodi isolati. Sono sintomi di problemi strutturali nel modo in cui i sistemi ferroviari vengono specificati, progettati, validati e riutilizzati tra i programmi.

La pressione sugli OEM del settore ferroviario è in costante aumento

I programmi ferroviari stanno diventando sempre più lunghi, complessi ed esposti al cambiamento:

  • Piattaforme di veicoli con cicli di vita di 20–30 anni
  • Requisiti che evolvono continuamente a causa di:
    • Normative nazionali e locali
    • Vincoli infrastrutturali
    • Opzioni specifiche del cliente
    • Sottosistemi sempre più software defined (TCMS, segnalamento, cybersecurity)
  • Programmi distribuiti su più segmenti:
    • Linea principale (VHS, SD, DD)
    • Mass transit (Heavy, Medium, Light, LRV)
    • Locomotive

Nonostante ciò, gli OEM del settore ferroviario continuano a sviluppare i progetti come silos indipendenti, anche se fino all’80% delle funzioni del treno (incluse quelle legate al segnalamento) è comune tra i segmenti.
Il risultato?
Ogni nuovo progetto si comporta come se fosse unico, con poco riuso, scarsa collaborazione e un enorme consumo di risorse ingegneristiche.

La causa principale: una mentalità document based

Una delle cause fondamentali di queste inefficienze è che l’industria ferroviaria si basa ancora fortemente su processi document centrici:

  • Dalla Invitation to Tender
  • Attraverso sviluppo e certificazione
  • Fino all’after sales

Molte organizzazioni continuano a dipendere da soluzioni legacy di requirements management come DOORS Classic.

Anche quando si adottano piattaforme più moderne come Polarion, l’approccio spesso non cambia:

  • La soluzione viene fortemente personalizzata
  • I processi vengono forzati per replicare il paradigma documentale
  • PDF, Word e baseline statiche restano il fulcro del lavoro

In pratica, il settore ha digitalizzato i documenti, senza trasformare realmente l’ingegneria.

Gli strumenti legacy non sono solo obsoleti, sono un limite strutturale

Nel tempo, le soluzioni RM/ALM legacy nel settore rail si sono trasformate in sistemi:

  • Fortemente personalizzati e fragili
  • Difficili da evolvere e integrare
  • Inadeguati per:
    • Collaborazione multidisciplinare
    • Analisi d’impatto del cambiamento
    • Gestione della configurazione e delle varianti
    • Branching e riuso
    • Automazione e continuità digitale

Le conseguenze sono evidenti:

  • Requisiti clonati e copiati tra i progetti
  • Tracciabilità ricostruita manualmente, tardi e sotto pressione
  • Scoperte tardive di incoerenze, inevitabili e costose

In un settore dove compatibilità infrastrutturale, sicurezza e certificazione sono assolute, questo modello non è più sostenibile.

La modernizzazione parte da una solida dorsale ALM

gestione-requisiti-settore-ferroviario-1.png

La trasformazione dell’ingegneria dei sistemi ferroviari deve iniziare da una piattaforma ALM moderna e robusta, come Codebeamer, in grado di supportare:

  • Tracciabilità end to end
  • Consapevolezza di configurazioni e varianti
  • Automazione lungo l’intero ciclo di vita
  • Integrazione con software, test e modelli di Sistema

Ma l’ALM, da solo, non basta.

L’unione di ALM + PLE: la leva strategica che l’industria ferroviaria non può più ignorare

gestione-requisiti-settore-ferroviario-2.png

Il vero salto di qualità avviene combinando ALM moderno e Product Line Engineering (PLE), supportato da soluzioni come Pure Variants.

Questa combinazione consente agli OEM ferroviari di:

  • Identificare ciò che è comune tra piattaforme e segmenti
  • Gestire esplicitamente la variabilità
  • Passare da Engineer to Order a Configure to Order
  • Riutilizzare sistematicamente requisiti, architetture, test e documentazione
  • Ridurre drasticamente il non recurring engineering tra i progetti

Il settore ferroviario è particolarmente adatto alla PLE:

  • Famiglie di treni
  • Strategie di piattaforma
  • Equipaggiamenti opzionali
  • Varianti paese e normative
  • Variabilità hardware e software da governare in modo coerente

Questo è il vero punto di partenza della trasformazione.

L’MBSE viene dopo, ma solo se orientato al riuso

Solo quando un’organizzazione ha:

  • Una solida base ALM
  • Maturitá nei processi di Systems Engineering
  • Una strategia PLE consolidata

ha senso scalare in modo efficace la Model Based Systems Engineering (MBSE).
Anche in questo caso, il focus iniziale dovrebbe essere sulle aree a maggior valore:

  • Analisi operativa
  • Analisi funzionale
  • Decomposizione del sistema

È fondamentale che anche l’MBSE adotti i principi della PLE.

In una precedente esperienza su una piattaforma UK di veicoli ferroviari, sono stati fatti forti investimenti in MBSE, ma senza considerare riuso e variabilità. Il risultato è stato che i modelli hanno supportato solo il primo progetto, non la piattaforma. Concluso quel progetto, gran parte del valore dei modelli è andato perso. Senza una basa solida di Systems Engineering e senza una gestione strutturata della variabilità, l’MBSE rischia di diventare l’ennesimo silo.

L’ultimo passo: da ALM a PLM come digital factory

L’ultimo livello di maturità è una integrazione profonda tra ALM e PLM.

Non si tratta più di collegare strumenti, ma di costruire un digital fabric strategico, che connetta:

  • Requisiti
  • Funzioni
  • Architetture logiche e fisiche
  • Software e hardware
  • E BOM e M BOM

La variabilità deve essere gestita in modo coerente su tutti i domini:

  • Hardware e software
  • Sistemi e sottosistemi
  • Ingegneria e produzione

La variabilità non conosce confini tra strumenti, e nemmeno la governance dovrebbe.

Un futuro in cui i programmi ferroviari sono più prevedibili, rapidi e sicuri

Gli approcci legacy, document based e le soluzioni RM fortemente personalizzate hanno servito l’industria ferroviaria per decenni.
Ma non sono più adeguati alla complessità attuale.

Con un percorso chiaro e progressive che si fonda su:

  1. Stabilire una dorsale ALM moderna
  2. Industrializzare il riuso con la Product Line Engineering
  3. Adottare MBSE sulla base di un fondamento di Systems Engineering, con variabilità e riuso al centro
  4. Costruire un digital thread coerente fino al PLM

gli OEM ferroviari possono:

  • Ridurre drasticamente le sorprese tardive
  • Evitare di ripetere casi come SNCF o Renfe
  • Risparmiare milioni di ore ingegneristiche per programma
  • Migliorare qualità, compliance e prevedibilità
  • Costruire vere piattaforme, non singoli progetti isolati
  • Senza una gestione strutturata della variabilità, l’MBSE rischia di diventare l’ennesimo silo

La trasformazione dello sviluppo dei sistemi ferroviari non è più opzionale. È ciò che distingue la progettazione di piattaforme dalla ripetizione degli stessi errori costosi, progetto dopo progetto.

Argomenti Progettazione tecnica delle linee di prodotti
Prossimo

I cinque principali casi d'uso dell'integrazione ALM-PLM

Esplora i cinque principali casi d'uso che motivano i clienti PTC a integrare e migliorare la loro maturità ALM e PLM Scopri di più
Marco Forlingieri

Marco Forlingieri è Senior Director Product Line Engineering (PLE) in PTC e Chair della INCOSE PLE Working Group. Esperto internazionale di Model-Based Systems Engineering (MBSE) e Model-Based Product Line Engineering (MB‑PLE), ha guidato iniziative complesse in ambiti aerospace, difesa, automotive e ferroviario in Europa, USA e APAC. È autore del volume di riferimento Model-Based Product Line Engineering (Wiley). Con un Master in Innovation & Technology Management presso l’Università Tecnica di Berlino e un MBA all’Università di Twente nei Paesi Bassi, Marco vanta oltre 15 anni di esperienza in aziende leader nei settori A&D e Transportation, tra cui Airbus e Bombardier, oltre che in realtà internazionali del software e della consulenza come IBM e Accenture.

per saperne di più